Gelişmiş AUTO CDC konuları

Temel AUTO CDC ve AUTO CDC FROM SNAPSHOT API'lerin ötesinde hedef tablolarda DML çalıştırabilir, CDC hedeflerinden değişiklik veri akışlarını okuyabilir, işleme ölçümlerini izleyebilir, kısmi güncelleştirmeleri uygulayabilir ve bitemporal depolama ile değişiklikleri izleyebilirsiniz. API'lere giriş için AUTO CDC bkz. AUTO CDC API'leri: İşlem hatları ile değişiklik verilerini yakalamayı basitleştirme.

Hedef akış tablosuna veri ekleme, değiştirme veya silme

İşlem hattınız tabloları Unity Kataloğu'nda yayımlıyorsa, akış tablolarında (DML) deyimlerini, örneğin ekleme, güncelleştirme, silme ve birleştirme deyimlerini kullanarak, AUTO CDC ... INTO deyimleriyle oluşturulan hedef tabloları değiştirebilirsiniz.

Uyarı

  • Akış tablosunun tablo şemasını değiştiren DML deyimleri desteklenmez. DML deyimlerinizin tablo şemasını geliştirmeye çalışmadığından emin olun.
  • Akış tablosunu güncelleştiren DML deyimleri, Databricks Runtime 13.3 LTS ve üzeri kullanılarak yalnızca paylaşılan unity kataloğu kümesinde veya SQL ambarında çalıştırılabilir.
  • Akış, yalnızca eklemeye izin veren veri kaynakları gerektirdiğinden, işlemeniz bir kaynak akış tablosundan değişiklikler içeren akış gerektiriyorsa (örneğin, DML deyimleri kullanılarak), kaynak akış tablosunu okurken skipChangeCommits bayrağını ayarlayın. skipChangeCommits ayarlandığında, kaynak tablodaki kayıtları silen veya değiştiren işlemler yoksayılır. İşlemeniz bir akış tablosu gerektirmiyorsa, ekleme kısıtlaması olmayan gerçekleştirilmiş bir görünümü hedef tablo olarak kullanabilirsiniz.

İşlem hattı belirtilen SEQUENCE BY bir sütun kullandığından ve hedef tablonun ve __START_AT sütunlarına __END_AT uygun sıralama değerlerini yaydığından (SCD Tür 2 için), DML deyimlerinin kayıtların doğru sıralamasını korumak için bu sütunlar için geçerli değerler kullandığından emin olmanız gerekir. Bkz. AUTO CDC nasıl çalışır?

Akış tablolarıyla DML deyimlerini kullanma hakkında daha fazla bilgi için bkz. Akış tablosunda veri ekleme, değiştirme veya silme.

Aşağıdaki örnek, başlangıç dizisi 5 olan etkin bir kayıt ekler:

INSERT INTO my_streaming_table (id, name, __START_AT, __END_AT) VALUES (123, 'John Doe', 5, NULL);

İpucu

SCD Tür 2 hedef tablosundaki __START_AT ve __END_AT sütunlarını yeniden adlandırmanız gerekiyorsa (örneğin, karşılayan şema gereksinimlerine uyum sağlamak için), hedef tablo üzerinde bir görünüm oluşturun.

CREATE VIEW my_employees_view AS
SELECT
  *,
  __START_AT AS valid_from,
  __END_AT AS valid_to
FROM my_scd2_target_table;

AUTO CDC hedef tablosundan değişiklik veri akışını okuma

Databricks Runtime 15.2 ve üzeri sürümlerde, diğer Delta tablolarındaki değişiklik veri akışını okuduğunuz şekilde, AUTO CDC veya AUTO CDC FROM SNAPSHOT sorgularının hedefi olan bir akış tablosundan da değişiklik veri akışını okuyabilirsiniz. Bir hedef akış tablosundan değişiklik veri akışını okumak için aşağıdakiler gereklidir:

  • Hedef akış tablosunun Unity Kataloğu'nda yayımlanması gerekir. Bkz. Unity Kataloğu'nu işlem hatlarıyla kullanma.
  • Hedef akış tablosundaki değişiklik veri akışını erişmek için Databricks Runtime 15.2 veya üzerini kullanmanız gerekir. Değişiklik veri akışını farklı bir işlem hattında okumak için işlem hattının Databricks Runtime 15.2 veya üzerini kullanacak şekilde yapılandırılması gerekir.

