Microsoft Fabric'de çapraz iş yükü tablosu bakımı ve iyileştirmesi

Microsoft Fabric'teki delta tablolar, OneLake'te depolanan verilerden Spark, SQL analitik uç noktası, Power BI Direct Lake, Warehouse ve diğer Fabric deneyimlerine hizmet verebilir. Optimal çapraz iş yükü performansı iki faktöre bağlıdır:

  • Tabloyu oluşturan ve bakımını yapan iş yükü.
  • Tabloyu kullanan motorlar.

Lakehouse tabloları genellikle Spark, Fabric pipeline Kopyalama etkinliği veya Dataflow Gen2 tarafından yönetilir. Spark en yaygın yazıcıdır ve en kapsamlı yerleşim ile bakım denetimlerini sunar. Depo ve veritabanı aynalamaları fiziksel düzenlerini otomatik olarak yönetir. Aynalı kataloglar, kaynak sistemde yönetilen düzeni korur. Tüketici gereksinimleri genellikle uyumludur, ancak Power BI Direct Lake optimal performans için ek depolama gereksinimleri sunar.

Gereksinimleri uygun olduğunda tek bir ortak tablo kullanın. Başka bir tabloyu haklı çıkaran istisnalar için, bkz. Ne zaman başka bir tablo oluşturulur.

Düzen sahipliğini anlayın

Fiziksel tablo düzenine hangi iş yükünün sahip olduğunu belirleyerek başlayın. Aşağıdaki tablodaki kontroller, çapraz iş yükü tablosu düzeni ve bakımıyla ilgili temel kontrollerdir; her motorun yeteneklerinin kapsamlı bir listesi değildir.

Veri deposu Yazar veya tüketme yöntemi Düzen ve bakım sahipliği Anahtar denetimleri
Lakehouse Spark Kullanıcı tarafından yönetilen Dosya boyutlandırması: uyarlanabilir hedef dosya boyutu ve dosya düzeyinde sıkıştırma hedefleri.
Yazma ve bakım: silme vektörleri, otomatik sıkıştırma, optimize yazma, OPTIMIZE, ve VACUUM.
Veri organizasyonu: sıvı kümeleme, bölümleme, Z-Order ve V-Order.
Lakehouse Fabric işlem hattı Kopyalama etkinliği ya da Dataflow Gen2 Hizmet verileri yazar; lakehouse sahibi tablonun bakımını yapar Hedefe özgü yazma ayarları. Spark, Lakehouse bakımı veya boru hattı bakım etkinliği kullanarak uyumlu bakımı ayrı ayrı yürütün.
Depo Fabric Veri Ambarı, Fabric işlem hattı Kopyalama etkinliği veya Dataflow Gen2 Depo yönetimli Veri kümeleme ve depo düzeyinde V-Order ayarı.
Aynalı eşya Yansıtma hizmeti Yansıtma türüne bağlı Veritabanı yansıtma, doğrudan yerleşim denetimleri bulunmayan, sistem tarafından yönetilen bir V-Order Delta yerleşimi kullanır. Aynalı kataloglar, kaynak dosya düzenini korur ve desteklendiğinde bunu kaynak sistemde optimize edebilirsiniz.

Çapraz iş yükü yönlendirmesi

Aşağıdaki tablo, üretici ve tüketici tarafından önerilen yaklaşımı özetlemektedir.

