進化を加速させるデータ基盤CI/CDの実践 / accelerating-data-platform-ci-cd

Slide 1

Slide 1 text

進化を加速させるデータ基盤CI/CDの実践 Data Engineering Study #28 データ基盤のCI/CD 近森淳平（チカモリ　ジュンペイ） @pei0804

Slide 2

Slide 2 text

データ活用は難しい

Slide 3

Slide 3 text

データ活用は基本的に成功確率が低く多くの試行錯誤が要します

Slide 4

Slide 4 text

データ活用の成功確率を上げれないなので、試行回数を上げるしかない

Slide 5

Slide 5 text

試行回数を上げるここにCI/CDが効く

Slide 6

Slide 6 text

同じ失敗でも効率よく失敗する方が良い

Slide 7

Slide 7 text

けど、データ基盤のCI/CDは難しい

Slide 8

Slide 8 text

何が難しくしているのか？

Slide 9

Slide 9 text

「コード」「データ」「コンピュート」三位一体の要素これらが密に作用し合うことで難しくなる

Slide 10

Slide 10 text

実際の現場で、どのように問題を捉え取り組んでいるかの思考を共有したいと思います

Slide 11

Slide 11 text

話すこと ● データ基盤におけるCI/CDを構築する上での勘所 ○ こうやって考えて設計するのか！が分かっている状態を目指します

Slide 12

Slide 12 text

話さないこと ● 細かい実装

Slide 13

Slide 13 text

アジェンダ ● 自己紹介 ● データ基盤のCI/CDが必要な理由 ● データ基盤開発が難しい理由 ● ケーススタディ: CARTA MARKETING FIRM ○ 設計方針 ○ 実践例

Slide 14

Slide 14 text

自己紹介ぺい @pei0804 近森淳平(チカモリ　ジュンペイ) 新卒7年目です VP of Data @ CARTA MARKETING FIRM / CARTA HOLDINGS 2024, 2025 Snowﬂake Data Superheroes

Slide 15

Slide 15 text

Slide 16

Slide 16 text

データ基盤のCI/CDが必要な理由

Slide 17

Slide 17 text

データ活用は失敗するものと捉えるデータ基盤を会社として取り組んでいるということは、恐らくデータを活用して、ビジネス価値を出すことが目的でしょう。データ活用は、実験的な取り組みの連続です。ほとんどの取り組みは失敗して、成功する確率は非常に低いです。なので、私は基本的に失敗前提で取り組んでいます。

Slide 18

Slide 18 text

では、失敗を前提とした時に何をすべきでしょうか？

Slide 19

Slide 19 text

答えはシンプルで、「たくさん試す」

Slide 20

Slide 20 text

「たくさん試す」を実現する手段として CI/CDは有効な手段です

Slide 21

Slide 21 text

ちなみに、データ基盤のCI/CDはソフトウェア開発と少し性質が違いますこれを意識して取り組みたい

Slide 22

Slide 22 text

ソフトウェア開発者でも苦労するデータ基盤のCI/CD構築は、一般的なソフトウェア開発とは異なる課題があります。豊富なソフトウェア開発経験を持つエンジニアでさえ、データ基盤特有の課題に直面し、効果的なCI/CD構築に苦労しているケースを数多く見てきました。

Slide 23

Slide 23 text

ソフトウェア開発とは最終成果物が違う従来のソフトウェア開発ではコード自体が最終成果物ですが、データ基盤ではデータセット自体が最終成果物となります。そのため、良いプラクティスが違うということは当然起きます。これを聞いてるあなたが、ソフトウェア開発経験者なら、最終成果物が違うものを扱っているんだという意識が大事です。もちろん数多くの場面で、ソフトウェア開発の知識は役立ちます。

Slide 24

Slide 24 text

どこがどう難しいのか？紐解いていきます

Slide 25

Slide 25 text

Slide 26

Slide 26 text

データ基盤開発が難しい理由

Slide 27

Slide 27 text

テストデータでは動いたけど本番では動かない遭遇したことある人〜✋

Slide 28

Slide 28 text

このトラブルはデータ基盤の開発の難しさを表す最たる例です

Slide 29

Slide 29 text

この難しさはどこから来るのか？

Slide 30

Slide 30 text

三位一体の要素

Slide 31

Slide 31 text

