データリネージの組織導入事例と今後の戦略 / Introduction to an example of data lineage in GMO Pepabo

datatech-jp Casual Talks #4 登壇資料 https://datatech-jp.connpass.com/event/264640/

Transcript

1. データリネージの 組織導入事例と今後の戦略 堤 利史 / GMO PEPABO inc. 2022.12.12 datatech-jp Casual Talks #4 1
2. 2 自己紹介 技術部 データ基盤チーム シニアエンジニア 2020年 中途入社 堤　利史 TSUTSUMI Toshifumi 2020年12月にGMOペパボへ入社。 データエンジニアとしてデータ基盤の 開発・運用に従事。 Twitter: @tosh2230 先日、PS5の購入に成功しました
3. 3 アジェンダ 1. データリネージをはじめた背景 2. Stairlight の紹介 3. GMOペパボでのデータリネージ導入事例 4. 今後の戦略と課題
4. 4 1. データリネージを はじめた背景
5. データの系譜を明らかにすること - Lineage: 血統、家柄 - メタデータ（データを説明するためのデータ）の一種 データの可観測性（Data observability）の向上が目的 - このデータは何から生まれたのか？ - このデータはどこで使われているのか？ 1. データリネージをはじめた背景 5 データリネージ（Data lineage）
6. - データ駆動のためのエコシステムの提供 - サービスの動的な改善と意思決定の自動化をサポート 詳細はこちらの資料を ご参照ください 👉 1. データリネージをはじめた背景 6 データ基盤 Bigfoot https://speakerdeck.com/zaimy/inside-story-of-data-infrastruc ture-supporting-gmo-pepabos-services-and-r-and-d
7. 7 - 運営サービスが複数ある = データベースが複数ある - つまり Extract 対象がいっぱいある - Extract したデータの種類が多いと Transform のパターン数も増えがち GMOペパボは、インターネットサービスを多数運営しています 1. データリネージをはじめた背景 * ほかにもたくさん! 詳しくは https://pepabo.com/services/ をご覧ください
8. 8 困りごと 1： データ障害の原因や影響範囲を把握しにくい 1. データリネージをはじめた背景 誰か 「このテーブルが壊れたら、誰が、どういう風に困る？」　 私 「」 過去には、データ障害発生から復旧までに要した時間の半分以上を “影響範囲の調査”と”復旧に必要なジョブ特定”に使っていたことも...
9. 9 困りごと 2: 業務データの活用状況を把握しにくい 1. データリネージをはじめた背景 「誰が、どこにあるデータを、どのように活用しているのか？」 • 各事業では、複数のデータベースやデータウェアハウスに対して SQL を用いてデータを取得し、施策の検討やビジネス的な判断を行っている • Bigfoot は、社内ユーザーから見るとデータソースのひとつに過ぎない • Bigfoot の活用状況のみならず、業務データ全体の活用状況を知りたい
10. 10 業務データ全体に対するデータリネージがしたい 1. データリネージをはじめた背景 特定のアプリケーションやデータウェアハウス、ワークフローではなく、 業務データフロー全体におけるアウトプット同士の関係性を把握したい • テーブル • ダッシュボード • Slack 通知 • 統計・機械学習モデル • …
11. 11 2. Stairlight の紹介
12. 12 2. Stairlight の紹介 An end-to-end data lineage tool, detects table dependencies from SQL statements. $ pip install stairlight https://github.com/tosh2230/stairlight
13. 13 2. Stairlight の紹介 特徴1: SQL からデータのつながりを見つける Jinja パラメータ
14. 14 2. Stairlight の紹介 特徴2： コードベースにある SQL を探す 過去に実行されたクエリではなく いま・これから実行されうるクエリを リネージ対象にする
15. 15 2. Stairlight の紹介 特徴3: 独立性が高い - データリネージ機能(抽出・検索)のみを提供する - ETL/ELT, BI などの機能を提供するツールとの結合度が低い - 複数のユースケース - ローカルなどから依存関係を検索 - 抽出用エージェント - Python ライブラリとしてアプリケーションに組み込み
16. 16 2. Stairlight の紹介 開発背景や機能解説は PyCon JP 2022 のスライドをご覧ください https://speakerdeck.com/tosh2230/e2e-data-lineage
17. 17 1. セクションタイトル 3. GMOペパボでの データリネージ導入事例
18. 3. GMOペパボでのデータリネージ導入事例 18 logs metrics GitHub issues databases tbls datasets BigQuery bigfoot/platform Cloud Storage - Permissions - Datasets - Buckets Looker Studio bigfoot/cloud-composer Cloud Composer dags/ tbls-build base tbls.yml files patch files ( *.yml, *.json ) patched tbls.yml files tbls-meta tbls data catalog Apply metadata Generate & Commit Generate schema.json & commit bigfoot/data-catalog Update metadata & commit Send analysis results Verne Vertex AI Bigfoot 概要図 18
19. 3. GMOペパボでのデータリネージ導入事例 19 bigfoot/cloud-composer のリネージ情報を収集 Bigfoot のオーケストレーションに関するコードを 管理するリポジトリ 現時点で管理している SELECT 文： 約220 2022年10月から運用開始
20. 3. GMOペパボでのデータリネージ導入事例 20 bigfoot/data-lineage で設定ファイルを管理 bigfoot/cloud-composer 1. コード追加・変更 2. Pull Request 作成 3. マージ・デプロイ bigfoot/data-lineage 1. 未設定クエリの自動抽出＊ 2. 設定追加・変更 3. Pull Request 作成 4. マージ * “stairlight map” コマンドで抽出します
21. 3. GMOペパボでのデータリネージ導入事例 21 情報伝達の質と展開速度↑ - データ障害が発生した際、影響調査に要する時間が減った - 業務影響の有無を、これまでよりも正確に・早い段階で周知できるようになった 俯瞰的な視点 - アウトプット同士の依存関係を把握する手段を得たことで、 優先順位を決める判断材料が増えた - 障害復旧までに要する作業量の削減と作業時間の短縮を実現した 効果
22. 22 4. 今後の戦略と課題
23. 4. 今後の戦略と課題 23 View 層のデータリネージ Verne - Cloud Run ベースの 汎用アプリケーション基盤 - Streamlit を用いた ダッシュボードがメイン - ex. Four keys* BI ツール - Redash - Metabase * エンジニアの活動情報からFour Keysを集計、可視化した話 https://tech.pepabo.com/2022/01/06/four-keys-dashboard/
24. 4. 今後の戦略と課題 24 設定ファイル更新 Pull Request 作成の自動化 bigfoot/cloud-composer 1. コード追加・変更 2. Pull Request 作成 3. マージ・デプロイ bigfoot/data-lineage 1. 未設定クエリの自動抽出 2. 設定追加・変更 3. Pull Request 作成 4. マージ
25. 4. 今後の戦略と課題 25 リネージ情報を GUI で公開 bigfoot/cloud-composer 1. コード追加・変更 2. Pull Request 作成 3. マージ・デプロイ bigfoot/data-lineage 1. 未設定クエリの自動抽出 2. 設定追加・変更 3. Pull Request 作成 4. マージ Verne
26. 4. 今後の戦略と課題 26 遅延情報の開示と通知 Data Health Dashboard - データが期待した状態であるか、ヘルスチェック結果を常に開示 - ETLジョブではなく アウトプットの状態とその関係性 を表示する 遅延通知 - データ遅延を都度報告するのではなく、即座に伝える - 通知登録をした人・グループ・Slack チャンネルに送る(列車遅延通知と同じ)
27. 4. 今後の戦略と課題 27 Looker Studio と Connected Sheets - 設定を取り出す方法が 見つかっていない - 監査ログから事後的に クエリを検出する予定 検討中... アプリ・ジョブ ⇔ アウトプットの 相互検索 - Stairlight の Label 機能 で実現できる？ - (要検証)
28. まとめ 28 - 人間やアプリケーション、統計・機械学習モデルなどが生み出す アウトプットの関係性を、データリネージによって継続的に捉える - データ基盤チームから積極的に施策を提案できる態勢にする - 社内データ活用の状況・状態が常に公開されていることを”ふつう”にする
29. 29 Thank You! Thank You!