Lakeflow işlem hattında oluşturulan bir hedef akış tablosundaki değişiklik veri akışını, diğer Delta tablolarından değişiklik veri akışını okumakla aynı şekilde okursunuz. Python ve SQL örnekleri de dahil olmak üzere Delta değişiklik veri akışı işlevini kullanma hakkında daha fazla bilgi edinmek için bkz. Azure Databricks değişiklik veri akışını kullanma.

Uyarı

Değişiklik veri akışı kaydı, değişiklik olayının türünü tanımlayan meta verileri içerir. Tabloda bir kayıt güncellendiğinde, ilişkili değişiklik kayıtlarının meta verileri genellikle _change_type değerlerine ayarlanmış ve update_preimage ile update_postimage olaylarını içerir.

Ancak, birincil anahtar değerlerinin değiştirilmesini _change_type içeren hedef akış tablosunda güncelleştirmeler yapıldığında değerler farklıdır. Değişiklikler birincil anahtar güncelleştirmelerini içerdiğinde, _change_type meta veri alanları, insert ve delete olayları olarak ayarlanır. Birincil anahtarlardaki değişiklikler, UPDATE veya MERGE deyimiyle anahtar alanlarından birinde manuel güncellemeler yapıldığında veya SCD tür 2 tabloları için __start_at alanı, daha önceki bir başlangıç dizisi değerini yansıtacak şekilde değiştiğinde meydana gelebilir.

Sorgu AUTO CDC , SCD tür 1 ve SCD tür 2 işleme için farklılık gösteren birincil anahtar değerlerini belirler:

SCD Türü Birincil anahtar
SCD türü 1 ve işlem hatları için Python arabirimi Birincil anahtar, keys işlevindeki create_auto_cdc_flow() parametresinin değeridir. SQL arabirimi için birincil anahtar, KEYS ifadesindeki AUTO CDC ... INTO yan tümcesi tarafından tanımlanan sütunlardır.
SCD türü 2 Birincil anahtar, keys işleminden gelen dönüş değeri ile birlikte KEYS parametresi veya coalesce(__START_AT, __END_AT) yan tümcesidir; burada __START_AT ve __END_AT, hedef akış tablosundaki ilgili sütunlar olarak konumlanır. Bu, kullanılabiliyorsa __START_AT ve __END_AT null olduğunda (örneğin, ilk kayıt için) __START_AT kullanır.

Bir değişiklik veri akışını maddeleştirilmiş bir görünümden okuyun

Important

Bu özellik Beta sürümündedir. Çalışma alanı yöneticileri Bu özelliğe erişimi Önizlemeler sayfasından denetleyebilir. Bkz. Azure Databricks önizlemelerini yönetme.

Bir Lakeflow boru hattında veya Databricks SQL'de oluşturulan bir malzemeleştirilmiş görünümden bir değişiklik veri akışını okuyabilirsiniz. Bunu, Azure Databricks dışındaki hedeflere uygulanan materyalize görünüm değişikliklerini çoğaltmak veya denetim ve raporlama için gerçekleşmiş görünüm değişikliklerinin geçmişini tutmak için kullanın.

