BigQueryからSnowflakeへ移管して作る最強のデータ基盤 〜Data Ingestion編〜 / The Ultimate Data Platform Migration from BigQuery to Snowflake: Data Ingestion Edition

『みんなの考えた最強のデータ基盤アーキテクチャ2024前半おまとめ拡大版SP！』の発表資料です。
https://datatech-jp.connpass.com/event/319827/

Transcript

1. © LayerX Inc. BigQueryからSnowflakeへ移管して作る 最強のデータ基盤 〜Data Ingestion編〜 2024/08/21 @civitaspo みんなの考えた最強のデータ基盤アーキテクチャ2024前半おまとめ拡大版SP！
2. © LayerX Inc. 2 バクラク事業部 機械学習・データ部 DataOps チーム 兼 Platform Engineering部 DevOps チーム DataOps/DevSecOps/MLOps が大好きなエンジニア 福岡在住のフルリモートワー カーです。福岡にデータ友達 がいないのでデータ友達が 欲しいです！ OSSが大好きで、よく読ん だり書いたりしてます。 SNS 𝕏 civitaspo 　 civitaspo その他 画像を入れてね 自己紹介 civitaspo （ｷﾋﾞﾀｽﾎﾟ、きびちゃん）
3. 3 © LayerX Inc. 「すべての経済活動を、デジタル化する。」をミッションに掲げ、 法人支出管理サービス「バクラク」や企業内業務のデジタル化を支援するサービスを提供しています。 事業紹介 バクラク事業 企業活動のインフラとなる法人支出 管理（BSM）SaaSを開発・提供 Fintech事業 ソフトウェアを駆使したアセットマネジメ ント・証券事業を合弁会社にて展開 AI・LLM事業 文書処理を中心とした、LLMの活用による プロセスのリデザイン
4. 今日話す内容
5. © LayerX Inc. 5 • 我々にとってBigQueryからSnowflakeへ移管する選択が、なぜ最強への道だったか • Snowflakeへの移管によって、Data Ingestionまわりのアーキテクチャがどう変化したか • Snowflakeへの移管によって、我々のデータ基盤がどういう能力を持つようになったか BigQueryからSnowflakeへ移管して作る最強のデータ基盤 今日話す内容
7. 練習したら 30分コースだった
8. © LayerX Inc. 8 • 我々にとってBigQueryからSnowflakeへ移管する選択が、なぜ最強への道だったか • Snowflakeへの移管によって、Data Ingestionまわりのアーキテクチャがどう変化したか • Snowflakeへの移管によって、我々のデータ基盤がどういう能力を持つようになったか BigQueryからSnowflakeへ移管して作る最強のデータ基盤 今日話す内容 割愛した部分はAppendixとして資料に載せておきます！ パネルディスカッションやアフタートークでタイミングがあれば話すかも！
9. では、はじめていきます
10. アーキテクチャ全体像
11. © LayerX Inc. 11 コアとなるデータ • プロダクトデータベース • アプリケーションログ • 営業活動データ • 企業・顧客データ ユースケース • プロダクト利用分析 • 事業指標モニタリング • ビジネスオペレーション • 開発デバッグ・調査 現行データ基盤 アーキテクチャ全体像 ref. 株式会社LayerXのBigQuery導入事例
12. © LayerX Inc. 12 Snowflake一色に！ 新データ基盤 アーキテクチャ全体像
13. © LayerX Inc. 13 アーキテクチャ全体像 現行データ基盤 / 新データ基盤
14. © LayerX Inc. 14 アーキテクチャ全体像 今日のフォーカス
15. Data Ingestionに関する アーキテクチャの変化
16. 目次 Agenda • Salesforce • Aurora MySQL • S3 • EventBridge • 様々なSaaS • Google Sheets / Google Analytics
17. Salesforce
18. © LayerX Inc. 18 • Snowflake MarketplaceからOmnataをインストールして使用 • 外部プロセスを使用することなく、Snowflakeから直接SOQLの結果を取得できる • $3/day と格安 Salesforce Data Ingestionに関するアーキテクチャの変化 Embulkを動かすための仕組みが必要だった Snowflakeから直接SOQLを実行できるため dbtだけでデータ取得から変換・格納までできるようになる Omnata https://omnata.com/
19. © LayerX Inc. 19 • データ取得部分がdbtのみで完結し、データの取得・変更の依頼に特殊な技能を必要としなくなった。 • また、ｄｂｔ内でSOQLを組み立てられるようになったことで、動的なSOQL生成が可能に。 dbtを使ったSOQLの動的生成 Data Ingestionに関するアーキテクチャの変化
20. Aurora MySQL
21. © LayerX Inc. 21 • 2024/07にPublic PreviewになったSnowflake Connector for MySQLを使用 • MySQLへの変更をニアリアルタイムにSnowflakeへ反映できる Aurora MySQL Data Ingestionに関するアーキテクチャの変化
22. © LayerX Inc. 22 Snowflake Connector for MySQL の仕組み Data Ingestionに関するアーキテクチャの変化 ref. Snowflake Brings Seamless PostgreSQL and MySQL Integration with New Connectors
23. © LayerX Inc. 23 Previewホヤホヤということもあり、運用課題が多数 • コンテナネイティブな運用が想定されていない • ログがあんまり出ない • Warehouseの稼働時間が長くなりがちで、コストが結構嵩む などなど...（詳しくは後日ブログを出します） Preview中にフィードバックを送らないと望む形でGAしないので、フィードバックは送りつつ、 代替案を使用することに。 だがしかし... Data Ingestionに関するアーキテクチャの変化
24. © LayerX Inc. 24 代替案: Kafka + debezium / Aurora S3 Export※ Data Ingestionに関するアーキテクチャの変化 fast layer = debezium + MSK Connect + MSK + Data Firehose + Snowpipe Streaming batch layer = Aurora S3 Export ※ + Snowflake External Table ※ 正式名称は「Exporting DB cluster snapshot data to Amazon S3」
25. S3
26. © LayerX Inc. 26 • これまでの仕組みはクラウドをまたいだ複数サービスの連携によって実現する複雑性の高い手法 • Snowpipeの利用によって、この複雑性がなくなり運用容易性が格段に上がった S3 Data Ingestionに関するアーキテクチャの変化 S3のPut Eventを受け取って、BigQueryへデータ格納 1分以内にはBigQueryに格納されている 新規データはSnowpipeで格納 過去データはIceberg Tableとして定義 ※ 左のアーキテクチャの詳細は『生データを最速で取り込むチャレンジ ~LayerXデータ基盤成長物語 part1~』を参照
27. EventBridge
28. © LayerX Inc. 28 • 2024/04にGAしたData Firehose + Snowpipe Streamingで構成 • Apache Beam / Flink構成は、処理を柔軟に書ける一方、学習・実装コストが高く、馴染まなかった EventBridge Data Ingestionに関するアーキテクチャの変化 ref. Snowpipe StreamingとAmazon Data Firehoseを使用してSnowflakeにストリームデータをロードする #ベッテク月間 - LayerX エンジニアブログ
29. 様々なSaaS
30. © LayerX Inc. 30 • コストがかからなかったり、信頼性よりもスピードが重視されるケースは引き続きFivetran • 一方、そうではない場合はOmnataかdbt Python modelを使ったExternal Accessを利用 様々なSaaS Data Ingestionに関するアーキテクチャの変化
31. © LayerX Inc. 31 • SnowflakeにはSnowpark※1 というPythonやJava などのプログラミング言語を用いて処理を記述可能なラ ンタイムがある • dbtのPython model※２ は、このSnowpark上で動く • SQLのように宣言的な言語では書きにくい、外部APIか らのデータ取得などを書くのに便利！ dbt Python model + Snowpark Data Ingestionに関するアーキテクチャの変化 ※1: https://www.snowflake.com/ja/data-cloud/snowpark/ ※2: Data Engineering with Snowpark Python and dbt
32. Google Sheets / Google Analytics
33. © LayerX Inc. 33 • BigQueryでは直接取得できていたサービスのデータは、別のソリューションを入れる必要があった。 • 明確に不便になったと言えるが、Snowflake Marketplaceで解決ができた Google Sheets / Google Analytics Data Ingestionに関するアーキテクチャの変化 Snowflake Connector for Google Analytics Raw Data
34. © LayerX Inc. 34 Snowflake Connector for Google Analytics Raw Data Data Ingestionに関するアーキテクチャの変化 BigQueryのほうが 明確に優れるケースでは BigQuery Storage API を叩くことも検討すべき ref. About the Snowflake Connector for Google Analytics Raw Data
35. おわり
36. © LayerX Inc. 36 『Snowflakeで構築する最強データ基盤 〜Data Ingestion編〜』 でした。 もし今日の話を聞いて「面白そうなやつだ」と思ったら x.com/civitaspo のフォローをお願いします！ もし今日の話を聞いて「もっと話したい！」と思ったら「civitaspo layerx カジュアル面談」で検索！検索！ ご視聴ありがとうございました！ おわりだよ〜 おわり
37. Appendix
38. © LayerX Inc. 38 • 「我々にとってBigQueryからSnowflakeへ移管する選択が、なぜ最強への道だったか」の章では、 BigQueryからSnowflakeへ移管する意思決定をした背景について載せています。が、「BigQuery vs Snowflakeであれば迷わずSnowflakeを選択すべき」と主張するものではありません。 BigQueryを選択するべき場面もあります。あくまで、我々にとってSnowflakeを選択すべきだった という話であることを理解の上、読んでください。 おことわり Appendix
39. 我々にとってBigQueryからSnowflakeへ 移管する選択が、なぜ最強への道だったか
40. © LayerX Inc. 40 • 雑に入れて、雑にクエリを投げても、それなりの速度で返ってくる • Copy Jobを使えば無料でデータを格納できる • Google Workspaceのアカウントがあれば、すぐに使える 昨今のデータ基盤に求められてる機能って、それで十分なんだっけ？？？ 単純なクエリエンジンとしての機能はBigQueryのほうが強いが...※ 我々にとってBigQueryからSnowflakeへ移管する選択が、なぜ最強への道だったか ※ 異論がある人はいると思う。
41. © LayerX Inc. 41 • ビジネスオペレーションへの組み込み • システム間データ連携 • 機械学習 • ... 事業・ビジネスからの要求は高度化・多様化している その要求を満たすためのデータ基盤としてBigQueryを見るとどうか ビジネス要件を満たすにはそれだけじゃ足りない 我々にとってBigQueryからSnowflakeへ移管する選択が、なぜ最強への道だったか
42. © LayerX Inc. 42 我々にとってBigQueryからSnowflakeへ移管する選択が、なぜ最強への道だったか BigQueryでも、できる！できるけど... Cloud Data Transfer Security Command Center Storage Transfer Service Vertex AI Cloud Functions Cloud Run Pub/Sub Dataproc Google Kubernetes Engine Virtual Private Cloud Cloud NAT Workflows Cloud Scheduler Identity-Aware Proxy BigQueryだけではなく、Google Cloudの他サービスの理解がそれなりに必要...!!!
43. © LayerX Inc. 43 つまり、組織の人員をAWSでサービス運用する前提で採用・教育している。 当然だが、各人員のGoogle Cloudに対する習熟度は高くない。そのため、データを使った施策は... • データエンジニアに依頼するパターン ⇒ データエンジニアの人数に依存するのでスケールしない • AWSからBigQuery叩いちゃうパターン ⇒ 情報資産がいろんなところに散らばって統制を効かせられなくなる ⇒ クラウドを跨ぐことによる運用コスト • Google Cloud上で頑張って作ってもらうパターン ⇒ 時間がかかる / 事故率高め ⇒ データ基盤のためだけにGoogle Cloud上にガードレール/基盤を組むのはROIが合わない BigQueryを継続すると、人的資源に依存して、事業増加・成長を支えるかんじになりそう。 弊社のサービスはAWSで動いている 我々にとってBigQueryからSnowflakeへ移管する選択が、なぜ最強への道だったか
44. © LayerX Inc. 44 多種多様な要求を、学習コスト低く安全にシュッと満たせる いいかんじのソリューションはないものか... 我々にとってBigQueryからSnowflakeへ移管する選択が、なぜ最強への道だったか
45. © LayerX Inc. 45 我々にとってBigQueryからSnowflakeへ移管する選択が、なぜ最強への道だったか
46. © LayerX Inc. 46 • データに特化して、高度に抽象化が行われた、統一されたインターフェース（SQL） • 機能拡張を可能にする、発達したエコシステム • コミュニティの熱量 × コミュニティの声を聞き入れる文化 なぜBigQueryからSnowflakeへ移管するのか 我々にとってBigQueryからSnowflakeへ移管する選択が、なぜ最強への道だったか 自分が思い描く、 事業の増加・成長に対して、弾力のある応答ができる最強のデータ基盤・組織が作れそう！
47. © LayerX Inc. 47 • 元々、移管されることを想定して、可搬性の高いデータの持ち方でデータ基盤を作っていたので、移管 コストが比較的低かった • 超大規模なデータを扱うわけではないので、データウェアハウスとしてのコスト比較では差が出にく かった • AWS / Google Cloud間のデータ転送コストが金銭面でも運用面でも高いことが分かっていた • ...などなど 他にも理由はある 我々にとってBigQueryからSnowflakeへ移管する選択が、なぜ最強への道だったか
48. Snowflakeへの移管によって 我々のデータ基盤が どのような能力を持つようになったか
49. © LayerX Inc. 49 • Snowflakeの導入により、SQLインターフェースだ けでできることが増えた。 • SQLインターフェースであれば、非エンジニアでも比 較的コミットしやすく、できることが増えた。 • データエンジニアは、利用者をサポートするツール（自 動生成、dbt macros、etc.）を少し開発するだけ で、要求を満たせるようになった。 データ基盤の利用者が、利用者だけでできることが増えた Snowflakeへの移管によって我々のデータ基盤がどのような能力を持つようになったか Alert実行の例。青枠部分が自動生成。赤枠部分をユーザーが埋める。
50. © LayerX Inc. 50 • Snowflakeの導入により、S3にデータを置いておけば、Snowflakeから操作できる状態になった • これにより、プロダクト開発チームが、データ基盤へデータを格納するハードルが大きく下がった • そのため、「依頼してデータを格納してもらう動き」から「プロダクト開発チームが能動的にデータを格 納する動き」ができるようになった プロダクト開発者がデータ基盤にデータを入れやすくなった Snowflakeへの移管によって我々のデータ基盤がどのような能力を持つようになったか
51. © LayerX Inc. 51 • Snowflakeを導入したことにより、Snowflake MarketplaceやSaaS、OSSなど、Snowflakeエ コシステムの力を借りることが可能になった • 統計情報等がないため主観になるが、Snowflakeのエコシステムは非常に発達している※ • そのため、要求を満たすための選択肢が増えた。自分たちで実装しなくともエコシステムによって解決 できるケースが増えた。 要求を満たすための選択肢が増えた Snowflakeへの移管によって我々のデータ基盤がどのような能力を持つようになったか ※ たとえば、Salesforce Data CloudとのZero ETL機能はSnowflakeとBigQueryで対応時期が半年以上開いている ref. Salesforce and Snowflake Make Data Sharing-Based Integration Generally Available, Helping Customers with Data-Driven Engagement ref. Combine data across BigQuery and Salesforce Data Cloud securely with zero ETL
52. 真のおわり x.com/civitaspo