【dbt活用事例】データカタログから始める、AI活用可能なデータ分析基盤への道のり

はじめに

Analyticsチームの清水です。 今回はアナリティクスチームの業務紹介として、将来のAI活用を本格的に見据えたデータ基盤変革の第一歩、 データマートおよびデータカタログ整備の取り組みについてご紹介します。

現在のデータ基盤には、要所要所でViewやデータマートとなるテーブルが手動で作成されており、バージョン管理やメタデータ管理ができていない状態でした。 Analyticsチーム内だけであればコミュニケーションで補えますが、データを利活用する他部署のメンバーにとっては非常に使いにくい状態です。

そして、この課題は単なる業務効率の問題に留まりません。今後、Text-to-SQL(自然言語からのSQL生成)のようなAI技術を導入する上で、メタデータが整備されていないことは致命的な障壁となります。AIが高い精度で価値を発揮するには、AI自身が「どのデータが何を意味するのか」を正確に理解できる、整理・文書化されたデータカタログが不可欠だからです。

そこで私たちは、この「AI活用のための布石」として、既存で利用しているTROCCOと親和性が高く、コードベースでのバージョン管理やドキュメント生成機能に優れたdbtの導入を決定しました。

dbt自体は既にメジャーなツールで、環境構築やデータマートモデル作成に関しては情報がたくさんあると思いますので、検証ポイントに絞って書きました。 読んでくださる方に少しでも参考になれば幸いです。

TROCCOでdbtジョブを実行・ワークフロー化

TROCCOにはdbt連携機能があり、UIや自身でワークフロー管理を持たないdbt Coreでの構築において、特に役立ちます。 ※前提として、dbtプロジェクトをGit管理、かつTROCCO側でdbt連携設定済みの状態とします。

手順は簡単で、TROCCOの[dbt連携]->[dbtジョブ設定]で開いた画面で[新規作成]を押下します。

dbtジョブを設定するTROCCOの画面

最初のエリアにある名前やメモ、リソースグループ設定はdbtジョブに限らない一般設定ですね。ここは組織のポリシーに則り設定します。

新規作成画面(1/2)

次のエリアにあるのが、dbtリポジトリからクローンした環境でどんなコマンドを実行するかを決める設定です。

新規作成画面(2/2)

実行するコマンドやオプションは下図の通りです。 オプションで実行対象のモデルを選択したりdbt runする前にdbt testを実行できたり、柔軟に実行対象やフローを設定できます。

実行コマンドの選択肢
実行コマンドにつけるオプションの選択肢

実行コマンドやオプションを指定したら、[保存]を押下します。dbtジョブ設定でできるのはここまでで、dbtジョブを日次実行してデータマートを更新したい場合は、ワークフロー機能でdbtジョブを呼び出し、スケジュール実行します。

dbtのドキュメント生成機能を試してみた

データマート整備にdbtを使ってみる背景になった要素にドキュメント生成機能があります。 RedashのLoad Schemaによるテーブルやスキーマのリストが限界を迎えロードできなくなってしまったこともあり、 生成されたドキュメントのクオリティによっては社内向けに公開したいと考えていました。

そして、この構造化されたドキュメント(メタデータ)こそが、将来のText-to-SQL精度の鍵を握ります。AIがテーブルの意味やカラムの定義を正確に理解するための、いわば教師データそのものになるからです。

まずは典型的なコマンドをそのまま実行して、どんなものができるのか見てみます。 dbt docs generateでドキュメント生成して、dbt docs serveでローカルサーバーを起動します。

ブラウザには、dbtプロジェクト内にymlで作成した説明、カラム定義、参照先、ソースとなるSQLが非常に視覚的に表示できることがわかりました。(架空の情報を作る余裕がなく、ぼかしだらけですみません。雰囲気だけ掴めれば。。)

dbtドキュメント機能

ローカルサーバーで確認した結果、dbtで生成したドキュメントで社内のデータ利活用者がクエリを作成するのに必要な情報をわかりやすく表現できていると感じました。 そのため、次はこの生成されたドキュメントを社内に公開する手段を検討しました。

社内のデータ利活用者に公開したい

まず、dbtが生成するドキュメントは、デフォルト設定だとtargetフォルダに出力される、index.htmlcatalog.jsonmanifest.jsonの3点があればブラウザで閲覧可能です。 これらを静的サイトとしてホスティングする手段として、最も低コストなのがGitHub Pagesを利用することでしたが、環境の問題で可視性をprivateに設定できず、S3+CloudFrontで構築することにしました。

SREチームの皆様に側面支援をいただきながら、既存のterraformのリポジトリに必要なリソースを定義し、無事デプロイできました。 Analyticsチームの普段の業務ではやらないようなことができるのは非常に新鮮で楽しい経験になりました。

作成した構成

今回作成した構成は下図の通りで、GitHub Actionsを通してS3バケットにリソースをアップロードし、CloudFrontを用いて公開する形です。 ※社内アクセスに限定するため、CloudFront Functionsを用いてIPアドレスベースの制限を設定しています。

構成

おわりに・今後やりたいこと

今回dbtを用いて行ったデータマートとデータカタログの整備は、単なるドキュメンテーション作業の効率化ではありません。これは、来るべき「AIとの協業時代」に向けた、最も重要な布石です。

YAMLベースで管理された構造化メタデータは、Text-to-SQLの精度を飛躍的に向上させるポテンシャルを秘めています。現状では「どのテーブルに何の情報があるか分からず」AIに的確な質問をすることすら困難ですが、カタログが整備されることで、AIは「このビジネス用語に関連するデータはこれだ」と自律的に判断できるようになります。これにより、非エンジニアでも自然言語でデータ抽出が可能になる世界の実現を目指しています。

dbtによるデータマート整備はまだまだ検証の余地があり、この記事には多くを書けませんでしたが、ビューで持たせるorテーブルで持たせる、増分で蓄積するなどの変更をSQL部分を変更せずにConfigに設定するだけで切り替えられる点も非常に便利だと感じています。 今後はデータモデル構成のレイヤー分けや、AIを活用したレビュー・モデル生成の自動化なども検討しています。

そして今後のブログでは、今回整備したデータカタログを活用し、どうAIを活用できている状態にあるのかをお届けできるかもしれません。 ぜひご期待ください。