Maddeleştirilmiş görünümler otomatik değişim veri akışını kullanır, bu yüzden değişiklik veri akışını açmıyorsunuz. Bunun yerine, ihtiyacınız olan her maddeleştirilmiş görünümde değişiklik veri akışını etkinleştirerek aşağıdaki gereksinimleri karşılarsınız. Bkz. Otomatik değişiklik veri akışı.

  • Değişiklik veri akışını okumak için, klasik hesaplama, sunucusuz hesaplama veya Databricks SQL üzerinden Databricks Runtime 18 LTS veya üzeri kullanmanız gerekir.

  • Maddeleştirilmiş görünüm, onu oluşturan boru hattı veya onu okuyan boru hattı kanalı PREVIEW kullanmak zorundadır.

  • Maddeleştirilmiş görünümde satır takibi etkinleştirilmiş olmalıdır. Sunucusuz hesaplamada maddeleşmiş görünümlerde varsayılan olarak satır izleme etkindir. Bkz. Azure Databricks’te satır izleme. Maddeleştirilmiş bir görünümde satır izlemenin etkin olup olmadığını kontrol etmek için şu çalıştırın:

    SHOW TBLPROPERTIES my_mv ('delta.enableRowTracking');

  • Maddeleştirilmiş görünüm meta verisi, kendi boru hattı dışında okunabilir olacak şekilde senkronize edilmelidir:

    • Pipeline'da oluşturulan bir maddeleştirilmiş görünüm için, pipeline yapılandırmasında ayarla pipelines.externalMetadata.enabled :

      {
  "configuration": {
    "pipelines.externalMetadata.enabled": "true"
  }
}

    • Bağımsız bir maddeleştirilmiş görünüm için, her maddeleştirilmiş görünümde aşağıdaki komutu bir kez çalıştırın. Bu komut, maddeleştirilmiş görünümler ve akış tabloları için harici erişim önizlemesini gerektirir. Bkz. Akış tablolarına ve somutlaştırılmış görünümlere dış veri erişimini etkinleştirme.

      REPAIR TABLE my_mv SYNC METADATA;

Değişiklik veri akışını, diğer Delta tablolarındaki gibi materyalize edilmiş görünümden okursunuz; fonksiyon table_changes() , akış okuma veya readChangeFeed seçenek kullanılarak. SQL ve Python'da sözdizimi ve örnekler için bkz. Use change data feed on Azure Databricks.

Bir Databricks SQL materyalize edilmiş görünüm veya akış tablosunun içinden bir maddeleştirilmiş görünüm değişimi veri akışını okumak için, o maddeleştirilmiş görünüm veya akış tablosu da şu kanalı PREVIEW kullanmalıdır:

CREATE OR REFRESH STREAMING TABLE sales
TBLPROPERTIES ('pipelines.channel' = 'preview')
  AS SELECT * FROM STREAM my_mv WITH (readChangeFeed=true)

Limitations

Otomatik değişiklik veri beslemesi sınırlamalarına ek olarak, bir değişiklik veri akışını maddeleştirilmiş bir görünümden okunduğunuzda aşağıdakiler geçerlidir:

  • Değişiklik veri akışı, maddeleştirilmiş görünüm tamamen yeniden yazıldığında değişmemiş satırlar içerir ve aynı satıra birden fazla güncellemeyi tek bir olayda birleştirmez. Bunları filtrelemek için, değişiklik veri akışını tüm sütunlarda gruplayarak aynı satır değerlerini paylaşan ekleme ve silme öğelerini bularak toplayın.
  • Yalnızca Azure Databricks, changedata feed'i maddeleştirilmiş görünüm için sorgulayabilir. Dış Delta Gölü ve Iceberg müşterileri bunu yapamaz.
  • Lakeflow boru hatları içinde, yalnızca farklı bir boru hattından gelen bir maddeleştirilmiş görünüm değişikliği veri akışını okuyabilirsiniz ve o boru hattı kanalı PREVIEW kullanmak zorundadır. Aynı boru hattında gerçekleşmiş bir görünümün değişim veri akışını okumak desteklenmez.
  • Maddeleştirilmiş bir görünümden vektör arama indeksi oluşturamazsınız.

Veri işleme hatlarındaki CDC sorgusu tarafından işlenen kayıtlar hakkında veri alın

Uyarı

Aşağıdaki ölçümler yalnızca AUTO CDC sorgular tarafından yakalanır, AUTO CDC FROM SNAPSHOT sorgular tarafından yakalanmaz.

Aşağıdaki metrikler AUTO CDC sorgular tarafından yakalanır.

  • num_upserted_rows: Güncelleştirme sırasında veri kümesine ekli çıkış satırlarının sayısı.
  • num_deleted_rows: Güncelleştirme sırasında veri kümesinden silinen mevcut çıkış satırlarının sayısı.

num_output_rows CDC olmayan akışlar için çıkış olan ölçüm, AUTO CDC sorgular için yakalanmaz.

Kısmi güncelleştirmeleri uygulama

