Wawancara data engineering: Bagaimana stempel waktu nanodetik Iceberg v3 dapat menghindari distorsi lintas-engine?

Konteks dan cakupan

Sebuah event lake harus mempertahankan stempel waktu penangkapan pada presisi nanodetik. Tabel ini menggunakan Iceberg v3 dan dibaca oleh engine batch, streaming, dan BI. Jelaskan perbedaan antara tipe stempel waktu dengan dan tanpa zona waktu, pemeriksaan saat penulisan (write-time), kompatibilitas reader lama, serta migrasi yang dapat dibatalkan (reversible).

Hal yang diuji oleh pewawancara

• Mengetahui bahwa v3 menambahkan timestamp_ns dan timestamptz_ns, bukan mengganti nama bidang milidetik.
• Membedakan waktu sipil (civil time) dari momen absolut (absolute instant) dan menangani offset dengan benar.
• Mengenali pemotongan (truncation), waktu bernilai negatif, dan risiko serialisasi.
• Merancang matriks kemampuan lintas-engine dan jalur rollback.

Pertanyaan klarifikasi

1. Apakah presisi nanodetik diperlukan untuk pengurutan, atau hanya untuk tampilan audit?
2. Apakah nilainya mewakili satu momen global atau nilai kalender lokal?
3. Versi Iceberg v3 mana yang didukung oleh writer, layanan katalog, dan reader?
4. Jika sistem lama hanya membaca milidetik, bolehkah sistem tersebut menggunakan kolom yang diturunkan mutunya (degraded) secara eksplisit?

Jawaban 30 detik

Pilih berdasarkan makna: timestamp_ns tidak memiliki zona waktu, sedangkan timestamptz_ns mewakili momen absolut dengan offset +00:00. Tolak pemotongan implisit pada writer, normalisasi input ke ISO-8601 kanonis atau nilai epoch-nanodetik eksplisit, dan validasi rentang, tanda (sign), serta pembulatan. Bangun matriks kemampuan sebelum migrasi; reader tanpa dukungan v3 harus menggunakan compatibility view atau kolom milidetik yang ditulis ganda (dual-written), bukan menebak tipe baru tersebut. Buktikan hasilnya dengan uji pemutaran ulang (replay), lintas zona waktu, dan batas nilai (boundary).

Desain langkah demi langkah

1. Menetapkan semantik waktu

Ulang tahun dan tanggal bisnis adalah nilai kalender lokal; log, transaksi perdagangan, dan trace span biasanya mewakili satu momen di seluruh dunia dan harus menggunakan timestamptz_ns. Bidang bernama created_at tidak membuktikan bahwa itu adalah UTC, dan offset lokal tidak boleh dibuang secara diam-diam.

2. Mempertahankan batasan presisi

Parsing input dan pertahankan kesembilan digit pecahan. Jangan lewatkan melalui JavaScript Date atau bilangan bulat milidetik terlebih dahulu. Bandingkan nilai yang diserialisasi dan di-parse dengan metode round trip agar komponen nanodetik tetap tidak berubah.

stored_ns = parse(input)
assert format(parse(format(stored_ns))) == stored_ns

3. Menangani zona waktu dan pencilan (outliers)

Tipe yang peka terhadap zona waktu memerlukan offset kanonis; simpan representasi UTC dan konversikan hanya saat ditampilkan. Uji epoch negatif sebelum tahun 1970, kebijakan detik kabisat (leap second), batas daylight-saving, dan nilai di luar rentang implementasi. Tolak string lokal yang ambigu atau wajibkan pemanggil untuk menyediakan zona waktu.

4. Membangun matriks kompatibilitas

Cakup katalog, writer, reader batch, reader streaming, dan engine BI. Catat apakah masing-masing mengenali v3, mempertahankan nanodetik, serta gagal atau mengabaikan tipe yang tidak dikenal. Jangan menyimpulkan perilaku hanya dari versi pustaka (library); jalankan tabel baca/tulis minimal melalui setiap engine.

5. Merencanakan migrasi dan degradasi

Tulis kedua tipe nanodetik ke tabel yang terisolasi dan putar ulang sampel nyata. Jika reader lama tidak dapat mendukung v3, ekspos kolom turunan milidetik eksplisit dengan pernyataan pelepasan presisi (precision disclaimer); jangan pernah berpura-pura bahwa itu adalah data nanodetik. Gunakan penulisan ganda, pemeriksaan kesetaraan, dan cutover per-engine, dengan opsi beralih kembali ke tabel atau kolom lama.

6. Memantau kualitas data

Lacak pemotongan, kegagalan parse, zona yang hilang, rasio nilai negatif, dan perbedaan round-trip lintas-engine. Ambil sampel dari event mentah, file Iceberg, dan hasil kueri; catat versi skema, versi writer, dan kebijakan zona waktu dalam metadata audit.

Contoh jawaban berkualitas tinggi

Pertama-tama saya akan menetapkan apakah nilai tersebut merupakan momen absolut. Event absolut menggunakan timestamptz_ns; nilai kalender lokal menggunakan timestamp_ns. Writer mempertahankan representasi nanodetik secara end-to-end, menolak API milidetik, dan menguji round trip sembilan digit, epoch negatif, batas daylight-saving, dan batas rentang. Sebelum migrasi, saya membangun matriks kemampuan v3. Reader versi lama menggunakan kolom turunan milidetik eksplisit atau compatibility view, tidak pernah melakukan pemotongan diam-diam. Saya menerapkan penulisan ganda, melakukan cutover engine demi engine, memantau kehilangan dan divergensi, serta mempertahankan kemampuan untuk beralih kembali ke tabel atau kolom lama.

Kesalahan umum

• Memperlakukan kedua tipe sebagai UTC → mengubah makna kalender lokal → tetapkan semantik terlebih dahulu.
• Mengonversi ke milidetik sebelum menulis ke v3 → presisi sudah hilang → pertahankan nanodetik secara end-to-end.
• Menghapus offset +08:00 → menggabungkan momen yang berbeda → normalisasi ke UTC, lalu tampilkan secara lokal.
• Hanya menguji penulisan yang berhasil → reader lama mungkin gagal atau melakukan pemotongan → uji seluruh matriks dan lakukan pemutaran ulang (replay).
• Mempercayai nomor versi → dukungan format mungkin berbeda → jalankan pembacaan dan penulisan minimal lintas-engine.

Pertanyaan lanjutan dan tanggapan

Bisakah timestamp_ns menggantikan timestamptz_ns?

Tidak. Yang pertama tidak membawa zona waktu dan sesuai dengan semantik kalender yang ditentukan; yang kedua mengekspresikan momen yang memiliki offset. Mengganti salah satunya akan mengubah makna bisnis, bukan hanya presisi.

Bagaimana jika engine lama tidak dapat membaca tabel v3?

Tentukan apakah engine tersebut menolak tipe yang tidak dikenal atau masih dapat membaca kolom lain. Dalam lingkungan produksi, gunakan compatibility view atau kolom milidetik yang ditulis ganda dengan penurunan presisi secara eksplisit; jangan biarkan engine lama menebak-nebak.

Apakah pengurutan nanodetik sama dengan pengurutan kausal?

Tidak. Nilai dari jam pada mesin yang berbeda dapat mengalami pergeseran (skew). Pengurutan tetap memerlukan ID event, nomor urut sumber, atau jam logis; stempel waktu hanyalah sebuah observasi.