Kỹ sư QLTT Ghi chú ôn thi
← Về danh sách
Cơ sở dữ liệu
#Iceberg#오픈테이블포맷#레이크하우스#타임트래블#스키마진화
Cập nhật lần cuối · 2026-09-19

Định dạng bảng mở (Apache Iceberg)

1. Tổng quan

Định nghĩa: Apache Iceberg là một định dạng bảng mở (Open Table Format) dành cho các tập dữ liệu phân tích quy mô lớn, là đặc tả metadata gán ngữ nghĩa của bảng quan hệ (giao dịch ACID, tiến hóa lược đồ, time travel) cho tập hợp tệp trên object storage (S3, HDFS, GCS...). Nó không phải là bản thân tệp dữ liệu, mà là chuẩn của tầng metadata mô tả "những tệp nào cấu thành bảng tại một thời điểm cụ thể".

Data lake lan rộng nhanh chóng nhờ ưu điểm có thể nạp nguyên dữ liệu gốc vào object storage giá rẻ, nhưng data lake thời kỳ đầu thực chất chỉ là "một đống tệp chất trong thư mục". Tiêu biểu là bảng Hive, vốn coi đường dẫn thư mục (ví dụ: /sales/dt=2026-09-19/) là phân vùng, và cấu trúc này mang ba giới hạn căn bản. Thứ nhất, để nắm được danh sách tệp phải liệt kê (LIST) đệ quy thư mục của kho lưu trữ, nên khi số tệp tăng lên hàng triệu thì bản thân việc lập kế hoạch truy vấn trở thành nút thắt. Thứ hai, khi nhiều tác vụ cùng ghi vào một bảng, các tệp được cập nhật dở dang bị lộ ra nguyên trạng nên không bảo đảm tính nguyên tử (bên đọc có thể thấy kết quả chỉ mới ghi một nửa). Thứ ba, khi đổi cột phân vùng hoặc thay đổi lược đồ thì phải ghi lại toàn bộ dữ liệu.

Apache Iceberg được Netflix phát triển nội bộ năm 2017 để giải quyết vấn đề "data lake thiếu độ tin cậy" này, được hiến tặng cho Apache Foundation năm 2018 và trở thành Top-Level Project năm 2020. Ý tưởng cốt lõi là thay việc liệt kê thư mục bằng việc theo dõi tệp metadata. Bằng cách quản lý tường minh danh sách và thống kê của mọi tệp dữ liệu cấu thành bảng dưới dạng metadata, nó quyết định cần đọc tệp nào chỉ bằng việc tra cứu metadata thay vì O(số tệp), mà không cần liệt kê kho lưu trữ. Nhờ đó, nó trở thành nền tảng lưu trữ của Lakehouse, nơi data lake có được tính giao dịch và hiệu năng ngang tầm data warehouse.

Bối cảnh Netflix gặp phải vấn đề này mang nhiều ý nghĩa. Khi đó Netflix vận hành hàng chục petabyte dữ liệu trên S3 dưới dạng bảng Hive, và ngay cả một truy vấn đơn giản tra cứu một phân vùng cụ thể trong một bảng lớn cũng mất vài phút chỉ để lập kế hoạch do hàng triệu lời gọi LIST/GET tới S3, đồng thời do không có tính nguyên tử khi ghi đồng thời mà sự cố kết quả sai lọt vào phân tích cứ lặp lại. Iceberg đã giải quyết tận gốc vấn đề này bằng sự chuyển đổi quan điểm "đừng để engine truy vấn lục lọi kho lưu trữ, hãy để metadata có sẵn đáp án". Điều này tương đương với việc cấy vai trò mà chỉ mục và catalog của cơ sở dữ liệu vẫn đảm nhận vào data lake dựa trên tệp.

