Mengubah tangkapan data dan rekam jepret

Teknisi data sering kali perlu mereplikasi data dari sumber di hulu Azure Databricks, seperti database relasional (Oracle, Postgres, SQL Server), ke Azure Databricks untuk analitik, pelaporan, dan pembelajaran mesin. Saat sistem operasional berubah, tabel analitik harus tetap disinkronkan dengan perubahan tersebut.

Beberapa tim perlu mencerminkan status database operasional mereka saat ini untuk pelaporan dan analitik. Yang lain perlu mempertahankan riwayat penuh perubahan untuk auditabilitas, persyaratan peraturan, atau analitik pelanggan.

Pemantauan perubahan data (CDC) memperlakukan database sebagai sekumpulan perubahan, bukan sebagai database statis lengkap. Diagram berikut menunjukkan bahwa ketika baris dalam tabel sumber yang berisi data karyawan diperbarui, ia menghasilkan sekumpulan baris baru dalam umpan CDC yang hanya berisi perubahan. Setiap baris umpan CDC biasanya berisi metadata tambahan, termasuk operasi seperti UPDATE dan kolom yang dapat digunakan untuk mengurutkan setiap baris secara deterministik di umpan CDC sehingga Anda dapat menangani pembaruan yang tidak berurutan. Misalnya, sequenceNum kolom dalam diagram berikut menentukan urutan baris dalam umpan CDC:

Ubah gambaran umum pengambilan data.

CDC memungkinkan Anda untuk hanya melihat perubahan pada data untuk transaksi yang lebih sederhana saat memperbarui database dalam sistem hilir. Ini juga dapat memungkinkan Anda untuk melihat riwayat database, jika itu adalah persyaratan.

Tantangannya adalah bahwa sistem sumber menyediakan data dalam format yang berbeda. Beberapa memancarkan umpan perubahan yang menangkap perubahan individual (sisipan, pembaruan, penghapusan). Yang lain hanya menyediakan rekam jepret berkala dari seluruh tabel. Setiap format memerlukan pendekatan pemrosesan yang berbeda untuk menjaga tabel hilir tetap akurat dan terbaru.

Secara historis, tim telah mengandalkan logika kustom MERGE INTO untuk menerapkan perubahan ini, baik dari umpan perubahan atau dengan membandingkan rekam jepret. Pendekatan ini kompleks dan rawan kesalahan, membutuhkan tabel penahapan, fungsi jendela, dan asumsi pengurutan yang sulit untuk dipahami dan dipertahankan saat pipelin berkembang.

Manfaat CDC

Mengubah pengambilan data memberikan beberapa manfaat dalam beban kerja Anda.

  • Data perubahan biasanya lebih kecil dari himpunan data lengkap, dan perubahan dapat diproses oleh kueri hilir sebagai pembaruan bertambah bertahap pada data.
  • Data perubahan dapat disimpan dengan cara yang memungkinkan Anda untuk membangun ulang rekaman seperti pada waktu tertentu, memberi Anda riwayat lengkap untuk audit, pelaporan titik waktu, atau analisis tren.
  • Data perubahan memungkinkan kunci pengganti tetap stabil dari waktu ke waktu.

Bagaimana perubahan diterapkan: Status saat ini atau riwayat lengkap perubahan

Dimensi yang Berubah Perlahan (SCD) menentukan bagaimana perubahan hulu diterapkan dan dimodelkan setelah sampai pada tabel analitis. Organisasi mungkin menggunakan pendekatan yang berbeda berdasarkan kebutuhan data mereka. SCD Tipe 1 memungkinkan Anda hanya menyimpan status himpunan data saat ini. SCD Tipe 2 menyimpan riwayat lengkap perubahan pada himpunan data. Bagian ini menjelaskan ini secara lebih rinci.

SCD Tipe 1: Kondisi saat ini saja

SCD Tipe 1 menimpa data lama dengan data baru setiap kali perubahan terjadi, hanya menyimpan versi terbaru dari setiap rekaman. Riwayat tidak disimpan.

Gunakan SCD Tipe 1 saat:

  • Anda hanya memerlukan status data saat ini.
  • Anda ingin tampilan materialisasi hilir disegarkan secara bertahap daripada komputasi ulang sepenuhnya.
  • Anda memerlukan kunci pengganti yang stabil untuk operasi penggabungan.

Hanya versi terbaru data yang tersedia di SCD1. Ini adalah pendekatan mudah yang dapat Anda anggap sebagai hanya menyimpan tabel akhir. Jika rekaman berubah dari Owner menjadi Manager, hanya Manager tetap dalam tabel:

Gambaran Umum Perekaman Perubahan Data SCD Tipe 1.

SCD Tipe 2: Pelacakan sejarah

SCD Tipe 2 mempertahankan catatan historis lengkap dengan membuat beberapa versi data dari waktu ke waktu, setiap kali ditandai dengan metadata. Kolom __START_AT dan __END_AT menentukan periode validitas untuk setiap versi rekaman. Rekaman aktif memiliki __END_AT = NULL. Anda dapat melihat status himpunan data seperti pada titik waktu apa pun.

Gunakan SCD Tipe 2 saat:

  • Auditabilitas atau persyaratan peraturan menuntut pelacakan historis.
  • Analitik pelanggan memerlukan pemahaman tentang bagaimana entitas berevolusi dari waktu ke waktu.
  • Logika bisnis memerlukan pelaporan titik waktu.
  • Anda perlu menganalisis tren atau membandingkan status historis.

Pemrosesan SCD Tipe 2 mempertahankan catatan historis perubahan data. Misalnya, jika rekaman saat ini memiliki bidang peran yang ditetapkan sebagai Manager, Anda juga dapat melihat bahwa peran sebelumnya ditetapkan sebagai Owner. Dalam gambar berikut, itulah yang terjadi pada rekaman untuk Chris. Anda bisa mengetahui rekaman saat ini karena memiliki null nilai untuk end_at bidang :

Gambaran Umum Change Data Capture SCD Type 2.

Apa itu umpan CDC?

Change Data Capture (CDC) adalah pola integrasi data yang menangkap perubahan yang dilakukan pada data dalam sistem sumber: menyisipkan, memperbarui, dan menghapus. Daripada memproses seluruh himpunan data, CDC menghasilkan umpan yang hanya berisi rekaman yang dimodifikasi.

Misalnya, jika Anda memiliki tabel karyawan di Oracle dengan 50 baris, dan judul pekerjaan satu karyawan berubah, umpan CDC berisi satu UPDATE catatan untuk karyawan tersebut. Ini memungkinkan Azure Databricks untuk memproses hanya rekaman yang diubah daripada membaca seluruh tabel sumber pada setiap proses.

Setiap rekaman CDC dari database sumber meliputi:

  • Jenis operasi (INSERT, UPDATE, DELETE)
  • Nilai data untuk rekaman
  • Nomor urut atau tanda waktu untuk pemesanan deterministik

Nomor urut memastikan bahwa kedatangan terlambat atau tidak berurutan diterapkan dengan benar. Database transaksi seperti SQL Server, MySQL, dan Oracle menghasilkan umpan CDC secara asli. Tabel Delta juga menghasilkan umpan CDC-nya sendiri, yang dikenal sebagai Change Data Feed (CDF), mempermudah pemrosesan perubahan dari sumber Delta.

Apa itu rekam jepret?

Rekam jepret mewakili status lengkap tabel pada titik waktu tertentu. Tidak seperti umpan CDC yang hanya mengambil perubahan, rekam jepret berisi setiap baris dalam tabel sumber.

Teams tidak selalu mengaktifkan umpan CDC pada database operasional karena berbagai alasan:

  • Biaya (CDC dapat meningkatkan beban pada database produksi)
  • Masalah performa pada database sumber
  • Sistem warisan yang tidak mendukung CDC
  • Batasan organisasi (tim yang mengelola penyerapan tidak memiliki database upstream)

Ketika umpan perubahan tidak tersedia, penyerapan berbasis rekam jepret adalah satu-satunya opsi. Rekam jepret dapat berasal dari:

  • Ekspor berkala dari database relasional (Oracle, Postgres, SQL Server)
  • Pembuangan file penyimpanan cloud dari sistem hulu
  • Tabel delta (setiap versi tabel secara efektif merupakan rekam jepret)
  • OpenSharing dari penyewa hulu

Karena rekam jepret tidak menangkap perubahan tingkat rekaman, mengidentifikasi apa yang berubah memerlukan perbandingan rekaman di seluruh rekam jepret untuk menyimpulkan sisipan, pembaruan, dan penghapusan.

Memproses umpan CDC secara otomatis

Azure Databricks menyederhanakan pemrosesan CDC melalui AUTO CDC API dalam alur Lakeflow. API ini dirancang untuk memproses perubahan dari umpan CDC pada database sumber atau tabel Delta dengan Umpan Data Perubahan diaktifkan.

Untuk contoh kode SQL dan Python, lihat contoh CDC OTOMATIS.

