Apache Iceberg & Open Lakehouse 2026 - Kiến trúc Catalog, Metadata, Time Travel và Query Engines cho Data Platform Production

Posted on: 4/16/2026 7:12:45 AM

1. Mở đầu - Open Lakehouse đã trở thành mặc định của data platform 2026

Trong gần hai thập kỷ, thế giới phân tích dữ liệu bị xé đôi giữa hai trường phái: data warehouse đóng với hiệu năng SQL cực cao nhưng khóa dữ liệu trong một định dạng độc quyền, và data lake mở với chi phí lưu trữ rẻ nhưng thiếu ACID, thiếu schema evolution, thiếu time travel. Bất kỳ đội ngũ nào muốn cả hai đều phải duy trì hai hệ thống song song: một ETL đổ dữ liệu vào warehouse (Snowflake, BigQuery, Redshift) để phục vụ BI, và một ETL khác đổ vào lake (Parquet trên S3) để phục vụ ML và data science. Hai bản sao. Hai chi phí. Hai nguồn sự thật.

Năm 2026 là năm cuối cùng cuộc chiến đó có ý nghĩa. Apache Iceberg - ban đầu chỉ là một format bảng do Netflix tạo ra năm 2017 để giải quyết vấn đề nhất quán trên S3 - đã trở thành lớp bảng chuẩn cho mọi data platform hiện đại. Khi Databricks mua Tabular đầu năm 2024 và hợp nhất hệ thống metadata của Delta Lake với Iceberg, khi Snowflake và BigQuery đều khai báo hỗ trợ Iceberg native với khả năng đọc-ghi hai chiều, khi AWS S3 Tables và Apple FoundationDB-based catalog đều nói "chúng tôi là REST Iceberg Catalog", thì điều từng là một giấc mơ công nghệ đã trở thành một thực tế vận hành: mọi công cụ phân tích lớn đọc cùng một bảng vật lý.

2. Từ data warehouse đến open lakehouse - bản đồ tiến hóa

Để hiểu vì sao Iceberg lại có kiến trúc như hiện tại, cần nhìn lại con đường ba thập kỷ của việc lưu trữ và truy vấn dữ liệu phân tích.

3. Kiến trúc metadata của Iceberg - ba tầng bất biến

Toàn bộ sức mạnh của Iceberg nằm ở một ý tưởng rất đơn giản: không bao giờ sửa file metadata; mỗi thay đổi sinh ra một bộ file mới, rồi đổi một con trỏ nguyên tử duy nhất. Nhờ đó, bảng Iceberg có ACID mà không cần cơ sở dữ liệu quan hệ, có time travel miễn phí, có branching nhẹ như Git, và có thể scale tuyến tính trên object storage vốn chỉ cung cấp put/get/list.

flowchart TB
    Cat[Catalog: con trỏ tới metadata.json hiện tại] --> M0[metadata.json v12]
    M0 --> S1[Snapshot N-1]
    M0 --> S2[Snapshot N]
    S2 --> ML1[manifest-list-N.avro]
    ML1 --> MA1[manifest-a.avro]
    ML1 --> MA2[manifest-b.avro]
    MA1 --> D1[data-file-1.parquet]
    MA1 --> D2[data-file-2.parquet]
    MA2 --> D3[data-file-3.parquet]
    MA2 --> DEL1[delete-file-1.parquet]

Hình 1: Chuỗi phân cấp của Iceberg - catalog chỉ cần cung cấp một swap nguyên tử con trỏ tới metadata.json

Bảng Iceberg được mô tả bởi ba loại file, luôn bất biến sau khi ghi:

• metadata.json - thông tin ở tầng cao nhất của bảng: schema hiện tại và lịch sử schema, partition spec, sort order, danh sách tất cả các snapshot và một con trỏ tới snapshot "current". Mỗi commit sinh ra một file v{n}.metadata.json mới.
• manifest list - mỗi snapshot trỏ tới một manifest list (file Avro). Manifest list chứa danh sách các manifest thuộc snapshot đó, kèm theo thống kê tổng hợp (min/max giá trị phân vùng, số hàng, số file data, số file delete).
• manifest - mỗi manifest (cũng là file Avro) liệt kê các data file và delete file thực sự. Với từng file, nó lưu đường dẫn, kích thước, số record, và - quan trọng nhất - per-column stats min, max, null count, giá trị giới hạn của từng cột partition.

