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

Data Engineering Study #28 データ基盤のCI/CD
https://forkwell.connpass.com/event/339761/

https://www.youtube.com/live/Bkhazm0CmFk?si=kss-ygcfwaLYFV_C&t=4158

データ基盤のCI/CDは、データの品質担保やスキーマ変更など、従来のソフトウェア開発とは異なる課題に直面します。本講演では、これらの技術的な課題と多様なステークホルダーの要求に応えながら、いかに安定的で俊敏な変更管理を実現するかについて、実践的な戦略と実装例を共有。データ基盤の進化を加速させるための具体的なアプローチについて解説します。

Transcript

1. 進化を加速させる データ基盤CI/CDの実践 Data Engineering Study #28 データ基盤のCI/CD 近森 淳平（チカモリ　ジュンペイ） @pei0804
2. データ活用は難しい
3. データ活用は基本的に成功確率が低く 多くの試行錯誤が要します
4. データ活用の成功確率を上げれない なので、試行回数を上げるしかない
5. 試行回数を上げる ここにCI/CDが効く
6. 同じ失敗でも 効率よく失敗する方が良い
7. けど、データ基盤のCI/CDは難しい
8. 何が難しくしているのか？
9. 「コード」「データ」「コンピュート」 三位一体の要素 これらが密に作用し合うことで難しくなる
10. 実際の現場で、どのように問題を捉え 取り組んでいるかの思考を共有したいと思います
11. 話すこと • データ基盤におけるCI/CDを構築する上での勘所 ◦ こうやって考えて設計するのか！が分かっている状態を目指します
12. 話さないこと • 細かい実装
13. アジェンダ • 自己紹介 • データ基盤のCI/CDが必要な理由 • データ基盤開発が難しい理由 • ケーススタディ: CARTA MARKETING FIRM ◦ 設計方針 ◦ 実践例
14. 自己紹介 ぺい @pei0804 近森淳平(チカモリ　ジュンペイ) 新卒7年目です VP of Data @ CARTA MARKETING FIRM / CARTA HOLDINGS 2024, 2025 Snowflake Data Superheroes
15. アジェンダ • 自己紹介 • データ基盤のCI/CDが必要な理由 • データ基盤開発が難しい理由 • ケーススタディ: CARTA MARKETING FIRM ◦ 設計方針 ◦ 実践例
16. データ基盤のCI/CDが必要な理由
17. データ活用は失敗するものと捉える データ基盤を会社として取り組んでいるということは、 恐らくデータを活用して、ビジネス価値を出すことが目的でしょう。 データ活用は、実験的な取り組みの連続です。 ほとんどの取り組みは失敗して、成功する確率は非常に低いです。 なので、私は基本的に失敗前提で取り組んでいます。
18. では、失敗を前提とした時に 何をすべきでしょうか？
19. 答えはシンプルで、「たくさん試す」
20. 「たくさん試す」を実現する手段として CI/CDは有効な手段です
21. ちなみに、データ基盤のCI/CDは ソフトウェア開発と少し性質が違います これを意識して取り組みたい
22. ソフトウェア開発者でも苦労する データ基盤のCI/CD構築は、 一般的なソフトウェア開発とは異なる課題があります。 豊富なソフトウェア開発経験を持つエンジニアでさえ、 データ基盤特有の課題に直面し、効果的なCI/CD構築に 苦労しているケースを数多く見てきました。
23. ソフトウェア開発とは最終成果物が違う 従来のソフトウェア開発ではコード自体が最終成果物ですが、 データ基盤ではデータセット自体が最終成果物となります。 そのため、良いプラクティスが違うということは当然起きます。 これを聞いてるあなたが、ソフトウェア開発経験者なら、 最終成果物が違うものを扱っているんだという意識が大事です。 もちろん数多くの場面で、ソフトウェア開発の知識は役立ちます。
24. どこがどう難しいのか？ 紐解いていきます
25. アジェンダ • 自己紹介 • データ基盤のCI/CDが必要な理由 • データ基盤開発が難しい理由 • ケーススタディ: CARTA MARKETING FIRM ◦ 設計方針 ◦ 実践例
26. データ基盤開発が難しい理由
27. テストデータでは動いたけど 本番では動かない 遭遇したことある人〜✋
28. このトラブルはデータ基盤の 開発の難しさを表す最たる例です
29. この難しさはどこから来るのか？
30. 三位一体の要素
31. データ基盤の三位一体の要素が生み出す課題 データ基盤には切っても切り離せない • コード • データ • コンピュート という三位一体の要素があります。 この3要素が相互作用し合って、 「テストデータでは動いたけど、本番では動かない」 を引き起こしています。
32. コード • データ変換ロジック ◦ dbt, Python • パイプライン制御 ◦ AWS Step Functions, Airflow, Dagster • 品質検証 ◦ dbtテスト, Great Expectations
33. データ • 入力データ ◦ アプリケーションログ ◦ マスターデータ（顧客、商品など） • 出力データ ◦ レポートテーブル ◦ ダッシュボード ◦ データマート
34. コンピュート • データウェアハウス ▪ Snowflake, BigQuery, Databricks, Redshift… • 実行環境 ◦ ECS Fargate, EC2, Lambda…
35. これらの3つの要素は 密接に関連し合っています
36. コードとデータの関係 コードはデータの処理ロジックを定義し、 データはコードの実行結果を決定づけます。 コードの変更はデータの品質や構造に直接影響を与ます。 データの変更も同様です。 • 具体例 ◦ SQLの結合条件を変更すると、集計結果が大きく変わる ◦ 型やカラム名の変更により、依存する下流のレポートが動かなくなる
37. データとコンピュートの関係 データの規模や処理要件が必要なコンピュートリソースを決定し、 逆にコンピュートの制約がデータの保持・処理方針に影響を与えます。 • 具体例 ◦ 大規模なデータ処理には、それに見合ったメモリやCPUリソースが必要 ◦ ストレージの容量の制限により、保持期間や粒度を調整する必要がある
38. コンピュートとコードの関係 コンピュートリソースの制約がコードの実装方法を規定し、 コードの処理要件が必要なコンピュートリソースを決定します。 • 具体例 ◦ メモリ制約により、データの分割処理やストリーミング処理が必要になる ◦ 実行時間の制約により、クエリの最適化やインデックス設計が重要になる
39. 三位一体の要素の相互作用を意識する コード、データ、コンピュートという3つの要素は、 それぞれが独立して存在するのではなく、密接に関連し合っています。 例えば、コードの変更がデータの品質に影響を与え、 それによってコンピュートリソースの要件が変わるといった具合です。 このように、一つの要素への変更が他の要素に波及的な 影響を及ぼすという特性を理解することが重要です。
40. 手運用で開発するとトラブルが起きまくる ここまで紹介した通り、結構複雑なものを扱っています。 なので、できるだけCI/CDでデータ基盤開発でトラブルを防ぐ。 気をつけないとすぐ壊れるみたいな体験になるのは、 CI/CDがうまく構築できていない兆候です。 本来集中したい業務に集中できる環境を整えることが重要です。 そこまで行くとようやくデータ品質云々の話になってきます。 手前でトラブルが多いと、それどころじゃなくなりがちです。
41. コード、データ、コンピュート 何が開発を難しくしているかを 理解すると、戦い方も自ずと見える
42. アジェンダ • 自己紹介 • データ基盤のCI/CDが必要な理由 • データ基盤開発が難しい理由 • ケーススタディ: CARTA MARKETING FIRM ◦ 設計方針 ◦ 実践例
43. アジェンダ • 自己紹介 • データ基盤のCI/CDが必要な理由 • データ基盤開発が難しい理由 • ケーススタディ: CARTA MARKETING FIRM ◦ 設計方針 ◦ 実践例
44. CARTA MARKETING FIRMおける データ基盤CI/CDの設計方針
45. 闇雲にCI/CD組んでも意味がない
46. データ基盤のCI/CDを構築する際 目標、組織、データに合わせて 設計方針を定めることが重要です
47. 目標 RevOpsの考え方を経営に導入し、 部門間の壁を越えて収益最大化を 目指しています。 短期的な課題解決と 長期的なビジョンを両立させながら、 データを経営資本として活用することを 目標にデータ活用を推進中。 https://speakerdeck.com/pei0804/path-to-revops
48. 開発体制 中央集権から分散管理体制へ移行。 データオーナーにデータに関する 意思決定権の委譲。 データ基盤チームは、基盤の改善や 未整備の領域の仕組み開発に注力。 https://speakerdeck.com/pei0804/centralized-to-dataops-transformation
49. データ特性 一言で表すなら、大量で複雑。 複数の広告プロダクトのデータを 扱っています。 1つのログだけで、 1日に数億レコードを超える 膨大な量の半構造化データもあります。 https://speakerdeck.com/pei0804/data-cloud-world-tour-tokyo-2023
50. これらの背景を踏まえ、 データオーナーのアイデアを最速で実現するを 設計方針に据え、CI/CDを構築しています
51. データオーナーのアイデアを最速で実現する RevOpsの推進には、データオーナーの協力が不可欠です。 そのためには、データオーナーが簡単に試せる仕組みを必要です。 仮に技術的なハードルが高いと、アイデアが実行されにくくなります。 ここでCI/CDの活用が効果を発揮します。 例えば、CIで問題点を事前に検知できると、 データオーナーは安心してリリースまで持っていきやすくなります。
52. ガードレールとしてのCI CIはデータ基盤に関わる人達にとって、ガードレールの様な存在です。 最低限のラインをCIで担保し、 「CIが通ってればリリースして良い」としています。 このアプローチにより、開発者の創造性を活かしながら、 データ基盤全体の品質と安全性を確保しています。 ソフトウェア開発なら、こんなの当たり前ですが、 これがデータ基盤だと難しい・・・。
53. 簡単で確実なデプロイを実現するCD データオーナーが開発したコードを、 簡単にリリースすできることを最優先としています。 具体的には、mainにマージされたら、次の実行ではそれが反映されます。 これにより、開発者はリリースプロセスではなく、 本来の開発業務に集中することができます。 リリース作業が大変だと、本当にやる気削がれますし、 開発体験にも直結するため、簡単な方がいいです。
54. そんな委譲しまくって事故らないの？
55. 最初は事故ってました（過去形）
56. 事故ったから、中央集権体制に戻す こんなことやってたら何も変わらない
57. 事故は成長痛
58. 完璧な状態で権限委譲は難しい やってみたら分かることは多い
59. 素振り1年間やるより 1回試合出た方が分かる
60. なぜ事故ったか？を分析する そこに必要な仕組みを作ればいい まず、足元からデータドリブンで解決する
61. 継続的改善が大事 最初からうまく行く施策は珍しいです。 CARTA MARKETING FIRMでも、 様々な苦労がありました。 気になる方はこちらの資料を 御覧ください。 https://speakerdeck.com/pei0804/journey-to-dataops
62. アジェンダ • 自己紹介 • データ基盤のCI/CDが必要な理由 • データ基盤開発が難しい理由 • ケーススタディ: CARTA MARKETING FIRM ◦ 設計方針 ◦ 実践例
63. CARTA MARKETING FIRMおける データ基盤CI/CDの実践
64. 構築する上で 頭を悩ませたCIについて紹介します
65. dbt Slim CI
66. dbt buildをCIで動かしたいニーズ CARTA MARKETING FIRMでは、データ変換にdbtを使っています。 データオーナーは、dbtを使って必要なモデル構築を行います。 コード管理はGitHubで行っています。 こういう状況下で出てくるニーズとして、PullRequestのコード内容で、 dbtを動かしてみて、エラーが起きないか？テストが落ちないか？を、 リリースする前に気づきたい。
67. GitHub Actionで、 dbt buildしたら終わり！ではない
68. 大量データ x dbt build = コストが高い 特に何も考えずに、本番の大量なデータに対して、 コミット毎にdbt buildを実行すると当然ですが、 時間・金銭的コストが高くつきます。 一方で、ある程度は本番のカオスな状態で動かさないと、 この実装で良いと言えるのか？に疑問が出てくる。
69. CIでチェックすることを絞る 本番相当のデータで試すのは難しい。 けど、作ったモデルが想定通りの実装になっているかを確認したい。 • 実行可能なSQLになっているか • テストが通ることを確認したい これに焦点を絞ってCIを構築することにしました。
70. 本番で試したい場合 もちろん本番相当のデータで試したいニーズもあります。 その場合は、開発環境に本番データベースを、 簡単にクローンできる方法を用意しています。 これを活用することで、実際のカオスなデータで 想定通りデータラングリングできているか？など、 本番と同じ環境下で試すことができるようになっています。
71. 実装したもの $ dbt build --target ci --select state:modified+ 変更のあったモデルだけを実行する state:modified+ これに加えて、次に示すようなマクロを基底のモデルで使う
72. limit_ci @ dbt-snowflake 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
73. limitするだけだと足りない limit 10 すると、適当に10件取ってくる挙動になる。 これでリネージュ全体がエラー起きずに動くかのチェックはできる。 一方で時系列データに対しては、これだと片手落ち。 例えば、今日のデータと去年のデータでは、全く文脈が違う。 いま実装しているコードは、今日のデータを前提に書いている。 なので、今日のデータを使って動かしたい。
74. filter_partition_and_limit_ci @ dbt-snowflake 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
75. filter_partition @ dbt-snowflake {%- 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 -%}
76. これで最新のデータ取ってきて 少量データでdbt buildできる！
77. これでも、気付けない問題はある けど、防げるトラブルもある
78. 事故っても気付ける仕組みを作る そして、簡単に戻せるようにする これが実は一番大事
79. 朗報です 先ほどのロジックは、dbt標準になりそう
80. https://github.com/dbt-labs/dbt-core/discussions/11200
81. これから実装する方へ filter_partitionは自前実装しなくていいです https://zenn.dev/pei0804/articles/dbt-new-microbatch-strategy-implementation
82. どんどん標準化されつつあるので 積極的にサボっていきましょう
83. 他の実装も気になる？
84. 公開しているCI/CDに関する記事紹介 techblog.cartaholdings.co.jp/entry/snowflake-dbt-data-platform-vision techblog.cartaholdings.co.jp/entry/pr-agent-dbt-code-review-automation
85. まとめ
86. データ基盤開発は難しい課題を含んでいます コード、データ、コンピュートの 三位一体の要素が密接に関連し合うことで 複雑性が増しています
87. データ活用はさらに難しい領域ですが そこに至るまでの技術的ハードルは CI/CDで大幅に軽減できます
88. 実装が行き詰まったら思い出してみよう コード、データ、コンピュート 何が難しい理由なのか どこまではCI/CDで担保できるか
89. そして、その先にあるデータ活用 これにコミットする時間を増やす
90. データでビジネスを革新する そんなでかいヤマを共に解きませんか？
91. 【PR】We're hiring 【アナリティクスエンジニア】データ活用の可能性を引き出し、新たな価値創造に挑戦 https://hrmos.co/pages/cartaholdings/jobs/cmf-e04 【データエンジニア】データの源泉から価値創造までエンジニアリングする https://hrmos.co/pages/cartaholdings/jobs/cmf-e05