01製品

定義は一度。どこからでも問い合わせ。

Metricごとに、YAMLの定義はひとつ。どこから問い合わせても同じ正しいSQLになり、結合は自動で見つかり、合計は正しく保たれます。

model.yaml

entities:
  - name: Order
    table: public.orders
    primary_key: id
    dimensions:
      - name: region
        type: string
    measures:
      - name: revenue
        expr: amount
        agg: sum
      - name: order_count
        expr: id
        agg: count

metrics:
  - name: avg_order_value
    expr: revenue / order_count
    format: currency

リクエスト

{ "metrics": ["avg_order_value"],
  "dimensions": ["region"] }

datahashiが書くSQL

SELECT o.region,
       SUM(o.amount) / COUNT(o.id)
         AS avg_order_value
FROM public.orders o
GROUP BY o.region;

結果 · サンプル値

region	avg_order_value
EMEA	118.40
NA	131.52
APAC	104.77

仕組み

ウェアハウスから答えまで4ステップ

セルフホストでもホスト型でも、手順は同じ4ステップです。

01
Query Runnerを動かす
ウェアハウスの隣に、読み取り専用ロールでインストールします。パスワードと監査ログはRunnerが保持します。
```
$ query-runner -config runner.yaml
✓ listening :8787
✓ warehouse reachable (read-only role)
```
02
Metricを定義する
YAMLで書きます。誰かが問い合わせる前に、コンソールがすべての定義を検証します。
```
metrics:
  - name: avg_order_value
    expr: revenue / order_count
✓ 3 metrics valid
# example
```
03
バージョンを公開する
公開すると、モデルとアクセスルールがまとめて固定されます。変更はすべて次のバージョンとして出ます。
```
✓ published v7
  model + access rules, frozen together
# example
```
04
アクセスを配る
アプリにはキーを、エージェントにはOAuthのサインインを。それぞれ許可したMetricだけが見えます。
```
app-finance  key    governed  4 metrics
agent-sales  OAuth  governed  2 metrics
```

コンパイラ

結合（JOIN）は書かなくていい

テーブル同士の関係を一度だけ記述します。datahashiが結合パスを選び、結合の前に合計するので、1対多の結合で合計が膨らむことはありません。

Order.order_totalmeasure

一度だけ宣言

Order → Refund1対多の結合

ファンアウト安全

Refund.reasondimension

返金理由別のorder_total（全理由）· 例示データ1,284,930✓ 二重カウントなし

結合パスはモデルから解決されます。結合で行が重複する前に合計されます。

規模が大きくなっても

Metricが100個になっても変わらないこと

アクセスモード

エージェントには狭く、アナリストには広く

governedキーは名前付きのMetricだけを参照します。exploreキーは実作業のために生のフィールドも使えます。モードはキーごとに固定です。

定義済みMetric · キュレーションされたView · エージェントのデフォルト

Metricを要求 · avg_order_value, revenue
キュレーション済みviewにクエリ · finance_summary
raw measureを要求 · 403 forbidden
raw fieldを読む · このキーには公開されません

ポータビリティ

今のウェアハウスのままで

リクエストはウェアハウスを名指ししません。後から移行しても、呼び出し側は何も変えずに済みます。

Snowflake
BigQuery
Postgres
MySQL

Rollupは頻出の質問を事前に集計し、ウェアハウスを読まずに答えます。

オーナーシップ

すべてのMetricにオーナーがいる

定義には所有チームを記せます。変更は新しいバージョンとして出て、呼び出し側は信頼するバージョンに固定できます。

# model.yaml
- name: Order
  owner: "Finance Analytics"

# a caller pins the version it trusts
{ "metrics": ["avg_order_value"],
  "version": "7" }

次は、エージェントの問い合わせ方

エージェントは、ダッシュボードと同じリクエストを送ります。

エージェントの問い合わせ方を見るコンソールを開く

定義は一度。どこからでも問い合わせ。

ウェアハウスから答えまで4ステップ

Query Runnerを動かす

Metricを定義する