Gunakan AUTO CDC ketika salah satu dari ini benar:

  • Sistem sumber Anda menghasilkan Umpan Data Perubahan (CDF)
  • Anda membaca dari tabel Delta dengan Umpan Perubahan Data diaktifkan
  • Anda memiliki umpan CDC dari database relasional (melalui alat seperti Debezium atau Oracle GoldenGate)

AUTO CDC secara otomatis menangani rekaman di luar urutan dengan memproses peristiwa dalam urutan yang ditentukan oleh kolom urutan. Kolom pengurutan harus berupa representasi yang meningkat secara monoton dari urutan peristiwa yang benar, dengan satu pembaruan per kunci yang berbeda pada setiap nilai urutan. NULL nilai urutan tidak didukung. Untuk SCD Tipe 2, pipeline meneruskan nilai pengurutan ke kolom __START_AT dan __END_AT pada tabel target.

Hidrasi awal: Saat mereplikasi tabel database operasional yang ada ke Azure Databricks, Anda harus terlebih dahulu memuat semua data historis sebelum memproses perubahan yang sedang berlangsung. AUTO CDC mendukung ini melalui alur sekali, mode yang memproses semua data yang tersedia satu kali lalu berhenti. Setelah beban awal selesai, gunakan alur mode yang dipicu atau berkelanjutan untuk pemrosesan CDC yang sedang berlangsung. Ini memastikan logika yang konsisten untuk beban massal dan bertahap.

Memproses rekam jepret secara otomatis

Saat umpan CDC tidak tersedia, Azure Databricks menyediakan AUTO CDC FROM SNAPSHOT API. API ini dirancang untuk penyerapan berbasis rekam jepret; ini membandingkan rekam jepret berturut-turut, menghasilkan umpan perubahan sintetis, dan menerapkan logika SCD Tipe 1 atau Tipe 2 ke dalam tabel target. Tabel target dapat menyediakan umpan CDC (disebut umpan data perubahan (CDF) dalam tabel Delta) dari SCD Tipe 1 atau Tipe 2 untuk kueri hilir.

Untuk contoh kode Python, lihat contoh AUTO CDC FROM SNAPSHOT.

AUTO CDC FROM SNAPSHOT hanya didukung di antarmuka alur Python. Rekam jepret harus diproses dalam urutan naik berdasarkan versi; jika rekam jepret di luar urutan terdeteksi, rekam jepret tersebut diabaikan. Pemrosesan hilir, seperti tampilan materialisasi yang mengkueri output dataset AUTO CDC FROM SNAPSHOT memperoleh manfaat dari CDC, seperti kemampuan untuk bertambah secara bertahap, dan kunci pengganti yang stabil.

Note

AUTO CDC FROM SNAPSHOT bukan hanya untuk pemuatan awal. Ini dirancang untuk pemrosesan berkelanjutan ketika rekam jepret adalah satu-satunya format yang tersedia. Setiap kali rekam jepret baru tiba, API membandingkannya dengan rekam jepret sebelumnya untuk mendapatkan perubahan dan umpan data perubahan.

Gunakan AUTO CDC FROM SNAPSHOT saat:

  • CDC tidak diaktifkan pada database sumber
  • Anda hanya memiliki akses ke cuplikan berkala (cetak tabel penuh)
  • Anda menginginkan manfaat CDC untuk pemrosesan inkremental, atau memiliki riwayat perubahan penuh.

AUTO CDC FROM SNAPSHOT menangani hal berikut secara otomatis:

  1. Membandingkan rekam jepret berturut-turut untuk mengidentifikasi rekaman yang disisipkan, diperbarui, dan dihapus.
  2. Menghasilkan umpan perubahan sintetis berdasarkan perbedaan antara rekam jepret.
  3. Menerapkan logika SCD yang sama seperti AUTO CDC untuk menghitung SCD Tipe 1 atau Tipe 2.

Note

AUTO CDC FROM SNAPSHOT hanya mengetahui perubahan dari satu snapshot ke snapshot berikutnya, dan tidak mengetahui perubahan-perubahan di antaranya. Misalnya, jika Anda mendapatkan rekam jepret harian, dan pengguna mengubah alamat mereka dua kali dalam satu hari (dari A ke , kemudian dari B ke BC), umpan perubahan Anda mungkin langsung dari A ke C, karena Anda hanya menerima rekam jepret untuk waktu tersebut.

Pola pemrosesan snapshot

AUTO CDC FROM SNAPSHOT mendukung dua pola untuk menentukan versi rekam jepret.

Pemrosesan snapshot menggunakan waktu pemrosesan alur masuk

