En iyi deneyimler: Delta Lake

  • Makale

Bu makalede Delta Lake kullanırken en iyi yöntemler açıklanmaktadır.

Databricks tahmine dayalı iyileştirme kullanılmasını önerir. Bkz . Delta Lake için tahmine dayalı iyileştirme.

Aynı konumdaki bir tabloyu silip yeniden oluştururken her zaman bir CREATE OR REPLACE TABLE deyimi kullanmanız gerekir. Bkz. Delta tablosunu bırakma veya değiştirme.

İyileştirilmiş veri atlama için sıvı kümeleme kullanma

Databricks, veri düzenini atlama için en iyi duruma getirmek için bölümleme, Z sırası veya diğer veri düzenleme stratejileri yerine sıvı kümeleme kullanılmasını önerir. Bkz. Delta tabloları için sıvı kümeleme kullanma.

Dosyaları sıkıştırma

Unity Kataloğu yönetilen tablolarında tahmine dayalı iyileştirme otomatik olarak çalışır OPTIMIZE ve VACUUM komutlar. Bkz . Delta Lake için tahmine dayalı iyileştirme.

Databricks, küçük dosyaları sıkıştırmak için sık sık OPTIMIZE komutunun çalıştırılmasını önerir.

Not

Bu işlem eski dosyaları kaldırmaz. Bunları kaldırmak için VACUUM komutunu çalıştırın.

Tablonun içeriğini veya şemasını değiştirme

Bazen Delta tablosunu değiştirmek isteyebilirsiniz. Örneğin:

  • Tablodaki verilerin yanlış olduğunu ve içeriği değiştirmek istediğinizi fark edebilirsiniz.
  • Uyumsuz şema değişiklikleri (sütun türlerini değiştirme gibi) yapmak için tablonun tamamını yeniden yazmak istiyorsunuz.

Delta tablosunun tüm dizinini silip aynı yolda yeni bir tablo oluşturabilirsiniz ancak aşağıdakilerden dolayı önerilmez :

  • Bir dizini silmek verimli değildir. Çok büyük dosyalar içeren bir dizinin silinmesi saatler, hatta günler sürebilir.
  • Silinen dosyalardaki tüm içeriği kaybedersiniz; yanlış tabloyu silerseniz kurtarmak zordur.
  • Dizin silme işlemi atomik değildir. Tabloyu silerken, tabloyu okuyan bir eşzamanlı sorgu başarısız olabilir veya kısmi bir tablo görebilir.

Tablo şemasını değiştirmeniz gerekmiyorsa, Delta tablosundaki verileri silebilir ve yeni verilerinizi ekleyebilir veya yanlış değerleri düzeltmek için tabloyu güncelleştirebilirsiniz .

Tablo şemasını değiştirmek istiyorsanız, tablonun tamamını atomik olarak değiştirebilirsiniz. Örneğin:

Python

dataframe.write \
  .format("delta") \
  .mode("overwrite") \
  .option("overwriteSchema", "true") \
  .saveAsTable("<your-table>") # Managed table

dataframe.write \
  .format("delta") \
  .mode("overwrite") \
  .option("overwriteSchema", "true") \
  .option("path", "<your-table-path>") \
  .saveAsTable("<your-table>") # External table

SQL

REPLACE TABLE <your-table> USING DELTA AS SELECT ... -- Managed table
REPLACE TABLE <your-table> USING DELTA LOCATION "<your-table-path>" AS SELECT ... -- External table

Scala

dataframe.write
  .format("delta")
  .mode("overwrite")
  .option("overwriteSchema", "true")
  .saveAsTable("<your-table>") // Managed table

dataframe.write
  .format("delta")
  .mode("overwrite")
  .option("overwriteSchema", "true")
  .option("path", "<your-table-path>")
  .saveAsTable("<your-table>") // External table

