「コードでデータ分析に関わる指標を管理できる ”Semantic Layer”、dbtとLookerで何が違うの？」あなたのこの疑問、解消します

2023/7/7~2023/7/8に開催された「DevelopersIo 2023」で登壇した際の資料です。

1. 「コードでデータ分析に関わる指標を管理できる ”Semantic Layer”、dbtとLookerで何が違うの？」あな たのこの疑問、解消します 2023/7/8 アライアンス事業部 相樂悟
2. 氏名 相樂 悟 (サガラ サトシ) 所属 クラスメソッド株式会社 アライアンス事業部 役割 Modern Data Stackソリューション　テックリード 自己紹介 2
3. １．Semantic Layerとは ２．Lookerとdbtの概要 ３．Semantic Layerの観点で見た、Lookerとdbtの違い ４．各製品の選定時の考え方 ５．最後に アジェンダ 3
4. １．Semantic Layerとは ２．Lookerとdbtの概要 ３．Semantic Layerの観点で見た、Lookerとdbtの違い ４．各製品の選定時の考え方 ５．最後に アジェンダ 4
5. • データを用いたビジネス指標の定義を一元管理するレイヤー ◦ 統一された定義の元に、データ活用を行うことが出来る Semantic Layerとは レポーティング データアプリ データカタログ 社内のデータ 5 DWH (データウェアハウス) Semantic Layer 加工 顧客ランク = case … 総売上 = sum(...)
6. • 組織内のデータを用いるビジネス指標の定義を統制できる ⇛ データガバナンスの向上・アウトプット時の品質向上 例：複数のフィールドを組み合わせた指標をBIツールで表現しようとしたとき Semantic Layerのメリット Semantic Layerがある場合 DWH Semantic Layer 【30歳以上の会員の総売上】 「年齢」列： >= 30 「売上」列：SUMで集計 必ず同じグラフに Semantic Layerがない場合 DWH 違うグラフになってしまう 【30歳以上の会員の総売上】 「年齢」列： > 30 「売上」列：SUMで集計 【30歳以上の会員の総売上】 「年齢」列： >= 30 「売上」列：SUMで集計 6
7. • 製品の仕様に沿ったYAMLベースの「コード」を定義するのが主流 • コードで定義するため、Gitを併用することが多い ◦ ブランチの切り分けによる開発環境と本番環境の分離が可能 Semantic Layerってどう定義する？ 7 Lookerの例 dbt Semantic Layerの例
8. １．Semantic Layerとは ２．Lookerとdbtの概要 ３．Semantic Layerの観点で見た、Lookerとdbtの違い ４．各製品の選定時の考え方 ５．最後に アジェンダ 8
9. • LookMLというYAMLベースの言語で各指標の定義をコード管理し、 データガバナンスを保ちつつ可視化できるBIツール • LookMLで定義した指標をAPIで参照することができるため、 BIツールでありながら、Semantic Layerとしての側面も持つ • 2023年4月に、Semantic Layerに特化した「Looker Modeler」を発表 ※Looker Modelerの詳細は、まだ発表されていない Lookerとは 9
10. • 「BIツール」の側面から生まれたSemantic Layer Lookerの「Semantic Layer」における立ち位置 10 レポーティング等 社内のデータ DWH (データウェアハウス) Semantic Layer 加工 顧客ランク = case … 総売上 = sum(列名) Looker Looker Modeler
11. • dbt Labs社が開発するDWH内のデータ変換に特化したサービス SELECT文だけで開発でき、自動テストやドキュメント化もできる • 2022年にdbt Labs社独自の「dbt Semantic Layer」をリリース ・Metricsの定義：dbt-metricsを使用 ・Semantic Layerに必要なプロキシサーバーなど：dbt Cloud上で展開 • 2023年2月にdbt Labs社が、OSSのSemantic Layerである「MetricFlow」を開 発するTransform社を買収した。MetricFlow統合後のリリースはまだ 　・Metricsの定義：dbt-metricsが廃止となり、dbt-metricflowに置き換わる ※dbt Core v1.6~ dbtとは 11
12. • 「データ変換」の側面から生まれたSemantic Layer dbtの「Semantic Layer」における立ち位置 12 レポーティング等 社内のデータ DWH (データウェアハウス) Semantic Layer 加工 顧客ランク = case … 総売上 = sum(列名) dbt dbt Semantic Layer
13. １．Semantic Layerとは ２．Lookerとdbtの概要 ３．Semantic Layerの観点で見た、Lookerとdbtの違い ４．各製品の選定時の考え方 ５．最後に アジェンダ 13
14. 振り返り：Semantic Layerに該当する機能がある2製品 14 レポーティング等 社内のデータ DWH (データウェアハウス) Semantic Layer 加工 顧客ランク = case … 総売上 = sum(列名) dbt dbt Semantic Layer Looker Modeler Looker
15. 今日のメイントピック 15 レポーティング等 社内のデータ DWH (データウェアハウス) Semantic Layer 加工 顧客ランク = case … 総売上 = sum(列名) dbt dbt Semantic Layer Looker Looker Modeler ・LookerのSemantic Layer ・dbtのSemantic Layer 何が違うの？？
16. 以下の観点で、dbtとLookerのSemantic Layerを比較 ・定義の方法 ・指標の参照方法 ・クエリの最適化 ・キャッシュ ・WINDOW関数 ・連携可能なBIツール ・連携可能なデータカタログ ・各製品独自の強み 観点 16
17. • Looker ◦ 2023年7月8日時点で最新のLooker 23.10の仕様を参考にする • dbt Semantic Layer ◦ 基本は、2023年6月に公開された最新ドキュメントを参考にする ▪ 参考：The new dbt Semantic Layer spec: the DNA for our vision ▪ 参考：Build your metrics ◦ 上述の情報に無いより細かな仕様については、買収前のMetricFlow のドキュメントや、dbt Labs社のブログを参考にする ▪ 参考：The dbt Semantic Layer: what’s next ▪ 参考：Introduction to MetricFlow Concepts 前提条件：各製品の情報について 17
18. 定義の方法 18
19. • Model：使用するデータベースや、後述するExploreを定義 • Explore：View同士のJOINや、Explore全体に関わるフィルターの定義 　　　　 ※Lookerを介してグラフを作成する時はExploreがベースとなる • View：dimensionとmeasureを各テーブルごとに定義 • dimension：１～複数カラムを用いて、「分析の軸」を定義 • measure：１～複数カラムを用いて、「集計指標」を定義 定義の方法：Looker 19 Model Explore View① View② 顧客ランク(dimension) 顧客ID(dimension) 総売上(measure) 顧客ID(dimension)
20. 定義の方法：dbt Semantic Layer 20 ※参考情報：公式Doc「About MetricFlow」「Joins」 • semantic_models：dbtのModel(1つのテーブルやビュー)と1:1で紐づき、　　　　　 entities,dimensions,measuresを含む基本オブジェクト • entities：他のsemantic_modelsと結合する際のキーを定義 • dimensions：１～複数カラムを用いて、「分析の軸」を定義 • measures：１～複数カラムを用いて、「集計指標」を定義 • metrics：エンドユーザーが参照する指標をmeasureを用いて定義 semantic_ models① 顧客ランク (dimensions) 顧客ID (entities) 総売上 (measures) semantic_ models② 顧客ID (entities) ランクAの総売上 (metrics) ランクBの総売上 (metrics)
21. 指標の参照方法 21
22. • 基本は、事前に定義済みのmeasureとdimensionを選択する形式 • Looker・他のBIからの参照 ◦ ユーザーが必要なdimensionや measureを選択する形式 • APIを用いた参照 ◦ Looker APIというREST APIに加えて、 Ruby、Python、TypeScript、JavaScriptのSDKもある 指標の参照方法：Looker 22
23. • 基本は、事前に定義済みのmetricsとdimensionsを選択する形式 • CLI、SQL、JDBC、GraphQL、様々な方法で参照できる予定 ◦ ODBC、REST APIによる参照も開発予定 • 参考：Pythonを用いて、MetricFlowで定義された指標を参照する例 指標の参照方法：dbt Semantic Layer 23 #Query Metrics df = mql.query(["gross_sales"], ["metric_time", "customer__billing_country"]) #Format results and print first 5 rows df.head().style.format({'gross_sales':'${0:,.0f}'}) ※参考情報：公式ブログ「The dbt Semantic Layer: what’s next」、買収前のMetricFlowのドキュメント「Querying Metrics using Python」
24. クエリの最適化 24
25. • 選択したmeasure・dimensionに応じて、 最低限のView（１テーブル・ビュー）同士を結合する • 結合によるレコード膨張(fan-out)を 防ぐようにクエリを都度書き換えてくれる 「Symmetric Aggregates」 • クエリ内容に応じ参照するテーブルを 動的に切り替える「Aggregate Awareness」 クエリの最適化：Looker 25 ※画像引用元：公式ドキュメント「Aggregate awareness」
26. • 選択したmetrics・dimensionsに応じて、 最低限のsemantic_model(１テーブル・ビュー)同士を結合する • ユーザーが定義したentitiesの 「Primary・Foreign・Unique」に応じて、 レコード膨張(fan-out)が起こりうる 組み合わせの場合は結合させない クエリの最適化：dbt Semantic Layer 26 ※参考情報：公式Doc「About MetricFlow」「Joins」、買収前のMetricFlowのドキュメント「Join Logic」
27. キャッシュ 27
28. • Lookerで実行されたクエリの結果は、Lookerに保持されるため、 同じクエリが投げられたらキャッシュから結果を返す ⇨DWHに負荷がかからない！ • キャッシュの定義もLookMLで行うため、自由に保持期間を定義可能 ◦ sql_trigger ▪ 定期的に指定したクエリを実行し、値が更新されたらキャッシュを更新 ◦ max_cache_age ▪ 一度キャッシュ作成後、一定時間経過後にキャッシュを削除 キャッシュ：Looker 28 datagroup: datagroup_name { sql_trigger: SELECT MAX(id) FROM table;; max_cache_age: "24 hours" }
29. • MetricFlow統合後の初リリース時にはキャッシュ機能はない予定 • しかし、キャッシュ機能の開発予定はあり ◦ 第１弾：ユーザー側で指定したメトリクスについて、 　　　　キャッシュを保持する仕組み ◦ 第２弾：頻繁にリクエストがあるMetricsを分析し、 　　　　ユーザーへの通知や自動キャッシングをしてくれる？ 　　　　（詳細未定） キャッシュ：dbt Semantic Layer 29 ※参考情報：公式ブログ「The dbt Semantic Layer: what’s next」
30. WINDOW関数 30
31. • 「Derived table」という”Looker上で定義できる仮想テーブル”を 用いて、WINDOW関数を用いたSQLを記述する必要あり • WINDOW関数の対象となるデータを動的に変更したい場合には、 テンプレートフィルターというLookerの中でも高度な機能が必要 WINDOW関数：Looker 31 derived_table: { 　sql: 　SELECT 　　"Order ID" as order_id 　　, ROW_NUMBER() OVER (PARTITION BY "Customer ID" ORDER BY "Order Date") as user_order_sequence_number 　FROM "order";; }
32. • MetricFlow統合後の初リリース時にはWINDOW関数の機能はなし • しかし、廃止されるdbt-metricsではWINDOW関数に対応した Secondary calculationsの機能があり、再導入予定と公式ブログに 表記あり ◦ 下図は、Period over Period(ある指標について別の期間の値と比較する)の例 WINDOW関数：dbt Semantic Layer 32 ※参考情報：公式ブログ「The dbt Semantic Layer: what’s next」DevelopersIO：相樂がSecondary calculationsを検証したブログ select * from {{ metrics.calculate( metric('revenue'), grain='week', secondary_calculations = [ metrics.period_over_period( comparison_strategy = 'difference', interval = 1, alias = 'week_over_week' ) ] ) }} 前週との差を 出している
33. 連携可能なBIツール 33
34. • まず、Looker自体もBIの機能を持つ ◦ LookerのBI機能は、インスタンス上のロゴを非表示にして公開、アプリ へのグラフの埋め込みなど、社外への公開が強み • LookerをSemantic Layerとして使用した際に対応するツール ◦ GA済み：Microsoft Power BI、 　　　　 Looker Studio、 　　　　 Google Spreadsheet ◦ これから：Tableau、 ThoughtSpot 連携可能なBIツール：Looker 34 ※参考情報：公式ブログ「Looker Modeler のご紹介: BI 指標のための信頼できる唯一の情報源」
35. • 2023年7月8日時点、MetricFlow統合後のdbt Semantic Layerと ネイティブに接続できるBIツールは未定 • 参考：2022年リリースのdbt Semantic Layerと接続できるBIツール ◦ ネイティブに接続可能なBIツール ▪ Lightdash、Preset Mode(2023年6月にThoughtSpotが買収) ◦ Tableauからも接続は可能だが、カスタムクエリが必須 連携可能なBIツール：dbt Semantic Layer 35
36. 連携可能なデータカタログ 36
37. • Lookerとの連携に対応したデータカタログの例 ◦ Atlan、Select Star、Secoda、CastorDoc、OpenMetadata、等 • できること ◦ Lookerで定義されたDescriptionなどのメタデータの確認 ◦ 元テーブル～View～Explore～ダッシュボード、の列レベルリネージ ※右図はSelect Starの例 連携可能なデータカタログ：Looker 37
38. • 2023年7月8日時点、MetricFlow統合後のdbt Semantic Layerと ネイティブに接続できるデータカタログは未定 • 参考：2022年リリースのdbt Semantic Layerとデータカタログの連携 ◦ Secodaの例：データカタログのGlossary(社内用語の辞書)に自動登録 連携可能なデータカタログ：dbt Semantic Layer 38
39. 各製品独自の強み 39
40. • User Attributeで独自のユーザー属性を作成し、ユーザーごとに 任意の値を定義することで、アクセス可能なデータの制限が可能 • 行レベルセキュリティ ◦ 「access_filter」とユーザーごとの属性情報を用いて、 どのレコードを参照させるかを絞り込み可能 • 列レベルセキュリティ ◦ 「access_grant」とユーザーごとの属性情報を用いて、 どのdimension・measureを使用させるか制御可能 各製品独自の強み：Looker 40
41. • dbtで開発したモデルに対し、直接Semantic Layerを定義できる ◦ 変換処理の開発～Semantic Layerの定義まで一貫した開発が可能 • 参考：2022年リリースのdbt Semantic Layerによるデータリネージの例 各製品独自の強み：dbt Semantic Layer 41 ※参考情報：公式ブログ「The dbt Semantic Layer: what’s next」 dbtで定義された各種データモデル (SELECT文が記述されたSQLで定義されている) dbtで定義されたmetrics
42. １．Semantic Layerとは ２．Lookerとdbtの概要 ３．Semantic Layerの観点で見た、Lookerとdbtの違い ４．各製品の選定時の考え方 ５．最後に アジェンダ 42
43. 選定時の観点１つ目：既存のデータ基盤との相性 43 • 特に「データ変換ツール」と「BIツール」との相性が重要 • 参考：相性を見る際の考え方 ◦ データ変換にDataformを導入済みなのに、dbt Semantic Layerの 導入を考えるとdbtを入れることになるため、dbtとDataformで 機能重複するところが出てくる（Gitリポジトリも別になる） ◦ 社内ですでに使用しているBIツールがあれば、 「連携手順」「クエリパフォーマンス」「開発ブランチの内容でのBIツー ルからのテスト可否」などを確認する
44. • データカタログ ◦ Semantic Layerとの連携でデータカタログに求めることは？ • データアプリケーション ◦ 既存のアプリのアーキテクチャを大きく変えることなく、 Semantic Layerで定義された指標を参照できるか？ • Generative AIとの相性　※最近BIツールやデータカタログで機能発表が相次いでいる ◦ Semantic Layerを連携させて、定義した指標を学習させて より的確な情報をGenerative AIが提供できるようになるか？ 選定時の観点２つ目：未来のデータ基盤との相性 44
45. • Semantic Layerは導入して終わりの製品ではないです ◦ データガバナンスを担保するためには、適切にSemantic Layerで 指標を定義して、エンドユーザーに浸透させないといけない • どちらの製品も、今後たくさんのアップデートが見込まれます！ ◦ Looker ▪ Semantic Layerに特化したLooker Modelerの詳細はまだ不明 ◦ dbt Semantic Layer ▪ MetricFlow統合後のdbt Semantic Layerについて、 連携できるパートナー製品は2023年後半に判明予定 選定時の観点３つ目：焦らないこと 45
46. １．Semantic Layerとは ２．Lookerとdbtの概要 ３．Semantic Layerの観点で見た、Lookerとdbtの違い ４．各製品の選定時の考え方 ５．最後に アジェンダ 46
47. • Lookerでもdbtでも、Semantic Layerを有効に使えれば よりデータのガバナンスを保ったデータ活用が可能となります 自社に合った製品を選定しデータ活用を促進してください！ 最後に 47 レポーティング データアプリ データカタログ 社内のデータ DWH (データウェアハウス) Semantic Layer 加工 顧客ランク = case … 総売上 = sum(...)