Nhờ per-column stats ở tầng manifest, một query engine có thể cắt bỏ những file không liên quan chỉ bằng cách đọc metadata, không cần mở một byte dữ liệu Parquet nào. Đây là lý do Iceberg nhanh gấp nhiều lần Hive metastore trên cùng một tập file: Hive phải liệt kê thư mục S3 và mở từng Parquet để lấy footer; Iceberg chỉ cần đọc một manifest list và vài manifest đã được pre-aggregated.

4. Catalog - điểm then chốt của kiến trúc open lakehouse

Catalog là thành phần duy nhất trong Iceberg mà bạn bắt buộc phải chọn. Từ 2017 tới 2022, lựa chọn catalog luôn gắn chặt với một thư viện Java cụ thể: Hive metastore, AWS Glue, JDBC, hay Hadoop catalog. Điều đó khóa chặt dữ liệu vào một hệ sinh thái compute. Năm 2022, spec Iceberg REST Catalog ra đời và mọi thứ thay đổi: catalog biến thành một giao thức HTTP, mọi engine chỉ cần nói REST là đọc được cùng một bảng.

Năm 2026, các lựa chọn catalog đáng quan tâm cho một data platform nghiêm túc:

5. Iceberg spec v3 - những gì mới trong 2026

Spec v3 là bản nâng cấp lớn đầu tiên của Iceberg sau v2 (ra đời 2020 khi thêm row-level delete). Nó không chỉ bổ sung tính năng cho query engine mà còn trả lời trực tiếp những giới hạn đã cản trở Iceberg tiếp quản toàn bộ warehouse workload trong ba năm qua.

5.1. Variant type - JSON semi-structured hạng nhất

Trước v3, cột kiểu JSON trong Iceberg chỉ có thể lưu là string. Một query engine như Trino muốn truy cập field bên trong phải parse lại toàn bộ chuỗi trong mỗi query. Spec v3 chuẩn hóa kiểu variant - một biểu diễn nhị phân tự mô tả, có shredding (các field hay dùng được trích ra cột riêng trong Parquet để tận dụng column pruning và zstd dictionary). Đây là chuẩn chia sẻ giữa Iceberg, Delta Lake và Apache Spark.

5.2. Deletion Vectors - thay thế positional delete file

Trong Iceberg v2, xóa một dòng có hai cơ chế: equality delete (lưu giá trị key) và positional delete (lưu cặp file_path + row_position). Positional delete đơn giản nhưng đắt khi có nhiều update cùng lúc, vì mỗi lần phải tạo một file delete mới. Deletion Vectors thay bằng một bitmap Roaring đi kèm từng data file, update tại chỗ về mặt logic nhưng vẫn bất biến về mặt storage - được nén rất hiệu quả và giảm độ phóng đại I/O đáng kể với workload CDC.

5.3. Row lineage - dấu vết thay đổi ở cấp dòng

Mỗi dòng mới được gắn _row_id và _last_updated_sequence_number. Điều này cho phép CDC downstream biết chính xác dòng nào thay đổi giữa hai snapshot mà không cần join toàn bảng. Các engine replicate (Debezium, Flink CDC, Kafka Connect Iceberg Sink) có thể phát event deterministic mà không cần "delta computation" đắt.

5.4. Default value và column promotion sâu hơn

V3 cho phép khai báo giá trị mặc định ở cấp cột, nhờ đó việc thêm cột mới không cần backfill: các dòng cũ khi đọc ra sẽ nhận giá trị mặc định đã khai báo. V3 cũng mở rộng luật column promotion an toàn (int → long, float → double, decimal mở rộng scale), giảm số lần phải rewrite dữ liệu vì lý do schema.

5.5. Geospatial native

Iceberg v3 chính thức có kiểu geometry và geography tương thích với OGC WKB. Các engine như DuckDB spatial, Apache Sedona, PostGIS có thể đọc bảng Iceberg mà không cần gói ngoài.

6. Query engine - ai đang đọc và ghi Iceberg trong 2026