Bu yaklaşımın birden çok avantajı vardır:

  • Dizinin özyinelemeli olarak listelenmesi veya herhangi bir dosyayı silmesi gerekmediğinden tablonun üzerine yazmak çok daha hızlıdır.
  • Tablonun eski sürümü hala var. Yanlış tabloyu silerseniz, zaman yolculuğu kullanarak eski verileri kolayca alabilirsiniz. Bkz . Delta Lake tablo geçmişiyle çalışma.
  • Atomik bir operasyon. Siz tabloyu silerken eşzamanlı sorgular tabloyu okumaya devam edebilir.
  • Delta Lake ACID işlem garantileri nedeniyle, tablonun üzerine yazılması başarısız olursa tablo önceki durumunda olur.

Ayrıca, tablonun üzerine yazdıktan sonra depolama maliyetlerinden tasarruf etmek için eski dosyaları silmek istiyorsanız, bunları silmek için VACUUM kullanabilirsiniz. Dosya silme için iyileştirilmiştir ve genellikle dizinin tamamını silmekten daha hızlıdır.

Spark önbelleğe alma

Databricks, aşağıdaki nedenlerle Spark önbelleğini kullanmanızı önermez:

  • Önbelleğe alınan DataFrameüzerine eklenen ek filtrelerden gelebilecek tüm veri atlamalarını kaybedersiniz.
  • Tabloya farklı bir tanımlayıcı kullanılarak erişilirse önbelleğe alınan veriler güncelleştirilmeyebilir.

Apache Spark'ta Delta Lake ile Parquet arasındaki farklar

Delta Lake aşağıdaki işlemleri otomatik olarak işler. Bu işlemleri asla el ile gerçekleştirmemelisiniz:

  • REFRESH TABLE: Delta tabloları her zaman en güncel bilgileri döndürür, bu nedenle değişikliklerden sonra el ile çağrı REFRESH TABLE yapmanız gerekmez.
  • Bölüm ekleme ve kaldırma: Delta Lake, bir tabloda bulunan bölüm kümesini otomatik olarak izler ve veriler eklendikçe veya kaldırıldıkçe listeyi güncelleştirir. Sonuç olarak veya MSCKkomutunu çalıştırmanız ALTER TABLE [ADD|DROP] PARTITION gerekmez.
  • Tek bir bölüm yükleme: Bölümleri doğrudan okumak gerekli değildir. Örneğin, komutunu çalıştırmanız spark.read.format("parquet").load("/data/date=2017-01-01")gerekmez. Bunun yerine, verileri atlamak için gibi spark.read.table("<table-name>").where("date = '2017-01-01'")bir WHERE yan tümce kullanın.
  • Veri dosyalarını el ile değiştirmeyin: Delta Lake, değişiklikleri tabloda atomik olarak işlemek için işlem günlüğünü kullanır. Delta tablosundaki Parquet veri dosyalarını doğrudan değiştirmeyin, eklemeyin veya silmeyin, çünkü bu veri kaybına veya tablo bozulmasına neden olabilir.

Delta Lake birleştirme performansını geliştirme

