SE の雑記

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 の基本アーキテクチャとしては次のような構成となっています。

分散クエリ処理 (Distributed Query Processing) のアーキテクチャとなっており、クエリの要求を受け付ける「SQL フロントエンド」の後ろには複数のバックエンドコンピュートプールが存在しており、ユーザーが実行した SQL を複数のタスクに分散させて実行します。

OneLake を使用したデータ操作が可能となっており、Data Warehouse 以外の Fabric の他の機能で生成されたデータについても参照を行う方法が提供されています。

大枠としては次のような特徴があるのではないでしょうか。

• クエリエンジンとして SQL Server ベースのクエリエンジンを使用
  • トランザクション / ロックマネージャー等のコンポーネントも使用
  • SQL Server ベースの環境の機能の一部を使用することもでき、SQL Server の機能を活用できる個所 (例: セキュリティ) がある
• クエリの実行は Synapse Analytics の Serverless SQL プールのような分散環境を使用
  • クエリは複数のタスクに分割され、複数のコンピューティングで実行される
• データストアは Dedicated SQL プールのような SQL Server のデータベースファイル (mdf / ldf) ではなく、Parquet ファイルを採用しながら、参照だけでなく更新も可能としている
  • データの変更を行った場合は、Delta Lake のデータ更新のアーキテクチャにより、データの変更が行われる
• T-SQL をデータに対して優先的な操作言語として使用し、ショートカット機能を使用することで他の利用形態に対しての参照データとして提供することができる
  • Lakehouse にショートカットを作成することで、Data Warehouse で参照可能なデータを増やすことができる
  • Lakehouse に対して Spark で作成したテーブルについては、ショートカットを作成しなくても Data Warehouse から参照可能

Fabric では T-SQL のエンドポイントを持つ類似の機能としては Lakehouse があり、Data Warehouse と Lakehouse の違いについては、データ ストアのプロパティ に記載されています。

T-SQL 利用してのデータ変更は Data Warehouse で作成したテーブルでのみ可能となっています。

Fabric の SQL エンドポイントでは、単一のエンドポイント (論理サーバー名) で、次のデータベースにアクセスすることができ、これらのデータベースを横断した検索が可能となっています。

• Data Warehouse
• Lakehouse
  • Spark で作成したテーブル
  • ショートカットで追加したテーブル
    • KQL DB (KustoDatabase) のテーブルもショートカットで参照可能
• Mirroed Database (MountedRelationalDatabase)
  • SQL DB / CosmosDB / Snowflake

実際にいくつかのデータベースを作成した環境に対して SSMS で接続した状態が次の画像となります。

同一のワークスペースに作成されている SQL 分析エンドポイントをサポートするデータベースについては、データベース配下に表示が行われているようになっているかと思います。

インスタンスのアイコンは SQL Database の論理サーバー名と同一となっていますが、SQL Database と異なり、これらのデータベースについてはデータベースを跨いだクエリの実行が可能となっています。

これらのデータベースの中で、T-SQL によりデータの変更を伴う DML を実行できるのは Data Warehouse に対してのみとなり、他のデータベースについては参照のみが可能です。
セキュリティ関連の機能についても、SQL Server ベースの機能を使用する場合、Data Warehouse でのみサポートされている機能もあります。

使用可能な機能の違いは、データ ストアのプロパティ に記載されており、Data Warehouse を採用する観点についてはこの情報を参照するとよいのではないでしょうか。

参考ドキュメント

• ワークロードの管理
• Microsoft Fabric 決定ガイド: データ ストアを選択する

制限事項

Data Warehouse は T-SQL のエンドポイントを介して、変更を含めたデータ操作を行うことができます。
しかし、SQL Server の全 T-SQL をサポートしているわけではなく、サポートされる T-SQL / データ型には制限があります。

制限事項について参考ドキュメントに記載をしましたのでこちらの情報を確認するとよいかと。

参考ドキュメント

• Microsoft Fabric の T-SQL のセキュリティ、外部からのアクセス
  • Transact-SQL リファレンス (データベース エンジン)