Vẻ đẹp của open lakehouse là bạn có thể chọn engine phù hợp cho từng workload mà không phải di chuyển dữ liệu. Năm 2026, bức tranh query engine quanh Iceberg trông như thế này:

flowchart LR
    subgraph Storage
      S3[(S3 / GCS / ABFS / MinIO)]
    end
    subgraph Catalog
      REST[Iceberg REST Catalog]
    end
    subgraph Engines
      Trino[Trino / Starburst]
      Spark[Apache Spark 4]
      Flink[Apache Flink]
      Duck[DuckDB 1.x]
      CH[ClickHouse]
      SR[StarRocks]
      Dre[Dremio]
      Snow[Snowflake]
      DBX[Databricks]
      BQ[BigQuery]
    end
    REST --- Trino
    REST --- Spark
    REST --- Flink
    REST --- Duck
    REST --- CH
    REST --- SR
    REST --- Dre
    REST --- Snow
    REST --- DBX
    REST --- BQ
    Trino --> S3
    Spark --> S3
    Flink --> S3
    Duck --> S3
    CH --> S3
    SR --> S3
    Dre --> S3
    Snow --> S3
    DBX --> S3
    BQ --> S3

Hình 2: Mọi engine đều đọc cùng một bảng Iceberg qua catalog REST chung - cốt lõi của triết lý open lakehouse

• Trino / Starburst - engine SQL phân tán tiêu chuẩn cho ad-hoc và BI. Hỗ trợ Iceberg gần như hoàn chỉnh, kể cả CTAS, MERGE, time travel, table procedures (expire snapshots, rewrite data files, rewrite manifests).
• Apache Spark 4 - Runtime batch/ETL chủ lực. Iceberg ra đời để phục vụ Spark, và vẫn có API gốc phong phú nhất. Thích hợp cho các job rewrite lớn, backfill, ML feature engineering.
• Apache Flink - Streaming ingestion. Flink Iceberg connector hỗ trợ upsert, exactly-once và Iceberg v3 row lineage, biến Iceberg thành đích của Kafka/Pulsar ở quy mô production.
• DuckDB 1.x - Engine analytics trong tiến trình (embedded). Cho phép đọc Iceberg trực tiếp từ máy cá nhân, từ notebook, từ Lambda, hay ngay bên trong một service Go/Rust bằng extension. Cực kỳ phù hợp cho interactive exploration ở quy mô TB.
• ClickHouse - Engine OLAP nổi tiếng về latency, hỗ trợ Iceberg qua bảng function và database engine Iceberg. Rất hợp cho dashboard truy vấn real-time trên bảng Iceberg vừa được Flink nạp.
• StarRocks - Engine MPP cho BI tương tác, có external catalog Iceberg, cache metadata cục bộ để đạt độ trễ dưới 1 giây trên bảng nhiều tỷ dòng.
• Dremio - Tập trung vào self-service BI, semantic layer và reflection cache đặt trên nền Iceberg. Tích hợp tự nhiên với Nessie.
• Snowflake, BigQuery, Databricks - Ba warehouse lớn đều hỗ trợ Iceberg native với mức độ khác nhau: đọc-ghi hai chiều, external table, hoặc managed table. Điểm quan trọng là cùng một file trên S3 có thể phục vụ cả ba, tùy chọn engine nào phù hợp workload.

7. Time travel, branching và tag - Git semantics cho dữ liệu

Một trong những tính năng làm Iceberg thay đổi cách vận hành pipeline là nó biến bảng thành một DAG snapshot. Mỗi commit thành công sinh một snapshot bất biến. Con trỏ "current" chỉ là nhãn, và bạn có thể tạo bao nhiêu nhãn cũng được.

Với Iceberg, các khái niệm sau là công dân hạng nhất:

• Time travel - truy vấn bảng tại một thời điểm quá khứ: SELECT * FROM orders FOR VERSION AS OF 938251 ... hoặc FOR TIMESTAMP AS OF '2026-04-10 00:00:00'.
• Tag - đặt tên cố định cho một snapshot (ví dụ release-2026-Q1). Tag không bao giờ di chuyển, dùng để đóng băng dữ liệu cho report pháp lý, audit, kiểm toán.
• Branch - con trỏ có thể di chuyển, thừa kế từ một snapshot gốc. Một nhánh "experiment" có thể nhận write riêng cho đến khi review xong rồi merge ngược lại main.
• Rollback - nếu một ETL vừa ghi đè sai dữ liệu, một lệnh CALL rollback_to_snapshot có thể đưa bảng về trạng thái trước đó trong vài mili giây - không cần khôi phục backup.