Producer Consumer Önerilen yaklaşım
Lakehouse: Kıvılcım yazarı Spark Fabric Spark runtime 2.0 veya daha sonraki varsayılan ayarları kullanın ve otomatik sıkıştırmayı etkinleştirin. Ölçülen yüklemler geliştirilmiş dosya atlamadan yarar sağladığında sıvı kümelemeyi değerlendirin.
Lakehouse: Kıvılcım yazarı SQL analiz uç noktası Spark için önerilen aynı düzeni kullanın. Sadece SQL analitiğinin uç nokta performansı için statik hedef dosya boyutu, rastgele satır sınırı veya V-Order koymayın.
Lakehouse: Kıvılcım yazarı Power BI Direct Lake Spark için önerilen aynı düzeni kullanın ve ayrıca V-Order'ı etkinleştirin veya kaynak profilinireadHeavyForPBI kullanın.
Lakehouse: Fabric pipeline veya Dataflow Gen2 yazıcı Spark, SQL analytics endpoint veya Power BI Direct Lake Ortaya çıkan dosya düzenini izleyin ve uyumlu göl evi bakımını ayrı ayrı planlayın. Bazı hedef modlar, örneğin Dataflow Gen2 artımlı yenileme, bakım kısıtlamaları uygular.
Depo Fabric Data Warehouse ya da Kıvılcım Sistem tarafından yönetilen düzeni kullanın. Fabric Data Warehouse sıkıştırma ve diğer bakım işlemlerini otomatik olarak yönetir. Yinelenen seçici yüklemlere sahip iş yükleri için dosya atlamayı iyileştirmek üzere veri kümeleme kullanın.
Depo Power BI Direct Lake Varsayılan Warehouse V-Order ayarını koruyun. Paylaşılan sorgu kalıplarına fayda sağladığında veri kümeleme yöntemini kullanın.
Yansıtma Spark, SQL analytics endpoint veya Power BI Direct Lake Veritabanı yansıtma için sistemce yönetilen V-Ordered Delta yerleşimini kullanın. Yansıtılmış kataloglar için, desteklendiğinde kaynak sistemdeki temel dosyaları optimize edin. Bkz. Fabric'te Yansıtma nedir?

Lakehouse tablolarını optimize et

Lakehouse Delta tabloları, Spark, Pipeline Kopyalama etkinliği veya Dataflow Gen2 tarafından yazılırsa da açık bir bakım stratejisi gerektirir. Spark, bu bölümdeki birincil örnektir çünkü Fabric'te en geniş düzen ve bakım kontrollerini sağlar.

Önemli

Tablo bakımı, motorlar arasında optimal yazma ve okuma performansı için kritiktir. Bakım olmadan başlangıçta iyi çalışan sadece ekleme amaçlı iş yükleri bile, aşırı küçük dosyalar biriktirebilir ve bu da Spark, SQL analitik uç noktası, Direct Lake ve harici veri okuyucularını etkiler. Otomatik ve manuel sıkıştırma yöntemleri için Delta tablolarını sıkıştırma sayfasına bakınız.

Spark çalışma süresi varsayılan ayarlarını kullanın

Spark tabloyu yazarken, Fabric Spark çalışma zamanı 2.0 veya daha sonraki varsayılan ayarları kullanın:

  • Adaptif hedef dosya boyutunu etkin tutun. Her tablo için 128 MB'den 1 GB'a kadar bir hedef otomatik olarak seçer.
  • Dosya düzeyinde sıkıştırma hedeflerini etkinleştirin ki önceki uyarlanabilir hedefi karşılayan dosyaları yeniden yazmaktan kaçının.
  • Silme vektörlerini etkin tutun.
  • Dosya başına rastgele maksimum satır sayısı dayatmayın. Satır genişliği değişkenlik gösterir, bu yüzden satır sınırı dar tablolar için aşırı küçük dosyalar oluşturabilir.

Fabric Spark çalışma zamanı 1.3'te, uyarlanabilir hedef dosya boyutu, dosya düzeyinde sıkıştırma hedefleri ve silme vektörleri isteğe bağlı ayarlar olarak mevcuttur.

Pipeline Copy etkinliği veya Dataflow Gen2 tabloyu yazdığında, oluşan dosya düzenini inceleyin ve bakımı ayrıca planlayın. Bu yazarların Spark çalışma süresi varsayılan ayarlarını uyguladığını varsaymayın.

Önemli

Artımlı yenileme kullanan Dataflow Gen2 lakehouse hedefleri, OPTIMIZE veya REORG TABLE desteklemez. Dataflow Gen2 artımlı yenileme sınırlamalarını göz önünde bulundurun.

Küçük dosyaları önle ve sıkıştırma

