Topik Lanjutan AUTO CDC

Di luar dasar AUTO CDC dan AUTO CDC FROM SNAPSHOT API, Anda dapat menjalankan DML pada tabel target, membaca umpan data perubahan dari target CDC, memantau metrik pemrosesan, menerapkan pembaruan parsial, dan melacak perubahan dengan penyimpanan bitemporal. Untuk pengenalan AUTO CDC API, lihat API CDC OTOMATIS: Menyederhanakan perubahan pengambilan data dengan alur.

Menambahkan, mengubah, atau menghapus data dalam tabel streaming target

Jika pipeline Anda menerbitkan tabel ke Unity Catalog, Anda dapat menggunakan pernyataan bahasa manipulasi data (DML), termasuk pernyataan insert, update, delete, dan merge, untuk memodifikasi tabel streaming target yang dibuat oleh pernyataan AUTO CDC ... INTO.

Nota

• Pernyataan DML yang mengubah skema tabel tabel streaming tidak didukung. Pastikan bahwa pernyataan DML Anda tidak mencoba mengembangkan skema tabel.
• Pernyataan DML yang memperbarui tabel streaming hanya dapat dijalankan di kluster Unity Catalog bersama atau gudang SQL menggunakan Databricks Runtime 13.3 LTS ke atas.
• Karena streaming memerlukan sumber data khusus tambahan, jika pemrosesan Anda memerlukan streaming dari tabel streaming sumber dengan perubahan (misalnya, menurut pernyataan DML), atur bendera skipChangeCommits saat membaca tabel streaming sumber. Saat skipChangeCommits diatur, transaksi yang menghapus atau mengubah rekaman pada tabel sumber diabaikan. Jika pemrosesan Anda tidak memerlukan tabel streaming, Anda dapat menggunakan pandangan materialisasi (yang tidak memiliki batasan hanya-menambahkan) sebagai tabel target.

Karena alur menggunakan kolom tertentu SEQUENCE BY dan menyebarkan nilai urutan yang sesuai ke __START_AT kolom dan __END_AT tabel target (untuk SCD Tipe 2), Anda harus memastikan bahwa pernyataan DML menggunakan nilai yang valid untuk kolom ini untuk mempertahankan urutan rekaman yang tepat. Lihat Cara kerja CDC OTOMATIS.

Untuk informasi selengkapnya tentang menggunakan pernyataan DML dengan tabel streaming, lihat Menambahkan, mengubah, atau menghapus data dalam tabel streaming.

Contoh berikut menyisipkan rekaman aktif dengan urutan awal 5:

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

Petunjuk / Saran

Jika Anda perlu mengganti nama __START_AT kolom dan __END_AT dalam tabel target SCD Tipe 2 Anda (misalnya, untuk mencocokkan persyaratan skema hilir), buat tampilan di atas tabel target:

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

Membaca umpan data perubahan dari tabel target CDC OTOMATIS

Di Databricks Runtime 15.2 ke atas, Anda dapat membaca umpan data perubahan dari tabel streaming yang merupakan target AUTO CDC atau AUTO CDC FROM SNAPSHOT kueri dengan cara yang sama seperti Anda membaca umpan data perubahan dari tabel Delta lainnya. Berikut ini diperlukan untuk membaca umpan data perubahan dari tabel streaming target:

• Tabel streaming target harus diterbitkan ke Katalog Unity. Lihat Menggunakan Unity Catalog dengan alur.
• Untuk membaca umpan data perubahan dari tabel streaming target, Anda harus menggunakan Databricks Runtime 15.2 atau lebih tinggi. Untuk membaca umpan data perubahan dalam alur yang berbeda, alur harus dikonfigurasi untuk menggunakan Databricks Runtime 15.2 atau lebih tinggi.

