Slide 1
Slide 1 text
ぼくのかんがえる
最高のデータ分析基盤
データ分析基盤の構築事例
みんなの考えた最強のデータアーキテクチャ 2022/11/08
Slide 2
Slide 2 text
No content
Slide 3
Slide 3 text
なぜこのような設計になったか、
泥臭い背景とセットで話そうと思います。
Slide 4
Slide 4 text
誰のためのデータ基盤
主に機械学習チームが使う。
多種多様で大量の広告ログを、
機械学習の学習データとして
使いたい。また、分析する時にも
簡単にクエリしたい！
弊社の機械学習チームについては、
過去に話をしたスライドがあるので、興味あればどうぞ。
speakerdeck.com, データをモデリングしていたら、組織をモデリングし始めた話 , 2022/11/07,
speakerdeck.com/pei0804/engineers-in-carta-vol3-data-engineer
Slide 5
Slide 5 text
アドテクおける機械学習の活用例
Demand Side Platform(以下DSP)は、Supply Side Platform(以下SSP)と
OpenRTB（≒プロトコル）を使って、オークションを行っている。
※弊社はDSPを作っている。
SSP「こういうユーザー来たけど、何円で広告出したい？」
DSP「んーーーー。◯円！！！」
「んーーーー」って考えるところに、
機械学習を使っている部分が入ってきます。
※時間の都合上、かなり割愛しています。
Slide 6
Slide 6 text
多種多様なデータ
OpenRTBとは、オークションを、
このフォーマットで、やりましょうを
決めたものです。
こういうユーザー来たけど広告枠買う？は、
でっかいJSONで表現されています。
OpenRTBの仕様については、
インターネットで公開されています。
www.iab.com/, OpenRTB Spec v2.5, 2022/11/07,
www.iab.com/wp-content/uploads/
2016/03/OpenRTB-API-Specification-Version-2-5-FINAL.pdf
Slide 7
Slide 7 text
でっかいJSONのスクリーンショットです。
Slide 8
Slide 8 text
この一つひとつが、
分析で使う値になりえるので、扱いが面倒。
Slide 9
Slide 9 text
広告はそれなりに、
ログが大量に発生します。
1種類の使いたいログだけでも、
day8億レコード程度。
アドテクにおいてのログは、
お金に直結する存在なので、
丁寧に扱う必要があります。
大量データ
アドテクのログについては、
過去に発表してるので、興味あればどうぞ。
speakerdeck.com, ぼくのかんがえる最高のレポーティング基盤 , 2022/11/07,
speakerdeck.com/pei0804/
hokufalsekankaeruzui-gao-falserehoteinkuji-pan-at-awsdeshi-jian-analytics-
modernization
Slide 10
Slide 10 text
大変なのは分かった！！
いい感じにしよう！！！！
Slide 11
Slide 11 text
という話をする予定でした。
Slide 12
Slide 12 text
最終的に、全社（Zucks）向けの
データ基盤を目指すことになりました。
Slide 13
Slide 13 text
ぼくのかんがえる
最高のデータ分析基盤
データ分析基盤の構築事例
みんなの考えた最強のデータアーキテクチャ 2022/11/08
Slide 14
Slide 14 text
話すこと
● データ基盤を作る時の技術選定や設計の考え方。
Slide 15
Slide 15 text
話さないこと
● データモデリング。
○ いくらでも話せますけど、時間の都合上無理でした。
Slide 16
Slide 16 text
アジェンダ
● 自己紹介
● 背景
● 出来上がったもの
Slide 17
Slide 17 text
自己紹介
ぺい
@pei0804
近森淳平(チカモリ ジュンペイ)
CARTA HOLDINGS （旧VOYAGE GROUP）
Zucks システム局 エンジニア
Slide 18
Slide 18 text
techblog.cartaholdings.co.jp, The Zen of Zucks, 2022/06/10, https://techblog.cartaholdings.co.jp/entry/the-zen-of-zucks
Slide 19
Slide 19 text
アジェンダ
● 自己紹介
● 背景
● 出来上がったもの
Slide 20
Slide 20 text
別の事に当たる2つのデータ基盤があった。
Slide 21
Slide 21 text
データ分析基盤とレポーティング基盤
Slide 22
Slide 22 text
データ分析基盤
データ分析基盤が作られる前から、アプリケーションはAWSにあり、
そこから生まれるログは、全てAmazon S3(以下S3)に上がっていた。
サービスが成長する過程で、データの分析をしたいニーズが生まれ、
2015年頃から、Google BigQuery(以下BigQuery)をベースとした
データ分析基盤が作られた。
BigQueryはGoogle Cloud Storage(以下GCS)に置いたデータしか、
取り込めないため、日々発生するログをS3からGCSへ転送する必要があった。
この仕組みが簡単ではなく、一定の属人性が発生していた。
Slide 23
Slide 23 text
レポーティング基盤
DSPは様々なイベントが発生する。
それらのレポーティングだけで、
人々は疲弊していた。
その疲弊を無くすために、
レポーティング基盤が構築された。
元あったデータ分析基盤は、
分析のために作られた物であり、
メンタルモデルが合わないことや、
BigQueryよりも、要件にマッチした
AWS Redshift(以下Redshift)を
採用した。
レポーティングとは何か？については、
過去に発表してるので、興味あればどうぞ。
speakerdeck.com, まだレポーティング業務で疲弊してるの？ , 2022/11/07,
https://speakerdeck.com/pei0804/aws-media-seminar-2022-q1
Slide 24
Slide 24 text
分散によるデメリット
それぞれの基盤は、当初は適材適所に機能をしていた。
しかし、分散のデメリットも見え始めた。
例えば、データウェアハウス(以下DWH)の片方にしか入ってないデータ。
片方にしか適用されていないロジック。片方にしかない仕組みなど。
一方で、どちらも同じ品質や機能性を維持すると、コストが倍になるので、
生産性を上げづらい構造になってしまっていた。
Slide 25
Slide 25 text
一つのDWHに出来ないか？
Slide 26
Slide 26 text
BigQuery、Redshiftの両方の強みを持ったDWH
事前にどんなクエリが発行されるか予測がつきにくい分析は、
BigQueryのようなクエリパワーがほしい。
しかし、データ運搬業が発生するため、簡単にログをロード出来ない。
一方で、Redshiftは、簡単にログをロード出来て、定常クエリには強い。
だけど、事前に必要なパワーが予測できない分析には、心もとない。
両方のいいとこ取り出来るDWHはないのだろうか・・・。
そこで、最近気になっていたSnowflakeを調べたところ、
アーキテクチャ的にいける気がしてきたので、詳しい人に聞いてみた。
Slide 27
Slide 27 text
ある夜の雑談
「Snowflakeでいけそうです？」
「絶対それSnowflakeでいけるよ！」
「なるほどおおおおおお」
※多少文脈が省かれています。
Slide 28
Slide 28 text
PoCした結果、圧倒的だったので、
Snowflakeを採用しました。
Slide 29
Slide 29 text
SnowflakeがRedshiftより優れてるところ
コンピューティングとストレージが、完全に分離している。
例えば、クエリの性質に応じたパワー調整が、一瞬でしかも簡単。
Redshiftだとクラスター自体の調整が必要で面倒。
用途に応じて、クラスターを分けれるけど、手間がかかる。
Slide 30
Slide 30 text
SnowflakeがBigQueryより優れてるところ
● S3にあるログを、そのままSnowflakeに取り込める。
○ Snowflakeの仕組み上、
AWSの同一リージョン通信で済むので、転送料がかからない。
○ GCSへのログ運搬が必要なくなるので、
そのための仕組みが全ていらなくなる。
● 課金体系がウェアハウス（≒コンピューティング）実行時間課金。
○ BigQueryのスキャン量課金は、個人的に難しい。
Snowflakeなら、効率が良いテーブル作ればいいだけ。
Slide 31
Slide 31 text
騙されたと思って、
Snowflakeのトライアルやってみましょう。
ガチで世界が変わります。（当社比）
※私は営業では、ありません。
Slide 32
Slide 32 text
アジェンダ
● 自己紹介
● 背景
● 出来上がったもの
Slide 33
Slide 33 text
No content
Slide 34
Slide 34 text
ここ
Slide 35
Slide 35 text
S3 -> dbt -> Snowflake
Slide 36
Slide 36 text
dbtで
ETL????????????
WHY!!!!!!!!!!!!!!!
Slide 37
Slide 37 text
ELTの「T」を担当するツールと言われています。
ELTとは、Extract（抽出）、Load（ロード）、Transform（変換）。
今回は、あろうことか、ETL処理をdbtにやってもらいました。
dbtとは
Slide 38
Slide 38 text
dbt ETLがやっていること
● やっていること
○ ログを1時間ごとに、Snowflake External Stage(以下External Stage)
からデータを取り出して、Snowflakeにロードする。
● 特徴
○ 冪等性。
■ 問題が起きたら再実行するだけで良い。
○ データの変換処理は一切しない。
■ メタデータカラムだけの追加はしている。
● この時点で間違えた変換があると、巻き戻しが大変なので、
変換しないことで、問題発生ポイントをSnowflake内に、
完結させることが狙い。
Slide 39
Slide 39 text
External Stageとは
一言で言うと、SnowflakeからS3に直接クエリが出来る。
例えばs3://adtechlog/clicks/2022/11/01/07/に取り込みたいログがある。
SELECT * FROM @adtechlog/clicks/2022/11/01/07/ で取ってこれる。
結果の取得は、通常のSELECTと同じ。
Slide 40
Slide 40 text
dbt x Snowflake External Stage
dbtからExternal Stageへクエリすれば、なんと簡単にETLが出来る。
Slide 41
Slide 41 text
dbt + External Stage以外に検討した方法
● COPY句
○ COPYは、dbtで素直に発行できるクエリではなかった。
カスタムマテリアライゼーションとかで、頑張れば出来るけど・・・
● Snowflake External Table
○ 初期作成時にパーティションが多すぎてエラーになった。
都度パーティション作るなり、頑張れば出来るけど、頑張りたくない。
● Snowflake Snowpipe（以下Snowpipe）
○ パフォーマンス面は問題なかったけど、コスパが合わなかった。
オブジェクト数課金なので、使うなら、ログの数を減らす必要がある。
それなりに様々なサーバーがあるので、そこから頑張るのは、コスパ悪い。
Slide 42
Slide 42 text
dbt cloudを使っていない理由
課金形態が、開発スタイルとマッチしない。
弊社では、基本的に決められた開発領域がないため、
データ基盤も全員が触ることを想定する必要がある。
dbt cloudだと、開発者数に応じた課金アップモデルなので、
少ししか触らない人でも、一人分のコストを払う必要がある。
また、dbt coreで、レポーティング基盤の実装を、
再実装をした経験もあったため、cloudの採用を見送った。
Slide 43
Slide 43 text
オーケストレーションにStepFunctions
オーケストレーションには、
StepFunctions(以下SFN)を全面的に採用している。
理由は、コストパフォーマンスが圧倒的であるため。
現状は、1時間に1回の実行と、10分に1回の実行をしているSFNがある。
かかっているコストは、なんと、$0.03/day だけ。
例えば、これをAirflow(MWAAなど)で同じことをやると、
維持費だけで倍以上のコストがかかる。
しかも、Airflowじゃないと出来ないこと…が思いつかずSFNを採用。
Slide 44
Slide 44 text
ここ
Slide 45
Slide 45 text
S3 -> Snowpipe -> Snowflake
Slide 46
Slide 46 text
Snowpipeとは
ファイルがステージで利用可能になり
次第、ファイルからデータをロードしま
す。データは、
参照パイプで定義されている COPY
ステートメントに従ってロードされま
す。(公式の説明)
docs.snowflake.com, Snowpipeの紹介, 2022/11/07,
docs.snowflake.com/ja/user-guide/data-load-snowpipe-intro.html
Slide 47
Slide 47 text
S3イベントをトリガーに、
ロードしといて！って設定すると、
勝手にSnowflakeにロードしてくれる。
Slide 48
Slide 48 text
Snowpipeの用途
バッチロードだと、数値を見れるのが最速でも1時間後になるので、
それより早く見たいデータをSnowpipeで収集するようにしてる。
オブジェクト数課金になるので、そこのコスパが合うのであれば、
基本的に全てのロードは、Snowpipeでやってしまって問題ない。
今回作ったデータ基盤が扱ってるログでは、コストが高くつくので、
全面的な採用は見送っている。
Slide 49
Slide 49 text
ここ
Slide 50
Slide 50 text
Amazon Aurora -> Fivetran -> Snowflake
Slide 51
Slide 51 text
Fivetranとは
様々なデータソースと、
さくっと連携してくれるSaaS。
公式サイトにどんなデータソースと連携できるか
紹介されてます。
www.fivetran.com, Fivetran, 2022/11/07, www.fivetran.com
Slide 52
Slide 52 text
Fivetranの用途
Amazon Auroraに入ってる管理画面のデータとの連携や、
今後発生するちょっとしたデータ連携などに使っていく。
これを自前でやろうとすると、結構大変で、それなりの工数が
発生する。これをFivetranでやると、本当にすぐ出来る。
一方で、ビジネスクリティカルなデータ、大量データ部分には、Fivetranは使っ
ていない。
例えば、広告ログだと、課金体系的に高くつきすぎるのと、
なんらか障害発生時に、コントロール出来る余地を残しておきたい。
Slide 53
Slide 53 text
Fivetranを採用した理由
ETLにカスタム設定が出来ないのが魅力的だった。
個人的に、データソースから、DWHにロードする時は、
Rawデータ（≒生ログ）のままにしてほしい。
経験的に、データソースから変換したものしかDWHにないと辛い。
例えば、問題が起きた時に、ロード部分まで疑う必要が出る。
また、再集計時にロードからやり直しになることがあるので、
基本的にはRawはそのまま入ってるという状態にした。
そして、FivetranはRawはそのままです！が強制されるので、良かった。
Slide 54
Slide 54 text
ここ
Slide 55
Slide 55 text
Transform by dbt in Snowflake
Slide 56
Slide 56 text
dbtを使ったデータ変換(Transform)
データソースからロードされたRawデータを、
使いやすいデータに変換するのにdbtを使っている。
主なモデリング手法は、ディメンションモデリングを採用している。
Slide 57
Slide 57 text
ディメンションモデリングとは
ディメンションモデリングって何？は、
過去の発表資料にあるので、興味あればどうぞ。
ディメンションモデリングとは、
データウェアハウスにデータを
格納するために、
最適化されたデータ構造の手法。
※本日は、時間の都合上、
モデリングについては語れません。
speakerdeck.com, モデリングはキラキラ技術より地味だが役に立つ , 2022/11/07,
speakerdeck.com/pei0804/modeling-over-shiny-tech
Slide 58
Slide 58 text
今後の展望
Slide 59
Slide 59 text
今後の展望
● BigQueryとRedshiftに乗ってる運用を、少しずつSnowflakeへ。
● 開発しやすさの向上。
○ 一旦作り上げることに注力したので、改善の余地がある。
● データの傾向監視を入れたい。
○ dbt testだと、時系列での監視が難しいので、
elementaryというOSSを検討中。
Slide 60
Slide 60 text
まとめ
Slide 61
Slide 61 text
No content
Slide 62
Slide 62 text
これを2ヶ月くらいで作れるので、
いい時代になった！
Slide 63
Slide 63 text
朗報です。
実はエンジニア採用してます。
Slide 64
Slide 64 text
https://engineering.cartaholdings.co.jp/