Aşağıdaki yaklaşımları kullanarak birleştirme süresini kısaltabilirsiniz:

  • Eşleşmeler için arama alanını azaltın: Varsayılan olarak, merge işlem kaynak tablodaki eşleşmeleri bulmak için Delta tablosunun tamamını arar. Hızlandırmanın merge bir yolu, eşleştirme koşuluna bilinen kısıtlamalar ekleyerek arama alanını azaltmaktır. Örneğin, tarafından bölümlenmiş country bir tablonuz olduğunu ve date son güne ve belirli bir ülkeye ilişkin bilgileri güncelleştirmek için kullanmak merge istediğinizi varsayalım. Aşağıdaki koşulun eklenmesi, sorgunun yalnızca ilgili bölümlerde eşleşmeleri araydıkça daha hızlı olmasını sağlar:

    events.date = current_date() AND events.country = 'USA'

    Ayrıca, bu sorgu diğer eşzamanlı işlemlerle çakışma olasılığını da azaltır. Diğer ayrıntılar için bkz . Azure Databricks'te yalıtım düzeyleri ve yazma çakışmaları.

  • Sıkıştırılmış dosyalar: Veriler birçok küçük dosyada depolanıyorsa, eşleşmeleri aramak için verileri okumak yavaş olabilir. Okuma aktarım hızını geliştirmek için küçük dosyaları daha büyük dosyalara sıkıştırabilirsiniz. Ayrıntılar için bkz . Delta Lake'te iyileştirme ile veri dosyalarını sıkıştırma.

  • Yazma işlemleri için karıştırma bölümlerini denetleme: İşlem merge , güncelleştirilmiş verileri hesaplamak ve yazmak için verileri birden çok kez karıştırıyor. Karıştırmak için kullanılan görev sayısı Spark oturum yapılandırması spark.sql.shuffle.partitionstarafından denetlenır. Bu parametrenin ayarlanması yalnızca paralelliği denetlemez, aynı zamanda çıkış dosyalarının sayısını da belirler. Değerin artırılması paralelliği artırır ancak aynı zamanda daha fazla sayıda daha küçük veri dosyası oluşturur.

  • İyileştirilmiş yazmaları etkinleştirme: Bölümlenmiş tablolar için, merge karışık bölüm sayısından çok daha fazla sayıda küçük dosya oluşturabilir. Bunun nedeni, her karıştırma görevinin birden çok bölüme birden çok dosya yazabilmesi ve performans sorununa dönüşebileceğidir. İyileştirilmiş yazmaları etkinleştirerek dosya sayısını azaltabilirsiniz. Bkz . Azure Databricks'te Delta Lake için iyileştirilmiş yazma işlemleri.

  • Tablodaki dosya boyutlarını ayarlama: Azure Databricks, Delta tablosunun dosyaları yeniden yazan sık işlemleri merge olup olmadığını otomatik olarak algılayabilir ve gelecekte daha fazla dosya yeniden yazma olasılığıyla yeniden yazılan dosyaların boyutunu küçültmeyi seçebilir. Ayrıntılar için dosya boyutlarını ayarlama bölümüne bakın.

  • Düşük Karışık Birleştirme: Düşük Karıştırma Birleştirme , en yaygın iş yükleri için daha iyi performans sağlayan iyileştirilmiş bir uygulaması MERGE sağlar. Ayrıca, değiştirilmemiş verilerde Z sıralama gibi mevcut veri düzeni iyileştirmelerini korur.

Veri geri kazanmayı yönetme

Her sorgunun başında, Delta tabloları tablonun en son sürümüne otomatik olarak güncelleştirilir. Komut durumu şunu bildirdiğinde bu işlem not defterlerinde gözlemlenebilir: Updating the Delta table's state. Ancak, bir tabloda geçmiş analizi çalıştırırken, özellikle akış verilerinin sık sık alındığı tablolar için son dakikaya kadar verilere ihtiyacınız olmayabilir. Bu durumlarda sorgular Delta tablonuzun eski anlık görüntülerinde çalıştırılabilir. Bu yaklaşım sorgulardan sonuç alma gecikme süresini düşürebilir.

Spark oturum yapılandırmasını spark.databricks.delta.stalenessLimit veya 15m (sırasıyla 1 saat veya 15 dakika) gibi 1h bir zaman dizesi değeriyle ayarlayarak eski veriler için toleransı yapılandırabilirsiniz. Bu yapılandırma oturuma özgüdür ve tabloya erişen diğer istemcileri etkilemez. Tablo durumu eskime sınırı içinde güncelleştirildiyse, tabloya yönelik bir sorgu en son tablo güncelleştirmesini beklemeden sonuçları döndürür. Bu ayar tablonuzun güncelleştirilmesini hiçbir zaman engellemez ve eski veriler döndürülürken güncelleştirme arka planda işlenir. Son tablo güncelleştirmesi eskilik sınırından eskiyse, tablo durumu güncelleştirmesi tamamlanana kadar sorgu sonuç döndürmez.