Bir kaynak yalnızca değişen sütunları gönderdiğinde, AUTO CDC hedef değeri değiştirmeden bırakması gereken bir değişiklik kaydında bulunmayan bir sütunu ve hedef değerin nullüzerine yazılması gereken açıkça olarak olarak ayarlanmış nullbir sütunu ayırt etmelidir. Varsayılan olarak, IGNORE NULL UPDATES her null öğesini "güncelleştirme" işaretçisi olarak ele alır, bu nedenle açık nullbir uygulayamaz. Bu belirsizliği çözmek için aşağıdaki üç yöntemden birini seçin:

Method Ne zaman kullanılır? Davranış
IGNORE NULL UPDATES ON columnList Küçük, sabit bir sütun kümesinin değerleri yoksayması null gerekirken, diğer tüm sütunlar açık null değerler uygular. Gelen değer olduğunda null, listelenen sütunlar mevcut hedef değerlerini tutar. Diğer tüm sütunlar açık null değerler uygular.
IGNORE NULL UPDATES ON * EXCEPT (exceptColumnList) Sütunların çoğu değerleri yoksaymalı null ve yalnızca birkaçı açık null değerler uygulamalıdır. Listelenen sütunlar açık null değerler uygular. Gelen değer olduğunda nulldiğer tüm sütunlar mevcut hedef değerlerini tutar.
COLUMNS TO UPDATE Her değişiklik kaydı farklı bir sütun kümesini güncelleştirir veya zaman içinde güncelleştirilebilir sütun kümesi değişir. Kaynak sütun, her değişiklik kaydı için güncelleştirilecek sütunları adlandırın. Listelenen sütunlar, açık null değerler de dahil olmak üzere kaynaktan yazılır. Listelenmeyen sütunlar var olan hedef değerlerini tutar.

COLUMNS TO UPDATE ile IGNORE NULL UPDATESbirleştirilemez ve bitemporal tablolarında desteklenmez.

Kural olarak, üreticinin her kayıtta hangi sütunların değiştiğini ne zaman bildiğini ve birden çok üreticinin aynı kaynağa yazması veya zaman içinde güncelleştirilebilir sütun kümesi gibi bu bilgileri bir kaynak sütunda taşıyabileceğini seçin COLUMNS TO UPDATE . IGNORE NULL UPDATES ON İşlem hattı sahibinin sabit güncelleştirilebilir sütun kümesini önceden ne zaman bildiğini ve bunları işlem hattı kodunda denetlemeyi tercih ettiğinde seçin.

Aşağıdaki örnekte, kayıt güncelleştirmelerini hangi sütunların değiştireceğini denetlemek için adlı columnsToUpdate bir kaynak sütun kullanılır ve sütunlar açıkça olarak nullolarak ayarlanır:

Python

from pyspark import pipelines as dp

dp.create_streaming_table("target")

dp.create_auto_cdc_flow(
  target = "target",
  source = "cdc_source",
  keys = ["id"],
  sequence_by = "sequenceNum",
  stored_as_scd_type = 1,
  columns_to_update = "columnsToUpdate"
)

SQL

CREATE OR REFRESH STREAMING TABLE target;

CREATE FLOW apply_cdc AS AUTO CDC INTO
  target
FROM
  stream(cdc_source)
KEYS
  (id)
SEQUENCE BY
  sequenceNum
STORED AS
  SCD TYPE 1
COLUMNS TO UPDATE
  columnsToUpdate;

Tam parametre başvurusu için bkz. AUTO CDC INTO (işlem hatları) ve create_auto_cdc_flow.

İki zamanlık OTO CDC

Important

Bitemporal AUTO CDC Beta sürümündedir.

SCD Tür 1 ve Tür 2 unitemporal'dır: değişiklikleri tek bir zaman boyutunda izlerler. Bitemporal, SCD Tür 2 geçmişini iki zaman boyutunda değişiklikleri izlemek ve iki perspektif arasında ayrım yapmak için genişletir:

  • İş zamanı: olayın gerçekleştiği zaman.
  • Sistem zamanı: sistemin olayı kaydettiği veya sisteme aldığı zaman.

SCD Tip 2 gibi bitemporal da kayıtların tam geçmişini korur. İkinci bir zaman çizelgesi ekler, böylece hem verilerin gösterdiği hem de sistemin geçmişteki herhangi bir noktada neye inandığını yeniden oluşturabilirsiniz.