-- Tạo nhánh thử nghiệm để chạy ETL mới
ALTER TABLE sales.orders CREATE BRANCH experiment_q1_fix
  AS OF VERSION 923112;

-- Chạy ETL chỉ trên nhánh
INSERT INTO sales.orders.`branch_experiment_q1_fix`
  SELECT * FROM staging.orders_fixed;

-- Review kết quả bằng time travel ngược
SELECT COUNT(*)
FROM sales.orders.`branch_experiment_q1_fix`
MINUS
SELECT COUNT(*) FROM sales.orders;

-- Merge vào main hoặc hủy nhánh
ALTER TABLE sales.orders REPLACE BRANCH main
  WITH `branch_experiment_q1_fix`;
-- hoặc
ALTER TABLE sales.orders DROP BRANCH experiment_q1_fix;

8. Compaction và bảo trì - phần ít được nói nhất nhưng quan trọng nhất

Một bảng Iceberg production không phải là tĩnh - nó cần dọn dẹp đều đặn. Streaming ingest thường tạo ra hàng nghìn file nhỏ mỗi ngày, còn upsert sinh delete file và các dòng lỗi thời. Nếu không bảo trì, query engine sẽ chết vì số lượng file quá lớn.

Bảo trì Iceberg gồm bốn công việc chính:

1. Rewrite data files - gộp nhiều file nhỏ thành ít file lớn hơn, theo target file size (thường 256-512 MB). Có thể rewrite theo strategy bin-pack (đơn giản), sort (sắp xếp lại theo cột phổ biến để pruning tốt hơn), hoặc z-order (multi-dimensional locality).
2. Rewrite manifests - gộp manifest nhỏ, cân đối partition phân bố trong manifest để giảm số manifest phải mở cho mỗi query.
3. Expire snapshots - xóa các snapshot cũ hơn ngưỡng, giải phóng file data và delete không còn được tham chiếu. Đây là điều kiện tiên quyết để giải phóng dung lượng object storage.
4. Remove orphan files - quét thư mục dữ liệu, so với danh sách file hợp lệ trong metadata, xóa các file mồ côi do job lỗi hoặc truncate không sạch.

Với Spark, bộ API CALL procedures là chuẩn: CALL catalog.system.rewrite_data_files(...), CALL catalog.system.expire_snapshots(...). Với các catalog managed như S3 Tables, các công việc này được tự động hóa: bucket tự chạy compaction và expire theo policy, đội dữ liệu không cần viết job riêng.

9. Streaming ingestion - từ Kafka thẳng vào Iceberg

Cho đến 2023, ghi streaming vào Iceberg là một trải nghiệm khó khăn: phải cân đối giữa latency và overhead commit, dễ tạo ra file nhỏ, dễ gặp "commit conflict" khi có nhiều job song song. Năm 2026 tình hình đã thay đổi hẳn, nhờ ba cải tiến:

1. Kafka Connect Iceberg Sink - connector chính thức do cộng đồng Iceberg duy trì, hỗ trợ upsert, multi-table fan-out và idempotent commit, cho phép ghi từ hàng trăm topic Kafka vào hàng trăm bảng Iceberg trong cùng một transaction.
2. Flink Iceberg connector - với Flink 2.x, connector Iceberg đã hỗ trợ đầy đủ v3, bao gồm deletion vector và row lineage, cho phép CDC full từ Debezium vào Iceberg với exactly-once thực sự.
3. Serverless Lambda / Cloud Run sink - các dịch vụ managed ingest thẳng vào Iceberg (AWS Data Firehose, Snowflake Openflow, GCP Dataflow) biến đối tượng tiêu dùng thành nhà phát triển backend thông thường, không cần cụm Kafka riêng.

