Apache Iceberg telah muncul sebagai topik hangat dalam infrastruktur data, namun tantangan teknis yang kritis menyebabkan diskusi sengit di antara para pengembang. Masalah ini berpusat pada bagaimana menangani operasi delete secara efisien ketika melakukan streaming perubahan real-time dari database tradisional seperti Postgres ke dalam sistem penyimpanan Apache Iceberg yang berfokus pada analitik.
Dilema Teknis Inti
Ketika perusahaan ingin mencerminkan perubahan database Postgres mereka ke Apache Iceberg untuk analitik, mereka menghadapi pilihan mendasar antara dua mekanisme delete. Position delete bekerja dengan menentukan lokasi file yang tepat dan nomor baris, menawarkan performa query yang sangat baik karena sistem dapat melewati baris tanpa membacanya. Namun, pendekatan ini memerlukan pengetahuan tentang lokasi penyimpanan fisik sebelumnya, yang menciptakan bottleneck besar untuk skenario streaming real-time.
Equality delete, di sisi lain, bekerja dengan mencocokkan nilai primary key daripada lokasi fisik. Pendekatan ini cocok secara alami dengan sistem Change Data Capture (CDC) yang melakukan streaming perubahan database, tetapi memaksa query untuk melakukan operasi merge-on-read, memindai file data dan file delete untuk menyaring record yang dihapus.
Perbandingan Mekanisme Delete Iceberg
| Tipe Delete | Mekanisme | Performa Query | Kompatibilitas CDC | Kompleksitas Write |
|---|---|---|---|---|
| Position Deletes | Path file + nomor baris | Tinggi (dapat melewati baris) | Buruk (memerlukan pencarian lokasi) | Tinggi (membutuhkan lokasi fisik) |
| Equality Deletes | Pencocokan primary key | Lebih rendah (memerlukan merge-on-read) | Sangat baik (cocok secara alami) | Rendah (langsung dari stream CDC ) |
Pushback Komunitas terhadap Asumsi Arsitektur
Komunitas teknis telah mengajukan pertanyaan signifikan tentang pilihan arsitektur yang mendasari. Seorang pengembang menunjukkan solusi yang tampaknya jelas yang sepertinya diabaikan oleh industri: mempertahankan pemetaan antara baris Postgres dan posisi Iceberg . Karena proses CDC sudah perlu mempertahankan state, mengapa tidak menyimpan seluruh pemetaan? Ukurannya akan sebanding dengan satu indeks database, dan pembaruan akan lebih cepat daripada tabel Postgres sumber.
Pemetaan yang dibutuhkan akan berukuran sekitar satu indeks pada tabel. Mengapa tidak menyimpannya di suatu tempat? Pembaruan terhadapnya akan lebih cepat daripada pembaruan ke tabel Postgres sumber, jadi akan bisa mengikuti.
Mempertanyakan Pendekatan Fundamental
Beberapa ahli berpendapat bahwa seluruh pipeline Postgres -ke- Iceberg merepresentasikan keputusan arsitektur yang cacat. Mereka berpendapat bahwa menggunakan CDC untuk membuat ulang snapshot tabel dengan mengimplementasikan ulang logika merge-on-read di luar database melewatkan poin dari apa yang dirancang untuk CDC . CDC unggul dalam menangkap dan memproses perubahan individual secara terisolasi, bukan dalam mempertahankan replika tabel yang lengkap.
Kritik meluas ke pilihan Iceberg itu sendiri untuk kasus penggunaan ini. Sebagai sistem penyimpanan kolumnar yang dioptimalkan untuk analitik historis skala besar, Iceberg tidak dirancang untuk data relasional atau operasi real-time. Kritikus menyarankan bahwa database time-series seperti TimescaleDB atau InfluxDB akan lebih tepat untuk workload ini.
Pertanyaan Kematangan dan Realitas Implementasi
Diskusi juga telah menyoroti kekhawatiran tentang klaim kematangan Apache Iceberg . Meskipun implementasi Java telah ada selama bertahun-tahun, library bahasa lain tertinggal secara signifikan. Library Rust baru-baru ini memperoleh kemampuan write, dan karena tidak ada server Iceberg pusat, library ini pada dasarnya merupakan seluruh produk ketika berinteraksi dengan sistem penyimpanan seperti Amazon S3 .
Dukungan query engine untuk equality delete tetap tidak konsisten di seluruh ekosistem. Sementara beberapa engine menyediakan dukungan Iceberg penuh melalui integrasi native, yang lain bergantung pada katalog eksternal seperti AWS Glue dan mungkin hanya mendukung position delete atau tidak memiliki penanganan file delete yang dapat diandalkan sama sekali.
Status Dukungan Query Engine
Dukungan Iceberg Penuh:
- Implementasi Iceberg native dengan penanganan metadata yang lengkap
- Dukungan untuk position dan equality deletes
Dukungan Terbatas:
- Engine berbasis katalog eksternal (contoh: AWS Glue )
- Mungkin hanya mendukung position deletes
- Penanganan delete file yang tidak konsisten
Tidak Ada Dukungan:
- Amazon Redshift (tidak dapat menulis, tidak ada dukungan delete file)
- Berbagai vendor data lake dengan implementasi yang tidak lengkap
Pola yang Lebih Luas
Tantangan teknis ini mencerminkan tren yang lebih besar di dunia infrastruktur data. Perusahaan mencoba menjembatani kesenjangan antara database transaksional tradisional dan sistem analitik modern, sering menemukan bahwa titik integrasi lebih kompleks daripada yang diantisipasi awalnya. Masalah equality delete di Iceberg berfungsi sebagai pengingat bahwa bahkan teknologi yang tampak matang dapat memiliki keterbatasan fundamental ketika diterapkan pada kasus penggunaan yang tidak dirancang untuk ditangani pada awalnya.
Perdebatan yang sedang berlangsung menunjukkan bahwa meskipun Apache Iceberg terus mendapatkan adopsi, komunitas masih mengerjakan tantangan praktis implementasi dunia nyata, terutama ketika menyangkut skenario integrasi data real-time.