Düşük gecikme süreli sorgular için gelişmiş denetim noktaları

Delta Lake, denetim noktalarını delta tablosunun en iyi duruma getirilmiş bir sıklıkta toplam durumu olarak yazar. Bu denetim noktaları, tablonun en son durumunu hesaplamak için başlangıç noktası görevi görür. Denetim noktaları olmadan Delta Lake'in bir tablonun durumunu hesaplamak için işlem günlüğüne yapılan işlemeleri temsil eden büyük bir JSON dosyası koleksiyonunu ("delta" dosyaları) okuması gerekir. Ayrıca Delta Lake'in veri atlama işlemi gerçekleştirmek için kullandığı sütun düzeyinde istatistikler denetim noktasında depolanır.

Önemli

Delta Lake denetim noktaları Yapılandırılmış Akış denetim noktalarından farklıdır.

Sütun düzeyinde istatistikler bir yapı ve JSON (geriye dönük uyumluluk için) olarak depolanır. Yapı biçimi Delta Lake'in çok daha hızlı okunmasını sağlar, çünkü:

  • Delta Lake, sütun düzeyinde istatistikler elde etmek için pahalı JSON ayrıştırma gerçekleştirmez.
  • Parquet sütunu ayıklama özellikleri, bir sütuna ilişkin istatistikleri okumak için gereken G/Ç'yi önemli ölçüde azaltır.

Yapı biçimi, Delta Lake okuma işlemlerinin yükünü saniyelerden onlarca milisaniyeye düşüren ve kısa sorgular için gecikme süresini önemli ölçüde azaltan bir iyileştirme koleksiyonu sağlar.

Denetim noktalarında sütun düzeyinde istatistikleri yönetme

ve tablo özelliklerini delta.checkpoint.writeStatsAsJsondelta.checkpoint.writeStatsAsStructkullanarak istatistiklerin denetim noktalarına nasıl yazıldığından siz yönetirsiniz. Her iki tablo özelliği de ise falseDelta Lake veri atlama gerçekleştiremez .

  • Toplu yazma istatistiklerini hem JSON hem de yapı biçiminde yazar. delta.checkpoint.writeStatsAsJsontrue.
  • delta.checkpoint.writeStatsAsStruct varsayılan olarak tanımlanmamıştır.
  • Okuyucular kullanılabilir olduğunda yapı sütununu kullanır ve aksi takdirde JSON sütununu kullanmaya geri döner.

Önemli

Gelişmiş denetim noktaları, Delta Lake okuyucularıyla uyumluluğu açık kaynak kesmez. Ancak ayarının delta.checkpoint.writeStatsAsJsonfalse özel Delta Lake okuyucuları üzerinde etkileri olabilir. Performans etkileri hakkında daha fazla bilgi edinmek için satıcılarınıza başvurun.

Yapılandırılmış Akış sorguları için gelişmiş denetim noktalarını etkinleştirme

Yapılandırılmış Akış iş yüklerinizin düşük gecikme süresi gereksinimleri yoksa (alt gecikme süreleri), aşağıdaki SQL komutunu çalıştırarak gelişmiş denetim noktalarını etkinleştirebilirsiniz:

ALTER TABLE [<table-name>|delta.`<path-to-table>`] SET TBLPROPERTIES
('delta.checkpoint.writeStatsAsStruct' = 'true')

Aşağıdaki tablo özelliklerini ayarlayarak denetim noktası yazma gecikme süresini de geliştirebilirsiniz:

ALTER TABLE [<table-name>|delta.`<path-to-table>`] SET TBLPROPERTIES
(
 'delta.checkpoint.writeStatsAsStruct' = 'true',
 'delta.checkpoint.writeStatsAsJson' = 'false'
)

Veri atlama özelliği uygulamanızda yararlı değilse, her iki özelliği de false olarak ayarlayabilirsiniz. Daha sonra hiçbir istatistik toplanmaz veya yazılır. Databricks bu yapılandırmayı önermez.