• Microsoft Fabric のデータ型
• Microsoft Fabric の制限事項

ストレージ

Synapse Data Warehouse は Synapse Analytics の専用 SQL プールと異なり、SQL Server ベースのデータストア (mdf) ではなく、Parquet ファイルをベースとしたデータストアが使用されます。

詳細については参考ドキュメントを確認していただくと把握することができますが、次のような特徴があります。

データストア

データファイル

Microsoft Fabric のウェアハウスの Delta Lake ログ に記載されていますが、Data Warehouse 内のユーザーの実データは Parquet ファイルで保存が行われています。

Microsoft Fabric のウェアハウスは、オープン ファイル形式で構築されています。 ユーザー テーブルは parquet ファイル形式で保存され、Delta Lake ログはすべてのユーザー テーブルに対して発行されます。

OneLake 上はテーブル単位にディレクトリが作成されており、トランザクション単位でサブディレクトリが作成されています。Parquet ファイルについては、ステートメント単位で作成されるようなので、細かな INSERT を実行した場合には、INSERT ステートメント単位で Parquet ファイルが作成されます。(トランザクションの中で複数の INSERT を実行した場合も INSERT 単位で Parquet が作成されています)

細かなデータの更新を繰り返すと、Parquet ファイル数が肥大化してしまうため、出来るだけバッチで操作を行ったほうが効率的なアクセスにつながるかと。

トランザクションログ

この Parquet ファイルは、ユーザーデータのデータストアとしてだけでなく、トランザクションログとしての役割も兼ねています。

Data Warehouse はユーザートランザクションの開始がサポートされています。

トランザクション実行時の、詳細は トランザクション ログ に記載されています。

Microsoft Fabric の Warehouse でのトランザクション ログは、Parquet ファイルは不変であるため (変更できないため)、Parquet ファイル レベルです。ロールバックすると、前の Parquet ファイルが指し示されます。 この変更の利点は、トランザクション ログとロールバックがより高速になるという点です。

ロールバックを実施した場合、SQL Server ベースの環境のように、トランザクションログの変更レコードを使用してロールバックを実施するのではなく、最終的なデータを参照させるための Parquet ファイルを指すようにテーブルの構成がロールバックされることでデータの巻き戻しが実行されています。

「どの時点のデータを参照すればよいか」については Data Warehouse 内で、「どの Parquet ファイルを読めばよいか」で判断が行われているのかと思います。

OneLake 内のファイルを確認すると、Delta Lake ログが生成されていますが、Delta Lake ログ が生成される前に、Data Warehouse に接続した他のセッションから更新データを参照すると参考することができましたので、Data Warehouse 内でのデータ検索においては Delta Lake ログは使用されていないということはこの挙動からも確認することができるかと。

データベース照合順序

Data Warehouse で作成したデータベースについては「Latin1_General_100_BIN2_UTF8」の照合順序が設定された状態となり変更することはできません。

この照合順序では BIN2 による比較が行われるため、大文字 / 小文字の区別が行われます。

今後のロードマップとして 大文字と小文字を区別しない照合順序のサポート が計画されており、これが実装されると「Latin1_General_100_CI_AS_KS_WS_SC_UTF8」の照合順序により、大文字 / 小文字を区別しない設定とすることができるようですが、現状は上記の照合順序を使用する必要があります。

パーティションの設定

Data Warehouse で作成したテーブルですが、パーティションの設定は実施されていないように見えました。

現状、パーティションを指定してテーブルを作成するオプションは CREATE TABLE では提供されていないため、パーティションを使用した効率的なアクセスを行うためには、Lakehouse で Spark でテーブルを作成する必要があるのではないでしょうか。(Databricks であれば、Databricks Rutime 11.3 以降でインジェスト時間クラスタリングが使用できますが、Fabric は Spark Runtime が使用されているため、Spark Runtime でインジェスト時間クラスタリングがサポートされて有効化されるようなことがないと、デフォルトでパーティショニングされている状態にならないのではないでしょうか)