Anda membaca umpan data perubahan dari tabel streaming target yang dibuat dalam alur Lakeflow dengan cara yang sama seperti membaca umpan data perubahan dari tabel Delta lainnya. Untuk mempelajari selengkapnya tentang menggunakan fungsionalitas umpan data perubahan Delta, termasuk contoh di Python dan SQL, lihat Menggunakan umpan data perubahan pada Azure Databricks.

Nota

Rekaman umpan data perubahan mencakup metadata yang mengidentifikasi jenis peristiwa perubahan. Saat rekaman diperbarui dalam tabel, metadata untuk rekaman perubahan terkait biasanya menyertakan _change_type nilai yang dikonfigurasi menjadi update_preimage dan peristiwa update_postimage.

Namun, _change_type nilainya berbeda jika pembaruan dilakukan pada tabel streaming target yang menyertakan perubahan nilai kunci utama. Saat perubahan menyertakan pembaruan pada kunci primer, _change_type bidang metadata diatur ke insert dan delete peristiwa. Perubahan pada kunci primer dapat terjadi ketika pembaruan manual dilakukan pada salah satu kolom kunci dengan perintah UPDATE atau MERGE, untuk tabel SCD tipe 2, ketika kolom __start_at berubah untuk mencerminkan nilai urutan mulai sebelumnya.

Kueri AUTO CDC menentukan nilai kunci utama, yang berbeda untuk pemrosesan SCD tipe 1 dan SCD tipe 2:

Jenis SCD	Kunci utama
SCD jenis 1, dan antarmuka alur Python	Kunci primer adalah nilai keys parameter dalam create_auto_cdc_flow() fungsi . Untuk antarmuka SQL, kunci primer adalah kolom yang ditentukan oleh KEYS klausa dalam AUTO CDC ... INTO pernyataan.
SCD tipe 2	Kunci utama adalah parameter keys atau klausul KEYS ditambah dengan nilai pengembalian dari operasi coalesce(__START_AT, __END_AT), di mana __START_AT dan __END_AT adalah kolom yang sesuai dari tabel streaming target. Ini menggunakan __START_AT jika tersedia, dan __END_AT ketika __START_AT bernilai null (misalnya, catatan awal).

Membaca umpan data perubahan dari tampilan materialized

Important

Fitur ini ada di Beta.

Anda dapat membaca umpan data perubahan dari tampilan terwujud yang dibuat di sebuah pipeline Lakeflow atau di Databricks SQL. Gunakan ini untuk mereplikasi perubahan tampilan yang termaterialisasi ke tujuan di luar Azure Databricks, atau untuk menyimpan riwayat perubahan tampilan yang dimaterialisasi untuk audit dan pelaporan.

Materialized view menggunakan feed data perubahan otomatis, jadi Anda tidak mengaktifkan feed data perubahan itu sendiri. Sebagai gantinya, Anda mengaktifkan umpan data perubahan pada setiap tampilan terwujud yang memerlukannya dengan memenuhi persyaratan berikut ini. Lihat umpan data perubahan otomatis.

• Untuk membaca feed data perubahan, Anda harus menggunakan Databricks Runtime 18 LTS atau lebih tinggi, pada komputasi klasik, komputasi serverless, atau Databricks SQL.

• Materialized view tersebut, pipeline yang membuatnya, atau pipeline yang membacanya harus menggunakan saluran PREVIEW.

• Tampilan materialisasi harus mengaktifkan pelacakan baris. Materialized view di lingkungan komputasi serverless mengaktifkan pelacakan baris secara default. Lihat Pelacakan baris di Azure Databricks. Untuk memeriksa apakah pelacakan baris diaktifkan pada tampilan terwujud, jalankan:

  SHOW TBLPROPERTIES my_mv ('delta.enableRowTracking');
  

• Untuk membaca umpan data perubahan dari tampilan terwujud, aktifkan flag metadata eksternal pada pipeline atau tampilan terwujud. Untuk instruksi, lihat Cara mengaktifkan akses untuk dataset.

