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

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

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

バックグラウンド プロセスは、lakehouse の変更をスキャンし、ワークスペース内の lakehouse にコミットされたすべての変更に対して SQL 分析エンドポイントを up-to-date に保つ役割を担います。 Microsoft 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 ファイルがオーバーヘッドを発生させ、クエリのパフォーマンスに悪影響を及ぼします。 予測可能で効率的なパフォーマンスを確保するには、各 Parquet ファイルに 200 万行が含まれるようにテーブル ストレージを維持します。 この行数は、データセットを過度に小さなスライスに断片化することなく、バランスの取れたレベルの並列処理を提供します。

行数のガイダンスに加えて、ファイル サイズも同様に重要です。 SQL 分析エンドポイントは、Parquet ファイルがファイル処理のオーバーヘッドを最小限に抑えるのに十分な大きさであるが、並列スキャンの効率を制限するほど大きくない場合に最適に実行されます。 ほとんどのワークロードでは、個々の Parquet ファイルを 400 MB に近づけておくと、最適なバランスが取ります。 このバランスを実現するには、次の手順を使用します。

1. データの変更が発生する前に、 maxRecordsPerFile を 2,000,000 に設定します。
2. データの変更 (データ インジェスト、更新、削除) を実行します。
3. maxFileSizeを 4 GB に設定します。
4. OPTIMIZE を実行します。 OPTIMIZEの使用方法の詳細については、「Lakehouse からテーブルのメンテナンスを実行する」を参照してください。

次のスクリプトは、これらの手順のテンプレートを提供し、lakehouse で実行する必要があります。

from delta.tables import DeltaTable

# 1. CONFIGURE LIMITS

# Cap files to 2M rows during writes. This should be done before data ingestion occurs. 
spark.conf.set("spark.sql.files.maxRecordsPerFile", 2000000)

# 2. INGEST DATA
# Here, you ingest data into your table 

# 3. CAP FILE SIZE (~4GB)
spark.conf.set("spark.databricks.delta.optimize.maxFileSize", 4 * 1024 * 1024 * 1024)

# 4. RUN OPTIMIZE (bin-packing)
spark.sql("""
    OPTIMIZE myTable
""")

正常なファイル サイズを維持するには、 OPTIMIZEなどの差分最適化操作を定期的に実行します。特に、頻繁に増分挿入、更新、削除を受け取るテーブルに対して実行します。 これらのメンテナンス操作では、小さなファイルを適切なサイズに圧縮し、SQL 分析エンドポイントがクエリを効率的に処理できるようにします。

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

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

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

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

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

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

以下のノートブックを使用して、Delta テーブルを支えるパーティションのサイズと詳細について詳しく説明したレポートを印刷してください。

1. 最初に、変数 delta_table_pathのデルタ テーブルの ABFSS パスを指定します。
   • Delta テーブルの ABFSS パスは、Fabric ポータルのエクスプローラーから取得できます。 テーブル名を右クリックし、オプションの一覧から COPY PATH を選択します。
2. このスクリプトは、Delta テーブルのパーティションをすべて出力します。
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 を使用して、プログラムによって自動メタデータ スキャンの更新を強制することもできます。

関連するコンテンツ

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