Örneğin, bir hedge fonu bir kaynak sistemden hisse senedi verilerini alır. Acme Corp’un hisse senedi fiyatı 1 Ocak'ta değişir, ancak fon bu güncellemeyi 5 Ocak'a kadar içeri aktarmaz. Bitemporal AUTO CDC, fonun iki farklı soruyu yanıtlamasına olanak tanır: Acme Corp'un gerçek hisse senedi fiyatının 1 Ocak'ta ne olduğu (iş zamanı) ve fon 3 Ocak'ta alım satım kararları aldığında sistemin neye inandığı (sistem saati). Bu zaman çizelgelerini ayırt edebilme özelliği denetim, mevzuat raporlama ve finansal karar alma için kullanışlıdır.

Bitemporal işlemeyi etkinleştirmek için ( SQL) veya (Python) ayarlayın STORED AS BITEMPORAL , iş zamanı sütunu için kullanın stored_as_scd_type="bitemporal" ve sistem saati sütunu için kullanınSEQUENCE BY.SYSTEM SEQUENCE BY Hedef tablo, SCD Tip 2 __SYSTEM_START_AT ve __SYSTEM_END_AT sütunlarının yanı sıra __START_AT ve __END_AT sütunlarını ekler. Söz dizimi ayrıntıları için bkz. AUTO CDC INTO (pipelines) veya create_auto_cdc_flow.

Bitemporal AUTO CDC örnekleri

Aşağıdaki örnek, küçük bir sentetik CDC olay kümesinden bitemporal hedef tablosu oluşturur. bt sütununda iş zamanı, st sütununda ise sistem zamanı bulunur.

Python

from pyspark import pipelines as dp

# Source: synthetic CDC events
dp.create_streaming_table(name="cdc_source")

@dp.append_flow(target="cdc_source", once=True)
def load_cdc_source():
  return spark.createDataFrame(
    [
      (1, "x10", "y10", 10, 100),
      (1, "x20", "y20", 20, 200)
    ],
    schema="id INT, x STRING, y STRING, bt INT, st INT",
  )

# Target: bitemporal table
dp.create_streaming_table(name="target_bitemporal")

dp.create_auto_cdc_flow(
  target = "target_bitemporal",
  source = "cdc_source",
  keys = ["id"],
  sequence_by = "bt",
  system_sequence_by = "st",
  stored_as_scd_type = "bitemporal"
)

SQL

-- Source: synthetic CDC events
CREATE OR REFRESH STREAMING TABLE cdc_source_sql;

CREATE FLOW cdc_source_sql AS INSERT INTO ONCE
  cdc_source_sql BY NAME
SELECT * FROM VALUES
  (1, 'x10', 'y10', 10, 100),
  (1, 'x20', 'y20', 20, 200)
  AS t(id, x, y, bt, st);

-- Target: bitemporal table
CREATE OR REFRESH STREAMING TABLE target_bitemporal_sql;

CREATE FLOW target_bitemporal_sql AS AUTO CDC INTO
  target_bitemporal_sql
FROM
  stream(cdc_source_sql)
KEYS
  (id)
SEQUENCE BY
  bt
SYSTEM SEQUENCE BY
  st
STORED AS
  BITEMPORAL;

Aşağıdaki değişiklik dizisi, bitemporal tablosunun bir ekleme, güncelleştirme, sıra dışı güncelleştirme ve tek bir şirket için silmeyi nasıl kaydettiğini gösterir. Sıralama sütunu ve __START_AT (iş zamanı) sütunlarını__END_AT, sistem sıralama sütunu ise ve __SYSTEM_START_AT (sistem saati) sütunlarını oluşturur__SYSTEM_END_AT:

Column Description
__START_AT Bu satırın geçerli hâle geldiği işlem zamanı.
__END_AT Bu satırın geçerliliğinin sona erdiği iş zamanı. null süresiz olarak geçerliyse.
__SYSTEM_START_AT Bu satırın verilerinin ve iş zamanı aralığının geçerli olduğunun bilindiği sistem saati.
__SYSTEM_END_AT Bu satıra ait verilerin ve iş zamanı aralığının geçersiz kılındığının bilindiği sistem saati. null süresiz olarak doğru olduğu biliniyorsa.