データ基盤の三位一体の要素が生み出す課題データ基盤には切っても切り離せない ● コード ● データ ● コンピュートという三位一体の要素があります。この3要素が相互作用し合って、「テストデータでは動いたけど、本番では動かない」を引き起こしています。

Slide 32

Slide 32 text

コード ● データ変換ロジック ○ dbt, Python ● パイプライン制御 ○ AWS Step Functions, Airﬂow, Dagster ● 品質検証 ○ dbtテスト, Great Expectations

Slide 33

Slide 33 text

データ ● 入力データ ○ アプリケーションログ ○ マスターデータ（顧客、商品など） ● 出力データ ○ レポートテーブル ○ ダッシュボード ○ データマート

Slide 34

Slide 34 text

コンピュート ● データウェアハウス ■ Snowﬂake, BigQuery, Databricks, Redshift… ● 実行環境 ○ ECS Fargate, EC2, Lambda…

Slide 35

Slide 35 text

これらの3つの要素は密接に関連し合っています

Slide 36

Slide 36 text

コードとデータの関係コードはデータの処理ロジックを定義し、データはコードの実行結果を決定づけます。コードの変更はデータの品質や構造に直接影響を与ます。データの変更も同様です。 ● 具体例 ○ SQLの結合条件を変更すると、集計結果が大きく変わる ○ 型やカラム名の変更により、依存する下流のレポートが動かなくなる

Slide 37

Slide 37 text

データとコンピュートの関係データの規模や処理要件が必要なコンピュートリソースを決定し、逆にコンピュートの制約がデータの保持・処理方針に影響を与えます。 ● 具体例 ○ 大規模なデータ処理には、それに見合ったメモリやCPUリソースが必要 ○ ストレージの容量の制限により、保持期間や粒度を調整する必要がある

Slide 38

Slide 38 text

コンピュートとコードの関係コンピュートリソースの制約がコードの実装方法を規定し、コードの処理要件が必要なコンピュートリソースを決定します。 ● 具体例 ○ メモリ制約により、データの分割処理やストリーミング処理が必要になる ○ 実行時間の制約により、クエリの最適化やインデックス設計が重要になる

Slide 39

Slide 39 text

三位一体の要素の相互作用を意識するコード、データ、コンピュートという3つの要素は、それぞれが独立して存在するのではなく、密接に関連し合っています。例えば、コードの変更がデータの品質に影響を与え、それによってコンピュートリソースの要件が変わるといった具合です。このように、一つの要素への変更が他の要素に波及的な影響を及ぼすという特性を理解することが重要です。

Slide 40

Slide 40 text

手運用で開発するとトラブルが起きまくるここまで紹介した通り、結構複雑なものを扱っています。なので、できるだけCI/CDでデータ基盤開発でトラブルを防ぐ。気をつけないとすぐ壊れるみたいな体験になるのは、 CI/CDがうまく構築できていない兆候です。本来集中したい業務に集中できる環境を整えることが重要です。そこまで行くとようやくデータ品質云々の話になってきます。手前でトラブルが多いと、それどころじゃなくなりがちです。

Slide 41

Slide 41 text

コード、データ、コンピュート何が開発を難しくしているかを理解すると、戦い方も自ずと見える

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

CARTA MARKETING FIRMおけるデータ基盤CI/CDの設計方針

Slide 45

Slide 45 text

闇雲にCI/CD組んでも意味がない

Slide 46

Slide 46 text

データ基盤のCI/CDを構築する際目標、組織、データに合わせて設計方針を定めることが重要です

Slide 47

Slide 47 text

目標 RevOpsの考え方を経営に導入し、部門間の壁を越えて収益最大化を目指しています。短期的な課題解決と長期的なビジョンを両立させながら、データを経営資本として活用することを目標にデータ活用を推進中。 https://speakerdeck.com/pei0804/path-to-revops

Slide 48

Slide 48 text

開発体制中央集権から分散管理体制へ移行。データオーナーにデータに関する意思決定権の委譲。データ基盤チームは、基盤の改善や未整備の領域の仕組み開発に注力。 https://speakerdeck.com/pei0804/centralized-to-dataops-transformation

Slide 49

Slide 49 text

データ特性一言で表すなら、大量で複雑。複数の広告プロダクトのデータを扱っています。 1つのログだけで、 1日に数億レコードを超える膨大な量の半構造化データもあります。 https://speakerdeck.com/pei0804/data-cloud-world-tour-tokyo-2023

Slide 50

Slide 50 text

