Aracılığıyla paylaş

Azure Databricks'te yalıtım düzeyleri ve yazma çakışmaları

Tablonun yalıtım düzeyi, bir işlemin eşzamanlı işlemler tarafından yapılan değişikliklerden ne derece yalıtılması gerektiğini tanımlar. Azure Databricks'te yazma çakışmaları yalıtım düzeyine bağlıdır.

Delta Lake, okuma ve yazma işlemleri arasında ACID işlem garantileri sağlar. Bunun anlamı şudur:

  • Birden çok kümede birden çok yazıcı bir tablo bölümünü aynı anda değiştirebilir. Yazarlar tablonun tutarlı bir anlık görüntü görünümünü görür ve yazma işlemleri seri sırada gerçekleşir.
    • Okuyucular, iş sırasında bir tablo değiştirildiğinde bile Azure Databricks işinin başladığı tablonun tutarlı bir anlık görüntü görünümünü görmeye devam eder.

Bkz. Azure Databricks'te ACID garantileri nelerdir?.

Uyarı

Azure Databricks varsayılan olarak tüm tablolar için Delta Lake kullanır. Bu makalede, Azure Databricks'te Delta Lake'in davranışı açıklanmaktadır.

Önemli

Meta veri değişiklikleri tüm eşzamanlı yazma işlemlerinin başarısız olmasına neden olur. Bu işlemler tablo protokolünde, tablo özelliklerinde veya veri şemasında yapılan değişiklikleri içerir.

Akış okumaları, tablo meta verilerini değiştiren bir işlemeyle karşılaştıklarında başarısız olur. Akışın devam etmesi için akışı yeniden başlatmanız gerekir. Önerilen yöntemler için bkz Yapılandırılmış Akış Üretimi için Dikkat Edilmesi Gereken Hususlar.

Meta verileri değiştiren sorgu örnekleri aşağıda verilmiştir:

-- Set a table property.
ALTER TABLE table-name SET TBLPROPERTIES ('delta.isolationLevel' = 'Serializable')

-- Enable a feature using a table property and update the table protocol.
ALTER TABLE table_name SET TBLPROPERTIES ('delta.enableDeletionVectors' = true);

-- Drop a table feature.
ALTER TABLE table_name DROP FEATURE deletionVectors;

-- Upgrade to UniForm.
REORG TABLE table_name APPLY (UPGRADE UNIFORM(ICEBERG_COMPAT_VERSION=2));

-- Update the table schema.
ALTER TABLE table_name ADD COLUMNS (col_name STRING);

-- Remove column mapping (rewrites all files).
ALTER TABLE table_name SET TBLPROPERTIES ('delta.columnMapping.mode' = 'none')

Satır düzeyi eşzamanlılık ile yazma çakışmaları

Satır düzeyi eşzamanlılık, satır düzeyindeki değişiklikleri algılayarak ve eşzamanlı yazma işlemleri aynı veri dosyasındaki farklı satırları güncelleştirdiğinde veya sildiğinde oluşan çakışmaları otomatik olarak çözerek eşzamanlı yazma işlemleri arasındaki çakışmaları azaltır.

Satır düzeyi eşzamanlılık genellikle Databricks Runtime 14.2 ve üzeri sürümlerinde kullanılabilir. Satır düzeyi eşzamanlılık aşağıdaki koşullar için varsayılan olarak desteklenir:

  • Silme vektörlerinin etkin olduğu ve bölümleme içermeyen tablolar.
  • Sıvı kümelemeli tablolar, silme vektörlerini devre dışı bırakmadığınız sürece.

Bölümleri olan tablolar satır düzeyi eşzamanlılığı desteklemez, ancak silme vektörleri etkinleştirildiğinde OPTIMIZE ile diğer tüm yazma işlemleri arasındaki çakışmaları yine de önleyebilir. Bkz . Satır düzeyi eşzamanlılık sınırlamaları.

Diğer Databricks Runtime sürümleri için Satır düzeyi eşzamanlılık önizleme davranışı (eski) başlığına bakın.

MERGE INTO satır düzeyi eşzamanlılık desteği için Databricks Runtime 14.2'de Photon gerekir. Databricks Runtime 14.3 LTS ve üzerinde Photon gerekli değildir.

Aşağıdaki tabloda, satır düzeyi eşzamanlılık etkinleştirilmiş her yalıtım düzeyinde hangi yazma işlemi çiftlerinin çakışabileceği açıklanmaktadır.

Uyarı

Kimlik sütunları olan tablolar eşzamanlı işlemleri desteklemez. Bkz. Delta Lake'te kimlik sütunlarını kullanma.

