Suốt một thập kỷ, các kiến trúc sư dữ liệu phải lựa chọn giữa hai cực: Data Lake (rẻ, linh hoạt, nhưng thiếu transaction và schema) hoặc Data Warehouse (mạnh về truy vấn nhưng đắt và đóng). Mỗi lần chọn lake là chấp nhận viết lại logic nhiều lần. Mỗi lần chọn warehouse là cam kết khoá vào một vendor.
Lakehouse ra đời để xoá bỏ lựa chọn nhị nguyên đó. Và trong cuộc đua giữa các table format, Apache Iceberg đã vượt lên dẫn đầu — được Netflix, Apple, LinkedIn, Stripe, Airbnb và hầu hết các cloud provider lớn áp dụng. Bài viết này tổng hợp kinh nghiệm Nocalab triển khai Iceberg cho 7 doanh nghiệp Việt Nam trong 18 tháng qua.
Vì sao Iceberg, không phải Delta hay Hudi?
Cả ba đều giải quyết cùng bài toán cốt lõi: đem ACID, time-travel, schema evolution lên object storage. Nhưng có ba điểm khác biệt khiến Iceberg trở thành lựa chọn an toàn cho 2026:
- Trung lập engine: Iceberg không thuộc về Databricks (Delta) hay Uber (Hudi). Nó được hỗ trợ first-class bởi Spark, Trino, Flink, Snowflake, BigQuery, DuckDB, ClickHouse — bạn không bị khoá.
- Hidden partitioning: người dùng truy vấn không cần biết partition scheme. Khi thay đổi partition (ví dụ từ ngày sang giờ), không cần rewrite dữ liệu cũ — Iceberg quản lý qua metadata.
- Branching và tagging như Git: kể từ v2, Iceberg hỗ trợ tạo branch để thử nghiệm transformation, tag để snapshot version chính thức. Đây là tính năng game-changing cho data team làm việc giống dev team.
Kiến trúc Lakehouse trên Iceberg: 4 lớp
Một Lakehouse production-ready không chỉ là "đặt Iceberg lên S3". Nó là một stack 4 lớp, mỗi lớp có lựa chọn công nghệ riêng:
Storage Layer — Object storage giữ Parquet files. Trên cloud: S3, GCS, Azure Blob. On-prem: MinIO hoặc Ceph. Lựa chọn ít rủi ro nhất.
Table Format Layer — Iceberg quản lý metadata: snapshot, manifest, partition spec. Đây là lớp "biến file thành bảng".
Catalog Layer — Quản lý metadata tập trung. Lựa chọn 2026: Apache Polaris (mới ra mắt, được Snowflake hậu thuẫn), Nessie (Git-like, mạnh cho data versioning), AWS Glue (đơn giản nếu đã trên AWS), hoặc REST Catalog tự host.
Compute Layer — Engine chạy query. Spark cho ETL nặng, Trino cho ad-hoc analytics, Flink cho streaming, DuckDB cho local exploration. Tất cả đọc cùng một bảng Iceberg.
Pipeline tham chiếu: Bronze → Silver → Gold
Mô hình medallion vẫn là cách tổ chức dữ liệu hiệu quả nhất chúng tôi từng thấy, đặc biệt khi áp dụng trên Iceberg.
Bronze (Raw): ingest dữ liệu nguyên bản từ nguồn — Kafka, CDC từ database, file dump. Mỗi record có metadata về nguồn, thời điểm, partition theo ingest time. Không transform, chỉ lưu trung thực.
Silver (Cleansed): chuẩn hoá schema, deduplicate, áp dụng data quality rules. Đây là nơi xử lý slowly changing dimensions (SCD2) — Iceberg MERGE INTO làm việc này gọn hơn rất nhiều so với Hive.
Gold (Business): aggregations, denormalized tables phục vụ BI và ML. Partition theo business dimensions (region, product category) thay vì ingest time.
-- Tạo bảng Iceberg với hidden partitioning trong Trino
CREATE TABLE silver.orders (
order_id BIGINT,
customer_id BIGINT,
order_date TIMESTAMP(6),
amount DECIMAL(18,2),
status VARCHAR
)
WITH (
format = 'PARQUET',
partitioning = ARRAY['day(order_date)'],
sorted_by = ARRAY['customer_id']
);
-- MERGE để xử lý CDC từ Bronze
MERGE INTO silver.orders AS t
USING bronze.orders_cdc AS s
ON t.order_id = s.order_id
WHEN MATCHED AND s._op = 'D' THEN DELETE
WHEN MATCHED THEN UPDATE SET
status = s.status, amount = s.amount
WHEN NOT MATCHED THEN INSERT VALUES
(s.order_id, s.customer_id, s.order_date, s.amount, s.status);Bảy bài học từ thực tế triển khai
- Compaction là không thể thiếu: streaming ingest tạo ra hàng triệu file nhỏ. Schedule rewrite_data_files mỗi giờ, nếu không query sẽ chậm dần đều.
- Snapshot expiration cần policy rõ ràng: time-travel quá xa nghĩa là giữ rất nhiều file. Mặc định 7 ngày là điểm cân bằng tốt cho hầu hết workload.
- Đừng partition quá mịn: partition theo giờ cho bảng 100GB/ngày là OK. Partition theo phút sẽ tạo small file problem nghiêm trọng.
- Sorted_by quan trọng hơn bạn nghĩ: với truy vấn theo customer_id, bảng được sort sẽ nhanh hơn 10–50 lần nhờ data skipping.
- Catalog là single point of failure: backup metadata catalog như backup database. Nessie/Polaris đều hỗ trợ HA — dùng đi.
- Schema evolution dễ lạm dụng: chỉ vì bạn có thể add/drop column dễ dàng không có nghĩa là nên làm thường xuyên. Vẫn cần data contract giữa producer và consumer.
- Cost monitoring từ ngày đầu: object storage rẻ, nhưng request charges (LIST, GET) có thể đốt tiền nếu engine config sai. Monitor S3 cost theo prefix, không chỉ tổng.
Khi nào KHÔNG nên dùng Lakehouse?
Không phải workload nào cũng phù hợp. Hai trường hợp Nocalab thường khuyên khách hàng giữ kiến trúc cũ:
Workload OLTP-heavy với latency dưới 100ms: Lakehouse không thay thế Postgres hay MySQL. Object storage có latency cố hữu, không phù hợp serving real-time.
Khối lượng dữ liệu nhỏ (<1TB) và đội ngũ <3 data engineer: chi phí vận hành (Spark cluster, catalog, monitoring) có thể vượt giá trị mang lại. Snowflake hay BigQuery managed có thể rẻ và đơn giản hơn.
Lộ trình áp dụng cho doanh nghiệp Việt Nam
Nocalab khuyến nghị lộ trình 6 tháng để chuyển đổi từ data warehouse truyền thống hoặc data lake legacy sang Lakehouse trên Iceberg:
Tháng 1–2: Chọn 1 domain dữ liệu pilot (ví dụ: orders + customers). Dựng MinIO + Trino + Polaris. Migrate dữ liệu lịch sử, đo hiệu năng so với hệ thống cũ.
Tháng 3–4: Mở rộng sang 3–5 domain. Triển khai pipeline Bronze→Silver→Gold với Spark + Airflow. Setup observability với DataHub hoặc OpenMetadata.
Tháng 5–6: Chuyển workload BI (Metabase, Superset) sang đọc trực tiếp từ Iceberg qua Trino. Decommission data warehouse cũ cho các use-case đã migrate.
Sau 6 tháng, doanh nghiệp có thể giảm 40–60% chi phí lưu trữ, giảm 30% thời gian phát triển pipeline mới, và quan trọng nhất là sẵn sàng cho AI/ML workload mà không cần copy dữ liệu lần nữa.