Mô hình tham khảo được ưa chuộng: Flink đảm nhiệm CDC và transform phức tạp, ghi vào bảng Iceberg "bronze"; một job Spark hoặc Trino chạy theo schedule đọc bronze, làm sạch và ghi vào bảng "silver" và "gold". Các engine BI (StarRocks, ClickHouse, Dremio) đọc bảng gold với độ trễ từ vài giây đến vài phút tùy tần suất compact.

10. Iceberg so với Delta Lake và Hudi

Đến năm 2026, câu hỏi "chọn format nào" đã bớt căng thẳng so với 2022, nhưng vẫn cần nhìn rõ:

Đường hội tụ rõ: Delta Lake hỗ trợ UniForm để ghi metadata Iceberg song song, còn Iceberg v3 học từ Delta về variant và deletion vector. Với đa số dự án mới năm 2026, Iceberg là lựa chọn mặc định vì độ mở của catalog REST và tính trung lập về vendor; Delta là lựa chọn tự nhiên nếu đội ngũ đã đứng sâu trong Databricks; Hudi là lựa chọn tốt cho workload streaming upsert với lịch sử lâu đời.

11. Case study - Netflix, Apple, Airbnb, Shopify, LinkedIn

Iceberg không phải là công nghệ phòng thí nghiệm. Nó được chứng minh ở quy mô lớn nhất hành tinh:

• Netflix - nơi Iceberg ra đời - chạy hơn 1 exabyte dữ liệu trên S3 dưới dạng bảng Iceberg, với hàng triệu snapshot mỗi ngày và hàng tỷ dòng được ghi mới. Một trong các bài học công bố là: bỏ Hive metastore, chuyển hết sang Iceberg REST giúp giảm thời gian plan query trung bình từ nhiều phút xuống dưới một giây.
• Apple - các đội dữ liệu của Apple đóng góp sâu vào Iceberg (spec v3 có nhiều đề xuất từ Apple). Apple dùng Iceberg làm định dạng chuẩn cho toàn bộ data lake nội bộ, chia sẻ giữa Spark, Trino và các engine riêng.
• Airbnb - chuyển hàng petabyte từ Hive sang Iceberg trong hai năm, ghi nhận giảm hơn 50% chi phí lưu trữ nhờ compaction và row-level delete thay cho rewrite partition.
• Shopify - xây dựng toàn bộ lakehouse trên Iceberg + Trino, dùng Nessie để branching pipeline và giảm rủi ro deploy ETL sai.
• LinkedIn - xây dựng OpenHouse, một lớp quản trị bảng trên Iceberg, tự động compaction, snapshot expiration và data retention cho hàng trăm nghìn bảng nội bộ.

12. Giới hạn và những điểm cần tỉnh táo

• Không phải OLTP. Iceberg tối ưu cho append, batch và bulk update. Một workload transaction với hàng nghìn update điểm mỗi giây không phù hợp - nên giữ trên OLTP và CDC qua.
• Commit conflict với nhiều writer. Nhiều job ghi song song vào cùng một bảng cần chiến lược retry hoặc tách phân vùng. REST catalog giúp nhiều nhưng không xóa được gốc vấn đề.
• Chi phí list / metadata I/O trên object storage. Dù manifest đã giảm đáng kể số lần gọi list, một bảng có hàng triệu file không được compact vẫn là thảm họa. Ngân sách S3 LIST/GET cần được theo dõi như metric hạng nhất.
• Small files problem vẫn còn. Iceberg không tự compact nếu bạn không đặt lịch. Mặc định "không làm gì" sẽ gây hậu quả sau vài tháng vận hành.
• Governance yếu nếu chọn sai catalog. Iceberg chỉ chuẩn hóa đến "ai đang giữ con trỏ". Quyền cấp cột, mask dữ liệu, lineage, audit đều phụ thuộc vào catalog. Nếu chọn catalog nghèo governance, bạn phải tự xây.
• Schema evolution vẫn có giới hạn. Đổi tên cột dễ, thêm cột dễ, nhưng thay đổi kiểu theo hướng không tương thích (ví dụ decimal giảm scale) vẫn cần rewrite. Đừng coi evolution là phép màu.

13. Checklist triển khai Iceberg production 2026

