Định dạng bảng mở vào năm 2026: Apache Iceberg v2 so với Delta Lake 3.0 trên Cloud Object Storage

Kiến trúc data lakehouse, tận dụng lưu trữ đối tượng đám mây (S3, GCS, Azure Blob Storage) làm nền tảng, đã trở thành tiêu chuẩn thực tế cho các khối lượng công việc phân tích. Trọng tâm của sự phát triển này là các định dạng bảng mở: Apache Iceberg và Delta Lake. Các định dạng này trang bị cho lưu trữ đối tượng khả năng giao dịch ACID, cô lập ảnh chụp nhanh (snapshot isolation) và khả năng du hành thời gian (time-travel), những tính năng vốn gắn liền với các cơ sở dữ liệu quan hệ. Hướng dẫn này phân tích Apache Iceberg (đặc tả v2) và Delta Lake (3.0 với UniForm) vào năm 2026, cung cấp một so sánh kỹ thuật và những hiểu biết sâu sắc về kiến trúc.

Nguyên tắc cốt lõi: ACID trên lưu trữ đối tượng

Cả Iceberg và Delta Lake đều đạt được các thuộc tính ACID bằng cách duy trì một nhật ký giao dịch hoặc cây siêu dữ liệu theo dõi các thay đổi của tệp dữ liệu. Bản thân các tệp dữ liệu là bất biến. Các thao tác cập nhật, xóa và chèn được xử lý bằng cách ghi các tệp dữ liệu mới và cập nhật siêu dữ liệu để phản ánh trạng thái mới, đồng thời đánh dấu các tệp cũ là đã xóa một cách logic. Cách tiếp cận copy-on-write (CoW) này là nền tảng cho hoạt động của chúng trên lưu trữ đối tượng chỉ có thể thêm (append-only).

Apache Iceberg v2: Siêu dữ liệu phân cấp và phân vùng tiến hóa

Kiến trúc của Iceberg được xây dựng xung quanh một cấu trúc siêu dữ liệu phân cấp:

1. Catalog: Lưu trữ con trỏ siêu dữ liệu hiện tại cho một bảng. Đây có thể là Hive Metastore, Nessie, AWS Glue, hoặc một catalog tùy chỉnh.
2. Metadata File: Trỏ đến một danh sách các manifest list. Mỗi commit tạo ra một tệp siêu dữ liệu mới.
3. Manifest List: Trỏ đến một danh sách các manifest file. Mỗi manifest list đại diện cho một ảnh chụp nhanh (snapshot) của bảng.
4. Manifest File: Chứa các mục nhập cho các tệp dữ liệu, bao gồm đường dẫn, giá trị phân vùng và thống kê (giá trị min/max, số lượng null).
5. Data Files: Các tệp Parquet, ORC, Avro chứa dữ liệu thực tế.

Cấu trúc này cho phép cắt tỉa hiệu quả trong quá trình lập kế hoạch truy vấn. Iceberg v2 tăng cường đáng kể các khả năng, đặc biệt là về tiến hóa lược đồ và phân vùng, cũng như các thao tác cấp hàng.

Tiến hóa phân vùng

Tiến hóa phân vùng của Iceberg cho phép thay đổi các lược đồ phân vùng theo thời gian mà không cần ghi lại dữ liệu hiện có. Điều này rất quan trọng đối với các bảng tồn tại lâu dài nơi các mẫu truy cập dữ liệu phát triển.

-- Example: Evolving a table's partitioning in Iceberg
-- Initial table creation
CREATE TABLE my_iceberg_table (
    id BIGINT,
    event_time TIMESTAMP,
    value STRING
)
USING iceberg
PARTITIONED BY (days(event_time));

-- Later, evolve partitioning to hourly
ALTER TABLE my_iceberg_table
ADD PARTITION FIELD hours(event_time);

-- Existing data remains partitioned by days, new data by hours.
-- Queries automatically handle both partition schemes.

Xóa và cập nhật cấp hàng (Copy-on-Write so với Merge-on-Read)

