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

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

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

## イベント説明

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

## 発表概要

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

Transcript

1. ぼくのかんがえる
   最高のデータ分析基盤
   データ分析基盤の構築事例
   みんなの考えた最強のデータアーキテクチャ 2022/11/08
   

   View Slide

2. View Slide

3. なぜこのような設計になったか、
   泥臭い背景とセットで話そうと思います。
   

   View Slide

4. 誰のためのデータ基盤
   主に機械学習チームが使う。
   多種多様で大量の広告ログを、
   機械学習の学習データとして
   使いたい。また、分析する時にも
   簡単にクエリしたい！
   弊社の機械学習チームについては、
   過去に話をしたスライドがあるので、興味あればどうぞ。
   speakerdeck.com, データをモデリングしていたら、組織をモデリングし始めた話 , 2022/11/07,
   speakerdeck.com/pei0804/engineers-in-carta-vol3-data-engineer
   

   View Slide

5. アドテクおける機械学習の活用例
   Demand Side Platform(以下DSP)は、Supply Side Platform(以下SSP)と
   OpenRTB（≒プロトコル）を使って、オークションを行っている。
   ※弊社はDSPを作っている。
   SSP「こういうユーザー来たけど、何円で広告出したい？」
   DSP「んーーーー。◯円！！！」
   「んーーーー」って考えるところに、
   機械学習を使っている部分が入ってきます。
   ※時間の都合上、かなり割愛しています。
   

   View Slide

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
   

   View Slide

7. でっかいJSONのスクリーンショットです。
   

   View Slide

8. この一つひとつが、
   分析で使う値になりえるので、扱いが面倒。
   

   View Slide

9. 広告はそれなりに、
   ログが大量に発生します。
   1種類の使いたいログだけでも、
   day8億レコード程度。
   アドテクにおいてのログは、
   お金に直結する存在なので、
   丁寧に扱う必要があります。
   大量データ
   アドテクのログについては、
   過去に発表してるので、興味あればどうぞ。
   speakerdeck.com, ぼくのかんがえる最高のレポーティング基盤 , 2022/11/07,
   speakerdeck.com/pei0804/
   hokufalsekankaeruzui-gao-falserehoteinkuji-pan-at-awsdeshi-jian-analytics-
   modernization
   

   View Slide

10. 大変なのは分かった！！
    いい感じにしよう！！！！
    

    View Slide

11. という話をする予定でした。
    

    View Slide

12. 最終的に、全社（Zucks）向けの
    データ基盤を目指すことになりました。
    

    View Slide

13. ぼくのかんがえる
    最高のデータ分析基盤
    データ分析基盤の構築事例
    みんなの考えた最強のデータアーキテクチャ 2022/11/08
    

    View Slide

14. 話すこと
    ● データ基盤を作る時の技術選定や設計の考え方。
    

    View Slide

15. 話さないこと
    ● データモデリング。
    ○ いくらでも話せますけど、時間の都合上無理でした。
    

    View Slide

16. アジェンダ
    ● 自己紹介
    ● 背景
    ● 出来上がったもの
    

    View Slide

17. 自己紹介
    ぺい
    @pei0804
    近森淳平(チカモリ　ジュンペイ)
    CARTA HOLDINGS （旧VOYAGE GROUP）
    Zucks システム局 エンジニア
    

    View Slide

18. techblog.cartaholdings.co.jp, The Zen of Zucks, 2022/06/10, https://techblog.cartaholdings.co.jp/entry/the-zen-of-zucks
    

    View Slide

19. アジェンダ
    ● 自己紹介
    ● 背景
    ● 出来上がったもの
    

    View Slide

20. 別の事に当たる2つのデータ基盤があった。
    

    View Slide

21. データ分析基盤とレポーティング基盤
    

    View Slide

