Integritas data dengan Delta Lake

5 menit

Integritas data di Delta Lake adalah aspek penting yang memastikan akurasi, konsistensi, dan keandalan data sepanjang siklus hidupnya. Delta Lake menyediakan beberapa mekanisme untuk menjunjung tinggi integritas data, terutama di lingkungan dengan alur data yang kompleks, dan beberapa pengguna bersamaan. Kami telah membahas transaksi ACID, penegakan skema, evolusi, perjalanan waktu, dll.

Menerapkan Batasan

Batasan Kunci Primer (PK) dan Kunci Asing (FK) dalam Databricks menentukan struktur relasional dan keunikan yang dimaksudkan dan hubungan referensial antar tabel. Batasan kunci utama menunjukkan bahwa kolom (atau sekumpulan kolom) harus secara unik mengidentifikasi setiap baris dalam tabel (dan biasanya tidak ada kolom tersebut yang null). Batasan kunci asing berarti bahwa kolom atau sekumpulan kolom dalam satu tabel harus cocok dengan nilai dalam kunci utama atau kandidat dalam tabel lain, menetapkan integritas referensial. Namun, penting untuk dicatat bahwa batasan ini bersifat informasi, tidak diberlakukan oleh mesin Databricks itu sendiri. Mereka berfungsi untuk mendokumen hubungan yang dimaksudkan dan memungkinkan pengoptimalan (terutama jika Anda menandainya dengan opsi RELY), tetapi mereka tidak menjamin bahwa data benar-benar memenuhinya kecuali diberlakukan upstream atau divalidasi secara manual.

Mari kita jelajahi contoh di SQL tempat kita membuat tabel pelanggan (PK komposit) dan tabel pesanan (PK tunggal + FK komposit):

-- Dimension: customers (composite primary key)
CREATE TABLE customers (
  customer_id INT    NOT NULL,
  region_id   INT    NOT NULL,
  name        STRING NOT NULL,
  email       STRING,
  CONSTRAINT customers_pk PRIMARY KEY (customer_id, region_id)
);

-- Fact: orders (single-column primary key, plus a composite FK to customers)
CREATE TABLE orders (
  order_id    INT      NOT NULL PRIMARY KEY,
  customer_id INT,
  region_id   INT,
  order_date  DATE     NOT NULL,
  amount      DECIMAL(12,2) NOT NULL,
  CONSTRAINT orders_customer_fk
    FOREIGN KEY (customer_id, region_id) REFERENCES customers
);

Nota

Batasan kunci primer dan kunci asing tersedia di Databricks Runtime 11.3 LTS dan versi di atasnya, dan sepenuhnya tersedia secara umum dalam Databricks Runtime 15.2 dan versi di atasnya.
Batasan kunci primer dan kunci asing memerlukan Katalog Unity dan Delta Lake.

Delta juga mendukung keterbatasan, seperti NOT NULL dan CHECK kolom yang dihasilkan. Batasan ini divalidasi pada waktu tulis untuk memastikan bahwa hanya data yang valid yang memasuki tabel. Contoh berikut membuat tabel karyawan dengan kunci utama, NOT NULL, dan CHECK batasan untuk memberlakukan usia dan tanggal yang valid, lalu menambahkan batasan CHECK lain employee_id yang memastikan nilai tetap berada dalam rentang 1–99.999.999. Rekaman yang melanggar aturan ditolak, menjaga tabel tetap konsisten dengan aturan bisnis.

CREATE TABLE employees (
    employee_id INT PRIMARY KEY,
    first_name  STRING,
    last_name   STRING NOT NULL,
    age         INT,
    start_date  DATE,
    end_date    DATE,
    CONSTRAINT age_non_negative CHECK (age >= 0),
    CONSTRAINT valid_dates      CHECK (end_date > start_date)
);

ALTER TABLE employees ADD CONSTRAINT validIds CHECK (employee_id >= 1 and employee_id <= 99999999);

Menangani Konkurensi

Konkurensi adalah tantangan integritas lain, terutama ketika beberapa pengguna atau pekerjaan menulis ke tabel yang sama. Delta menangani ini dengan kontrol konkurensi optimis (OCC). Setiap transaksi membaca rekam jepret saat ini dan mengusulkan perubahan; sebelum melakukan, Delta memeriksa apakah penerapan lain telah memodifikasi file data yang sama. Jika konflik terdeteksi (misalnya, dua pekerjaan yang memperbarui baris yang sama), satu transaksi gagal dengan kesalahan konflik alih-alih secara diam-diam menimpa perubahan yang lain. Ini memastikan konsistensi tanpa mengunci seluruh tabel.

Mari kita lihat contohnya. Kami memiliki tabel karyawan:

CREATE TABLE employees (
  id INT,
  name STRING,
  age INT
);

INSERT INTO employees VALUES (1, 'Alice', 30), (2, 'Bob', 25);

Bayangkan Transaksi A dan Transaksi B dimulai pada saat yang sama, masing-masing membaca rekam jepret tabel yang sama (versi 1).

Transaksi A (sesi 1):

-- Session 1: Try to update Bob
UPDATE employees
SET age = 26
WHERE id = 2;

Transaksi B (Sesi 2):

-- Session 2: Try to update Bob differently
UPDATE employees
SET age = 27
WHERE id = 2;

Sesi 1 berhasil diselesaikan dan dilakukan, menghasilkan versi 2 dari tabel tempat usia Bob diperbarui menjadi 26. Ketika Sesi 2 mencoba melakukan commit, Delta membandingkan file yang direncanakan untuk diubah dengan status tabel saat ini. Ditemukan bahwa file-file tersebut telah diubah pada versi 2, sehingga commit diblokir dan sesi 2 gagal dengan kesalahan konflik.

Tentukan Ekspektasi

Terakhir, Delta menyediakan alat kualitas data seperti ekspektasi Lakeflow Declarative Pipelines, yang memungkinkan Anda menentukan aturan kualitas data secara deklaratif dan melacak pelanggaran.

Mereka memungkinkan Anda memastikan kondisi boolean pada rekaman ketika data mengalir melalui alur ETL/streaming (pandangan materialisasi atau tabel streaming), untuk memvalidasi bahwa data memenuhi batasan yang ditentukan. Misalnya, Anda mungkin memberlakukan bahwa kolom "usia" adalah antara 0 dan 120, atau bahwa bidang tertentu tidak null. Kondisi dinyatakan dalam SQL (atau melalui dekorator Python) dan dijalankan per rekaman. Ketika rekaman melanggar harapan, apa yang terjadi selanjutnya tergantung pada konfigurasi ekspektasi ("tindakan terhadap pelanggaran") — Anda dapat memperingatkan/mencatat, menghilangkan rekaman, atau gagal pembaruan.

Ada tiga bagian utama yang diharapkan:

Nama ekspektasi – label yang mengidentifikasi aturan (harus unik per himpunan data). Digunakan untuk pemantauan, metrik, dan pemahaman aturan mana yang gagal.
Batasan / Kondisi – kondisi boolean SQL yang harus dipenuhi setiap rekaman.
Tindakan pelanggaran – apa yang harus dilakukan ketika catatan melanggar batasan. Opsinya adalah:
- warn (default): simpan rekaman yang tidak valid, tetapi log metrik.
- drop: hilangkan rekaman yang tidak valid sebelum menulisnya ke tabel target, mencatat berapa banyak yang dihilangkan.
- gagal: batalkan pembaruan/alur jika ada catatan yang melanggar harapan.

Kami akan membahas ini secara lebih rinci dalam modul berikutnya.

Saran dan Komentar

Apakah halaman ini membantu?