Iceberg v2 giới thiệu hai cách tiếp cận chính cho các thao tác cấp hàng:

1. Copy-on-Write (CoW): Phương pháp truyền thống. Đối với thao tác xóa hoặc cập nhật, các tệp dữ liệu bị ảnh hưởng sẽ được ghi lại, loại trừ hoặc sửa đổi các hàng mục tiêu. Điều này có thể tốn nhiều I/O đối với các tệp lớn có ít thay đổi.
2. Merge-on-Read (MoR) với Delete Files: Iceberg v2 hỗ trợ "delete files" (xóa theo vị trí hoặc xóa theo giá trị).
   • Positional Delete Files: Lưu trữ đường dẫn tệp và vị trí (số hàng) của các hàng cần xóa trong một tệp dữ liệu.
   • Equality Delete Files: Lưu trữ các giá trị của các cột xác định duy nhất các hàng cần xóa. Trong thời gian truy vấn, công cụ đọc các tệp dữ liệu và áp dụng các tệp xóa để lọc các hàng. Điều này trì hoãn chi phí ghi lại đến thời gian đọc.

// Example: Writing an Iceberg table with Spark and performing a delete
import org.apache.spark.sql.SparkSession
import org.apache.spark.sql.functions._

val spark = SparkSession.builder()
  .appName("IcebergDeleteExample")
  .config("spark.sql.catalog.local", "org.apache.iceberg.spark.SparkSessionCatalog")
  .config("spark.sql.catalog.local.type", "hadoop")
  .config("spark.sql.catalog.local.warehouse", "/tmp/iceberg_warehouse")
  .getOrCreate()

spark.sql("CREATE NAMESPACE IF NOT EXISTS local.db")
spark.sql("""
  CREATE TABLE local.db.my_iceberg_table (
    id BIGINT,
    data STRING,
    ts TIMESTAMP
  ) USING iceberg
  PARTITIONED BY (days(ts))
""")

// Insert initial data
spark.sql("""
  INSERT INTO local.db.my_iceberg_table VALUES
  (1, 'value_a', TIMESTAMP '2026-01-01 10:00:00'),
  (2, 'value_b', TIMESTAMP '2026-01-01 11:00:00'),
  (3, 'value_c', TIMESTAMP '2026-01-02 12:00:00')
""")

// Perform a delete operation (CoW by default, but can be configured for MoR with delete files)
// For MoR, ensure the table property 'format-version' is 2 and 'write.delete.mode' is 'merge-on-read'
spark.sql("ALTER TABLE local.db.my_iceberg_table SET TBLPROPERTIES ('format-version'='2', 'write.delete.mode'='merge-on-read')")

spark.sql("DELETE FROM local.db.my_iceberg_table WHERE id = 2")

// Verify the delete
spark.sql("SELECT * FROM local.db.my_iceberg_table").show()
// Expected output: rows with id 1 and 3

Delta Lake 3.0: Nhật ký giao dịch và UniForm

Cốt lõi của Delta Lake là nhật ký giao dịch của nó, một chuỗi các tệp JSON (và các điểm kiểm tra Parquet để tăng hiệu quả) được lưu trữ cùng với các tệp dữ liệu trong thư mục _delta_log. Mỗi mục nhập trong nhật ký đại diện cho một commit nguyên tử, mô tả chi tiết việc thêm và xóa các tệp dữ liệu.

UniForm (Định dạng phổ quát)

Delta Lake 3.0 giới thiệu UniForm, một tính năng quan trọng cho khả năng tương tác. UniForm tạo siêu dữ liệu Iceberg và Hudi cùng với nhật ký giao dịch gốc của Delta Lake. Điều này cho phép các công cụ hiểu Iceberg hoặc Hudi một cách tự nhiên có thể đọc các bảng Delta mà không yêu cầu các trình kết nối Delta Lake. Đây là một bước tiến đáng kể hướng tới khả năng tương tác định dạng bảng mở thực sự.

// Example: Creating a Delta table with UniForm enabled in Spark
import org.apache.spark.sql.SparkSession

val spark = SparkSession.builder()
  .appName("DeltaUniFormExample")
  .config("spark.sql.extensions", "io.delta.sql.DeltaSparkSessionExtension")
  .config("spark.sql.catalog.spark_catalog", "org.apache.spark.sql.delta.catalog.DeltaCatalog")
  .getOrCreate()

// Create a Delta table with UniForm enabled
spark.sql("""
  CREATE TABLE my_delta_table (
    id BIGINT,
    data STRING,
    ts TIMESTAMP
  ) USING DELTA
  TBLPROPERTIES (
    'delta.enableIcebergCompatV2' = 'true',
    'delta.universalFormat.enabledFeatures' = 'iceberg'
  )
  PARTITIONED BY (CAST(ts AS DATE))
""")

// Insert data
spark.sql("""
  INSERT INTO my_delta_table VALUES
  (1, 'delta_val_a', TIMESTAMP '2026-01-01 10:00:00'),
  (2, 'delta_val_b', TIMESTAMP '2026-01-01 11:00:00')
""")

// Now, this Delta table can be read by Iceberg-compatible engines
// (e.g., Trino, DuckDB) directly, without Delta Lake specific connectors.
// The Iceberg metadata is automatically generated and kept in sync.

Phân vùng và tiến hóa lược đồ

Delta Lake cũng hỗ trợ tiến hóa lược đồ (thêm/xóa cột, thay đổi kiểu dữ liệu) và tiến hóa phân vùng. Phân vùng thường được định nghĩa khi tạo bảng và có thể được thay đổi bằng cách ghi lại bảng.

-- Example: Delta Lake schema evolution
ALTER TABLE my_delta_table ADD COLUMNS (new_col INT);

Xóa và cập nhật cấp hàng

Delta Lake chủ yếu sử dụng cách tiếp cận CoW cho các thao tác DELETE, UPDATE và MERGE. Nó xác định các tệp bị ảnh hưởng, ghi lại chúng với các thay đổi và ghi lại các tệp mới vào nhật ký giao dịch. Đối với các bảng lớn với các cập nhật nhỏ thường xuyên, điều này có thể dẫn đến sự khuếch đại tệp và chi phí hiệu suất. Databricks đã giới thiệu "liquid clustering" và "photon-accelerated writes" để giảm thiểu một số vấn đề này, nhưng cơ chế cốt lõi vẫn là CoW.

Khả năng tương tác của công cụ

Khả năng truy vấn các bảng từ nhiều công cụ khác nhau là nền tảng của lakehouse.

Trino

Trino (trước đây là PrestoSQL) có các trình kết nối mạnh mẽ cho cả Iceberg và Delta Lake.

-- Trino: Querying an Iceberg table
-- Catalog configuration (e.g., in etc/catalog/iceberg.properties)
-- connector.name=iceberg
-- iceberg.catalog.type=rest # or hive, glue, hadoop

SELECT * FROM iceberg.db.my_iceberg_table WHERE id = 1;

-- Trino: Querying a Delta Lake table (with UniForm, via Iceberg connector)
-- Assuming UniForm is enabled on the Delta table, Trino's Iceberg connector
-- can read it directly.
SELECT * FROM iceberg.db.my_delta_table WHERE id = 1;

-- Trino: Querying a Delta Lake table (via Delta Lake connector)
-- Catalog configuration (e.g., in etc/catalog/delta.properties)
-- connector.name=delta_lake
-- delta.catalog.type=glue # or hive, hadoop

SELECT * FROM delta.db.my_delta_table WHERE id = 1;

Apache Spark

Spark là môi trường gốc cho cả Iceberg và Delta Lake.

// Spark: Reading Iceberg
spark.read.format("iceberg").load("local.db.my_iceberg_table").show()

// Spark: Reading Delta Lake
spark.read.format("delta").load("/path/to/my_delta_table").show()

DuckDB

DuckDB, một cơ sở dữ liệu OLAP trong tiến trình, cung cấp khả năng phân tích cục bộ tuyệt vời.

# Python with DuckDB: Reading Iceberg
import duckdb

con = duckdb.connect(database=':memory:', read_only=False)
con.execute("INSTALL iceberg;")
con.execute("LOAD iceberg;")

# Point to the Iceberg table's metadata file or catalog
# For local Iceberg table created by Spark in /tmp/iceberg_warehouse/db/my_iceberg_table
con.execute("CREATE OR REPLACE TABLE my_iceberg_table AS SELECT * FROM iceberg_scan('/tmp/iceberg_warehouse/db/my_iceberg_table/metadata/v*.metadata.json');")
con.execute("SELECT * FROM my_iceberg_table;").fetchdf()

# Python with DuckDB: Reading Delta Lake (with UniForm, via Iceberg extension)
# Assuming UniForm is enabled on the Delta table
con.execute("INSTALL delta;") # Delta extension is also available
con.execute("LOAD delta;")
con.execute("CREATE OR REPLACE TABLE my_delta_table AS SELECT * FROM delta_scan('/path/to/my_delta_table');")
con.execute("SELECT * FROM my_delta_table;").fetchdf()

# If UniForm is enabled, you might be able to use iceberg_scan directly on the Delta path
# (This depends on the exact implementation of DuckDB's Iceberg connector and UniForm's metadata sync)
# con.execute("CREATE OR REPLACE TABLE my_delta_table_as_iceberg AS SELECT * FROM iceberg_scan('/path/to/my_delta_table');")

So sánh kiến trúc và đánh đổi

Đánh đổi

• Chi phí siêu dữ liệu: Siêu dữ liệu phân cấp của Iceberg có thể dẫn đến nhiều tệp nhỏ hơn (manifest) cho các bảng rất lớn với nhiều phân vùng và các commit thường xuyên. Tuy nhiên, khả năng cắt tỉa của nó rất hiệu quả. Nhật ký giao dịch của Delta Lake đơn giản hơn nhưng có thể trở nên rất lớn, đòi hỏi phải tạo điểm kiểm tra.
• Các thao tác cấp hàng: MoR của Iceberg với các tệp xóa cung cấp một giải pháp thay thế hấp dẫn cho CoW, đặc biệt đối với các bảng có tần suất cập nhật/xóa cao trên một tỷ lệ nhỏ các hàng, giảm sự khuếch đại ghi. CoW của Delta Lake có thể rất hiệu quả cho các thao tác hàng loạt nhưng có thể phát sinh chi phí ghi lại cao hơn cho các thay đổi chi tiết.
• Khả năng tương tác: Thiết kế của Iceberg vốn dĩ cởi mở hơn và không phụ thuộc vào công cụ ngay từ đầu. UniForm của Delta Lake là một động thái chiến lược để đạt được khả năng tương tác rộng rãi tương tự bằng cách tạo siêu dữ liệu tương thích với Iceberg, giúp các bảng Delta có thể đọc được bởi các công cụ Iceberg. Đây là một chiến thắng đáng kể cho hệ sinh thái.
• Cộng đồng & Hệ sinh thái: Cả hai đều có cộng đồng mạnh mẽ, năng động. Iceberg được hưởng lợi từ quản trị của Apache Foundation, thúc đẩy một hệ sinh thái đa dạng. Delta Lake, mặc dù là mã nguồn mở, có mối quan hệ chặt chẽ với Databricks, nơi thúc đẩy phần lớn sự phát triển và bộ tính năng của nó.

Những vấn đề và cách khắc phục trong sản xuất

