[レポート] セマンティックレイヤーに求められる新たなアプローチ #dbtCoalesce #Coalesce23

大阪オフィスの玉井です。

米国時間2023年10月16日〜19日、イベント『Coalesce 2023』が開催されました。主催はdbt labs社です。

本記事は、その中で発表されたThe need for a new approach to the semantic layer（セマンティックレイヤーに新たなアプローチが求められる理由）というセッションについて、レポートをお届け致します。

セッション概要

登壇者

• Artyom Keydunov, Co-founder & CEO, Cube Dev

超概要

セマンティックレイヤーをデータ分析基盤に普及させるために必要なことについて話されているセッションです。

セッションレポート

前段

私の名前はArtyomです。オープンソースプロジェクトのCubeの共同創設者の一人です。CubeはGitHubで公開されています。その後、私はCubeの商用版を構築する会社を立ち上げました。

今日は、セマンティックレイヤーというカテゴリーについて、そしてなぜ標準化が必要なのかについて話します。 セマンティックレイヤー（あるいはメトリクスレイヤー）は、比較的新しいカテゴリーです。データエンジニアリングのコミュニティでは、その必要性や価値について、大まかな理解はなされていると思います。 しかし、具体的にはどのように機能すべきか、メトリクスの定義方法やBIツールとの統合方法など、まだ不明確な部分が多いのが現状です。

そこで今日は、セマンティックレイヤーの外部インターフェースについて、主に話をしたいと思います。 この考え方は、私たちのコミュニティや、この分野で先進的な取り組みを行っている企業との議論を通じて得られたものです。 セマンティックレイヤーの標準化に向けて、皆で議論を重ねてきた結果です。

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

それでは、まずセマンティックレイヤーの基本的な定義から始めましょう。 ここにいる皆さんは、セマンティックレイヤーについて聞いたことがあるという方が多いようですね。

セマンティックレイヤーを一文で説明すると、データ（の利用側の）アーキテクチャーにDRYの原則を適用したものだと言えます。 DRYとは「Don't Repeat Yourself」の略で、同じことを繰り返さないという原則です。 データを使用するツールとして、BI、Notebook、埋め込み分析などがありますが、新しいツールを導入するたびに、同じようなメトリクスの定義を繰り返す必要があります。これを解決するのがセマンティックレイヤーの役割です。メトリクスの定義をセマンティックレイヤーで一元管理し、各ツールから共通して利用できるようにするのです。

セマンティックレイヤーには4つの柱があります。

1つ目は、データモデリングです。ここでメトリクスや各種データモデルを定義します。多くのツールはコード中心のアプローチをとりますが、GUIを用いたものもあります。

2つ目は、アクセスコントロールとガバナンスです。メトリクスの定義と密接に関係し、組織内の各ユーザーや部門に応じたアクセスコントロールが必要になります。

3つ目はキャッシングです。メトリクスの高速な提供と、データウェアハウスのコスト削減に役立ちます。

4つ目はAPIです。BI、組み込み分析、カスタムアプリなど、様々なツールにメトリクスを提供する手段として重要です。

データ分析基盤の全体像の中で、セマンティックレイヤーがどのように位置づけられるかを説明します。

セマンティックレイヤーは、データウェアハウスと各種BIツールの間に位置します。 データウェアハウスには、dbtやSQLMeshなどのツールで変換された、正規化された形式のデータが格納されています。 このデータがセマンティックレイヤーに渡されると、そこで非正規化され、メトリクスが定義されます。 そして、最終的にはこのメトリクスが、BIツール等に提供されるのです。

セマンティックレイヤーの標準化

なぜ標準化が必要なのでしょうか。

セマンティックレイヤーの本来の目的は、データを使用する様々なツールにメトリクスを提供することです。 つまり、セマンティックレイヤーは、色々なツールとうまく連携できる必要があります。 そのためには、私たちセマンティックレイヤーの開発者側も、常に拡大し続ける技術スタックをサポートしていく必要があります。

一方、BIツール等の開発者側も、複数のセマンティックレイヤーに対応できるようにしなければなりません。 このように、異なる主体間の連携が重要になってきます。 そこで、他の業界で見られるような標準化が、セマンティックレイヤーの分野でも役立つと考えられるのです。

次に、セマンティックレイヤーと特定のツールとの連携について考えてみましょう。

1対1の専用コネクタを構築することも可能ですが、BIツール市場は非常に細分化されており、すべてのツールに対して専用コネクタを構築し、メンテナンスを行うのは現実的ではありません。そもそもセマンティックレイヤーを導入する目的は、このような問題を解決することなのです。

では、この問題をどのように解決すればよいでしょうか。つまり、結合度の低いアーキテクチャーにおいて、統合されたセマンティックレイヤーの体験を提供するにはどうすればよいかが、課題となります。