OneLake へのデータ反映

ドキュメントとして記載されているのは Microsoft Fabric のウェアハウスの Delta Lake ログ の次の記載となるかと思います。

Microsoft Fabric のウェアハウスは、オープン ファイル形式で構築されています。 ユーザー テーブルは parquet ファイル形式で保存され、Delta Lake ログはすべてのユーザー テーブルに対して発行されます。

Delta Lake ログは Delta Lake テーブルを読み取ることができるすべてのエンジンに対してウェアハウスのユーザー テーブルへの直接アクセスを開きます。 このアクセスは、ユーザー データが ACID トランザクション コンプライアンスを守るために、読み取り専用に制限されています。 テーブル内のデータに対するすべての挿入、更新、および削除は、ウェアハウスを通じて実行する必要があります。 トランザクションがコミットされると、システム バックグラウンド プロセスが開始され、影響を受けるテーブルに対して更新された Delta Lake ログを発行します。

OneLake の Data Warehouse のディレクトリ構造

Data Warehouse を作成すると、OneLake にデータベース名のディレクトリが作成されます。

このディレクトリの下には「Files」「Tables」があり、Data Warehouse に対して作成したテーブルは、Tables に作成されます。(Files / Tables は同一の Parquet ファイルが格納されているようで、Files をスキーマ / テーブルの構成にして、Delta Lake ログが追加されたものが、Tables となっているのではないでしょうか)

テーブル名の下が Delta Lake フォーマットのファイルレイアウトとなっており、トランザクション単位にディレクトリが作成されて Parquet ファイルが格納されます。

Parquet ファイルについては、後述の Delta Lake ログと異なり、コミットをしないでも OneLake 上にファイルが存在していたため、OneLake 上で直接 Parquet ファイルを生成しているか、トランザクションのコミットに依存しないデータ同期のような形で連携が行われているのではという雰囲気がありました。(ファイルの最終更新日時で比較すると、SQL を実行したタイミングが最終更新日時になっているように見えるのですが、大量のクエリを実行していた時に、Parquet ファイルの生成が実際のクエリ実行タイミングとずれているように見えたことがあったのですよね)

参照を含めたテーブルへのアクセスを実施した場合、SQL Server の待機事象上は「EDC_EXEC」となっているため、基本的なアクセスは外部データ接続扱いとなっているようには見えるのですが、OneLake を直接参照しているのか、Data Warehouse 用の領域を参照しているかまでは確認することができませんでした。

Delta Lake ログの作成について

各テーブル名の下に Delta Lake の構成でデータが格納されています。

トランザクションをコミットすると「_delta_log」の下に該当トランザクションの Delta Lake ログが作成されますが、この作成についてはバックグラウンド実行による非同期作成となっています。(私が検証していた時にはコミット後、数秒の時間をおいてからログの JSON ファイルが生成されていました)

Data Warehouse の DB に対してクエリを実行しているセッションであれば、Dalta Lake ログが OneLake 上に作成される前でも、最新の状態を参照できていました。

しかし、Lakehouse からショートカットによりアクセスしている環境については、Delta Lake ログが OneLake に作成されるまで、最新のデータを参照することができませんでしたので、OneLake 上のデータを直接参照している場合には、Data Warehouse の更新データが反映されるのには多少の遅延が発生することは意識しておいたほうが良いのではないでしょうか。

Data Warehouse に対しての更新は Delta Lake ログ経由で、Lakehouse のショートカット経由でのアクセスに対しても反映がされますので、JSON の内容については、Delta Transaction Log Protocol も参考になります。

1 or 100 件の程度の DELETE を実行した場合、Parquet ファイルの作成でなく Delta Lake ログに、Inline の削除ベクトル (pathOrInlineDv)として JSON に記録され、1,000 件のデータを DELETE した場合は、Parquet ファイルの作成が実行されるというような挙動となっており、実行した変更に対してどのように Delta Lake 上で処理が行われているのかを確認する場合は、上述のプロトコルのドキュメントが参考になると思います。

