Direct Lake anlam modelleri için depolamayı anlama

Bu makale Direct Lake depolama kavramlarını tanıtır. Delta tablolarını ve Parquet dosyalarını açıklar. Ayrıca, Delta tablolarını Direct Lake anlam modelleri için nasıl iyileştirebileceğinizi ve güvenilir, hızlı sorgu performansı sağlamaya yardımcı olmak için bunların bakımını nasıl yapabileceğiniz açıklanır.

Delta tabloları

Delta tabloları OneLake'de bulunur. Dosya bazlı verileri satırlar ve sütunlar halinde düzenler ve Microsoft Fabric işlem altyapıları tarafından kullanılabilir, bunlar arasında not defterleri, Kusto, lakehouse ve ambarıbulunur. Veri Çözümleme İfadeleri (DAX), Çok Boyutlu İfadeler (MDX), T-SQL (Transact-SQL), Spark SQL ve hatta Python kullanarak Delta tablolarını sorgulayabilirsiniz.

Delta tabloları verilerini, genellikle Direct Lake semantik modelinin veri yüklemek için kullandığı bir göl evinde depolanan Parquet dosyalarında depolar. Ancak Parquet dosyaları harici olarak da depolanabilir. Dış Parquet dosyalarına, Azure Data Lake Storage (ADLS) 2. Nesil, Amazon S3 depolama hesapları veya Dataversegibi belirli bir depolama konumuna işaret eden OneLake kısayolukullanılarak başvurulabilir. Neredeyse tüm durumlarda işlem altyapıları Delta tablolarını sorgulayarak Parquet dosyalarına erişiyor. Ancak Direct Lake semantik modelleri genellikle kod dönüştürmeolarak bilinen bir işlemi kullanarak sütun verilerini doğrudan OneLake'deki iyileştirilmiş Parquet dosyalarından yükler.

Veri sürümü oluşturma

Delta tabloları bir veya daha fazla Parquet dosyası içerir. Bu dosyalara, Delta tablosuyla ilişkili her Parquet dosyasının sırasını ve doğasını izleyen JSON tabanlı bağlantı dosyaları kümesi eşlik eder.

Temel alınan Parquet dosyalarının doğası gereği artımlı olduğunu anlamak önemlidir. Bu nedenle, artımlı veri değişikliğine bir referans olarak Delta adı verilmiştir. Delta tablosuna her yazma işlemi gerçekleştiğinde (örneğin, veriler eklendiğinde, güncelleştirildiğinde veya silindiğinde) veri değişikliklerini bir sürüm olarak temsil eden yeni Parquet dosyaları oluşturulur. Bu nedenle Parquet dosyaları sabit , yani hiçbir zaman değiştirilmez. Bu nedenle verilerin Delta tablosu için bir Parquet dosyaları kümesinde birçok kez çoğaltılması mümkündür. Delta çerçevesi, doğru sorgu sonucunu elde etmek için hangi fiziksel Parquet dosyalarının gerekli olduğunu belirlemek için bağlantı dosyalarına dayanır.

Bu makalenin farklı veri değiştirme işlemlerini açıklamak için kullandığı delta tablosunun basit bir örneğini düşünün. Tabloda iki sütun vardır ve üç satır içerir.

Delta tablosu verileri, tüm verileri içeren tek bir Parquet dosyasında depolanır ve verilerin ne zaman eklendiğine (eklendiğine) ilişkin meta verileri içeren tek bir bağlantı dosyası vardır.

• Parquet dosyası 1:
  • ProductID: A, B, C
  • StockOnHand: 1, 2, 3
• Bağlantı dosyası 1:
  • Parquet file 1'nın oluşturulduğu zaman damgasını içerir ve verilerin eklendiğini kaydeder.

Ekleme işlemleri

Ekleme işlemi gerçekleştiğinde ne olacağını düşünün: Ürün C için eldeki hisse senedi değeri 4 olan yeni bir satır eklenir. Bu işlemler yeni bir Parquet dosyası ve bağlantı dosyası oluşturulmasına neden olur, bu nedenle artık iki Parquet dosyası ve iki bağlantı dosyası vardır.