これらの背景を踏まえ、データオーナーのアイデアを最速で実現するを設計方針に据え、CI/CDを構築しています

Slide 51

Slide 51 text

データオーナーのアイデアを最速で実現する RevOpsの推進には、データオーナーの協力が不可欠です。そのためには、データオーナーが簡単に試せる仕組みを必要です。仮に技術的なハードルが高いと、アイデアが実行されにくくなります。ここでCI/CDの活用が効果を発揮します。例えば、CIで問題点を事前に検知できると、データオーナーは安心してリリースまで持っていきやすくなります。

Slide 52

Slide 52 text

ガードレールとしてのCI CIはデータ基盤に関わる人達にとって、ガードレールの様な存在です。最低限のラインをCIで担保し、「CIが通ってればリリースして良い」としています。このアプローチにより、開発者の創造性を活かしながら、データ基盤全体の品質と安全性を確保しています。ソフトウェア開発なら、こんなの当たり前ですが、これがデータ基盤だと難しい・・・。

Slide 53

Slide 53 text

簡単で確実なデプロイを実現するCD データオーナーが開発したコードを、簡単にリリースすできることを最優先としています。具体的には、mainにマージされたら、次の実行ではそれが反映されます。これにより、開発者はリリースプロセスではなく、本来の開発業務に集中することができます。リリース作業が大変だと、本当にやる気削がれますし、開発体験にも直結するため、簡単な方がいいです。

Slide 54

Slide 54 text

そんな委譲しまくって事故らないの？

Slide 55

Slide 55 text

最初は事故ってました（過去形）

Slide 56

Slide 56 text

事故ったから、中央集権体制に戻すこんなことやってたら何も変わらない

Slide 57

Slide 57 text

事故は成長痛

Slide 58

Slide 58 text

完璧な状態で権限委譲は難しいやってみたら分かることは多い

Slide 59

Slide 59 text

素振り1年間やるより 1回試合出た方が分かる

Slide 60

Slide 60 text

なぜ事故ったか？を分析するそこに必要な仕組みを作ればいいまず、足元からデータドリブンで解決する

Slide 61

Slide 61 text

継続的改善が大事最初からうまく行く施策は珍しいです。 CARTA MARKETING FIRMでも、様々な苦労がありました。気になる方はこちらの資料を御覧ください。 https://speakerdeck.com/pei0804/journey-to-dataops

Slide 62

Slide 62 text

Slide 63

Slide 63 text

CARTA MARKETING FIRMおけるデータ基盤CI/CDの実践

Slide 64

Slide 64 text

構築する上で頭を悩ませたCIについて紹介します

Slide 65

Slide 65 text

dbt Slim CI

Slide 66

Slide 66 text

dbt buildをCIで動かしたいニーズ CARTA MARKETING FIRMでは、データ変換にdbtを使っています。データオーナーは、dbtを使って必要なモデル構築を行います。コード管理はGitHubで行っています。こういう状況下で出てくるニーズとして、PullRequestのコード内容で、 dbtを動かしてみて、エラーが起きないか？テストが落ちないか？を、リリースする前に気づきたい。

Slide 67

Slide 67 text

GitHub Actionで、 dbt buildしたら終わり！ではない

Slide 68

Slide 68 text

大量データ x dbt build = コストが高い特に何も考えずに、本番の大量なデータに対して、コミット毎にdbt buildを実行すると当然ですが、時間・金銭的コストが高くつきます。一方で、ある程度は本番のカオスな状態で動かさないと、この実装で良いと言えるのか？に疑問が出てくる。

Slide 69

Slide 69 text

CIでチェックすることを絞る本番相当のデータで試すのは難しい。けど、作ったモデルが想定通りの実装になっているかを確認したい。 ● 実行可能なSQLになっているか ● テストが通ることを確認したいこれに焦点を絞ってCIを構築することにしました。

Slide 70

Slide 70 text

本番で試したい場合もちろん本番相当のデータで試したいニーズもあります。その場合は、開発環境に本番データベースを、簡単にクローンできる方法を用意しています。これを活用することで、実際のカオスなデータで想定通りデータラングリングできているか？など、本番と同じ環境下で試すことができるようになっています。

Slide 71

Slide 71 text

実装したもの $ dbt build --target ci --select state:modified+ 変更のあったモデルだけを実行する state:modified+ これに加えて、次に示すようなマクロを基底のモデルで使う

