dbt-osmosisを利用して、なるべくコストを抑えつつ効率的にメタデータ管理を行なう

3行まとめ

  • ビジネスメタデータはデータ生成者にとってもデータ活用者にとっても重要
  • しかし、カラムのメタデータを同じ説明をあちこちに書いていくのは大変...
  • dbt-osmosisはビジネスメタデータの管理を省力化したり、自動化できる便利なツール

背景: メタデータの重要さとメタデータ管理の大変さ

データマネジメントにおいてメタデータの重要性は今さら説明するまでもないと思います。メタデータは以下の3種類が代表的です。

  • A: テクニカルメタデータ
  • B: オペレーショナルメタデータ
  • C: ビジネスメタデータ

BigQueryなどを利用している場合、AやBのメタデータについてはINFORMATION_SCHEMAや監査ログを使ってある程度機械的に付与されることが多いでしょう。一方、Cのビジネスメタデータはデータ管理をする人が地道に付与していくしかないことが多いです。スプレッドシートにみんなで書き込んでいったり、BigQueryのカラムのdescriptionに直接書いていったり、dbtのyamlに記載していくなど、組織によってやり方は色々あります。ビジネスメタデータの運用の大変さはいくつかの観点があると思いますが、今回は以下の2点を取り上げてみましょう。

なお、今回は(テーブルに対してではなく)カラムに対するビジネスメタデータを中心的に取り上げます。

大変さ1: 多段のデータレイヤーにどうメタデータを付与していくか

データ基盤の構成は俯瞰的に見ると、データレイク / DWH / martの3層の構造をしていることが多いと思います*1。全てのレイヤーに対して手動でメタデータを付与していくのはとても大変なので、現実的には優先順位を決めて取りかかることが多いでしょう。考えられる作戦としては、例えば以下のようなものがあると思います*2

  • A: データレイクから先に付与する
    • 元データの仕様が分からないと後段のデータ変換は正しくできないから、ここをしっかりやるべき
  • B: martから先に付与する
    • ビジネスユーザーからすると一番目にするのはmart
    • ここの説明書きをしっかりすることで間違った分析を防げるし、データに対する問合せコストも減らせる
  • C: レイヤーに依らず、利用が多いテーブルから優先的に付与する
    • 監査ログを元に、よく分析に利用されているテーブルがどれかを特定し、優先的にメタデータを付与する

ここでは、上記のどの方法がよいかは特に議論しませんが、共通していることはメタデータは複数レイヤーにまたがるということです。dbtなどのデータ変換を想像して欲しいのですが、以下のようなテーブル間の依存関係があったとしましょう。

graph LR;
  X --> Y;
  X --> Y';
  Y --> Z;
  Y' --> Z';

この依存関係を見たときに、以下のような悩みが発生します。

  • テーブルXのカラムにメタデータを付与すると、テーブルZやテーブルZ'中の同名のカラムに対してコピペでメタデータを付与していくか?
    • 手動で付与していくと面倒だし、運用が大変
  • テーブルZやテーブルZ'に対してのみメタデータを付与する場合、同じカラム名なのに異なるメタデータが付与されて困ることはないか?
    • メタデータのSSoTをどうする問題

理想的には、テーブルXのような下層のレイヤーに対してメタデータを付与して、テーブルYやテーブルZなど依存関係のあるものに対してメタデータを伝播させることができれば問題が解決できそうです。

大変さ2: 継続的な運用をどうするか

「大変さ1」を仮に何とかできたとして、それをどう継続的に運用していくか、という悩みも考える必要があります。先ほどの例のテーブルXのカラムのメタデータの管理は何とか運用できたとしても、その先のレイヤーであるテーブルYやテーブルZのカラムのメタデータの管理はどうやればいいでしょうか。うまくやれないとすると、ビジネスユーザーは古いメタデータを参照し続ける、といった危険性があります。

データレイクなど最小限のメタデータ付与の管理工数はもちろん必要ではあるものの、何らかの自動化を考える必要がありそうです。

dbt-osmosisでメタデータ管理を行なう

