Arsitektur Data Lakehouse di Indonesia 2026: Adopsi Apache Iceberg, Delta Lake, dan Hudi di Perbankan & Fintech

Tahun 2026 menandai titik balik (inflection point) bagi arsitektur data modern di Indonesia. Paksaan regulasi UU PDP (Undang-Undang Perlindungan Data Pribadi) yang mulai diberlakukan penuh, serta mandat data sovereignty dari Bank Indonesia dan OJK, mendorong institusi finansial meninggalkan arsitektur data warehouse tradisional (Teradata, Oracle Exadata) serta data lake generasi pertama (HDFS, Hive) yang rapuh dan mahal operasional. Solusi konvergen yang dipilih: Data Lakehouse berbasis format tabel terbuka (open table formats) — Apache Iceberg, Delta Lake, Apache Hudi — yang berjalan di atas object storage S3-compatible (MinIO, Ceph RGW, Cloudian, AWS S3, Google Cloud Storage).

Mengapa Lakehouse, Mengapa 2026?

Arsitektur Lambda (batch + streaming terpisah) dan Kappa (streaming-only) sering menciptakan data silo, latensi tinggi, dan biaya komputasi ganda. Lakehouse menggabungkan kelebihan data lake (biaya rendah, format terbuka, schema-on-read) dengan data warehouse (ACID, time-travel, schema evolution, SQL performant). Tiga format tabel terbuka utama — Iceberg, Delta Lake, Hudi — kini production-ready di skala petabyte di Bank BRI, BNI, Bank Mandiri, serta fintech unicorn seperti GoTo Financial, DANA, dan Akulaku.

Pendorong kunci 2026:

• UU PDP Pasal 15-16: Wajib data localization dan data portability. Format tabel terbuka memastikan data tidak vendor lock-in — bisa dipindah antar cloud/on-prem tanpa migrasi ulang.
• AI/ML Workload: Feature store dan training dataset membutuhkan time-travel (reproduktibilitas model) dan schema evolution (iterasi cepat fitur). Iceberg time-travel dan Delta Lake CDF (Change Data Feed) jadi standar de facto.
• Cost Optimization: Object storage (HDD/SSD tiering) 5-10x lebih murah vs block storage appliance proprietary. BUMN perbankan migrasi ke software-defined storage (Ceph, MinIO Enterprise) di private cloud souveren.

Peta Adopsi: Iceberg vs Delta Lake vs Hudi di Indonesia

Pemilihan format bukan one-size-fits-all. Berikut pola adopsi nyata di sektor finansial Indonesia Q1-Q2 2026:

Insight Praktis: BRI memilih Iceberg + Trino untuk federated query lintas data domain (core banking, digital, syariah) tanpa memindahkan data. BNI adopt Delta Lake + Databricks untuk ML feature store terpusat. BCA gunakan Hudi + Flink CDC untuk real-time fraud detection sub-second latency. Tidak ada "pemenang absolut" — pilih berdasarkan workload dominan (OLAP vs Streaming vs ML).

Arsitektur Referensi: Lakehouse di Private Cloud Soberan

Berikut pola arsitektur yang diterapkan konsorsium BUMN perbankan (koordinasi BSSN & Kominfo) untuk memenuhi data residency:

┌─────────────────────────────────────────────────────────────────┐
│                    PRIVATE CLOUD SOVERAN (INDONESIA)            │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────┐  │
│  │  SOURCE      │  │  INGESTION   │  │  LAKEHOUSE STORAGE   │  │
│  │  ────────────│──│  ────────────│──│  ────────────────────│  │
│  │ Core Banking │  │ Kafka/       │  │ MinIO / Ceph RGW     │  │
│  │ (CDC:        │  │ Flink CDC    │  │ (S3 API, Erasure    │  │
│  │  Debezium/   │  │ / Spark      │  │  Coding, Multi-site │  │
│  │  GoldenGate) │  │ Structured   │  │  Replication)       │  │
│  │ Digital Ch.  │  │ Streaming)   │  │                      │  │
│  │ Fintech API  │  │              │  │  Format: Iceberg/    │  │
│  └──────────────┘  └──────────────┘  │  Delta/Hudi          │  │
│         │                │           └──────────┬───────────┘  │
│         ▼                ▼                      │              │
│  ┌──────────────────────────────────────────────▼──────────┐  │
│  │              CATALOG & GOVERNANCE LAYER                  │  │
│  │  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌────────────┐  │  │
│  │  │ Nessie  │  │ Unity   │  │ Apache  │  │ DataHub /  │  │  │
│  │  │ /       │  │ Catalog │  │ Gravitino│  │ Amundsen   │  │  │
│  │  │ Polaris │  │ (Delta) │  │ (Multi-  │  │ (Data      │  │  │
│  │  │ (Iceberg)           │  │  Format) │  │  Catalog &  │  │  │
│  │  └─────────┘  └─────────┘  └─────────┘  │  Lineage)  │  │  │
│  │                                         └────────────┘  │  │
│  └─────────────────────────────────────────────────────────┘  │
│                            │                                  │
│         ┌──────────────────┼──────────────────┐               │
│         ▼                  ▼                  ▼               │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐       │
│  │  QUERY/      │  │  STREAMING   │  │  ML/AI       │       │
│  │  COMPUTE     │  │  COMPUTE     │  │  WORKLOAD    │       │
│  │  ────────────│  │  ────────────│  │  ────────────│       │
│  │  Trino/      │  │  Flink SQL   │  │  Spark ML,   │       │
│  │  StarRocks   │  │  / RisingWave│  │  Ray,        │       │
│  │  / Doris     │  │              │  │  Feast       │       │
│  │  (OLAP)      │  │  (CDC/RT)    │  │  (Feature    │       │
│  └──────────────┘  └──────────────┘  │   Store)     │       │
│                                       └──────────────┘       │
└─────────────────────────────────────────────────────────────────┘