• Parquet dosyası 1:
  • ProductID: A, B, C
  • StockOnHand: 1, 2, 3
• Parquet dosyası 2:
  • ProductID: D
  • StockOnHand: 4
• Bağlantı dosyası 1:
  • Parquet file 1'nın oluşturulduğu zaman damgasını içerir ve verilerin eklendiğini kaydeder.
• Bağlantı dosyası 2:
  • Parquet file 2 oluşturulma zamanını içerir ve verilerin eklendiğini kaydeder.

Bu noktada Delta tablosunun sorgusu aşağıdaki sonucu döndürür. Sonucun birden çok Parquet dosyadan kaynaklanmış olması önemli değildir.

Sonraki her ekleme işlemi yeni Parquet dosyaları oluşturur ve dosyaları bağlar. Bu, Parquet dosyalarının ve bağlantı dosyalarının sayısının her ekleme işlemiyle arttığını gösterir.

Güncelleştirme işlemleri

Şimdi bir güncelleştirme işlemi gerçekleştiğinde ne olacağını düşünün: Ürün D satırının eldeki stok değeri 10olarak değiştirildi. Bu işlemler yeni bir Parquet dosyası ve bağlantı dosyası oluşturulmasına neden olur, bu nedenle artık üç Parquet dosyası ve üç bağlantı dosyası vardır.

• Parquet dosyası 1:
  • ProductID: A, B, C
  • StockOnHand: 1, 2, 3
• Parquet dosyası 2:
  • ProductID: D
  • StockOnHand: 4
• Parquet dosyası 3:
  • Ürün Kimliği: C
  • StockOnHand: 10
• Bağlantı dosyası 1:
  • Parquet file 1 oluşturulduğu zaman damgasını içerir ve verilerin eklendiğini kaydeder.
• Bağlantı dosyası 2:
  • Parquet file 2'ın oluşturulma zaman damgasını ve verilerin eklendiğini kaydeder.
• Bağlantı dosyası 3:
  • Parquet file 3'ın ne zaman oluşturulduğuna dair zaman damgasını içerir ve verilerin güncellendiğini kaydeder.

Bu noktada Delta tablosunun sorgusu aşağıdaki sonucu döndürür.

Ürün C verileri artık birden çok Parquet dosyasında var. Ancak Delta tablosundaki sorgular, doğru sonucu sağlamak için hangi verilerin kullanılması gerektiğini belirlemek için bağlantı dosyalarını birleştirir.

Silme işlemleri

Şimdi silme işlemi gerçekleştiğinde ne olacağını düşünün: Ürün B satırı silinir. Bu işlem yeni bir Parquet dosyası ve bağlantı dosyasıyla sonuçlandığından artık dört Parquet dosyası ve dört bağlantı dosyası vardır.

• Parquet dosyası 1:
  • ProductID: A, B, C
  • StockOnHand: 1, 2, 3
• Parquet dosyası 2:
  • ProductID: D
  • StockOnHand: 4
• Parquet dosyası 3:
  • ProductID: C
  • StockOnHand: 10
• Parquet dosyası 4:
  • ProductID: A, C, D
  • StockOnHand: 1, 10, 4
• Bağlantı dosyası 1:
  • Parquet file 1 oluşturulduğu zamanı içeren zaman damgasını ve verilerin eklendiğini kaydeden bir kaydı içerir.
• Bağlantı dosyası 2:
  • Parquet file 2 oluşturulma tarihini ve verilerin eklenmiş olduğunu kaydeder.
• Bağlantı dosyası 3:
  • Parquet file 3 oluşturulduğu zaman damgasını içerir ve verilerin güncellendiğini kaydeder.
• Bağlantı dosyası 4:
  • Parquet file 4'ın oluşturulduğu zaman damgasını ve verilerin silindiğini kaydeden bir kaydı içerir.

