この記事は何

2023年、世間はLLMで大騒ぎですが、データの業界ではセマンティックレイヤー・Headless BIへの注目も高まっています。
これは、まだ国内では黎明期ともいえるそんな技術が、今後どんな存在となりうるのかを、筆者の個人的な解釈~~と妄想~~をもとに述べる長文ポエムです。

セマンティックレイヤーとは

まず最初にセマンティックレイヤーについて解説します。

セマンティックレイヤーとは

セマンティックレイヤーとは、データベースとデータ利用者の間に入り、両者間のやりとりを円滑にする存在です。

データ統合プラットフォームを提供するAirbyte社は、セマンティックレイヤーをデータとビジネスユーザーの中間に位置する、複雑なデータを理解可能なビジネスの概念に変換・翻訳するレイヤーと説明しています。

A semantic layer is a translation layer that sits between your data and your business users. The semantic layer converts complex data into understandable business concepts.
引用元: The Rise of the Semantic Layer

通常、データベースにあるデータの利用には、利用者がデータの構造を理解した上で、正確にSQLを書いてデータを取得する必要があります。しかし、データを利用するのはエンジニアやアナリストだけではない今の時代、それらのスキルを全てのデータ利用者に求めるのは現実的ではありません。

そんな課題を、セマンティックレイヤーは解決します。セマンティックレイヤーを利用すると、データの利用者は「売上」「注文日」などの慣れ親しんだ社内用語をディメンション・メジャー（説明は後述）などに指定するだけで、データを利用できるようになります。セマンティックレイヤーが、指定された条件をもとにSQLを発行してくれるためです。

ディメンション・メジャーとは

ディメンション
日付や顧客名などの、データ集計結果の属性となるもの。SQLではGROUP BYに利用される。
メジャー
売上や利益などのデータ集計結果に表示される集計された数値。指標。SQLではSUM/AVG/COUNTなどの集計関数と併用される。

そもそもIT業界では「セマンティック」という言葉は、与えられたデータや言葉の意味を解釈し、適切なプログラムやデータに変換する技術に対して利用されます。（参考：セマンティック検索とは | ウィルゲート）

セマンティックレイヤーも、慣れ親しんだビジネス用語を基に、データベースにとって適切な処理（SQL）を生成すると言う性質を持っているため、セマンティックという言葉がついています。

セマンティックレイヤーはどのようにSQLを作るのか

条件を指定するだけで何故SQLが生成されるのかは、セマンティックレイヤーが保持する情報を考えると理解できます。

セマンティックレイヤーは一般的に、事前に以下のような情報を定義することで構築されます。

データベースやテーブルに関する基本情報
- 接続に必要な情報（ホスト名や接続方法など）
- データベース上のテーブル名・カラム名
- テーブル間のリレーションシップ
各ビジネス用語（売上・日付など）に対する以下の情報
- テーブル上のカラムとの対応関係や計算の定義
- ディメンション・メジャーの分類

セマンティックレイヤーが構築された後は、データの利用者は、主にディメンション・メジャー・フィルターの３つの条件を指定することで、任意の条件でのデータ集計が可能になります。

例えば、以下のような条件を指定します。

ディメンション：注文日
メジャー：売上、購買顧客数
フィルター：2023年のみ

するとセマンティックレイヤーは、事前に定義された情報をもとにして、以下のようなSQLをデータベースに対して発行し、結果を取得します。

SELECT 
  order_date AS "注文日",
  SUM(sales) AS "売上",
  COUNT(DISTINCT customer_id) AS "購買顧客数"
FROM orders
WHERE YEAR(order_date) = 2023
GROUP BY order_date

上記のSQLの結果、データの利用者の元には以下のようなデータが渡り、可視化や分析に活用できるようになります。

日付	売上	購買顧客数
2023-01-01	123123	123
2023-01-02	234234	234
2023-01-03	345345	345
...	...	...

このようにしてセマンティックレイヤーは、データ利用者が直接SQLを書くことなしに、データを集計することを可能にします。

