ぼくのかんがえる最高のデータ分析基盤 / strongest-data-architecture-discussion

# みんなの考えた最強のデータアーキテクチャ

https://datatech-jp.connpass.com/event/258157/

## イベント説明

datatech-jpで集ったデータエンジニアが、それぞれみんなの考えた最強のデータアーキテクチャを紹介し合うという夢のような企画が実現しました！
たくさんの新しいプロダクトが群雄割拠する現在、モダンデータスタックなどという言葉も登場しています。
今こそ、どんなプロダクトを選び、どのようなデータ基盤を作れば、効率的にやりたいことが実現できるのか。
5人の猛者からおすすめの構成をご紹介いただきながら、参加者のみなさんとも一緒に考えていく時間としたいと思います。
ぜひ奮ってご参加ください！

## 発表概要

広告配信システムで発生する大量で多種多様のデータ。そして、人間の多種多様なデータへのニーズに耐えるために至ったデータアーキテクチャについてお話できればと思います。

Transcript

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