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

Şunlar için geçerlidir:✅ Microsoft Fabric'te SQL analiz uç noktası

SQL analiz uç noktası, T-SQL dili ve TDS protokollerini kullanarak lakehouse'daki verileri sorgulamanızı sağlar.

İpucu

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.

Arka plan süreci, değişiklikler için Lakehouse'un taranmasından ve bir çalışma alanındaki Lakehouse'lara yapılan tüm değişiklikler için SQL analiz uç noktasının güncel olmasını sağlamaktan sorumludur. Eşitleme işlemi Microsoft Fabric platformu tarafından şeffaf bir şekilde yönetilir. 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 boyunca etkinlik olmadığında durdurulur.

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

SQL analytics uç noktası, çalışma alanı kullanıcılarının bunları değiştirememeleri için otomatik olarak oluşturulan tabloları yönetir. Kullanıcılar kendi SQL şemalarını, görünümlerini, yordamlarını ve diğer veritabanı nesnelerini ekleyerek veritabanı modelini zenginleştirebilir.

Lakehouse'unuzda her Delta tablosu için SQL analiz uç noktası otomatik olarak uygun şemada bir tablo oluşturur. SQL analizi uç noktası için otomatik oluşturulan şema veri türleri için bkz . Microsoft Fabric'te veri türleri.

SQL analiz uç noktasındaki tablolar küçük bir gecikmeyle oluşturulur. Delta Lake tablosunu gölde oluşturduktan veya güncelleştirdikten sonra Delta lake tablosuna başvuran SQL analiz uç noktası tablosu otomatik olarak oluşturulur/yenilenir.

Tabloyu yenilemek için gereken süre, Delta tablolarının ne kadar iyileştirilmiş olduğuyla ilgilidir. Daha fazla bilgi için, Delta Lake tablosu optimizasyonu ve V-Order'ı inceleyin ve önemli senaryolar hakkında daha fazla bilgi sahibi olun. Ayrıca, Delta tablolarını en yüksek performans için verimli bir şekilde nasıl sürdürebileceğiniz konusunda ayrıntılı bir kılavuz edinin.

Fabric portalında otomatik meta veri taramasını el ile yenilemeye zorlayabilirsiniz. SQL analiz uç noktasının sayfasında, şemayı yenilemek için Gezgin araç çubuğundaki Yenile düğmesini seçin. SQL analiz uç noktanızı sorgula bölümüne gidin ve aşağıdaki görselde gösterildiği gibi yenileme düğmesini arayın.

Ayrıca SQL uç noktası meta verilerini yenile REST API'sini kullanarak otomatik meta veri taramasını program aracılığıyla yenilemeye zorlayabilirsiniz.

Kılavuz

• 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ında eşitlenecek değişikliklerin gecikme süresinin arttığını gözlemliyorsanız, bunun nedeni tek bir çalışma alanında çok fazla sayıda göl evi olabilir. Böyle bir senaryoda, her göl veri ambarını ayrı bir çalışma alanına taşımayı düşünün, çünkü bu, sistemin otomatik meta veri keşfi ölçeklendirmesine olanak tanır.
• Parquet dosyaları tasarım gereği değiştirilemezdir. Güncelleştirme veya silme işlemi olduğunda, Delta tablosu değişiklik kümesiyle yeni parquet dosyaları ekler ve güncelleştirmelerin ve silmelerin sıklığına bağlı olarak zaman içindeki dosya sayısını artırır. Zamanlanmış bir bakım yoksa, sonunda bu desen bir okuma yükü oluşturur ve bu, değişiklikleri SQL analiz uç noktasına eşitleme süresini etkiler. Bu sorunu çözmek için normal 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şturmuş olabilirsiniz ancak henüz SQL analiz uç noktasında listelenmemiştir. Alternatif olarak, lakehouse'taki bir tabloya çok sayıda satır eklemiş olabilirsiniz ancak bu veriler henüz SQL analitik uç noktasında görünmüyordur. SQL sorgu düzenleyicisi Şeridi yenile seçeneğinden veya SQL uç noktası meta verilerini yenile REST API'sinden tetiklenen isteğe bağlı meta veri eşitlemesi başlatmanızı öneririz. Bu seçenek, arka plan meta veri eşitlemesinin tamamlenmesini beklemek yerine isteğe bağlı meta veri eşitlemesini zorlar.
• Tüm Delta özellikleri otomatik eşitleme işlemi tarafından anlaşılmaz. 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 olursa, tüm değişiklikler işlenene kadar beklenen bir gecikme oluşabilir.

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ı temel alınan parquet dosyalarının fiziksel düzeninden büyük ölçüde etkilenir.

Çok sayıda küçük parquet dosyası fazladan ek yük oluşturur ve sorgu performansını olumsuz yönde etkiler. Tahmin edilebilir ve verimli bir performans sağlamak için, her biri iki milyon satır içeren Parquet dosyalarıyla tablo depolamayı korumanızı öneririz. 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 ek 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 ayrı ayrı 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:

1. Veri değişiklikleri gerçekleşmeden önce 2.000.000 olarak ayarlayın maxRecordsPerFile .
2. Veri değişikliklerinizi (veri alımı, güncelleştirmeler, silmeler) gerçekleştirin.
3. 4 GB olarak ayarlayın maxFileSize .
4. OPTIMIZE'i çalıştırın. OPTIMIZE kullanımı ile ilgili ayrıntılı bilgi için Tablo bakım işlemleri bölümüne bakın.

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", 400 * 1024 * 1024 * 1024)

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

İyi durumdaki dosya boyutlarını korumak için kullanıcıların özellikle sık artımlı yazma, güncelleştirme ve silme işlemleri alan tablolar için OPTIMIZE gibi Delta iyileştirme işlemlerini düzenli aralıklarla çalıştırması gerekir. 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.

Uyarı

Lakehouse tablolarının genel bakımıyla ilgili yönergeler için Bkz. Lakehouse kullanarak Delta tablosunda geçici tablo bakımı yürütme.

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. Çözüm önerimiz, en az 1 GB'lık veya yaklaşık bir bölüm oluşturacak bir sütun kullanmaktır. Delta tabloları bakımı için en iyi yöntemlerin izlenmesini öneririz; en iyi duruma getirme. Bölümleri değerlendirmek için bir Python betiği görmek için Bölüm ayrıntıları için örnek betik bölümüne 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ümleme stratejisi seçerseniz, her benzersiz değer için bölümlenebilir ve aşırı parçalı hale gelebilir. 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 çözmek için normal lakehouse tablo bakımının uygulanmasını öneririz.

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.

1. İlk olarak, değişkenindeki delta_table_pathdelta tablonuz için ABSFF yolunu sağlamanız gerekir.
   • 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 .
2. Betik, delta tablosundaki tüm bölümleri görüntüler.
3. Betik, dosya boyutunu ve dosya sayısını hesaplamak için her bir bölümü dolaşır.
4. 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ı aşağıdaki kod bloğundan kopyalanabilir:

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

İlgili içerik

• İş yükleri arası tablo bakımı ve iyileştirmesi
• Delta Lake tablo optimizasyonu ve V-Order
• Tablo sıkıştırma
• Dosya boyutunu ayarlama
• Birlikte daha iyi: göl evi ve depo
• Kumaş Veri Ambarı performans yönergeleri
• SQL analiz uç noktasının sınırlamaları