身近にあったセマンティックレイヤー

実は、セマンティックレイヤー自体は新しい技術ではありません。主にビジネスサイドの人を対象に、データ利用者が直接SQLを書かずにデータを取得出来る技術自体は、1991年に取得されたSAP社による特許にも登場しており、DW/BIの世界でも広く活用されている技術です。

身近なBI製品でも、その技術は搭載されています。データ利用者は、BIツール上の「売上」「日付」などのフィールド（≒カラム）を、UI上でドラッグ＆ドロップ操作をすると、裏側ではデータベースに対してクエリの発行が行われていることは、ご存知の方も多いでしょう。こうした体験が可能なのは、BIのツールの内部にセマンティックレイヤーが構築されており、ユーザーの操作を基にしたSQLの生成・発行が行われているためです。

従来型セマンティックレイヤーの課題

しかし、従来のBIツールに搭載されたセマンティックレイヤーには課題がありました。それは、セマンティックレイヤーのスコープの狭くなりやすいことです。

特に、2010年代に大きく普及した 「セルフBI」 と呼ばれるデータ利用者が主体的にデータ集計・可視化していく世界観の中では、セマンティックレイヤーの定義は、各ワークブックやダッシュボード単位でユーザーによって自由に使われることが一般的でした。

セマンティックレイヤーの定義を各ワークブックで行えるということは、セマンティックレイヤーにあるビジネスロジックの定義もユーザーが各自行うことを意味します。この誰でも、簡単にリッチなレポートを構築できるセルフBI文化は日本でも広く普及し、組織のデータ活用に大きく貢献してきました。

しかし、そうした手法の普及につれて、ビジネスロジックへの解釈の差分により、ダッシュボードによって表示されている数値が異なるといった課題も発生するようになりました。例えば、とある部署が見てるダッシュボードでは、「売上」に返品額が反映されるのに、他の部署の人のレポートでは反映されないといった課題です。

また、データの活用が進んでいる組織では、データウェアハウスを参照するのはBIツールだけではありません。例えばデータサイエンティストは、Jupyer Notebookを使って分析するかもしれませんし、社内アプリケーションへの埋め込みを使って、データウェアハウスから直接データを取得し表示するレポートもあるかもしれません。

その度に、ロジックの定義やセマンティックレイヤーの構築が発生することは、ビジネスロジックの定義の分散を意味します。これでは、組織内のデータ活用が進めば進むほど、定義が分散してしまうリスクが発生してしまいます。更に、データの定義に変更が走った際にも、新しい定義が反映されているレポートと、反映されていないレポートなどが出てくるかも知れません。

ユニバーサル・セマンティックレイヤー/Headless BIの時代

そんな背景を受けて、あらゆるサービスから参照可能なセマンティックレイヤーである「ユニバーサル・セマンティックレイヤー」の構築に注目が集まり始めました。

ユニバーサル・セマンティックレイヤーは、データが利用される様々なサービス（各種BIツール、Notebook、アプリケーションなど）からAPIを経由して接続し、統合管理されたセマンティックレイヤーを使って、データウェアハウスにあるデータを集計することができます。

ユニバーサル・セマンティックレイヤーを提供する代表的なサービスにCubeがあります。

画像引用元: https://github.com/cube-js/cube

Cubeでは、画像右側にあるような多種多様なアプリケーション（BIツール、埋め込み分析、ノートブックやその他App）から接続可能なセマンティックレイヤー（画像中央）を提供しています。接続先としてもSnowflakeやBigQueryなどの様々なデータウェアハウスへの接続をサポート（画面左側）しています。

これにより、各データ利用者が使い慣れたサービスやデータウェアハウスを利用したまま、表示されるデータの定義に対して信頼性を与える仕組みが実現できるようになりました。

更に、Cubeはロジックの管理だけではなく、データへのアクセス制御やパフォーマンス高速化させることや、SQL/REST/GraphQLなどの幅広いAPIへの対応も含めてサービス提供しています。