Các đặc điểm của Iceberg được tóm tắt như sau: tính trung lập với engine (nhiều engine như Spark, Trino, Flink, Snowflake, Dremio chia sẻ cùng một bảng), tính trung lập với định dạng tệp (hỗ trợ Parquet, ORC, Avro), tính trung lập với kho lưu trữ (ghi đường dẫn tệp trong metadata dưới dạng đường dẫn tuyệt đối nên không phụ thuộc cấu trúc thư mục), và tính nhất quán ở mức khả tuần tự (serializable) thông qua cách ly dựa trên snapshot.

Tóm lại, mệnh đề cốt lõi mà Iceberg giải quyết là "giữ nguyên khả năng mở rộng và tính kinh tế của object storage giá rẻ, đồng thời lấy lại độ tin cậy về giao dịch, quản lý lược đồ và truy vấn theo thời điểm mà cơ sở dữ liệu quan hệ từng cung cấp". Mệnh đề này là bài toán bắt buộc phải giải trong nền tảng dữ liệu hiện đại, nơi dữ liệu bùng nổ và nhu cầu phân tích, AI ngày càng đa dạng; vì vậy từ góc độ Kỹ sư chuyên nghiệp Quản lý Thông tin, Iceberg đã trở thành đối tượng bắt buộc phải xem xét trong thiết kế kiến trúc dữ liệu.

2. Cấu trúc tổng thể và tầng metadata

Bảng Iceberg có cấu trúc con trỏ phân tầng nối tiếp catalog → tệp metadata → manifest list → manifest → tệp dữ liệu. Cấu trúc đa tầng này chính là cơ chế cốt lõi tạo ra hiệu năng và tính giao dịch của Iceberg. Mỗi tầng chia sẻ nguyên tắc: tầng trên tham chiếu tầng dưới bằng con trỏ bất biến (immutable), và mọi thay đổi đều được phản ánh bằng cách tạo tệp mới rồi chỉ thay con trỏ cấp cao nhất. Nguyên lý "ghi luôn là thêm, chuyển đổi là thay con trỏ" này gắn kết tính nguyên tử, cách ly và time travel sẽ giải thích dưới đây thành một cơ chế nhất quán.

graph TD
    Catalog["Catalog<br/>Bảng → vị trí metadata hiện tại"]
    Meta["metadata.json<br/>Lược đồ, partition spec, danh sách snapshot"]
    S1["Snapshot S1 (quá khứ)"]
    S2["Snapshot S2 (hiện tại)"]
    ML["Manifest List<br/>Danh sách manifest theo snapshot + phạm vi phân vùng"]
    M1["Manifest A"]
    M2["Manifest B"]
    D1["data-0001.parquet"]
    D2["data-0002.parquet"]
    D3["data-0003.parquet"]
    Catalog --> Meta
    Meta --> S1
    Meta --> S2
    S2 --> ML
    ML --> M1
    ML --> M2
    M1 --> D1
    M1 --> D2
    M2 --> D3

Catalog là con trỏ cấp cao nhất ánh xạ tên bảng tới vị trí của metadata.json đang có hiệu lực. Tính nguyên tử của giao dịch được bảo đảm chính tại điểm này. Tác vụ ghi chuẩn bị xong cả tệp dữ liệu mới lẫn metadata mới, rồi vào khoảnh khắc cuối cùng thay thế nguyên tử con trỏ của catalog từ metadata cũ sang metadata mới (compare-and-swap). Trước khi phép hoán đổi này thành công, không bên đọc nào thấy dữ liệu mới; ngay khi thành công, toàn bộ thay đổi hiện ra cùng lúc. Các hiện thực catalog gồm Hive Metastore, AWS Glue, JDBC, Nessie và REST Catalog được chuẩn hóa năm 2024; REST Catalog tách engine với catalog bằng giao thức HTTP, nâng cao đáng kể khả năng tương tác.

Tệp metadata (metadata.json) chứa lược đồ hiện tại, partition spec, thứ tự sắp xếp của bảng và danh sách mọi snapshot đã tạo đến nay. Mỗi snapshot biểu diễn trạng thái hoàn chỉnh của bảng tại một thời điểm cụ thể, và lịch sử snapshot này là căn cứ cho time travel và rollback.