Parquet file 4 artık ürün Biçin veri içermediğini, ancak tablodaki diğer tüm satırların verilerini içerdiğine dikkat edin.

Bu noktada Delta tablosunun sorgusu aşağıdaki sonucu döndürür.

Delta zaman yolculuğu

Bağlantı dosyaları, verilerin zamanın önceki bir noktasından itibaren sorgulanmasını sağlar. Bu özellik, Delta zaman yolculuğuolarak bilinir. Zamanın önceki noktası bir zaman damgası veya sürüm olabilir.

Aşağıdaki sorgu örneklerini göz önünde bulundurun.

SELECT * FROM Inventory TIMESTAMP AS OF '2024-04-28T09:15:00.000Z';
SELECT * FROM Inventory AS OF VERSION 2;

Aşağıda, kısaltma söz dizimi ile yeniden yazılan önceki sorgu örnekleri verilmiştir.

SELECT * FROM Inventory@20240428091500000;
SELECT * FROM Inventory@v2;

Çerçeveleme

Çerçeveleme, verileri anlam modeli sütununa yüklemek için kullanılması gereken Delta tablosunun sürümünü ayarlayan bir Direct Lake işlemidir. Aynı derecede önemli olan sürüm, veriler yüklendiğinde nelerin dışlanması gerektiğini de belirler.

Çerçeveleme işlemi, her Delta tablosunun zaman damgasını/sürümünü semantik model tablolarına damgalar. Bu noktadan itibaren anlamsal modelin Delta tablosundan veri yüklemesi gerektiğinde, yüklenecek verileri belirlemek için en son çerçeveleme işlemiyle ilişkili zaman damgası/sürüm kullanılır. En son çerçeveleme işleminden bu yana Delta tablosu için yapılan sonraki veri değişiklikleri yoksayılır (bir sonraki çerçeve işlemine kadar).

Çerçeveleme hakkında daha fazla bilgi için Direct Lake Genel Bakışbölümüne bakın.

Tablo bölümleme

Delta tabloları, satırların bir alt kümesinin tek bir Parquet dosyaları kümesinde birlikte depolanması için bölümlenebilir. Bölümler hem sorguları hızlandırabilir hem de yazma işlemlerini hızlandırabilir.

İki yıllık bir dönem için milyar satırlık satış verilerine sahip bir Delta tablosu düşünün. Tüm verileri tek bir Parquet dosyaları kümesinde depolamak mümkün olsa da, bu veri hacmi için okuma ve yazma işlemleri için uygun değildir. Bunun yerine, milyarlarca veri satırı birden çok Parquet dosyası dizisine yayılarak performans artırılabilir.

Tablo bölümleme ayarlanırken bölüm anahtarı tanımlanmalıdır. Bölüm anahtarı hangi satırların hangi seride depoleneceğini belirler. Delta tablolarında bölüm anahtarı, tarih tablosunun ay/yıl sütunu gibi belirtilen bir sütunun (veya sütunların) ayrı değerlerine göre tanımlanabilir. Bu durumda, iki yıllık veriler 24 bölüme (2 yıl x 12 ay) dağıtılır.

Doku işlem altyapıları tablo bölümlerinin farkında değildir. Yeni bölüm anahtarı değerleri eklendikçe, yeni bölümler otomatik olarak oluşturulur. OneLake'te, her benzersiz bölüm anahtarı değeri için bir alt klasör bulursunuz ve her alt klasör kendi Parquet dosyalarını ve bağlantı dosyalarını depolar. En az bir Parquet dosyası ve bir bağlantı dosyası bulunmalıdır, ancak her alt klasördeki gerçek dosya sayısı farklılık gösterebilir. Veri değiştirme işlemleri gerçekleşirken, her bölüm belirli bir zaman damgası veya sürüm için ne döndürüleceklerini izlemek için kendi Parquet dosyalarını ve bağlantı dosyalarını korur.

