AlloyDB のデータ分析基盤での活用におけるポテンシャルとは？

｜　　© PLAID Inc. 2022.06.08　　｜　　Data Analytics / Database OnAir　　｜　 1
AlloyDBのデータ分析基盤での
活用におけるポテンシャルとは？
株式会社プレイド小川拓也

｜　　© PLAID Inc. 2
自己紹介
小川拓也
Takuya Ogawa
2009年にヤフーに新卒入社し、エンジニアとして広告システム
やtoCサービスの開発・運用・マネージメント等に従事。
その後2019年12月にプレイドに入社し、ユーザー分析の機能
である「KARTE Insight」や「KARTE Live」を中心にプロダク
ト開発を行なっている。
Lead Product Engineer @ PLAID, Inc.

アジェンダ
・PLAID / KARTEについて
・KARTEの分析基盤と課題感
・Columnar engineの検証
・AlloyDBの活用どころ
・今後の展望

KARTEについて
一人一人に合わせた
顧客体験を提供
Webサイトの訪問者の行動を
顧客ごとにリアルタイムに解析
CX(顧客体験)プラットフォーム
karte.io

Stats of KARTE
145億UU
累計ユーザー数 ※1
0.x秒/解析
解析速度
135,000 over
秒間トラッキング数 ※3
2.43兆円
年間解析流通金額 ※2
※1 ローンチ〜2022年3月までのユニークユーザー数の実績
※2 EC領域における解析流通金額。
2021年3月〜2022年2月までの単年の実績
※3 秒間解析イベント数
（閲覧、購入、クリックなど全計測イベントが対象。
2022 年 3 月最大値）
8+ PB
蓄積データ量
180+ PB
月間解析データ量
karte.io
CX(顧客体験)プラットフォーム
KARTEについて

Stats of KARTE
KARTEについて
KARTE Insightの主な機能

・今後の展望
アジェンダ

KARTEの分析基盤と課題感
データ分析周辺のアーキテクチャ概要
エンドユーザークライアント
Cloud Spanner
ユーザー解析のためのユーザー
統計値やイベントデータ
Cloud
Bigtable
BigQuery
イベントデータ
分析で重要なデータはscheduled queryで
差分ロードしレプリケーション
ユーザーに対する外部
データ付加や CRMデータ
外部データの書き込みやシンプルな検索
リアルタイム性を重視する分析画面のための
データ取得。主に1ユーザー単位の処理。
各種事前計算処理の実行
高度な検索・分析処理でのクエリ実行
※全体のアーキテクチャから一部抜き出し簡略化
Track / real-time analyze Admin

｜　　© PLAID Inc.
見出しテキスト
9
・分析機能ではBigQueryをメ
インDBとして利用
・対話的な検索・分析機能
・自由度のあるスキーマレス
データのあらゆるフィールドに
対応

selection
projection
aggregation
…
cycle: adhoc, every X minutes, every hour, every
day, etc.
Analysis features
Tables or materialized views
analytical query
raw event data
BigQuery内部でのデータフロー

- 対話的な分析機能のレイテンシーを0.X秒にしたい
- BigQueryは強力でPB級データにもスケールし優れたパフォーマンスを出せる
- テーブル構造やクエリを最適化し数秒という単位は実現できるケースはあるがそれ以上の高速化を行いたい
- 大規模な事前計算処理とも同居する為、それらにSlotが圧迫され予測し辛いパフォーマンスの変化が起こる
- BigQueryをより使い倒す余地はまだまだある e.g. JSON型 (preview)、BI Engine
- その為の高速な分析処理のレイヤーが欲しい
- フラットにさまざまな列指向DBも含め検討 e.g. Snowflake、Druid、Citus Data、etc…
- 複数のオプションがある中で、その一つとなるポテンシャルをAlloyDBに感じた https://tech.plaid.co.jp/bigquery-
slot-resource-optmization

・今後の展望
アジェンダ

13
Columnar engine
・列指向処理を透過的に拡張
: クエリに応じ自動判定され、ʼCustomScanʼが行われる（クエリの書き換えは不要でオプティマイザに任せられる）
・非常に高速: オンメモリで処理される為、Index無しで高いパフォーマンス
・事前に設定が必要: メモリサイズの設定とストアするカラムの指定。実行されたクエリを自動で学習し、ストアデータを自動で最適化させる事も可能。
https://cloud.google.com/alloydb/docs/columnar-engine/about
Columnar engineの検証

BigQuery
検証用のアドホック環境
Data ow
Compute
Engine
AlloyDB
実際に分析機能で使用する構造
と同等の行動データ
(社内用データ
)
最低限の加工処理を行いロード
開発機
psql/pgbenchで
クエリ実行
PostgreSQLのCLI/GUIツール
で各種操作
4vCPU, 32GB / Columnar engineを設定したpoolと無効なpoolをそれぞれ
用意 / キャッシュサイズは10,000MB
Size: 約20GB
Rows: 約9,000,000

SELECT
COUNT(*)
FROM
events
WHERE
event_date >= TIMESTAMP '2022-05-01 00:00:00'
AND event_name = 'view';
SELECT
day, COUNT(*)
FROM
(
SELECT
DISTINCT DATE_TRUNC('day', event_date) AS day,
visitor_id
FROM
events
WHERE
AND event_name = 'view'
) AS t
GROUP BY 1
ORDER BY 1;
検証用クエリ1:単純なカウントのみを行うクエリ検証用クエリ3:日毎のユニークユーザー数を集計する
クエリ
それぞれ、event_dateの時間指定を調整してスキャン行数を増やしながらテスト
SELECT
AVG(CURRENT_TIMESTAMP - event_date)
FROM
events
WHERE
AND event_name = 'view';
検証用クエリ2:経過時間の平均値を取るクエリ