Manifest List là danh sách các tệp manifest cấu thành một snapshot, đồng thời lưu phạm vi giá trị phân vùng (cận dưới, cận trên) mà mỗi manifest bao phủ. Nhờ vậy, engine truy vấn có thể bỏ qua toàn bộ các manifest không liên quan chỉ bằng phạm vi phân vùng mà chưa cần mở chúng.

Manifest chứa danh sách các tệp dữ liệu thực tế cùng thống kê theo cột (giá trị nhỏ nhất/lớn nhất, số null, số bản ghi) của từng tệp. Thống kê ở mức tệp này là cốt lõi hiệu năng của Iceberg: engine loại bỏ (file pruning) các tệp không có khả năng thỏa điều kiện như WHERE price > 1000 chỉ bằng cách xem thống kê.

3. Các chức năng cốt lõi và nguyên lý hoạt động

A. Phân vùng ẩn (Hidden Partitioning)

Trong bảng Hive truyền thống, người dùng phải nhận biết cột phân vùng về mặt vật lý và ghi rõ trong truy vấn. Chẳng hạn, để tạo phân vùng theo ngày từ timestamp sự kiện, phải duy trì một cột event_date riêng, và trong truy vấn cũng phải đưa trực tiếp cột phân vùng vào điều kiện như WHERE event_date = '2026-09-19' thì partition pruning mới hoạt động. Nếu người dùng lỡ chỉ viết WHERE event_time BETWEEN ... thì không dùng được phân vùng và xảy ra quét toàn bộ — một cái bẫy phổ biến và chết người.

Phân vùng ẩn của Iceberg định nghĩa phân vùng bằng hàm biến đổi (transform) trên cột gốc. Khi khai báo như days(event_time), bucket(16, user_id), truncate(10, zipcode), Iceberg tự động tính giá trị phân vùng khi ghi và lưu vào metadata; khi đọc, dù người dùng chỉ lọc theo cột gốc (event_time), engine biết quan hệ biến đổi nên tự áp dụng partition pruning. Nói cách khác, sự tồn tại của phân vùng trở nên trong suốt (bị ẩn) đối với người dùng, ngăn chặn về mặt cấu trúc sự cố hiệu năng sụp đổ do dùng sai cột phân vùng. Trong thực tế, khi phân vùng bảng log dung lượng lớn bằng days(ts), lúc tra cứu dữ liệu một ngày chỉ cần quét các tệp của ngày đó trong hàng nghìn tệp, rút ngắn thời gian phản hồi từ hàng chục phút xuống vài giây.

Một lợi ích khác của thiết kế này là loại bỏ việc lưu trùng lặp cột phân vùng. Cách của Hive phải lưu trữ và duy trì vật lý một cột event_date riêng ngoài timestamp gốc để chứa giá trị phân vùng, và nếu cột dẫn xuất này lệch với bản gốc thì dẫn đến sự cố chất lượng dữ liệu. Iceberg chỉ khai báo biểu thức biến đổi trong metadata nên không cần cột dẫn xuất, và dù tiến hóa định nghĩa phân vùng (ví dụ: days→hours) cũng không động đến dữ liệu đã lưu. Đây là sự chuyển đổi tư duy trừu tượng hóa phân vùng từ "bố trí thư mục vật lý" thành "quy tắc lập chỉ mục logic", có thể coi là hiện thực phiên bản data lake của tính độc lập dữ liệu vật lý, nơi người dùng đạt hiệu năng tối ưu mà không cần biết cấu trúc lưu trữ vật lý.

B. Tiến hóa lược đồ và phân vùng (Evolution)