Sistem, her iki zaman çizelgesinde de herhangi bir sırada gelen olayları işler. Bir olay, önceden işlenen olaylardan daha eski bir iş zamanı veya sistem saatiyle geldiğinde, sistem yalnızca sonuna eklemek yerine etkilenen geçmişi düzelter.

Değişiklik 1: Ekle

Şirket A, 18.07.2025 10:01:00'de (iş saatiyle) eklenir, ancak 10:05:00'te (sistem saatine göre) sisteme alınır.

Giriş:

Şirket Kimliği Veri Noktası Sıralama Sistem Sıralama Operation
A XFv1 7/18/2025 10:01:00 7/18/2025 10:05:00 INSERT

Çıktı:

Şirket Kimliği Veri Noktası __START_AT __END_AT __SYSTEM_START_AT __SYSTEM_END_AT
A XFv1 7/18/2025 10:01:00 NULL 7/18/2025 10:05:00 NULL

XFv1, bilinen bir sonu olmadan 10:01:00'dan itibaren geçerlidir. Sistem bu durumu sistem zamanı 10:05:00'te, bilinen bir bitiş zamanı olmadan tespit etti.

Değişiklik 2: Güncelleştirme

A şirketi 18.07.2025 12:15:43 (iş zamanı) saatinde güncelleştirilir ve sistem olayı 12:20:00'da (sistem saati) tüketir. Sistem hem güncelleştirme bilinmeden önce inandıklarını hem de güncelleştirme alındıktan sonra düzeltilen iş geçmişini korur.

Giriş:

Şirket Kimliği Veri Noktası Sıralama Sistem Sıralama Operation
A XFv2 7/18/2025 12:15:43 7/18/2025 12:20:00 UPDATE

Çıktı:

Şirket Kimliği Veri Noktası __START_AT __END_AT __SYSTEM_START_AT __SYSTEM_END_AT
A XFv1 7/18/2025 10:01:00 NULL 7/18/2025 10:05:00 7/18/2025 12:20:00
A XFv1 7/18/2025 10:01:00 7/18/2025 12:15:43 7/18/2025 12:20:00 NULL
A XFv2 7/18/2025 12:15:43 NULL 7/18/2025 12:20:00 NULL

XFv1'in bilinen sonu olmayan 10:01:00'dan itibaren geçerli olduğuna inanılıyordu ve sistem bu inancı 10:05:00 ile 12:20:00 arasında tuttu. XFv1'in artık yalnızca 12:15:43'e kadar geçerli olduğu ve 12:20:00 sistem zamanından itibaren geçerli olan, bilinen bir bitişi olmayan düzeltilmiş bir geçmiş kaydının bulunduğu bilinmektedir. XFv2, bilinen sonu olmayan 12:15:43'den itibaren geçerlidir ve sistem saati 12:20:00'de öğrenilir.

Değişiklik 3: Sıra dışı güncelleştirme

A Şirketi'nin aslında 18/7/2025 12:05:00'te (iş zamanı) güncellendiğini gösteren, ancak 12:25:00'ye (sistem saati) kadar sisteme alınmayan sırası bozuk bir güncelleme gelir. Bir güncelleştirme, sistem zamanına göre daha sonra ancak daha önceki bir iş zamanı ile geldiğinde, sistem geçmişteki iş zamanını düzeltir ve hem geliş sırası bozuk güncelleştirmeden önce doğru kabul ettiği durumu hem de düzeltilmiş geçmişi korur.

Giriş:

Şirket Kimliği Veri Noktası Sıralama Sistem Sıralama Operation
A XFv3 7/18/2025 12:05:00 7/18/2025 12:25:00 UPDATE

Çıktı:

