「コードでデータ分析に関わる指標を管理できる ”Semantic Layer”、dbtとLookerで何が違うの？」あな たのこの疑問、解消します 2023/7/8 アライアンス事業部 相樂悟

氏名 相樂 悟 (サガラ サトシ) 所属 クラスメソッド株式会社 アライアンス事業部 役割 Modern Data Stackソリューション　テックリード 自己紹介 2

１．Semantic Layerとは ２．Lookerとdbtの概要 ３．Semantic Layerの観点で見た、Lookerとdbtの違い ４．各製品の選定時の考え方 ５．最後に アジェンダ 3

１．Semantic Layerとは ２．Lookerとdbtの概要 ３．Semantic Layerの観点で見た、Lookerとdbtの違い ４．各製品の選定時の考え方 ５．最後に アジェンダ 4

● データを用いたビジネス指標の定義を一元管理するレイヤー ○ 統一された定義の元に、データ活用を行うことが出来る Semantic Layerとは レポーティング データアプリ データカタログ 社内のデータ 5 DWH (データウェアハウス) Semantic Layer 加工 顧客ランク = case … 総売上 = sum(...)

● 組織内のデータを用いるビジネス指標の定義を統制できる ⇛ データガバナンスの向上・アウトプット時の品質向上 例：複数のフィールドを組み合わせた指標をBIツールで表現しようとしたとき Semantic Layerのメリット Semantic Layerがある場合 DWH Semantic Layer 【30歳以上の会員の総売上】 「年齢」列： >= 30 「売上」列：SUMで集計 必ず同じグラフに Semantic Layerがない場合 DWH 違うグラフになってしまう 【30歳以上の会員の総売上】 「年齢」列： > 30 「売上」列：SUMで集計 【30歳以上の会員の総売上】 「年齢」列： >= 30 「売上」列：SUMで集計 6

● 製品の仕様に沿ったYAMLベースの「コード」を定義するのが主流 ● コードで定義するため、Gitを併用することが多い ○ ブランチの切り分けによる開発環境と本番環境の分離が可能 Semantic Layerってどう定義する？ 7 Lookerの例 dbt Semantic Layerの例

１．Semantic Layerとは ２．Lookerとdbtの概要 ３．Semantic Layerの観点で見た、Lookerとdbtの違い ４．各製品の選定時の考え方 ５．最後に アジェンダ 8

● LookMLというYAMLベースの言語で各指標の定義をコード管理し、 データガバナンスを保ちつつ可視化できるBIツール ● LookMLで定義した指標をAPIで参照することができるため、 BIツールでありながら、Semantic Layerとしての側面も持つ ● 2023年4月に、Semantic Layerに特化した「Looker Modeler」を発表 ※Looker Modelerの詳細は、まだ発表されていない Lookerとは 9

● 「BIツール」の側面から生まれたSemantic Layer Lookerの「Semantic Layer」における立ち位置 10 レポーティング等 社内のデータ DWH (データウェアハウス) Semantic Layer 加工 顧客ランク = case … 総売上 = sum(列名) Looker Looker Modeler

● 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

● 「データ変換」の側面から生まれたSemantic Layer dbtの「Semantic Layer」における立ち位置 12 レポーティング等 社内のデータ DWH (データウェアハウス) Semantic Layer 加工 顧客ランク = case … 総売上 = sum(列名) dbt dbt Semantic Layer

１．Semantic Layerとは ２．Lookerとdbtの概要 ３．Semantic Layerの観点で見た、Lookerとdbtの違い ４．各製品の選定時の考え方 ５．最後に アジェンダ 13

振り返り：Semantic Layerに該当する機能がある2製品 14 レポーティング等 社内のデータ DWH (データウェアハウス) Semantic Layer 加工 顧客ランク = case … 総売上 = sum(列名) dbt dbt Semantic Layer Looker Modeler Looker

今日のメイントピック 15 レポーティング等 社内のデータ DWH (データウェアハウス) Semantic Layer 加工 顧客ランク = case … 総売上 = sum(列名) dbt dbt Semantic Layer Looker Looker Modeler ・LookerのSemantic Layer ・dbtのSemantic Layer 何が違うの？？

以下の観点で、dbtとLookerのSemantic Layerを比較 ・定義の方法 ・指標の参照方法 ・クエリの最適化 ・キャッシュ ・WINDOW関数 ・連携可能なBIツール ・連携可能なデータカタログ ・各製品独自の強み 観点 16

● 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

● 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)

定義の方法：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

● 基本は、事前に定義済みのmeasureとdimensionを選択する形式 ● Looker・他のBIからの参照 ○ ユーザーが必要なdimensionや measureを選択する形式 ● APIを用いた参照 ○ Looker APIというREST APIに加えて、 Ruby、Python、TypeScript、JavaScriptのSDKもある 指標の参照方法：Looker 22

● 基本は、事前に定義済みの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

● 選択したmeasure・dimensionに応じて、 最低限のView（１テーブル・ビュー）同士を結合する ● 結合によるレコード膨張(fan-out)を 防ぐようにクエリを都度書き換えてくれる 「Symmetric Aggregates」 ● クエリ内容に応じ参照するテーブルを 動的に切り替える「Aggregate Awareness」 クエリの最適化：Looker 25 ※画像引用元：公式ドキュメント「Aggregate awareness」