1. Vấn đề tệp nhỏ (cả Iceberg & Delta Lake): Các thao tác thêm hoặc cập nhật nhỏ thường xuyên có thể dẫn đến sự bùng nổ của các tệp dữ liệu nhỏ. Điều này làm giảm hiệu suất truy vấn do tăng cường xử lý siêu dữ liệu và chi phí I/O.

   • Cách khắc phục: Triển khai các công việc nén (ví dụ: sử dụng Spark OPTIMIZE cho Delta, hoặc hành động rewrite_data_files của Iceberg) để hợp nhất các tệp nhỏ thành các tệp lớn hơn. Lên lịch thực hiện chúng thường xuyên.
   scalaCopy

   // Delta Lake compaction
   spark.sql("OPTIMIZE my_delta_table ZORDER BY (event_time)")
   
   // Iceberg compaction (Spark example)
   import org.apache.iceberg.spark.actions.SparkActions
   SparkActions.get(spark).rewriteDataFiles(spark.table("local.db.my_iceberg_table")).execute()
   

2. Phình to siêu dữ liệu (cả Iceberg & Delta Lake): Theo thời gian, nhật ký giao dịch (_delta_log) hoặc các tệp siêu dữ liệu của Iceberg có thể trở nên rất lớn, ảnh hưởng đến thời gian commit và lập kế hoạch truy vấn.

   • Cách khắc phục: Cấu hình các chính sách lưu giữ cho các ảnh chụp nhanh cũ. Đối với Delta Lake, sử dụng VACUUM với một khoảng thời gian lưu giữ. Đối với Iceberg, hành động expire_snapshots.
   scalaCopy

   // Delta Lake vacuum (retains 7 days by default, can be configured)
   spark.sql("SET spark.databricks.delta.retentionDurationCheck.enabled = false") // Disable safety check for testing
   spark.sql("VACUUM my_delta_table RETAIN 0 HOURS") // DANGER: Deletes files not referenced by current snapshot
   spark.sql("SET spark.databricks.delta.retentionDurationCheck.enabled = true")
   
   // Iceberg expire snapshots (retains last N snapshots or snapshots newer than a timestamp)
   SparkActions.get(spark).expireSnapshots(spark.table("local.db.my_iceberg_table"))
     .retainLast(10) // Retain last 10 snapshots
     .execute()
   

3. Xung đột tiến hóa lược đồ: Mặc dù cả hai đều hỗ trợ tiến hóa lược đồ, nhưng các kiểu dữ liệu không mong muốn hoặc đổi tên cột có thể gây ra sự cố.

   • Cách khắc phục: Xác thực dữ liệu đến so với lược đồ bảng trước khi ghi. Sử dụng spark.sql.legacy.allowUntypedScalaUDF cho Spark nếu gặp sự cố UDF với tiến hóa lược đồ. Đối với Iceberg, đảm bảo schema.auto.merge không được bật một cách mù quáng trong sản xuất mà không xem xét cẩn thận.

4. Giới hạn tốc độ/Điều tiết lưu trữ đối tượng: Khả năng đồng thời cao hoặc các thao tác nhỏ thường xuyên có thể chạm đến giới hạn API lưu trữ đối tượng (ví dụ: S3 5000 yêu cầu PUT/GET mỗi giây trên mỗi tiền tố).

   • Cách khắc phục: Tối ưu hóa các thao tác ghi cho kích thước tệp lớn hơn. Triển khai logic lùi lũy thừa và thử lại trong các pipeline nhập dữ liệu. Phân phối dữ liệu trên nhiều tiền tố S3 hơn nếu có thể. Giám sát các chỉ số của nhà cung cấp đám mây để phát hiện điều tiết.

5. Đọc không nhất quán (Time Travel): Nếu không sử dụng rõ ràng tính năng time travel, các truy vấn có thể lấy dữ liệu cũ nếu một thao tác ghi đồng thời commit ngay sau khi truy vấn bắt đầu lập kế hoạch nhưng trước khi nó đọc các tệp dữ liệu.

   • Cách khắc phục: Đối với các truy vấn phân tích quan trọng yêu cầu tính nhất quán nghiêm ngặt, hãy sử dụng time travel để truy vấn một ID ảnh chụp nhanh hoặc dấu thời gian cụ thể.
   sqlCopy

   -- Delta Lake time travel
   SELECT * FROM my_delta_table VERSION AS OF 5;
   SELECT * FROM my_delta_table TIMESTAMP AS OF '2026-01-01 12:00:00';
   
   -- Iceberg time travel
   SELECT * FROM local.db.my_iceberg_table FOR SYSTEM_VERSION AS OF 1234567890123456L; -- Snapshot ID
   SELECT * FROM local.db.my_iceberg_table FOR SYSTEM_TIME AS OF '2026-01-01 12:00:00';
   