INSERT (1) UPDATE, SİL, MERGE INTO OPTIMIZE
INSERT Çakışamaz
UPDATESİLMEK MERGE INTO WriteSerializable içinde çatışma meydana gelemez. Aynı satırın değiştirilmesi durumunda Serializable içinde çakışma olabilir. Bkz . Satır düzeyi eşzamanlılık sınırlamaları. Aynı satır üzerinde değişiklik yapıldığında çakışmalar olabilir. Bkz . Satır düzeyi eşzamanlılık sınırlamaları.
OPTIMIZE Çakışamaz Bu, ZORDER BY kullanıldığında çakışabilir. Aksi takdirde çakışamaz. Bu, ZORDER BY kullanıldığında çakışabilir. Aksi takdirde çakışamaz.

Önemli

(1) Yukarıdaki tablolardaki tüm INSERT işlemleri, işlemeden önce aynı tablodan herhangi bir veri okumayan ekleme işlemlerini açıklar. Aynı tabloyu okuyan alt sorgular içeren INSERT işlemleri, MERGEile aynı eşzamanlılığı destekler.

REORG işlemleri, silme vektörlerinde kaydedilen değişiklikleri yansıtacak şekilde veri dosyalarını yeniden yazma işlemiyle aynı OPTIMIZE yalıtım semantiğine sahiptir. Yükseltme uygulamak için REORG kullandığınızda, devam eden tüm işlemlerle çakişen tablo protokolleri değişir.

Satır düzeyi eşzamanlılık olmadan oluşan yazma çakışmaları

Aşağıdaki tabloda,her yalıtım düzeyinde hangi yazma işlemi çiftlerinin çakışabileceği açıklanmaktadır.

Tablolar tanımlı bölümlere sahipse veya silme vektörleri etkin değilse satır düzeyi eşzamanlılığı desteklemez. Satır düzeyi eşzamanlılık için Databricks Runtime 14.2 veya üzeri gereklidir.

Uyarı

Kimlik sütunları olan tablolar eşzamanlı işlemleri desteklemez. Bkz. Delta Lake'te kimlik sütunlarını kullanma.

INSERT (1) UPDATE, SİL, MERGE INTO OPTIMIZE
INSERT Çakışamaz
UPDATESİLMEK MERGE INTO WriteSerializable içinde çatışma meydana gelemez. Serializable'da çakışma olabilir. Bkz parçalama ile çakışmaları önleme. Serializable ve WriteSerializable ile çakışabilir. Bkz parçalama ile çakışmaları önleme.
OPTIMIZE Çakışamaz ZORDER BY kullanılmadığı sürece silme vektörleri etkinleştirilmiş tablolarla çakışamaz. Aksi takdirde çelişebilir. ZORDER BY kullanılmadığı sürece silme vektörleri etkinleştirilmiş tablolarla çakışamaz. Aksi takdirde çelişebilir.

Önemli

(1) Yukarıdaki tablolardaki tüm INSERT işlemleri, işlemeden önce aynı tablodan herhangi bir veri okumayan ekleme işlemlerini açıklar. Aynı tabloyu okuyan alt sorgular içeren INSERT işlemleri, MERGEile aynı eşzamanlılığı destekler.

REORG işlemleri, silme vektörlerinde kaydedilen değişiklikleri yansıtacak şekilde veri dosyalarını yeniden yazma işlemiyle aynı OPTIMIZE yalıtım semantiğine sahiptir. Yükseltme uygulamak için REORG kullandığınızda, devam eden tüm işlemlerle çakişen tablo protokolleri değişir.

Satır düzeyi eşzamanlılık sınırlamaları

Satır düzeyi eşzamanlılık için bazı sınırlamalar geçerlidir. Aşağıdaki işlemler için çakışma çözümü, Azure Databricks'te yazma çakışmaları için normal eşzamanlılığı izler. Bkz Satır düzeyi eşzamanlılık olmadan yazma çakışmaları.

  • Aşağıdakiler de dahil olmak üzere karmaşık koşullu yan tümceleri olan komutlar:
    • Yapılar, diziler veya haritalar gibi karmaşık veri türleriyle ilgili koşullar.
    • Belirleyici olmayan ifadeler ve alt sorgular kullanan koşullar.
    • Bağıntılı alt sorgular içeren koşullar.
  • Databricks Runtime 14.2'de MERGE komutların kaynak tabloyla eşleşen satırları filtrelemek için hedef tabloda açık bir koşul kullanması gerekir. Birleştirme çözümlemesi için, filtre yalnızca eşzamanlı işlemlerdeki filtre koşullarına göre çakışabilecek satırları tarar.

