SQL 分析エンドポイントのパフォーマンスに関して考慮すべき事項

SQL 分析エンドポイントを使用すると、T-SQL 言語と TDS プロトコルを使用して、lakehouse 内のデータに対してクエリを実行できます。

どのレイクハウスにも、SQL 分析エンドポイントが 1 つあります。 ワークスペース内の SQL 分析エンドポイントの数は、その同じワークスペースにプロビジョニングされたレイクハウスおよびミラー化されたデータベースの数に一致します。

バックグラウンド プロセスは、lakehouse の変更をスキャンし、ワークスペース内の lakehouse にコミットされたすべての変更に対して SQL 分析エンドポイントを up-to-date に保つ役割を担います。 Fabricプラットフォームは同期プロセスを透過的に管理します。 レイクハウスで変更が検出されると、バックグラウンド プロセスがメタデータを更新し、レイクハウス テーブルにコミットされた変更が SQL 分析エンドポイントに反映されます。 通常の動作条件であれば、レイクハウスと SQL 分析エンドポイント間のタイムラグは 1 分未満です。 実際の時間の長さは、この記事で説明する多くの要因に応じて、数秒から分まで異なる場合があります。 バックグラウンド プロセスは、SQL 分析エンドポイントがアクティブであり、非アクティブ状態が 15 分後に停止した場合にのみ実行されます。

Guidance

• 自動メタデータ検出は、レイクハウスにコミットされた変更を追跡する機能であり、Fabric ワークスペースごとに 1 つあるインスタンスです。 lakehouses と SQL Analytics エンドポイントの間で同期する変更の待機時間が長くなる場合は、1 つのワークスペースに多数の lakehouse が存在することが原因である可能性があります。 このようなシナリオでは、このアプローチではメタデータの自動検出をスケーリングできるため、各 Lakehouse を個別のワークスペースに移行することを検討してください。
• Parquet ファイルは変更できない仕様になっています。 更新操作または削除操作がある場合、Delta テーブルは変更セットを使用して新しい Parquet ファイルを追加します。更新と削除の頻度に応じて、時間の経過と共にファイルの数が増えます。 メンテナンスをスケジュールしない場合、このパターンでは最終的に読み取りオーバーヘッドが発生し、この条件は SQL 分析エンドポイントへの変更の同期にかかる時間に影響します。 この問題に対処するには、レイクハウス テーブルのメンテナンス処理を定期的にスケジュールしてください。
• 一部のシナリオでは、lakehouse にコミットされた変更が、関連付けられている SQL 分析エンドポイントに表示されない場合があります。 たとえば、lakehouse に新しいテーブルを作成しても、SQL 分析エンドポイントにはまだ一覧表示されていません。 または、レイクハウス内のテーブルに多数の行をコミットしても、このデータは SQL 分析エンドポイントにまだ表示されません。 オンデマンド メタデータ同期を開始するオプションがあります。
• 自動同期プロセスでは、すべての Delta 機能がサポートされているわけではありません。 Fabric の各エンジンでサポートされる機能の詳細については、「 Delta Lake テーブル形式の相互運用性」を参照してください。
• 抽出変換と読み込み (ETL) 処理中にテーブルの変更が非常に大量に発生した場合、すべての変更が処理されるまで予想される遅延が発生します。

SQL 分析エンドポイントのクエリを実行するための lakehouse テーブルの最適化

SQL 分析エンドポイントがレイクハウスに格納されているテーブルを読み取る場合、クエリのパフォーマンスは、基になる Parquet ファイルの物理レイアウトに大きく依存します。 エンジンはParquetファイルレベルでスキャンを並列化します。 小さなファイルが多すぎるとファイルやメタデータのオーバーヘッドが増え、大きなファイルが少なすぎると走査並列性が制限されます。

Sparkで書かれたテーブルについては、Fabric Spark 2.0以降のデフォルト設定をご利用ください。 これらのランタイムにより、適応型 ターゲットファイルサイズ がデフォルトで最適なテーブルサイズを選択できるようになり、小さいテーブルでは128MB、最大のテーブルでは最大1GBまで可能です。 デフォルト設定の上に静的ターゲットや任意の行数制限を設定するのは避けましょう。 行の制限は行幅を考慮せず、狭いテーブル用の小さなファイルを作ることがあります。

Fabric Spark 1.3 ランタイムを使用している場合は、オプトイン機能として利用可能な適応型ターゲットファイルサイズとファイルレベルのコンパクト化ターゲットを有効にしてください。

Spark は読み取りと書き込みの両方の I/O を削減するために Parquet ファイルを Snappy 圧縮して書き込むので、SQL 分析エンドポイントのパフォーマンスを向上させるために V-Order は必要ありません。

デフォルトの書き込み設定はテーブルのメンテナンスに代わるものではありません。 テーブルが変わるたびに健全なレイアウトを維持するために、以下の方法を実践してください:

• 定期的に発生する同期書き込みレイテンシの増加を許容できるワークロードでは、自動コンパクションを有効にします。 オートコンパクトは、テーブルに小さなファイルが多すぎる場合にのみ動作するSparkの機能です。
• 自動圧縮による周期的な遅延がデータ更新SLAを満たさないワークロードに対して、定期的な OPTIMIZE ジョブをスケジューリングします。
• 保持期間やタイムトラベルの要件に応じて、デルタログで参照されていないファイルを削除する VACUUM を実行してください。 VACUUM 保持されるストレージは減りますが、アクティブなファイルレイアウトは改善しません。
• カーディナリティの高いパーティショニングや、多数の小さなファイルを生成するカスタマイズされたライター設定は避けてください。

