データカタログの最初の⼀歩 〜データ組織向けに dbt docs を整備している話〜 2024.05.24 @TROCCO UG 株式会社ヤプリ 技術戦略室 データサイエンスグループ ⼭本 雄太

Speaker プロダクト開発本部 技術戦略室 データサイエンスグループ ⼭本 雄太 ● 23新卒として⼊社 ● 分析⽤データ基盤のdbt刷新を担当 ● 社内でのあだ名は「もっさん」

株式会社ヤプリと データサイエンスグループの 紹介

ヤプリの製品｜ノーコードのアプリ開発プラットフォーム「Yappli」 ● 700社以上が導⼊、800アプリ以上を提供 ● 40種類以上の機能が利⽤可能。多様なシーンに合致したアプリが作成可能

ヤプリの製品｜Yappli 導⼊顧客向けにアナリティクスサービスを提供 CMS ダッシュボード Yappli 管理画⾯のトップに 表⽰されるダッシュボード Yappli Data Hub アプリ内の⾏動データや属性データを ユーザ単位で分析を可能にする データ連携サービス Yappli Analytics アプリログを網羅した分析や、 機能別に特化した分析が可能な ダッシュボード

TROCCO歴は4年⽬！いつもお世話になってます🙇 第3回troccoUG 『ヤプリ社の症例から考えるtrocco依存症』 trocco® Best Contributor ユーザアワードを 阿部が受賞

2023 2024 … 1⽉ 2⽉ 3⽉ 4⽉ 5⽉ 6⽉ 7⽉ 8⽉ 9⽉ 10⽉ 11⽉ 12⽉ 1⽉ 2⽉ 3⽉ … 開発フロー 構築 2023年から分析⽤データ基盤の   移⾏を開始 CMS ダッシュボードの参照元切り替え 共通データマートの dbt リプレイス dbt test 導⼊ Yappli Analytics の 参照元切り替え （DSメンバーが dbt 導⼊に集中できるよう）問い合わせ対応など

2023 2024 … 1⽉ 2⽉ 3⽉ 4⽉ 5⽉ 6⽉ 7⽉ 8⽉ 9⽉ 10⽉ 11⽉ 12⽉ 1⽉ 2⽉ 3⽉ … 2023 2024 … 1⽉ 2⽉ 3⽉ 4⽉ 5⽉ 6⽉ 7⽉ 8⽉ 9⽉ 10⽉ 11⽉ 12⽉ 1⽉ 2⽉ 3⽉ … 開発フロー 構築 2023年から分析⽤データ基盤の   移⾏を開始 共通データマートの dbt リプレイス dbt test 導⼊ Yappli Analytics の 参照元切り替え CMS ダッシュボードの参照元切り替え https://tech.yappli.io/entry/update-dbt-infra-dev-flow https://speakerdeck.com/yamamotoyuta/ci-no10nian -wozhan-erufen-xi-yong-detaji-pan-gou-zhu-nodi-bu- dbtniyoruji-pan-shua-xin-tokuerifei-yong-90-percent- xue-jian-henoqu-rizu-mi （DSメンバーが dbt 導⼊に集中できるよう）問い合わせ対応など https://tech.yappli.io/entry/replace-ya-mart-to-dbt

TROCCO UG にもかかわらず⼤変恐縮なのですが… TROCCO のデータカタログ機能は未導⼊です🙇 発表を聞いて活⽤ポイント等ございましたら、ぜひ布教いただけますと幸いです🙏

と、思ってたんですが…

はじめに： 誰向けのデータカタログ？

ヤプリではDWHをBigQuery、データ加⼯をTROCCOで実施 （現在、データ基盤全体でベースとなっているデータマート（共通データマート）の加⼯処理をdbtへ移⾏中） エンドユーザ 営業 エンジニア 営業データ サービスDB アプリログ DSグループ BigQuery CMS ダッシュボード Yappli Analytics 社内外ダッシュボード‧ データ提供 顧客 CS 顧客 営業 エンジニア trocco dbt