Uyarı

Satır düzeyi çakışma algılama, toplam yürütme süresini artırabilir. Çok sayıda eşzamanlı işlem söz konusu olduğunda, yazıcı çakışma çözümüne göre gecikme süresini önceliklendirir ve çakışmalar oluşabilir.

Silme vektörleri için tüm sınırlamalar da geçerlidir. Bkz. Sınırlamalar.

Delta Lake tabloyu okumadan ne zaman işleme yapar?

Delta Lake INSERT veya ekleme işlemleri, aşağıdaki koşullar karşılandığında işlemeden önce tablo durumunu okumaz:

  1. Mantık, SQL mantığı veya ekleme modu kullanılarak INSERT ifade edilir.
  2. Mantık, yazma işlemi tarafından hedeflenen tabloya başvuran alt sorgular veya koşullular içermez.

Diğer işlemelerde olduğu gibi Delta Lake de işlem günlüğündeki meta verileri kullanarak işlemedeki tablo sürümlerini doğrular ve çözümler, ancak tablonun hiçbir sürümü aslında okunmaz.

Uyarı

Birçok yaygın desen, tablo koşullarına göre veri eklemek için MERGE işlemleri kullanır. INSERT deyimlerini kullanarak bu mantığı yeniden yazmak mümkün olsa da, herhangi bir koşullu ifade hedef tablodaki bir sütuna başvuruda bulunursa, bu deyimler MERGEile aynı eşzamanlılık sınırlamalarına sahiptir.

Serileştirilebilir ve serileştirilebilir yalıtım düzeylerini yazma

Tablonun yalıtım düzeyi, bir işlemin eşzamanlı işlemler tarafından yapılan değişikliklerden ne derece yalıtılması gerektiğini tanımlar. Azure Databricks'te Delta Lake iki yalıtım düzeyini destekler: Serializable ve WriteSerializable.

  • Serileştirilebilir: En güçlü yalıtım düzeyi. Kaydedilmiş yazma işlemlerinin ve tüm okuma işlemlerinin Seri hale getirilebilir olmasını sağlar. İşlemlere, tablodakiyle aynı sonucu oluşturan bir seri bir yürütme dizisi olduğu sürece izin verilir. Yazma işlemleri için seri dizisi, tablonun geçmişinde görülenle tam olarak aynıdır.

  • WriteSerializable (Varsayılan): Serileştirilebilir'den daha zayıf bir yalıtım düzeyi. Yalnızca yazma işlemlerinin (okuma değil) serileştirilebilir olmasını sağlar. Ancak bu, anlık görüntü yalıtımından daha güçlüdür. WriteSerializable, en yaygın işlemler için büyük veri tutarlılığı ve kullanılabilirlik dengesi sağladığından varsayılan yalıtım düzeyidir.

    Bu modda Delta tablosunun içeriği, tablo geçmişinde görülen işlem dizisinden beklenenden farklı olabilir. Bunun nedeni, bu modun belirli bir eş zamanlı yazma çiftine (örneğin, X ve Y işlemleri) Y'nin X'ten önce gerçekleştirilmiş gibi bir sonuç ortaya çıkmasına izin vermesidir; bu durum, geçmişe bakıldığında Y'nin X'ten sonra tamamlanmış olduğunu gösterse bile, bu işlemler arasında serileştirilebilir olduklarını ifade eder. Bu yeniden sıralamayı önlemek için, tablo yalıtım seviyesini olarak Serileştirilebilir seviyesine ayarlayarak bu işlemlerin başarısız olmasına neden olur.

Okuma işlemleri her zaman anlık görüntü yalıtımı kullanır. Yazma yalıtım düzeyi, okuyucunun geçmişe göre "hiç varolmayan" bir tablonun anlık görüntüsünü görmesinin mümkün olup olmadığını belirler.

Serileştirilebilir düzeyi için okuyucu her zaman yalnızca geçmişe uygun tabloları görür. WriteSerializable düzeyi için, okuyucu Delta günlüğünde bulunmayan bir tablo görebilir.

Örneğin, uzun süre çalışan silme işleminin ve ekleme işleminin aynı anda başladığı ve v0 sürüm numarasını okuduğu senaryoyu göz önünde bulundurun. Ekleme işlemi önce işleme alır ve sürümünü v1oluşturur. Bundan sonra silme işlemi işlemeye v2çalışır:

t0: deleteTxn_START
t1: insertTxn_START
t2: insertTxn_COMMIT(v1)
t3: deleteTxn_COMMIT(v2)