Rekam jepret dibaca pada saat eksekusi alur, dan waktu penyerapan digunakan sebagai versi rekam jepret. Cuplikan baru diintegrasikan ke dalam setiap pembaruan pipeline. Saat alur berjalan dalam mode berkelanjutan, beberapa rekam jepret diserap berdasarkan pengaturan interval pemicu untuk alur.

Gunakan pola ini ketika cuplikan datang secara teratur dan berurutan dan Anda dapat mengandalkan cap waktu pelaksanaan alur untuk pengaturan versi.

Pemrosesan rekam jepret menggunakan fungsi versi

Anda menyediakan fungsi yang menentukan versi rekam jepret mana yang akan diproses pada saat alur kerja berjalan. Fungsi mengembalikan tuple: (DataFrame, version_number). API memproses rekam jepret dalam urutan yang ditentukan oleh nomor versi. Jika rekam jepret di luar urutan terdeteksi, rekam jepret diabaikan.

Gunakan pola ini ketika:

  • Beberapa rekam jepret dapat tiba pada saat yang sama dan membutuhkan pemrosesan berurutan.
  • Cuplikan dapat tiba tidak berurutan.
  • Anda memerlukan kontrol eksplisit atas pemesanan rekam jepret.

Kemampuan CDC tambahan

Mengubah operasi pada sasaran Auto CDC

Tidak seperti tabel streaming standar, tabel Unity Catalog yang menjadi AUTO CDC target mendukung pernyataan INSERT, UPDATE, DELETE, dan MERGE bahkan saat alur sedang berjalan. Untuk detail dan batasan, lihat Menambahkan, mengubah, atau menghapus data dalam tabel streaming target.

Membaca umpan data perubahan dari target CDC Otomatis

AUTO CDC tabel streaming sasaran dapat memancarkan Umpan Data Perubahan (CDF) mereka sendiri, memungkinkan pipeline hilir untuk memanfaatkan perubahan dari AUTO CDC output. Untuk informasi lebih lanjut, lihat Membaca umpan data perubahan dari tabel target CDC OTOMATIS.

Metrik dan pemantauan

AUTO CDC secara otomatis mengambil num_upserted_rows dan num_deleted_rows metrik pada setiap eksekusi alur. Untuk detailnya, lihat Topik CDC OTOMATIS Tingkat Lanjut.

Melacak subset kolom untuk SCD Tipe 2

Secara default, SCD Tipe 2 membuat versi baru setiap kali nilai kolom berubah. AUTO CDC memungkinkan Anda menentukan kolom mana yang akan dilacak untuk riwayat, sehingga perubahan pada kolom yang tidak terlacak memperbarui versi saat ini di tempat daripada membuat catatan historis baru. Ini mengurangi biaya penyimpanan dan kompleksitas kueri sambil mempertahankan riwayat untuk atribut penting. Misalnya, lihat Melacak subset kolom dengan SCD Tipe 2.

Recommendations

Gunakan change data capture (CDC) saat Anda hanya ingin bekerja dengan perubahan data Anda, misalnya, untuk memungkinkan tampilan materialisasi di hilir diperbarui secara bertahap. Gunakan juga CDC saat Anda ingin mempertahankan riwayat perubahan pada data Anda, misalnya, untuk mengetahui siapa yang memiliki peran apa pada titik waktu tertentu.

Gunakan API CDC OTOMATIS saat Anda perlu mereplikasi data hulu ke Azure Databricks dan menjaganya tetap sinkron dengan perubahan sumber. API yang tepat bergantung pada bagaimana sistem sumber Anda mengekspos perubahan:

  • Menggunakan AUTO CDC saat sumber Anda memancarkan umpan perubahan, misalnya, database relasional dengan CDC diaktifkan (melalui alat seperti Debezium atau Oracle GoldenGate), tabel Delta dengan Umpan Data Perubahan diaktifkan, atau sumber apa pun yang menghasilkan aliran sisipan, pembaruan, dan penghapusan dengan kolom urutan.
  • Menggunakan AUTO CDC FROM SNAPSHOT ketika sumber Anda tidak mendukung CDC dan hanya menyediakan cadangan tabel penuh berkala. API ini menyimpulkan perubahan dengan membandingkan rekam jepret berturut-turut dan menghasilkan umpan perubahan sintetis, sehingga Anda mendapatkan manfaat pemrosesan SCD yang sama bahkan tanpa umpan CDC asli.

Dalam kedua kasus, pilih SCD Tipe 1 jika Anda hanya memerlukan status saat ini dari setiap rekaman, atau SCD Tipe 2 jika Anda perlu mempertahankan riwayat perubahan penuh untuk audit, pelaporan titik waktu, atau analisis tren.

Sumber daya tambahan

  • Last updated on