22. データ分析基盤
    データ分析基盤が作られる前から、アプリケーションはAWSにあり、
    そこから生まれるログは、全てAmazon S3(以下S3)に上がっていた。
    サービスが成長する過程で、データの分析をしたいニーズが生まれ、
    2015年頃から、Google BigQuery(以下BigQuery)をベースとした
    データ分析基盤が作られた。
    BigQueryはGoogle Cloud Storage(以下GCS)に置いたデータしか、
    取り込めないため、日々発生するログをS3からGCSへ転送する必要があった。
    この仕組みが簡単ではなく、一定の属人性が発生していた。
    

    View Slide

23. レポーティング基盤
    DSPは様々なイベントが発生する。
    それらのレポーティングだけで、
    人々は疲弊していた。
    その疲弊を無くすために、
    レポーティング基盤が構築された。
    元あったデータ分析基盤は、
    分析のために作られた物であり、
    メンタルモデルが合わないことや、
    BigQueryよりも、要件にマッチした
    AWS Redshift(以下Redshift)を
    採用した。
    レポーティングとは何か？については、
    過去に発表してるので、興味あればどうぞ。
    speakerdeck.com, まだレポーティング業務で疲弊してるの？ , 2022/11/07,
    https://speakerdeck.com/pei0804/aws-media-seminar-2022-q1
    

    View Slide

24. 分散によるデメリット
    それぞれの基盤は、当初は適材適所に機能をしていた。
    しかし、分散のデメリットも見え始めた。
    例えば、データウェアハウス(以下DWH)の片方にしか入ってないデータ。
    片方にしか適用されていないロジック。片方にしかない仕組みなど。
    一方で、どちらも同じ品質や機能性を維持すると、コストが倍になるので、
    生産性を上げづらい構造になってしまっていた。
    

    View Slide

25. 一つのDWHに出来ないか？
    

    View Slide

26. BigQuery、Redshiftの両方の強みを持ったDWH
    事前にどんなクエリが発行されるか予測がつきにくい分析は、
    BigQueryのようなクエリパワーがほしい。
    しかし、データ運搬業が発生するため、簡単にログをロード出来ない。
    一方で、Redshiftは、簡単にログをロード出来て、定常クエリには強い。
    だけど、事前に必要なパワーが予測できない分析には、心もとない。
    両方のいいとこ取り出来るDWHはないのだろうか・・・。
    そこで、最近気になっていたSnowflakeを調べたところ、
    アーキテクチャ的にいける気がしてきたので、詳しい人に聞いてみた。
    

    View Slide

27. ある夜の雑談
    「Snowflakeでいけそうです？」
    「絶対それSnowflakeでいけるよ！」
    「なるほどおおおおおお」
    ※多少文脈が省かれています。
    

    View Slide

28. PoCした結果、圧倒的だったので、
    Snowflakeを採用しました。
    

    View Slide

29. SnowflakeがRedshiftより優れてるところ
    コンピューティングとストレージが、完全に分離している。
    例えば、クエリの性質に応じたパワー調整が、一瞬でしかも簡単。
    Redshiftだとクラスター自体の調整が必要で面倒。
    用途に応じて、クラスターを分けれるけど、手間がかかる。
    

    View Slide

30. SnowflakeがBigQueryより優れてるところ
    ● S3にあるログを、そのままSnowflakeに取り込める。
    ○ Snowflakeの仕組み上、
    AWSの同一リージョン通信で済むので、転送料がかからない。
    ○ GCSへのログ運搬が必要なくなるので、
    そのための仕組みが全ていらなくなる。
    ● 課金体系がウェアハウス（≒コンピューティング）実行時間課金。
    ○ BigQueryのスキャン量課金は、個人的に難しい。
    Snowflakeなら、効率が良いテーブル作ればいいだけ。
    

    View Slide

31. 騙されたと思って、
    Snowflakeのトライアルやってみましょう。
    ガチで世界が変わります。（当社比）
    ※私は営業では、ありません。
    

    View Slide

