はじめに
連載「Genie Codeと学ぶDatabricks」の第5回です。
今回はAI/BIダッシュボードです。第4回でパイプラインが作ったマテリアライズドビュー workspace.tpch_learning.monthly_order_totals (1998年の月別受注金額サマリー、8行) をソースにして、チームの誰もがブラウザだけで見られる形にします。
先に今回の結論を言ってしまうと、ダッシュボードを「作る」工程はGenie Codeで数秒に縮みます。だからこの記事の関心は、作った後に人間に残る仕事は何か、です。答えは2つあって、数字の出どころを確かめることと、誤読を防いで届けることでした。環境はDatabricks Free Editionです。
なぜ生データではなくマテリアライズドビューをソースにするのか
手を動かす前に、設計の話を1つだけ。ダッシュボードのソースは、samples.tpch.ordersの生データ (750万行) からでも作れます。しかし今回は、あえて集計済みのマテリアライズドビュー (8行) をソースにします。理由は3つあります。
1つ目は責務の分離です。「1998年に絞って月別に合計する」という集計ロジックをダッシュボード側に持たせると、ダッシュボードが増えるたびに同じ集計の亜種が画面ごとに増殖していきます。集計は上流のパイプラインに一元化し、ダッシュボードは表示に徹する。直す場所が常に1箇所になります。
2つ目はグラフの描きやすさです。集計済みのビューでは、order_monthは日付型、total_amountとorder_countは数値型と、型が整理されています。ダッシュボードのウィジェットは「この列をX軸に、この列をY軸に」と割り当てるだけで済み、AIに作らせたときの事故 (月を色分けのカテゴリとして扱ってしまう、など) も起きにくくなります。
3つ目は鮮度の自動化です。ソースがマテリアライズドビューなら、第4回のパイプラインを実行するだけで集計が更新され、ダッシュボードは次に開いたときに最新の数字を映します。
この回から読み始めた方は、第4回に戻らなくても大丈夫です。SQLエディタで次の1本を実行すれば、同等のマテリアライズドビューが作れます。
CREATE SCHEMA IF NOT EXISTS workspace.tpch_learning;
CREATE OR REPLACE MATERIALIZED VIEW workspace.tpch_learning.monthly_order_totals AS
SELECT
DATE_TRUNC('month', o_orderdate) AS order_month,
COUNT(DISTINCT o_orderkey) AS order_count,
SUM(o_totalprice) AS total_amount
FROM samples.tpch.orders
WHERE YEAR(o_orderdate) = 1998
GROUP BY DATE_TRUNC('month', o_orderdate);
作る: いつも通りGenie Codeに任せる
フルページ型のGenie Codeに仕様を渡します。
workspace.tpch_learning.monthly_order_totalsを使って、
AI/BIダッシュボードを作成してください。
- 月別の受注金額合計の棒グラフ
- 月別の注文件数の折れ線グラフ
- 総受注金額と総注文件数を表示するカウンター
- タイトルと軸ラベルは日本語にする
上段にカウンター2つ、下段に棒グラフと折れ線グラフ、という素直なレイアウトが一発で出てきました。棒グラフは単色、折れ線は1本の線で月をつないでいて、余計な色分けも凡例もありません。ソースの型が整理されていれば、AIのグラフ選択も素直になる。前段の理由2がそのまま効いています。
ただし1箇所、引っかかるところがあります。総受注金額が「¥101B」と円表記になっているのです。Genie Codeの作業ログを見ると「通貨形式 (JPY) を設定しました」とあり、日本語ラベルの指定から気を利かせて通貨まで日本円にしてくれたようです。TPC-Hの金額は名目上ドルなので、これは親切による誤りです。頼んでいないことを上手にやってくれて、それが間違っている。この連載で繰り返し見てきたAIの過剰サービスの、最小の実例です。フォローアップで直します。
通貨形式をJPYではなくUSDに変更してください
この指示だけで、カウンターの表示が$101Bに変わっただけでなく、棒グラフのY軸の通貨表示も併せて修正されました。影響するウィジェットを自分で特定して両方直してくれるあたりは頼もしいところです。
作る工程は、これで完了です。ノートブック、パイプラインと作らせてきた連載の流れの中でも、ダッシュボードは一番あっけない。だからこそ、ここから先が本題です。
確かめる: 数字の出どころをたどる
配る前に、このグラフの数字がどこから来ているのかを自分の言葉で説明できるようにしておきます。ダッシュボードの構造は2層です。見た目を担当するウィジェット (グラフ、カウンター、テキスト) と、数字を担当するデータセット。この構造が見えるのがデータタブです。
データタブを開くと、データセット「月次受注データ」はSQLとして定義されています。ただし、その中身は実質これだけです。
SELECT * FROM monthly_order_totals
集計ロジックはダッシュボードの中にはありません。それは前段の設計通りで、月別集計はマテリアライズドビュー側で済んでいるからです。結果テーブルには8行が並び、8月のorder_countが6,205件と、他の月の9万件前後に対して桁違いに小さいこともここで確認できます。後で効いてくる数字なので覚えておいてください。
だから数字を検証する経路はこうなります。ウィジェット → データタブでソースを確認 → カタログエクスプローラーでmonthly_order_totalsを開く → リネージをたどると第4回のパイプラインに行き着き、そこに集計の定義 (SDP) がある。第2回で見たリネージと第4回で読んだSDPが、ここで検証の道具として回収されます。「このグラフの数字、合ってる？」に、勘ではなく経路で答えられる。これが1つ目の人間の仕事です。
整える: 部分月は誰も注釈してくれない
2つ目の仕事は誤読への手当てです。恒例の部分月問題 (第1回から数えて4回目) が、ここで一番深刻な形で現れます。
月別グラフの1998年8月は、データが8月2日までしかないため末尾が急落して見えます。ノートブックで自分が見ている分には「8月は途中まで」と本人が知っているので実害はありませんでした。しかしダッシュボードは、その文脈を知らない人が見る道具です。何も手当てしなければ、見た人は「8月に何かあったのか」と誤読します。
対処は、テキストウィジェットで注記を入れる、集計から部分月を除外する、フィルタで期間を制御する、のいずれかです。私は注記を選びました。データを加工せず、事実をそのまま見せて文脈を足す方が、この規模のダッシュボードでは誠実だと思うからです。
作業自体はGenie Codeに任せます。ダッシュボード上のGenie Codeにこう依頼しました。
月別受注金額のグラフの近くに、テキストウィジェットで注記を追加してください。
内容: ※1998年8月は8月2日までの部分データです。月次のトレンドを見る際は
8月を完全な月として扱わないでください。
ここでの役割分担がこの記事の主張そのものです。注記が必要だと気づくこと、何と書くかを決めることが人間の仕事で、ウィジェットを配置する手作業はAIに任せてよい。AIはグラフを数秒で作りますが、そのグラフが誰にどう誤読されるかまでは考えてくれません。「文脈を知らない人がこれを見たら何と解釈するか」を配る前に一周考える。編集者の仕事に近いこの工程が、AI時代のダッシュボード作りで一番価値の残る部分だと思います。
届ける
共有ボタンから他のユーザーやグループに公開します。閲覧側に必要なのはブラウザだけで、ワークスペースの操作もSQLの知識も要りません。ソースはマテリアライズドビューなので、第4回のパイプラインをスケジュール実行すれば数字は自動で最新化されます。「ノートブックを再実行してグラフを貼り直す」という手作業は、もうどこにもありません。
これで、生データからパイプライン、集計、ダッシュボード、共有までがつながりました。第1回で「データ分析が一周回った」と書きましたが、今回で「データ活用が一周回った」ことになります。
補足: Genieという名前について
ダッシュボードの周辺を触っていると「Genie」の名前に何度も出会うので、混乱しないよう整理しておきます。DatabricksのGenieは今や単一の製品名ではなくファミリー名で、この連載の相棒であるGenie Code (開発者向け)、データに自然言語で質問できるGenieエージェント、データ資産を横断するチャットのGenie Oneがいます。Genieエージェントは以前はGenieスペースと呼ばれていたもので、古い記事やUIにはスペース表記が残っています。役割で言えば、ダッシュボードは「作り手が決めた質問への答え」を配る道具、Genieエージェントは「想定外の質問」を受ける道具で、この連載で扱ったのは前者です。
まとめ
Genie Codeにダッシュボードを作らせて届けるまでをまとめます。
- ダッシュボードのソースは生データではなく集計済みのマテリアライズドビューに。責務の分離、グラフの描きやすさ、鮮度の自動化の3点で効く
- ダッシュボードを「作る」工程はGenie Codeで数秒。人間の仕事はその後にある
- 確かめる: 数字の検証は、データタブ → ソースのMV → リネージ → パイプラインという経路でたどれる。勘ではなく経路で答える
- 整える: 部分月のようなデータの文脈は、配った先では誰も補ってくれない。注記が必要だと気づき、何と書くかを決めるのが人間の仕事。配置はAIに任せてよい
- ソースがマテリアライズドビューなら、パイプラインのスケジュール実行だけで数字が最新に保たれる
一番の収穫は、ダッシュボード作りの重心が「作る」から「確かめて、整える」へ完全に移ったと実感できたことでした。作る速度はAIで上がるほど、出どころを説明できること、誤読を防げることの価値が相対的に上がっていきます。
次回はLakebase編です。分析の世界から一歩出て、レイクハウスの隣にPostgreSQL互換のトランザクショナルなデータベースを立てます。
参考リンク
- AI/BIダッシュボード (日本語ドキュメント)
- Genieエージェント (日本語ドキュメント)
- 第1回: 入門編
- 第2回: Unity Catalog編
- 第3回: Delta Lake編
- 第4回: Lakeflow編