Kunci arsitektur:

• Object Storage S3-compatible: MinIO Enterprise (untuk performa SSD/NVMe tier) atau Ceph RGW (untuk kapasitas HDD tiering). Keduanya mendukung multi-site replication untuk disaster recovery antar data center Jakarta-Surabaya-Batam.
• Catalog Multi-Format: Apache Gravitino (incubating) atau Polaris (Incubating) dipilih untuk unified catalog mengelola Iceberg, Delta, Hudi sekaligus — menghindari catalog silo.
• Compute-Separated-Storage: Engine query (Trino, StarRocks, Doris) dan streaming (Flink, RisingWave) stateless, skalir horizontal independen dari storage.
• Governance & Lineage: DataHub/Amundsen untuk data discovery, column-level lineage, dan PII tagging otomatis (compliance UU PDP Pasal 15).

Tantangan Implementasi Nyata & Solusi

1. Small Files Problem pada Streaming Ingestion

Flink CDC / Spark Structured Streaming menghasilkan ribuan file kecil (< 128 MB) per jam. Solusi: compaction async via Spark job terjadwal (Iceberg rewriteDataFiles, Delta OPTIMIZE, Hudi ClusteringService) + partition pruning berbasis hidden partitioning Iceberg.

# Contoh Iceberg Compaction Job (Spark Structured Streaming)
from pyspark.sql import SparkSession

spark = SparkSession.builder \
    .appName("IcebergCompaction-BRI") \
    .config("spark.sql.catalog.bri", "org.apache.iceberg.spark.SparkCatalog") \
    .config("spark.sql.catalog.bri.type", "hadoop") \
    .config("spark.sql.catalog.bri.warehouse", "s3a://bri-lakehouse/warehouse") \
    .getOrCreate()

# Compaction harian untuk tabel transaksi
table = spark.sql("SELECT * FROM bri.core_banking.transactions")
# Rewrite file kecil jadi target 512 MB
table.rewriteDataFiles()
  .option("target-file-size-bytes", 536870912)  # 512 MB
  .option("min-input-files", 20)
  .execute()

2. Schema Evolution & Data Contract

Tim data engineering & producer (core banking, mobile apps) harus sepakati data contract. Iceberg schema evolution aman (add column, rename, reorder, drop) tapi type widening (int → long, float → double) butuh koordinasi. Pola terbaik: contract-first dengan Protobuf/Avro schema registry (Confluent Schema Registry / Apicurio) + validasi CI/CD sebelum deploy producer.

3. Multi-Tenancy & Resource Isolation

Di shared lakehouse BUMN, domain core banking, digital, syariah, risk butuh isolasi komputasi & quota storage. Solusi: Trino/StarRocks resource groups + MinIO bucket quota + Ranger/Apache Polaris row/column-level security.

4. Cost Observability & Chargeback

Biaya object storage + komputasi elastis butuh chargeback model per domain. Tooling: OpenCost + Trino Query Cost Model + MinIO Prometheus Exporter untuk per-query/per-domain cost attribution.

Roadmap 2026 H2 – 2027: Lakehouse Native AI & Interoperabilitas

Fase selanjutnya yang sudah dipilotkan Bank Mandiri & BRI Q3 2026:

• Iceberg REST Catalog + Apache Arrow Flight SQL untuk zero-copy akses dari Python/Rust/Go ML pipeline tanpa Spark overhead.
• Delta Lake Uniform (UniForm): Satu tabel, baca sebagai Iceberg, Delta, Hudi simultan — menghilangkan format lock-in antar tim.
• Apache XTable (incubating): Translasi metadata antar format tabel real-time.
• Lakehouse GPU-Accelerated: StarRocks/Doris + NVIDIA RAPIDS untuk feature engineering skala petabyte di GPU cluster (H100/H200 sovereign DC).
• Data Mesh Federation: Setiap domain (core banking, digital, risk) punya data product sendiri (Iceberg table + contract + SLA), difederasi via Gravitino/Polaris.

Kesimpulan: Adopsi Lakehouse di Indonesia 2026 bukan sekadar migrasi teknologi — tapi respons strategis terhadap kedaulatan data, efisiensi biaya infrastructure, dan kebutuhan AI/ML skala enterprise. Pilih format tabel berdasarkan workload dominan, investasi pada catalog terpadu multi-format, dan bangun data contract culture sejak hari pertama. BUMN perbankan yang sudah production (BRI, BNI, Mandiri, BCA) membuktikan: arsitektur terbuka, composable, dan vendor-neutral adalah fondasi data sovereign Indonesia kedepan.

Penulis: Moch Aziz — Tech Journalist, fokus arsitektur data, cloud native, & regulasi digital Indonesia. Artikel ini sintetisis dari wawancara CTO/Head of Data Engineering BRI, BNI, Mandiri, BCA, GoTo Financial, DANA (Q1-Q2 2026), serta dokumen arsitektur referensi BSSN/Kominfo.