Azure DatabricksのGenie Codeに搭載されたBeta機能「Import BI files using Genie Code」を検証しました。
TL;DR
| 観点 | 内容 |
|---|---|
| できること | .pbitファイルをGenie Codeに渡すと、Databricks上にスキーマ、テーブル、Metric View、ダッシュボードが自動生成される |
| 意味 | Power BIに閉じていたBI資産(モデル、メジャー、レイアウト)がDatabricks側に移植可能になる |
| 限界 | BI層は運べるが、データそのものとカタログ設計は別途必要 |
Power BI Desktopのレポートを、、、
Genieにお願いするだけで、、、
Databricksのワークスペースにニア再現
この機能の背景（考察）
そもそもこの機能は何をしているのか整理しておきます。
理由は「DAX」にあると思う
Power BIのダッシュボードを支えているのは、Microsoft独自の計算言語 DAX (Data Analysis Expressions) です。今回使用しているデータにも約30個のDAX指標が含まれています。
たとえば「市場シェアの直近12か月移動平均」のような指標は、典型的にこのような式で書かれます。
市場シェアの直近12か月移動平均.dax
% Units Market Share =
DIVIDE(
[Total VanArsdel Units],
[Total Category Volume]
)
% Units Market Share R12M =
CALCULATE(
[% Units Market Share],
DATESINPERIOD(
'Date'[Date],
LASTDATE('Date'[Date]),
-12,
MONTH
)
)
DAXはSQLとは異なるパラダイムで、CALCULATEによるフィルタコンテキストの操作、TIME INTELLIGENCE関数群、行コンテキストとフィルタコンテキストの相互作用といった独特の概念を持っています。
BI業界でも「習得難易度が最も高い言語の一つ」とよく言われており、私自身も慣れるまでに時間がかかりました。
.pbitが運ぶもの
今回Databricksにほぼ半自動で送るには、「.pbitファイル」が必要です。
.pbitファイルは中身がZIPで、解凍すると以下のような構成になっています。
| ファイル | 役割 |
|---|---|
DataModelSchema |
テーブル、列、メジャー(DAX)、リレーションシップの定義 |
Report/Layout |
ページ構成、ビジュアル、配置、フィルターパネル |
Connections |
データソース接続情報 |
Metadata / DiagramLayout
|
バージョン情報、モデル図のレイアウト |
ここで重要なのは、.pbitにはデータそのものは入っておらず、モデルとロジック (= DAX式) がすべて含まれているということです。
つまりPower BI Desktopで構築した知的資産だけを、数MBのポータブルファイルとして取り出せる仕組みになっています。
Genieは何をしているか
Databricks Genieの/importBIコマンドは、次のようなことをしているのではないかと考えています。
-
.pbitを解凍してDataModelSchemaとReport/Layoutを読み取る - テーブル定義から
CREATE TABLEを生成する - DAX式を読み取って、SQLやMetric View YAMLに翻訳する (ここがコア)
- ビジュアルJSONをDatabricks Dashboardの
.lvdash.jsonに変換する - データが存在しない場合は、サンプルデータの生成SQLまで提案する
特に重要だと感じたのは、DAXが Metric View(YAML 定義のセマンティック層)に変換される点 です。これにより、BIツール固有の式言語がDatabricks側の宣言的なセマンティック定義に翻訳されます。
例えば、DAXのCALCULATEとDATESINPERIODを組み合わせた時間軸計算は、SQLのウィンドウ関数や日付テーブルを使った自己結合に書き換える必要があります。
ここの精度がそのまま完成品の品質を左右していると感じています。
実際、検証ではシンプルな指標 (合計、平均) はほぼ正確に翻訳されたものの、比率系・時間軸計算系のDAXは意図と異なるSQLに置き換えられるケースがありました。本記事冒頭で「6〜7割の完成度」と書いた根拠の一つはここにあります。
Power BI Desktopからの解放
従来Power BI Desktopのみを始めるときに立ちはだかっていた壁と、Genie Code経由で何が変わるかを比較すると次のとおりです。
| 壁 | Power BI Desktop | Genie Code経由 |
|---|---|---|
| ツールの導入 | Windows + Desktopアプリ必須 | ブラウザのDatabricksのみ |
| 計算ロジック | DAXを書ける人が必要 | Metric View(YAML)で宣言的に管理 |
| データ変換 | Power Query(M言語) | Spark SQL |
| ガバナンス | ファイル/ワークスペースごと | Unity Catalogで一元 |
Power BIを否定したい話ではなく、BI資産が特定ツールに縛られない選択肢が増える という意味で価値があると考えています。
特にPower BIで蓄積された数年分の指標定義を、Databricks側のSQL/Viewとして再利用可能なアセットに変換できるという構造は、単なる移行作業の効率化を超える話だと感じています。
ユースケース (考察)
ここからは検証から見えたこの機能の使い道について、考察を3つ述べます。
1. BI資産の棚卸し・可視化
数百本のPower BIレポートを抱えながら、「どの指標が、どのテーブルから、どう計算されているのか」を把握しきれていない組織は普遍的に存在すると思います。PBIを長年運用されている組織ほど、過去のベテランが書いた複雑DAXが残っていたり、逆に似たような指標が部門ごとに重複していたりするのではないでしょうか。
.pbitを一括投入してDatabricks側でカタログ化できれば、
- どの指標が何件あるのか
- 重複している指標はないか
- 使われていないKPIはどれか
- どのテーブル・カラムに依存しているか
といった俯瞰が可能になるはずです。これまで台帳管理していたようなBI資産の棚卸しが、構造化された形で自動化される可能性があります。
2. DAX↔SQLの対応
ここが個人的に最も実務的な価値を感じている部分です。
Power BIとDatabricksは、それぞれ独自の言語と思想を持っているので、現時点で両方を深く理解できる人材は限られていると思います。
Power BIを使うユーザーはDAXやPower Query (M言語) をメインで、DatabricksのエンジニアはSQLやPySparkをメインで使う、というようにスキルセットが若干分断されている印象を受けます。
.pbitをインポートすると、Genieは元のDAX式と、それを翻訳したSQL / Metric View YAMLを並べて見せてくれます。これは結果として、
- 「うちのDAX、Databricksではこう書けるのか」がPower BIチームに伝わる
- 「Power BIではこう計算していたのか」がDatabricksチームに伝わる
- 翻訳が正しくできなかった箇所から、移行時に手当てが必要なポイントがあぶり出される
という、知識移転とリスク評価が同時に進む状態を作れます。
検討前に、両組織間のコミュニケーションコストを下げる教材 としての価値が大きいのではないかと考えています。移行もしくは導入を決断する前段階、つまり「やれるかどうかを見極めるフェーズ」で効くタイプの価値だと思います。
3. DAXのMetric View展開
Power BI内に閉じ込められていた指標は、これまで「Power BIを開かないと見えない計算」でした。これがUnity CatalogのMetric Viewとして登録できれば、
- Tableau / Looker / Excel / Genie / AIエージェントなど、異なるツールから同じ指標定義を参照できる
- 計算の中身を変えれば、全レポートが一斉に追従する
- アクセス権や系統管理がUnity Catalogで効く
という、いわゆる 「セマンティックレイヤーを民主化できる入口」 になるのではないかと考えています。
DAXというある種の特殊技能で書かれていた知的資産が、SQLが読める人なら誰でも理解・再利用できる形に変換される、そのインパクトは単なる効率化を超えていると感じています。
現状の限界
データ移行とカタログ設計が本丸
今回の検証は、データそのものは移行させず、Genieにサンプルデータを生成させた前提で動かしています。つまり.pbitに載っていた「BIのガワ」が綺麗に運べただけで、本番で価値を出すには別途データそのものをどうDatabricksのカタログに集めるか、またどう運用するかという課題が残ります。
| 観点 | 課題 | 検討の方向性 |
|---|---|---|
| データ取り込み | 元データはどこにあるか(オンプレDB、SaaS、ファイル) | Lakehouse Federation、DLT、Auto Loader |
| カタログ設計 | catalog / schema / tableの粒度と命名 | 業務ドメイン単位での標準化 |
| 権限 | Power BIのワークスペース権限相当をどう表現するか | Unity CatalogのGRANT設計 |
| 履歴 | 既存.pbixが持つ過去データの扱い | 一度エクスポートして取り込みパイプラインに乗せる |
これらが固まっていない状態で.pbitだけ流し込んでも、見た目は動くけれど運用に乗らない、というのが正直なところだと思います。
この機能の価値は「BIの再現を"半自動"でできる」ことであり、裏を返せば 「データ基盤さえ整っていれば」という前提の上に成り立っているとも言えます。
ショートカット連携やミラーリング連携が進んでいるので、ここのカタログ設計がキーになってくると思われます。
苦手領域
また、上述の通り、DAX → Metric Viewの変換にも、現時点で得意/不得意があると感じました。
| 種類 | 翻訳のしやすさ |
|---|---|
| 単純な集計(SUM、COUNT、AVG) | 得意 |
| 単純な比率(DIVIDE) | 得意 |
| Time Intelligence(R12M、YTD) | おおむね対応するが要確認 |
| 複雑なフィルターコンテキスト操作 | 人間によるレビュー前提 |
| ビジュアル固有の細かな書式 | 完全再現は難しい場合あり |
ピクセルパーフェクトな帳票、3層ネストのDAXタイムインテリジェンス、オンプレ専用環境などは現状想定されていないかなと感じました。
結論
今回登場した /importBI は、Power BI側に蓄積されたBI資産をDatabricksに持ち込むための強力な入口だと感じました。その先にあるのは、単なるPower BI代替ではなく、"BI"から"セマンティックレイヤー + AIネイティブな分析"への進化 かもしれません
| 層 | この機能で運べるか | 別途必要か |
|---|---|---|
| BI層(モデル、メジャー、レイアウト) | 運べる | - |
| データ層(実データ、ETL、カタログ、権限) | 運べない | 設計が必要 |
ただ、逆にこれだけでPower BIからDatabricksへの移行が完了するという話ではないとも思います。移行すること＝Goodと言うわけではないと思いますし、お互いのソリューションに強みがあるので適宜使い分けですね。
現時点ではBeta段階なのでこの先の進化にも期待しつつ、まずは手元の.pbitを一度通してみる、という入り方が現実的だと感じました。
Discussion