OneLake の Tables 配下の全体の構成

実際の OneLake の Tables 配下の構成は次のようになっており Delta Lake 形式でファイルが保存されています。

WarehouseDB.Datawarehouse # Database
  │                  
  └─Tables
      └─dbo # Schema
      　　  └─NATION
      　　      ├─E0EF79D1-6C8B-4384-8A90-1AA572EDD668 # Table Unique ID
      　　      │  └─0
      　　      │      ├─2548 # Txn
      　　      │      │      D2F19067-F0D0-443C-A443-BFA8CDF700ED.parquet
      　　      │      │      
      　　      │      └─2559
      　　      │              9E4CA303-BB94-4110-BC47-72DBBE41356C.parquet
      　　      │              
      　　      └─_delta_log #Delta lake Log
      　　              00000000000000000000.json
      　　              00000000000000000001.json
      　　              00000000000000000002.json
      　　              00000000000000000003.json

CosmosDB をミラーした場合は、deletion_vector ファイルとして削除ベクトルのファイル生成されており、Parquet ファイルが zstd.parquet (ZStandard Compression) となっていたので、OneLake 上のデータ生成方法によって、ディレクトリの内容には特色がありそうです。

参考ドキュメント

• Delta Lake とは
  • 削除ベクトルとは
  • Delta Transaction Log Protocol

• Microsoft Fabric の Warehouse テーブル内のトランザクション
• Microsoft Fabric のウェアハウスの Delta Lake ログ

• レイクハウス チュートリアル: レイクハウスでデータを準備して変換する
• ベスト プラクティス: Delta Lake
• Azure Databricks でテーブルをパーティション分割するタイミング
• Pros and cons of Hive-style partitioning

OneLake のデータの確認

OneLake に実際にどのようにデータが格納されているかを確認する方法としては、次の 2 種類が一般的な方法ではないでしょうか。

• OneLake ファイルエクスプローラー
• Azure Storage Explorer

OneLake ファイルエクスプローラーは Windows のエクスプローラーと統合された形で OneLake 内のファイルを確認することができ、複数のワークスペースの OneLake を確認することができます。

Azure Storage Explorer は Storage Explorer が使用できる環境であれば、どの環境でも OneLake 内のファイルを確認することができますので、OS を選ばず、汎用的に情報を確認する方法として活用できるのかと。

Storage Explorer を使用した接続方法

Storage Explorer を使用した接続については Azure Storage Explorer を接続して使用する に記載されています。

接続の BLOB の URL 指定については「https://onelake.dfs.fabric.microsoft.com/{workspace-Name}/{itemName.itemType}/」と記載されていますが、「https://onelake.dfs.fabric.microsoft.com/{workspace-Name}」の指定でも接続ができます。({itemName.itemType} の指定は、所見では何を指定すればよいのかがわからない可能性があるため、ワークスペース名で接続したほうがわかりやすいのではと思っています)

ワークスペース名で接続をした場合は、次のように各データベース向けの OneLake  の一覧から表示することができます。

ワークスペース名でなく、Workspace の GUID を指定することで接続もできるのですが、これで接続をした場合は、データベース名も GUID での表示となっていたため、GUID を指定した接続は使用しなくてもよいかなと思いました。

Data Warehouse に接続した場合、「Files」「Tables」の二種類のディレクトリを確認することができますが、Data Warehouse の場合、どちらも読み取り専用となっており、直接の更新はできないようです。(Lake House の場合「Files」にアップロードするというシナリオがあるため、Files の操作は可能ですが Data Warehouse では実施できないようです)

参考ドキュメント

• OneLake ファイル エクスプローラーを使用して Fabric データにアクセスする
• OneLake と Azure Storage Explorer の統合

トランザクション / ロック

利用可能な分離レベル

