Format tabel Iceberg, ide bagus - spesifikasi yang didefinisikan dengan keliru - Bagian 2 dari 2

Masalah pada spesifikasi Iceberg

• Masalah serius pada spesifikasi Iceberg: spesifikasi Iceberg bukan upaya yang sungguh-sungguh untuk menyelesaikan masalah metadata pada data lake skala besar.
• Pelajaran dari sejarah: pada bagian pertama, penulis kembali ke sejarah untuk mempelajari pelajaran masa lalu, dan memperkenalkan "masalah manajemen ruang" yang harus diselesaikan oleh database.
  • Elemen masalah:
    1. Fragmentasi ruang
    2. Kontrol konkurensi berbutir halus
    3. Atomisitas untuk banyak objek
    4. Ketidakcocokan impedansi antara baris dan file
    5. Akses metadata dengan latensi rendah dan throughput tinggi
• Pentingnya format terbuka: penulis 100% mendukung penggunaan format terbuka di seluruh stack, dan khususnya antusias terhadap penggunaan Parquet sebagai format penyimpanan bersama untuk data terstruktur berbentuk tabel.
• Perbedaan file Parquet dan tabel database: sekumpulan file Parquet tidak otomatis menjadi tabel database. Tabel database lebih dari sekadar kumpulan baris.

Ringkasan masalah metadata

• Masalah manajemen ruang: kembali ditekankan berbagai masalah yang harus diselesaikan oleh database.
• Kebutuhan metadata: agar banyak file Parquet dapat terlihat seperti tabel database, metadata berikut dibutuhkan:
  1. Daftar lokasi semua file yang membentuk tabel
  2. Metadata kasar untuk tiap file
  3. Mekanisme kontrol transaksi untuk menambah atau menghapus file
  4. Cara untuk mengembangkan skema tabel
• Menemukan lokasi file: untuk memperlakukan sekumpulan file Parquet sebagai satu tabel, dibutuhkan mekanisme untuk menemukan file-file tersebut.
• Pentingnya metadata: tiap file membutuhkan metadata tambahan agar baris yang relevan bisa ditemukan dengan cepat.

File Parquet dan tabel database

• Definisi file Parquet: Parquet menyediakan format data tabular yang self-describing.
• Definisi tabel database: tabel database bukan sekadar kumpulan baris, tetapi memerlukan berbagai metadata dan kontrol transaksi.
• Syarat agar file Parquet bisa digunakan seperti tabel:
  1. Daftar lokasi file
  2. Metadata setiap file
  3. Mekanisme kontrol transaksi untuk penambahan dan penghapusan file
  4. Cara evolusi skema tabel
• Perbedaan file dan tabel: hanya karena file-file Parquet memiliki tata letak kolom yang sama, itu tidak berarti tampil sebagai tabel database.

File manifest dan daftar manifest

• Proses penambahan data: agar klien Iceberg dapat menambahkan data ke tabel, langkah berikut harus dilalui:
  1. Menulis satu atau lebih file Parquet ke lokasi tertentu (misalnya S3).
  2. Menulis file manifest yang menunjuk ke file yang ditulis pada langkah 1.
  3. Menulis daftar manifest yang baru.
• Format file manifest: file manifest dan daftar manifest menggunakan format AVRO, yang terkompresi dan self-describing.
• Isi file manifest: file manifest berisi pointer ke file Parquet dan metadata untuk setiap kolom.
• Masalah ukuran metadata: menyimpan metadata dengan cara ini membuat ukurannya lebih besar dari yang diperlukan, dan tidak bisa dikompresi dengan mengenali nilai string umum di antara file-file.

Beban yang meningkat pada klien

• Tanggung jawab klien: di seluruh spesifikasi Iceberg, klien harus melakukan pencatatan administratif dalam jumlah besar hanya untuk perubahan sederhana.
• Masalah akurasi metadata: jika klien menulis sebagian secara salah, commit snapshot baru harus diperiksa secara menyeluruh untuk memastikan data manifest telah ditulis dengan benar.
• Masalah keamanan: karena klien harus menulis daftar manifest yang menunjuk ke semua file manifest, lokasi semua file S3 menjadi terekspos.
• Pentingnya keamanan data: karena nilai data sangat tinggi, patut dipertanyakan mengapa spesifikasi ini tidak menempatkan keamanan sebagai prioritas utama.

Kelemahan keamanan tingkat baris

• Kebutuhan keamanan tingkat baris: bahkan di negara yang regulasinya longgar seperti Amerika Serikat, keamanan tingkat baris diperlukan untuk melindungi data sensitif.
• GDPR di Uni Eropa: di Eropa, undang-undang seperti GDPR menuntut sensitivitas yang lebih tinggi terhadap akses data.
• Masalah akses data oleh klien: klien dapat menambahkan data ke tabel, tetapi tidak bisa membatasi akses ke data yang sudah ada.
• Seriusnya masalah keamanan: alasan spesifikasi ini tidak memprioritaskan keamanan seharusnya menimbulkan pertanyaan tentang nilai informasi data lake.

Peran file metadata

• Penulisan file metadata: setelah klien menulis file Parquet, ia harus membuat file manifest terkait, membaca daftar manifest yang ada, membuat daftar manifest baru, lalu melakukan commit data.
• Proses commit: commit dilakukan dengan menulis file metadata (<prefix>.metadata.json).
• Pemilihan format JSON: alasan file metadata menggunakan format JSON tidak jelas, dan memberi kesan "desain oleh komite".
• Pengulangan metadata: file metadata mencantumkan semua snapshot, sehingga ruang terbuang karena pengulangan informasi.

