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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© LayerX Inc. 2 バクラク事業部機械学習・データ部 DataOps チーム兼 Platform Engineering部 DevOps チーム DataOps/DevSecOps/MLOps が大好きなエンジニア福岡在住のフルリモートワーカーです。福岡にデータ友達がいないのでデータ友達が欲しいです！ OSSが大好きで、よく読んだり書いたりしてます。 SNS 𝕏 civitaspo 　 civitaspo その他画像を入れてね自己紹介 civitaspo （ｷﾋﾞﾀｽﾎﾟ、きびちゃん）

Slide 3

Slide 3 text

3 © LayerX Inc. 「すべての経済活動を、デジタル化する。」をミッションに掲げ、法人支出管理サービス「バクラク」や企業内業務のデジタル化を支援するサービスを提供しています。事業紹介バクラク事業企業活動のインフラとなる法人支出管理（BSM）SaaSを開発・提供 Fintech事業ソフトウェアを駆使したアセットマネジメント・証券事業を合弁会社にて展開 AI・LLM事業文書処理を中心とした、LLMの活用によるプロセスのリデザイン

Slide 4

Slide 4 text

今日話す内容

Slide 5

Slide 5 text

© LayerX Inc. 5 ● 我々にとってBigQueryからSnowflakeへ移管する選択が、なぜ最強への道だったか ● Snowflakeへの移管によって、Data Ingestionまわりのアーキテクチャがどう変化したか ● Snowflakeへの移管によって、我々のデータ基盤がどういう能力を持つようになったか BigQueryからSnowflakeへ移管して作る最強のデータ基盤今日話す内容

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

練習したら 30分コースだった

Slide 8

Slide 8 text

© LayerX Inc. 8 ● 我々にとってBigQueryからSnowflakeへ移管する選択が、なぜ最強への道だったか ● Snowflakeへの移管によって、Data Ingestionまわりのアーキテクチャがどう変化したか ● Snowflakeへの移管によって、我々のデータ基盤がどういう能力を持つようになったか BigQueryからSnowflakeへ移管して作る最強のデータ基盤今日話す内容割愛した部分はAppendixとして資料に載せておきます！パネルディスカッションやアフタートークでタイミングがあれば話すかも！

Slide 9

Slide 9 text

では、はじめていきます

Slide 10

Slide 10 text

アーキテクチャ全体像

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Data Ingestionに関するアーキテクチャの変化

Slide 16

Slide 16 text

目次 Agenda ● Salesforce ● Aurora MySQL ● S3 ● EventBridge ● 様々なSaaS ● Google Sheets / Google Analytics

Slide 17

Slide 17 text

Salesforce

Slide 18

Slide 18 text

© LayerX Inc. 18 ● Snowflake MarketplaceからOmnataをインストールして使用 ● 外部プロセスを使用することなく、Snowflakeから直接SOQLの結果を取得できる ● $3/day と格安 Salesforce Data Ingestionに関するアーキテクチャの変化 Embulkを動かすための仕組みが必要だった Snowflakeから直接SOQLを実行できるため dbtだけでデータ取得から変換・格納までできるようになる Omnata https://omnata.com/

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Aurora MySQL

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

© LayerX Inc. 23 Previewホヤホヤということもあり、運用課題が多数 ● コンテナネイティブな運用が想定されていない ● ログがあんまり出ない ● Warehouseの稼働時間が長くなりがちで、コストが結構嵩むなどなど...（詳しくは後日ブログを出します） Preview中にフィードバックを送らないと望む形でGAしないので、フィードバックは送りつつ、代替案を使用することに。だがしかし... Data Ingestionに関するアーキテクチャの変化

Slide 24

Slide 24 text

© 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」

Slide 25

Slide 25 text

Slide 26

Slide 26 text

© LayerX Inc. 26 ● これまでの仕組みはクラウドをまたいだ複数サービスの連携によって実現する複雑性の高い手法 ● Snowpipeの利用によって、この複雑性がなくなり運用容易性が格段に上がった S3 Data Ingestionに関するアーキテクチャの変化 S3のPut Eventを受け取って、BigQueryへデータ格納 1分以内にはBigQueryに格納されている新規データはSnowpipeで格納過去データはIceberg Tableとして定義 ※ 左のアーキテクチャの詳細は『生データを最速で取り込むチャレンジ ~LayerXデータ基盤成長物語 part1~』を参照

Slide 27

Slide 27 text

EventBridge

Slide 28

Slide 28 text

© LayerX Inc. 28 ● 2024/04にGAしたData Firehose + Snowpipe Streamingで構成 ● Apache Beam / Flink構成は、処理を柔軟に書ける一方、学習・実装コストが高く、馴染まなかった EventBridge Data Ingestionに関するアーキテクチャの変化 ref. Snowpipe StreamingとAmazon Data Firehoseを使用してSnowflakeにストリームデータをロードする #ベッテク月間 - LayerX エンジニアブログ

Slide 29

Slide 29 text

様々なSaaS

Slide 30

Slide 30 text

Slide 31

Slide 31 text

© 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

Slide 32

Slide 32 text

Google Sheets / Google Analytics

Slide 33

Slide 33 text

