Power BIサービスユーザがFabricを使うメリットの現在地

## はじめに
FabricのPublic Preview以降、毎週のように発表される新機能をワクワクしながら確認してきました。個人的に思っているPower BIサービスを展開しているユーザがFabricを使うことで得られるメリットを纏めます。
## Fabricアイテムを使うメリット
既にPower BIはFabricの一機能の位置づけですので、Fabricアイテムを使うという表現にしています。
個人的には以下４点がFabricアイテムを使うメリットだと感じています。

1. 複数のデータベースアイテム(Warehouse、Lakehouse、Eventhouse、Fabric SQL Database)が使える
1. スケーラビリティ・カスタマイズ性に優れたデータ収集・加工機能（Dataflow gen2、Notebook、Data pipeline)が使える
1. 新しいストレージモードDirect Lakeの活用
1. ミラーリング機能

## 複数のデータベースアイテムが使える
Power BIサービスでは**永続的にデータを保管する機能は提供されていません**。プレビュー機能ではデータマートというアイテムがありますが、プレビューのまま機能強化はされず塩漬け状態です。またDataflow gen1ではPremium機能の**拡張コンピューティング エンジン**（Enhanced Compute engine）を使うことで、裏側ではSQLデータベースに格納されますが、あくまで一時的なキャッシュの位置づけで設定変更などで容易に空になってしまいます。同様にインポートモードのセマンティックモデルも読み取り特化のデータベースで永続的にデータを保管する設計になっていません。結果的に**Power BIサービスではオリジナルデータを永続的に保管する機能がなく**、外部のデータベースやSharePoint上にあるデータが正のデータになっていると思います。

https://learn.microsoft.com/ja-jp/power-bi/transform-model/dataflows/dataflows-premium-features


FabricではOnelake上にデータを一元的に格納しますが、そのデータを扱う堅牢な**ACID特性[^1]を備えたデータベース機能**を複数持っています。これでFabricだけでデータ基盤を作ることも可能になったことは非常に大きなメリットになると思います。

では、複数あるデータベースをどう使い分ければいいのか？を悩みました。Real-Time Intelligence用のEventhouseや、発表したてのFabric SQL Databaseもありますが、Power BIサービスユーザ目線では**Lakehouse**か**Warehouse**が主要な選択肢になると思います。

### LakehouseかWarehouseか？
公式に決定ガイドもありますが、読み解くのが難しいと感じました。

https://learn.microsoft.com/ja-jp/fabric/get-started/decision-guide-lakehouse-warehouse

個人的には以下の理由で**Lakehouse**を優先して使うのがよいと思っています。
1. **ショートカット**が使える
1. **非構造化データ**を扱える
1. **複数言語**（Spark SQL、PySpark（Python））が使える

:::note
ショートカットが非常に便利です。機能的に外部ソース（AWS、GCP等）の仮想化統合に使えることがメリットとして訴求される傾向にありますが、内部ソース（Onelake）のテーブルのショートカットを使えば、後述のDirect Lakeモードのセマンティックモデルで使用するディメンションテーブルの再利用が可能です。
:::

上記のドキュメントはWarehouseとLakehouseの**SQL分析エンドポイント**との比較になっているため、Deltaテーブルは読み取りしかできない記載になっていますが、Notebookを使用してLakehouseをマウントすればSpark SQLやPySparkで**書き込みが可能**です。

SparkSQLはT-SQLより制約が多い印象はあります。上記ドキュメントに記載の**複数テーブルのトランザクション管理ができない**ことや、**ネストしたSQLを受け付けない**などがありますが、PySparkでSQLをラッピングすることで、**より柔軟な処理が可能**だと感じています。


## スケーラビリティ・カスタマイズ性に優れたデータ収集・加工機能が使える
Power BIアイテムでの加工処理はPower BIデスクトップのPower QueryとDataflow gen1を使用することになります。正直、Dataflow gen1でもPower Queryエクスペリエンスが非常に優秀であり、**Premium機能**があれば拡張コンピューティングエンジンや増分更新機能などで**大量データにも充分有用**であると思っていたので、当初はData pipelineやコードベースのNotebookが必要になるイメージが湧いておりませんでした。
今は選択肢が増えることで（学習コストは増えますが）開発生産性が上がり、堅牢なパイプラインを作ることができるケースが多くあると感じています。**Notebook**ではSemantic-Linkを使用したセマンティックモデルの更新など運用上のツールとして今までできなかったことが可能になったり、**Dataflow gen2**ではLakehouseの読み取りに加えて**書き込み**が可能になり、**Data pipeline**でこれらのデータパイプラインをオーケストレーションを行うことができます。