1. Chọn catalog REST trước khi chọn engine. Polaris, Unity Catalog, Nessie, Gravitino hay S3 Tables - quyết định này ảnh hưởng lâu dài hơn chọn Trino hay Spark.
2. Thiết lập target file size và partition spec rõ ràng. Không để engine tự quyết định. 256-512 MB cho bảng tĩnh, 128-256 MB cho bảng streaming.
3. Lên lịch compaction và expire snapshot. Hàng ngày cho bảng streaming, hàng tuần cho bảng batch. Đặt TTL snapshot theo yêu cầu time travel thực tế, không theo thói quen "càng lâu càng tốt".
4. Ngân sách metadata I/O. Theo dõi số manifest trung bình mỗi snapshot, số file trung bình mỗi partition, thời gian plan query. Đây là các leading indicator của lỗi hiệu năng sắp đến.
5. Tách môi trường bằng branch hoặc namespace. Dev/stage/prod không nên dùng chung bảng. Dùng branch cho thử nghiệm ngắn hạn, namespace riêng cho môi trường dài hạn.
6. Tuân thủ spec REST nghiêm ngặt. Không cho phép các "extension" không có trong spec, vì chúng sẽ khóa bạn vào catalog đó.
7. Đưa governance vào catalog từ ngày đầu. RBAC, row filter, column mask, audit log cấu hình qua catalog chứ không phải qua từng engine riêng.
8. Backup metadata, không chỉ dữ liệu. File metadata.json và manifest cần có chiến lược sao lưu riêng; mất chúng là mất bảng dù dữ liệu Parquet vẫn còn nguyên.
9. Quan trắc catalog như một dịch vụ sản phẩm. Các metric quan trọng: p99 commit latency, conflict rate, số snapshot mỗi giờ, dung lượng metadata.
10. Kế hoạch rollback và DR. Viết runbook cho: rollback snapshot sai, khôi phục catalog, phục hồi bucket nếu bị xóa nhầm.

14. Kết luận - Lakehouse mở đã thắng, vấn đề còn lại là vận hành

Năm 2017 khi Netflix công bố Iceberg, rất ít ai tin rằng một định dạng bảng open source có thể đặt chân vào một thế giới bị thống trị bởi Snowflake, BigQuery và Redshift. Chín năm sau, ba nhà cung cấp lớn đó đều hỗ trợ Iceberg như công dân hạng nhất. Tabular - công ty do chính cha đẻ của Iceberg lập ra - được mua với giá hàng tỷ đô. Các cloud provider đưa Iceberg vào managed service ở mức "bật công tắc". Khi tất cả các bên đều quy tụ quanh một chuẩn, điều đó có nghĩa cuộc tranh luận "format nào" đã thực sự kết thúc.

Vấn đề còn lại của năm 2026 không phải là Iceberg có tốt không, mà là: đội ngũ của bạn có đủ kỷ luật vận hành một hệ thống mở? Chọn catalog chuẩn, nghiêm với compaction, theo dõi metadata I/O, thiết lập governance từ ngày đầu, có runbook rollback. Open lakehouse mang lại sự độc lập về vendor và sự linh hoạt về engine, nhưng không cho bạn kỷ luật - cái đó vẫn phải tự xây.

Với người kỹ sư hệ thống năm 2026, hiểu Iceberg không còn là kỹ năng chuyên ngành của đội dữ liệu. Đó là kiến thức nền giống như hiểu DNS, hiểu gRPC, hiểu eventual consistency - một nguyên liệu bạn sẽ gặp đi gặp lại trong mọi quyết định platform lớn của thập kỷ này.

15. Nguồn tham khảo

• Apache Iceberg - Table Specification
• Apache Iceberg - Official Documentation
• Apache Iceberg - Spec v3 on GitHub
• Netflix Tech Blog - Iceberg at Netflix
• Databricks - Delta Lake UniForm and Iceberg
• Snowflake - Introducing Polaris Catalog
• Project Nessie - Git-like experience for data lake
• Apache Gravitino - Unified metadata lake
• AWS S3 Tables - Managed Iceberg Catalog
• Trino - Iceberg Connector Documentation
• DuckDB - Iceberg Extension
• ClickHouse - Iceberg Database Engine
• Apache Flink - Iceberg Connector
• LinkedIn Engineering - OpenHouse Control Plane
• Apache Iceberg - Definitive Guide to REST Catalog