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.

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 işlemi, değişiklikler için lakehouse'un taranmasından ve bir çalışma alanında lakehouse'lara yapılan tüm değişiklikler için SQL analiz uç noktasının güncel tutulmasından 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 önemli senaryolar hakkında daha fazla bilgi edinmek için Delta Lake tablo iyileştirmesi ve V Düzeni'ne göz atın ve delta tablolarını en yüksek performans için verimli bir şekilde koruma hakkında ayrıntılı bir kılavuz edinin.

Doku 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ı sorgulama'ya gidin ve aşağıdaki görüntüde gösterildiği gibi yenile 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.

Rehber

• Otomatik meta veri bulma, lakehouse'lara yapılan değişiklikleri izler ve Doku ç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, otomatik meta veri bulmanın ölçeklendirilmesine izin verdiğinden her göl evi ayrı bir çalışma alanına geçirilmelidir.
• Parquet dosyaları tasarım gereği sabittir. 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. 400 MB 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 (~400 MB)
spark.conf.set("spark.databricks.delta.optimize.maxFileSize", 400 * 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. Önerimiz, en az 1 GB'lık bir bölüme (veya yakına) neden olacak 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 python betiği için bkz . Bölüm ayrıntıları için örnek betik.

Büyük hacimli küçük boyutlu parquet dosyaları, bir lakehouse ile ilişkili SQL analiz uç noktası arasındaki değişiklikleri eşitleme süresini artırır. Delta tablosunda bir veya daha fazla nedenden dolayı çok sayıda parquet dosyasıyla sonuçlanabilir:

• Çok sayıda benzersiz değer içeren bir delta tablosu için bölüm seçerseniz, her benzersiz değer tarafından bölümlenmiş 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 veri alımı ve akış veri alımı oranları, değişikliklerin sıklığına ve boyutuna bağlı olarak göl binasına yazılma sıklığına ve boyutuna bağlı olarak küçük dosyalara neden olabilir. Ö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.
   • Doku 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 tablosu için tüm bölümlerin çıkışını alır.
3. Betik, toplam dosya boyutunu ve sayısını hesaplamak için her bölümde yinelenir.
4. Betik, bölümlerin ayrıntılarını, bölüm başına dosyaları 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

• Birlikte daha iyi: göl evi ve depo
• Doku Veri Ambarı performans yönergeleri
• SQL analiz uç noktasının sınırlamaları