例えばSharePoint上のファイルを構造化データに変換してLakehouseに蓄積するケースでは以下のような**純粋差分**の取り込みの実装が可能になりました。

1. Dataflow gen2でLakehouse上のデータ最終更新日を取得
1. Dataflow gen2でSharePoint上から最終更新日以降に作成されたファイルのみを取得
1. Dataflow gen2でLakehouse上のtempテーブルに差分データを置換
1. Notebookで差分データを読み取り本テーブルにマージ
1. 上記をData Pipeline上でオーケストレーション

##  新しいストレージモードDirect Lakeの活用
Fabric以前のPower BIサービスでは、**インポート**モード、**Direct Query**モード、両方を組み合わせた**Composite**モードの３つがありました。基本はインポートモードを使用し、リアルタイム性もしくはセマンティックモデルに入りきらない大量データの場合にDirect QueryやCompositeモードを検討するという順番で考えると思います。個人的には**Direct Query*やCompositeモードには多くの制限事項があり**、インポートモードと比較してパフォーマンスが劣り、パフォーマンスチューニングに**高度な知識が必要**であることから選択肢になりませんでした。

[DirectQuery に関する制限](https://learn.microsoft.com/ja-jp/power-bi/connect-data/desktop-directquery-about#directquery-limitations)

インポートモードはセマンティックモデルにデータを取り込む処理が必要です。ある程度のボリュームでまでは問題はありませんが、数千万を超えるボリュームになる場合は上述した増分更新の検討が必要です。また、数億を超える場合はXMLAエンドポイント[^2]経由でパーティションごとの更新を行うなどの工夫も必要になります。
Direct Lakeモードでは明示的なセマンティックモデルに**データを取り込む更新を行う必要がありません**。Onelake上のParquetファイルを作成し、セマンティックモデルの**メタデータ**を更新するだけで更新が完了します。それでインポートモードと同等のパフォーマンスがでるという優れた機能になります。

https://learn.microsoft.com/ja-jp/fabric/get-started/direct-lake-overview

:::note info
セマンティックモデルのメタデータを更新する行為を「Framing」と呼びます。Delta Lakeではデータを履歴で持っていますが、最新のバージョンへを指し示す処理になります。
:::

### Direct Lakeモードの制限事項
Direct Lakeモードがいいことばかりではなく、いくつかの制約やデメリットがあります。
主要なところはこの辺だと思っています。

:::note info
当初はRLS、計算グループ、階層が作れないなど、もっと多くの制約がありましたがかなり解消されてきています。
:::
1. 計算列や計算テーブルが使えない
1. ソースデータにViewを使えない（使うとDirect Queryにフォールバックする）
1. SKU別に件数などのガードレールがある。例えばF64では15億件がガードレール条件です。これを満たすとDirect Queryにフォールバックします。

1.と2.については上流でテーブルを準備する必要があります。
また、計算テーブルは今でも作れませんが、フィールドパラメタは作れるようになりました…！
3.についてはフォールバックするとSQLエンドポイントに対してDirect Queryに切り替わるのですが、要は非常に遅くなり、リソースも大量に使ってタイムアウトになることが想定されます。

[Fabric 容量のガードレールと制限事項](https://learn.microsoft.com/ja-jp/fabric/get-started/direct-lake-overview#fabric-capacity-guardrails-and-limitations)

### デフォルトのセマンティックモデルを使用するか新しいセマンティックモデルを作るか？
LakehouseやWarehouseを作成すると自動的にデフォルトのセマンティックモデルが作成されます。しかも消せませんのでちょっと邪魔です💦
デフォルトのセマンティックモデルには多くの制約があるため、**新しいセマンティックモデルを作る**一択です。

以下がデフォルトのセマンティックモデルの制約です。

1. メジャーの書式設定が不可
1. XMLAエンドポイントからの書き込みが不可
1. RLS、計算グループが作れない
1. セマンティックモデル名に日本語が使えない

## ミラーリングの衝撃！
ミラーリングは簡単な設定をするだけでデータベースとFabricのParquetファイルを同期してくれる機能です。**ミラー化されたSnowflake**、Azure SQL Database、Azure Cosmos DB、そして先日オープンミラーリングという機能も発表されました。個人的に試したのはミラー化されたSnowflakeのみですが、前述のDirect Lakeモードと共に利用することでSnowflakeで管理しているデータをセマンティックモデルとして利用するまでの**時間・リソースを圧倒的！に削減する**ことが可能になります。

https://learn.microsoft.com/ja-jp/fabric/database/mirrored-database/overview


### どれ位の時間とリソースを節約できるか？
F64の容量環境で**30億件**のデータからPower BIアイテムのみでインポートモードの複数セマンティックモデルを作成すると時間的にはすべて順列処理として計算すると**23時間**程度かかりました。多重に並列処理をすることで、3時間程度にすることも可能ですが、バックグラウンド処理が**スムージング**[^3]によって平準化された処理容量が蓄積し保持容量を使い果たしてスロットリング[^4]が発生するほどのリソース消費になります。それをミラーリングを使ってDirect Lakeのセマンティックモデルを更新するまで**10分程度**でセマンティックモデルまでの更新が完了するようになりました。勿論、Snowflake側の処理時間が高速なのが要因ですが、この**Snowflakeの能力を引き出すことができる機能**であると思います。※Snowflakeのウエアハウス（＝コンピュートリソース）のサイズはMを使用しています。

https://learn.microsoft.com/ja-jp/fabric/enterprise/throttling


また当初はミラーリングの開始・停止は手動で行うしかなかった為、四六時中更新の有無をSnowflake側に問い合わせをするクエリーが実行されるためSnowflake側のリソース消費が激しいのが難点でしたが、**APIが提供されたため**必要な時にだけミラーリングをすることでSnowflake側のコストも最適化できるようになりました。

https://learn.microsoft.com/ja-jp/fabric/database/mirrored-database/mirrored-database-rest-api

Snowflakeとの連携についてはミラーリング以外にも**Iceberg**テーブルによる統合があり、こちらも注目の機能です。OnelakeがDelata Lakeだけではなく複数のオープンフォーマットに対応し始めのが興味深いです。**Vオーダー**[^5]が適用されていないIcebergテーブルのパフォーマンスが未知数ですが、選択肢が増えたのはいいことです。

https://learn.microsoft.com/ja-jp/fabric/onelake/onelake-iceberg-tables

## おわりに
Power BIサービス（特にPower BI Premium容量使用ユーザ）を使用している方にとってFabricアイテムの活用は多くのメリットがあると思います。同じコストで高度な処理が実装でき、リソース消費も節約できるのがメリットであると思います。

学習コストが増えるのも確かなので、有効な機能を見極めて標準化することで学習コストの低減も必要だと思います。

GAしたとは言えまだまだ新しいサービスであるFabricには課題もあります。
個人的には以下の点の改善を望んでいます。
1. 配置パイプラインでのDataflow gen2及びDirect Lakeモデル対応（Dataflow gen2は来年1月対応予定）
1. AutoML機能のノーコード対応
1. 組織アプリのブックマーク機能対応
1. Power Automateからdata pipelineの呼び出しを可能に
1. Data pipelineでSharePointフォルダのファイルを取得可能に

現在進行形でFabricは進化しています。引き続きワクワクしながらアップデートを追いかけていきたいと思います。

[^1]: ACID特性とはデータベーストランザクションの信頼性を保証する4つの特性。：原子性（全操作が完全に実行）、一貫性（データの整合性維持）、隔離性（独立実行）、持続性（結果の永続保存）。理論的に完全なACID属性はありませんが、RDBMSの基本的な目指すべき機能です。
[^2]: XMLAエンドポイントはXML for Analsyisの略でワークスペースとセマンティックモデルの通信に使用されるプロトコル。デフォルトは読み取り専用となっており、管理ポータルの設定で「読み取り/書き込み」両方の操作が可能になります。
[^3]:スムージング処理とはバックグラウンド処理を24時間で負荷を平準化してくれて一時的にリソースを超えても継続してサービスを使用できるようにしてくれる機能
[^4]:スロットリングとは使用容量が保持容量を超えたときに発生する制限状態。対話処理のスロットリングは少し待てば回復しますが、バックグラウンドの蓄積でのスロットリングは完全にサービスが使えなくなり、保持容量内に収まるまで待つしかなくなります…😢
[^5]:VオーダーとはMicrosoftが発明した、Parquet ファイル形式に対する書き込み時間の最適化とPower BIの高速読み取りを可能にする技術。[Delta Lake テーブルの最適化と V オーダー](https://learn.microsoft.com/ja-jp/fabric/data-engineering/delta-optimization-and-v-order?tabs=sparksql)