まず、「統合されたセマンティックレイヤー」と「結合度の低いアーキテクチャー」について定義しましょう。

Lookerは、非常に良い統合型セマンティックレイヤーの例だと言えます。 Lookerの成功の鍵となったのが、LookMLというコード中心のアプローチでした。 LookMLでExploreなどのオブジェクトを定義すると、BIツールのUIにもすぐに反映されるのです。 つまり、統合型セマンティックレイヤーでは、セマンティックレイヤーの変更がBIツールのUIにダイレクトに影響するのが特徴です。

では、セマンティックレイヤーが、結合度の低いアーキテクチャーの場合、つまり、別のスタンドアロンツールやベンダーが提供する場合、Lookerのような統合体験をどのように実現できるでしょうか。

データ分析チームがセマンティックレイヤーでメトリクスを定義したとき、データを使う側がBIツールでそのメトリクスやオブジェクトを見られるようにするにはどうすればよいでしょうか。 BIツールにはそれぞれネイティブのオブジェクト、例えばSupersetのデータセット、Tableauのデータソース、Power BIのスタックなどがあります。 この問題を解決するには、これらのBIツールのネイティブオブジェクトとセマンティックレイヤーを統合する方法を見つける必要があります。 そうすれば、データを使う人達は、セマンティックレイヤーで定義された名称のオブジェクトを使えるようになります。

つまり、標準化によって、BIツール等とセマンティックレイヤーを整合させ、統合型セマンティックレイヤーと同様のユーザー体験を実現することができると考えます。 これは非常に重要なことです。 なぜなら、1つのセマンティックレイヤーが複数のデータ分析ツールをサポートする必要があり、逆に、データ分析ツールも複数のセマンティックレイヤーと連携できる必要があるからです。 このように、双方向の連携が不可欠なのです。

セマンティックレイヤーのインターフェースを検討する

それでは、この標準化によってカバーすべき内容について話しましょう。 ここでは、実装ではなく、インターフェースについて議論します。 なぜなら、ベンダーによって実装は異なる可能性がありますが、標準化すべきはインターフェースだからです。

この標準化には、おおよそ以下の内容を含めるべきだと考えています。

まず、セマンティックレイヤーを記述するためのオブジェクトの仕様です。 メトリクスについては、集計の計算式を定義することができます。 また、エンティティに紐づく非集計値、例えば注文の顧客や更新日などについても、定義できるようにする必要があります。

次に、クエリプロトコルについてです。BIツールや埋め込み分析がセマンティックレイヤーにどのようにクエリを発行するかを定義します。

最後に、メタデータAPIについてです。BIツールがセマンティックレイヤーからオブジェクトを取得し、ネイティブのオブジェクトにマッピングできるようにする仕組みを定義します。

まず、セマンティックレイヤーを記述するオブジェクトについて見ていきましょう。 これまでに、主に2つのアプローチが見られます。 1つは、メトリクスを中心としたアプローチ、もう1つはデータセットを中心としたアプローチです。

まず、メトリクス中心のアプローチについて説明します。

このアプローチでは、メトリクスが第一級のオブジェクトとなります。 メトリクスには時間のディメンションと、関連する複数のディメンションが設定されます。 セマンティックレイヤーはこのようなメトリクスのリストとして公開され、データを使う側は、そこから必要なメトリクスを選んで分析を行います。 例えば、平均注文金額のメトリクスを月次や四半期で見たり、州や国別に分析したりするといった具合です。 このようなワークフローがメトリクス中心のアプローチの特徴です。

メトリクス中心のアプローチには、長所と短所があります。

長所は、組織がメトリクスを目標やKPIとして考えているため、メトリクスという概念が馴染みやすいということです。つまり、組織内でのコミュニケーションが取りやすいでしょう。

短所は、多くのデータ分析ツールがメトリクスの概念を持っていないことです。統合型BIやセマンティックレイヤーでは、テーブルやキューブ、メジャーとディメンションといった概念が一般的ですが、メトリクスを第一級のオブジェクトとして扱うツールはまだ少ないのが現状です。また、非集計値をどのように扱うかも課題となります。例えば、平均注文金額ではなく特定の注文の金額を見たい場合、それをどのようにメトリクスモデルに組み込むべきかが明確ではありません。ディメンションとして扱うべきか、別の方法があるべきか、検討の余地があります。

次に、データセット中心のアプローチについて見ていきましょう。

