Azure Data Factory (ADF) / Synpase Analytics / Fabric でパイプラインを作成し、アクティビティの実行時にエラーとなったことを検知する方法についてまとめておきたいと思います。
ADF を使用して Fabric Data Warehouse にデータを投入する際に必要となる権限
ADF はデータセットとして Fabric として次のデータストアを使用することができます。
- Microsoft Fabric Lakehouse テーブル
- Microsoft Fabric Lakehouse ファイル
- Microsoft Fabric ウェアハウス
Fabric へのデータ投入は、Fabric 内のデータパイプラインだけでなく、Azure 内でパイプラインを作成することでデータの投入を行うこともできます。
Microsoft Fabric ウェアハウス (Data Warehouse) に ADF を使用してデータを投入する際に、必要となる権限についてまとめておきたいと思います。
なお、Data Warehouse へのデータ投入については「データのコピー」のアクティビティを使用しており、ステージングストレージが必要となります。
クエリストアのカスタムキャプチャの設定を行う場合の考慮点
SQL Server 2019 以降のクエリストアでは、カスタムキャプチャの設定を行うことができるようになりました。これにより、クエリのキャプチャモードを「ALL」「AUTO」以外に「CUSTOM」で設定することができるようになります。
「CUSTOM」を使用した場合、キャプチャされるクエリの条件を従来より柔軟に設定することができます。
「CUSTOM」を設定した場合の設定観点について少しふれておきたいと思います。
クエリストアの活用については次のドキュメントが参考になります。
SSMS の接続情報を整理する
SSMS は接続情報として入力した内容が保存されており、接続を行おうとした場合に再利用することができます。
自サーバー上の SQL Server にのみ接続をしているのであれば、この情報が増えるということはあまりないですが、クライアントからいくつかのサーバーに接続している場合にはこの情報が増えていき、今は接続が不要になったサーバーの情報も残った状態となっていることがあります。
接続の情報は SSMS の構成ファイルである 「UserSettings.xml」に記録が行われており、この XML から接続情報を削除することで、表示が行われなくなります。
ファイルは「%USERPROFILE%\AppData\Roaming\Microsoft\SQL Server Management Studio」に SSMS のバージョンごと (18.0 / 19.0 / 20.0 等のディレクトリ) に保存されています。
不要となった情報は
- SSMS を起動していない状態にする
- SSMS を起動していると、SSMS を閉じた場合に修正した情報が初期化されてしまう可能性があるため
- UserSettings.xml を直接編集し、不要となったサーバーの接続情報を削除
することでクリアすることができます。
XML の階層としては「SqlStudio > SSMS > ConnectionOptions > ServerTyes > Element」配下に保存されています。
UserSettings.xml は情報量が多い XML ですので、メモ帳で修正するよりは、Visual Studio Code で XML を編集して、不要となったサーバー情報の Element をブロック単位で削除したほうが効率が良いかと。
Microsoft Fabric の Synapse Data Warehouse の特性を把握するためのドキュメント
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 の特性を把握するために、一読しておく必要があるドキュメントとしてはどのようなものがあるかをまとめておきたい思います。
SQL Server のフィルター選択されたインデックスの利用について
SQL Server では フィルター選択されたインデックス (フィルター化インデックス) というインデックスを作成することができます。
このインデックスはインデックスの作成を行う際に、以下のクエリのように、インデックス作成時に WHERE 句を指定することで、特定の範囲のデータのみが含まれたインデックスを作成することができます。
12345CREATE
NONCLUSTERED
INDEX
[NCIX_accesslog2_01]
ON
[frontdoor].[accesslog2]
(
[
time
]
ASC
)
WHERE
([
time
]>=
'2020-01-01'
AND
[
time
]<
'2021-01-01'
)
フィルター選択されたインデックスは、特定のデータ範囲のみがインデックスに含まれますので次のようなメリットがあります。
- インデックスで使用されるストレージサイズの削減
- フィルター外のデータを追加 / 変更する場合のインデックス更新コストの削減
- 該当データ範囲で Index Scan が発生した場合の、Scan コストの削減
特定のデータ範囲の検索向けに作成するインデックスとして便利な機能となるのですが、作成したインデックスが使用されるかどうかについては考慮が必要な点がありますので、本投稿で触れておきたいと思います。
フィルター選択されたインデックスの詳細な情報については次のドキュメントが参考となります。
ストアドプロシージャのリコンパイルを同時実行性の低下を抑えて誘発させる
ストアドプロシージャを明示的にリコンパイルさせる方法として ストアド プロシージャの再コンパイル に記載されている sp_recompile を使用するという方法があります。
ストアドプロシージャはコンパイル時に指定されたパラメーターによって実行プランが生成されるため、コンパイル時に指定されたパラメーターが大多数の実行に対してマイノリティな設定の場合、頻繁に実行するクエリに対しては効率の悪い実行プランが生成されることがあります。
このような場合は、ストアドプロシージャをリコンパイルさせることで新しい実行プランを生成することがあります。
このリコンパイルを同時実行性の低下をできるだけ抑えて実行するにはどのような方法が考えられるでしょうか。
SSMS のクエリ実行時に ARITHABORT を OFF にするだけではアプリケーションから実行しているクエリと同一にならなかった
SSMS からクエリを実行した場合と、アプリケーションからクエリを実行した場合の違いとして、Qiita で書いた アプリから動かすと遅いが SSMS から動かすと速いのは ARITHABORT の違いという情報の動作を理解する というような動作があります。
SET オプションが異なっていると、異なる実行プランとしてキャッシュが行われるため、SSMS とアプリケーションで同一のオプションを使用するというのが記載した内容となります。
この投稿では、「SET ARITHABORT OFF」を SSMS から実行し、アプリケーションと同一の SET オプションの状態とすることで SSMS とアプリケーションで同一のプランキャッシュを使用していました。
クエリの多重実行と SSMS から実行したクエリで同一のプランキャッシュを使用したかったので「SQLQueryStress」と「SET ARITHABORT OFF に設定した SSMS」でクエリを実行したところ、同一のプランキャッシュが使用されないという事象が発生しました。
そこで、同一の SET オプション以外にどのような要因が同一のプランキャッシュが使用されないことにつながっているのかを確認してみました。
SQL Server のコンパイル時間とコンパイルの CPU 時間の関係について
SQL Server ではコンパイル時間を確認する方法としては次のような方法があります。
- 実行プランの CompileTime / CompileCPU を確認する
- sys.query_store_plan の compile_duration を確認する
- SET STATISTICS TIME ON を実行して、実行時のコンパイル時間を確認する
これらの情報からクエリのコンパイルにかかった時間を確認することができるのですが、値を正しく把握しておかないとコンパイル時間についてミスリードをする可能性があります。
Serverless SQL プールで Azure ストレージの診断ログを検索する際の考慮事項
Frontdoor の診断設定で取得した、Azure ストレージ上のアクセスログを Synapse Analytics の Serveless SQL プールで検索する際にいくつかの考慮点があったため、その内容をまとめておきたいと思います。