こちらの記事が昨日 Twitter で流れて来ました：
Dataform と見間違えて一瞬混乱しました。。（余談：Dataform は dbt と同じく SQL をベースにパイプラインを構築できるサービスで、Google Cloud に買収されました）。上の記事は Transform Data 社についてで、dbt Labs 社と Transform Data 社の買収について、最終契約書が交わされたという内容です。
dbt は半年ほど前に少し勉強した程度でほとんど忘れてしまっているので、復習がてらまとめます。
買収の目的: dbt のセマンティックレイヤの強化
上記記事の中において
the capabilities of Transform’s MetricFlow will be merged with the dbt Semantic Layer
という一文があり、Transform Data 社の MetricFlow というサービスが dbt のセマンティックレイヤに統合されるようです。
dbt セマンティックレイヤとは
dbt セマンティックレイヤは現在パブリックプレビューの段階で、マルチテナントかつ北アメリカでホスティングされているdbt Cloudアカウントでのみ利用できます。パブリックプレビューを終えてGAとなった後は、dbt Cloud Team と Enterprise の有料プランでのみ利用可能となるようです。パブリックプレビュー中にセマンティックレイヤの機能を利用できるデータプラットフォームは Snowflake のみです。
「売上」や「顧客数」などの重要なメトリクスを dbt のセマンティックレイヤで定義して集約管理することで、定義のブレを起こらないようにし、意思疎通やデータ活用をしやすくします。メトリクスは YAML ファイルで記述することができます。
version: 2 metrics: - name: expenses label: Expenses model: ref('orders') description: "The total expenses of our jaffle business" type: sum sql: amount / 4 timestamp: order_date time_grains: [day, week, month, year] dimensions: - customer_status - had_credit_card_payment - had_coupon_payment - had_bank_transfer_payment - had_gift_card_payment filters: - field: status operator: '=' value: "'completed'"
Quickstart | dbt Developer Hub より抜粋
Available integrations | dbt Developer Hub より抜粋
この図を見ると dbt Cloud がメトリクスを集計・保存するように見えますが、dbt Cloud ではデータを保存・キャッシュすることはないと明記されています。ドキュメントからの推測ですが、おそらく上記 YAML で宣言したメトリクスが SQL に変換され、dbt の Metadata API を経由して SQL 実行し、実行結果を連携した外部ツールへ転送する仕組みのようです（誤っていたら指摘してください）。
MetricFlow を dbt セマンティックレイヤへ統合させる
Transform Data 社の買収について別の記事を紹介します。ブログ形式で、どういった経緯でこの買収が行われたのかが詳しく紹介されています：
この冒頭で、Transform社のコアテクノロジーである MetricFlow に触れられています。MetricFlow はメトリクスの定義、そしてそれをコンパイルしてSQLへ変換する最高のツールであり、この高品質のSQLを生成することがセマンティックレイヤの中で最も難しいと紹介されています。
先ほど上で推測した、YAMLをSQLへ変換するのではという推測が当たっていました。この変換部分を今後 MetricFlow やその開発者たちと協力し、より使いやすく機能拡張していくようです。
データ活用した業務を行なった方なら分かると思いますが、メトリクスの齟齬やデータ関連用語の統一は非常に大きな課題です。「売上」といっても総売上だったり経常利益で考えるケースもあるかもしれませんし、「ユーザ数」といえば述べ人数なのか、ユニークユーザ数なのか、Webサービスであればログインしているユーザのみ対象とするのかなど、TPOに応じてすぐに変わってしまいます。コミュニケーションコストが上がるだけでなく、誤ったメトリクスを利用することで実害が生じてしまう可能性も考えられます。
dbt Labs ではベンダーロックインを防ぎながら、dbt でメトリクスを定義することで様々なツールでそのメトリクスを利用できるエコシステムを構想しているようです。日本では近年盛り上がりつつある dbt 界隈ですが、データ変換処理を SQL で書きやすくするだけの ETL ツールではなくなりつつあるのかもしれません。
