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

Microsoft Fabric'teki delta tabloları, her birinin farklı performans özelliklerine ve iyileştirme gereksinimlerine sahip birden çok tüketim altyapısına hizmet eder. Bu kılavuz, bir altyapı tarafından yazılan tabloların başkaları tarafından nasıl kullanılacağını ve tablo bakım stratejilerini buna göre nasıl iyileştireceklerini anlamak için kapsamlı bir çerçeve sağlar.

Verimli veri platformları oluşturmak için farklı altyapılarda yazma desenleri ile okuma performansı arasındaki ilişkiyi anlamak önemlidir. Amaç, veri üreticilerinin spark, SQL analiz uç noktası, Power BI Direct Lake veya Warehouse kullanıp kullanmadığı fark etmeksizin aşağı akış tüketicileri için okuma performansını en iyi duruma getiren tablo düzenleri oluşturmalarını sağlamaktır.

Senaryo matrisi yazma ve okuma

Aşağıdaki tabloda, yaygın yazma ve okuma birleşimleri için beklenen performans özellikleri ve önerilen iyileştirme stratejileri özetlenmektedir. Senaryonuzu tanımlamak ve ilgili yönergeleri anlamak için bu matrisi kullanın.

Yazma yöntemi	Okuma motoru	Beklenen boşluklar	Önerilen strateji
Spark toplu işlemi	Spark	Boşluk yok	Varsayılan Spark yazma yapılandırmaları yeterlidir
Spark toplu işlem	SQL analiz uç noktası	Boşluk yok	Otomatik sıkıştırmayı etkinleştirme ve yazmayı iyileştirme
Spark Streaming	Spark	Küçük dosyalar mümkün	Zamanlanmış OPTIMIZE ile otomatik sıkıştırma ve en iyi duruma getirme
Spark Streaming	SQL analiz uç noktası	Küçük dosyalar ve denetim noktaları	Otomatik sıkıştırma, optimizasyon-yazma, medalyon katmanlarının bölünmesi
Depo	Spark	Boşluk yok	Sistem tarafından yönetilen iyileştirme düzeni kontrol eder
Depo	SQL analiz uç noktası	Boşluk yok	Sistem tarafından yönetilen iyileştirme düzeni yönetir

Motora göre en uygun dosya düzenleri

Farklı tüketim altyapıları farklı en uygun dosya düzenlerine sahiptir. Bu hedefleri anlamak, yazma işlemlerini ve bakım işlerini uygun şekilde yapılandırmanıza yardımcı olur.

SQL Analitik Uç Noktası ve Fabric Veri Ambarı Rehberi

SQL analiz uç noktası ve Ambar ile en iyi performans için aşağıdaki ayarları kullanın:

Hedef dosya boyutu: Dosya başına yaklaşık 400 MB
Satır grubu boyutu: Satır grubu başına yaklaşık 2 milyon satır
V Sırası: Okuma performansını 10% artırır

Ambar sıkıştırma adaylarını bulmak için şu ölçütleri kullanır:

Tablo dosyasının yükü %10'dan fazla
Mantıksal olarak silinmiş tablo satırları %10'dan fazla.
Tablo boyutu 1.024 satırdan büyük

Sıkıştırma yürütme sırasında, işlem şu ölçütlere göre adayları seçer:

Herhangi bir dosya ideal boyuttan 25% küçüktür (satır sayısına göre)
Tüm dosyalarda 20'den fazla% silinen satır var

Spark

Spark, çeşitli dosya boyutlarını okurken güçlüdür. En iyi performans için:

Hedef dosya boyutu: Tablo boyutuna bağlı olarak 128 MB ile 1 GB arası
Satır grubu boyutu: Satır grubu başına 1 milyon ila 2 milyon satır
V-Order: Spark okuma performansı için gerekli değildir (yazma ek yükü % 15-33 artırabilir)

Spark okumaları, tablo boyutuna göre otomatik olarak ayarlanan uyarlamalı hedef dosya boyutundan yararlanır:

10 GB altındaki tablolar: 128 MB hedef
10 TB'ın üzerindeki tablolar: 1 GB'a kadar hedef