Spark tarafından yazılmış tablolar için otomatik sıkıştırma kullanın. Bu özellik, yazımdan sonra tablo parçalanmasını değerlendirir ve sadece gerektiğinde sıkıştırmayı çalıştırır. Bu, bakım çalışmalarından önce ayrı bir masa sağlığı kontrolüne gerek kalmıyor.

İstisnalar ve tamamlayıcı özellikler için aşağıdaki rehberi kullanın:

Scenario Önerilen yaklaşım
Spark tarafından yazılan tablo Varsayılan bakım stratejisi olarak otomatik sıkıştırmayı etkinleştirin.
Akış veya mikro toplu yazma işlemleri Otomatik sıkıştırmayı etkinleştirin ve küçük dosya birikimini azaltmak için yazmayı optimize edin.
Sıkı yazma gecikmesi gereksinimlerine sahip iş yükleri Senkron otomatik sıkıştırma çalıştırmak yerine ayrı ayrı planlayınOPTIMIZE.
Küçük dosyaların biriktiği mevcut tablo Bir OPTIMIZEkez çalıştırın, ardından sürekli bakım için otomatik sıkıştırmayı etkinleştirin.
Sık güncellenen, sililen veya birleştirilen tablolar Silme vektörlerini ve otomatik sıkıştırmayı etkin tutun.

OPTIMIZE dosyaları sıkıştırır ve bir dosyadaki kayıtların %5'inden fazlasına silme vektörleri tarafından başvurulduğunda, dosyanın silme vektörlerini otomatik olarak temizler. Sadece o eşik altındaki kayıtları fiziksel olarak temizlemeniz veya belirli bir uyum gereksinimini karşılamanız gerektiğinde kullanın REORG TABLE ... APPLY (PURGE) .

Note

Otomatik sıkıştırma, silme vektörlerini yalnızca bölüm küçük dosya eşiğini de karşıladığında temizler. Bir iş yükü, küçük dosyalar oluşturmadan güncelleme veya silme işlemleri gerçekleştiriyorsa, uygun silme vektörlerini temizlemek üzere OPTIMIZE komutunu düzenli aralıklarla çalıştırın. Fiziksel bir temizlemeyi zorlamanız gerektiğinde REORG TABLE ... APPLY (PURGE) kullanın.

Saklama süresinden sonra referans verilmeyen dosyaları kaldırmak için ayrı bir takvim üzerinde çalıştırın VACUUM . VACUUM Depolamayı geri alır ama aktif dosya düzenini iyileştirmez.

Uyarı

Zaman yolculuğu gereksinimlerini ve eşzamanlı okuyucu veya yazarları değerlendirmeden VACUUM saklama süresini kısaltmayın. Dosyaları çok erken silmek, gerekli tablo sürümlerini kullanılamaz hâle getirebilir.

Dosya atlama için veri organize et

Yinelenen filtreleme veya işleme kalıpları, iyileştirilmiş dosya atlama özelliğinden yarar sağlıyorsa sıvı kümeleme kullanın. Sıvı kümelenmiş tablolar, yeni yazılmış verileri düzenlemek için otomatik sıkıştırma gerektirirOPTIMIZE.

Varsayılan olarak bölümlemeden kaçının. Bunu, belirli bir gereksinim söz konusu operasyonel ödünleri haklı kıldığında kullanın; örneğin, ayrık bölümlerde verileri güncelleyen, silen veya birleştiren eşzamanlı yazıcıları yalıtmak için. Daha fazla bilgi için, bölümleme ne zaman kullanılır başlıklarına bakabilirsiniz.

Mevcut bölümlenmiş tablolar için, seçici koşullar genellikle bir bölüm içinde aynı sütunlar üzerinde filtreleme yapıyorsa Z-Order'ı göz önünde bulundurun.

Depo tarafından yönetilen tabloları optimize et

Fabric Data Warehouse, sindirme yönteminden bağımsız olarak fiziksel Delta tablo düzenini yönetir.

Warehouse'un sunduğu stratejik kontrolleri kullanarak veri düzenini ayarlayın:

  • Sorgular aynı sütunlarda tekrar tekrar seçici önlemler kullandığında büyük tablolara veri kümeleme uygulanır.
  • Okuma odaklı ve karma iş yükleri için V-Order'ı etkin tutun. V-Order varsayılan olarak etkin.
  • Yazı yoğun depo iş yükleri için V-Order'ı devre dışı bırakmayı düşünün.