今回お話しするデータカタログは「DSグループ内向け」 DSグループ外向けのデータカタログの話はしません（どう作ると良いのか絶賛悩み中…） エンドユーザ 営業 エンジニア 営業データ サービスDB アプリログ CMS ダッシュボード Yappli Analytics 社内外ダッシュボード‧ データ提供 顧客 CS 顧客 営業 エンジニア DSグループ BigQuery trocco dbt

● なぜDSグループ内向けのデータカタログを作っているのか？ ● どうやって作っているのか？ ● 実際にやってみての所感 ● 今後やっていきたいこと 本⽇お話しすること

なぜDSグループ内向けの データカタログを？

無かったから

ヤプリのデータ組織の変遷 2023年 ● 社内唯⼀のDSとして阿部がデータ周りの全てを担当 ○ セールス、CS、エンジニア etc…様々な部署と連携しながらデータ基盤を構築 ➡ データカタログを整えるところまで⼿を回す余裕がない… 私が作りました ● DSメンバーが増えて3⼈になり、DS”グループ”に ➡ データカタログがないことが深刻化 データのキャッチアップつらい …

● データ関係の仕様書があちこちに分散 ○ 社内ドキュメント、スプレッドシート、LookML、顧客向けサポートページ etc… から頑張っ て探す ● クエリを直接読まないと分からない ○ TROCCO のワークフローに組み込まれているデータマート定義のクエリを解読 ● 作った本⼈に直接訊かないと分からない ○ Slack メンション等で作った本⼈を頻繁に召喚 → コミュニケーションコスト、召喚＝作業中断によって作業効率 DOWN 何が深刻だったか？

同じく2023年、データ基盤の   移⾏がスタート エンドユーザ 営業 エンジニア 営業データ サービスDB アプリログ DSグループ BigQuery CMS ダッシュボード Yappli Analytics 社内外ダッシュボード‧ データ提供 エンドユーザ‧ CS 営業‧ エンジニア trocco dbt

● データの加⼯処理を管理してくれるツール ○ SQL による加⼯処理の Git 管理を可能に ○ データカタログの⾃動⽣成 ○ データのテスト ○ etc… ● 無償CLI版の「dbt Core」と 有償SaaS版の「dbt Cloud」がある ○ ヤプリでは dbt Core を採⽤      とは

● データの加⼯処理を管理してくれるツール ○ SQL による加⼯処理の Git 管理を可能に ○ データカタログの⾃動⽣成 ○ データのテスト ○ etc… ● 無償CLI版の「dbt Core」と 有償SaaS版の「dbt Cloud」がある ○ ヤプリでは dbt Core を採⽤      とは

dbt のデータカタログ⾃動⽣成 SELECT id AS order_id, user_id as customer_id, order_date, status FROM dbt_src_test.raw_orders SELECT id AS customer_id, first_name, last_name FROM dbt_src_test.raw_customers raw_orders.sql raw_customers.sql dbt では SELECT~FROM 句が書かれた SQL ファイルでテーブルを定義

dbt のデータカタログ⾃動⽣成 SELECT id AS order_id, user_id as customer_id, order_date, status FROM dbt_src_test.raw_orders SELECT id AS customer_id, first_name, last_name FROM dbt_src_test.raw_customers raw_orders.sql raw_customers.sql テーブル定義ファイルからデータカタログ（ dbt docs ）を⾃動作成 dbt docs generate コマンド

dbt のデータカタログ⾃動⽣成 YAML ファイルでテーブルやカラムの説明などを補⾜可能 version: 2 models: - name: stg_customers description: | 顧客テーブルを参照するためのステージング View columns: - name: customer_id description: "顧客ID" data_type: INT64 - name: first_name description: "名前" data_type: STRING - name: last_name description: "名字" data_type: STRING stg_customers.yml

