Upgrade to Pro — share decks privately, control downloads, hide ads and more …

データの民主化を支える、透明性のあるデータ利活用への挑戦 2025-06-25 Datab...

データの民主化を支える、透明性のあるデータ利活用への挑戦 2025-06-25 Database Engineering Meetup#7

BigQuery + dbt + Paradime.ioを中心としたデータ基盤で、データの民主化を実現するための6つのアクションプランと具体的な解決策を紹介します。

主な取り組み

定義・指標の統一 - 過去数値の確定化
dbt mesh構成 - 複数プロジェクト対応による疎結合化
CI/CDによる品質担保 - Column Lineage Diffで影響範囲を事前把握
データカタログ共有 - ThoughtSpot含む全ダッシュボードのリネージュ可視化

Avatar for Kentaro Yoshida

Kentaro Yoshida

June 25, 2025
Tweet

More Decks by Kentaro Yoshida

Other Decks in Programming

Transcript

  1. © Commune Inc. All rights reserved ⽬次 1. ⾃⼰紹介、システムアーキテクチャ紹介 2.

    データの⺠主化とは何か 3. 短期に実現したい世界(ビジョン) 4. 直⾯していた課題をいかに解決したか 5. Paradime.ioを導⼊して良かったこと 6. まとめ
  2. © Commune Inc. All rights reserved ⾃⼰紹介 Kentaro Yoshida (X:

    @yoshi_ken) 4 Communeのデータエンジニア。ex-TreasureData • 2024年6⽉にコミューンへ⼊社 • Product & Dataチームに所属(10⼈/150⼈) • ビジネス側と開発チームの間に⽴つProduct&Data チームから、組織全体の知の⾼速道路となるデー タ活⽤環境整備と仕組み化を推進中。 データ処理にdbtを活⽤、BIにThoughtSpot導⼊中 • ⾃社メディア事業をいくつも起ち上げてきた ソフトウェアエンジニアやDBAの経験を⽣かし、 2015年頃からはデータ分析基盤を軸に、⾃社SaaS 系のデータエンジニアをエンジョイしています
  3. © Commune Inc. All rights reserved 8 短期に実現したい世界(ビジョン) データの⺠主化のために、次の6つのアクションプランを⽴てました 1.

    定義‧指標の統⼀ 2. dbt mesh構成による疎結合化(複数dbt project対応) 3. 不整合や実⾏エラーを未然に防ぐ 4. 依存関係を観測できる 5. 品質問題の早期検知とアラート 6. カタログを社内に共有
  4. © Commune Inc. All rights reserved 課題1「定義‧指標の統⼀」をいかに解決したか 必要なこと • 地道な調整と解決

    • 過去の数字はファクトとして確定させられる定義にただす • 指標毎に定義書を作成してそれを元にあるべき集計を⾏うモデルを作成する 実現の障壁 • incremental modelなのに、再実⾏すると過去の結果が⽇々変わってしまう • 過去の⾏動ログと、最新断⾯を結合しているものがあった • 既に動いている物を可能な限り破壊せずに移⾏すること 9
  5. © Commune Inc. All rights reserved 課題2「dbt mesh構成、疎結合化」をいかに解決したか 必要な要件 •

    単⼀のdbt projectからdbt mesh構成になり、名前空間を分けた分業が⾏えること • クラスのようにprivate, publicモデルとラベルし、ガバナンスを効かること ◦ 同じ名前空間でなければ、循環参照を起こさず適切な階層構造が取れる • 各チームにとって必要な参照モデルだけを持つ軽量なdbt packageとなれば、 他チームも扱いやすくなり、コラボレーションを⾏いやすいこと 実現の障壁 • dbt-coreを⽤いたVisual Studio Codeでのローカル開発を引き続き⾏いたい • dbt Cloud Teamプランだと1プロジェクトまで、開発者も8名までという制約 • dbt Cloud Enterpriseプラン(年間200万円〜)では複数プロジェクト対応だが、 Cloud IDEを使わずに開発体験を損なわずにローカル開発するのは難しい 10
  6. © Commune Inc. All rights reserved 11 dbt-loomを導⼊することで、dbt mesh構成が実現できる •

    dbtのGroups, Access機能を活⽤したアクセス制御がdbt-coreのままで実現 • 他のプロジェクトのモデルを {{ ref('parent_dbt_project_name', 'model_name') }} の形式で参照できる • pip install dbt-loom と設定ファイルの配置で導⼊でき、dbt-coreの機能を拡張 • 実⾏時に、親となるdbtプロジェクトの manifest.json をダウンロードしてdbt packageとして内部的に展開することで、他のプロジェクトのモデルを参照できる ようになります • dbt Mesh constructsの設定が楽になる dbt_meshify というツールがあります • しかしdbt-loomは、dbt Cloudでは使えません...
  7. © Commune Inc. All rights reserved 課題3「不整合や実⾏エラーを未然に防ぐ」をいかに解決したか 必要な要件 • CIによって、ビルドできることを担保する

    ◦ defer to prodを用いて差分ビルドを行い、短時間に結果が分かること • ある列名を消したりリネームした時、後続モデルが壊れないことをテストする ◦ それを利用するダッシュボードが壊れないことも CIで担保する • 不具合が起きても、テストのエラー結果を⾒れば、調査なしに原因がわかること 実現の障壁 • ダッシュボードが壊れないことを担保できるCIをいかに作るか? (答えは次ページ) 13
  8. © Commune Inc. All rights reserved 14 不整合や実⾏エラーを未然に防ぐための⼯夫 • ⾼速なCI

    ◦ dbt Cloudで、defer to prod設定を有効にしたCIを設定した • dbt buildコマンドの‒emptyフラグを⽤いたビルドでコンパイルエラーの検知可能 ◦ どの列で問題が発⽣しているかの調査は⼿間 • ダッシュボード群への影響検知 ◦ PRのコメントにレポートをまとめて欲しい ◦ Paradime.io によるlinage diffがズバリ便利 ◦ Looker, Tableau, ThoughtSpotに対応 ◦ CIだけのためにでも使いたい機能!
  9. © Commune Inc. All rights reserved 課題4「依存関係を観測できること」をいかに解決したか 必要な要件 • ローカル開発に⽀障を与えずに、リネージュに利⽤先が⾒えること

    • CIでの破壊的変更があったとき、CIでどこに影響するか後続モデルだけでなく、 どのようなダッシュボードに影響が出るかが検知できること 実現の障壁 • BIツールのダッシュボードをスキャンして リネージュに組み込むこと • exposureの名前表⽰にnameではなく、 ⽇本語が⼊るlabelを参照できること • ThoughtSpotのカタログ化を⾏うOSSがない 15 全てのダッシュボードをexposureに登録 した際の、VS Codeでのリネージュ表⽰
  10. © Commune Inc. All rights reserved 16 • GithubActionsを⽤いて、BigQueryのクエリログを解析し、dbt exposureを⽣成

    LookerStudio, ConnectedSheet, Redashのクエリログを解析してdbt modelの名前に 変換している • local dbt packageを作り、その中にexposureをカプセル化 elementary, dbt cloud, paradime.ioのデータカタログでは関連パッケージがすべて⾒ えるが、vs codeでのローカル開発ではそのdbt projectだけが⾒えるため、⾒通しが よくなった • MySQLのテーブル名に対応する形で、何個の後続処理がそれを参照しているか分かる スプシを作成し、開発チームに提供 依存関係を観測するための⼯夫
  11. © Commune Inc. All rights reserved 課題5「品質問題の早期検知とアラート」をいかに解決したか 必要な要件 • ⾃動化できる余地のある作業はすべて⾃動化すること

    • 各Jobが実⾏した後にelementaryを呼んで、テストの結果をslackに流す • 失敗したテストの⼀覧がelementaryのレポートで⾒られること • データの⽋損‧重複‧⻭抜けテストをモデル追加時に備わっていること • MySQLからの新規取り込みが必要なテーブルを検知して⾃動で通知が⾶ぶこと 実現の障壁 • slack通知や、レポートの⽣成をどこで⾏うか • PRの⾃動AIレビュー 17
  12. © Commune Inc. All rights reserved • MySQLからBigQueryへの取り込みが必要なテーブルの通知 ◦ MySQLのカラム追加/削除検知も実施

    ◦ dbtモデルの調整が必要な課題の⼀覧を抽出し、メールで変更通知する仕組み を、GoogleSheetのコネクテッドシートの条件付き通知機能を⽤いて実現 • dbt testの結果はelementaryのedr reportコマンドで即時slack通知を実⾏ • AIによる⾃動PRレビューにGemini Code Assist を導⼊ ◦ PRレビューで確認したい観点をあらかじめ⽇本語で指⽰ ◦ 2025年5⽉ gemini 2.5から役⽴つコメントをしてくれるようになった ◦ データの⽋損‧重複‧⻭抜けのテスト実装の定型パターンを提案 18 品質問題の早期検知とアラートするための⼯夫
  13. © Commune Inc. All rights reserved 19 paradime.io のスケジュールは、dbtコマンド以外も⾊々呼べる •

    dbtコマンド以外も呼べる。インフラ管理不要なのが嬉しい。 pythonスクリプト経由で、cronでは表現しきれないユースケースにも対応できる • スケジュール設定⾃体がJSTタイムゾーン対応してるので、UTC換算が不要
  14. © Commune Inc. All rights reserved 課題6「カタログを社内に共有する」をいかに解決したか カタログを社内に共有するために必要な要件 • Google認証でSSOしたらダッシュボード群を含めたカタログが⾒られること

    実現の障壁 • そもそもdbt docs generateやelementaryでは、exposureとして登録した物は⾒え るが、Looker Studio, ThoughtSpotダッシュボード群のリネージュが⾒えない • Elementary Cloudはダッシュボード群のリネージュが⾒えるため有⽤だが、閲覧 ユーザのアカウント数はシート課⾦ • dbt Cloud Teamsプランでは、カタログを提供が8名までのため利⽤不可 → Paradime.io はカタログが⾒られる閲覧ユーザはFreeで使えるため検討を始める Looker, Tableau, ThoughtSpotダッシュボードにも対応している 20
  15. © Commune Inc. All rights reserved 22 • Paradime Labsチームの開発スピードが速く、進化し続けている

    • 複数dbt project対応により、dbt mesh構成を実現できた • dbt buildが1.3倍 速くなった(AWS Gravitonインスタンスを使っているため) • スケジュールの管理をUI操作なしに、YAMLファイルで管理できるようになった • dbt buildの前後に好きなCLIやpythonコードをインフラ管理なしに実⾏可能 elementaryで集計したテスト結果などのslack通知が送れる • データカタログを社員ならGoogle SSOで⾒られるようになった このカラムはどこで使ってるの?等の疑問をセルフサービスで解決 • CI/CD, Column Linage Diffによりデータパイプラインがさらに壊れづらくなった • ダッシュボード群も含めた依存関係図がリネージュで⾒られるようになった Paradime.ioを導⼊して良かったこと