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

はじめに

FabricのPublic Preview以降、毎週のように発表される新機能をワクワクしながら確認してきました。個人的に思っているPower BIサービスを展開しているユーザがFabricを使うことで得られるメリットを纏めます。

Fabricアイテムを使うメリット

既にPower BIはFabricの一機能の位置づけですので、Fabricアイテムを使うという表現にしています。
個人的には以下４点がFabricアイテムを使うメリットだと感じています。

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

複数のデータベースアイテムが使える

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

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

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

LakehouseかWarehouseか？

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

個人的には以下の理由でLakehouseを優先して使うのがよいと思っています。

1. ショートカットが使える
2. 非構造化データを扱える
3. 複数言語（Spark SQL、PySpark（Python））が使える

ショートカットが非常に便利です。機能的に外部ソース（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上のデータ最終更新日を取得
2. Dataflow gen2でSharePoint上から最終更新日以降に作成されたファイルのみを取得
3. Dataflow gen2でLakehouse上のtempテーブルに差分データを置換
4. Notebookで差分データを読み取り本テーブルにマージ
5. 上記をData Pipeline上でオーケストレーション

新しいストレージモードDirect Lakeの活用

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

DirectQuery に関する制限

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

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

Direct Lakeモードの制限事項

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

当初はRLS、計算グループ、階層が作れないなど、もっと多くの制約がありましたがかなり解消されてきています。

1. 計算列や計算テーブルが使えない
2. ソースデータにViewを使えない（使うとDirect Queryにフォールバックする）
3. SKU別に件数などのガードレールがある。例えばF64では15億件がガードレール条件です。これを満たすとDirect Queryにフォールバックします。

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

Fabric 容量のガードレールと制限事項

デフォルトのセマンティックモデルを使用するか新しいセマンティックモデルを作るか？

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

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

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

ミラーリングの衝撃！

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

どれ位の時間とリソースを節約できるか？

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

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

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

おわりに

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

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

GAしたとは言えまだまだ新しいサービスであるFabricには課題もあります。
個人的には以下の点の改善を望んでいます。

1. 配置パイプラインでのDataflow gen2及びDirect Lakeモデル対応（Dataflow gen2は来年1月対応予定）
2. AutoML機能のノーコード対応
3. 組織アプリのブックマーク機能対応
4. Power Automateからdata pipelineの呼び出しを可能に
5. 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 オーダー ↩