dbt のデータカタログ⾃動⽣成 リネージグラフが⾒れる！

● データ関係の仕様書があちこちに分散 ○ 社内ドキュメント、スプレッドシート、LookML、顧客向けサポートページ etc… ● クエリを直接読まないと分からない ○ TROCCO のデータマート定義にあるクエリを解読 ● 作った本⼈に直接訊かないと分からない ○ Slack メンション等で頻繁に本⼈召喚が発⽣ → コミュニケーションコスト、作業効率 DOWN ➡ dbt 移⾏時にデータカタログも dbt docs で作っていこう 何が深刻だったか？ dbt docs でこれらを解消しよう💪

「dbt docs にまとまっている」を⽬指すために やったこと

● GitHub Actions で dbt docs を GitHub Pages へ⾃動でデプロイ＆更新 ● 社内ドキュメントにあった DB 仕様書を dbt docs へ転記 やったこと

● GitHub Actions のワークフローの流れ ○ 1. main ブランチへの push が⾏われたらワークフローを実⾏ ○ 2. ワークフロー内にて dbt の実⾏環境を作成 ○ 3. dbt docs generate コマンドを実⾏して dbt docs ⽤のファイル（HTML, JSON）を⽣成 ○ 4. ⽣成されたファイルを GItHub Pages へデプロイ ● GitHub Pages の Private 公開が可能なプランを契約している必要がある ○ ヤプリは Private 公開が可能な契約プランだった GitHub Actions で dbt docs を GitHub Pages へ⾃動でデプロイ＆更新

GitHub Actions で dbt docs を GitHub Pages へ⾃動でデプロイ＆更新 2023 2024 … 1⽉ 2⽉ 3⽉ 4⽉ 5⽉ 6⽉ 7⽉ 8⽉ 9⽉ 10⽉ 11⽉ 12⽉ 1⽉ 2⽉ 3⽉ … 開発フロー 構築 CMS ダッシュボードの参照元切り替え 共通データマートの dbt リプレイス dbt test 導⼊ Yappli Analytics の データソース切り替え （DSメンバーが dbt 導⼊に集中できるよう）問い合わせ対応など チームでの dbt 開発が始まったタイミングで 早期に⾃動更新の仕組みを導⼊💪

GitHub Actions で dbt docs を GitHub Pages へ⾃動でデプロイ＆更新 2023 2024 … 1⽉ 2⽉ 3⽉ 4⽉ 5⽉ 6⽉ 7⽉ 8⽉ 9⽉ 10⽉ 11⽉ 12⽉ 1⽉ 2⽉ 3⽉ … 開発フロー 構築 CMS ダッシュボードの参照元切り替え 共通データマートの dbt リプレイス dbt test 導⼊ Yappli Analytics の データソース切り替え （DSメンバーが dbt 導⼊に集中できるよう）問い合わせ対応など 後段のタスクを通して、 dbt docs が⾃然と浸透🙌

GitHub Actions で dbt docs を GitHub Pages へ⾃動でデプロイ＆更新 ● 当時、dbt docs のテーブルやカラムの説明はまだほぼ空欄だった   ⬇ ● テーブル、クエリ、リネージグラフがサクッと確認できるだけでも⼗分役 ⽴った ● 早めにデータカタログとしての場所だけ作って運⽤を始めたおかげで、「こ こに情報を集約しよう」というモチベが発⽣ → ネクストアクションへ

社内ドキュメントにあった DB 仕様書を dbt docs へ転記 エンドユーザ 営業 エンジニア 営業データ サービスDB アプリログ DSグループ BigQuery CMS ダッシュボード Yappli Analytics 社内外ダッシュボード‧ データ提供 エンドユーザ‧ CS 営業‧ エンジニア trocco dbt 社内ドキュメントを探索していたら… サービスDBの仕様書が まとまっているのを発⾒

