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. Fabric Data Warehouse motorundan faydalanı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. Fabric platformu, senkronizasyon sürecini şeffaf bir şekilde yönetiyor. 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 süreci, SQL analitik uç noktası aktifken çalışır ve 15 dakika sorgulama aktivitesi olmadan 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. Fabric portalında talep üzerine meta veri senkronizasyonunu başlatabilir veya Refresh SQL analitik uç noktası metaveri REST API'sini kullanabilirsiniz.
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. İşleme motoru, taramaları Parquet dosyası düzeyinde paralelleştirir. Çok fazla küçük dosya dosya ve meta veri yükünü artırırken, çok az büyük dosya tarama paralelliğini sınırlayabilir.

Spark tarafından yazılmış tablolar için, Fabric Spark runtime 2.0 veya daha sonrasında varsayılan ayarları kullanın. Bu çalışma zamanları, varsayılan olarak uyarlanabilir hedef dosya boyutunun en uygun hedef dosya boyutunu tabloya göre seçmesini sağlar; küçük tablolar için 128 MB'den en büyük tablolar için 1 GB'a kadar. Varsayılan yapılandırmaların üzerine statik hedefler veya rastgele satır sayısı sınırı koymaktan kaçının. Satır sınırı satır genişliğini hesaba katmaz ve dar tablolar için küçük dosyalar oluşturabilir.

Fabric Spark çalışma zamanı 1.3 kullanıyorsanız, adaptif hedef dosya boyutu ve dosya seviyesindeki sıkıştırma hedeflerini etkinleştirin; bunlar isteğe bağlı özellikler olarak sunuluyor.

V-Order öncelikle Power BI Direct Lake'e fayda sağlar ve bazı iş yüklerinde sıkıştırmayı iyileştirebilse de, genellikle optimal SQL analitik uç nokta performansı için varsayılan olarak zorunlu veya önerilmez.

Varsayılan yazma ayarları tablo bakımının yerini alamaz. Tablolar değişirken sağlıklı bir düzeni korumak için aşağıdaki uygulamaları kullanın:

Periyodik eklenen senkron yazma gecikmesinin kabul edilebilir olduğu iş yükleri için otomatik sıkıştırmayı etkinleştirin. Otomatik sıkıştırma, yalnızca tabloda çok fazla küçük dosya olduğunda çalışan bir Spark özelliğidir.
Otomatik sıkıştırmanın neden olduğu ek periyodik gecikmenin veri güncelleme SLA'larını karşılamadığı iş yükleri için periyodik OPTIMIZE işler planlayın.
Delta günlüğünün artık referans vermediği dosyaları kaldırmak için tutma ve zaman yolculuğu gereksinimlerinize göre çalıştırın VACUUM . VACUUM saklanan depoyu azaltır ama aktif dosya düzenini iyileştirmez.
Yüksek kardinalite bölümlemelerden ve çok sayıda küçük dosya oluşturan özelleştirilmiş yazıcı yapılandırmalarından kaçının.

Otomatik sıkıştırma kullanmıyorsanız, bakım gerektiren tabloları belirlemek için OPTIMIZE çalıştırmadan önce bir veri işlem hattı ve sys.sp_get_table_health_metrics T-SQL saklı yordamını kullanın. Bkz. Sistem durumu denetimlerini temel alarak Lakehouse tablolarını en iyi duruma getirme.

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

Bölüm düzeni, SQL analitik uç noktasının değişiklikleri keşfedip senkronize etmesinin ne kadar sürdüğünü etkiler. Çok sayıda bölüm veya küçük Parquet dosyası, meta veri tarama yükünü artırır. Şu uygulamaları izleyin:

Her benzersiz değer için bir bölüm oluşturabilen yüksek kardinalite bölüm sütunlarından kaçının. 1 GB'a yakın veya daha büyük bölümler üreten bir sütun seçin. Daha fazla bilgi için Delta Lake tablo bölümlemesi sayfasına bakınız.
Toplu ve akış veri içe alımı, değişiklikler sık veya küçük olduğunda küçük dosyalar oluşturabilir. Bu dosyaları birleştirmek için düzenli lakehouse tablo bakımı kullanın.

Her bölümün boyutunu ve dosya sayısını değerlendirmek için, bölüm detayları için örnek betiklerini kullanın.

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

Bir Delta tablosunun temelini oluşturan bölümlerin boyutunu ve ayrıntılarını içeren bir rapor oluşturmak için aşağıdaki not defterini kullanın.

İlk olarak, değişkende delta_table_pathDelta tablonuzun ABFSS yolunu belirtin.
- 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 .
Script, Delta tablosu için tüm bölümleri çıkarır.
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']}")

Geri Bildirim

Bu sayfayı yararlı buldunuz mu?

Last updated on 2026-09-16