Iceberg theo dõi cột bằng ID duy nhất thay vì tên. Nhờ thiết kế này, có thể thực hiện an toàn việc thêm, xóa, đổi tên, đổi thứ tự cột và mở rộng kiểu (int→long...) chỉ bằng cách thay đổi metadata mà không ghi lại tệp dữ liệu. Ví dụ, dù đổi tên cột thì ID vẫn giữ nguyên nên ánh xạ với các tệp dữ liệu cũ không bị phá vỡ. Ngược lại, Hive ánh xạ cột theo vị trí (số thứ tự), nên khi xóa một cột ở giữa, dữ liệu của các cột phía sau bị dịch và đọc sai là sự cố thường gặp.

Tiến hóa phân vùng là chức năng tiến thêm một bước. Khi dữ liệu tăng và cần đổi chiến lược phân vùng từ days sang hours, Iceberg thêm partition spec mới mà không ghi lại dữ liệu hiện có. Chỉ dữ liệu ghi sau đó mới theo spec mới, và manifest ghi lại mỗi tệp được ghi bằng partition spec nào, nên dù trong một bảng tồn tại song song các tệp có cách phân vùng khác nhau, truy vấn vẫn hoạt động chính xác. Đây là lợi thế vận hành rất lớn, cho phép thay đổi chiến lược phân vùng của bảng cỡ petabyte mà không có thời gian ngừng hoạt động.

Khả năng tiến hóa này quan trọng vì thực tế là mô hình dữ liệu chắc chắn thay đổi theo thời gian. Khi doanh nghiệp tăng trưởng, phân vùng theo ngày làm tệp quá lớn, quy định mới buộc phải thêm cột, và sẽ đến lúc phải mở rộng kiểu đã thiết kế sai. Trong data lake truyền thống, mỗi thay đổi như vậy đồng nghĩa với lô ghi lại toàn bộ kéo dài hàng giờ đến hàng ngày và gián đoạn dịch vụ trong thời gian đó; Iceberg hạ cấp chúng thành giao dịch metadata, cho phép "tái cấu trúc (refactor) dần dần mô hình dữ liệu như mã nguồn". Đây là yếu tố nâng Iceberg từ một định dạng tệp đơn thuần thành khung quản lý cho các bảng tồn tại lâu dài.

C. Cách ly snapshot, time travel và rollback

Cấu trúc snapshot đã nói ở trên tự nhiên cung cấp cách ly khả tuần tự (serializable isolation). Bên đọc đọc nhất quán snapshot tại thời điểm bắt đầu truy vấn cho đến cuối, còn bên ghi chỉ tạo snapshot mới và thay con trỏ catalog mà không làm hỏng snapshot hiện có. Do đó, đọc và ghi không chặn lẫn nhau (tương tự MVCC).

Lịch sử snapshot này dẫn trực tiếp đến time travel và rollback. Có thể truy vấn nguyên trạng bảng tại thời điểm quá khứ như SELECT * FROM tbl FOR TIMESTAMP AS OF '2026-09-18 00:00:00', hoặc đưa ngay một lần nạp lô sai về snapshot trước. Một ứng dụng tiêu biểu trong thực tế là khi ETL ban đêm nạp dữ liệu sai, dùng rollback_to_snapshot để khôi phục trạng thái bình thường trong vài giây mà không cần khôi phục bản sao lưu.

Time travel vượt qua chức năng tiện lợi đơn thuần để giải quyết bài toán lâu đời của kỹ thuật dữ liệu là khả năng tái lập (reproducibility) dữ liệu. Ví dụ, nếu cố định trạng thái dữ liệu tại thời điểm huấn luyện mô hình học máy bằng ID snapshot, thì vài tháng sau vẫn có thể tái lập thí nghiệm với chính xác cùng dữ liệu huấn luyện, hoặc tách bạch làm rõ nguyên nhân suy giảm hiệu năng mô hình là do thay đổi dữ liệu hay thay đổi mã. Ngoài ra, nó hỗ trợ đọc tăng dần (incremental read) chỉ lấy phần chênh lệch giữa hai snapshot, nên có thể tiêu thụ CDC hiệu quả: chỉ chuyển các bản ghi mới thêm/thay đổi kể từ lần xử lý cuối sang pipeline hạ nguồn mà không quét lại toàn bảng.

sequenceDiagram
    participant W as Writer_Spark
    participant S as Storage_S3
    participant C as Catalog
    participant R as Reader_Trino
    R->>C: Tra cứu vị trí metadata hiện tại
    C-->>R: Trả về metadata (snapshot S2)
    W->>S: Ghi tệp data mới + Manifest + metadata (S3)
    Note over R,S: Reader vẫn đang đọc S2 một cách nhất quán
    W->>C: Yêu cầu hoán đổi CAS S2 → S3
    C-->>W: Thành công (hoàn tất commit nguyên tử)
    R->>C: Tra cứu lại ở truy vấn kế tiếp → giờ thấy S3

D. Thay đổi mức hàng và compaction (MoR/CoW)

Để hiện thực UPDATE, DELETE, MERGE trên ràng buộc tệp object storage là bất biến (immutable), Iceberg cung cấp hai chiến lược. CoW (Copy-on-Write) ghi lại toàn bộ tệp dữ liệu bị thay đổi chạm tới để có ngay tính nhất quán; đọc nhanh nhưng dù thay đổi nhỏ cũng phải ghi lại cả tệp nên chi phí ghi lớn. MoR (Merge-on-Read) ghi phần thay đổi vào tệp xóa (position/equality delete) riêng rồi hợp nhất khi đọc; ghi nhẹ nhưng có chi phí hợp nhất khi đọc. Với cập nhật nhỏ và thường xuyên như streaming CDC thì MoR có lợi, còn với cập nhật lớn chủ yếu theo lô thì CoW có lợi.

MoR và nạp streaming tất yếu sinh ra vấn đề tệp nhỏ (small file). Khi tệp bị chia vụn, manifest phình to và chi phí quét tăng. Giải pháp là compaction: dùng rewrite_data_files để gộp tệp nhỏ thành tệp lớn và expire_snapshots để dọn các snapshot cũ cùng tệp dữ liệu chỉ được chúng tham chiếu, qua đó quản lý chi phí lưu trữ và kích thước metadata. Mức độ tự động hóa các tác vụ bảo trì bảng (maintenance) này quyết định chất lượng vận hành thực tế.

Cụ thể, một bảng streaming nhận hàng nghìn bản ghi mỗi giây sẽ tạo tệp vài MB ở mỗi lần commit và chỉ trong một ngày có thể phình lên hàng chục nghìn đến hàng trăm nghìn tệp. Khi đó hiệu năng truy vấn bị chi phối bởi số lượng tệp chứ không phải tổng dung lượng dữ liệu, vì mỗi tệp cần ít nhất một yêu cầu GET và phân tích metadata. Hướng dẫn thực tế thường là lên lịch compaction định kỳ để duy trì tệp dữ liệu ở mức 128MB~512MB, đồng thời thực hiện hợp nhất vật lý tệp xóa vào tệp dữ liệu để khôi phục hiệu năng đọc của bảng MoR. Ngoài ra, khi bản thân manifest nhiều lên thì dùng rewrite_manifests để tái cấu trúc manifest, giảm thời gian lập kế hoạch truy vấn. Như vậy, cần nhận thức rõ rằng hiệu năng của Iceberg không tự có "vì định dạng tốt" mà chỉ được duy trì khi liên tục vận hành pipeline bảo trì.

4. So sánh: Iceberg vs Delta Lake vs Hudi vs Hive

Ba định dạng bảng mở (Iceberg, Delta Lake, Hudi) đều có chung mục tiêu gán ACID cho data lake, nhưng khác nhau về nguồn gốc và thế mạnh. Bảng dưới đây là phần tổng hợp bổ trợ, còn lý do tạo nên khác biệt được trình bày tiếp theo.

Phân loại Hive (truyền thống) Apache Iceberg Delta Lake Apache Hudi
Đơn vị theo dõi Thư mục (đường dẫn) Danh sách tệp (metadata) Nhật ký giao dịch (JSON) Timeline + chỉ mục
ACID Không bảo đảm Snapshot + CAS Nhật ký giao dịch Commit theo timeline
Tiến hóa phân vùng Cần ghi lại Hỗ trợ (không ghi lại) Hạn chế Hạn chế
Phân vùng ẩn Không có Hỗ trợ Không có (cần generated column) Không có
Thế mạnh Tương thích hệ thống cũ Trung lập engine, quy mô lớn Gắn chặt hệ sinh thái Spark Upsert streaming

Khác biệt căn bản giữa Hive và ba định dạng còn lại là "liệt kê thư mục hay theo dõi metadata". Hive liệt kê danh sách tệp từ kho lưu trữ theo thời gian thực nên càng nhiều tệp càng chậm và không có tính nguyên tử. Ngược lại, ba định dạng mở quản lý tường minh danh sách tệp bằng metadata để giải quyết vấn đề này.

Để minh họa khác biệt này thể hiện thế nào trên hiệu năng đo thực tế: khi tra cứu dữ liệu một ngày cụ thể trong bảng gồm 1 triệu tệp, Hive liệt kê đệ quy các thư mục liên quan, phát sinh hàng chục nghìn đến hàng trăm nghìn lời gọi API lưu trữ, có thể mất vài phút chỉ để lập kế hoạch truy vấn. Ngược lại, Iceberg bỏ qua các manifest không liên quan bằng phạm vi phân vùng trong manifest list và loại các tệp dữ liệu không thỏa điều kiện bằng thống kê cột trong manifest, nên chỉ giữ lại số ít tệp thực sự cần đọc và hoàn tất lập kế hoạch trong vài giây. Kết hợp file pruning dựa trên thống kê mức tệp này với sắp xếp và phân cụm Z-order gom dữ liệu theo thứ tự giá trị, lượng dữ liệu mà truy vấn phải đọc giảm mạnh, cải thiện đồng thời chi phí (tính phí theo byte quét) và thời gian phản hồi.

Khác biệt giữa Iceberg và Delta Lake trở nên rõ ràng khi hiểu như sự đánh đổi trung lập đối lập với tích hợp. Iceberg ngay từ đầu được thiết kế như đặc tả mở (spec) không phụ thuộc engine cụ thể, nên mạnh trong môi trường đa engine nơi nhiều engine đọc ghi cùng một bảng một cách bình đẳng. Thực tế, khi các nhà cung cấp lớn như Snowflake, Google BigQuery, AWS lấy Iceberg làm chuẩn, nó đã củng cố vị thế chuẩn công nghiệp trên thực tế (việc Databricks mua lại Tabular và Snowflake mở mã nguồn catalog Polaris năm 2024 là biểu tượng của xu hướng này). Delta Lake tích hợp sâu với hệ sinh thái Spark/Databricks nên có mức tối ưu và độ trưởng thành tính năng cao trong môi trường đó, nhưng về lịch sử có sự phụ thuộc engine (sau đó được bổ sung khả năng tương tác bằng Delta UniForm). Hudi chuyên về upsert dựa trên chỉ mục, thể hiện thế mạnh trong nạp streaming CDC. Do đó, nếu ưu tiên hàng đầu là đa engine và trung lập nhà cung cấp thì Iceberg, nếu lấy Databricks làm trung tâm thì Delta, còn nếu upsert streaming tần suất cao là cốt lõi thì Hudi là lựa chọn hợp lý.

5. Chuyên sâu: Xu hướng chuẩn hóa và áp dụng thực tế

Xu hướng quan trọng nhất gần đây quanh Iceberg là chuẩn hóa catalog và tăng cường tính trung lập nhà cung cấp. Năm 2024, khi cộng đồng Iceberg ổn định đặc tả REST Catalog, engine và catalog giao tiếp bằng giao thức chuẩn dựa trên HTTP, giảm đáng kể sự phụ thuộc vào một hiện thực catalog cụ thể. Cùng năm, Snowflake công bố mã nguồn mở Polaris Catalog hiện thực đặc tả REST, còn Databricks mua lại Tabular, công ty hỗ trợ thương mại của Iceberg. Điều này cho thấy thị trường đang hội tụ theo hướng các nhà cung cấp data warehouse chấp nhận Iceberg làm tầng lưu trữ chung thay vì định dạng đóng riêng. Từ góc độ Kỹ sư chuyên nghiệp (Professional Engineer), xu hướng này có thể được diễn giải là việc hiện thực hóa kiến trúc dữ liệu mở (open data architecture) — tức mô thức "một bản dữ liệu được nhiều engine chia sẻ mà không cần sao chép".

Về đặc tả kỹ thuật, thảo luận về Iceberg V3 đang diễn ra, bao gồm cải thiện hiệu năng MoR bằng vectơ xóa (deletion vector), theo dõi dòng dõi hàng (row lineage) và hỗ trợ kiểu dữ liệu mới như hình học (geometry), kiểu biến thể (variant). Vectơ xóa hướng tới giảm chi phí hợp nhất so với tệp xóa theo vị trí hiện có, qua đó giảm chi phí đọc của MoR.

Về tình huống áp dụng thực tế, kiến trúc điển hình là lưu trữ đơn nhất, đa engine: một doanh nghiệp thương mại điện tử lớn nạp trung bình hàng tỷ sự kiện clickstream mỗi ngày vào S3 dưới dạng Iceberg, dùng Flink nạp thời gian thực (MoR), Trino cho phân tích ad-hoc và Spark cho compaction lô ban đêm. Khi đó, truy vấn dữ liệu một ngày tránh quét toàn bộ nhờ phân vùng ẩn days(event_time) và pruning theo thống kê tệp, lần nạp sai được khôi phục bằng rollback snapshot, và chi phí lưu trữ được kiểm soát bằng expire_snapshots. Trong ngành tài chính, nó còn được dùng để tái lập và kiểm toán dữ liệu tại một thời điểm quyết toán cụ thể bằng time travel nhằm đáp ứng quy định.

Liên kết với pipeline AI/ML cũng là lĩnh vực tăng trưởng nhanh. Khi chọn Iceberg làm kho lưu trữ ngoại tuyến của feature store, có thể cố định snapshot của các đặc trưng dùng để huấn luyện nhằm bảo đảm khả năng tái lập, và dùng đọc tăng dần để cập nhật hiệu quả chỉ các đặc trưng mới. Hơn nữa, khi các nhà cung cấp data warehouse chấp nhận Iceberg làm tầng chung, cấu trúc trong đó công cụ BI, engine SQL và framework ML cùng tiêu thụ một dữ liệu mà không cần sao chép đang trở thành hiện thực. Đây là hướng loại bỏ sự kém hiệu quả khi dữ liệu bị lưu trùng và đồng bộ giữa warehouse và lake vốn tách đôi lâu nay, nhắm đồng thời tới giảm tổng chi phí sở hữu (TCO) và nâng cao tính nhất quán dữ liệu.

6. Những điểm cần lưu ý và hàm ý

