dbtのセマンティックレイヤーは一度書けば、どこでもクエリから使えるようになる
先日、dbtの公式から以下のような記事が投稿されました。
非常に興味深い内容だったので、多くの人にみてもらいたくひとまず翻訳記事をぱっと書いてみます。
サマリ
- ビジネスメトリクスの管理を特定のプロダクトから開放し、バージョン管理下に置きながら様々なBIから利用できるようにしようとしている取り組み（ヘッドレスBI）
- BIからの利用はSQL Proxy（+ dbt Sever）を介して、ライブSQL変換をされたクエリがDWHプロダクトに問い合せされ、データがdbt Server経由でBI側に返ってくる
- アドホックや高度な分析はDWHプロダクトに今まで通り直接アクセスして利用する（dbtで管理されたモデルでデプロイされたデータ達に）
以下はこういう世界観が生まれるんじゃないかというイメージ図（非公式）
以下翻訳。
dbtのセマンティックレイヤーは一度書けば、どこでもクエリから使えるようになる
10月のdbtのイベント「Coalesce」でdbt Semantic Layerの発表を控えています。dbt Semantic Layerでは、コアとなるビジネスメトリクスをバージョン管理下で一度定義すれば、どこからでも問い合わせができるようになります。
dbt Labs Developer AdvocateのCallum McCannは、dbtのメトリクスを使い始めるための関連記事を書いていますが、この機会に私たちが何を作っているか、誰のために作っているか、そして最終的にどのようにモダンなデータスタックに新しいレベルのコラボレーションと一貫性をもたらすと考えているかについて、より詳しくお伝えしたいと思います。
一貫性を持たせる
初めてのOLAPキューブを覚えています。Tristan、Jeremy、そして私は、2017年にコンサルティングプロジェクトに取り組んでおり、コアなビジネスメトリクスの一貫したレポートについて頭を悩ませていました。私たちは、基本的に OLAP キューブというアプローチにたどり着き、dbt モデルを構築してビジネス指標を 1 日単位まで集約し、それらを「analytics.metrics」という大きなテーブルに統合しました。特定の日の指標値を問い合わせるには、次のようなクエリを実行します。
これは、正しい考えでしたが、間違った実装でした。しかし、dbtモデルで事前に集計された指標は、柔軟性とレポート作成において悲劇的な制約があります。次元性（どれだけ深くメトリックをスライス＆ダイスできるか）とユーザビリティ（結果としてのメトリックテーブルをどれだけ直感的にクエリできるか）の間で不快なトレードオフをしなければならず、実装を本当に完成させることはできませんでした。しかし、私たちは、社内のビジネス・メトリックのために独自のメトリック・テーブルを構築することを止めませんでした。これらの極めて重要なメトリックの一貫性と精度の価値は、私たちのアプローチのコストを上回るほど十分なものでした。
両立させる
データにおいては、ほとんどがトレードオフの関係にあります。私たちがdbt Semantic Layerで答えようとしているのは、「もし精度と柔軟性のどちらかを選ぶ必要がなかったらどうなるか？データウェアハウスにあらかじめ集約されたテーブルを使い、次元を失うことなく（あるいは次元の爆発に対処することなく）、バージョンコントロール下でビジネス指標を定義することができるデータ基盤とはどのようなものでしょうか？さらに、このインフラを簡単にプラグイン化し、すでにデータウェアハウスへの問い合わせ方法を知っている既存の豊富なデータツールと互換性を持たせるにはどうしたらよいでしょうか。
私たちがたどり着いたアプローチは、とても賢いものです。Callumのブログ記事で詳しく説明されていますが、大まかに言えば、OLAPキューブをクラウドデータウェアハウス時代に持ち込むということです。社内では、dbtのメトリクスを使用して、会社レベルのOKRを追跡し、報告しています。つまり、すべてのKey Resultの定義はバージョン管理されており、メトリックの定義にロジックの変更があると、社内で使用しているすべての異なるデータツールに伝搬されるのです。
以下は、時系列でのメトリクス値のクエリを実行したときのイメージです。
dbtのコードを書いたことがある人なら見覚えがあるはずです。これはmetricsというパッケージの中のcalculateというマクロを呼び出すSQLクエリです。私たちは、データウェアハウスに送られるクエリをライブコンパイルできる新しいデータ基盤（dbtサーバーとSQLプロキシ）を構築することで、このような体験を可能にしました。このアプローチでは、データウェアハウスに集約されたメトリックデータは存在しません。その代わり、dbtプロジェクトにあるバージョン管理されたメトリクス定義に基づいて、dbt_cloud_weekly_active_usersを計算するメトリクスクエリをライブコンパイルしています。実際にどんな感じなのか、今日はご紹介します。
統合化
dbtは相互運用可能なツールのエコシステム（モダンデータスタックと呼ばれることもある）に参加しており、機能的な分析業務を構築するためのベストオブブリードのアプローチになっています。分散化されたデータスタックには多くの利点がありますが、ビジネスロジックを断片化し、システム間の依存性を覆い隠すことにもなりかねません。私たちは、中核となるビジネス・エンティティ、関係、測定基準に関する共有定義に基づいてこれらのツールを結びつけることができるスタックのレイヤーを欠いています。
この問題を解決するために、私たちはBI、データサイエンス、データロード、その他倉庫に接続されたデータアプリケーションにフォーカスしたデザインパートナーと共に、dbt Semantic Layerの統合に取り組んでいます。つまり、dbtセマンティックレイヤーは、これらのベストオブブリードのデータツールを、より統一された、断片的でないスタックに結合する接着剤のような役割を担っているのです。このような未来像に私たちは大きな期待を寄せていますが、その実現には時間がかかると思われます。
メトリクスの先にあるもの
今日、dbtはデータモデルを生成する変換のグラフについてはよく知っていますが、これらのテーブルが互いにどのように関連しているかについては、ほとんど知りません。確かに、dbtはfct_transactionsとdim_customersの両方のモデルを構築できますが、customer_idカラムで結合していることも知っておく必要があるのではないでしょうか？そして、その情報をBIツールやデータカタログ、その他のウェアハウスに接続されたデータアプリケーションに公開することはできないのでしょうか？dbtセマンティックレイヤーは、このような具体的なインターフェイスを提供します。ここでいう「セマンティック」とは、システムの個々のパズルピース（テーブルやビュー）と、それらがどのように組み合わされるか（エンティティやメトリック）についての作業知識を指します。
このビジョンを実現することで、最新のデータスタックにおける柔軟性と機能を拡張しながら、精度と一貫性を向上させることができます。新しいツールへの参入障壁を下げ（オンボーディングのステップ1は、もはや「データモデルの再定義」ではありません）、データツールは、中核となるビジネス指標やよく理解されている意味的実体の再定義をサポートするために無数のワークフローを作るのではなく、独自の価値提案に集中できるようにすることで、これを実現することができるのです。
データのセマンティックモデルを想像したのは、地球上で私たちが初めてではありません。セマンティックモデルの作成と探索をサポートする分析製品はすでにいくつかあります。Looker（LookML経由）とPowerBI（DAX/MDX経由）の両方が包括的で強化されたセマンティックモデルを提供していますが、どちらもこの分野の他の分析ツールとはうまく連携していません。セマンティックレイヤーが最大限に役立つためには、多くの異なるツールと統合され、一言で言えば「ヘッドレス」でなければならないと考えています。dbtは、そのような意味で、この空間を占めるのに極めて適していると考えています。
- オープンソースであること
- 現代のデータスタックにおいて独立したユビキタスな存在であること
- 将来の発展を見守ることができる、活気に満ちた健全なコミュニティによって支えられていること
ご協力いただけること
私たちはこの問題領域に敬意を払っていますが、このビジョンを一晩で実現することはできません。私たちの最初のステップであるdbt Semantic Layerの立ち上げは、今年の10月にCoalesceで行われます。初期のメトリクスは、完全なセマンティック関係（モデル間の結合、仮想化された次元など）をサポートしないかもしれませんが、これは私たちがセマンティックレイヤーを長期的に活用する上で最も関心のある方向性です。
しかし、そこに到達するためには、皆さんの協力が必要なのです。すでに多くの方がこのdbtセマンティックレイヤーベータサインアップフォームを提出されていますが、私からの返事はまだでしょう。今後数週間でdbtセマンティックレイヤー統合のプライベートベータを開始する予定で、このリストにある人たちに近々連絡する予定です。それまでは、dbt Slackの#dbt-metrics-and-serverチャンネルで、良いアイデアやホットな話題を提供し続けてください。私たちはいつでも皆さんからのご意見をお待ちしていますし、私たちが作っているものを披露するのが待ち遠しいのです。
以上翻訳終了。
Metrics活用してみたいけど、利用できるBIがLightdashはあるけどまだまだ少なくて社内に導入するのちょっとまだ遠いかな。。って思っていたところにジャストフィットなソリューションが開発されていきそうでとてもワクワクします。