Các câu hỏi thường gặp

1. Khi nào tôi nên chọn Iceberg thay vì Delta Lake, hoặc ngược lại? Chọn Iceberg nếu: bạn ưu tiên một hệ sinh thái thực sự mở, không phụ thuộc vào nhà cung cấp, yêu cầu tiến hóa phân vùng nâng cao, hoặc cần MoR hiệu quả cho các cập nhật/xóa cấp hàng thường xuyên. Chọn Delta Lake nếu: bạn đầu tư nhiều vào hệ sinh thái Databricks, thích một mô hình nhật ký giao dịch đơn giản hơn, hoặc hưởng lợi từ các tối ưu hóa hiệu suất dành riêng cho Databricks (ví dụ: Photon, Liquid Clustering). Với UniForm, khoảng cách tương tác của Delta Lake với Iceberg giảm đáng kể.

2. UniForm ảnh hưởng đến quyết định của tôi giữa Iceberg và Delta Lake như thế nào? UniForm làm cho các bảng Delta Lake có thể đọc được bởi các công cụ tương thích với Iceberg. Điều này làm giảm đáng kể mối lo ngại về "khóa nhà cung cấp" đối với Delta Lake. Nếu mối quan tâm chính của bạn là khả năng hỗ trợ công cụ rộng hơn của Iceberg, UniForm phần lớn đã giảm thiểu điều đó. Tuy nhiên, UniForm hiện chỉ cung cấp khả năng tương thích Iceberg chỉ đọc; các thao tác ghi vẫn yêu cầu Delta Lake.

3. Ý nghĩa về hiệu suất của MoR của Iceberg so với CoW của Delta Lake đối với các thao tác cấp hàng là gì? MoR của Iceberg có thể mang lại hiệu suất ghi tốt hơn cho các cập nhật/xóa nhỏ, thường xuyên bằng cách trì hoãn chi phí ghi lại đến thời gian đọc. Điều này có lợi khi sự khuếch đại ghi là một mối lo ngại. Tuy nhiên, MoR có thể gây ra chi phí đọc vì công cụ phải áp dụng các tệp xóa. CoW của Delta Lake đảm bảo các thao tác đọc luôn sạch nhưng có thể dẫn đến sự khuếch đại ghi và I/O cao hơn cho các thay đổi chi tiết. Lựa chọn tối ưu phụ thuộc vào các mẫu đọc/ghi và yêu cầu độ trễ của bạn.

4. Tôi có thể di chuyển một bảng Hive hiện có sang Iceberg hoặc Delta Lake không? Có, cả hai định dạng đều cung cấp các công cụ để di chuyển. Đối với Iceberg, bạn có thể sử dụng ALTER TABLE ... SET TBLPROPERTIES ('format'='iceberg') trong Spark cho các bảng không được quản lý, hoặc sử dụng hành động migrate. Đối với Delta Lake, lệnh CONVERT TO DELTA có thể chuyển đổi các bảng Parquet hoặc Hive tại chỗ. Luôn kiểm tra kỹ lưỡng các lần di chuyển trên một tập hợp con dữ liệu trước.

5. Vai trò của một catalog trong các định dạng bảng này là gì? Catalog rất quan trọng. Nó hoạt động như một sổ đăng ký trung tâm cho các bảng, lưu trữ con trỏ siêu dữ liệu hiện tại (đối với Iceberg) hoặc đường dẫn cơ sở (đối với Delta Lake). Nếu không có catalog, các công cụ không thể định vị và diễn giải trạng thái của bảng. Các catalog phổ biến bao gồm Hive Metastore, AWS Glue Data Catalog, Project Nessie (đối với Iceberg) và Databricks Unity Catalog (đối với Delta Lake).