私は仕事ではdbtを使ってDWHやmartを構築することが多いので、これまでに上げた2つの大変さを解決できるツールを探したところ、dbt-osmosisというツールがよさそうに思いました。

Most of the time, you don't need to write YAML by hand. dbt-osmosis automates the process of generating YAML files for you. You can focus on what matters. Source yaml files are generated from your database. Schema yaml files are generated from your dbt models with inherited metadata.

概要としては↑の通りですが、dbt-osmosisがメタデータ管理をどう効率化してくれるか説明します。

依存関係を考慮したメタデータの伝播

dbt-osmosisは名前の通りdbtを利用したツールです。dbt内で記述されたモデル内の依存関係(refなど)を利用*3して、データレイクなど依存元のメタデータをDWHやmartなど依存先にメタデータを伝播させることができます。より具体的には、DWHやmartのyamlファイルの自動生成 / 更新をしてくれます。

よって、基本的にはデータレイクを中心にカラムのメタデータを付与していくと、DWHやmartにも機械的にメタデータが反映されていきます。DWHなど中間レイヤーで定義したディメンションやメトリックがあった場合も、そこに書いておけばそこを参照しているmartにメタデータを反映できます。楽ができて助かる。

「メタデータの伝播」と言っているのは、以下の動画を見てもらうと雰囲気が伝わるかと思います。

自動化による継続的な運用

dbt-osmosisはコマンドラインツールなので、自動化もしやすいです。mart上に新しいモデル(sqlファイル)ができたら、データレイクなどのカラムのdescriptionも考慮したyamlファイルを生成し、CI上で自動でgitのcommitに積むようにする、ということも可能でしょう。頑張って人間がメンテナンスすべきところは

  • データレイク相当のレイヤー
  • ロジックの定義元

など大分限定されるため、自動化と合わせて継続的な運用がかなりやりやすくなると感じました。

基本的な使い方

使うのもかなり簡単です。dbt_project.ymlに、以下のように記述します。

models:
  my_dbt_project:
    +persist_docs:
      relation: true
      columns: true
    marts:
      +materialized: table
      +dbt-osmosis: "{model}.yml"

dbt-osmosisが具体的な設定ですが、シンプルですね。上記は1つのsqlに対して、それに対応する1つのymlファイルを生成する設定になっていますが、生成するymlの命名規則やパスの設定などは割と柔軟に設定できます。

設定はこれだけなので、仮にdbt-osmosisがメンテナンスされなくなったとしても、簡単に捨てることができます。導入のハードルを下げてくれるのでいいですね。dbt-osmosisを捨てたとしても、yamlにあるメタデータは引き続きメタデータとして資産にできます。

動かすときは以下のコマンドを実行します。

% dbt-osmosis yaml refactor

↑はプロジェクト全体で実行になるので、実際は--fqnオプションを付けて対象を絞って実行するのがオススメです(dbtでいうところのselectorのことだと思うとよい)。

% dbt-osmosis yaml refactor --fqn marts.monthly_sales

使ってみた感想

(以前の)リポジトリのREADMEに

dbt-osmosis yaml management is extremely powerful and ready to use as-is. To get familiar, you should run it on a fresh branch and ensure everything is backed in source control. You'll wonde r why its not in dbt-core. Enjoy!

と書いてあって、確かにdbtのユースケースとしてはどんぴしゃで欲しい機能の一つではあるし、簡単に導入もできるので、結構オススメしやすいなと思いました。ビジネスメタデータの運用は結構大変なことが多いため、dbt-osmosisを使って楽をしていきたいなと思います。

dbtはコミュニティが活発でこういうツールがどんどん出てくるのは楽しいですね。あと先日、ちょっとだけリポジトリにcontributionもしましたw。

また、dbt-osmosisは先日のdbt Tokyo Meetup #5でも言及されていたので、気になる人は動画を見てみるといいかもしれません。

*1:もっと複雑なのはいくらでもあるけど、ここではとにかく多段である前提で書きます

*2:データ基盤が複数チームから構成されている場合、これらが並行に進む場合ももちろんあると思います

*3:利用しやすいように作者がwrapperも作っている