Bölümlenmiş Delta tablosunun sorgusu yalnızca en son üç aylık satış verilerine göre filtrelenmişse, erişilebilir olması gereken Parquet dosyalarının ve bağlantı dosyalarının alt kümesi hızla tanımlanabilir. Böylece birçok Parquet dosyasının tamamen atlanması ve daha iyi okuma performansı elde edilmesini sağlar.

Ancak bölüm anahtarında filtreleme yapmayan sorgular her zaman daha iyi performans göstermeyebilir. Delta tablosu tüm verileri tek bir büyük Parquet dosyaları kümesinde depoladığında ve dosya veya satır grubu parçalanması söz konusu olduğunda bu durum söz konusu olabilir. Birden çok küme düğümünde birden çok Parquet dosyasından veri alımını paralelleştirmek mümkün olsa da, birçok küçük Parquet dosyası dosya G/Ç'sini ve dolayısıyla sorgu performansını olumsuz etkileyebilir. Bu nedenle, yazma işlemleri veya ayıklama, dönüştürme ve yükleme (ETL) işlemlerinin bundan açıkça yararlanacağı durumlar dışında delta tablolarını bölümlemekten kaçınmak en iyisidir.

Bölümleme, ekleme, güncelleştirme ve silme işlemlerine de fayda sağlar çünkü dosya etkinliği yalnızca değiştirilmiş veya silinmiş satırların bölüm anahtarıyla eşleşen alt klasörlerde gerçekleşir. Örneğin, bir veri yığını bölümlenmiş bir Delta tablosuna eklendiğinde, veriler yığında hangi bölüm anahtarı değerlerinin mevcut olduğunu belirlemek için değerlendirilir. Daha sonra veriler yalnızca bölümler için ilgili klasörlere yönlendirilir.

Delta tablolarının bölümleri nasıl kullandığını anlamak, büyük Delta tablolarını güncelleştirirken gerçekleşmesi gereken yazma işlemlerini azaltan en uygun ETL senaryolarını tasarlamanıza yardımcı olabilir. Yazma performansı, oluşturulması gereken yeni Parquet dosyalarının sayısını ve boyutunu azaltarak artar. Önceki örnekte açıklandığı gibi aya/yıla göre bölümlenmiş büyük bir Delta tablosu için, yeni veriler yalnızca en son bölüme yeni Parquet dosyaları ekler. Önceki takvim aylarının alt klasörleri değişmeden kalır. Önceki takvim aylarının verilerinin değiştirilmesi gerekiyorsa, yalnızca ilgili bölüm klasörleri yeni bölüm ve bağlantı dosyaları alır.

Direct Lake semantik modelleri veya SQL analytics uç noktasıiçin Delta tablosu bölümlerini iyileştirmenin en iyi yolu, Delta tablosunun her sürümü için Parquet dosyalarının Fabric tarafından otomatik olarak yönetilmesine izin vermektir. Yönetimi Fabric'e bırakmak, paralelleştirme yoluyla yüksek sorgu performansı sağlamalıdır, ancak en iyi yazma performansını sağlayacağı kesin değildir.

Yazma işlemleri için iyileştirmeniz gerekiyorsa, bölüm anahtarına göre Delta tablolarında yazma işlemlerini iyileştirmek için bölümleri kullanmayı göz önünde bulundurun. Ancak Delta tablosunu bölümlemenin okuma performansını olumsuz etkileyeebileceğini unutmayın. Bu nedenle, zamanlamaları karşılaştırmak için farklı yapılandırmalara sahip aynı Delta tablosunun birden çok kopyasını oluşturarak okuma ve yazma performansını dikkatli bir şekilde test etmenizi öneririz.

Parquet dosyaları

Delta tablosunun temel depolama alanı bir veya daha fazla Parquet dosyasıdır. Parquet dosya biçimi genellikle bir kez yazılıp birçok kez okunan uygulamalar için kullanılır. Yeni Parquet dosyaları, bir Delta tablosundaki veriler ekleme, güncelleştirme veya silme işlemiyle her değiştirildiğinde oluşturulur.