Uyarı

V-Order'ı devre dışı bırakmak , depo düzeyinde, geri döndürülemez bir operasyondur. Kapatmadan önce okuma ve yazma iş yükünün tamamını test edin.

Tam Depo rehberliği için Fabric Data Warehouse'daki Performans yönergelerine bakınız.

Yansıtılmış verileri optimize et

Fiziksel düzeni iyileştirme yeteneğiniz, Fabric'in veriyi kopyalayıp çoğaltmadığına veya kaynak dosyalara referans vermesine bağlıdır:

  • Veritabanı yansıtma: Fabric, kaynak verileri OneLake'te Delta tablolarına çoğaltır ve V-Ordered dosya düzenini ve bakımını yönetir. Yansıtılan hedefte hedef dosya boyutunu, silme vektörü temizliğini, sıvı kümelemeyi, bölümlemeyi veya V-Order'ı doğrudan yapılandıramazsınız.
  • Yansıtılmış kataloglar: Fabric, meta verileri senkronize eder ve OneLake kısayollarıyla kaynak verilere referans verir. Fabric bu dosyaları yeniden yazmaz veya sürdürmez. Desteklenen özellikler izin verdiğinde kaynak sistemde fiziksel düzeni ve temizliği iyileştirin. Bu değişiklikler, Fabric'te başka bir kopya oluşturmadan kısayollardan görünür.

Veritabanı aynalı veriler için:

  • Seçici önlemler kullanın ve Spark ile SQL sorgularında gereksiz sütunlardan kaçının.
  • Verimli Direct Lake tüketimi için Power BI anlamsal modelleri ve DAX ölçümleri tasarlamak.

Aynalı kataloglar için:

  • Kaynak platformun desteklenen tablo bakım ve düzen özelliklerini kullanın.
  • Kısayolları sorgulayan Fabric kullanıcıları için kaynak dosya ve satır grup dağılımını değerlendirin.
  • Direct Lake için, kaynak düzeni performans gereksinimlerini karşılayamadığında ek boyutsal modellenmiş, V-Order servis katmanı oluşturmayı değerlendirin.

Yansıtma kavramları, türleri ve desteklenen kaynaklar için Fabric'te Yansıtma nedir? ve Meta veri yansıtma nasıl çalışır bölümlerine bakın.

Tüketiciye özgü optimizasyonu uygulayın

Spark ve SQL analiz uç noktaları, aynı adaptif lakehouse düzeni üzerinde yüksek performans gösterir. Uyarlanabilir hedef dosya boyutunu kullanın, aşırı sayıda küçük dosyayı önleyin ve ölçülen yüklemler geliştirilmiş dosya atlamasından yarar sağladığında akışkan kümeleme uygulayın. V-Order'ı sadece Spark veya SQL analytics endpoint performansı için etkinleştirmeyin. Motora özgü detaylar için SQL analytics uç nokta performans değerlendirmelerine bakınız.

Power BI Direct Lake

Direct Lake aynı altta yatan Delta tablolarını kullanır ancak transkodlama ve kademeli çerçeveleme ile ilgili öneriler ekler:

Note

Direct Lake, genellikle 1 milyon ile 16 milyon satır arasındaki satır gruplarında en iyi performansı gösterir. Desteklenen üretici ayarını değiştirmeden önce sıra-grup dağılımını ve Direct Lake performansını değerlendirin.

Spark tarafından yazılmış tablolar için, spark.sql.parquet.native.writer.maxRowGroupRowCountyerel yürütme motoru Parquet dosyalarını yazdığında satır grubu başına maksimum satır sayısını ayarlar. Varsayılan değer 0, bu da maksimum bir yük oluşturmaz. Eğer analiz, satır grubu boyutlandırmasının Direct Lake performansını etkilediğini gösteriyorsa, tabloyu yazmadan veya yeniden yazmadan önce test edilmiş bir sınır belirleyin. Örneğin:

spark.conf.set("spark.sql.parquet.native.writer.maxRowGroupRowCount", 8_000_000)

Sınırı sadece belirli bir satır sayısına ulaşmak için ayarlamayın. Satır genişliği, sıkıştırma, dosya dağılımı ve kapasite paralelliği de performansı etkiler. Ortaya çıkan düzeni değerlendirmek için Delta Analyzer kullanın.

Çerçeveleme, transkodlama, satır grupları, güncelleme desenleri ve Delta Analizörü hakkında ayrıntılı rehberlik için Direct Lake sorgu performansını Anlamak bölümünü inceleyebilirsiniz.

Rehberliği madalyon katmanlarına uygulayın

Bronz, Gümüş ve Altın verilerin amacı ve incelenmesini ifade eder. Düzenin kullanıcı tarafından mı yoksa sistem tarafından mı yönetildiğini belirlemezler ve her tüketici için ayrı kopyalar gerekmez.

Katman Birincil hedef Çapraz iş yükü yönlendirmesi
Bronz (iniş) Kaynağa sadık kalmayı ve veri alım aktarım hızını koruyun Otomatik sıkıştırma ile Spark tarafından yazılmış tabloları koruyarak yazma verimliliğini önceliklendirin. Modeli ve veri yapısını bu kullanım için bilerek tasarlamadıysanız, ham Bronze tabloları üzerinde Power BI Direct Lake semantik modellerini kullanmayın.
Silver (özenle seçilmiş) Yeniden kullanım için doğrulanmış, uyumlu veri sağlayın Tabloyu Fabric ile uyumlu tüketiciler arasında yeniden kullanın. Spark tarafından yazılmış göl evi tabloları için, V-Order'ı yalnızca Direct Lake birincil tüketici olduğunda etkinleştirin.
Altın (servis) İş kullanımına hazır boyutlar, olgular, toplulaştırmalar ve analiz modelleri sunun Direct Lake semantik modelleri için bu katmanı tercih ederim. Tabloyu uyumlu tüketiciler arasında tekrar kullanın ve bu makalede açıklanan üreticiye özgü kontrolleri uygulayın.

Düzen ve bakım sorunlarını çözmek

Üreticiye duyarlı düzeltme kullanın. Hedef mod bu işlemleri desteklediğinde Spark bakım komutlarını lakehouse tablolarına uygulayın. Sinyalleri evrensel eşikler yerine göstergeler olarak ele alın ve bunları tablonun yazma desenine ve tüketici performansına göre doğrulayın.

Condition Sinyal Lakehouse tablosu Depo masası
Aşırı küçük dosyalar Dosya sayısı aktif tablo boyutundan daha hızlı yükselir ve dosyalar adaptif hedefin altında kalır. Spark ile mevcut backlog için bir kez OPTIMIZE çalıştırın, ardından otomatik sıkıştırmayı etkinleştirin. Pipeline Copy etkinliği veya Dataflow Gen2 yazma işlemleri için, desteklenen lakehouse bakımını ayrı olarak zamanlayın. Eylem yok. Depo sıkıştırması otomatik olarak gerçekleşir.
Eski büyük boyutlu dosyalar Dosyalar, mevcut uyarlanabilir hedeften çok daha yüksek kalıyor ve çok az dosya tarama paralelliğini sınırlıyor. Tabloyu, üzerine yazma seçeneğini kullanarak veya uyarlanabilir hedef dosya boyutu etkinleştirilmiş CREATE OR REPLACE TABLE AS SELECT ile yeniden yazın. Eylem yok. Depo dosya boyutunu otomatik olarak yönetiyor.
Silme vektörü birikimi DESCRIBE HISTORY Metrikler, silme vektörlerinin sıkıştırmanın onları kaldırmasından daha hızlı eklendiğini veya güncellendiğini gösteriyor, bu da okuma yükünü artırabilir. Otomatik sıkıştırmayı etkin tutun. Silme vektörleri, küçük dosya birleştirmesini tetiklemeden birikirse OPTIMIZE öğesini zamanlayın. Sadece açık temizlik gereksinimleri için kullanın REORG TABLE ... APPLY (PURGE) . Eylem yok. Temizlik sistem tarafından yönetilir.
Hatalı dosya atlama Seçici yüklemler tablonun büyük bir bölümünü tarar veya kümeleme kalitesi değerlendirmesi kötü bir düzenlemeye işaret eder. Spark ile sıvı kümeleme yapılandırabilir veya mevcut bölümlenmiş tablo için Z-Order kullanabilirsiniz. Depo veri kümeleme yapılandırın.
Direct Lake kod dönüştürme ek yükü Delta Analyzer, güncellemelerden sonra aşırı dosyalar, küçük satır grupları veya geniş çaplı yeniden transkodlama gösteriyor. Küçük dosyaları sıkıştırın, satır gruplarını inceleyin ve Spark tarafından yazılmış tablolara V-Order uygulayın. Isteğe bağlı olarak, Parquet dosyalarında sıkıştırma kalitesini artırmak için sıvı kümeleme yapılandırın. V-Order'ı etkin tutun ve veri kümelemesini değerlendirin.
Referanssız dosya depolama büyümesi OneLake depolama, veri değiştirme işlemlerinden sonra aktif tablo boyutundan daha hızlı büyür. VACUUM öğesini saklama gereksinimlerine göre çalıştırın. Eylem yok. Temizlik sistem tarafından yönetilir.