社内ドキュメントにあった DB 仕様書を dbt docs へ転記 エンドユーザ 営業 エンジニア 営業データ サービスDB アプリログ DSグループ BigQuery CMS ダッシュボード Yappli Analytics 社内外ダッシュボード‧ データ提供 エンドユーザ‧ CS 営業‧ エンジニア trocco dbt サービスDBのデータはほとんどの データ活⽤先で参照されている ↓ ここの仕様が dbt docs に載れば 有⽤性が⼀気に上がる！

社内ドキュメントにあった DB 仕様書を dbt docs へ転記 社内ドキュメントにあったDB仕様書 dbt docs ひたすら社内ドキュメント→ dbt docs へコピペ

社内ドキュメントにあった DB 仕様書を dbt docs へ転記 ● ヤプリでは毎⽉「YappdateDay」という改善に注⼒する⽇が設定されている ○ この⽇に取り組り組むことで通常業務との兼ね合いを考えずに作業可能に ➡ 素早く＆無理なく dbt docs の有⽤性を⼤幅に向上させることができた ● ⽇頃から関連他部署の社内ドキュメントも覗いていた ○ そのおかげで DB 仕様書という有益情報が得られた ➡ 関連他部署の情報も越境して取りに⾏ってみると良いことがあるかも

実際にやってみての所感

この資料をDSグループ内でレビューしてもらっていたとき… DSメンバー こんな嬉しいコメントが…！🙌

何やってたかまとめてみると…① PRレビュー時に dbt docs への 記載内容もしっかりレビュー 関連ドキュメントがあれば dbt docs へリンクを記載 トップページも 重要リンク集へカスタマイズ

何やってたかまとめてみると…② ⾔葉だけだとわかりにくいものは 画像も活⽤ 各カラムの description に データの⼀例を併記

何やってたかまとめてみると…③ データ構造が複雑なものは 図解して分かりやすく 図解しておいて良かったエピソード 私がスタンプカード分析を担当 ‧クエリを叩きまくってデータ構造を理解 ‧得られた理解を図解 ↓ その後、24新卒DSに同データを使って 分析してもらう機会が発⽣ ➡ 図が dbt docs にあったおかげで   データキャッチアップをスムーズに⾏えた

今後やっていきたいこと

● さらなる dbt docs 拡充 ● dbt docs 更新⼿順の改善 ● DSグループ外向けデータカタログの整備 今後やっていきたいこと

さらなる dbt docs 拡充 営業データ サービスDB アプリログ CMS ダッシュボード Yappli Analytics 社内外ダッシュボード‧ データ提供 dbt Source Mart (Table) Staging (View) Compo- nent (Table) dbtモデルのレイヤー分け

さらなる dbt docs 拡充 営業データ サービスDB アプリログ CMS ダッシュボード Yappli Analytics 社内外ダッシュボード‧ データ提供 dbt Source Mart (Table) Staging (View) Compo- nent (Table) dbtモデルのレイヤー分け 拡充済

さらなる dbt docs 拡充 営業データ サービスDB アプリログ CMS ダッシュボード Yappli Analytics 社内外ダッシュボード‧ データ提供 dbt Source Mart (Table) Staging (View) Compo- nent (Table) dbtモデルのレイヤー分け 拡充済 拡充 拡充 拡充 dbt-osmosisを使って、 上流テーブルのdescriptionを 下流テーブルへ流す

● 現状、通常のリリースと同じ⼿順で更新する運⽤ dbt docs 更新⼿順の改善 メリット: ● しっかりレビューできる ○ PRレビューを通した知⾒共有もできる デメリット: ● ⼩回りが効かない ○ 更新のモチベが削がれやすい ● dbt docs の⼿元確認が⾯倒 ○ 常時、開発エディタを⽴ち上げているわけでは ないので… より良い運⽤ができないか模索中…

DSグループ外向けデータカタログの整備 仕様書🛠 取説🔰 取説🔰