Slide 1
Slide 1 text
DataOps実現への道筋
持続可能な運用体制の構築
適材適所で協業するデータ活用へ
データ利活用のミソ DataOps実現のための取り組みとは？ Lunch LT
Slide 2
Slide 2 text
DataOpsとは
データ分析のプロセスを自動化・最適化し、
データの品質と利用可能性を向上させることで、
データドリブンな意思決定を促進し、
ビジネス価値の実現までのリードタイムを短くするための方法論です。
Slide 3
Slide 3 text
リードタイムを短くするために何をするか。
Slide 4
Slide 4 text
データの利用者は価値創出に集中でき、
データ基盤チームは仕組み作りに集中できる状態を作る。
※弊社の定義
Slide 5
Slide 5 text
DataOpsへの転換
DataOpsが必要になった背景は、
過去の資料で詳しく話しているので、
どういう局面で必要になるかを
知りたい方は、こちらのスライドを
参照してください。
https://speakerdeck.com/pei0804/centralized-to-dataops-transformation
Slide 6
Slide 6 text
DataOpsはいいぞと言われても、
実際なにやったらいいの？
Slide 7
Slide 7 text
今日は養殖ではない本物の現場で、
実際にやったことを余さず話します。
Slide 8
Slide 8 text
アジェンダ
● 自己紹介
● データで振り返る当時の状況
● 効果的だった5つの施策
Slide 9
Slide 9 text
自己紹介
ぺい
@pei0804
近森淳平(チカモリ ジュンペイ)
VP of Data @ CARTA MARKETING FIRM / CARTA HOLDINGS
2024 Snowflake Data Superheroes
Slide 10
Slide 10 text
本日の内容
● 実際の現場でのDataOps導入で効果的だった施策の共有
Slide 11
Slide 11 text
本日話さないこと
● DataOpsの概念的なところ。
● 施策の一つ一つの具体的な実装。
Slide 12
Slide 12 text
アジェンダ
● 自己紹介
● データで振り返る当時の状況
● 効果的だった5つの施策
Slide 13
Slide 13 text
DataOpsが必要になったあの頃。
Slide 14
Slide 14 text
データ基盤チーム: 3名（2024年7月に1名増えたました🎉🎉🎉）
データオーナー: 10名+-
少ない週で10PR/week。多い週で50PR/week。
データ基盤の週ごとのリリース状況(2023-10~2024-07)
DataOpsを考えはじめた時期
Slide 15
Slide 15 text
データ基盤の週ごとのリリース状況(2023-10~2024-07)
データオーナー（黄色）によるリリースが
10PR/weekを安定して超えはじめた頃でした。
DataOpsを考えはじめた時期
Slide 16
Slide 16 text
正直、認知の限界が来ていて、
本格的に回らなくなる前に、なんとかせねば。
当時はそういう状況でした。
Slide 17
Slide 17 text
データオーナー 20PR/week
Slide 18
Slide 18 text
DataOps戦略の立案
2023年11月15日。
Slide 19
Slide 19 text
基盤チーム 35PR/week
Slide 20
Slide 20 text
実際の運用に
乗りはじめたとのは、
戦略立案から3ヶ月後の
2024年2月19日。
Slide 21
Slide 21 text
アジェンダ
● 自己紹介
● データで振り返る当時の状況
● 効果的だった5つの施策
Slide 22
Slide 22 text
ゴールは、データの利用者は価値創出に集中でき、
データ基盤チームは仕組み作りに集中できる状態を作る。
※再掲
Slide 23
Slide 23 text
データ利用者が、データを自ら運用して、
意思決定できている状況を作る。
そのための足りない要素を、ひたすら整える。
Slide 24
Slide 24 text
効果的だった5つの施策
1. ツールの導入
2. データオーナーの確立
3. Slackチャンネルの再設計
4. データ品質向上
5. Playbookの整備
実際のDataOpsの推進施策は、この順番で進めました。
なぜこの順番なのかは、それぞれのセクションで説明します。
Slide 25
Slide 25 text
1. ツールの導入
Slide 26
Slide 26 text
ツール導入がもたらす戦略的意義
何よりも時間と人的リソースを大幅に節約しつつ、
数週間でDataOpsに必要なインフラを本番に導入できる点が重要です。
さらに、ツールが示すベストプラクティスを採用することで、
自然とアンチパターンを避け、効果的な施策を実行しやすくなります。
ただし、適切なツールを選択する目利き力は不可欠です。
Slide 27
Slide 27 text
私の「使える」ツールを見極める4つの視点
● ドキュメントの可読性。
○ 読みやすさはツールの使いやすさを反映している。
● 開発元とのコミュニケーションの相性。
○ 頻繁に共感できる応答がある場合、長期的な協力関係が期待できる。
● 将来性。
○ 今後のロードマップに共感できるか。
● 費用対効果の高さ。
○ 重要な課題を解決できる場合、多少値が張っても安いと感じるものです。
Slide 28
Slide 28 text
DataOpsに向けて本格導入したツール
※実は既に導入していた。
Slide 29
Slide 29 text
No content
Slide 30
Slide 30 text
Elementary Cloud
dbt native データオブザーバビリティサービス
dbtとシームレスに統合できるデータオブザーバビリティサービスです。
dbtを使っていれば、学習コストを低く抑えられることを意味しています。
主な機能は、異常検知テスト、自動モニタリング、データリネージ、
ダッシュボード、Slackアラートなどがあります。
dbtコード内で設定を管理でき、UIでの設定作業が不要な点が魅力的です。
加えてElementaryが提供するメタデータは運用上、
非常に利便性の高いものが多いので、そこもおすすめです。
Slide 31
Slide 31 text
Elementary Cloudを採用している理由
OSS版でも十分な機能がありましたが、
Cloud版の開発初期段階(β版)から参画することでアドテク特有のニーズに
対応できる可能性がありました。（実際に反映されました）
もちろんロードマップも魅力的でした。（2023年時点）
また、dbtネイティブなオブザーバビリティサービスは弊社にとって
重要なコンポーネントになると確信し、投資価値があると判断しました。
※詳細な導入経験は後日記事にまとめる予定です。
Slide 32
Slide 32 text
No content
Slide 33
Slide 33 text
SELECT (SaaS版)
Snowflakeコスト最適化 & 可視化サービス
Snowflakeの使用状況を深く可視化し、効果的なコスト管理を実現。
年間Snowflake支出の3%という明確な料金体系で、
請求額以上のコスト削減を保証。自動化された節約機能により、
導入だけで10-30%のコスト削減が可能。
多種多様なユーザーが使うからこそ、コストがかかりやすいデータ基盤の
コストパフォーマンスを、わずか15分の導入で最適化できます。
効果絶大で2年目も契約更新。データ基盤運用者必見のサービスです。
Slide 34
Slide 34 text
SELECTを使った
コスト可視化、最適化
どういう事業背景で、
実際にどういう課題を解いたか
気になった方は、
こちらの記事を御覧ください。
せっかく契約更新したので、
今度それについてもまとめる予定です。
https://techblog.cartaholdings.co.jp/entry/select-cloud-cost-optimize-cmf
Slide 35
Slide 35 text
次なる課題: データオーナー
データ基盤で起きている問題が見えるようになりました。
しかし、発見した問題の適切な対応者を特定することが
困難であるという新たな課題が浮き彫りになりました。
これは、データの責任所在が不明確であることに起因していました。
効率的なデータ管理と迅速な意思決定を実現するためには、
明確な責任体制の確立が不可欠です。
そこで次のステップとして、データオーナーの確立に取り組みました。
Slide 36
Slide 36 text
2. データオーナーの確立
Slide 37
Slide 37 text
データオーナーの役割
作ったモデルを、自ら運用管理する。
具体的には以下のような責任を担います。
● モデルの品質管理と不具合対応を主導。
● モデルの仕様とロジックに対して、説明責任を負う。
● 実装、テスト、リリース、コスト最適化を実施。
Slide 38
Slide 38 text
dbtのmeta.ownerを使ったデータオーナー管理
dbt_project.ymlの例
models:
jaffle_shop:
+meta:
owner: "@alice"
models/schema.ymlの例
models:
- name: users
meta:
owner: "@alice"
ツールと連携
Elementary Cloud
SELECT
dbt-core
Slide 39
Slide 39 text
次なる課題: Slackチャンネル
データオーナーを設定し、データの責任所在が明確になりました。
しかし、既存のSlackチャンネル設計では、
基盤チーム向けとデータオーナー向けの通知が混在していました。
そのため、各役割の人々がどのチャンネルの通知を重点的に見るべきかが不明確でした。
効率的な情報伝達のため、各役割に必要な情報を伝達する環境整備が必要となりました。
そこで次のステップとして、Slackチャンネルの再設計に取り組むことにしました。
Slide 40
Slide 40 text
3. Slackチャンネルの再設計
Slide 41
Slide 41 text
Slackチャンネル再設計の目的と要件
データオーナーと基盤チーム、それぞれがほしい情報が違うため、
それぞれのほしい情報を集まる場所を作る。
● データオーナーが担当領域の問題を迅速に把握
○ 例: モデルの問題の早期発見
● 基盤チームがシステム全体の状態を迅速に把握
○ 例: データパイプラインの問題の早期発見
Slide 42
Slide 42 text
実際に行ったSlackチャンネルの再設計
● 基盤チーム向け（#info, #warning, #error, #emegency）
○ 目的
■ システム全体の把握を素早くできる。
○ 効果
■ 基盤チームに特化した作りにできるようになった。
● 役割が曖昧な時はオーナーへのノイズを気にしていた。
● データオーナー向け（#data_monitoring）
○ 目的
■ モデル関連問題を一元管理。
○ 効果
■ ここだけ見ればいい状態になり、情報の取捨選択が簡素化。
■ チーム間のナレッジシェア。
Slide 43
Slide 43 text
Elementaryの通知例
設定されたownerを使って、
Slackで通知を制御できる。
ownerをSlackグループにしておくと
メンションもしてくれるので、
気づいてほしい人たちに、
情報を確実に届けることができる。
Slide 44
Slide 44 text
SELECTのコスト通知
SELECTには、User Groupという概念
があり、リソースをグルーピング
できます。
これとdbtで設定したownerの設定が
連携できるので、自分たちのモデルが
どれだけのコストがかかっているかを
簡単に把握することができます。
Slide 45
Slide 45 text
次なる課題: データ品質向上
Slackチャンネルの再設計により、
発生している問題の迅速な伝達が可能になりました。
次に、そもそも問題が発生しにくい環境の整備に着手しました。
具体的には、データ品質向上に取り組みました。
これにより、より安定したデータ運用環境を目指します。
Slide 46
Slide 46 text
4. データ品質向上
Slide 47
Slide 47 text
データ品質の向上のために行ったアプローチ
● データ設計ガイドラインの確立
● 多層的なデータ品質テスト戦略
● インテリジェントなレビュープロセス
Slide 48
Slide 48 text
データ品質の向上のために行ったアプローチ
● データ設計ガイドラインの確立
● 多層的なデータ品質テスト戦略
● インテリジェントなレビュープロセス
Slide 49
Slide 49 text
データ設計ガイドライン
一貫性のあるモデリングを促進し、
初期段階での品質向上を図る指針です。
高品質なデータ設計が分析プロセス全体
の効率を大幅に向上させます。
このガイドラインの導入により、
組織全体のデータ品質の底上げを
図っています。
社内向けのドキュメントで現状非公開
Slide 50
Slide 50 text
良いデータを作る意義
データの設計の重要性については、
こちらの発表で説明しています。
興味がある方は是非御覧ください。
https://speakerdeck.com/pei0804/modeling-over-shiny-tech
Slide 51
Slide 51 text
データ品質の向上のために行ったアプローチ
● データ設計ガイドラインの確立
● 多層的なデータ品質テスト戦略
● インテリジェントなレビュープロセス
Slide 52
Slide 52 text
データ入力の信頼性確保
dbt freshness
鮮度テストの実装は、信頼性の高いデータパイプライン構築の第一歩です。
これにより、後段のモデルテストの有効性が担保され、
問題の早期発見と切り分けが容易になります。
鮮度テストは問題の即時検知を可能にし、デバッグプロセスも簡素化します。
例えば、何らかのテストが失敗した場合、鮮度テストの結果によって問題の
所在を特定できます。鮮度テストが失敗していれば外部要因の可能性が高く、
通過していればデータパイプライン内の問題と推測できます。
この切り分けにより、トラブルシューティングの効率が大幅に向上します。
Slide 53
Slide 53 text
基本的なデータ整合性の検証
dbt generic data test
dbtのgeneric data testは基本的なデータ品質保証の要です。
特にビジネスキーに対するuniqueとnot_nullテストは必須であり、
これだけでも多くのデータ問題（ファントラップ等）を防げます。
弊社だと、全カラムへの網羅的なテスト適用はコスト効率が悪いため、
ビジネス上クリティカルな部分に焦点を当てるようにしています。
※事業特性に応じて適切に判断しましょう。
Slide 54
Slide 54 text
ビジネスロジックに基づく高度なデータ検証
複雑なビジネスルールや特殊なデータパターンの検証には、
dbt expectationsなどの専門パッケージを活用します。
これらの高度な検証は、基本的なテストで対応できない課題が明確に
なった時点で段階的に導入します。
過度に複雑なテストを早期に導入すると、
維持管理の負担が増大し、効果が低下する可能性があります。
Slide 55
Slide 55 text
データ品質の向上のために行ったアプローチ
● データ設計ガイドラインの確立
● 多層的なデータ品質テスト戦略
● インテリジェントなレビュープロセス
Slide 56
Slide 56 text
CIによる品質保証
機械的判断可能な部分を徹底的に
自動化し、品質の一貫性を確保。
人為的ミスやばらつきを排除し、
開発プロセスの信頼性を向上。
一貫性の維持がユースケース増加時の
パターン認識を容易にし、
長期的な拡張性に貢献。
詳しくは記事を御覧ください。
https://techblog.cartaholdings.co.jp/entry/snowflake-dbt-data-platform-vision
Slide 57
Slide 57 text
AIを活用したレビュー
CIでは捉えにくい潜在的リスクを自
動検出。
意図しない破壊的変更や
判断を要する箇所を特定し、
開発者に再考を促す。
詳しくは記事を御覧ください。
https://techblog.cartaholdings.co.jp/entry/pr-agent-dbt-code-review-automation
Slide 58
Slide 58 text
次なる課題: Playbookの整備
データ品質向上施策後に、問題対応プロセスの個人知識に依存している
問題が浮上しました。これは、dbtへの理解度の違いで起きる問題です。
この課題に対処するため、基本的な対応手順を明記したPlaybookを
整備し、問題対応の均一化、そして知識の共有を目指しました。
Slide 59
Slide 59 text
5. Playbookの整備
Slide 60
Slide 60 text
Playbookの目的と効果
Playbookは、データ運用の標準化された指針です。
主な目的は
● 問題対応の一貫性確保。
● 組織的な知識共有。
● ベストプラクティスの文書化。
手順と判断基準を明確化し、データオーナーのスキル向上を促進します。
結果として、問題対応の迅速化と運用品質の向上を実現します。
Slide 61
Slide 61 text
データオーナー向けに用意してるPlaybook例
社内向けのドキュメントで現状非公開
Slide 62
Slide 62 text
6. 継続的進化
Slide 63
Slide 63 text
継続的進化（まとめ）
DataOpsに終着点はなく、常に新たな最適化の機会が生まれます。
その時々の最善策を追求し、アジャイルに実践することが重要です。
この継続的な進化のプロセスを通じて、
組織のデータ活用能力とビジネス価値の創出を着実に
向上させていくことがDataOpsの本質だと考えています。
Slide 64
Slide 64 text
8/21に「みんなの考えた最強のデータ基盤アーキテクチャ」に登壇します。
発表内容は、「（仮）データ基盤が安定稼働した先にあるデータエンジニアリングの世界線。」
https://datatech-jp.connpass.com/event/319827/