100 億人のユーザー行動からインサイトを得るための大規模分析基盤 〜BigQuery を活用して〜
https://cloudonair.withgoogle.com/events/google-cloud-day-digital-21/watch?talk=d1-da-05
"KARTE では、これまで累計約 100 億人のユーザー行動を解析してきました。本セッションでは、KARTE において行動データを分析しインサイトを得るプロダクトについてご紹介し、プロダクトを支える大規模分析基盤についてご説明します。この基盤は BigQuery が主軸になっており、Partitioning・キャッシング・Column の最適化など運用における具体的な工夫点について解説致します。
"
| 質問 |
返答 |
| KARTEのpocky eventは今後、パーティショニングテーブルの列削除機能がGAされたら、シャーディングでなくパーティショニングテーブルにしていくのでしょうか。 |
ご指摘の通りです。現在では移行が可能になったたため、より効率的なテーブル構成にするためにパーティショニングへの移行を進めております。 |
| TrackサーバやアナライズサーバがGCEで、AdminはGKEな使い分けの理由はどんなところでしょうか。 |
過去の移行の経緯によります。初期ではEC2で構築されており、2017年頃に解析サーバーをまずGCEに移行した背景があります。その後、管理画面をGKEに2019年頃に移行したため、別々になっております。 |
|
去年のGCDでもご紹介しておりますので、よろしければご参考ください（ https://speakerdeck.com/tikson/plaids-journey-with-multi-cloud-10128526-d75f-41de-98ec-27025f8d35a9 ） |
| 切り口 |
内容 |
| KARTEについて |
一人一人に合ったUXを提供する |
| KARTEのアーキテクチャ |
多いときは1000台近くGKEがスケールする。KARTE Pockyイベントがデータ分析の中心で、データレイク。 |
| BQのポイント |
|
| ①について |
用途に応じて使い分けたいという要望があった。 |
| ①について |
KARTE Pockyイベントは変更が容易にできる必要があった。そのためShardingTableである必要があった。セッションサマリはパーティショニングで使いたかった。 |
| ②について |
KARTE Pockyイベントにたいして、クエリキャッシュがきかず、表示に時間がかかった。中間テーブルを作ることでこれが解決した。MaterializedViewを使う手段もあったが、テーブルの最大作成数やクエリの制約があり、要求を満たせなかった。自由度が高く、高速な検索ができる一般的なテーブルを使った。中間テーブルを分けることで、データを最小限にした。 |
| ③について |
データ構造により、スロットもたくさん消費している。分析時の問題が右の画像。そこで、カラムを切り出した。カラムの切り出しで分析の効率化を実施し、コストも少なくなった。 |
| MLPipleineについて |
|