Anda membaca umpan data perubahan dari materialized view dengan cara yang sama seperti saat membacanya dari tabel Delta lainnya, menggunakan fungsi table_changes(), pembacaan streaming, atau opsi readChangeFeed. Untuk sintaks dan contoh dalam SQL dan Python, lihat Gunakan perubahan data feed di Azure Databricks.

Anda dapat membaca umpan data perubahan tampilan terwujud di dalam tampilan terwujud Databricks SQL atau tabel streaming:

CREATE OR REFRESH STREAMING TABLE sales
  AS SELECT * FROM STREAM my_mv WITH (readChangeFeed=true)

Limitations

Selain batasan feed data perubahan otomatis, hal berikut berlaku saat Anda membaca feed data perubahan dari tampilan terwujud:

• Feed data perubahan mencakup baris yang tidak berubah ketika tampilan terwujud ditulis ulang secara penuh, dan tidak mengonsolidasikan beberapa pembaruan pada baris yang sama tersebut menjadi satu peristiwa. Untuk memfilter data ini, agregasikan umpan data perubahan dengan mengelompokkan berdasarkan semua kolom untuk menemukan entri penyisipan dan penghapusan yang memiliki nilai baris yang sama.
• Hanya Azure Databricks yang dapat mengkueri umpan data perubahan untuk tampilan terwujud. Klien eksternal Delta Lake dan Iceberg tidak bisa.
• Di dalam pipeline Lakeflow, Anda hanya dapat membaca feed data perubahan tampilan yang termaterialisasi dari pipeline yang berbeda, dan pipeline tersebut harus menggunakan channel tersebut PREVIEW . Membaca change data feed dari tampilan terwujud dalam pipeline yang sama dengan yang membuatnya tidak didukung.
• Anda tidak dapat membuat indeks pencarian vektor dari tampilan materialisasi.

Mendapatkan data tentang rekaman yang diproses oleh kueri CDC dalam alur

Nota

Metrik berikut hanya diambil oleh AUTO CDC kueri dan bukan oleh AUTO CDC FROM SNAPSHOT kueri.

Metrik berikut diambil oleh AUTO CDC kueri:

• num_upserted_rows: Jumlah baris output yang di-upsert ke dalam himpunan data selama pembaruan.
• num_deleted_rows: Jumlah baris output yang ada yang dihapus dari himpunan data selama pembaruan.

Metrik num_output_rows, keluaran untuk alur non-CDC, tidak diambil untuk kueri AUTO CDC.

Menerapkan pembaruan parsial

Ketika sumber hanya mengirim kolom yang berubah, AUTO CDC harus membedakan antara kolom yang tidak ada dalam catatan perubahan, yang seharusnya membiarkan nilai target tetap, dan kolom yang secara eksplisit disetel ke null, yang harus menimpa nilai target dengan null. Secara default, IGNORE NULL UPDATES memperlakukan setiap null sebagai penanda "jangan perbarui", sehingga tidak dapat menerapkan eksplisit null. Untuk mengatasi ambiguitas ini, pilih salah satu dari tiga metode berikut:

Method	Kapan digunakan	Behavior
IGNORE NULL UPDATES ON columnList	Sejumlah kecil kolom tetap harus mengabaikan nilai null, sementara semua kolom lainnya menerapkan nilai null secara eksplisit.	Kolom yang tercantum menyimpan nilai target yang ada saat nilai masuk adalah null. Semua kolom lainnya menerapkan nilai eksplisit null .
IGNORE NULL UPDATES ON * EXCEPT (exceptColumnList)	Sebagian besar kolom harus mengabaikan null nilai, dan hanya beberapa yang harus menerapkan nilai eksplisit null .	Kolom yang tercantum menerapkan nilai eksplisit null . Semua kolom lain menyimpan nilai target yang ada saat nilai masuk adalah null.
COLUMNS TO UPDATE	Setiap rekaman perubahan memperbarui kumpulan kolom yang berbeda, atau kumpulan kolom yang dapat diperbarui berubah dari waktu ke waktu.	Kolom sumber memberi nama kolom yang akan diperbarui untuk setiap rekaman perubahan. Kolom yang tercantum ditulis dari sumbernya, termasuk nilai eksplisit null . Kolom yang tidak tercantum tetap menggunakan nilai target yang ada.