Parquet dosya biçimi

Parquet dosyasının iç biçimi CSV, TSV, XMLA ve JSON gibi diğer yaygın veri depolama biçimlerinden farklıdır. Bu biçimler veri satırlara göre düzenlerken Parquet veri sütunlara göre düzenler. Ayrıca, Veri satırlarını bir veya daha fazlasatır grubu halinde düzenlediğinden Parquet dosya biçimi bu biçimlerden farklıdır.

Power BI anlam modelinin iç veri yapısı sütun tabanlıdır ve bu da Parquet dosyalarının Power BI ile çok ortak olduğu anlamına gelir. Bu benzerlik, Direct Lake semantik modelinin Parquet dosyalarındaki verileri doğrudan belleğe verimli bir şekilde yükleyebileceği anlamına gelir. Aslında, çok büyük hacimli veriler saniyeler içinde yüklenebilir. Bu özelliği, blokları veya kaynak verileri alıp sonra işleme, kodlama, depolama ve belleğe yükleme süreçlerini gerçekleştirerek yenilenen bir İçeri Aktarma semantik modeliyle kıyaslayın. İçeri aktarma semantik modeli yenileme işlemi de önemli miktarda işlem (bellek ve CPU) tüketebilir ve tamamlanması çok zaman alabilir. Ancak Delta tablolarında, anlamsal bir modele doğrudan yüklemeye uygun verileri hazırlama çabasının büyük bölümü Parquet dosyası oluşturulduğunda gerçekleşir.

Parquet dosyaları verileri nasıl depolar?

Aşağıdaki örnek veri kümesini göz önünde bulundurun.

Parquet dosya biçiminde depolandığında, kavramsal olarak bu veri kümesi aşağıdaki metin gibi görünebilir.

Header:
RowGroup1:
    Date: 2024-09-16, 2024-09-16, 2024-09-17…
    ProductID: A, B, A…
    StockOnHand: 10, 11, 13…
RowGroup2:
    …
Footer:

Veriler, ortak değerler için sözlük anahtarları değiştirilerek ve çalışma uzunluğu kodlaması (RLE) uygulanarak sıkıştırılır. RLE, aynı değer serisini daha küçük bir gösterimde sıkıştırmaya çalışır. Aşağıdaki örnekte, başlıkta sayı anahtarlarının değerlerle eşlendiği bir sözlük oluşturulur ve veri değerlerinin yerine daha küçük anahtar değerleri kullanılır.

Header:
    Dictionary: [
        (1, 2024-09-16), (2, 2024-09-17),
        (3, A), (4, B),
        (5, 10), (6, 11), (7, 13)
        …
    ]
RowGroup1:
    Date: 1, 1, 2…
    ProductID: 3, 4, 3…
    StockOnHand: 5, 6, 7…
Footer:

Direct Lake anlam modeli, ProductIDgöre gruplandırılmış StockOnHand sütununun toplamını hesaplamak için verilere ihtiyaç duyduğunda, yalnızca iki sütunla ilişkili sözlük ve veriler gereklidir. Çok sayıda sütun içeren büyük dosyalarda, okuma işlemini hızlandırmaya yardımcı olmak için Parquet dosyasının önemli bölümleri atlanabilir.

V Sırası

Fabric, V-Orderadlı ek bir optimizasyonu destekler. V-Order, Parquet dosya biçimine yönelik bir yazma zamanı iyileştirmesidir. V-Order uygulandıktan sonra daha küçük ve dolayısıyla daha hızlı bir dosyanın okunmasıyla sonuçlanır. Bu iyileştirme özellikle Direct Lake semantik modeli için geçerlidir çünkü verileri belleğe hızlı yüklemeye hazırlar ve bu nedenle kapasite kaynaklarına daha az talepte bulunur. Daha az belleğin taranması gerektiğinden daha hızlı sorgu performansına da neden olur.