Bu senaryoda, deleteTxn tarafından insertTxn eklenen verileri görmedim ve bu nedenle bunları silmedi:

  • Yalıtım koşulu altında Serializable taahhüt etmeye deleteTxn izin verilmez ve bir çakışma meydana gelir.
  • Yalıtım WriteSerializable altında, işlemler sıraya konabildiğinden deleteTxn işlem gerçekleştirebilir. Elde edilen tablo durumu, deleteTxn olduktan sonra insertTxn gerçekleşmiş gibi görünür, bu nedenle eklenen satırlar tablonun bir parçasıdır. Ancak, Delta geçmişi fiziksel işlem sırasını ve v1'in deleteTxn (v2) öncesinde meydana geldiğini insertTxn gösterir.

Hangi tür işlemlerin her yalıtım düzeyinde birbiriyle çakışabileceği ve olası hatalar hakkında daha fazla bilgi için bkz . Bölümleme ve kopuk komut koşullarını kullanarak çakışmaları önleme.

Yalıtım düzeyini ayarlama

yalıtım düzeyini ALTER TABLE komutunu kullanarak ayarlarsınız.

ALTER TABLE <table-name> SET TBLPROPERTIES ('delta.isolationLevel' = <level-name>)

burada <level-name> ya Serializable veya WriteSerializable.

Örneğin, varsayılan WriteSerializable olan yalıtım düzeyini Serializable olarak değiştirmek için şunu çalıştırın:

ALTER TABLE <table-name> SET TBLPROPERTIES ('delta.isolationLevel' = 'Serializable')

Bölümleme ve ayrık komut koşullarını kullanarak çakışmaları önleme

"Çakışabilir" olarak işaretlenen her durumda, iki işlemin çakışıp çakışmayacağı, aynı dosya kümesinde çalışıp çalışmadıklarına bağlıdır. tabloyu işlemlerin koşullarında kullanılanlarla aynı sütunlara göre bölümleyerek iki dosya kümesinin kopuk olmasını sağlayabilirsiniz. Örneğin, UPDATE table WHERE date > '2010-01-01' ... ve DELETE table WHERE date < '2010-01-01' iki komut, tablo tarihe göre bölümlenmezse çakışır çünkü her ikisi de aynı dosya kümesini değiştirmeyi deneyebilir. Tabloyu date'e göre bölümlendirmek çatışmayı önleyecektir. Bu nedenle, bir tablonun komutta yaygın olarak kullanılan koşullara göre bölümlenmesi çakışmaları önemli ölçüde azaltabilir. Ancak, tabloyu yüksek kardinaliteye sahip bir sütuna göre bölümleme, çok sayıda alt dizin nedeniyle diğer performans sorunlarına yol açabilir.

Çakışma istisnaları

İşlem çakışması oluştuğunda aşağıdaki özel durumlardan birini gözlemlersiniz:

EşzamanlıEkEklemeİstisnası

Bu özel durum, eşzamanlı bir işlem işleminizin okuduğu aynı bölüme (veya bölümlenmemiş bir tabloda herhangi bir yere) dosya eklediğinde oluşur. Dosya eklemeleri, INSERT, DELETE, UPDATE veya MERGE işlemlerinden kaynaklanabilir.

varsayılan yalıtım düzeyiWriteSerializable, körINSERT işlemleri tarafından eklenen dosyalar (yani, verileri okumadan verileri körü körüne ekleyen işlemler) aynı bölüme (veya bölümlenmemiş bir tabloda herhangi bir yere) dokunsalar bile hiçbir işlemle çakışmaz. Yalıtım düzeyi Serializableolarak ayarlanırsa, görünmeyen eklemeler çatışabilir.

Önemli: WriteSerializable, DELETEveya UPDATE işlemleri çalıştıran birden çok eşzamanlı işlem, kör eklemeler tarafından eklenen değerlere başvurabiliyorsa, kör eklemeler MERGE modunda çakışabilir. Bu çakışmayı önlemek için aşağıdakilerden birini yapın:

  • Eşzamanlı DELETE, UPDATEveya MERGE işlemlerinin eklenen verileri okumadığından emin olun.
  • Eklenen verileri okuyabilen en fazla bir DELETE, UPDATEveya MERGE işlemine sahip olun.