SELECT google_columnar_engine_add(
‘public.events’, ‘event_name, event_date,visitor_id’
);
Columnar engineへ必要なカラムをストア
CREATE INDEX "test_idx" ON "public"."events" USING BTREE ("event_date","event_name");
Indexの作成
Indexが有効な場合での実行速度も確認したかった為作成。
Indexが無い状態と、Indexを作成しènable_seqscan`をòff`にし状態でそれぞれ検証。
前準備

scan rows
Columnar engine なし
Index Scan
Seq Scan
Columnar engine あり
Custom Scan(Columnar engine)
Ratio
クエリ1
10% (900,000) 312 ms 18,123 ms 55 ms 5.6x / 329.5x
40% (3,500,000) 928 ms 18,572 ms 56 ms 16.5x / 331.6x
100% (9,000,000) 2.133 ms 19,239 ms 56 ms 38.0x / 343.5x
クエリ3
10% (900,000) 775 ms 37,610 ms 561 ms 1.3x / 67.0x
40% (3,500,000) 2,573 ms 40,639 ms 1,878 ms 1.3x / 21.6x
100% (9,000,000) 7,081 ms 43,193 ms 5,358 ms 1.3x / 8.0x
クエリ2
10% (900,000) 390 ms 15,666 ms 202 ms 1.9x / 77.5x
40% (3,500,000) 1,153 ms 17,173 ms 587 ms 1.9x / 29.2x
100% (9,000,000) 2,893 ms 18,470 ms 1,616 ms 1.7x / 11.4x

scan rows
Index Scan
Seq Scan
Columnar engine あり
Custom Scan(Columnar engine)
Ratio
クエリ1
10% (900,000) 317 ms 2757 ms 30 ms 10.5x / 91.9x
40% (3,500,000) 920 ms 2812 ms 38 ms 24.2x / 74x
100% (9,000,000) 2.182 ms 2912 ms 35 ms 62.3x / 83.2x
クエリ3
10% (900,000) 790 ms 7169 ms 550 ms 1.4x / 13.0x
40% (3,500,000) 2,559 ms 8484 ms 1,799 ms 1.4x / 4.7x
100% (9,000,000) 6946 ms 11594 ms 5,274 ms 1.3x / 2.1x
クエリ2
10% (900,000) 344 ms 2911 ms 133 ms 2.5x / 21.8x
40% (3,500,000) 1,020 ms 3015 ms 356 ms 2.8x / 8.4x
100% (9,000,000) 2,577 ms 3450 ms 836 ms 3.0x / 4.1x
Appendix:4vCPU, 32GB → 8vCPU, 64GB

参照：https://cloud.google.com/alloydb/docs/columnar-engine/about
- 今回の検証では複数パターンのクエリでどれも優れたパフォーマンス
- Seq Scanに対しては圧倒的、Index Scanに対しても優位
- 分析クエリを同一DBで実行している場合、殆どのケースでパフォーマンスが改善され得る
- ただし現実のクエリはより複雑でシステムの負荷特性等に依る
- 分析クエリ用のIndexの削除でトランザクションワークロードの高速化と運用負荷軽減に繋がる
- メモリ上にデータをストアする為、どの様な戦略でストアする対象を決めるかも重要
- テーブル構造次第でレコメンダーにチューニングを任せるのみで済む
- KARTEを例にすると、イベントデータはスキーマレスな特性があり、分析ワークロードも最大限柔軟に行いたい、という
前提がある
- 全てのデータをストアするとコスト効率が悪くキャパシティもすぐに達してしまう為スキーマの最適化が必要
- パーティショニングやRead poolの分割も有効

・今後の展望
アジェンダ

AlloyDBの活用どころ
RDBMS
OLTP
worload
read / write
データエンジニア・
アナリスト・BIツール
AlloyDB
Primary
DWH
ETL / ELT / CDC
AlloyDB
Read pool
OLTP
worload
read / write
データエンジニア・
アナリスト・BIツール
e.g. OLTP + OLAPで最も価値を発揮
replication (full managed)
- DWHへの連携処理を省略
- アプリケーションはI/FをPostgreSQLに統一
- レプリケーションラグも少なくなる

AlloyDBの活用どころ
e.g. BigQueryの中間テーブルをload/unload
Transparent
data
integration
selection
projection
aggregation
…
cycle: adhoc, every X minutes, every hour,
every day, etc.
Analysis
features
Tables or materialized views
analytical query
raw event data
selection
projection
aggregation
…
Analysis
features
analytical query

・今後の展望
アジェンダ

今後の展望
- AlloyDBの機能拡張に伴いながら今後もより実際的な
PoCを行なっていきたい
特に期待する機能・・・
- Google Cloudの他DBサービスとのインテグレーション機能
- 特にBigQuery上のデータのフェデレーション
- マネージド、透過的
- Columnar engineの機能・メンテナンス性の向上
- jsonb型のサポート
- メモリストアに載せるデータの詳細な条件指定
- メモリストアの使用量やストアされた列等のメトリクス計測・可視化
- レコメンダーの最適化パラメータの実績と結果の履歴
- BigQueryはじめ他DBサービスの新機能も使い倒しながら組み合わせていく

AlloyDB のデータ分析基盤での活用におけるポテンシャルとは？

AlloyDB のデータ分析基盤での活用におけるポテンシャルとは？

More Related Content

What's hot

Similar to AlloyDB のデータ分析基盤での活用におけるポテンシャルとは？

AlloyDB のデータ分析基盤での活用におけるポテンシャルとは？