veri işlem hatları gibi Doku öğeleri tarafından oluşturulan ve yüklenen delta tabloları, veri akışlarınıve not defterlerini otomatik olarak V-Order uygular. Ancak, bir Fabric lakehouse'a yüklenen veya kısayolu tarafından atıfta bulunulan Parquet dosyalarında bu iyileştirme uygulanmamış olabilir. İyileştirilmiş olmayan Parquet dosyaları hala okunabiliyor olsa da, okuma performansı büyük olasılıkla V-Order uygulanmış eşdeğer bir Parquet dosyası kadar hızlı olmayacaktır.

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

Delta tablosu iyileştirme

Bu bölümde, anlamsal modeller için Delta tablolarını iyileştirmeye yönelik çeşitli konular açıklanmaktadır.

Veri hacmi

Delta tabloları son derece büyük hacimli verileri depolamak için büyüyebilse de, Fabric kapasite sınırları bu tabloları sorgulayan anlamsal modeller üzerinde kısıtlamalar getirir. Bu sınırlar aşıldığında, sorgular DirectQuery'e geri döner ve bu da sorgu performansının daha yavaş olmasını sağlar.

Bu nedenle, büyük bir olgu tablosu ayrıntı düzeyini artırarak (özetlenmiş verileri depolayarak), boyutsallığı azaltarak veya daha az geçmiş depolayarak satır sayısını sınırlamayı göz önünde bulundurun.

Ayrıca, V-Order uygulandığından emin olun çünkü daha küçük ve dolayısıyla daha hızlı bir dosyanın okunmasıyla sonuçlanır.

Sütun veri türü

Her Delta tablosunun her sütunundaki kardinaliteyi (benzersiz değerlerin sayısı) azaltmaya çalışın. Bunun nedeni, tüm sütunların karma kodlamakullanılarak sıkıştırılması ve depolanmasıdır. Karma kodlama, sütunda yer alan her benzersiz değere bir sayısal tanımlayıcı atamak için V-Order iyileştirmesi gerektirir. Bu, depolama ve sorgulama sırasında karma arama gerektiren, depolanan sayısal tanımlayıcıdır.

yaklaşık sayısal veri türü kullandığınızda (kayan ve gerçek), değerleri yuvarlama ve daha düşük bir duyarlık kullanmayı göz önünde bulundurun.

Gereksiz sütunlar

Tüm veri tablolarında olduğu gibi Delta tabloları da yalnızca gerekli sütunları depolamalıdır. Bu makale bağlamında bu, anlamsal modelin gerektirdiği anlamına gelir, ancak Delta tablolarını sorgulayan başka analitik iş yükleri de olabilir.

Delta tabloları, model ilişkilerini destekleyen sütunlara ek olarak filtreleme, gruplandırma, sıralama ve özetleme için semantik modelin gerektirdiği sütunları içermelidir. Gereksiz sütunlar semantik model sorgu performansını etkilemez (belleğe yüklenmeyeceğinden), daha büyük bir depolama boyutuna neden olur ve bu nedenle yüklenip bakımını yapmak için daha fazla işlem kaynağı gerektirir.

Direct Lake semantik modelleri hesaplanmış sütunları desteklemediğinden, Delta tablolarında bu tür sütunları gerçekleştirmeniz gerekir. Bu tasarım yaklaşımının İçeri Aktarma ve DirectQuery semantik modelleri için bir anti-desen olduğunu unutmayın. Örneğin, FirstName ve LastName sütunlarınız varsa ve bir FullName sütuna ihtiyacınız varsa, Delta tablosuna satır eklerken bu sütunun değerlerini oluşturun.

Bazı anlamsal model özetlemelerinin birden fazla sütuna bağlı olabileceğini düşünün. Örneğin, satışları hesaplamak için modeldeki ölçü iki sütunun çarpımını toplar: Quantity ve Price. Bu sütunlardan hiçbiri bağımsız olarak kullanılmazsa, satış hesaplamasını tek bir sütun olarak yapmak, bileşen değerlerini ayrı sütunlarda depolamaktan daha verimli olacaktır.

