Skip to content

実践のメトリクス契約:固定された定義から実行されるクエリまで

メトリクス契約とは、何かが実際に強制したときのセマンティックレイヤーの姿です。定義がどう固定されるか、2つのウェアハウスのフィールドを名指しする質問に何が起こるか、そして SQL に届く識別子が契約そのものから来る理由。

更新 · 6 分で読めます

パブリッシュされた定義から固定された定義へ

パブリッシュされた定義と固定された定義は、カタログブラウザーでは同じに見えます。どちらも名前、式、所有者を運びます。違いは、誰かが質問する瞬間に現れます。

固定とは、レイヤーがプラットフォーム自身の契約オブジェクトを一度読み、見つけたものを保存することです:メンバー、その式、由来するオブジェクト。それ以降のすべての質問は、尋ねた人が入力したものではなく、保存されたコピーに対して解決されます。

保存されたコピーは名前と式を保持し、行は決して保持しません。同期のたびに学び直されます:火曜日にウェアハウスで追加されたメジャーは火曜日の同期で届き、誰もそれを打ち直すことを覚えておく必要はありません。

契約が保持するもの

学習された契約は短く退屈な文書で、その退屈さが機能です。

  • 学習元のオブジェクト:セマンティックモデル、セマンティックビュー、またはメトリクスビュー。完全な名前で。
  • ディメンション。それぞれが属するエンティティと、その下のフィールドを運ぶ。
  • メジャー。それぞれが集計とフィールドを運ぶ。
  • プラットフォームがパブリッシュしたシノニム。ビジネスの言葉がその背後のメンバーを見つける方法。

契約は、記述であると同時に許可リストです。人に何が存在するかを教える文書が、クエリビルダーに何が実行してよいかを教える文書です。同期させ続けるべき第二のコピーは決して存在しません。

尋ねられる名前

4つのプラットフォームすべてが同じものを定義でき、4つすべてがメンバーの呼び方について独自の考えを持ちます。最初のクエリの前に語彙を決めておく価値があります。最初のいくつかの失敗は、ほぼ常にモデリングではなく命名の失敗だからです。

Salesforce Data 360
メンバーはエンティティと名前でキー付けされ、そう書かれます。ちょうどひとつのメンバーが持つ短い名前は、便宜としてなお解決されます。
Snowflake
メンバーはエンティティで修飾されなければなりません。複数に一致する裸の名前は、修飾された候補を列挙して戻ってきます。
Databricks
メンバーはメトリクスビュー自身のディメンションとメジャーの名前で、ビューが作られたときの定義から取られます。
Palantir AIP
メンバーはオブジェクト型と名前でキー付けされます。メジャーは、宣言された出力が数値である Function からのみ読まれます。オントロジーは型付きプロパティを公開し、独自のメジャーを宣言しないからです。

名前だけでなくエンティティと名前の組でキー付けするのは、ドキュメントを読んでではなく、稼働中のアカウントに対して動かして生まれました。そこでは5つのセマンティックビューがそれぞれ同じディメンション名を2つのエンティティに定義していました。ひとつは文書の粒度、もうひとつはセクションの粒度で。名前だけをキーにした辞書は双子をどちらにも属さないひとつの項目に統合しました。何もエラーにならず、その上に築かれたすべての答えは、誰にも見えない形で間違っていたはずです。

ひとつの質問、ひとつのウェアハウス

2つの異なるウェアハウスのフィールドを名指しする質問は、望むのは妥当で、実行するのは無理なものです。2つの契約は2つのエンジンに属し、両方の下に第三のエンジンはありません。

レイヤーは同じオブジェクトで2つの仕事をし、それらを分けておきます。インベントリでは、複数のウェアハウスで見られた同じスキーマとテーブルは、由来するすべてのソースを記憶するひとつの論理オブジェクトになり、それが比較レポートをそもそも可能にします。実行では、契約は学習元のウェアハウスに属し、クエリはそこへ振り分けられます。2つの契約を混ぜた質問は、何が混ざったかを名指しして戻ってき、たまたま先に載っていた契約に静かに解決されることは決してありません。

ひとつのウェアハウスの中では、同じ形が一段下に現れます。2つのエンティティの関係を宣言しないモデルは、それらにまたがる質問に答えられず、ウェアハウスは自身の言葉でそう言います。それは読む価値のあるモデリングの答えです:全員が存在すると思い込んでいた結合が、一度も宣言されていなかったと告げています。

ウェアハウスを横断して比較することと、ひとつの中で計算することは別の仕事です。分けておくことが、同じテーブルをガバナンスレポートに一度現し、それでも正確にひとつのエンジンで計算させるものです。

なぜ識別子は契約から来るのか

質問が文になるとき、その文に置かれる文字列は契約自身のコピーです。呼び出し側が入力したものはメンバーを探すのに使われます。SQL に届くのは、同期が保存したものです。

小さな区別で、3つのことを同時に決着させます。

  • 契約にない名前には、ウェアハウスへの経路がまったくありません。統制されたメジャーには、この製品を通じて計算されるちょうどひとつの方法があります。
  • 識別子は学習時に文字集合で制限され、文を組み立てるときにもう一度検査されるので、改ざんされた保存済み契約は実行中ではなく、文の組み立て中に失敗します。
  • 結果には行数の上限があり、統制された質問を、手順の増えたエクスポートではなく質問のままにします。

この性質はアーキテクチャ的なもので、指示的なものではありません。承認された名前だけを使うようモデルに言うことはできますが、十分に奇妙な会話はやがてそれを説き伏せます。書かれなかったコードパスには、説き伏せられるものがありません。

名前が契約外のとき、答えを読む

契約が答えられない質問は、問題を名指しして戻ってき、その答えのほうが機能の役に立つ半分です。3つの形が、出会うほぼすべてをカバーします。

契約外
名前が保存された契約にありません。モデルに一度もなかったか、最後の同期の後にモデルが得たかのどちらかです。何かを結論する前に、同期してもう一度尋ねてください。
曖昧
短い名前が複数のエンティティのメンバーに一致します。修飾された候補がメッセージとともに届きます。
エンティティが関連していない
ウェアハウス自身が、2つのエンティティに宣言された関係がないと報告しています。これは質問した人ではなく、モデルを所有する人のものです。

これらのメッセージは、ステータスコードにならされるのではなく、ウェアハウスから一字一句そのまま届きます。自身の答えを説明するコンパイラーは、その言い換えよりほぼ常に正確で、言い換えこそが、ずっと正常だったホストをデバッグしに誰かを送り出すものです。

自分のサイトで見る場所

  • セマンティックコンソールは、ウェアハウスごとに何が同期されたかを件数とパリティチップとともに示し、各バックエンドが学習した契約を描画します。
  • 契約は同期のたびに学び直されます。欠けたメンバーへの最速の答えは、たいていもう一度の同期です。
  • すべての統制されたクエリは記録されます。答えられたものも追い返されたものも同様に、行数を保持し、返されたセルは何も書き留めません。

最後のものは、二度見る価値があります。結果の形を保持し内容を捨てることが、監査証跡を何年も安全に保てるものにし、何年こそが監査証跡の唯一有用な長さです。