このように、従来型BIにあったロジック管理のスコープの狭さを解消しつつ、他にもデータ活用者にとって便利な様々な機能を提供するサービスはHeadless BIとも呼ばれています。Headlessとはフロントエンドを持たないという意味であり、データの文脈ではグラフやダッシュボードの可視化機能を持たないことを意味しています。
※これ以降本記事では、ユニバーサル・セマンティックレイヤーも含めて呼称をHeadless BI に統一します。

Headless BIを導入するメリット

Headless BIの導入によって、組織は以下のようなメリットを得ることが期待できます。

データへの信頼性の向上
パフォーマンスの向上、DWコストの節約
データ民主化の加速

データへの信頼性の向上

まず最初に挙げられるのが、ビジネスロジックの統合管理によるデータの信頼性の向上です。

ロジックの定義をHeadless BIに寄せると、ビジネスロジックの分散を抑えることが期待できるため、組織がモニタリングするKPIに定義の揺れが発生するのを抑えることや、集計定義のバージョン管理や一括変更などが容易になります。

既存のETLツールなども、データウェアハウス内のテーブルやビューの定義を管理することはできますが、それらの完成されたテーブルやビューに対して、外部から投げられるSQLのロジックを管理するのは限界があります。Headless BIを活用することで、外部からデータウェアハウス内に構築済みのテーブル・ビューに対して投げられるクエリのロジックも含めて管理することが可能になります。

パフォーマンスの向上、DWコストの節約

実用的なメリットとしてクエリのパフォーマンス向上も期待できます。

例えば上記のCubeでは、インメモリキャッシュ(Request Cache)と、事前集計データ（Pre-aggregation Store）の２段階のクエリ高速化手段を提供しています。

画像引用元：https://cube.dev/docs/product/caching

事前集計済みデータ（Pre-aggregation Store）では、事前に頻繁に参照されるディメンションとメジャーを組み合わせた計算結果を、Cube内または利用しているデータウェアハウス内で事前集計した結果を保持出来るため、集計パフォーマンスを大幅に改善させることが期待できます。

こうした機能は、データウェアハウスへのクエリ本数の削減や、個別のクエリのパフォーマンス高速化に活用できるため、データウェアハウスのコスト節約手段としても期待できます。

データ民主化の加速

Headless BIの利用は、データ民主化の促進にも大きく貢献すると考えられます。

データモデルを理解してSQLを書けるようになるのも、セルフBIツールでセマンティックレイヤーを自ら構築するのも、一朝一夕で出来るようになることではありません。

しかし、Headless BIの導入を行うと、データ利用者は事前構築済みのセマンティックレイヤーを利用することが可能なため、データ利用者はビジネスロジックのコピーに頭を悩ますことなく、慣れ親しんだ用語のみを使って集計したデータを、可視化や分析に利用できます。

そのため、データ活用にあたって必要な技術的なハードルが、従来よりも下げられた状態となり、より多くの人にデータを活用してもらえることも期待できます。

LLMとの掛け合わせへの期待

今後Headless BI × LLMとの統合も今後注目される分野でしょう。

2023年、代表的なBIツールベンダーが、次々とLLMとの統合機能や構想を発表しました。

PowerBI： PowerBI Copilot
Tableau： Tableau GPT
ThoughtSpot： ThoughtSpot Sage

これらの機能がどんどん実用化されていくと、「昨日の売上は？」「関東地方の顧客ごとの売上は？」などのデータ集計はもちろん、「今月の売上が先月より下がっている理由は？」「サービスを解約しやすい顧客の特徴は？」などのアドホックな分析も、LLMを活用したアプリケーションを介して行われる時代が遠くない未来にやってくることでしょう。

そのような時代の中、Headless BIは、LLMを介して表示されるデータのロジックに信頼を与えることができると考えられます。これは、これからのデータ活用において、とても大きなポテンシャルを秘めた分野になると考えられます。