Power BI Direct Lake

En iyi Direct Lake performansı için:

Hedef satır grubu boyutu: En iyi performans için satır grubu başına 8 milyon veya daha fazla satır
V-Order: Soğuk önbellek sorgularında %40-60’lık iyileştirme için kritik
Dosya sayısı: Kod dönüştürme ek yükünü azaltmak için dosya sayısını en aza indirin
Tutarlı dosya boyutları: Tahmin edilebilir sorgu performansı için önemlidir

Direct Lake semantik modelleri aşağıdaki durumlarda en iyi performansı gösterir:

VertiPaq uyumlu sıkıştırmayı desteklemek için sütun verileri V sıralı düzenlenmiştir.
Satır grupları verimli sözlük birleştirme için yeterince büyük
Silme vektörleri düzenli sıkıştırma ile en aza indirildi.

Daha fazla bilgi için bkz. Direct Lake sorgu performansını anlama.

Yansıtma

Yansıtma, dosyaları tablo birimine göre otomatik olarak boyutlandırır:

Tablo boyutu	Satır grubu başına satır sayısı	Dosya başına satır sayısı
Küçük (10 GB'a kadar)	2 milyon	10 milyon
Orta (10 GB - 2,56 TB)	4 milyon	60 milyon
Büyük (2,56 TB üzerinde)	8 milyon	80 milyon

Yazma desenleri ve yapılandırmaları

Spark yazım kalıpları

Spark yazma işlemleri aşağıdaki varsayılan yapılandırmaları kullanır:

Konfigürasyon	Varsayılan değer	Description
`spark.microsoft.delta.optimizeWrite.fileSize`	128MB	İyileştirilmiş yazma işlemleri için hedef dosya boyutu
`spark.databricks.delta.optimizeWrite.enabled`	Profile göre değişir	Otomatik dosya birleştirmeyi etkinleştirir
`spark.databricks.delta.autoCompact.enabled`	Disabled	Yazma sonrası sıkıştırmayı etkinleştirir
`spark.sql.files.maxRecordsPerFile`	Sınırsız	Dosya başına en fazla kayıt sayısı

Spark yazmalarını aşağı akış SQL tüketimi için yapılandırmak için:

# Enable optimize write for better file layout
spark.conf.set('spark.databricks.delta.optimizeWrite.enabled', 'true')

# Enable auto-compaction for automatic maintenance
spark.conf.set('spark.databricks.delta.autoCompact.enabled', 'true')

Kaynak profilleri ve bunların varsayılanları hakkında daha fazla bilgi için bkz. Kaynak profili yapılandırmalarını yapılandırma.

Depo yazma kalıpları

Ambar, yazma işlemleri sırasında veri düzenini otomatik olarak iyileştirir:

Okuma iyileştirmesi için V-Order varsayılan olarak etkindir.
Otomatik sıkıştırma arka plan işlemi olarak çalışır.
Denetim noktası yönetimi otomatik olarak işlenir.

The Warehouse, manuel müdahale gerektirmeden SQL tüketimi için iyileştirilmiş dosyalar üretir. Ambar tarafından yazılan tablolar, hem SQL analiz uç noktası hem de Ambar okumaları için doğal olarak iyileştirilmiştir.

Tablo bakım işlemleri

OPTIMIZE komutu

OPTIMIZE komutu küçük dosyaları daha büyük dosyalarda birleştirir:

-- Basic optimization
OPTIMIZE schema_name.table_name

-- Optimization with V-Order for Power BI consumption
OPTIMIZE schema_name.table_name VORDER

-- Optimization with Z-Order for specific query patterns
OPTIMIZE schema_name.table_name ZORDER BY (column1, column2)

Önemli

Komut OPTIMIZE bir Spark SQL komutudur. Bunu not defterleri, Spark iş tanımları veya Lakehouse Bakım arabirimi gibi Spark ortamlarında çalıştırmanız gerekir. SQL analytics uç noktası ve Warehouse SQL sorgu düzenleyicisi bu komutu desteklemez.

Daha fazla bilgi için bkz. Tablo sıkıştırma.

Otomatik sıkıştırma

Otomatik sıkıştırma, her yazma işleminden sonra bölüm durumunu otomatik olarak değerlendirir ve dosya parçalanması algılandığında zaman uyumlu iyileştirmeyi tetikler:

# Enable at session level
spark.conf.set('spark.databricks.delta.autoCompact.enabled', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.autoOptimize.autoCompact' = 'true')
""")

El ile zamanlama yapmayı önlemek ve dosyaların otomatik olarak sıkışmasını sağlamak için sık sık küçük yazma işlemlerine (akış veya mikrobatch) sahip alım işlem hatları için otomatik sıkıştırmayı kullanın.

Otomatik sıkıştırma ve en iyi duruma getirme yazma genellikle birlikte kullanıldığında en iyi sonuçları üretir. Yazmayı iyileştirme, yazılan küçük dosyaların sayısını azaltır ve otomatik sıkıştırma kalan parçalanmayı işler.

Daha fazla bilgi için bkz. Otomatik sıkıştırma.

Yazma işlemini optimize et

Yazma işlemini iyileştirme, daha az ve daha büyük dosyalar oluşturan önceden yazma sıkıştırması gerçekleştirerek küçük dosya ek yükünü azaltır:

# Enable at session level
spark.conf.set('spark.databricks.delta.optimizeWrite.enabled', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.autoOptimize.optimizeWrite' = 'true')
""")

Yazma iyileştirmesi şu nedenler için faydalıdır:

Bölümlenmiş tablolar
Küçük eklemelerin sık yapıldığı tablolar
Birçok dosyayaMERGE (, UPDATE, DELETE) dokunan işlemler

Yazma öncesi sıkıştırma (yazma iyileştirme) genellikle yazma sonrası sıkıştırmadan (iyileştirme) daha düşük maliyetlidir. Daha fazla bilgi için bkz. Yazmayı iyileştirme.

VACUUM komutu

Delta tablo günlüğünün artık başvurmadığı eski dosyaları VACUUM komutu kaldırır.

-- Remove files older than the default retention period (7 days)
VACUUM schema_name.table_name

-- Remove files older than specified hours
VACUUM schema_name.table_name RETAIN 168 HOURS

Varsayılan saklama süresi yedi gündür. Daha kısa saklama süreleri ayarlamak Delta'nın zaman yolculuğu özelliklerini etkiler ve eşzamanlı okuyucular veya yazıcılarla ilgili sorunlara neden olabilir.

Daha fazla bilgi için bkz. Lakehouse tablo bakımı.

V-Order optimizasyonu

V-Order, Parquet dosyalarına VertiPaq uyumlu sıralama, kodlama ve sıkıştırma uygulayan bir yazma zamanı iyileştirmesidir:

Power BI Direct Lake: Soğuk önbellek sorgularında 40-60% iyileştirme
SQL analytics uç noktası ve Depo: Okuma performansında yaklaşık %10'luk bir artış
Spark: Doğal okuma avantajı yoktur; 15-33% daha yavaş yazma

V-Order ne zaman etkinleştirileceği

V-Order aşağıdakiler için en fazla avantajı sağlar:

Power BI Direct Lake tarafından desteklenen Gold-layer tablolar
SQL analiz uç noktası aracılığıyla sık sorgulanan tablolar
Yazma performansının daha az kritik olduğu yoğun okuma iş yükleri

V-Order ne zaman kaçınılır?

Aşağıdakiler için V-Order'i devre dışı bırakmayı göz önünde bulundurun:

Alım hızına odaklanan bronz katmanlı tablolar
SQL ve Power BI'ın verileri kullanmadığı Spark'tan Spark'a işlem hatları
Veri gecikme süresinin kritik olduğu yoğun yazma iş yükleri

V-Order'ı Yapılandırın

V-Order, yeni Fabric çalışma alanlarında varsayılan olarak devre dışı bırakılmıştır. Etkinleştirmek için:

# Enable at session level (default for all writes)
spark.conf.set('spark.sql.parquet.vorder.default', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.parquet.vorder.enabled' = 'true')
""")

Direct Lake tüketimine göre V-Order'ı seçmeli olarak uygulamak için, Direct Lake anlam modellerinde kullanılan tablolar için V-Order etkinleştirmesini otomatikleştirmeyi göz önünde bulundurun. Direct Lake tarafından tüketilmeyen tablolar, daha iyi yazma performansı için V-Order olmadan kalabilir.

Daha fazla bilgi için bkz . Delta Lake tablo iyileştirme ve V-Order.

Sıvı Kümelemesi ve Z Sırası

Sıvı Kümeleme

Sıvı Kümeleme, veri düzenleme için önerilen yaklaşımdır. Geleneksel bölümlemenin aksine Liquid Clustering:

Değişen sorgu desenlerine uyarlar
OPTIMIZE Kümelemenin uygulanmasını gerektirir
Filtrelenmiş sorgular için daha iyi dosya atlama sağlar

Tablo oluşturma sırasında Liquid Clustering'i etkinleştirin:

CREATE TABLE schema_name.table_name (
    id INT,
    category STRING,
    created_date DATE
) CLUSTER BY (category)

Z Sırası

Z-Order, ilgili verileri aynı dosyalarda birlikte kullanır, böylece filtre koşullarında daha iyi sorgu performansı elde edersiniz.

OPTIMIZE schema_name.table_name ZORDER BY (column1, column2)

Şu durumlarda Z-Order kullanın:

Liquid Clustering bölümlenmiş tablolarla çalışmadığından tablonuz bölümlendi.
Sorgularınız genellikle iki veya daha fazla sütunu birlikte filtreler.
Sorgu koşullarınız, dosya atlama özelliğinden yararlanacak kadar seçicidir.

Madalyon mimari önerileri

Madalyon mimarisi (Bronz, Gümüş, Altın katmanlar), her katmanın amacına göre tablo bakım stratejilerini iyileştirmeye yönelik bir çerçeve sağlar.

Bronz katman (giriş bölgesi)

Bronz tabloları yazma performansına ve düşük gecikme süreli veri alımına odaklanır.

İyileştirme önceliği: Okuma performansına göre alma hızı
Bölümleme: Yeni uygulamalar için kabul edilebilir ancak önerilmez
Küçük dosyalar: Alım hızına odaklanıldığı için kabul edilebilir
V Sırası: Tavsiye edilmez (yazma işlemlerine ek yük getirir)
Otomatik sıkıştırma: Küçük dosya sayısını azaltmak için etkinleştirilebilir, ancak alım hızını artırmak için devre dışı bırakılabilir.
Silme vektörleri: Birleştirme desenleri olan tablolar için etkinleştirme

Bronz tablolar doğrudan SQL analiz uç noktasına veya Power BI Direct Lake tüketicilerine sunulmamalıdır.

Gümüş katman (seçilmiş bölge)

Gümüş tablolar yazma ve okuma performansını dengeler:

İyileştirme önceliği: Alma ve sorgu performansı arasında denge
Dosya boyutları: Hem yazma hem de okuma işlemlerini desteklemek için orta (128-256 MB)
V-Order: İsteğe bağlı; SQL analytics uç noktası veya Power BI tüketimi önemliyse etkinleştirin
Liquid Clustering veya Z-Order: Sorgu performansını geliştirmek için önerilir
Otomatik sıkıştırma ve en iyi duruma getirme-yazma: Aşağı akış gereksinimlerine göre etkinleştirme
Silme vektörleri: Sık güncelleştirmeleri olan tablolar için etkinleştirme
Zamanlanmış İYILEŞTIRME: Dosya düzenini korumak için agresif bir şekilde çalıştırın

Altın katman (sunum bölgesi)

Altın renkli tablolar, son kullanıcı tüketimi için okuma performansını önceliklendirir:

İyileştirme önceliği: Analiz için okuma performansı
Dosya boyutları: En iyi SQL ve Power BI performansı için büyük (400 MB - 1 GB)
V Sırası: Power BI Direct Lake için gereklidir; SQL analytics uç noktası için yararlı
Sıvı Kümeleme: En iyi dosya atlama için gereklidir
İyileştirme-yazma: Tutarlı dosya boyutları için gereklidir
Zamanlanmış OPTIMIZE: Optimum düzeni sürdürmek amacıyla agresif bir şekilde çalıştırın

Altın tabloları ana tüketim motoruna göre farklı şekilde optimize edin.

Tüketim motoru	V Sırası	Hedef dosya boyutu	Satır grubu boyutu
SQL analiz uç noktası	Evet	400 MB	2 milyon satır
Power BI Direct Lake	Evet	400 MB - 1 GB	8 milyondan fazla satır
Spark	Opsiyonel	128 MB - 1 GB	1-2 milyon satır

Birden çok tablo kopyası

Farklı tüketim desenleri için en iyi duruma getirilmiş tabloların birden çok kopyasının tutulması kabul edilebilir:

Spark işleme için iyileştirilmiş Silver tablosu
SQL analiz uç noktası ve Power BI Direct Lake için optimize edilmiş Altın tablo
Her katmanda doğru yapıyı dönüştüren ve yerleştiren veri işlem hatları

Depolama, hesaplamaya göre ucuzdur. Tabloların tüketim düzenleri için iyileştirilmesi, tek bir tablo düzenindeki tüm tüketicilere hizmet vermeye çalışmaktan daha iyi bir kullanıcı deneyimi sağlar.

Tablo sağlığını tanımlama

Tabloları iyileştirmeden önce, iyileştirme gereksinimlerini anlamak için geçerli tablo durumunu değerlendirin.

Parquet dosyalarını doğrudan inceleme

Tek tek Parquet dosyalarının boyutlarını incelemek için OneLake'deki tablo klasörüne göz atabilirsiniz. İyi durumdaki tabloların eşit olarak dağıtılmış dosya boyutları vardır. Şunu arayın:

Tutarlı dosya boyutları: Dosyalar kabaca aynı boyutta olmalıdır (birbirinin 2 katı içinde).
Son derece küçük dosya yok: 25 MB'ın altındaki dosyalar parçalanmayı gösterir.
Çok büyük dosya yok: 2 GB'ın üzerindeki dosyalar paralelliği azaltabilir.

Eşit olmayan dosya boyutu dağılımı genellikle farklı işlerde eksik sıkıştırmayı veya tutarsız yazma desenlerini gösterir.

Spark SQL'de KURU ÇALıŞTıRMAYı EN İYI DURUMA GETIRME

Sıkıştırmayı DRY RUN yürütmeden hangi dosyaların iyileştirme için uygun olduğunu önizlemek için seçeneğini kullanın:

-- Preview files eligible for optimization
OPTIMIZE schema_name.table_name DRY RUN

komut, iyileştirme sırasında yeniden yazılacak dosyaların listesini döndürür. Şunu yapmak için kullanın:

Çalıştırmadan önce iyileştirme kapsamını değerlendirin.
Tabloyu değiştirmeden dosya parçalamasını anlayın.
Etkilenen dosya sayısına göre en iyi duruma getirme süresini tahmin edin.

Dosya boyutu dağıtımı

Dosya boyutlarını ve dağıtımını analiz etmek için aşağıdaki yaklaşımı kullanın:

from delta.tables import DeltaTable

# Get table details
details = spark.sql("DESCRIBE DETAIL schema_name.table_name").collect()[0]
print(f"Table size: {details['sizeInBytes'] / (1024**3):.2f} GB")
print(f"Number of files: {details['numFiles']}")

# Average file size
avg_file_size_mb = (details['sizeInBytes'] / details['numFiles']) / (1024**2)
print(f"Average file size: {avg_file_size_mb:.2f} MB")

Tablonun başına yakın olan veya belirli bir bölümden gelen dosyalar optimize edilmemiş olabileceğinden, dağıtım çarpık olabilir.

Tablonun bölümleme veya kümeleme anahtarlarına göre gruplandıran bir sorgu çalıştırarak dağıtımı değerlendirebilirsiniz.

İyileştirme gereksinimlerini belirleme

Tüketim altyapısına göre gerçek dosya boyutlarını hedef boyutlarla karşılaştırın:

Motor	Hedef dosya boyutu	Dosyalar daha küçükse	Dosyalar daha büyükse
SQL analiz uç noktası	400 MB	`OPTIMIZE` komutunu çalıştırın	Dosyalar kabul edilebilir
Power BI Direct Lake	400 MB - 1 GB	`OPTIMIZE VORDER` komutunu çalıştırın	Dosyalar kabul edilebilir
Spark	128 MB - 1 GB	Otomatik sıkıştırmayı etkinleştirme	Dosyalar kabul edilebilir

Tablo geçmişi ve işlem günlüğü

Yazma desenlerini ve bakım sıklığını anlamak için tablo geçmişini gözden geçirin:

-- View table history
DESCRIBE HISTORY schema_name.table_name

-- Check for auto-compaction runs
-- Auto-compaction shows as OPTIMIZE with auto=true in operationParameters

Yapılandırma için en iyi yöntemler

Oturum yapılandırmaları üzerinde tablo özelliklerini kullanma

Tablo özellikleri oturumlar arasında korunur ve tüm işlerde ve yazılımlarda tutarlı davranışlar sağlar.

# Recommended: Set at table level for consistency
spark.sql("""
    CREATE TABLE schema_name.optimized_table (
        id INT,
        data STRING
    )
    TBLPROPERTIES (
        'delta.autoOptimize.optimizeWrite' = 'true',
        'delta.autoOptimize.autoCompact' = 'true',
        'delta.parquet.vorder.enabled' = 'true'
    )
""")

Oturum düzeyi yapılandırmaları yalnızca geçerli Spark oturumu için geçerlidir ve farklı oturumlarda farklı yapılandırmalar kullanılıyorsa tutarsız yazma işlemlerine neden olabilir.

Uyarlamalı hedef dosya boyutunu etkinleştirme

Uyarlamalı hedef dosya boyutu, dosya boyutu hedeflerini tablo boyutuna göre otomatik olarak ayarlar:

spark.conf.set('spark.microsoft.delta.targetFileSize.adaptive.enabled', 'true')

Bu özellik:

Küçük tablolar için daha küçük dosyalarla (128 MB) başlar
10 TB üzerindeki tablolar için 1 GB'a kadar ölçeklendirilir
İşlemler sırasında OPTIMIZE otomatik olarak yeniden değerlendirilir

Dosya düzeyinde sıkıştırma hedeflerini etkinleştirme

Hedef boyutlar değiştiğinde önceden sıkıştırılmış dosyaların yeniden yazılmasını önleyin:

spark.conf.set('spark.microsoft.delta.optimize.fileLevelTarget.enabled', 'true')

Önerilerin özeti

Katman	Otomatik sıkıştırma	En iyi duruma getirme-yazma	V Sırası	Sıvı Kümeleme	Zamanlanmış OPTİMİZASYON
Bronz	Etkinleştir (isteğe bağlı)	Enable	Hayı	Hayı	Opsiyonel
Gümüş	Enable	Enable	Opsiyonel	Evet	Aggressive
Altın	Enable	Enable	Evet	Evet	Aggressive

Belirli senaryolar için aşağıdaki önerileri kullanın:

Spark-to-Spark: Dosya boyutu optimizasyonuna odaklanın; V-Order isteğe bağlıdır.
Spark-SQL: İyileştirme-yazma ve otomatik sıkıştırmayı etkinleştirme; hedef 400 MB dosya ve 2 milyon satır grubu.
Veri akışı alımı: Otomatik sıkıştırmayı etkinleştirin; SQL tüketicileri için ek OPTIMIZE görevler zamanlayın.
Power BI Direct Lake: V-Order'ı Etkinleştir; hedefi 8+ milyon satır grubu; çalıştırın OPTIMIZE VORDER.

Geri Bildirim

Bu sayfayı yararlı buldunuz mu?

Last updated on 2026-02-13