Kompleksitas proses commit

• Masalah atomisitas: file metadata baru harus dijadikan file terbaru dan menggantikan file metadata sebelumnya secara atomik.
• Kompleksitas prosedur commit: untuk melakukan commit versi metadata baru V+1, langkah berikut perlu dilakukan:
  1. Membuat file metadata tabel baru berdasarkan metadata saat ini.
  2. Menulis metadata tabel baru ke file unik yang baru.
  3. Meminta metastore mengganti pointer metadata tabel dari V ke V+1.
• Penanganan saat swap gagal: jika swap gagal, berarti penulis lain sudah lebih dulu membuat V+1, sehingga klien harus kembali ke langkah 1.
• Masalah race condition: ketika klien saling bersaing, mereka harus membaca ulang file metadata yang ditulis klien sebelumnya, lalu membuat ulang daftar manifest dan file metadata.

Masalah pada optimistic concurrency control

• Fakta tentang konkurensi: jika persaingan atas sumber daya tidak diharapkan, jenis mekanisme konkurensi apa pun tidak terlalu penting.
• Saat persaingan diperkirakan terjadi: jika dua klien mencoba mengubah nilai yang sama, mekanisme penguncian perlu digunakan.
• Batasan optimistic concurrency control: di Iceberg, dua penulisan serentak akan selalu bertabrakan, dan itu akibat cara spesifikasi ini dirancang.
• Semantik penguncian terburuk: spesifikasi ini menggunakan semantik penguncian terburuk untuk metadata, padahal jika hanya ingin menambah data, koordinasi antar klien seharusnya tidak diperlukan.

Batasan swap metadata

• Sentralisasi metadata: dengan memusatkan metadata tabel ke satu file, tercipta satu titik kontensi untuk semua penulisan.
• Beban klien saat retry: jika klien gagal, ia harus membaca data yang ditulis klien sebelumnya, lalu membuat ulang daftar manifest dan file metadata.
• Kecepatan swap metadata: layanan yang melakukan swap metadata harus menangani retry, yang menyebabkan penurunan performa.
• Jumlah commit yang terbatas: karena implementasi konkurensi yang sederhana, jumlah commit menjadi terbatas oleh waktu yang diperlukan untuk penggantian atomik file metadata.

Kebutuhan akan database

• Menemukan lokasi file metadata: snapshot tabel Iceberg sepenuhnya dijelaskan oleh file metadata.json.
• Kontradiksi gagasan: Iceberg mencoba menentukan format metadata hanya dengan file, tetapi pada akhirnya tetap membutuhkan database.
• Keunggulan database: database modern mampu menangani ratusan ribu penulisan dan dapat diskalakan secara terdistribusi.
• Perbandingan file system dan database: menyimpan metadata di database lebih efisien daripada menyimpannya dalam file.

Fragmentasi dan pembengkakan metadata

• Pertumbuhan file metadata.json: file metadata.json menunjuk ke snapshot terbaru, dan setiap file metadata memiliki pointer balik ke snapshot sebelumnya.
• Kenaikan metadata yang terus-menerus: metadata terus bertambah, yang berdampak negatif pada performa data lake.
• Perlunya pembersihan metadata berkala: jika data terus ditambahkan ke data lake, metadata perlu dibersihkan.
• Biaya permintaan HTTP: proses penghapusan file metadata menimbulkan permintaan HTTP, yang dapat menambah biaya.

Pembacaan data dan perencanaan kueri

• Peran file manifest: file manifest memuat metadata tentang file Parquet.
• Kompleksitas perencanaan kueri: untuk menjalankan kueri, daftar manifest dan file manifest harus dibaca secara berurutan.
• Masalah biaya: pembacaan dari S3 menimbulkan biaya, dan ini memengaruhi kecepatan eksekusi kueri.
• Masalah fragmentasi metadata: jika metadata terfragmentasi, perencanaan kueri menjadi rumit dan akses data menjadi lebih sulit.

Caching dan sulitnya perencanaan kueri

• Caching manifest: manifest bisa di-cache, tetapi ini tidak efisien karena ukuran metadata terus membesar.
• Menjaga validitas cache: harus dipastikan bahwa cache tetap mutakhir, dan ini menambah biaya serta kompleksitas.
• Beban pada klien: semua klien harus meng-cache metadata, yang memicu jutaan permintaan HTTP.
• Meningkatnya kompleksitas: penggunaan data lake menjadi semakin kompleks, sehingga diperlukan solusi tambahan untuk mengatasinya.

Kesimpulan dari gagasan ini

• Kritik terhadap gagasan ini: spesifikasi Iceberg bukan spesifikasi yang serius untuk metadata data lake dan memuat banyak masalah.
• Ringkasan masalah: Iceberg menambahkan metadata dengan pekerjaan O(n), tidak mampu menangani commit lintas tabel, dan tidak menyelesaikan masalah pembengkakan metadata.
• Batasan skalabilitas: Iceberg tidak cocok untuk scaling dan memindahkan kompleksitas berlebihan ke klien.
• Pertanyaan untuk industri: penulis mengajukan pertanyaan tentang mengapa masalah seperti ini bisa muncul di industri TI.