COLUMNS TO UPDATE tidak dapat dikombinasikan dengan IGNORE NULL UPDATES, dan tidak didukung untuk tabel bitemporal.

Sebagai aturan praktis, pilih COLUMNS TO UPDATE kapan produsen tahu kolom mana yang berubah di setiap rekaman dan dapat membawa informasi tersebut di kolom sumber, seperti ketika beberapa produsen menulis ke sumber yang sama atau kumpulan kolom yang dapat diperbarui tumbuh dari waktu ke waktu. Pilih IGNORE NULL UPDATES ON kapan pemilik alur mengetahui kumpulan tetap kolom yang dapat diperbarui terlebih dahulu dan lebih suka mengontrolnya dalam kode alur.

Contoh berikut menggunakan kolom sumber bernama columnsToUpdate untuk mengontrol kolom mana yang setiap mengubah pembaruan rekaman, termasuk kolom yang diatur secara eksplisit ke null:

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;

Untuk referensi lengkap parameter, lihat AUTO CDC INTO (pipeline) dan create_auto_cdc_flow.

CDC otomatis bitemporal

Important

Bitemporal AUTO CDC berada di Beta.

SCD Tipe 1 dan Tipe 2 adalah unitemporal: mereka melacak perubahan di satu dimensi waktu. Bitemporal memperluas riwayat SCD Tipe 2 untuk melacak perubahan di dua dimensi waktu dan membedakan antara dua perspektif:

• Waktu bisnis: ketika peristiwa benar-benar terjadi.
• Waktu sistem: ketika sistem merekam atau menyerap peristiwa.

Seperti SCD Tipe 2, bitemporal mempertahankan sejarah lengkap catatan. Ini menambahkan garis waktu kedua sehingga Anda dapat membangun kembali apa yang ditampilkan data dan apa yang diyakini sistem kapan saja di masa lalu.

Misalnya, hedge fund menyerap data saham dari sistem sumber. Harga saham Acme Corp berubah pada 1 Januari, tetapi dana tidak menyerap pembaruan itu hingga 5 Januari. Bitemporal AUTO CDC memungkinkan dana menjawab dua pertanyaan yang berbeda: berapa harga saham aktual Acme Corp pada 1 Januari (waktu bisnis), dan harga apa yang diyakini sistem ketika dana membuat keputusan perdagangan pada 3 Januari (waktu sistem). Kemampuan untuk membedakan antara garis waktu ini berguna untuk audit, pelaporan peraturan, dan pengambilan keputusan keuangan.

Untuk mengaktifkan pemrosesan bitemporal, atur STORED AS BITEMPORAL (SQL) atau stored_as_scd_type="bitemporal" (Python), gunakan SEQUENCE BY untuk kolom waktu bisnis, dan gunakan SYSTEM SEQUENCE BY untuk kolom waktu sistem. Tabel target menambahkan kolom __SYSTEM_START_AT dan __SYSTEM_END_AT di samping kolom __START_AT dan __END_AT SCD Tipe 2. Untuk detail sintaks, lihat AUTO CDC INTO (pipelines) atau create_auto_cdc_flow.

Contoh CDC bitemporal otomatis

Contoh berikut membuat tabel target bitemporal dari sekumpulan kecil kejadian CDC sintetis. Kolom bt memiliki waktu bisnis dan st kolom memiliki waktu sistem.

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;

