DevelopersIO 2023でコードでデータ分析に関わる指標を管理できる「Semantic Layer」についてLookerとdbtの違いを話しました #devio2023

さがらです。

2023年7月8日に開催されたDevelopersIO 2023 Day2で、コードでデータ分析に関わる指標を管理できる「Semantic Layer」についてLookerとdbtの違いを話しました。

本記事では、このセッション内容について簡単にまとめます。

登壇内容

概要

昨今Semantic Layerの分野が注目されておりますが、Lookerもdbtも同様の機能を提供しているため、Semantic Layer自体について簡単な説明をした後、以下8つの観点でLookerとdbtのSemantic Layerの違いについて話しました。

• 定義の方法
• 指標の参照方法
• クエリの最適化
• キャッシュ
• WINDOW関数
• 連携可能なBIツール
• 連携可能なデータカタログ
• 各製品独自の強み

この違いを述べたあと、どういう考え方でSemantic Layerの製品を選定すればいいのか、3つの考え方についても話しました。

詳しくは、以下の登壇資料に記しているので、ぜひこちらをご覧ください！

登壇資料

参考URL

Looker

• LookMLの用語と概念
• 対象集計（Symmetric aggregates）について
• 集計認識（Aggregate awareness）について
• Lookerのキャッシュをきちんと理解する
• Lookerを使いこなすための必須機能「テンプレートフィルタ」を試してみる
• Looker Modeler のご紹介: BI 指標のための信頼できる唯一の情報源
• Select Star : Data Lineage
• access_grant
• access_filter

dbt

• The new dbt Semantic Layer spec: the DNA for our vision
• The dbt Semantic Layer: what’s next
• Build your metrics
• Introduction to MetricFlow Concepts

質疑応答

セッション後、視聴いただいた皆様からいくつかご質問を頂いたので、その内容についてまとめておきます。

Q：dbtはすでに使っているのですが、dbtやLookerと連携する最近のデータカタログの特徴って？

Third-Gen Data Catalog（あるいはData Catalog 3.0）と呼ばれるような、Atlan、Secoda、Select Star、CastorDocなどのデータカタログはdbtとLookerどちらとも連携可能なので、このあたりのデータカタログの特徴について述べます。

• テーブルだけでなく、BIツールのダッシュボード、SQLクエリ、JupyterノートブックなどあらゆるData Assetsを管理対象とする
• 組織内のすべてのData assetsに関して信頼できる唯一の情報源であること
• ただメタデータを溜めて見せるのではなく、クエリログから列レベルのリネージを自動的に生成したり各Data assetsごとの人気度合いも表示するなど、メタデータを活用していく（Active Metadataの考えが該当すると思います）
• 組織が日常的に使用するワークフローとのシームレスな連携(簡単に言うとSlackやJIRAなど、業務で日常的に使用するツールとの連携)

以下は参考リンクです。

Q：Semantic Layerって、どういうプロセスでクエリが発行されるの？

大まかに以下のようなステップです。

1. Semantic Layerを参照するBIツールなどで、Semantic Layerで定義された指標を呼び出す
2. リクエストがSemantic Layerに届き、選択されたMetrics(Measure)・Dimensionなどからクエリを生成
3. 生成したクエリをDWH/DBへ送信
4. DWH上で処理され、BIツールに結果が返る（この時、Semantic Layer上に結果がキャッシュとして残ることも）

Q：DWH上でデータマート等で指標を管理することもできると思うが、Semantic Layerを使うメリットとは？

私の持論多めですが、「運用」の面での効果が一番大きいと思っています。

DWH上のデータマートのテーブルなどで指標を管理しようとすると、指標を管理する大量のデータマートのテーブルが発生したり、自社開発のアプリケーションから指標を参照するときに参照方法に制約があって開発しているアプリのコード上で指標の集計方法を記述しないといけず指標の管理とガバナンスに問題が出てくる、ということがあると思います。

こういったときにSemantic Layerがあれば、仮想的なデータモデル上で指標を管理するため大量のデータマートのテーブルは発生しませんし、仮想的なデータモデルのためクエリ負荷が心配されるかもしれませんが選択された指標に応じて最低限のカラム選択と結合処理を行うようになっています。また、開発しているアプリのコード上で集計方法を定義することなく、Semantic Layerで集計方法を定義するため指標の管理が楽になるだけでなく、社内向けのBIツールからの参照も楽になるため、どのツールからでも同じ定義の指標を参照することができるようになります。

また、データカタログの辞書機能に指標を自動登録したり、DWHに負荷がかからないようなキャッシュの機能も、Semantic Layerには備わっております。

最後に

登壇時にも述べましたが、LookerでもdbtでもSemantic Layerはこれから多くのアップデートがあります！

Semantic Layerをうまく導入することで、社内のデータガバナンスを保ちつつ、より有用なデータ分析・活用ができるようになります。

ぜひ皆様のデータ基盤に合って要件を満たすSemantic Layerを見つけてください！