🚩 Problem Statement
Pada skala lakehouse besar, partisi dan statistik kolom saja tidak cukup untuk menjawab query kompleks. Banyak query membutuhkan pencocokan tepat (equality), filter dengan transformasi ekspresi, serta proses indexing yang tidak mengganggu operasi baca/tulis. Hudi perlu menyediakan indexing yang cepat, fleksibel, dan aman untuk sistem yang aktif terus-menerus.
🛠️ Methodologi / Solusi
1️⃣ Record Index & Secondary Index → memetakan kunci dan kolom non-kunci ke lokasi file secara langsung untuk menghindari full-scan.
2️⃣ Expression Index → mengakselerasi query yang menggunakan transformasi (substring, from_unixtime) dengan memanfaatkan bloom filter & column stats.
3️⃣ Async Indexing → pembangunan indeks berjalan di background tanpa memblokir read/write, didukung commit-protocol dan conflict-resolution.
4️⃣ Hierarki indeks (file stats → partition → record → expression) untuk melayani berbagai pola query di skala besar.
📊 Findings / Results
1️⃣ Tabel 400 GB (~20.000 file group): query id='001' turun dari 977 detik → 12 detik (~98% lebih cepat) saat record index diaktifkan.
2️⃣ Benchmark TPC-DS: secondary index mempercepat query ~45% dan mengurangi data yang dipindai hingga ~90%.
3️⃣ Async indexing memungkinkan pembuatan indeks besar tanpa downtime, meningkatkan stabilitas operasional.
4️⃣ Kombinasi indeks membuat lakehouse mendekati performa database OLTP untuk pola-pola filter tertentu.
📌 Key Takeaways
1️⃣ Gunakan record/secondary/expression index untuk query yang sering melakukan filter tepat atau transformasi kolom.
2️⃣ Indeks = kecepatan, tapi ada biaya: storage & komputasi jadi lebih besar → pilih kolom penting saja.
3️⃣ Lakehouse modern bisa sangat cepat bila indeksnya dirancang matang — bukan mengandalkan partisi saja.
4️⃣ Rancang indexing sejak awal; menambahkannya setelah sistem tumbuh besar jauh lebih mahal.
Sumber:
https://hudi.apache.org/blog/2025/11/12/deep-dive-into-hudis-indexing-subsystem-part-2-of-2/
#ApacheHudi #DataLakehouse #Indexing #BigData #ETL #DataEngineering