Microsoft Fabric の Warehouse テーブル内のトランザクション に記載されていますが、Data Warehouse で実行されるクエリについては、「SNAPSHOT 分離レベル」によって実行が行われるため、SQL Server で「SET TRANSACTION ISOLATION LEVEL SNAPSHOT」が実行されているのと同様の状態となります。

Microsoft Fabric では、スナップショット分離レベルのみがサポートされています。 T-SQL を使用して分離レベルを変更した場合、クエリの実行時に変更は無視され、分離スナップショット適用されます。

検索時にはステートメント / トランザクションで読み取り整合性のある状態でデータの検索を実施することができます。

サポートされているロック

Data Warehouse に対してのクエリ実行は「テーブル単位でロックが取得」され、さまざまな種類のステートメントのロック に記載されているロックが取得されます。(ロックについては、Delta Lake の仕組みではなく、SQL Server のロックマネージャーによる制御となっているかと思います)

記載されているロックで競合する可能性があるのは DDL 実行時の「Sch-M」のロックぐらいな気がしています。

制限事項 に記載されていますが、現在の Data Warehouse では ADD / ALTER / DROP COLUMN はサポートされておらず、ALTER TABLE がサポートされるのは制約の追加となっていますので制約追加 / テーブル作成 / テーブル削除 の操作が SCH-M を取得する可能性のある代表的な操作となるのではないでしょうか。

データ変更時の楽観的同時実行制御

データ変更については、「IX」のロックしか取得されないため複数のセッションから同時にデータを更新することができます。そのため、データ更新については「楽観的同時実行制御」により制御が行われています。

トランザクション内でデータの更新を実行した場合に、同一のデータを他のセッションから更新された場合は、コミット時に更新競合によるエラーが発生します。

メッセージ 24556、レベル 16、状態 2、行 3

Snapshot isolation transaction aborted due to update conflict. Using snapshot isolation to access table ‘ip_info’ directly or indirectly in database ‘WarehouseDB’ can cause update conflicts if rows in that table have been deleted or updated by another concurrent transaction. Retry the transaction.

レコード単位でのロックは行われないため、データの整合性の確認はコミット時になるというのはポイントとして抑えておくとよいのではないでしょうか。

参考ドキュメント

• Microsoft Fabric の Warehouse テーブル内のトランザクション

データ復旧

復元ポイント

Data Warehouse では、復元ポイント がサポートされており、システム生成の復元ポイント / ユーザー定義の復元ポイントの二種類がサポートされています。

自動で取得されるシステム生成の復元ポイントは以下のタクトで取得が行われます。

システム生成の復元ポイントの作成は、Warehouse の組み込み機能です。 ただし、自動システム生成の復元ポイントを作成するには、ウェアハウスがアクティブ状態である必要があります。

システム生成の復元ポイントは 1 日を通して作成され、7 日間使用できます。 ウェアハウスが作成された時点から、システム生成の復元ポイントは 8 時間ごとに自動的に作成されます。 特定の時点で、最大 42 個のシステム生成復元ポイントを使用できます。

Warehouse では、8 時間の復元ポイントの目標 (RPO) がサポートされています。

Data Warehouse では、既定で 8 時間ごとに復元ポイントが自動的に作成され、7 日間分保持されています。

7 日間の範囲については緩和させることはできませんが、任意のタイミングで復元をポイントを作成したい場合にはユーザー定義の復元ポイントを利用することができます。

現時点では The Art of Data warehouse recovery within Microsoft Fabric で解説されているように REST API を直接呼び出す必要がありますが、データ復旧方法として把握しておくとよさそうです。

テーブルの複製

テーブルの複製を行おうとした場合、Synapse Analytics では CREATE TABLE AS SELECT (CTAS) を使用することがあったかと思います。

Fabric でも CTAS は引き続き利用することができますが、CREATE TABLE AS CLONE OF という構文がサポートされ、ゼロコピークローンが作成できるようになりました。

元になるテーブルのメタデータのコピーにより、新しいテーブルの作成を行う手法となり、作成したテーブルに対しても更新を行うことができますので、テーブルの複製が必要となった場合に、この機能の活用を検討してみてもよいのではないでしょうか。

