SQL analytics uç noktası performansıyla ilgili dikkat edilmesi gerekenler

SQL analiz uç noktası, T-SQL dili ve TDS protokollerini kullanarak lakehouse'daki verileri sorgulamanıza olanak tanır.

Tip

Dosya boyutu ve satır grubu önerileri de dahil olmak üzere Delta tablolarını SQL analiz uç noktası tüketimi için iyileştirmeye yönelik kapsamlı iş yükleri arası yönergeler için bkz. İş yükü tablosu bakımı ve iyileştirmesi.

Her göl evinde bir SQL analiz uç noktası vardır. Çalışma alanı içindeki SQL analiz uç noktalarının sayısı, bu çalışma alanında sağlanan göl evi ve yansıtılmış veritabanı sayısıyla eşleşir.

Bir arka plan işlemi, bir çalışma alanındaki lakehouse’larda yapılan değişiklikleri taramaktan ve SQL analiz uç noktasını, lakehouse’lara kaydedilen tüm değişikliklerle güncel tutmaktan sorumludur. Microsoft Fabric platformu eşitleme işlemini şeffaf bir şekilde yönetir. Göl evinde bir değişiklik algılandığında, arka plan işlemi meta verileri güncelleştirir ve SQL analiz uç noktası lakehouse tablolarına yapılan değişiklikleri yansıtır. Normal çalışma koşulları altında, bir lakehouse ile SQL analiz uç noktası arasındaki gecikme bir dakikadan kısadır. Gerçek süre, bu makalede ele alınan birçok faktöre bağlı olarak birkaç saniye ile dakika arasında değişebilir. Arka plan işlemi yalnızca SQL analiz uç noktası etkin olduğunda çalışır ve 15 dakika etkinlik dışı kalma süresinden sonra durur.

Yönergeler

Otomatik meta veri bulma, veri gölleri üzerinde yapılan değişiklikleri izler ve Fabric çalışma alanı başına tek bir örnektir. Göl evleri ile SQL analiz uç noktası arasındaki değişikliklerin eşitlenmesinde gecikme süresinin arttığını gözlemlerseniz, bunun nedeni bir çalışma alanında çok fazla sayıda göl evi olabilir. Böyle bir senaryoda, bu yaklaşım otomatik meta veri keşfinin ölçeklenmesine olanak tanıdığından her bir lakehouse’u ayrı bir çalışma alanına taşımayı değerlendirin.
Parquet dosyaları tasarım gereği değiştirilemezdir. Bir güncelleştirme veya silme işlemi olduğunda, Delta tablosu değişiklik kümesiyle yeni Parquet dosyaları ekler ve bu da güncelleştirmelerin ve silmelerin sıklığına bağlı olarak zaman içinde dosya sayısını artırır. Bakım planlamazsanız, bu örüntü sonunda bir okuma ek yükü oluşturur ve bu durum, değişikliklerin SQL analiz uç noktasına eşitlenmesi için gereken süreyi etkiler. Bu sorunu gidermek için düzenli lakehouse tablo bakım işlemlerini zamanlayın.
Bazı senaryolarda, bir lakehouse'a yapılan değişikliklerin ilişkili SQL analiz uç noktasında görünür olmadığını görebilirsiniz. Örneğin lakehouse'da yeni bir tablo oluşturabilirsiniz ancak henüz SQL analiz uç noktasında listelenmemiştir. Alternatif olarak, göl evindeki bir tabloya çok sayıda satır işleyebilirsiniz ancak bu veriler henüz SQL analiz uç noktasında görünmez. İsteğe bağlı meta veri eşitlemeyi başlatma seçeneğiniz vardır.
Otomatik eşitleme işlemi tüm Delta özelliklerini desteklemez. Fabric'deki her motor tarafından desteklenen işlevler hakkında daha fazla bilgi için Delta Lake tablo biçimi birlikte çalışabilirliği bölümüne bakın.
Ayıklama Dönüştürme ve Yükleme (ETL) işlemi sırasında çok büyük miktarda tablo değişikliği varsa, tüm değişiklikler işlenene kadar beklenen bir gecikme oluşur.

SQL analiz uç noktasını sorgulamak için lakehouse tablolarını iyileştirme

SQL analiz uç noktası bir lakehouse'da depolanan tabloları okuduğunda, sorgu performansı büyük ölçüde temel parquet dosyalarının fiziksel düzenine bağlıdır.

Çok sayıda küçük Parquet dosyası ek yük oluşturur ve sorgu performansını olumsuz etkiler. Tahmin edilebilir ve verimli performans sağlamak için her Parquet dosyasının iki milyon satır içermesi için tablo depolama alanını koruyun. Bu satır sayısı, veri kümesini aşırı küçük dilimlere bölmeden dengeli bir paralellik düzeyi sağlar.

Satır sayısı kılavuzuna ek olarak, dosya boyutu da aynı derecede önemlidir. SQL analiz uç noktası, Parquet dosyaları dosya işleme yükünü en aza indirecek kadar büyük olduğunda ancak paralel tarama verimliliğini sınırlayabilecek kadar büyük olmadığında en iyi performansı gösterir. Çoğu iş yükü için tek tek Parquet dosyalarının 400 MB'a yakın tutulması en iyi dengeyi sağlar. Bu dengeyi elde etmek için aşağıdaki adımları kullanın:

Veri değişiklikleri gerçekleşmeden önce 2.000.000 olarak ayarlayın maxRecordsPerFile .
Veri değişikliklerinizi (veri alımı, güncelleştirmeler, silmeler) gerçekleştirin.
4 GB olarak ayarlayın maxFileSize .
OPTIMIZE'i çalıştırın. OPTIMIZE kullanımına ilişkin ayrıntılar için bkz. Lakehouse’tan tablo bakımını çalıştırma.

Aşağıdaki senaryo bu adımlar için bir şablon sağlar ve bir lakehouse üzerinde yürütülmelidir:

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
""")

İyi durumdaki dosya boyutlarını korumak için, özellikle sık artımlı eklemeler, güncelleştirmeler ve silmeler alan tablolar için gibi Delta iyileştirme işlemlerini OPTIMIZEdüzenli aralıklarla çalıştırın. Bu bakım işlemleri küçük dosyaları uygun boyuttaki dosyalara sıkıştırarak SQL analiz uç noktasının sorguları verimli bir şekilde işleyebilmesine yardımcı olur.

Note

Lakehouse tablolarının genel bakımıyla ilgili yönergeler için bkz. Lakehouse'dan tablo bakımını çalıştırma.

Bölüm boyutuyla ilgili dikkat edilmesi gerekenler

Lakehouse'daki bir delta tablosu için bölüm sütunu seçimi, değişiklikleri SQL analiz uç noktasına eşitlemek için gereken süreyi de etkiler. Bölüm sütununun bölümlerinin sayısı ve boyutu performans açısından önemlidir:

Yüksek kardinaliteye sahip bir sütun (çoğunlukla veya tamamen benzersiz değerlerden oluşur) çok sayıda bölüme neden olur. Çok sayıda bölüm, meta veri bulma taramasının performansını değişiklikler için olumsuz etkiler. Bir sütunun kardinalitesi yüksekse bölümleme için başka bir sütun seçin.
Her bölümün boyutu performansı da etkileyebilir. En az (veya en yakın) 1 GB'lık bir bölümle sonuçlayan bir sütun kullanın. Delta tablolarının bakımı ve iyileştirmesi için en iyi yöntemleri izleyin. Bölüntüleri değerlendirmek için bir Python betiği için, bölüntü ayrıntılarına yönelik örnek betiğe bakın.

Çok sayıda küçük boyutlu Parquet dosyası, bir lakehouse ile ilişkili SQL analiz uç noktası arasındaki değişikliklerin eşitlenme süresini artırır. Bir veya daha fazla nedenden dolayı bir delta tablosunda çok sayıda parquet dosyasıyla karşılaşabilirsiniz.

Delta tablosu için çok sayıda benzersiz değer içeren bir bölüm seçerseniz, tablo her benzersiz değere göre bölümlenmiştir ve fazla bölümlenmiş olabilir. Yüksek kardinaliteye sahip olmayan ve her biri en az 1 GB olan tek tek bölümlere neden olan bir bölüm sütunu seçin.
Toplu ve akış veri alma oranları, değişikliklerin sıklığı ve boyutuna bağlı olarak veri gölü evine yazılırken küçük dosyalar oluşturabilir. Örneğin, göl evinde küçük miktarda değişiklik olabilir ve bu da küçük parquet dosyalarıyla sonuçlanabilir. Bu sorunu gidermek için normal lakehouse tablo bakımını uygulayın.

Bölüm ayrıntıları için örnek betik

Delta tablosunun altındaki bölümlerin boyutunu ve ayrıntılarını içeren bir raporu yazdırmak için aşağıdaki not defterini kullanın.

İlk olarak, değişkenindeki delta_table_pathdelta tablonuz için ABFSS yolunu sağlayın.
- Fabric portalı Gezgini'nden bir delta tablosunun ABFSS yolunu alabilirsiniz. Tablo adına sağ tıklayın, ardından seçenekler listesinden seçim yapın COPY PATH .
Betik, delta tablosundaki tüm bölümleri görüntüler.
Betik, dosya boyutunu ve dosya sayısını hesaplamak için her bir bölümü dolaşır.
Betik dosyası, bölümlerin ayrıntılarını, her bölüm için dosya sayısını ve GB cinsinden bölüm başına boyutu gösterir.

Betiğin tamamını aşağıdaki kod bloğundan kopyalayabilirsiniz:

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

Lakehouse'un SQL analiz uç noktasında otomatik olarak oluşturulan şema

Lakehouse'unuzda her Delta tablosu için SQL analiz uç noktası otomatik olarak uygun şemada bir tablo oluşturur. SQL analiz uç noktası altyapısı, Fabric Data Warehouse altyapısını temel alır.

Daha fazla bilgi için bkz. SQL analytics uç noktası meta veri eşitlemesi. Ayrıca SQL uç noktası meta verilerini yenile REST API'sini kullanarak otomatik meta veri taramasını program aracılığıyla yenilemeye zorlayabilirsiniz.

Geri Bildirim

Bu sayfayı yararlı buldunuz mu?

Last updated on 2026-05-26