このアプローチでは、セマンティックレイヤーがテーブルベースのデータセットのセットとして公開されます。 各テーブルには、メジャーとディメンションが定義されています。時間のディメンションも含まれます。 データを使う側は、このデータセットのリストから必要なものを選び、分析を行います。 例えば、平均注文金額を見たい場合、注文データセットを見つけ、そこに定義されているメジャーを活用することになります。 必要に応じて、時間のディメンションや他のディメンションを適用して分析を行います。

データセット中心のアプローチには、メトリクス中心型とは逆のメリデメがあります。

短所は、データセットやテーブルを扱うため、抽象度が高く、組織内での理解が難しいことです。

長所は、BIツールがテーブルやキューブの概念に馴染みがあるため、マッピングしやすいということです。

そこで、この2つのアプローチの長所を組み合わせることができないでしょうか。

具体的には、メトリクスをデータ中心アプローチの中で扱うことです。 メトリクスを、1つの列がメジャーで、他の列がディメンションという特殊なデータセットとして扱うのです。 これにより、エンティティモデリングとメトリクスモデリングを組み合わせることができ、用途やユーザーに応じて使い分けることが可能になります。 テーブルのリストがエントリーポイントとなりつつ、適切な命名規則によって、エンティティとメトリクスを区別して扱えるようになります。

セマンティックレイヤーにクエリする方法を検討する

今、時間を確認したところ、あと5分で止めないといけない…。けど、クエリプロトコルについて話しますね。

セマンティックレイヤーは、データ分析ツールすべてに一貫したメトリクスを提供するという目的を果たすため、完全なクエリインターフェースを提供する必要があります。

現在、ほとんどのデータツールがクラウドデータウェアハウスからデータを取得する際にSQLを使用しているため、SQLが一般的な選択肢だと考えられます。 セマンティックレイヤーもSQLインターフェースを提供すべきでしょう。

また、埋め込み分析など、データの様々な活用方法も、セマンティックレイヤーの重要な一部となります。 その場合、RESTやGraphQLなどのHTTPベースのインターフェースが適切だと考えられます。

さらに、Power BIで使われているMDXについても検討の余地があります。 Microsoft エコシステムでは非常に一般的ですが、それ以外では使われていません。 つまり、セマンティックレイヤーがMDXをサポートすべきかどうかは、Microsoft エコシステムとの親和性を考える必要があります。

SQLについて具体的に話をしましょう。SQLを使ってメトリクスをクエリするのは少し難しいかもしれません。 2つのオプションが考えられます。

1つ目のオプションは、SQLをラッパーとして使い、独自のメトリクスクエリ言語を埋め込むというものです。この方法の利点は、自分たちのニーズに合わせて言語を設計できることです。しかし、BIツールがこの独自の言語を生成することが難しいという問題があります。BIツールはSQLを生成してデータを取得していますが、この独自の言語を生成する方法がわからないため、実装が難しくなる可能性があります。

2つ目のオプションは、SQLを少しだけ拡張して、メトリクスのクエリをサポートする方法です。SQLは基本的に表形式のデータを扱うものですが、メトリクスの概念がありません。そこで、SQLに「measure」という概念を追加し、メトリクスを評価できるようにするのがこのアプローチです。具体的には、SQLに「measure」型のデータ型を追加し、それに対応した集計関数を用意するというものです。これにより、SQLの中でメトリクスを扱えるようになります。ただし、SQLの設計思想とは少し異なるため、実装上の課題が残る可能性があります。

セマンティックレイヤーをAPI経由で利用する方法を検討する

（登壇の残り）時間がないので、メタデータの部分について、ドロップダウンに「探索」が表示されるようにする方法を1分以内で説明します。

セマンティックレイヤーは、データを公開する際の単一の標準を持つ必要があると考えています。データ中心型なのか、メトリクス中心型なのか、オブジェクトの定義は何か？を明確にすれば、このオブジェクトをAPIで公開できます。

このAPIにより、BIツールなどのユーザーが、ネイティブのオブジェクトにマッピングしてデータを取得できるようになります。 セマンティックレイヤーがデータ定義を押し出すpushオプションと、ユーザー側が引き出すpullオプションの両方が考えられます。重要なのは、このメタデータAPIを確立し、さまざまなツールで統一化することです。

時間が来てしまったので、ここで説明を終わらせていただきます。

所感など

Lookerに触れているところが「わかっているな」と思いました（偉そう）。

Artyom氏が言っている通り、Lookerは統合型のセマンティックレイヤーとしては抜群の使いやすさを誇っています。しかし、統合型であるがゆえに、Looker以外のツールからメトリクスを利用するのが難しい（できないわけではない）です。そして、昨今のデータ分析基盤において、Lookerだけで完結するものは、ほとんど無いでしょう。

なので、統合型のメリットを、標準化された（独立した）セマンティックレイヤーでも何とか使えないか？というArtyom氏のアプローチは、私も非常に賛同します。