参考ドキュメント

• Microsoft Fabric でウェアハウスの所定の場所に復元
• Microsoft Fabric でテーブルを複製する (ゼロコピークローン)
  • Microsoft Fabric のデータ ウェアハウスのテーブル
  • CREATE TABLE AS CLONE OF
    • CREATE TABLE <ターゲットテーブル> AS CLONE OF <ソーステーブル> [AT ‘yyyy-MM-ddTHH:mm:ss.fff’]

データストアの自動的な最適化

Lakehouse では、テーブル メンテナンス機能を使用して Fabric でデルタ テーブルを管理する に記載されているようなメンテナンスの考慮が必要となるようです。

Warehouse については、Announcing: Automatic Data Compaction for Fabric Warehouse に記載されているように、Parquet ファイルは自動的な最適化に任せるようで、ユーザー側からマージ等の処理を実行することはできないようです。

Delta Log のチェックポイントについては、Announcing: Automatic Log Checkpointing for Fabric Warehouse で記載されているように 10 トランザクションログ毎にチェックポイントを非同期で自動的に作成する動作が行われます。

現状、設定については変更することができないため、既存の使用領域を最適なストレージ構成にするのは、Fabric のシステムタスクに一任することになります。

参考ドキュメント

• Announcing: Automatic Log Checkpointing for Fabric Warehouse
• Announcing: Automatic Data Compaction for Fabric Warehouse

キャッシュ

ユーザーが制御できない領域となりますが、Data Warehouse では、メモリ内キャッシュ / ディスクキャッシュ (SSD キャッシュ) の 2 種類のキャッシュが提供されており、これらのキャッシュによりデータアクセスの効率化が行われています。

キャッシュの無効 / キャッシュのクリアを行うことができず、キャッシュにどのようなデータが入っているかを確認することもできません。

クエリの処理時間を確認する場合は、同一のクエリを複数回実行して、最初の処理時間は測定には含めないというような考慮が必要となるかもしれませんね。パフォーマンスガイドラインにも次の記載があり、最初の数回のクエリ実行は後続の実行より遅くなることが記載されています。

ローカル SSD とメモリを使用したキャッシュは自動的に行われます。 クエリの最初の 1 – 3 回の実行は、後続の実行よりも著しく遅くなります。

参考ドキュメント

• Fabric データ ウェアハウスでのキャッシュ

利用可能な DMVとクエリの分析に活用できる情報

Data Warehouse でも DMV を使用することができますが、使用可能なものは一部の DMV のみとなっており、クエリ ライフサイクルの DMV を使用して接続、セッション、要求を監視する方法 に記載されている DMV はアクセスすることができます。

クエリの情報については、Fabric データ ウェアハウスにおけるクエリの分析情報 に記載されている「queryinsights」スキーマ配下のビューを参照することで確認するのが基本的な方法となるようです。

これららのビューの実体は、「queryinsights.fabric_query_starting 」「queryinsights.fabric_query_completed」になるようですが、直接の参照は不可能となっているようです。

メッセージ 373、レベル 14、状態 5、行 1

The SELECT permission or external policy action ‘Microsoft.Sql/Sqlservers/Databases/Schemas/Tables/Rows/Select’ was denied on the object ‘fabric_query_starting’, database ‘WarehouseDB’, schema ‘queryinsights’.

参考ドキュメント

• DMV を使用した接続、セッション、要求を監視する
  • システム動的管理ビュー
• Fabric データ ウェアハウスにおけるクエリの分析情報

セキュリティ

ログインとユーザー

SQL Server ベースの環境では、インスタンス / データベースに接続をするための資格情報として「ログイン」「ユーザー」の 二種類があります。

基本的な考え方としては次のようになります。

• ログイン: インスタンスへの接続とインスタンスレベルの操作
• ユーザー: データベースレベルの操作
• パスワードを持つユーザーの場合、ユーザーのみでインスタンスへの接続が可能