Yansıtılmış veriler için, Yansıtılmış verileri optimize edin bölümündeki üreticiye özgü düzeltme adımlarını uygulayın. Veritabanı aynalama sistem tarafından yönetilir; Yansıtılmış kataloglar için, kaynak platformda desteklenen bakım uygulanır.

Lakehouse tabloları için Spark’ın desteklediği inceleme seçenekleri şunlardır:

  • Dosya sayısını, toplam boyutu ve değerlendirilen DESCRIBE DETAIL özelliğini incelemek için delta.targetFileSize.adaptive çalıştırın.
  • Yazma düzenlerini ve bakım geçmişini gözden geçirmek için DESCRIBE HISTORY öğesini çalıştırın.
  • Detaylı Direct Lake sıra grubu ve güncelleme deseni analizine ihtiyacınız olduğunda Delta Analyzer kullanın.

Ortalama dosya boyutunu inceleyin

Tablo düzeninin ilk göstergesi olarak ortalama dosya boyutunu hesaplamak için kullanılır DESCRIBE DETAIL :

details = spark.sql("DESCRIBE DETAIL schema_name.table_name").first()

table_size_gb = details["sizeInBytes"] / (1024**3)
num_files = details["numFiles"]
avg_file_size_mb = (
    details["sizeInBytes"] / num_files / (1024**2)
    if num_files
    else 0
)

print(f"Table size: {table_size_gb:.2f} GB")
print(f"Number of files: {num_files}")
print(f"Average file size: {avg_file_size_mb:.2f} MB")

Ortalama, bölümler arasındaki veya yakın zamanda sıkıştırılmış dosyalarla daha önce sıkıştırılmış dosyalar arasındaki dengesizliği gizleyebilir. Ortalama olası bir düzen sorunu gösterirse, bireysel Parquet dosyalarını inceleyin veya bakım ayarlarını değiştirmeden önce dağıtımı değerlendirmek için Delta Analyzer kullanın.

Ne zaman yeni bir tablo oluşturulmalıdır

Birden fazla Fabric motoru verileri kullanıyor diye yalnızca ek bir fiziksel tablo oluşturmayın.

Bağımsız bir amacı olduğunda başka bir tablo oluşturun, örneğin:

  • Verinin ayrıntı düzeyini veya iş anlamını değiştiren bir dönüşüm ya da birleştirme.
  • Farklı güvenlik, tutma veya veri kalitesi gereksinimleri.
  • Paylaşılan tablonun karşılayamadığı bir gecikme veya yenileme gereksinimi.
  • Tüketiciye özgü bir düzen, ölçülen faydası depolama, işleme, soy ve yönetişim maliyetlerini geride bırakır.

İlgili içerik

  • Last updated on