Urutan perubahan berikut menunjukkan bagaimana tabel bitemporal merekam sisipan, pembaruan, pembaruan yang tidak berurutan, dan penghapusan untuk satu perusahaan. Kolom pengurutan menghasilkan kolom __START_AT dan __END_AT (waktu bisnis), dan kolom pengurutan sistem menghasilkan kolom __SYSTEM_START_AT dan __SYSTEM_END_AT (waktu sistem):

kolom	Deskripsi
__START_AT	Waktu bisnis di mana baris ini menjadi valid.
__END_AT	Waktu bisnis di mana validitas baris ini berakhir. null jika valid tanpa batas waktu.
__SYSTEM_START_AT	Waktu sistem saat data pada baris ini dan interval waktu bisnisnya diketahui valid.
__SYSTEM_END_AT	Waktu sistem di mana data baris ini dan interval waktu bisnis diketahui tidak valid. null jika diketahui benar tanpa batas waktu.

Sistem menangani peristiwa yang tiba dalam urutan apa pun di kedua garis waktu. Ketika suatu kejadian tiba dengan waktu bisnis atau waktu sistem yang lebih awal daripada kejadian yang sudah diproses, sistem mengoreksi riwayat yang terdampak alih-alih hanya menambahkan ke bagian akhir.

Ubah 1: Sisipkan

Perusahaan A ditambahkan pada 18/7/2025 10:01:00 (waktu bisnis) tetapi tidak diserap hingga 10:05:00 (waktu sistem).

Masukan:

CompanyId	Titik Data	Pengurutan	Pengurutan Sistem	Pengoperasian
A	XFv1	7/18/2025 10:01:00	7/18/2025 10:05:00	INSERT

Output:

CompanyId	Titik Data	__START_AT	__END_AT	__SYSTEM_START_AT	__SYSTEM_END_AT
A	XFv1	7/18/2025 10:01:00	NOL	7/18/2025 10:05:00	NOL

XFv1 berlaku mulai pukul 10:01:00 tanpa akhir yang diketahui. Sistem mempelajari fakta ini pada waktu sistem 10:05:00, tanpa akhir yang diketahui.

Perubahan 2: Pembaruan

Perusahaan A diperbarui pada 18/7/2025 12:15:43 (waktu bisnis), dan sistem memproses peristiwa pada pukul 12:20:00 (waktu sistem). Sistem mempertahankan apa yang diyakini sebelum pembaruan diketahui dan riwayat bisnis yang dikoreksi setelah pembaruan diserap.

Masukan:

CompanyId	Titik Data	Pengurutan	Pengurutan Sistem	Pengoperasian
A	XFv2	7/18/2025 12:15:43	7/18/2025 12:20:00	UPDATE

Output:

CompanyId	Titik Data	__START_AT	__END_AT	__SYSTEM_START_AT	__SYSTEM_END_AT
A	XFv1	7/18/2025 10:01:00	NOL	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	NOL
A	XFv2	7/18/2025 12:15:43	NOL	7/18/2025 12:20:00	NOL

XFv1 diyakini berlaku dari 10:01:00 tanpa akhir yang diketahui, dan sistem memegang keyakinan itu dari 10:05:00 hingga 12:20:00. XFv1 kini diketahui hanya valid hingga pukul 12:15:43, dengan riwayat yang dikoreksi berlaku mulai dari waktu sistem 12:20:00 tanpa waktu berakhir yang diketahui. XFv2 berlaku mulai pukul 12:15:43 tanpa akhir yang diketahui, dan dipelajari pada waktu sistem 12:20:00.

Perubahan 3: Pembaruan tidak berurutan

Sebuah pembaruan yang tidak berurutan diterima, yang menunjukkan bahwa Perusahaan A ternyata telah diperbarui pada 18/7/2025 12:05:00 (waktu bisnis), tetapi baru diproses ke dalam sistem pada 12:25:00 (waktu sistem). Ketika sebuah pembaruan diterima pada waktu sistem yang lebih lambat tetapi memiliki waktu bisnis yang lebih awal, sistem memperbaiki riwayat waktu bisnis serta menyimpan baik keadaan yang sebelumnya dianggap benar sebelum pembaruan yang datang di luar urutan maupun riwayat yang telah dikoreksi.

