2026/10/06 に「Microsoft Fabric 入門」が技術評論社から発売されます。
著者の一人であり、第 4~6 章の執筆を担当された株式会社ジール (企業 HP / LinkedIn) の 永田亮磨さん (X / LinkedIn) から本書籍を献本いただきました。
書籍を一通り内容を読むことができましたので感想を本投稿で残しておきたいと思います。
投稿時点では発売前の書籍となり、購入できるのは少し後となりますが、興味を持たれている方の参考になれば幸いです。
SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
Data Factory のコピーアクティビティーを使用したデータコピーでは、ステージングコピー を使用することができます。ステージングは、DWH に対してデータコピーを行う際に使用されるケースがあるのではないでしょうか。
ステージング コピーのしくみ には次の記載があります。
コピー アクティビティの実行後に一時データをクリーンアップできるように、ステージング ストレージ内の Azure Data Factory に削除アクセス許可を付与する必要があります。
コピーアクティビティにより格納されたステージングデータですがアクティビティ内のクリーンアップで自動的に削除が行われます。
しかし、Azure BLOB ストレージを使用している場合は問題ないのですが、ADL Gen2 をステージングアカウントとして使用した場合、コピーアクティビティが実行されるたびに、指定したステージングデータを格納するコンテナー内にファイルは存在しないのですが、GUID のディレクトリが残った状態となるという事象が発生します。
本事象ですが、ADL Gen2 をステージングアカウントととして指定した場合に必ず発生するわけではなく、コピー先によって発生有無が変わってくるようです。今回は、Fabric の Data Warehouse に対してデータのコピーを実施する際に発生しましたが、Synapse DWH でも発生するはずです。
この動作は現時点では想定された動作となり (SR で確認済み) 、ディレクトリの削除をパイプライン内で実行するためには本投稿のような対応を検討する必要がありますので、対応方法を残しておきたいと思います。
Microsoft Fabric のネットワーク接続で使用できる機能をまとめておきたいと思い、最初にプライベートリンクを使用した Microsoft Fabric への接続制御 (受信方向)
Fabric のセキュリティについては次のドキュメントから確認できます。
パブリックアクセスをブロックすることで、プライベートエンドポイント経由でのみ、Fabric へのアクセスを許可することができますが、Fabric にデータを格納するための既存のパイプラインのアクセスにも影響がでる可能性があります。
パブリックアクセスをブロックする場合には、途中からブロックするのではなく最初からブロックする設定を行っておいたほうが良いかと。(私が使用している環境では、ADF から Fabric へのインポートがブロックされるようになり、ADF で作成していた Fabric 向けのパイプラインがエラーとなりました)
Microsoft Fabric の Synapse Data Warehouse は、OneLake に対して T-SQL のエンドポイントを提供し、T-SQL による既存データの参照 (SELECT) だけでなく、テーブルの作成 (CREATE TABLE) / 更新系 (INSERT / DELETE / UPDATE) を可能とする機能となっています。
Synase Analytics の Dedicated SQL Pool と Serverless SQL Pool と近しい機能がいくつか実装されています。(Data Warehouse に対してエラーが発生した際に「Synapse SQL」というメッセージが返ってくることがあるため、Data Warehouse でも Synapse の Serverless SQL プールの分散クエリのアーキテクチャは採用されているかと思いますが)
大きな変更点として実データを格納するデータストアとして、SQL Server ベースのデータベースではなく、Delta Lake が採用されているという点があるのではないでしょうか。
厳密には SQL Server のクエリエンジンを使用するため SQL Server ベースのデータベース相当のものも一部存在しているとは思いますが。
Fabric の Data Warehouse の特性を把握するために、一読しておく必要があるドキュメントとしてはどのようなものがあるかをまとめておきたい思います。
Fabric が Public Preview でリリースされた当初は、Warehouse に対しての変更の Delta Lake ログの発行は「Insert Only」となっていました。
そのため Microsoft Fabric のウェアハウスの Delta Lake ログ には次の制限が記載されていました。
Currently, tables with inserts only are supported.
現在、挿入のみを含むテーブルはサポートされています。
Warehouse に対して Insert を実行した場合は、Lakehouse で Warehouse のショートカットとして追加している Warehouse の結果に対しても反映が行われていましたが、Update / Delete を Warehouse に実行した場合、同期が停止されるという動作となっていました。
これにより、Warehouse で Insert 以外の変更を実行すると、以降は Lakehouse で検索を行っても期待した結果が返ってきませんでした。
最近、Fabric を触る機会があったので、このあたりの動作が今はどうなっているのか確認してみたところ、現状、この制限が解消されていたようでした。
ドキュメントの更新履歴を確認したところ 20231025 Kevin Conan – Removed insert only limitation for Delta Log Publishing で Insert のみ、同期がサポートされるという制限は撤廃されていたようです。
実際に今の Fabirc の Warehouse に対して Insert 以外の変更を実施すると Lakehouse に変更が反映されていました。
本日、Microsoft Fabric の Mirroing Databases の機能が Public Preview で提供されました。
Mirroring については、What is Mirroring in Fabric? のドキュメントツリーから確認することができます。
Mirroring は SQL Database だけでなく Cosmos DB / Snowflake からも同期することができ、面白そうな機能ですね。
基本的な内容についてはドキュメントを確認すれば把握できますが、SQL Database からの連携について、実際に設定しながら試してみて気づいた内容を残しておきたいと思います。
Build 2023 で発表されていますが、Power BI / Microsoft Fabric のレポート開発において Git 統合 / 開発者モードが提供されます。
アナウンスについては Introducing git integration in Microsoft Fabric for seamless source control の Git integration and Power BI Desktop ‘Developer Mode’ となるのではないでしょうか。
Power BI のレポート作成を行う際に、従来までの Power BI ファイル (pbix) では 1 ファイルで管理されるため (pbix は zip 圧縮されたファイルのため、実際には複数のファイルで構成はされているのですが) 、ファイルをソース管理で管理するには効率が悪い点があったかと思います。
今回から導入される Git 統合 / 開発者モードでは、Power BI のレポートを作成する際に Power BI プロジェクト (pbip) や Power BI レポート (pbir) というようなファイルを使用して、レポートの構成要素に応じた複数のファイルで管理されるようになります。
この機能についてどの情報を確認すればよいかが、公開されている情報が増えてきたので、内容をまとめておきたいと思います。