セマンティックレイヤーとは何か、そして「一度定義する」が本当に意味すること

同じ名前、2つの数値

2人が2つのダッシュボードを開きます。どちらにも「純収益」というラベルが付いています。2つの数値は4パーセント違います。どちらも筋が通っています。それぞれ別の場所で計算されたからです。ひとつはワークブックの計算から来ました。もうひとつはウェアハウスのビューから来ていて、どちらも相手の存在を知りません。

これはたいてい、データそのものの問題ではありません。ウェアハウスは正常です。問題は別の場所にあります。「純収益」の定義が複数の場所にあるので、複数の「純収益」があるのです。

セマンティックレイヤーは、そのひとつの失敗を直します。メトリクスに単一の住まいを与えます。他の人たちは、もう一度書き出すのではなく、そのメトリクスを読むようになります。

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

セマンティックレイヤーは、あなたのデータの統制された記述です。物理テーブルと、質問する人たちの間に置かれます。3種類のものを保持します。

• エンティティ。話題にするビジネスオブジェクト：顧客、注文、保険契約、請求。
• ディメンション。それらを切り分ける軸：地域、製品ライン、月、チャネル。
• メジャー。数値。それぞれが、それを生み出す正確な式を運びます。

大事なのは式の部分です。フィールドに「純収益」と名付けてもセマンティックレイヤーはできません。集計、フィルター、粒度を記録して初めて、レイヤーが使えるメジャーになります。その3つがパブリッシュされ、強制されます。

セマンティックレイヤーは契約であって、データのコピーではありません。行は保存しません。行の合意された意味を保存し、行を運ぶテーブルを指し示します。

「一度定義する」の意味

「一度」とは、式が正確にひとつの場所にあるということです。メトリクスを必要とするすべてのツールが、そこから読みます。

1. 人がウェアハウスでメジャーを定義します。式、粒度、フィルターとともに。
2. 定義は統制されたオブジェクトとしてパブリッシュされます。プラットフォーム自身がそれを理解します。プラットフォームについての文書ではありません。
3. そのメジャーを名指しするすべての質問は、保存された定義を実行して答えられます。
4. 定義の変更は、ひとつの編集、ひとつのレビューで、すべての答えを変えます。

テストは単純です。「純収益」の定義をひとつの場所で変えてください。すべてのダッシュボード、ノートブック、アシスタントが追随すれば、メトリクスは一度定義されています。他のコピーを探して編集しなければならないなら、一度定義されたことは一度もなかったのです。

同じ考え、4つの名前

4つの主要プラットフォームは今、すべてこれを出荷しています。それぞれが違う名前で呼びます。言葉は本来より大きな意味を持ちます。ウェアハウスのチームは自分たちのオブジェクトを自分たちの名前で知っていて、間違った言葉はその会話を必要以上に難しくします。

Salesforce Data 360

Data 360 に登録されたセマンティックモデル。それが供給する質問画面は Tableau Semantics です。

Snowflake

Horizon Catalog にカタログ化されたセマンティックビュー。それが供給する質問画面は Cortex Analyst です。

Databricks

Unity Catalog にカタログ化されたメトリクスビュー。それが供給する質問画面は Genie です。

Palantir AIP

Foundry でパブリッシュされたオントロジー。オブジェクト型がエンティティとそのディメンションを運び、Function がメジャーの宣言される場所です。

4つの名前、ひとつの形。それぞれが、エンティティ、ディメンション、メジャーを保持する名前付きのオブジェクトです。それぞれがプラットフォーム自身のカタログの中にあるので、プラットフォーム自身のツールがそれを尊重します。Foundry は、あなたのためにメジャーを名付けてはくれない唯一のものです。誰かが自社にはセマンティックレイヤーがあると言うとき、指しているのはこのオブジェクトです。何を保持しているかを尋ねるより、4つのうちどれを作ったかを尋ねるほうが早く答えにたどり着けます。