Masukan:

CompanyId	Titik Data	Pengurutan	Pengurutan Sistem	Pengoperasian
A	XFv3	7/18/2025 12:05:00	7/18/2025 12:25:00	UPDATE

Output:

CompanyId	Titik Data	__START_AT	__END_AT	__SYSTEM_START_AT	__SYSTEM_END_AT
A	XFv1	7/18/2025 10:01:00	NOL	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	NOL
A	XFv3	7/18/2025 12:05:00	7/18/2025 12:15:43	7/18/2025 12:25:00	NOL
A	XFv2	7/18/2025 12:15:43	NOL	7/18/2025 12:20:00	NOL

XFv1 diyakini berlaku dari 10:01:00 hingga 12:15:43, dan keyakinan itu sekarang berlaku dalam waktu sistem hingga 12:25:00. Pembaruan baru ini memperbaiki validitas bisnis XFv1 sehingga berakhir pada pukul 12:05:00, dengan riwayat yang telah dikoreksi berlaku mulai waktu sistem 12:25:00. XFv3 sekarang diketahui valid dari pukul 12:05:00 hingga 12:15:43, dan fakta ini valid dalam waktu sistem mulai pukul 12:25:00 tanpa waktu akhir yang diketahui.

Ubah 4: Hapus

Perusahaan A dihapus pada 18/7/2025 12:30:00, dan sistem memproses kejadian tersebut pada pukul 12:30:00. Karena operasi penghapusan mewakili akhir keberadaan bisnis entitas, sistem tidak membuat baris pengganti. XFv2 ditampilkan dalam dua baris, dengan mempertahankan jejak audit lengkap tentang kapan perusahaan tidak lagi ada dan kapan sistem mengetahui penghapusan tersebut.

Masukan:

CompanyId	Titik Data	Pengurutan	Pengurutan Sistem	Pengoperasian
A	XFv2	7/18/2025 12:30:00	7/18/2025 12:30:00	DELETE

Output:

CompanyId	Titik Data	__START_AT	__END_AT	__SYSTEM_START_AT	__SYSTEM_END_AT
A	XFv1	7/18/2025 10:01:00	NOL	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	NOL
A	XFv3	7/18/2025 12:05:00	7/18/2025 12:15:43	7/18/2025 12:25:00	NOL
A	XFv2	7/18/2025 12:15:43	NOL	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	NOL

XFv2 berlaku dari 12:15:43 tanpa akhir yang diketahui, dan sistem memegang keyakinan itu dari 12:20:00 hingga 12:30:00. Setelah penghapusan diproses, XFv2 diketahui hanya valid hingga pukul 12:30:00, dan riwayat yang telah dikoreksi berlaku mulai waktu sistem 12:30:00.

Objek data apa yang digunakan untuk pemrosesan CDC dalam pipeline?

Saat Anda mendeklarasikan tabel target di metastore Apache Hive, dua struktur data dibuat:

• Tampilan yang menggunakan nama yang diberikan ke tabel target.
• Tabel dukungan internal yang digunakan oleh pipeline untuk mengelola pemrosesan CDC. Tabel ini dinamai dengan menambahkan __apply_changes_storage_ di awal sebelum nama tabel target.

Misalnya, jika Anda mendeklarasikan tabel target bernama dp_cdc_target, Anda akan melihat tampilan bernama dp_cdc_target dan tabel bernama __apply_changes_storage_dp_cdc_target di metastore. Kueri tampilan untuk mengakses data yang diproses. Jangan ubah tabel dasar secara langsung.

Nota

Struktur data ini hanya berlaku untuk AUTO CDC pemrosesan, bukan AUTO CDC FROM SNAPSHOT pemrosesan. Mereka juga hanya berlaku pada metastore Hive, bukan Katalog Unity.