Fabric の場合、上記 2 種類の資格情報の考え方は次のようになります。

• ログイン: Fabric Portal から ワークスペース / Data Warehouse のアクセス権により設定
• Fabric Portal のアクセス権設定を行わないと SQL エンドポイント経由で接続することができない
• ワークスペースレベルでアクセス許可を付与するとワークスペースSQL エンドポイント内の全データベースにアクセスが可能
• ワークスペースレベルでアクセス許可を付与した場合、接続先データベースが「既定」の状態で接続が可能
• ワークスペース内のアクセス可能な全データベースがオブジェクトブラウザに表示される
• Data Warehouse レベルでアクセス許可を付与すると該当データベースにのみアクセスが可能
• Data Warehouse レベルでアクセス許可を付与した場合、接続先データベースが「既定」の状態で接続は不可
• 明示的に接続先データベースを指定する必要がある
• アクセスを許可したデータベースのみがオブジェクトブラウザに表示される
• ユーザー: T-SQL (GRANT / REVOKE / DENY) でアクセス権を設定
• Fabric ワークスペースロール / データウェアハウスロールではすべてのデータが参照可能となるため、細かなアクセス制御は T-SQL のアクセス権設定で実施
• Fabric Portal からログインを設定する前に、ユーザーの設定を実施しておくことができるため、アクセス可能にする前に事前に T-SQL で権限設定を行うことができる

監査ログ

Synapse Analytics の SQL Server ベースの環境では、監査ログは SQL Server の監査の機能をベースにしたものが使用されていたため、監査の設定を実施するとどのようなクエリによりデータベースにアクセスが行われたのかを SQL 監査として確認することができました。

Fabric の標準機能として使用できる監査については Microsoft Fabric Data Warehouse のユーザー監査ログ に記載されています。

Data Warehouse に対しての操作のアクティビティログは取得できますが、「どのようなクエリが実行されたか」の SQL 監査についてのログは、ユーザー監査ログからは取得ができないようです。

そのため、クエリについてのログは Fabric データ ウェアハウスにおけるクエリの分析情報 の queryinsights の情報を使用する必要があるのではないでしょうか。

この情報は 30 日間の保持で固定となっていますので、それ以上の期間の情報が必要な場合には、この情報を定期的にダンプして情報を長期間保持する仕組みを検討する必要があります。

参考ドキュメント

• Microsoft Fabric のワークスペースのロール
• ウェアハウスを共有し、アクセス許可を管理する
• Microsoft Fabric のデータ ウェアハウスのセキュリティ
• Microsoft Fabric での SQL の詳細なアクセス許可

• Microsoft Fabric Data Warehouse のユーザー監査ログ
• 操作一覧
• Azure Synapse Analytics のセキュリティに関するホワイト ペーパー: 脅威の検出

最適化とトラブルシューティング

パフォーマンスガイドラインとトラブルシューティングのドキュメントも公開されています。

最適なパフォーマンスと、問題が発生した場合に参照すべき情報については、これらのドキュメントから確認することができます。

Data Warehouse では INSERT ステートメントによって 1 行単位でデータの投入を行うことも可能ですが、これが最適ではないということも、パフォーマンスガイドラインに記載されています。

以下の例に示すような INSERT ステートメントを使用して小さなテーブルを 1 回だけ読み込むことが、ニーズに応じて最適な方法である可能性があります。 ただし、1 日を通して数千から数百万もの行を読み込む必要がある場合、シングルトンの INSERT は最適ではありません。

参考ドキュメント

• Microsoft Fabric の Synapse Data Warehouse のパフォーマンス ガイドライン
• Warehouse のトラブルシューティング

今後のロードマップ

今後のロードマップについては、参考ドキュメントに記載したドキュメントで公開されています。今後、どのような機能が追加されるか / 改善されるかについては、定期的にこのドキュメントを確認するとよいのではないでしょうか。

参考ドキュメント

• Microsoft Fabric での Synapse Data Warehouseの新機能と計画