Wawancara Rekayasa Data: Bagaimana Anda Mengevaluasi dan Bermigrasi ke Delta Lake Liquid Clustering?

Perintah dan skenario

Anda mengelola tabel fakta pesanan Delta Lake yang dipartisi berdasarkan tenant_id dan order_date serta dipelihara dengan Z-Ordering. Seiring bertambahnya jumlah penyewa (tenant), kueri untuk penyewa kecil masih memindai banyak berkas, sehingga tim mengusulkan Liquid Clustering. Jelaskan bagaimana Anda akan mengevaluasi, memigrasikan, memvalidasi, dan mengembalikan (rollback) perubahan tersebut, termasuk metrik yang akan Anda pantau.

Apa yang sedang diuji oleh pewawancara

Apakah Anda mendiagnosis masalah tata letak data dari predikat nyata alih-alih memperlakukan suatu fitur sebagai solusi ajaib.
Apakah Anda memahami batasan kompatibilitas antara partisi, Z-Ordering, dan Liquid Clustering.
Apakah Anda dapat merancang migrasi bertahap, pemeliharaan inkremental, penulisan ulang penuh, dan perlindungan rollback.
Apakah Anda dapat membuktikan nilai manfaat dengan jumlah bita yang dipindai, jumlah berkas, latensi p95, dan biaya.

Pertanyaan klarifikasi untuk diajukan terlebih dahulu

Apakah kueri utama secara konsisten memfilter tenant_id, rentang waktu, atau customer_id, dan seberapa selektif predikat-predikat tersebut?
Versi Delta Lake, runtime Spark/Databricks, dan klien pembaca/penulis mana yang sedang digunakan, dan apakah versi tersebut mendukung Liquid Clustering?
Bagaimana ritme pemeliharaan partisi dan Z-Ordering saat ini, ukuran berkas, bita yang dipindai, dan latensi p95 selama dua minggu terakhir?
Apakah platform dapat menyerap komputasi latar belakang OPTIMIZE, dan apakah ada jendela lalu lintas rendah beserta salinan rollback?

Jawaban 30 detik

Saya akan mulai dengan log kueri untuk mengonfirmasi filter yang paling sering digunakan dan selektif, lalu menjalankan perbandingan dua minggu pada tabel bayangan (shadow table). Liquid Clustering dapat mengubah tata letak yang digunakan oleh penulisan dan pengoptimalan di masa mendatang tanpa menulis ulang semua data yang ada, tetapi fitur ini merupakan alternatif dari partisi tradisional dan Z-Ordering, jadi saya akan memverifikasi versi, perubahan protokol, dan klien hilir terlebih dahulu. Setelah migrasi, saya akan menjalankan OPTIMIZE inkremental, dan hanya menggunakan OPTIMIZE FULL jika data historis masih mendominasi pemindaian. Saya akan membandingkan kueri yang setara berdasarkan bita yang dipindai, jumlah berkas, p95, tingkat kegagalan, dan biaya. Saya akan memperluas implementasi hanya setelah penulisan, konkurensi, dan rollback juga berhasil diuji.

Pembahasan mendalam

1. Bangun profil beban kerja terlebih dahulu

Agregasikan kueri dua minggu terakhir berdasarkan templat. Catat kombinasi predikat, rentang waktu, berkas yang dipindai, bita yang dipindai, baris yang dikembalikan, latensi p50/p95, dan biaya eksekusi. Jika kueri sering menyertakan tenant_id tetapi ukuran penyewa sangat bervariasi, pemartisian hanya berdasarkan tanggal mungkin masih menyentuh banyak berkas untuk penyewa kecil. Jika predikat sering bergeser, pilihan pengelompokan tetap bisa menjadi tidak stabil; pertahankan tata letak saat ini sambil mengumpulkan lebih banyak bukti.

2. Pilih kolom pengelompokan dan jaga agar jumlahnya tetap sedikit

Prioritaskan kolom filter yang sering digunakan dan selektif yang dapat memperoleh manfaat dari pelewatan data (data skipping). Pertahankan kolom berfrekuensi rendah, atau kolom ber-kardinalitas tinggi yang jarang digunakan dalam predikat, sebagai kandidat daripada langsung dipilih untuk produksi. Liquid Clustering mendukung maksimal empat kolom pengelompokan; menambahkan lebih banyak kolom tidak secara otomatis membuat kueri lebih cepat dan justru meningkatkan biaya pemeliharaan. Uji ulang dua atau tiga kombinasi kandidat secara offline alih-alih mengoptimalkan hanya untuk satu kueri "terbaik".

3. Tentukan batas migrasi dan pemeriksaan kompatibilitas

Dokumentasi resmi mengaitkan Liquid Clustering dengan versi Delta Lake yang didukung, dan jalur pengaktifan untuk tabel yang ada bervariasi menurut versi. Sebelum mengaktifkannya, periksa mesin, dampak peningkatan protokol, penulisan streaming, pembacaan inkremental, alat pencadangan, dan klien lama. Liquid Clustering tidak dapat digabungkan dengan partisi tradisional atau Z-Ordering, sehingga rencana migrasi harus menghentikan tugas pemeliharaan lama dan memvalidasi konsumen lama terhadap tabel bayangan.

4. Mulai dengan pemeliharaan inkremental, lalu putuskan apakah perlu penulisan ulang penuh

Mengubah kolom pengelompokan tidak secara otomatis menulis ulang semua data yang ada; penulisan baru dan pengoptimalan selanjutnya akan mengatur data di bawah tata letak baru. Aktifkan pada tabel bayangan atau tabel berisiko rendah dan jalankan OPTIMIZE inkremental terlebih dahulu, sambil mengamati perilaku pelewatan berkas untuk data baru. Jika berkas historis masih mendominasi pemindaian, jadwalkan OPTIMIZE FULL dan sertakan biaya komputasi, perebutan kunci (lock contention), dan jendela lalu lintas rendah dalam tinjauan perubahan.

sql

CREATE TABLE fact_orders (
  tenant_id STRING,
  order_date DATE,
  customer_id STRING,
  amount DECIMAL(18, 2)
) USING DELTA
CLUSTER BY (tenant_id, order_date);

OPTIMIZE fact_orders;

ALTER TABLE fact_orders CLUSTER BY (tenant_id, customer_id);
OPTIMIZE fact_orders FULL;

5. Validasi peningkatan terhadap baseline yang dapat direproduksi

Pertahankan kestabilan rangkaian kueri, snapshot data, konkurensi, dan kondisi cache. Bandingkan berkas yang dipindai, bita yang dipindai, latensi p50/p95, tingkat kegagalan, throughput penulisan, dan biaya per kueri sebelum dan sesudah migrasi. Contoh kriteria penerimaan dapat mensyaratkan 30% lebih sedikit bita yang dipindai, 20% lebih rendah p95, dan tidak lebih dari 10% peningkatan biaya penulisan; ini adalah contoh proyek dan harus disesuaikan dengan baseline. Uji juga kueri rentang waktu, kueri lintas penyewa, backfill, dan pengoptimalan konkuren sehingga satu jalur tidak menyembunyikan regresi.

6. Tambahkan rollback, tata kelola, dan pemantauan berkelanjutan

Simpan snapshot asli atau tabel bayangan, alihkan pembacaan pada lalu lintas rendah terlebih dahulu, dan perluas secara bertahap. Catat kolom pengelompokan, versi, batch pengoptimalan, dan metrik, serta terapkan pemeriksaan kompatibilitas untuk klien lama. Jika p95, latensi penulisan, atau biaya berulang kali melewati ambang batas, jeda perluasan, pulihkan rute pembacaan, dan hentikan pemeliharaan tata letak baru. Setelah rollback, tinjau kembali predikat dan ketimpangan data (skew) alih-alih langsung mencoba rangkaian kolom lain.

Jawaban lengkap yang kuat

Saya akan menetapkan baseline log kueri dan memverifikasi bahwa tenant_id dan filter waktu benar-benar mendominasi pemindaian, lalu memutar ulang dua atau tiga kombinasi kolom pengelompokan pada tabel bayangan. Sebelum peluncuran, saya akan memeriksa versi Delta/Spark, perilaku protokol, pembacaan dan penulisan streaming, serta klien lama karena Liquid Clustering menggantikan alih-alih menggabungkan dengan pemartisian dan Z-Ordering serta mendukung paling banyak empat kolom. Saya akan memigrasikan data baru terlebih dahulu dan menjalankan OPTIMIZE inkremental; jika berkas historis masih mendorong pemindaian, saya akan menjadwalkan OPTIMIZE FULL selama jendela lalu lintas rendah. Saya akan membatasi peluncuran berdasarkan bita yang dipindai, jumlah berkas, p95, biaya, throughput penulisan, dan tingkat kegagalan sambil mempertahankan snapshot, sakelar jeda, dan fallback rute pembacaan. Saya akan memperluas hanya setelah dua jendela pengamatan terlewati, serta menjeda dan meninjau kembali jika ada pelanggaran metrik.

Mode kegagalan umum

Mengulang pernyataan "Liquid Clustering lebih cepat" tanpa baseline kueri atau kelompok kontrol.
Mengabaikan ketidakcocokannya dengan pemartisian dan Z-Ordering sementara tugas lama terus berjalan.
Mengasumsikan perubahan kolom pengelompokan segera menulis ulang semua data historis, tanpa rencana pengoptimalan inkremental atau penuh.
Hanya melaporkan latensi rata-rata sambil mengabaikan bita yang dipindai, p95, biaya penulisan, dan ketimpangan data.
Mengaktifkannya pada tabel produksi tanpa pemeriksaan versi, protokol, klien lama, dan rollback.

Pertanyaan lanjutan dan perluasan

Pertanyaan lanjutan 1: Mengapa tidak memasukkan keempat kolom umum dalam definisi?

Batas kolom bukanlah target yang harus dipenuhi. Kolom tambahan meningkatkan biaya pemeliharaan tata letak dan dapat mengurangi keuntungan di berbagai kombinasi kueri. Pilih kumpulan efektif terkecil menggunakan frekuensi predikat, selektivitas, dan hasil pemutaran ulang kueri.

Pertanyaan lanjutan 2: Berapa lama sampai data yang ada mengalami peningkatan performa?

Jangan menjanjikan waktu yang pasti. Data yang ada tidak secara otomatis ditulis ulang saat kolom berubah; jawabannya tergantung pada cakupan OPTIMIZE inkremental. Jika data historis mendominasi, evaluasi jendela waktu dan biaya dari OPTIMIZE FULL.

Pertanyaan lanjutan 3: Bagaimana Anda menangani ketimpangan (skew) penyewa yang ekstrem?

Putar ulang beban kerja berdasarkan tingkatan penyewa dan bandingkan kueri penyewa besar, penyewa kecil, dan lintas penyewa secara terpisah. Sesuaikan rangkaian kolom atau perutean kueri jika diperlukan, dan gunakan persentil terburuk daripada rata-rata keseluruhan sebagai kriteria penerimaan.

Pertanyaan lanjutan 4: Sinyal apa yang memberi tahu Anda untuk menghentikan migrasi?

Jeda perluasan jika bita yang dipindai tidak menurun secara konsisten, p95 atau biaya penulisan terus memburuk, klien lama tidak kompatibel, atau simulasi rollback gagal. Pulihkan jalur pemeliharaan asli dan lakukan kembali analisis beban kerja.