Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

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

## イベント説明

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

## 発表概要

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

Jumpei Chikamori

November 02, 2022
Tweet

More Decks by Jumpei Chikamori

Other Decks in Technology

Transcript

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  5. 多種多様なデータ
    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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  24. 一つのDWHに出来ないか?

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  32. S3 -> dbt -> Snowflake

    View full-size slide

  33. dbtで
    ETL????????????
    WHY!!!!!!!!!!!!!!!

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  41. S3 -> Snowpipe -> Snowflake

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  45. Amazon Aurora -> Fivetran -> Snowflake

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  49. Transform by dbt in Snowflake

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  52. 今後の展望

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide