Wawancara Data Engineering: Merancang Sistem Data Lineage

Prompt dan Konteks yang Berlaku

Perusahaan Anda memiliki 30.000 dataset dan 200.000 pipeline run per hari di seluruh Airflow, Spark, dbt, dan Kafka. Tim perlu menjawab tiga pertanyaan: dari mana dataset atau field berasal, apa yang akan terpengaruh oleh perubahan yang diusulkan, dan output mana yang dihasilkan oleh eksekusi tertentu. Rancang sistem lineage yang menangkap dependensi tingkat tabel dan kolom, mendukung penelusuran upstream dan downstream, merekonstruksi lineage pada waktu lampau, menangani retry serta run yang gagal atau parsial, menegakkan akses metadata, dan mengekspos apakah graf cukup lengkap untuk dipercaya.

Untuk wawancara ini, asumsikan penyerapan event mencapai puncak 500 event per detik, penelusuran tiga-hop biasanya harus selesai dalam 2 detik, dan riwayat eksekusi terperinci disimpan selama 1 tahun. Ini adalah input skenario, bukan tolok ukur industri. Desain harus menjelaskan bagaimana batasan ini akan diukur dan direvisi setelah mengamati traffic nyata.

Materi wawancara data-engineering tahun 2026 saat ini secara langsung menanyakan kepada kandidat bagaimana mereka merancang data lineage dan menyoroti tingkat tabel, kolom, dan job, penangkapan metadata, penamaan, dan dampak perubahan. OpenLineage 1.50.0 memberikan baseline faktual yang berguna: Job, Run, dan Dataset adalah entitas inti; namespace dan nama mengidentifikasi Job dan Dataset; Run menggunakan UUID; run event memiliki state siklus hidup yang terdefinisi; dan facet memperluas model dengan dependensi skema dan kolom. Kategorinya adalah data karena kemampuan utamanya adalah pemodelan metadata, semantik pipeline, analisis dampak, dan tata kelola data.

Apa yang Dinilai oleh Pewawancara

Sinyal pertama adalah apakah kandidat memulai dengan identitas dan semantik. Sebuah graf tidak dapat digunakan ketika tabel yang sama muncul sebagai orders, prod.orders, dan URL warehouse, atau ketika retry disalahartikan sebagai job baru. Kunci sumber daya yang stabil, batasan lingkungan, definisi job, execution ID, path field, dan semantik versi harus ditetapkan sebelum memilih database graf.

Sinyal kedua adalah apakah lineage mencerminkan realitas eksekusi. Lineage yang dideklarasikan (declared) dari kode sumber membantu sebelum rilis; lineage yang diobservasi (observed) dari run aktual membuktikan apa yang dibaca dan ditulis. Run yang gagal mungkin telah menulis output sementara atau parsial, sementara status eksekusi yang sukses tetap tidak membuktikan kebenaran data. Desain yang kuat membedakan bukti event, run state, declared edge, observed edge, dan publication state secara terpisah.

Sinyal ketiga adalah kedalaman desain sistem. Kandidat harus mencakup integrasi producer, jalur penyerapan yang tahan lama (durable) dan idempoten, raw event yang tidak dapat diubah (immutable), normalisasi, materialisasi graf temporal, indeks penelusuran, metrik kesegaran dan cakupan, backfill, serta kontrol akses. Mengatakan "masukkan saja ke database graf" mengabaikan masalah-masalah tersulit.

Terakhir, pewawancara menginginkan kepercayaan yang terkalibrasi. Instrumentasi yang hilang harus tetap terlihat. Graf rapi yang disusun dari 60% job kritis berbahaya jika UI menyajikannya seolah-olah lengkap. Jawaban yang kuat mengekspos provenans (asal-usul), waktu observasi, tingkat keyakinan, cakupan, dan celah/gap sehingga pengguna dapat memutuskan apakah kueri dampak memadai untuk keputusan deployment.

Pertanyaan untuk Diklarifikasi Sebelum Menjawab

• Keputusan apa yang harus didukung oleh lineage? Diagnosis insiden, analisis dampak pra-deployment, penemuan tata kelola,

propagasi PII, dan bukti audit memiliki persyaratan kesegaran, riwayat, dan kebenaran yang berbeda.

• Apa yang dihitung sebagai dataset? Tabel, view, file, prefiks objek, Kafka topic, materialized view, dasbor, dan

fitur machine-learning memerlukan granularitas eksplisit. Memperlakukan setiap file sebagai node dapat membuat graf tidak dapat digunakan.

• Apakah kita memerlukan declared lineage, observed lineage, atau keduanya? Declared lineage dapat menunjukkan perubahan di masa depan sebelum eksekusi;

observed lineage dapat mengikat input dan output ke Run konkret. UI tidak boleh menggabungkan maknanya secara diam-diam.

• Berapa presisi tingkat field yang diperlukan? Derivasi nilai langsung berbeda dari pengaruh tidak langsung melalui join,

filter, pengelompokan (grouping), pengurutan (sort), window, atau kondisi. Beberapa engine mengekspos logical plan; yang lain hanya mengekspos lineage tabel.

• Bagaimana dataset dan job diidentifikasi di seluruh lingkungan? Tentukan namespace, nama kanonikal, alias, aturan huruf besar/kecil (case),

perubahan nama (rename), dan kepemilikan. Label tampilan bukanlah primary key yang tahan lama.

• Apa yang harus terjadi setelah run yang gagal atau parsial? Klarifikasi apakah output yang ditulis sebagian dipublikasikan, diisolasi,

atau di-rollback dan apakah analisis dampak harus menyertakannya sebagai bukti, kebenaran saat ini, atau keduanya.

• Berapa lama riwayat point-in-time harus tetap dapat dikueri? Satu tahun run event tidak serta-merta memerlukan satu tahun

setiap edge kolom yang diperluas di serving layer berlatensi rendah.

• Metadata mana yang sensitif? Teks SQL, nama field, kepemilikan, tag PII, dan keberadaan dataset dapat mengungkap informasi yang

dilindungi. Hasil penelusuran memerlukan disiplin otorisasi yang sama seperti katalog.

• Apa sasaran skala dan layanan (service objectives)? Konfirmasikan laju event, ukuran graf, kedalaman penelusuran, persentil latensi,

recovery-point objective, dan keterlambatan yang dapat diterima antara sebuah run dan lineage yang terlihat.

Kerangka Jawaban 30 Detik

"Saya akan memodelkan identitas kanonikal Job, Run, Dataset, dan Field, lalu memisahkan declared dari observed lineage serta lineage tabel dari lineage kolom. Producer memancarkan event berversi melalui gateway terotentikasi dan idempoten yang didukung oleh durable log. Consumer menyimpan bukti mentah dan membangun indeks temporal upstream dan downstream; output yang gagal tetap bersifat diagnostik sampai publikasi dikonfirmasi. Penelusuran dibatasi oleh kedalaman, waktu, dan izin serta mengekspos provenans dan celah (gap). Saya akan mengukur lag, cakupan job yang diharapkan, kelengkapan terminal event, identitas yang belum terselesaikan, edge basi, dan akurasi path sampel, meluncurkan lineage tabel untuk pipeline kritis sebelum menambahkan ekstraksi kolom yang andal."

Jawaban Mendalam Langkah demi Langkah

Langkah 1: Tentukan model kebenaran sebelum storage engine.

Gunakan empat jenis record:

Namespace harus berasal dari sumber data untuk Dataset dan dari scheduler atau sistem pemrosesan untuk Job. Simpan alias dalam pemetaan terpisah dengan interval validitas. Mengubah nama analytics.orders menjadi analytics.sales_orders tidak boleh secara diam-diam membuat atau menggabungkan identitas berdasarkan kesamaan string; ini memerlukan event rename atau alias yang eksplisit.

Modelkan declared lineage dari SQL yang dikompilasi, dbt manifest, atau konfigurasi secara terpisah dari observed lineage yang dipancarkan oleh sebuah Run. Modelkan edge tabel secara terpisah dari edge field. Sebuah edge field mencatat output field, input field, jenis transformasi, dan apakah dependensinya berupa derivasi nilai langsung atau pengaruh tidak langsung. Model kolom OpenLineage membedakan identitas langsung, transformasi, dan agregasi dari efek tidak langsung seperti join, group, filter, sort, window, dan kondisi. Perbedaan itu penting saat memutuskan apakah mengubah nilai, tipe, atau ketersediaan suatu field mempengaruhi output.

Setiap edge harus menyertakan validFrom, validTo opsional, observedAt, producer, source event, versi Job, Run ID, run status, jenis lineage, dan confidence atau metode derivasi. Atribut-atribut ini mengubah panah tanpa kualifikasi menjadi bukti yang dapat menjawab "sejak kapan?" dan "menurut apa?".

Langkah 2: Tangkap lineage sedekat mungkin dengan eksekusi.

Gunakan integrasi native atau yang dikelola jika tersedia: listener orkestrasi untuk siklus hidup task, instrumentasi logical-plan Spark, artefak dbt dan run results, serta konektor atau riwayat kueri untuk warehouse dan sistem streaming. Utamakan logical plan yang di-parse atau dihasilkan oleh engine daripada regex terhadap SQL. SQL dinamis, makro, stored procedure, objek sementara, user-defined function, dan pemilihan branch saat runtime membuat parsing string menjadi tidak lengkap.

Tentukan amplop penyerapan (ingestion envelope) berversi di sekitar payload lineage:

{
  "eventId": "producer-unique-id",
  "producer": "spark-prod-eu",
  "schemaVersion": "1.0",
  "emittedAt": "2026-07-19T00:00:00Z",
  "job": { "namespace": "spark-prod", "name": "daily_orders" },
  "runId": "53ee3770-86fa-4cb9-8c31-a09072dd88f7",
  "state": "COMPLETE",
  "inputs": [{ "namespace": "warehouse-prod", "name": "raw.orders" }],
  "outputs": [{ "namespace": "warehouse-prod", "name": "mart.daily_orders" }]
}

eventId adalah persyaratan dari amplop platform ini untuk idempotensi; jangan mengklaimnya sebagai field wajib dalam setiap standar lineage eksternal. Producer mencoba ulang pengiriman dengan ID yang sama. Gateway mengotentikasi producer, memeriksa kompatibilitas skema dan batas ukuran, melampirkan waktu penerimaan, dan menulis event ke durable log yang terpartisi sebelum mengirimkan acknowledgement. Event yang tidak valid masuk ke karantina stream beserta alasan, producer, dan referensi payload yang aman; event tersebut tidak hilang begitu saja di dalam log.

Pemartisian berdasarkan Run ID mempertahankan urutan lokal suatu Run sekaligus mendistribusikan run yang tidak terkait. Waktu event bisa terlambat atau miring (skewed), sehingga consumer menyimpan waktu pemancaran (emitted) dan penerimaan (received) serta menerapkan aturan siklus hidup. OpenLineage mendefinisikan START, RUNNING, COMPLETE, ABORT, FAIL, dan OTHER; terminal event tidak boleh dibatalkan oleh START yang datang terlambat. Simpan event yang tidak dapat diubah (immutable) bahkan ketika event tersebut tidak lagi mengubah state saat ini yang termaterialisasi.

Langkah 3: Normalisasi tanpa merusak provenans.

Normalizer mengonversi payload setiap integrasi menjadi identitas kanonikal dan semantik edge. Normalizer menyelesaikan alias terdaftar, konvensi huruf besar/kecil, lingkungan, dataset sementara, dan nested field path. Identitas yang tidak dikenal masuk ke antrean yang belum terselesaikan (unresolved queue) alih-alih ditebak. Raw event, record yang dinormalisasi, versi resolver, dan peringatan apa pun tetap terhubung sehingga pemetaan yang salah dapat diperbaiki dan diputar ulang (replayed).

Perubahan skema menghasilkan definisi field berversi. Menghapus dan kemudian membuat ulang customer_id tidak mengimplikasikan riwayat field yang berkelanjutan. Hash skema atau versi katalog ditambah interval validitas memungkinkan kueri point-in-time memilih field yang tepat. Untuk pipeline streaming, catat topic dan transformasi Job pada granularitas yang stabil; pertahankan partisi dan offset sebagai bukti Run alih-alih memecah setiap pasangan partisi-offset menjadi node graf permanen.

Perlakukan execution state dengan hati-hati. COMPLETE berarti eksekusi Job telah selesai; ini tidak menjamin kualitas bisnis dari output tersebut. Event FAIL atau ABORT mungkin masih melaporkan input dan output yang dicoba. Simpan observed edge tersebut untuk diagnosis, tetapi hanya materialisasikan lineage terpublikasi saat ini ketika kebijakan publikasi output terpenuhi. Kebijakan tersebut mungkin memerlukan atomic commit marker atau quality gate terpisah. Beri label secara eksplisit.

Langkah 4: Bangun graf temporal event-sourced dengan indeks yang sesuai peruntukan.

Durable log dan arsip object-store yang immutable adalah sumber pemulihan. Consumer membuat tiga proyeksi:

1. Metadata store untuk Job, Dataset, Field kanonikal, skema, alias, pemilik, dan kebijakan akses.
2. Temporal edge store untuk declared dan observed lineage dengan interval validitas dan provenans eksekusi.
3. Run store untuk event siklus hidup, snapshot input/output, status, dan detail diagnostik.

Estimasi kapasitas awal yang dapat direproduksi mencegah jumlah Run harian disalahartikan sebagai throughput event. Minimal, satu START dan satu terminal event untuk masing-masing dari 200.000 Run menghasilkan 400.000 event per hari, sekitar 4,6 per detik secara rata-rata. Jika Run tipikal memancarkan satu START, dua pembaruan RUNNING, dan satu terminal event, jumlahnya menjadi 800.000 per hari, sekitar 9,3 per detik; oleh karena itu, input 500 per detik adalah target lonjakan (burst), bukan rata-rata. Dengan asumsi rata-rata raw payload sebesar 20 KB, 800.000 event membutuhkan sekitar 16 GB per hari atau 5,8 TB per tahun sebelum kompresi dan replikasi. Ukuran payload dan event per Run harus diukur karena facet kolom dapat mengubah estimasi ini secara substansial.

Untuk kueri dampak berlatensi rendah, pertahankan indeks adjasensi downstream dan upstream yang diberi kunci berdasarkan canonical node ID dan time bucket atau versi aktif. Penelusuran breadth-first memiliki batas kedalaman maksimum, jumlah node, tipe edge, lingkungan, dan batas waktu yang eksplisit. Layanan mengembalikan indikator hasil parsial jika batas tercapai. Database graf dapat mengimplementasikan ini, tetapi tidak wajib; tabel edge relasional dengan indeks yang sesuai atau layanan adjasensi key-value mungkin lebih sederhana pada skala ini. Lakukan benchmark pada fanout aktual dan predikat point-in-time sebelum memilih.

Lineage kolom bisa jauh lebih besar daripada lineage tabel. Simpan edge tabel di proyeksi hot, pertahankan adjasensi field yang sering dikueri tetap hot, dan tempatkan edge detail yang lebih lama atau jarang digunakan dalam penyimpanan historis terkompresi. Jangan melakukan prakalkulasi (precompute) transitive closure penuh: graf yang padat membuatnya mahal untuk diperbarui dan diotorisasi. Simpan hasil kueri berbatas dalam cache berdasarkan node, arah, kedalaman, waktu, filter jenis edge, dan cakupan otorisasi; batalkan cache saat versi edge yang relevan berubah.

Langkah 5: Buat kontrak kueri secara eksplisit.

API harus mendukung:

• penelusuran upstream atau downstream untuk Dataset atau Field, dibatasi oleh kedalaman dan titik waktu (point in time);
• analisis dampak untuk usulan perubahan skema atau field, dengan dependensi langsung dan tidak langsung yang dibedakan;
• pencarian Run yang menunjukkan input, output, versi Job, siklus hidup, dan status publikasi secara tepat;
• provenans pada setiap edge yang dikembalikan, termasuk declared versus observed dan waktu observasi terakhir;
• penanda celah (gap marker) untuk Job tanpa instrumentasi, identitas yang belum terselesaikan, producer basi, dan penelusuran yang terpotong (truncated).

Otorisasi tidak dapat diterapkan hanya setelah penelusuran. Nama atau keberadaan Dataset yang tersembunyi dapat bersifat sensitif. Selesaikan kebijakan pemanggil selama ekspansi, hilangkan atau ganti node yang dilindungi sesuai dengan aturan tata kelola, cegah jumlah derajat (degree count) membocorkan tetangga yang tersembunyi, dan audit penelusuran sensitif. Kunci cache menyertakan cakupan otorisasi sehingga graf milik satu pengguna tidak pernah disajikan kepada pengguna lain.

Untuk sasaran tiga-hop 2 detik, ukur P50, P95, dan P99 berdasarkan arah, kedalaman, fanout, filter temporal, serta kueri kolom versus tabel. Respons dapat mengembalikan continuation token atau pemotongan (truncation) eksplisit ketika batas kuota node terlampaui. Mengembalikan graf yang tidak lengkap secara diam-diam tidak dapat diterima.

Langkah 6: Rancang pemutaran ulang (replay), backfill, dan disaster recovery.

Consumer melakukan checkpoint pada offset durable-log. Karena pemrosesan bersifat at-least-once, penulisan proyeksi menggunakan eventId dan versi proyeksi untuk idempotensi. Bug normalisasi diperbaiki dengan men-deploy versi resolver baru, membangun ulang ke proyeksi bayangan (shadow projection) dari raw event, membandingkan jumlah dan jalur sampel, serta mengalihkan pembaca setelah validasi. Jangan menimpa satu-satunya serving graph selama pemutaran ulang penuh.

Simpan raw event selama 1 tahun yang diperlukan dalam penyimpanan immutable, dengan enkripsi dan lifecycle policy. Buat snapshot metadata kanonikal dan proyeksi edge untuk mengurangi waktu pemulihan, tetapi buktikan bahwa snapshot ditambah event setelahnya mereproduksi hasil yang sama. Tentukan target pemulihan, uji kehilangan satu region penyerapan, dan verifikasi bahwa retry producer tidak menghasilkan edge tambahan.

Point-in-time lineage menggunakan validitas edge dan waktu observasi, bukan graf saat ini ditambah label timestamp. Kueri untuk bulan lalu harus menyelesaikan identitas, versi skema, dan edge terotorisasi yang valid saat itu. Jika suatu sumber tidak pernah memancarkan riwayat, kembalikan batasan tersebut alih-alih mengada-adakannya.

Langkah 7: Ukur kepercayaan sebagai properti produk.

Lacak setidaknya metrik-metrik ini:

Cakupan membutuhkan penyebut (denominator). Bandingkan Run yang memancarkan lineage terhadap inventaris scheduler atau riwayat kueri warehouse, bukan hanya jumlah event yang diterima. Publikasikan lencana kepercayaan seperti "diamati 12 menit yang lalu", "hanya dideklarasikan", "lineage kolom tidak tersedia", atau "2 dari 17 Job upstream belum diinstrumentasi". Hindari satu skor keyakinan buram yang menyembunyikan mode kegagalan.

Validasi dengan pipeline fixture deterministik yang berisi kasus identitas, agregasi, join, filter, rename, retry, kegagalan, dan publikasi parsial. Di produksi, ambil sampel run baru-baru ini dan bandingkan plan engine, event yang dipancarkan, edge yang dinormalisasi, dan hasil kueri secara end-to-end. Rekonsiliasi jumlah node dan edge pada setiap rilis proyeksi.

Langkah 8: Luncurkan berdasarkan nilai keputusan.

Mulailah dengan domain kritis bisnis dan lineage tingkat tabel. Daftarkan identitas kanonikal dan pemiliknya, pasang instrumentasi pada scheduler dan engine dengan dampak tertinggi, serta ekspos kesegaran dan cakupan sebelum menjanjikan analisis dampak yang komprehensif. Kemudian tambahkan lineage kolom untuk engine dengan logical plan yang andal, declared lineage pra-deployment, riwayat, dan propagasi PII.

Keberhasilan diukur dari keputusan: persentase perubahan kritis dengan laporan dampak pra-deployment yang dapat digunakan, persentase insiden yang batas hulu (upstream) buruk pertamanya dapat diidentifikasi, pengurangan identitas yang belum terselesaikan, dan cakupan producer kritis. Jumlah node dan graf yang padat secara visual bukanlah metrik keberhasilan.

Contoh Jawaban Berkualitas Tinggi

"Saya akan mulai dengan menentukan keputusan dan identitas. Untuk sistem ini, Dataset atau Job diidentifikasi oleh namespace dan nama kanonikal dalam suatu lingkungan, Field menambahkan canonical path dan versi skema, dan Run adalah satu eksekusi yang diidentifikasi oleh UUID. Alias dan perubahan nama (rename) adalah pemetaan eksplisit yang dibatasi waktu. Saya akan memisahkan declared lineage dari plan yang dikompilasi dari observed lineage dari eksekusi, serta dependensi tabel dari dependensi field.

Pada waktu pengumpulan, integrasi yang dikelola di Airflow, Spark, dbt, dan framework pemrosesan Kafka yang relevan memancarkan payload berversi. Engine Spark dan SQL harus menggunakan logical plan jika memungkinkan karena regex tidak dapat memahami SQL dinamis, join, makro, atau runtime branch secara andal. Setiap amplop platform menyertakan event ID unik per producer, producer, versi skema, identitas Job, Run ID, lifecycle state, serta input dan output. Ingestion gateway mengotentikasi producer, memvalidasi payload, dan menambahkannya ke durable log sebelum mengirimkan ack. Pengiriman ulang dengan event ID yang sama bersifat idempoten; event yang tidak valid masuk ke antrean karantina yang terlihat.

Raw event bersifat immutable. Normalizer menyelesaikan alias terdaftar dan membuat Job, Dataset, Field, dan edge berversi sembari mempertahankan source event dan versi resolver. Normalizer tidak pernah menebak identitas yang tidak dikenal. Run state mempengaruhi serving: START dan RUNNING dapat menambahkan bukti, sedangkan COMPLETE, ABORT, dan FAIL bersifat terminal. Run yang gagal tetap tersedia untuk diagnosis, tetapi output yang dicobanya tidak dipromosikan sebagai lineage terpublikasi saat ini kecuali penanda publikasi independen menyatakan bahwa data tersebut telah terlihat. COMPLETE membuktikan selesainya eksekusi, bukan kebenaran data.

Consumer membangun canonical metadata store, temporal edge store, dan Run store. Indeks adjasensi upstream dan downstream mendukung penelusuran breadth-first berbatas. Setiap edge membawa interval validitas, waktu observasi, producer, versi Job, Run, status, jenis declared-atau-observed, dan transformasi field langsung-atau-tidak langsung. Kueri point-in-time memilih identitas dan edge yang valid pada waktu tersebut. Saya tidak akan melakukan prakalkulasi universal transitive closure karena fanout tinggi, perubahan versi, dan otorisasi membuatnya mahal dan berisiko.

Untuk 30.000 dataset dan 200.000 Run per hari, puncak 500 event per detik cukup moderat untuk dimulai dengan durable partitioned log dan proyeksi relasional atau key-value yang terindeks, lalu melakukan benchmark pada penyimpanan khusus graf terhadap fanout nyata. Edge kolom adalah dimensi yang lebih besar, sehingga adjasensi terbaru dan yang sering dikueri tetap hot sementara riwayat lama yang terperinci dapat dikompresi. Sasaran tiga-hop 2 detik diukur pada P50, P95, dan P99 berdasarkan tipe graf dan fanout. Setiap permintaan memiliki anggaran kedalaman dan node serta mengembalikan penanda kelanjutan atau pemotongan yang eksplisit.

Layanan kueri melakukan otorisasi selama ekspansi graf. Layanan ini tidak boleh membocorkan nama node tersembunyi, keberadaan, atau jumlah tetangga, dan kunci cache-nya menyertakan cakupan kebijakan pemanggil. Respons mencakup provenans dan celah yang terlihat: hanya dideklarasikan, waktu observasi, identitas yang belum terselesaikan, producer basi, lineage kolom yang hilang, dan Job tanpa instrumentasi.

Saya akan membuat proyeksi dapat diputar ulang (replayable). Raw event disimpan selama 1 tahun. Consumer melakukan checkpoint offset dan menulis secara idempoten. Bug resolver atau skema diperbaiki dengan membangun ulang shadow projection, merekonsiliasinya dengan yang aktif, menguji path yang diketahui, dan beralih hanya setelah validasi. Snapshot mempersingkat pemulihan tetapi diuji dengan event berikutnya untuk membuktikan rekonstruksi yang deterministik.

Terakhir, saya akan mengukur kepercayaan dengan cakupan expected-job, kelengkapan terminal-event, kegagalan resolusi identitas, kesegaran edge, cakupan tabel dan kolom kritis, event yang ditolak, dan kebenaran path sampel. Penyebutnya berasal dari inventaris scheduler dan riwayat kueri. Saya akan meluncurkan lineage tabel untuk domain keuangan dan pelanggan yang kritis, mempublikasikan celah cakupan, lalu menambahkan lineage kolom dan declared lineage di mana ekstraksi dapat diandalkan. Sistem ini berhasil ketika engineer dapat membuat perubahan yang lebih aman dan melacak insiden dengan bukti, bukan ketika graf hanya sekadar berisi banyak node."

Kesalahan Umum

• Memulai dengan database graf → Pilihan penyimpanan tidak menyelesaikan identitas, execution state, riwayat, atau instrumentasi

yang hilang → Tentukan entitas, bukti, siklus hidup, dan kontrak kueri terlebih dahulu.

• Menggunakan display name sebagai primary key → Alias, perubahan huruf besar/kecil, lingkungan, dan perubahan nama memecah atau menggabungkan node →

Gunakan identitas namespace/nama kanonikal dan alias eksplisit yang dibatasi waktu.

• Memperlakukan declared dan observed lineage sebagai hal yang identik → Kemungkinan yang dikompilasi dapat berbeda dari alur runtime →

Simpan jenis dan provenans dari setiap edge dan biarkan kueri memfilternya.

• Mempromosikan setiap output yang dicoba dari Run yang gagal → File atau tabel parsial menjadi kebenaran saat ini yang salah → **Simpan

bukti diagnostik, tetapi wajibkan semantik publikasi sebelum mengaktifkan edge.**

• Mengasumsikan COMPLETE berarti data benar → Eksekusi dapat selesai dengan output duplikat atau tidak valid → **Pisahkan state

kualitas data dari siklus hidup Run.**

• Mem-parse semua SQL dengan regex → SQL dinamis, dialek, makro, dan ekspresi bersarang menghasilkan dependensi palsu →

Utamakan engine plan dan parser yang didukung; ekspos cakupan yang tidak didukung.

• Melakukan deduplikasi berdasarkan hash payload tanpa kontrak event → Event progres yang berbeda dapat memiliki konten yang sama dan retry dapat

berbeda dalam timestamp → Wajibkan event ID yang stabil per producer dalam amplop penyerapan.

• Hanya menyimpan graf saat ini → Rekonstruksi dampak masa lalu dan insiden menjadi mustahil → **Pertahankan event yang

immutable dan versi edge temporal.**

• Melakukan prakalkulasi semua transitive path → Fanout, perubahan versi, dan otorisasi menyebabkan pembatalan cache yang mahal → **Gunakan

penelusuran berbatas dan caching yang ditargetkan.**

• Mengotorisasi hanya pada respons akhir → Node tersembunyi dan jumlah derajat dapat bocor selama penelusuran atau caching → **Terapkan

kebijakan selama ekspansi dan beri cakupan pada kunci cache.**

• Melaporkan jumlah event yang diterima sebagai cakupan → Producer yang tidak mengirim apa-apa (silent) menghilang dari event maupun metrik →

Bandingkan terhadap inventaris scheduler atau riwayat kueri.

• Menampilkan graf yang tampak lengkap dengan celah yang tidak diketahui → Pengguna membuat keputusan perubahan yang tidak aman → **Tampilkan kesegaran,

provenans, identitas yang belum terselesaikan, dan producer yang hilang di setiap hasil yang relevan.**

Pertanyaan Lanjutan dan Tanggapan

Lanjutan 1: Sebuah Spark Run yang gagal menulis partisi tabel sebelum memancarkan FAIL. Haruskah edge tersebut muncul?

Simpan Run dan edge input-output yang dicoba sebagai bukti diagnostik yang diobservasi, diberi tag FAIL dan tidak dipublikasikan. Apakah edge tersebut muncul di graf produksi saat ini bergantung pada commit penyimpanan dan kebijakan publikasi. Jika partisi menjadi terlihat, tampilkan sebagai versi yang gagal atau mencurigakan (suspect) hingga di-rollback atau divalidasi; jika penulisan bersifat atomik dan dibatalkan, jangan aktifkan. Mempertahankan bukti eksekusi dan status publikasi menghindari hilangnya detail forensik atau menyajikan output parsial sebagai kebenaran tepercaya.

Lanjutan 2: Bagaimana Anda mendeteksi producer yang diam-diam berhenti mengirim lineage?

Metrik event yang diterima tidak dapat mendeteksi producer yang absen sendirian. Bangun inventaris expected-Run dari jadwal Airflow, riwayat Spark, dbt run results, log kueri warehouse, atau control plane independen lainnya. Gabungkan (join) expected Runs dengan event lineage berdasarkan identitas Job dan Run kanonikal dalam jendela keterlambatan (lateness window). Berikan peringatan pada start yang hilang, terminal event yang hilang, dan cakupan yang menurun berdasarkan tingkat kekritisan, sembari membedakan Job yang dinonaktifkan dari integrasi yang rusak.

Lanjutan 3: Bagaimana Anda menjawab analisis dampak sebelum Job yang diubah dijalankan?

Gunakan declared lineage yang diekstraksi dari usulan compiled plan atau manifest dan bandingkan dengan definisi aktif. Telusuri ke hilir (downstream) dari output yang dihapus atau diubah, beri label hasilnya sebagai bukti declared pra-deployment, dan tunjukkan di mana observed lineage mengonfirmasi atau tidak sejalan dengannya. CI gate dapat mewajibkan tinjauan pemilik untuk aset kritis yang terpengaruh. Jangan mengklaim bahwa jalur runtime masa depan telah diobservasi; runtime branch yang dinamis mungkin masih berbeda setelah deployment.

Lanjutan 4: Mengapa tidak menyimpan semuanya dalam satu database graf?

Satu database mungkin dapat diterima setelah benchmark, tetapi riwayat Run event, pemutaran ulang immutable, pencarian metadata, dan adjasensi berlatensi rendah memiliki pola akses yang berbeda. Memisahkan sumber event yang tahan lama dari proyeksi yang dapat dibangun ulang melindungi pemulihan dan memungkinkan setiap proyeksi berkembang. Mulailah dengan jumlah penyimpanan paling sedikit yang memenuhi pola-pola tersebut, ukur biaya fanout dan kueri temporal, dan tambahkan penyimpanan khusus hanya jika bukti membenarkan biaya operasionalnya.

Lanjutan 5: Lineage kolom melipatgandakan jumlah edge hingga ratusan kali. Apa yang Anda turunkan kualitasnya (degrade) terlebih dahulu?

Lindungi kebenaran dan keputusan kritis. Pertahankan lineage tabel dan lineage kolom terbaru untuk domain berkekritisan tinggi tetap hot, pindahkan edge detail lama ke penyimpanan historis terkompresi, dan hitung jalur field yang jarang digunakan secara asinkron. Terapkan anggaran penelusuran dan kembalikan status parsial yang eksplisit. Jangan mengganti jawaban kolom dengan tebakan tabel secara diam-diam. Lacak cakupan kolom berdasarkan engine dan domain sehingga penurunan kualitas tetap terukur dan dapat dipulihkan (reversible).