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

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

Tip

ファイル サイズや行グループの推奨事項など、SQL 分析エンドポイントの使用のための Delta テーブルの最適化に関する包括的なワークロード間ガイダンスについては、「 クロスワークロード テーブルのメンテナンスと最適化」を参照してください。

どのレイクハウスにも、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 分析エンドポイントにまだ表示されません。 Fabricポータルでオンデマンドメタデータ同期を開始するか、Refresh SQL分析エンドポイントメタデータREST APIを利用できます。
  • 自動同期プロセスでは、すべての Delta 機能がサポートされているわけではありません。 Fabric の各エンジンでサポートされる機能の詳細については、「 Delta Lake テーブル形式の相互運用性」を参照してください。
  • 抽出変換と読み込み (ETL) 処理中にテーブルの変更が非常に大量に発生した場合、すべての変更が処理されるまで予想される遅延が発生します。

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

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

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

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

V-Orderは主にPower BI Direct Lakeの利点であり、一部のワークロードでは圧縮を改善することはありますが、SQL分析エンドポイントの最適なパフォーマンスのためにデフォルトで必須または推奨されるわけではありません。

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

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

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

Note

レイクハウス テーブルの一般的なメンテナンスに関するガイダンスについては、「 Lakehouse からテーブルのメンテナンスを実行する」を参照してください。

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

パーティションレイアウトは、SQL分析エンドポイントが変更の発見と同期にかかる時間に影響を与えます。 多数のパーティションや小さなParquetファイルはメタデータスキャンのオーバーヘッドを増加させます。 次のプラクティスに従います。

  • 高カーディナリティのパーティション列は避けてください。これにより、一意の値ごとにパーティションが作成される可能性があります。 パーティションが1GBに近いかそれ以上になるカラムを選びましょう。 詳細については、 デルタ湖テーブルの分割を参照してください。
  • バッチやストリーミングの取り込みは、変更が頻繁または小さい場合に小さなファイルを作成することがあります。 これらのファイルをコンパクト化するには、定期的に レイクハウス テーブル メンテナンス を使用します。

各パーティションのサイズとファイル数を評価するには、 パーティションの詳細はサンプルスクリプトを用いてください。

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

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

  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']}")

関連するコンテンツ

  • Last updated on