© LayerX Inc. 33 ● BigQueryでは直接取得できていたサービスのデータは、別のソリューションを入れる必要があった。 ● 明確に不便になったと言えるが、Snowflake Marketplaceで解決ができた Google Sheets / Google Analytics Data Ingestionに関するアーキテクチャの変化 Snowflake Connector for Google Analytics Raw Data

Slide 34

Slide 34 text

© 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

Slide 35

Slide 35 text

おわり

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Appendix

Slide 38

Slide 38 text

© LayerX Inc. 38 ● 「我々にとってBigQueryからSnowflakeへ移管する選択が、なぜ最強への道だったか」の章では、 BigQueryからSnowflakeへ移管する意思決定をした背景について載せています。が、「BigQuery vs Snowflakeであれば迷わずSnowflakeを選択すべき」と主張するものではありません。 BigQueryを選択するべき場面もあります。あくまで、我々にとってSnowflakeを選択すべきだったという話であることを理解の上、読んでください。おことわり Appendix

Slide 39

Slide 39 text

我々にとってBigQueryからSnowflakeへ移管する選択が、なぜ最強への道だったか

Slide 40

Slide 40 text

© LayerX Inc. 40 ● 雑に入れて、雑にクエリを投げても、それなりの速度で返ってくる ● Copy Jobを使えば無料でデータを格納できる ● Google Workspaceのアカウントがあれば、すぐに使える昨今のデータ基盤に求められてる機能って、それで十分なんだっけ？？？単純なクエリエンジンとしての機能はBigQueryのほうが強いが...※ 我々にとってBigQueryからSnowflakeへ移管する選択が、なぜ最強への道だったか ※ 異論がある人はいると思う。

Slide 41

Slide 41 text

Slide 42

Slide 42 text

© 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 Workﬂows Cloud Scheduler Identity-Aware Proxy BigQueryだけではなく、Google Cloudの他サービスの理解がそれなりに必要...!!!

Slide 43

Slide 43 text

© LayerX Inc. 43 つまり、組織の人員をAWSでサービス運用する前提で採用・教育している。当然だが、各人員のGoogle Cloudに対する習熟度は高くない。そのため、データを使った施策は... ● データエンジニアに依頼するパターン ⇒ データエンジニアの人数に依存するのでスケールしない ● AWSからBigQuery叩いちゃうパターン ⇒ 情報資産がいろんなところに散らばって統制を効かせられなくなる ⇒ クラウドを跨ぐことによる運用コスト ● Google Cloud上で頑張って作ってもらうパターン ⇒ 時間がかかる / 事故率高め ⇒ データ基盤のためだけにGoogle Cloud上にガードレール/基盤を組むのはROIが合わない BigQueryを継続すると、人的資源に依存して、事業増加・成長を支えるかんじになりそう。弊社のサービスはAWSで動いている我々にとってBigQueryからSnowflakeへ移管する選択が、なぜ最強への道だったか

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

© LayerX Inc. 46 ● データに特化して、高度に抽象化が行われた、統一されたインターフェース（SQL） ● 機能拡張を可能にする、発達したエコシステム ● コミュニティの熱量 × コミュニティの声を聞き入れる文化なぜBigQueryからSnowflakeへ移管するのか我々にとってBigQueryからSnowflakeへ移管する選択が、なぜ最強への道だったか自分が思い描く、事業の増加・成長に対して、弾力のある応答ができる最強のデータ基盤・組織が作れそう！

Slide 47

Slide 47 text

© LayerX Inc. 47 ● 元々、移管されることを想定して、可搬性の高いデータの持ち方でデータ基盤を作っていたので、移管コストが比較的低かった ● 超大規模なデータを扱うわけではないので、データウェアハウスとしてのコスト比較では差が出にくかった ● AWS / Google Cloud間のデータ転送コストが金銭面でも運用面でも高いことが分かっていた ● ...などなど他にも理由はある我々にとってBigQueryからSnowflakeへ移管する選択が、なぜ最強への道だったか

Slide 48

Slide 48 text

Snowflakeへの移管によって我々のデータ基盤がどのような能力を持つようになったか

Slide 49

Slide 49 text

© LayerX Inc. 49 ● Snowflakeの導入により、SQLインターフェースだけでできることが増えた。 ● SQLインターフェースであれば、非エンジニアでも比較的コミットしやすく、できることが増えた。 ● データエンジニアは、利用者をサポートするツール（自動生成、dbt macros、etc.）を少し開発するだけで、要求を満たせるようになった。データ基盤の利用者が、利用者だけでできることが増えた Snowflakeへの移管によって我々のデータ基盤がどのような能力を持つようになったか Alert実行の例。青枠部分が自動生成。赤枠部分をユーザーが埋める。

Slide 50

Slide 50 text

© LayerX Inc. 50 ● Snowflakeの導入により、S3にデータを置いておけば、Snowflakeから操作できる状態になった ● これにより、プロダクト開発チームが、データ基盤へデータを格納するハードルが大きく下がった ● そのため、「依頼してデータを格納してもらう動き」から「プロダクト開発チームが能動的にデータを格納する動き」ができるようになったプロダクト開発者がデータ基盤にデータを入れやすくなった Snowflakeへの移管によって我々のデータ基盤がどのような能力を持つようになったか

Slide 51

Slide 51 text

© 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

Slide 52

Slide 52 text

真のおわり x.com/civitaspo