Satır grubu boyutu

Dahili olarak, bir Parquet dosyası veri satırlarını her dosya içinde birden çok satır grubu halinde düzenler. Örneğin, 30.000 satır içeren bir Parquet dosyası bunları her birinde 10.000 satır bulunan üç satır grubuna ayırabilir.

Bir satır grubundaki satır sayısı, Direct Lake'in verileri ne kadar hızlı okuyabileceğini etkiler. Daha az satıra sahip daha fazla sayıda satır grubu, aşırı G/Ç nedeniyle sütun verilerinin anlamsal modele yüklenmesini olumsuz etkileyebilir.

Genel olarak, varsayılan satır grubu boyutunu değiştirmenizi önermeyiz. Ancak, büyük Delta tabloları için satır grubu boyutunu değiştirmeyi düşünebilirsiniz. Zamanlamaları karşılaştırmak için farklı yapılandırmalara sahip aynı Delta tablolarının birden çok kopyasını oluşturarak okuma ve yazma performansını dikkatle test etmeye dikkat edin.

Delta tablosu bakımı

Zaman içinde, yazma işlemleri gerçekleştikçe Delta tablosu sürümleri birikir. Sonunda, okuma performansı üzerinde olumsuz bir etkinin fark edilebilir hale geldiği bir noktaya ulaşabilirsiniz. Daha da kötüsü, tablo başına Parquet dosyalarının sayısı veya tablo başına satır grupları ya da tablo başına satır sayısı kapasite içinkorumalarını aşarsa, sorgular DirectQuery'e geri döner ve bu da sorgu performansının düşmesine neden olabilir. Bu nedenle Delta tablolarını düzenli olarak korumanız önemlidir.

OPTİMİZE

Delta tablosunu daha küçük dosyaları daha büyük dosyalarla birleştirecek şekilde iyileştirmek için OPTIMIZE kullanabilirsiniz. WHERE yan tümcesini, belirli bir bölüm koşuluyla eşleşen yalnızca filtrelenmiş bir satır alt kümesini hedeflemek için de ayarlayabilirsiniz. Yalnızca bölüm anahtarları içeren filtreler desteklenir. OPTIMIZE komutu, Parquet dosyalarını sıkıştırmak ve yeniden yazmak için V-Order da uygulayabilir.

EtL işleminiz tamamlandığında büyük, sık güncelleştirilen Delta tablolarında bu komutu düzenli aralıklarla çalıştırmanızı öneririz. Daha iyi sorgu performansı ile tabloyu iyileştirmek için gereken kaynak kullanımı maliyeti arasındaki dengeyi sağlayın.

VAKUM

Artık başvurulmayan ve/veya ayarlanan bekletme eşiğinden daha eski dosyaları kaldırmak için VACUUM kullanabilirsiniz. Uygun saklama süresini ayarlamaya dikkat edin; aksi takdirde, semantik model tablolarına damgalanmış çerçeveden daha eski bir sürüme zaman yolculuğu yeteneğinizi kaybedebilirsiniz.

TABLO YENİDEN DÜZENLE

REORG TABLE kullanarak geçici olarak silinen verileri temizlemek için dosyaları yeniden yazarak delta tablosunu yeniden düzenleyebilirsiniz. Örneğin, ALTER TABLE DROP COLUMN kullanarak bir sütunu bıraktığınızda.

Tablo bakımını otomatikleştirme

Tablo bakım işlemlerini otomatikleştirmek için Lakehouse API'sini kullanabilirsiniz. Daha fazla bilgi için bkz. Lakehouse'u Microsoft Fabric REST API ile yönetme.

İlgili içerik

• Direct Lake'e genel bakış
• Direct Lake anlam modelleri geliştirme
• Direct Lake anlam modellerini yönetme
• Delta Lake tablo iyileştirmesi ve V-Order