32. アジェンダ
    ● 自己紹介
    ● 背景
    ● 出来上がったもの
    

    View Slide

33. View Slide

34. ここ
    

    View Slide

35. S3 -> dbt -> Snowflake
    

    View Slide

36. dbtで
    ETL????????????
    WHY!!!!!!!!!!!!!!!
    

    View Slide

37. ELTの「T」を担当するツールと言われています。
    ELTとは、Extract（抽出）、Load（ロード）、Transform（変換）。
    今回は、あろうことか、ETL処理をdbtにやってもらいました。
    dbtとは
    

    View Slide

38. dbt ETLがやっていること
    ● やっていること
    ○ ログを1時間ごとに、Snowflake External Stage(以下External Stage)
    からデータを取り出して、Snowflakeにロードする。
    ● 特徴
    ○ 冪等性。
    ■ 問題が起きたら再実行するだけで良い。
    ○ データの変換処理は一切しない。
    ■ メタデータカラムだけの追加はしている。
    ● この時点で間違えた変換があると、巻き戻しが大変なので、
    変換しないことで、問題発生ポイントをSnowflake内に、
    完結させることが狙い。
    

    View Slide

39. External Stageとは
    一言で言うと、SnowflakeからS3に直接クエリが出来る。
    例えばs3://adtechlog/clicks/2022/11/01/07/に取り込みたいログがある。
    SELECT * FROM @adtechlog/clicks/2022/11/01/07/ で取ってこれる。
    結果の取得は、通常のSELECTと同じ。
    

    View Slide

40. dbt x Snowflake External Stage
    dbtからExternal Stageへクエリすれば、なんと簡単にETLが出来る。
    

    View Slide

41. dbt + External Stage以外に検討した方法
    ● COPY句
    ○ COPYは、dbtで素直に発行できるクエリではなかった。
    カスタムマテリアライゼーションとかで、頑張れば出来るけど・・・
    ● Snowflake External Table
    ○ 初期作成時にパーティションが多すぎてエラーになった。
    都度パーティション作るなり、頑張れば出来るけど、頑張りたくない。
    ● Snowflake Snowpipe（以下Snowpipe）
    ○ パフォーマンス面は問題なかったけど、コスパが合わなかった。
    オブジェクト数課金なので、使うなら、ログの数を減らす必要がある。
    それなりに様々なサーバーがあるので、そこから頑張るのは、コスパ悪い。
    

    View Slide

42. dbt cloudを使っていない理由
    課金形態が、開発スタイルとマッチしない。
    弊社では、基本的に決められた開発領域がないため、
    データ基盤も全員が触ることを想定する必要がある。
    dbt cloudだと、開発者数に応じた課金アップモデルなので、
    少ししか触らない人でも、一人分のコストを払う必要がある。
    また、dbt coreで、レポーティング基盤の実装を、
    再実装をした経験もあったため、cloudの採用を見送った。
    

    View Slide

43. オーケストレーションにStepFunctions
    オーケストレーションには、
    StepFunctions(以下SFN)を全面的に採用している。
    理由は、コストパフォーマンスが圧倒的であるため。
    現状は、1時間に1回の実行と、10分に1回の実行をしているSFNがある。
    かかっているコストは、なんと、$0.03/day だけ。
    例えば、これをAirflow(MWAAなど)で同じことをやると、
    維持費だけで倍以上のコストがかかる。
    しかも、Airflowじゃないと出来ないこと…が思いつかずSFNを採用。
    

    View Slide

44. ここ
    

    View Slide

45. S3 -> Snowpipe -> Snowflake
    

    View Slide

46. Snowpipeとは
    ファイルがステージで利用可能になり
    次第、ファイルからデータをロードしま
    す。データは、
    参照パイプで定義されている COPY
    ステートメントに従ってロードされま
    す。(公式の説明)
    docs.snowflake.com, Snowpipeの紹介, 2022/11/07,
    docs.snowflake.com/ja/user-guide/data-load-snowpipe-intro.html
    

    View Slide