Şirket Kimliği Veri Noktası __START_AT __END_AT __SYSTEM_START_AT __SYSTEM_END_AT
A XFv1 7/18/2025 10:01:00 NULL 7/18/2025 10:05:00 7/18/2025 12:20:00
A XFv1 7/18/2025 10:01:00 7/18/2025 12:15:43 7/18/2025 12:20:00 7/18/2025 12:25:00
A XFv1 7/18/2025 10:01:00 7/18/2025 12:05:00 7/18/2025 12:25:00 NULL
A XFv3 7/18/2025 12:05:00 7/18/2025 12:15:43 7/18/2025 12:25:00 NULL
A XFv2 7/18/2025 12:15:43 NULL 7/18/2025 12:20:00 NULL

XFv1'in 10:01:00 ile 12:15:43 arasında geçerli olduğu ve bu inancın 12:25:00'e kadar sistem zamanında geçerli olduğu düşünüldü. Yeni güncelleştirme, XFv1'in iş geçerliliğinin 12:05:00'te sona erecek şekilde düzeltilmesini ve 12:25:00 sistem saatinden itibaren geçerli olan düzeltilmiş bir geçmişi sağlar. XFv3'ün artık 12:05:00 ile 12:15:43 arasında geçerli olduğu bilinmektedir; bu kabul, sistem zamanında 12:25:00'ten itibaren geçerlidir ve bilinen bir bitişi yoktur.

Değişiklik 4: Sil

Şirket A 18.07.2025 12:30:00'da silinir ve sistem olayı 12:30:00'da tüketir. Silme işlemi varlığın iş varlığının sonunu temsil ettiğinden, sistem değiştirme satırı oluşturmaz. XFv2, iki satırda yer alır ve hem şirketin varlığının ne zaman sona erdiğine hem de sistemin silme işlemini ne zaman öğrendiğine dair eksiksiz bir denetim izi korur.

Giriş:

Şirket Kimliği Veri Noktası Sıralama Sistem Sıralama Operation
A XFv2 7/18/2025 12:30:00 7/18/2025 12:30:00 DELETE

Çıktı:

Şirket Kimliği Veri Noktası __START_AT __END_AT __SYSTEM_START_AT __SYSTEM_END_AT
A XFv1 7/18/2025 10:01:00 NULL 7/18/2025 10:05:00 7/18/2025 12:20:00
A XFv1 7/18/2025 10:01:00 7/18/2025 12:15:43 7/18/2025 12:20:00 7/18/2025 12:25:00
A XFv1 7/18/2025 10:01:00 7/18/2025 12:05:00 7/18/2025 12:25:00 NULL
A XFv3 7/18/2025 12:05:00 7/18/2025 12:15:43 7/18/2025 12:25:00 NULL
A XFv2 7/18/2025 12:15:43 NULL 7/18/2025 12:20:00 7/18/2025 12:30:00
A XFv2 7/18/2025 12:15:43 7/18/2025 12:30:00 7/18/2025 12:30:00 NULL

XFv2, bilinen sonu olmayan 12:15:43'ten itibaren geçerliydi ve sistem bu inancı 12:20:00 ile 12:30:00 arasında tuttu. Silme işlemi sisteme alındıktan sonra, XFv2'nin yalnızca 12:30:00'a kadar geçerli olduğu, 12:30:00 sistem zamanından itibaren ise düzeltilmiş bir geçmişin geçerli olduğu bilinmektedir.

Bir işlem hattında CDC işleme için hangi veri nesneleri kullanılır?

Hive meta veri deposunda hedef tabloyu bildirdiğinizde iki veri yapısı oluşturulur:

  • Hedef tabloya atanan adı kullanan bir görünüm.
  • CDC işlemeyi yönetmek için işlem hattı tarafından kullanılan bir iç yedekleme tablosu. Bu tablo, hedef tablo adının önüne __apply_changes_storage_ eklenerek adlandırılır.

Örneğin, adlı dp_cdc_targetbir hedef tablo bildirirseniz, meta veri deposunda adlı dp_cdc_target bir görünüm ve adlı __apply_changes_storage_dp_cdc_target bir tablo görürsünüz. İşlenen verilere erişmek için görünümü sorgular. Yedekleme tablosunu doğrudan değiştirmeyin.

Uyarı

Bu veri yapıları yalnızca AUTO CDC işlemi için geçerlidir, AUTO CDC FROM SNAPSHOT işlemi için geçerli değildir. Bunlar Unity Kataloğu'na değil yalnızca Hive meta veri deposuna da uygulanır.

  • Last updated on