自動コンパクションを使用しない場合は、メンテナンスが必要なテーブルを特定するために、OPTIMIZE を実行する前にデータ パイプラインと sys.sp_get_table_health_metrics T-SQL ストアド プロシージャを使用してください。 チュートリアルについては、 正常性チェックに基づいて Lakehouse テーブルを最適化するを参照してください。

パーティション サイズに関して考慮すべき事項

レイクハウス内のデルタテーブルのパーティション列の選択も、SQL分析エンドポイントへの変更同期にかかる時間に影響を与えます。 パフォーマンスを考えた場合、パーティション列のパーティションの数とサイズが重要になります。

• カーディナリティが高い (大部分または全部が一意の値で構成されている) 列の場合、パーティションの数が非常に多くなります。 パーティションの数が非常に多くなると、変更がないかメタデータ検出スキャンを実施する際のパフォーマンスに悪影響を与えます。 列のカーディナリティが高い場合は、パーティション分割には別の列を選択してください。
• 各パーティションのサイズも、パフォーマンスに影響を与えることがあります。 1 GB 以上 (または 1 GB に近い) パーティションが作成される列を使用します。 デルタテーブルの保守やパーティション管理のベストプラクティスを守ってください。 パーティションを評価するPython スクリプトについては、パーティションの詳細については、サンプル スクリプトを参照してください。

小さなサイズの Parquet ファイルが大量にあると、レイクハウスとその関連する SQL 分析エンドポイントとの間で変更を同期する際にかかる時間が長くなります。 Delta テーブルに多数の Parquet ファイルが含まれることになる理由としては、1 つ以上の原因が考えられます:

• 一意の値の数が多い Delta テーブルのパーティションを選択した場合、テーブルは一意の値ごとにパーティション分割され、過剰にパーティション分割される可能性があります。 カーディナリティが高くないパーティション列を選択すると、個々のパーティションがそれぞれ少なくとも 1 GB になります。
• バッチおよびストリーミング データ インジェスト率も、変更の頻度とサイズによっては、小さなファイルがレイクハウスに書き込まれる要因となることがあります。 たとえば、レイクハウスに少量の変更が発生し、その結果、小さな Parquet ファイルが生成される場合があります。 この問題に対処するには、 定期的な lakehouse テーブルのメンテナンスを実装します。

パーティションの詳細に関するサンプル スクリプト

以下のノートを使って、デルタテーブルの下にあるパーティションのサイズや詳細を詳細に記載したレポートを印刷してください。

1. まず、変数 delta_table_pathにデルタテーブルのABFSSパスを提供します。
   • Delta テーブルの ABFSS パスは、Fabric ポータルのエクスプローラーから取得できます。 テーブル名を右クリックし、オプションの一覧から COPY PATH を選択します。
2. スクリプトはデルタテーブルのすべてのパーティションを出力します。
3. 各パーティションを反復処理して、ファイルの合計サイズと数を計算します。
4. パーティション、パーティションごとのファイル、パーティションごとのサイズ (GB 単位) の詳細を出力します。

次のコード ブロックから完全なスクリプトをコピーできます。

# Purpose: Print out details of partitions, files per partitions, and size per partition in GB.
from notebookutils import mssparkutils

# Define ABFSS path for your delta table. You can get ABFSS path of a delta table by simply right-clicking on table name and selecting COPY PATH from the list of options.
delta_table_path = "abfss://<workspace id>@<onelake>.dfs.fabric.microsoft.com/<lakehouse id>/Tables/<tablename>"

# List all partitions for given delta table
partitions = mssparkutils.fs.ls(delta_table_path)

# Initialize a dictionary to store partition details
partition_details = {}

# Iterate through each partition
for partition in partitions:
  if partition.isDir:
      partition_name = partition.name
      partition_path = partition.path
      files = mssparkutils.fs.ls(partition_path)
      
      # Calculate the total size of the partition

      total_size = sum(file.size for file in files if not file.isDir)
      
      # Count the number of files

      file_count = sum(1 for file in files if not file.isDir)
      
      # Write partition details

      partition_details[partition_name] = {
          "size_bytes": total_size,
          "file_count": file_count
      }
      
# Print the partition details
for partition_name, details in partition_details.items():
  print(f"{partition_name}, Size: {details['size_bytes']:.2f} bytes, Number of files: {details['file_count']}")

レイクハウスの SQL 分析エンドポイントで自動的に生成されたスキーマ

レイクハウス内のすべての Delta テーブルに対して、SQL 分析エンドポイントによって 1 つのテーブルが適切なスキーマで自動的に生成されます。 SQL 分析エンドポイント エンジンは、Fabric Data Warehouse エンジンに基づいています。

詳細については、 SQL 分析エンドポイントのメタデータ同期に関するページを参照してください。 SQL エンドポイント メタデータの更新 REST API を使用して、プログラムによって自動メタデータ スキャンの更新を強制することもできます。

関連するコンテンツ

• ワークロード間のテーブルのメンテナンスと最適化
• デルタ湖表の最適化とV次数
• テーブル圧縮
• ファイル サイズを調整する
• Lakehouse SQL Analytics エンドポイントのユース ケース