● 選択したmetrics・dimensionsに応じて、 最低限のsemantic_model(１テーブル・ビュー)同士を結合する ● ユーザーが定義したentitiesの 「Primary・Foreign・Unique」に応じて、 レコード膨張(fan-out)が起こりうる 組み合わせの場合は結合させない クエリの最適化：dbt Semantic Layer 26 ※参考情報：公式Doc「About MetricFlow」「Joins」、買収前のMetricFlowのドキュメント「Join Logic」

キャッシュ 27

● 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" }

● MetricFlow統合後の初リリース時にはキャッシュ機能はない予定 ● しかし、キャッシュ機能の開発予定はあり ○ 第１弾：ユーザー側で指定したメトリクスについて、 　　　　キャッシュを保持する仕組み ○ 第２弾：頻繁にリクエストがあるMetricsを分析し、 　　　　ユーザーへの通知や自動キャッシングをしてくれる？ 　　　　（詳細未定） キャッシュ：dbt Semantic Layer 29 ※参考情報：公式ブログ「The dbt Semantic Layer: what’s next」

WINDOW関数 30

● 「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";; }

● 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' ) ] ) }} 前週との差を 出している

連携可能なBIツール 33

● まず、Looker自体もBIの機能を持つ ○ LookerのBI機能は、インスタンス上のロゴを非表示にして公開、アプリ へのグラフの埋め込みなど、社外への公開が強み ● LookerをSemantic Layerとして使用した際に対応するツール ○ GA済み：Microsoft Power BI、 　　　　 Looker Studio、 　　　　 Google Spreadsheet ○ これから：Tableau、 ThoughtSpot 連携可能なBIツール：Looker 34 ※参考情報：公式ブログ「Looker Modeler のご紹介: BI 指標のための信頼できる唯一の情報源」

● 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

● Lookerとの連携に対応したデータカタログの例 ○ Atlan、Select Star、Secoda、CastorDoc、OpenMetadata、等 ● できること ○ Lookerで定義されたDescriptionなどのメタデータの確認 ○ 元テーブル～View～Explore～ダッシュボード、の列レベルリネージ ※右図はSelect Starの例 連携可能なデータカタログ：Looker 37

● 2023年7月8日時点、MetricFlow統合後のdbt Semantic Layerと ネイティブに接続できるデータカタログは未定 ● 参考：2022年リリースのdbt Semantic Layerとデータカタログの連携 ○ Secodaの例：データカタログのGlossary(社内用語の辞書)に自動登録 連携可能なデータカタログ：dbt Semantic Layer 38

各製品独自の強み 39

● User Attributeで独自のユーザー属性を作成し、ユーザーごとに 任意の値を定義することで、アクセス可能なデータの制限が可能 ● 行レベルセキュリティ ○ 「access_filter」とユーザーごとの属性情報を用いて、 どのレコードを参照させるかを絞り込み可能 ● 列レベルセキュリティ ○ 「access_grant」とユーザーごとの属性情報を用いて、 どのdimension・measureを使用させるか制御可能 各製品独自の強み：Looker 40

● 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

１．Semantic Layerとは ２．Lookerとdbtの概要 ３．Semantic Layerの観点で見た、Lookerとdbtの違い ４．各製品の選定時の考え方 ５．最後に アジェンダ 42

選定時の観点１つ目：既存のデータ基盤との相性 43 ● 特に「データ変換ツール」と「BIツール」との相性が重要 ● 参考：相性を見る際の考え方 ○ データ変換にDataformを導入済みなのに、dbt Semantic Layerの 導入を考えるとdbtを入れることになるため、dbtとDataformで 機能重複するところが出てくる（Gitリポジトリも別になる） ○ 社内ですでに使用しているBIツールがあれば、 「連携手順」「クエリパフォーマンス」「開発ブランチの内容でのBIツー ルからのテスト可否」などを確認する

● データカタログ ○ Semantic Layerとの連携でデータカタログに求めることは？ ● データアプリケーション ○ 既存のアプリのアーキテクチャを大きく変えることなく、 Semantic Layerで定義された指標を参照できるか？ ● Generative AIとの相性　※最近BIツールやデータカタログで機能発表が相次いでいる ○ Semantic Layerを連携させて、定義した指標を学習させて より的確な情報をGenerative AIが提供できるようになるか？ 選定時の観点２つ目：未来のデータ基盤との相性 44

● Semantic Layerは導入して終わりの製品ではないです ○ データガバナンスを担保するためには、適切にSemantic Layerで 指標を定義して、エンドユーザーに浸透させないといけない ● どちらの製品も、今後たくさんのアップデートが見込まれます！ ○ Looker ■ Semantic Layerに特化したLooker Modelerの詳細はまだ不明 ○ dbt Semantic Layer ■ MetricFlow統合後のdbt Semantic Layerについて、 連携できるパートナー製品は2023年後半に判明予定 選定時の観点３つ目：焦らないこと 45

１．Semantic Layerとは ２．Lookerとdbtの概要 ３．Semantic Layerの観点で見た、Lookerとdbtの違い ４．各製品の選定時の考え方 ５．最後に アジェンダ 46

● Lookerでもdbtでも、Semantic Layerを有効に使えれば よりデータのガバナンスを保ったデータ活用が可能となります 自社に合った製品を選定しデータ活用を促進してください！ 最後に 47 レポーティング データアプリ データカタログ 社内のデータ DWH (データウェアハウス) Semantic Layer 加工 顧客ランク = case … 総売上 = sum(...)

No content