Headless BIはどのような組織に向いているのか

Headless BIの導入による効果が期待できる企業はどのような企業でしょうか。

筆者は個人的に以下のような特徴を持つ企業への導入効果が大きいと考えています。

組織の中でデータを基にした意思決定が浸透している
データ利用者のデータリテラシーが様々である
データウェアハウスに様々なアプリケーションから接続している

BI/DWの巨匠であるラルフ・キンボールが創設したKimball Groupは、セマンティックレイヤーの構築が「不要」かもしれない唯一のシナリオについて、「DW/BIシステムへのアドホックな分析ユーザーからのアクセスが閉されており、全てのアクセスはプロのレポート開発者のみを介して行われる状況」 と述べています。

There’s only one scenario where I might buy the argument that you can get away without a semantic layer. If the doors to your DW/BI system are closed to all ad hoc users, and all access is mediated by professional report developers, you can make it work without a BI semantic layer.
引用元：https://www.kimballgroup.com/2013/08/design-tip-158-making-sense-of-the-semantic-layer/

組織のデータ活用が浸透し、利用者や利用用途が多種多様になってくると、堅牢なセマンティックレイヤーやHeadless BIの重要性が、組織にとって増してくると考えられます。

注目のHeadless BIのサービス

注目のHeadless BIのサービス(構想のみのものを含む）を紹介します。

Cube

https://cube.dev/
本記事でも何度も登場したHeadless BIの代表格とも言えるサービスです。オープンソースで利用可能なCube Coreと、SaaSとして利用可能なCube Cloudがあります。

dbt Semantic Layer

ELTパイプラインのお供であるdbtでも、Semantic Layerの構築機能をサポートを始めています。データウェアハウス内のテーブル管理を行えるdbtを使って、そのままセマンティックレイヤーを定義できることは、多くの組織にとって魅力的に映ることでしょう。

※記事執筆時点では、Public Preview。dbt CloudでSnowflakeを利用しているアカウントのみ利用できます。

Looker Modeler （サービス未公開）

従来型BIの中で、セマンティックレイヤーの中央集権管理と、その機能の抱負さに強みを持っていたLookerによる、Headless BIのサービスです。BIツールとしてLookerを利用していない組織でも、LookMLによるセマンティックレイヤーの構築が可能になるサービスです。

※記事執筆時点でサービス未公開です。

Tableau VizQL Data Services（サービス未公開）

https://youtu.be/rgj2zyGRz7s
セルフBIの代表格であるTableauが、2023年のTableau Conferenceで発表したHeadless BIの構想です。Tableauを既に利用している企業が、Tableauプラットフォームにパブリッシュされているデータソースを、Headless BIとして利用出来る機能であり、Tableau GPTとの掛け合わせも含めて、注目度の高いHeadless BIです。

※記事執筆時点でサービス未公開です。

もっとHeadlessBI/Semantic Layerを知りたい方へ

本記事を書くのに参考にした世界中の人々の素晴らしいHeadless BIに対する熱い記事を貼っておきます。

The Rise of the Semantic Layer: Metrics On-The-Fly

Airbyte社によるSemantic Layerの解説記事です。セマンティックレイヤーの歴史から、OLAPキューブ・Data Catalogとの違いまでが網羅的に語られています。

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

クラスメソッドのさがらさんによる、Lookerとdbt Semantic Layerの比較記事です。多くの組織にとって身近な存在であるLookerとdbtが提供するセマンティックレイヤーの違いを、丁寧に解説するとても貴重な情報源です。

Headless BI vs Self-Service BI

PowerBIのPower BI Shared Datasetsを例に、Self Service BIの既存機能を活用すれば、Headless BIが必ずしも必要にならないことを説く記事です。これは、Tableauのパブリッシュされたデータソースなどにも同じことが言えると考えられ、BIツールの乱立などが行われていない組織では、Headless BIの導入に走る前に一見する価値がある記事です。

Discussion