実際の利用からの注意点をひとつ。稼働中の Snowflake アカウントを調べて学んだことです。そこではディメンションはエンティティで修飾されなければなりません。同じディメンション名が異なる粒度で2つのエンティティに設定されていることはよくあり、名前だけではどちらとも取れます。Snowflake はそれを曖昧として拒否します。それは正しい振る舞いで、同時に戸惑う出だしになります。

複数のウェアハウスを動かす

ひとつのプラットフォームの中では、「一度定義する」は短い一文です。ある程度の規模の会社の大半は、少なくとも2つのプラットフォームを動かしています。それは変わりません。

すると同じ論理テーブルが、プラットフォームごとに一度ずつ、2つのチームによって2つのレビュープロセスのもとで、二度定義されます。どちらの定義も統制されています。それでも2つは離れていきます。どちらのプラットフォームの中にも、相手を見張るものはありません。

Boreon のタブトータルは、カタログをひとつのオブジェクトモデルに読み込みます。同じスキーマとテーブルが複数の場所に現れることがあります。それはつながりのない別々のオブジェクトではなく、由来するすべてのソースを記憶するひとつのオブジェクトとして着地します。次に、接続されたウェアハウスのすべてのペアが比較され、2つの構造が食い違うところでは、その隙間がそのペアを名指しするガバナンス所見として記録されます。会議ではなく、レポートで読むことになります。

その比較は、カタログが宣言していることを読みます。答えが一致するかを見るために、ひとつの質問を複数のウェアハウスに投げることは決してありません。複数のウェアハウスのフィールドを名指しするクエリは、振り分けられるのではなく拒否されます。両方の下に共通のエンジンがないからです。

継承するもの

カタログを打ち直すよう求めるセマンティックレイヤーは、第二のカタログになります。第二のカタログは古くなります。最初の同期はすでに存在するものを読みます：テーブル、列、コメント、タグ、キー、権限付与。命名規則はそこに加わるもので、決して要求されません。期待されるパターンのどれにも合わないウェアハウスも、丸ごと入ってきます。

レイヤー名は、オブジェクト自身の修飾されたラベルから来ます。オブジェクトについてのコメントがそれを決めるのではありません。meta にあるテーブルは meta レイヤーにあります。gold にあるテーブルは gold にあります。レイヤー名のリストは開かれています。誰もツールに教えていない名前でも、正しく着地します。閉じたリストなら、出会ったことのない他のすべての規則とともに、それを「不明」に潰していたでしょう。

宣言されたコメントとオブジェクトのラベルが食い違うところでは、両方が保持され、その隙間自体が所見になります。あなた自身の分類を引き受けることと、それが自分自身と言い争っているのを見つけることは、同じ仕事です。

なぜ契約は強制されるのか

何も検査しないパブリッシュ済みの定義は、文書です。価値はある瞬間に現れます。クエリがメジャーを名指しします。そのクエリが走る前に、保存された定義が検査されます。

この製品では、ウェアハウスに届く名前は契約自身のコピーです。契約の外の名前には、ウェアハウスへのコードパスがまったくありません。クエリは、何が契約外だったかを名指しして戻ってきます。結果には行数の上限もあります。

この性質はコードに組み込まれたもので、指示に書かれたものではありません。モデルへの指示は無視されうる。存在しないコードパスは説得されようがない。サイトを運用する人にとっての効果は、狭く、役に立ちます。この製品を通せば、統制されたメジャーの計算方法はひとつしかなく、それが公式のものです。

見る場所

• セマンティックコンソールは、ウェアハウスごとに何が同期されたかを、件数とパリティチップとともに示します。
• 連携コンソールは、各接続がどの認証情報を使ったかを、ホスト、ロール、ウェアハウスとともに示します。秘密そのものは決して現れません。
• フィールドレコードは、所有者、スチュワード、分類を含むフィールドごとの9つの属性を運びます。何が文書化され、何がされていないかが見えます。

最初の同期は、所有者の大半が不明と報告することがよくあります。ツールは正常に動いています。見えているのは、今日あなたのカタログのどれだけが文書化されているかを、そのまま示したものです。空のレイヤーはゼロ点です。ゼロは、持つ価値のある唯一の出発点です。