Slide 72

Slide 72 text

limit_ci @ dbt-snowﬂake select * from {{source(...)}} {{limit_ci()}} {%- macro limit_ci(rows_limit=10) -%} {%- if target.name == "ci" %} limit {{ rows_limit }} {%- endif -%} {%- endmacro -%} 発行されるSQLイメージ select * from hoge limit 10

Slide 73

Slide 73 text

limitするだけだと足りない limit 10 すると、適当に10件取ってくる挙動になる。これでリネージュ全体がエラー起きずに動くかのチェックはできる。一方で時系列データに対しては、これだと片手落ち。例えば、今日のデータと去年のデータでは、全く文脈が違う。いま実装しているコードは、今日のデータを前提に書いている。なので、今日のデータを使って動かしたい。

Slide 74

Slide 74 text

ﬁlter_partition_and_limit_ci @ dbt-snowﬂake select * from {{source(...)}} where {{filter_partition_and_limit_ci()}} {%- macro filter_partition_and_limit_ci(rows_limit=10) -%} {%- if target.name == "ci" %} {{ filter_partition() }} {{ limit_ci(rows_limit) }} {%- else -%} 1 = 1 {%- endif -%} {%- endmacro -%} 発行されるSQLイメージ select * from hoge where 2025-02-26T04:00' <= _partition_hourly and _partition_hourly <= '2025-02-26T04:00' limit 10

Slide 75

Slide 75 text

ﬁlter_partition @ dbt-snowﬂake {%- macro filter_partition() -%} {%- set transform_start_datehour = var("transform_start_datehour", default=none) -%} {%- set transform_end_datehour = var("transform_end_datehour", default=none) -%} {%- set start_partition = dbt.safe_cast( "'" ~ transform_start_datehour ~ "'", api.Column.translate_type("timestamp"), ) -%} {%- set end_partition = dbt.safe_cast( "'" ~ transform_end_datehour ~ "'", api.Column.translate_type("timestamp"), ) -%} {{ start_partition }} <= _partition_hourly and _partition_hourly <= {{ end_partition }} {%- endmacro -%}

Slide 76

Slide 76 text

これで最新のデータ取ってきて少量データでdbt buildできる！

Slide 77

Slide 77 text

これでも、気付けない問題はあるけど、防げるトラブルもある

Slide 78

Slide 78 text

事故っても気付ける仕組みを作るそして、簡単に戻せるようにするこれが実は一番大事

Slide 79

Slide 79 text

朗報です先ほどのロジックは、dbt標準になりそう

Slide 80

Slide 80 text

https://github.com/dbt-labs/dbt-core/discussions/11200

Slide 81

Slide 81 text

これから実装する方へ ﬁlter_partitionは自前実装しなくていいです https://zenn.dev/pei0804/articles/dbt-new-microbatch-strategy-implementation

Slide 82

Slide 82 text

どんどん標準化されつつあるので積極的にサボっていきましょう

Slide 83

Slide 83 text

他の実装も気になる？

Slide 84

Slide 84 text

公開しているCI/CDに関する記事紹介 techblog.cartaholdings.co.jp/entry/snowflake-dbt-data-platform-vision techblog.cartaholdings.co.jp/entry/pr-agent-dbt-code-review-automation

Slide 85

Slide 85 text

まとめ

Slide 86

Slide 86 text

データ基盤開発は難しい課題を含んでいますコード、データ、コンピュートの三位一体の要素が密接に関連し合うことで複雑性が増しています

Slide 87

Slide 87 text

データ活用はさらに難しい領域ですがそこに至るまでの技術的ハードルは CI/CDで大幅に軽減できます

Slide 88

Slide 88 text

実装が行き詰まったら思い出してみようコード、データ、コンピュート何が難しい理由なのかどこまではCI/CDで担保できるか

Slide 89

Slide 89 text

そして、その先にあるデータ活用これにコミットする時間を増やす

Slide 90

Slide 90 text

データでビジネスを革新するそんなでかいヤマを共に解きませんか？

Slide 91

Slide 91 text

【PR】We're hiring 【アナリティクスエンジニア】データ活用の可能性を引き出し、新たな価値創造に挑戦 https://hrmos.co/pages/cartaholdings/jobs/cmf-e04 【データエンジニア】データの源泉から価値創造までエンジニアリングする https://hrmos.co/pages/cartaholdings/jobs/cmf-e05