47. S3イベントをトリガーに、
    ロードしといて！って設定すると、
    勝手にSnowflakeにロードしてくれる。
    

    View Slide

48. Snowpipeの用途
    バッチロードだと、数値を見れるのが最速でも1時間後になるので、
    それより早く見たいデータをSnowpipeで収集するようにしてる。
    オブジェクト数課金になるので、そこのコスパが合うのであれば、
    基本的に全てのロードは、Snowpipeでやってしまって問題ない。
    今回作ったデータ基盤が扱ってるログでは、コストが高くつくので、
    全面的な採用は見送っている。
    

    View Slide

49. ここ
    

    View Slide

50. Amazon Aurora -> Fivetran -> Snowflake
    

    View Slide

51. Fivetranとは
    様々なデータソースと、
    さくっと連携してくれるSaaS。
    公式サイトにどんなデータソースと連携できるか
    紹介されてます。
    www.fivetran.com, Fivetran, 2022/11/07, www.fivetran.com
    

    View Slide

52. Fivetranの用途
    Amazon Auroraに入ってる管理画面のデータとの連携や、
    今後発生するちょっとしたデータ連携などに使っていく。
    これを自前でやろうとすると、結構大変で、それなりの工数が
    発生する。これをFivetranでやると、本当にすぐ出来る。
    一方で、ビジネスクリティカルなデータ、大量データ部分には、Fivetranは使っ
    ていない。
    例えば、広告ログだと、課金体系的に高くつきすぎるのと、
    なんらか障害発生時に、コントロール出来る余地を残しておきたい。
    

    View Slide

53. Fivetranを採用した理由
    ETLにカスタム設定が出来ないのが魅力的だった。
    個人的に、データソースから、DWHにロードする時は、
    Rawデータ（≒生ログ）のままにしてほしい。
    経験的に、データソースから変換したものしかDWHにないと辛い。
    例えば、問題が起きた時に、ロード部分まで疑う必要が出る。
    また、再集計時にロードからやり直しになることがあるので、
    基本的にはRawはそのまま入ってるという状態にした。
    そして、FivetranはRawはそのままです！が強制されるので、良かった。
    

    View Slide

54. ここ
    

    View Slide

55. Transform by dbt in Snowflake
    

    View Slide

56. dbtを使ったデータ変換(Transform)
    データソースからロードされたRawデータを、
    使いやすいデータに変換するのにdbtを使っている。
    主なモデリング手法は、ディメンションモデリングを採用している。
    

    View Slide

57. ディメンションモデリングとは
    ディメンションモデリングって何？は、
    過去の発表資料にあるので、興味あればどうぞ。
    ディメンションモデリングとは、
    データウェアハウスにデータを
    格納するために、
    最適化されたデータ構造の手法。
    ※本日は、時間の都合上、
    モデリングについては語れません。
    speakerdeck.com, モデリングはキラキラ技術より地味だが役に立つ , 2022/11/07,
    speakerdeck.com/pei0804/modeling-over-shiny-tech
    

    View Slide

58. 今後の展望
    

    View Slide

59. 今後の展望
    ● BigQueryとRedshiftに乗ってる運用を、少しずつSnowflakeへ。
    ● 開発しやすさの向上。
    ○ 一旦作り上げることに注力したので、改善の余地がある。
    ● データの傾向監視を入れたい。
    ○ dbt testだと、時系列での監視が難しいので、
    elementaryというOSSを検討中。
    

    View Slide

60. まとめ
    

    View Slide

61. View Slide

62. これを2ヶ月くらいで作れるので、
    いい時代になった！
    

    View Slide

63. 朗報です。
    実はエンジニア採用してます。
    

    View Slide

64. https://engineering.cartaholdings.co.jp/
    

    View Slide