Kỹ sư chuyên nghiệp (Professional Engineer) khi xem xét đưa Iceberg vào cần tổng hợp các góc độ chiến lược và kỹ thuật sau.

  • Lựa chọn catalog là quyết định cốt lõi của kiến trúc. Vì tính nguyên tử của giao dịch phụ thuộc vào CAS của catalog, nếu muốn tương tác đa engine và tránh phụ thuộc nhà cung cấp thì ưu tiên xem xét dựa trên REST Catalog; nếu là hệ sinh thái AWS hiện có thì Glue, nếu là hybrid/on-premise thì Nessie, JDBC..., lựa chọn theo môi trường vận hành nhưng phải đánh giá đồng thời khả năng di chuyển (portability).

  • Thiết kế CoW/MoR và compaction như sự đánh đổi giữa hiệu năng và chi phí. Nếu khối lượng công việc là cập nhật lớn theo lô thì chọn CoW, nếu là cập nhật nhỏ và thường xuyên kiểu streaming thì chọn MoR; khi dùng MoR nhất thiết phải đưa vào pipeline tự động hóa compaction định kỳ và hết hạn snapshot để bù trừ sự tích tụ tệp nhỏ. Nếu lơ là, hiệu năng truy vấn suy giảm và chi phí lưu trữ bùng nổ sẽ xảy ra cùng lúc.

  • Tận dụng làm đòn bẩy cho quản trị dữ liệu và đáp ứng quy định. Time travel và lịch sử snapshot cung cấp dấu vết kiểm toán, khả năng tái lập và rollback, nhưng ngược lại nếu lưu giữ snapshot cũ vô thời hạn thì có thể xung đột với nghĩa vụ hủy dữ liệu cá nhân (quyền xóa theo GDPR và Luật Bảo vệ thông tin cá nhân của Hàn Quốc). Vì vậy, cần chính sách hóa thời gian lưu giữ snapshot cho khớp với yêu cầu quy định, và kiểm chứng quy trình hết hạn/dọn dẹp để bảo đảm việc xóa vật lý chắc chắn được thực hiện.

  • Định vị như chuẩn lưu trữ cho quá trình chuyển đổi sang lakehouse. Iceberg tự thân không phải là giải pháp hoàn chỉnh, mà chỉ tạo ra giá trị khi kết hợp với engine truy vấn (Trino, Spark, Flink), catalog, công cụ dòng dõi và chất lượng dữ liệu. Việc đưa vào cần được tiếp cận như thiết kế nền tảng bao gồm quản lý metadata, quản trị và tự động hóa vận hành chứ không chỉ là chấp nhận một định dạng, và chiến lược chuyển dần các bảng Hive hiện có bằng di chuyển tại chỗ (add_files, snapshot) sẽ giảm rủi ro.

  • Phản ánh xung đột đồng thời và thử lại commit vào thiết kế. Khi nhiều tác vụ cùng ghi vào một bảng, một bên sẽ thất bại ở phép hoán đổi CAS của catalog và phải thử lại. Vì đây là kiểm soát đồng thời lạc quan, ở các khối lượng công việc có tần suất xung đột cao (nhiều writer streaming dồn vào cùng phân vùng), việc thử lại commit diễn ra thường xuyên có thể làm giảm thông lượng. Cần thiết kế giảm xung đột bằng cách tách writer theo phân vùng, gom lô commit hoặc điều chỉnh số writer; đây là vùng phán đoán của Kỹ sư chuyên nghiệp am hiểu sự đánh đổi của giao dịch phân tán.

  • Triển vọng: hội tụ về kiến trúc dữ liệu mở. Với việc các nhà cung cấp lớn chấp nhận Iceberg, nền tảng dữ liệu tương lai nhiều khả năng sẽ tiến hóa theo hướng "chỉ lưu một bản dữ liệu và các engine phân tích, AI, BI cùng chia sẻ". Iceberg có nhiều dư địa trở thành nền tảng chung trong lưu trữ đặc trưng của pipeline AI/ML và liên kết với dữ liệu vectơ, nên việc thiết kế chiến lược dữ liệu của tổ chức trên chuẩn mở thay vì một nhà cung cấp cụ thể sẽ có lợi cho việc bảo đảm tính linh hoạt dài hạn.

Tài liệu tham khảo

Tóm tắt một câu: Apache Iceberg là định dạng bảng mở trung lập với engine, gán ACID dựa trên snapshot, phân vùng ẩn, tiến hóa lược đồ và time travel cho tập hợp tệp trên object storage, và là tầng lưu trữ chuẩn trên thực tế của lakehouse không phụ thuộc nhà cung cấp.