Bu özel durum genellikle eşzamanlı DELETE, UPDATEveya MERGE işlemleri sırasında oluşturulur. Eş zamanlı yürütülen işlemler fiziksel olarak farklı bölüm dizinlerini güncelleseler de, bunlardan biri, diğerinin eş zamanlı olarak güncellediği bölümü okuyabilir, bu da bir çakışmaya yol açabilir. İşlem koşulunda ayırmayı açık hale getirerek bunu önleyebilirsiniz. Aşağıdaki örneği inceleyin.

// Target 'deltaTable' is partitioned by date and country
deltaTable.as("t").merge(
    source.as("s"),
    "s.user_id = t.user_id AND s.date = t.date AND s.country = t.country")
  .whenMatched().updateAll()
  .whenNotMatched().insertAll()
  .execute()

Yukarıdaki kodu farklı tarihler veya ülkeler için eşzamanlı olarak çalıştırdığınızı varsayalım. Her iş hedef Delta tablosundaki bağımsız bir bölüm üzerinde çalıştığından herhangi bir çakışma beklemezsiniz. Ancak, koşul yeterince açık değildir ve tablonun tamamını tarayabilir ve diğer bölümleri güncelleştiren eşzamanlı işlemlerle çakışabilir. Bunun yerine aşağıdaki örnekte gösterildiği gibi, birleştirme koşuluna belirli bir tarih ve ülke eklemek için deyiminizi yeniden yazabilirsiniz.

// Target 'deltaTable' is partitioned by date and country
deltaTable.as("t").merge(
    source.as("s"),
    "s.user_id = t.user_id AND s.date = t.date AND s.country = t.country AND t.date = '" + <date> + "' AND t.country = '" + <country> + "'")
  .whenMatched().updateAll()
  .whenNotMatched().insertAll()
  .execute()

Artık bu işlemin farklı tarihlerde ve ülkelerde eşzamanlı olarak çalıştırılması güvenlidir.

ConcurrentDeleteReadException

Bu özel durum, eşzamanlı bir işlem işleminizin okuduğu bir dosyayı sildiğinde oluşur. Yaygın nedenler, dosyaları yeniden yazan bir DELETE, UPDATEveya MERGE işlemidir.

ConcurrentDeleteDeleteException

Bu özel durum, eşzamanlı bir işlem işleminizin de sildiği bir dosyayı sildiğinde oluşur. Bunun nedeni iki eşzamanlı sıkıştırma işleminin aynı dosyaları yeniden yazması olabilir.

MetadataDeğişikliğiHatası

Bu özel durum, eşzamanlı bir işlem delta tablosunun meta verilerini güncelleştirdiğinde oluşur. Yaygın nedenler, delta tablonuza yapılan ve tablonun şemasını güncelleştiren ALTER TABLE işlemler veya yazma işlemleridir.

Eşzamanlı İşlem İstisnası

Aynı denetim noktası konumunu kullanan bir akış sorgusu eşzamanlı olarak birden çok kez başlatılır ve Delta tablosuna aynı anda yazmaya çalışırsa. Hiçbir zaman aynı denetim noktası konumunu kullanan ve aynı anda çalışan iki akış sorgunuz olmamalıdır.

ProtokolDeğiştiİstisnası

Bu özel durum aşağıdaki durumlarda oluşabilir:

  • Delta tablonuz yeni bir protokol sürümüne yükseltildiğinde. Gelecekteki işlemlerin başarılı olması için Databricks Runtime'ınızı yükseltmeniz gerekebilir.
  • Birden çok yazar aynı anda bir tablo oluşturduğunda veya değiştirdiğinde.
  • Birden çok yazar aynı anda boş bir yola yazarken.

Daha fazla ayrıntı için bkz . Delta Lake özellik uyumluluğu ve protokolleri .

Satır düzeyi eşzamanlılık önizleme davranışı (eski)

Bu bölümde Databricks Runtime 14.1 ve altındaki satır düzeyi eşzamanlılık için önizleme davranışları açıklanmaktadır. Satır düzeyi eşzamanlılık her zaman silme vektörleri gerektirir.

Databricks Runtime 13.3 LTS ve üzeri sürümlerinde, sıvı kümelendiricisi etkinleştirilmiş tablolar otomatik olarak satır düzeyi eşzamanlılığı etkinleştirir.

Databricks Runtime 14.0 ve 14.1'de, küme veya SparkSession için aşağıdaki yapılandırmayı ayarlayarak silme vektörleri olan tablolar için satır düzeyi eşzamanlılığı etkinleştirebilirsiniz:

spark.databricks.delta.rowLevelConcurrencyPreview = true

Databricks Runtime 14.1 ve altında, Photon olmayan hesaplama yalnızca DELETE işlemleri için satır düzeyi eşzamanlılığı destekler.

  • Last updated on