Căn nhà trên hồ đã xây xong, rồi người ta phát hiện mình bị nhốt bên trong

Ở bài trước, chúng ta đã nói về Lakehouse 1.0.

Ý tưởng khi đó khá dễ hiểu.

Data lake là một cái hồ rất rộng, chứa được đủ thứ từ hóa đơn, log máy chủ, hình ảnh cho đến âm thanh tổng đài. Data warehouse là một căn nhà ngăn nắp, nơi dữ liệu được xếp thành bảng để chạy SQL và làm báo cáo.

Lakehouse 1.0 cố gắng xây căn nhà ngay trên mặt hồ:

1Object Storage
2    ↓
3Parquet
4    ↓
5Table Format
6    ↓
7Compute Engine
8    ↓
9Bronze → Silver → Gold

Ta không cần mỗi đêm chở dữ liệu từ hồ sang một nhà kho khác.

Ta có thể giữ dữ liệu trên object storage, đặt transaction log và metadata lên trên, sau đó dùng Spark hoặc một SQL engine để xử lý.

Nghe rất hợp lý.

Và nó thực sự giải quyết được nhiều vấn đề.

Nhưng sau vài năm sống trong căn nhà ấy, người ta bắt đầu nhận ra một chuyện hơi kỳ lạ.

Cửa sổ là kính mở.

Sàn nhà là Parquet mở.

Nước dưới hồ cũng nằm trong object storage của mình.

Nhưng chìa khóa cửa, bản đồ căn nhà, sổ hộ khẩu và hệ thống điện lại thường thuộc về một nền tảng duy nhất.

Muốn thay bóng đèn phải gọi đúng người.

Muốn đổi bếp phải dùng đúng hãng.

Muốn mời một compute engine khác vào nhà, nó phải học cách nói chuyện với metadata, catalog và cơ chế bảo mật của chủ nhà cũ.

Lakehouse 1.0 mở dữ liệu ở tầng file.

Nhưng nhiều hệ thống vẫn còn đóng ở tầng metadata, catalog, governance và compute.

Từ khoảng năm 2024, kiến trúc Lakehouse bắt đầu bước sang một giai đoạn khác.

Không phải xây một căn nhà lớn hơn.

Mà là tháo căn nhà thành những mảnh Lego, quy định rõ đầu nối giữa chúng, để người dùng có thể thay từng bộ phận mà không phải đập cả công trình.

Trong bài viết này, mình gọi giai đoạn đó là Lakehouse 2.0.

Lakehouse 2.0 có phải một tiêu chuẩn chính thức không?

Cần nói rõ ngay từ đầu:

Lakehouse 2.0 không phải một đặc tả chính thức của Apache, cũng không phải phiên bản phần mềm được toàn ngành thống nhất.

Không có một tài liệu nào quy định rằng hệ thống phải có đúng bảy thành phần, vượt qua bài kiểm tra rồi mới được dán nhãn Lakehouse 2.0.

Đây là cách gọi dùng để mô tả một hướng tiến hóa của kiến trúc Lakehouse sau năm 2024:

• Open table format trở thành nền tảng chung.
• Nhiều compute engine cùng đọc và ghi một bản dữ liệu.
• Catalog trở thành một giao diện mở.
• Storage bắt đầu hiểu khái niệm bảng.
• Streaming và batch tiến lại gần nhau.
• Governance không còn bị gắn chặt vào một engine duy nhất.
• Dữ liệu có thể được truy cập xuyên cloud và xuyên nền tảng mà không nhất thiết phải sao chép.

Một số bài viết mô tả Lakehouse 2.0 là sự chuyển đổi từ kiến trúc tích hợp dọc sang một hệ thống mở, có thể lắp ghép và hỗ trợ nhiều engine như Spark, Flink, Trino, DuckDB hoặc các engine thương mại khác. (Modern Data 101)

Có thể tóm gọn bằng một câu:

Lakehouse 1.0 mở nơi dữ liệu được lưu. Lakehouse 2.0 cố gắng mở cả cách dữ liệu được hiểu, quản lý và sử dụng.

Vấn đề còn lại của Lakehouse 1.0

File mở nhưng cách hiểu file vẫn có thể bị khóa

Giả sử dữ liệu bán hàng nằm trong Parquet trên S3.

Về lý thuyết, đó là dữ liệu mở.

Ta có thể tải file về.

Ta có thể đọc bằng Python.

Ta có thể dùng nhiều thư viện để mở nó.

Nhưng một bảng Lakehouse không chỉ có file Parquet.

Nó còn có:

• Danh sách file nào đang thuộc bảng.
• Snapshot hiện tại.
• Transaction nào đã commit.
• Schema đang có hiệu lực.
• Partition được tổ chức thế nào.
• File nào đã bị xóa về mặt logic.
• Chính sách ai được đọc và ai được ghi.

Những thông tin này nằm trong table metadata và catalog.

Nếu engine khác đọc được Parquet nhưng không hiểu metadata, nó giống một người nhìn thấy hàng triệu thùng hàng mà không có sổ kho.

Hàng ở ngay trước mắt.

Nhưng không biết thùng nào còn hiệu lực, thùng nào đã bị trả lại, thùng nào thuộc phiên bản hôm qua.

Mở file là chưa đủ.

Các hệ thống còn phải thống nhất cách hiểu cái bảng.

Một engine thường trở thành trung tâm vũ trụ

Trong nhiều kiến trúc Lakehouse đời đầu, một hệ sinh thái thường được xây quanh một engine chính.

Ví dụ:

1Storage
2   ↓
3Table Format
4   ↓
5Catalog
6   ↓
7Engine chính
8   ↓
9Mọi workload còn lại

ETL dùng engine đó.

SQL dùng engine đó.

Streaming cũng cố chạy trên engine đó.

Machine Learning lại đi qua một bộ thư viện của hệ sinh thái đó.

Cách thiết kế này có một lợi thế rất lớn: mọi thành phần được tối ưu cùng nhau.

Nhưng nó cũng tạo ra một vấn đề.

Khi một workload khác xuất hiện, ví dụ:

• Dashboard cần phản hồi trong vài trăm mili giây.
• Streaming cần xử lý liên tục.
• Một analyst muốn chạy DuckDB trên laptop.
• Một hệ thống realtime muốn dùng ClickHouse.
• Một nhóm khác muốn dùng Trino.
• Một ứng dụng chỉ cần đọc vài MB dữ liệu.

Ta vẫn có xu hướng kéo tất cả vào cùng một động cơ khổng lồ.

Nó giống việc gia đình mua được một chiếc xe tải rất mạnh, sau đó dùng nó cho mọi việc:

• Chở hàng.
• Đưa con đi học.
• Đi mua rau.
• Chạy ra đầu hẻm lấy một ly cà phê.

Xe tải làm được hết.

Chỉ là mỗi lần khởi động, hàng tỷ electron phải chạy qua con chip, động cơ gầm lên, tiền điện hóa thành nhiệt, hệ thống làm mát bắt đầu thở như một con trâu vừa chạy qua ba cánh đồng.

Streaming và batch vẫn là hai dòng sông riêng

Lakehouse 1.0 chủ yếu trưởng thành từ thế giới batch.

Dữ liệu được gom lại.

Job bắt đầu chạy.

Job đọc Bronze.

Job tạo Silver.

Một job khác tạo Gold.

100:00: Chốt dữ liệu
201:00: Chạy Bronze
302:00: Chạy Silver
404:00: Chạy Gold
506:00: Dashboard có dữ liệu

Trong khi đó, thế giới vận hành lại sống bằng những sự kiện xảy ra liên tục:

• Khách vừa đặt hàng.
• Kho vừa hết sản phẩm.
• Giá vừa thay đổi.
• Một giao dịch vừa bị hủy.
• Xe giao hàng vừa đổi trạng thái.
• Một khách hàng vừa bấm vào chiếc máy lạnh thứ mười bảy.

Để đưa dữ liệu từ Kafka hoặc database vào Lakehouse, doanh nghiệp thường phải tự xây một đoàn pipeline:

 1Database WAL
 2    ↓
 3Debezium
 4    ↓
 5Kafka
 6    ↓
 7Kafka Connect
 8    ↓
 9Streaming Job
10    ↓
11Parquet
12    ↓
13Table Metadata
14    ↓
15Compaction

Mỗi mũi tên là thêm một điểm có thể ngã.

Mỗi điểm ngã là thêm một dashboard đỏ.

Mỗi dashboard đỏ là thêm một cuộc điện thoại có câu mở đầu:

Em kiểm tra giúp anh dữ liệu realtime sao đứng từ sáng tới giờ.

Giai đoạn 2024–2026: các mảnh ghép bắt đầu đổi chỗ

Lakehouse 2.0 không xuất hiện bởi một sản phẩm duy nhất.

Nó hình thành từ nhiều sự kiện xảy ra gần nhau trong ngành dữ liệu.

Năm 2024: catalog và streaming bắt đầu mở cửa

Tháng 3 năm 2024, Confluent giới thiệu Tableflow với mục tiêu biến Kafka topic cùng schema của nó thành bảng Apache Iceberg hoặc Delta Lake. Thay vì tự viết pipeline chuyển Avro, JSON hoặc Protobuf thành Parquet rồi tự quản lý table metadata, hệ thống streaming có thể trực tiếp tạo ra bảng để các công cụ phân tích sử dụng. (Confluent)

Tháng 6 năm 2024, Databricks công bố mã nguồn mở Unity Catalog với OpenAPI, khả năng tương thích Iceberg REST Catalog API, hỗ trợ nhiều định dạng và nhiều engine. Catalog không còn chỉ là một cuốn sổ nằm kín trong một nền tảng; nó bắt đầu được trình bày như một giao diện mà các hệ thống bên ngoài có thể nói chuyện cùng. (Databricks)

Tháng 8 năm 2024, Apache Polaris bước vào Apache Incubator. Polaris được xây như một catalog mã nguồn mở cho Apache Iceberg, triển khai Iceberg REST API và hướng tới khả năng nhiều engine cùng truy cập một nguồn metadata thống nhất. (Apache Incubator)

Tháng 11 năm 2024, AWS giới thiệu khả năng đưa CDC từ PostgreSQL và MySQL vào Apache Iceberg trên S3 bằng Data Firehose. Ý tưởng quan trọng ở đây không phải tên dịch vụ, mà là việc thay đổi trong database có thể liên tục chảy thành các bản ghi Iceberg thay vì chờ một batch ETL ban đêm. (Amazon Web Services, Inc.)

Đến tháng 12 năm 2024, Amazon giới thiệu S3 Tables, đưa khái niệm bảng Apache Iceberg xuống gần hơn với chính lớp object storage. Storage không chỉ giữ object nữa mà bắt đầu đảm nhiệm một phần công việc vận hành bảng. (Amazon Web Services, Inc.)

Năm 2025: “open” bắt đầu đi cùng “managed”

Tháng 3 năm 2025, Tableflow hỗ trợ Iceberg ở trạng thái General Availability, cho phép Kafka topic được biểu diễn thành bảng Iceberg để các engine phân tích và AI truy cập. Hệ thống cũng xử lý chuyển đổi kiểu dữ liệu, schema evolution và việc sinh metadata tương ứng. (Confluent)

Tháng 5 năm 2025, Google công bố hướng phát triển BigLake thành một storage engine cho Iceberg Lakehouse. BigQuery có thể đọc và ghi bảng Iceberg, trong khi lớp storage bổ sung streaming, quản lý bảng và tự động reclustering. (Google Cloud)

Đây là một thay đổi đáng chú ý.

Trước đây, người dùng thường phải lựa chọn:

1Mở nhưng phải tự vận hành

hoặc:

1Được quản lý nhưng bị khóa

Đến giai đoạn này, các nhà cung cấp bắt đầu cố gắng bán một lựa chọn thứ ba:

1Định dạng mở
2+
3Dịch vụ được quản lý

Tất nhiên, “mở” không có nghĩa là hoàn toàn không phụ thuộc nhà cung cấp.

Nhưng ít nhất dữ liệu và metadata bắt đầu có những giao diện chuẩn để hệ thống khác tiếp cận.

Năm 2026: catalog trở thành đường biên giữa các cloud

Tháng 2 năm 2026, Apache Polaris tốt nghiệp khỏi Apache Incubator và trở thành Apache Top-Level Project. Đây là một tín hiệu cho thấy catalog mở và Iceberg REST API không còn là một thử nghiệm nhỏ ở góc phòng, mà đã trở thành một mảnh ghép nghiêm túc của hệ sinh thái Lakehouse. (Apache Polaris)

Đến tháng 4 năm 2026, Google mô tả kiến trúc Cross-cloud Lakehouse dựa trên Iceberg REST Catalog, catalog federation và khả năng khám phá hoặc chia sẻ dữ liệu giữa nhiều nền tảng như AWS Glue, Databricks, Snowflake và SAP. (Google Cloud)

Nhìn lại chuỗi sự kiện từ 2024 đến 2026, ta thấy một đường đi khá rõ:

 1File mở
 2    ↓
 3Table format mở
 4    ↓
 5Catalog mở
 6    ↓
 7Nhiều engine
 8    ↓
 9Streaming trực tiếp vào bảng
10    ↓
11Storage tự quản lý bảng
12    ↓
13Truy cập xuyên nền tảng

Lakehouse 2.0 không sinh ra từ một bài công bố duy nhất.

Nó mọc lên từ việc các lớp trong hệ thống lần lượt bị buộc phải mở cửa cho nhau.

Kiến trúc Lakehouse 2.0

Một kiến trúc đơn giản có thể được hình dung như sau:

 1                  NGUỒN DỮ LIỆU
 2
 3      Database        Kafka        File/API
 4          |              |             |
 5          +------- CDC / Streaming ----+
 6                         |
 7                         v
 8
 9             OPEN TABLE STORAGE LAYER
10
11          Object Storage / Table Storage
12                         |
13            Parquet + Open Table Format
14          Iceberg / Delta Lake / Apache Hudi
15                         |
16                         v
17
18                  OPEN CATALOG LAYER
19
20       Iceberg REST Catalog / Unity / Polaris
21        Namespace / Metadata / Access / Audit
22                         |
23                         v
24
25               COMPOSABLE COMPUTE LAYER
26
27       Spark    Flink    Trino    DuckDB
28       SQL Engine    Realtime Engine    AI
29                         |
30                         v
31
32               DATA PRODUCT / SEMANTIC LAYER
33
34       Bronze → Silver → Gold → Metrics
35       Feature / Vector / Model / Document
36                         |
37                         v
38
39             BI / APP / AGENT / ANALYTICS

Điểm khác biệt lớn nhất không nằm ở việc sơ đồ có thêm nhiều hộp.

Điểm khác biệt nằm ở đường nối giữa các hộp.

Trong Lakehouse 1.0, nhiều đường nối là dây điện riêng của nhà sản xuất.

Trong Lakehouse 2.0, người ta cố biến chúng thành những ổ cắm tiêu chuẩn.

Open table format trở thành hợp đồng của dữ liệu

Ở Lakehouse 1.0, người ta thường nói:

Dữ liệu của tôi là Parquet nên nó mở.

Đến Lakehouse 2.0, câu hỏi được hỏi kỹ hơn:

Metadata của bảng có mở không?

Parquet chỉ mô tả dữ liệu bên trong từng file.

Open table format mô tả cả tập hợp file như một bảng có lịch sử và giao dịch.

Các định dạng phổ biến gồm:

• Apache Iceberg.
• Delta Lake.
• Apache Hudi.

Chúng giải quyết những vấn đề gần giống nhau:

• Snapshot.
• Transaction.
• Schema evolution.
• Partition evolution.
• Time travel.
• Thêm, sửa và xóa dữ liệu.
• Theo dõi data file.

Nhưng metadata của chúng không giống nhau.

Điều này tạo ra một câu hỏi khó:

Doanh nghiệp nên chọn một format duy nhất hay chấp nhận nhiều format cùng tồn tại?

Lakehouse 2.0 nghiêng về khả năng tương tác thay vì ép toàn bộ thế giới chọn cùng một màu áo.

Delta UniForm, chẳng hạn, tận dụng việc Delta Lake, Iceberg và Hudi đều có thể dùng chung các file Parquet. Hệ thống có thể sinh thêm metadata Iceberg cho một bảng Delta mà không tạo thêm bản sao dữ liệu vật lý. Một engine hiểu Delta dùng metadata Delta; một engine hiểu Iceberg đọc cùng file thông qua metadata Iceberg. (Delta)

Có thể hình dung như một nhà kho có cùng một đống hàng, nhưng hai loại sổ kho:

1                Parquet Data Files
2                  /           \
3                 /             \
4        Delta Metadata     Iceberg Metadata
5             |                    |
6        Delta Engine         Iceberg Engine

Hàng hóa không bị chép thành hai bản.

Chỉ có hai bộ bản đồ giúp các nhóm người khác nhau tìm đến cùng những thùng hàng đó.

Nghe quá dễ.

Xong thuật toán.

Nhưng ngoài đời, giữ cho hai bộ metadata luôn nhất quán là một bài toán không hề nhẹ. Một thay đổi chỉ được ghi vào một bên có thể khiến hai engine nhìn thấy hai vũ trụ khác nhau.

Vì vậy, khả năng đa định dạng cần được cung cấp bởi một cơ chế được thiết kế rõ ràng, không phải vài script tự viết rồi đặt tên sync_metadata_final_v3.py.

Catalog trở thành bộ não của Lakehouse

Nếu object storage là đất đai và table format là sổ đỏ của từng căn nhà, catalog là cơ quan địa chính.

Nó biết:

• Bảng nào tồn tại.
• Bảng nằm ở đâu.
• Schema hiện tại là gì.
• Ai sở hữu bảng.
• Ai được đọc.
• Ai được ghi.
• Engine nào đang yêu cầu truy cập.
• Credential tạm thời nào được cấp.
• Dữ liệu có nguồn gốc từ đâu.
• Bảng liên quan đến dashboard hoặc mô hình nào.

Trong Lakehouse 1.0, catalog thường bị xem như một nơi tra tên bảng:

1catalog.schema.table

Trong Lakehouse 2.0, catalog tiến gần hơn đến vai trò control plane.

Compute engine không nhất thiết được cấp quyền đọc thẳng toàn bộ bucket.

Nó có thể hỏi catalog:

Người dùng Tùng có quyền đọc bảng silver.orders không?

Catalog kiểm tra chính sách rồi cấp credential tạm thời, chỉ đủ để đọc những file cần thiết.

Iceberg REST Catalog được tạo ra để nhiều ngôn ngữ và engine có thể dùng một giao thức chung khi làm việc với catalog. Đặc tả này cũng hỗ trợ các hướng như xử lý xung đột phía server, credential vending, multi-table commit và caching. (Apache Iceberg)

Luồng truy cập có thể trông như sau:

 1Người dùng
 2    |
 3    v
 4Trino / Spark / Flink
 5    |
 6    | Xin mở bảng silver.orders
 7    v
 8REST Catalog
 9    |
10    | Kiểm tra quyền
11    | Trả metadata
12    | Cấp credential tạm thời
13    v
14Object Storage

Compute engine không còn tự mò vào nhà kho bằng một chiếc chìa khóa tổng được lưu trong file cấu hình ba năm chưa đổi.

Nó phải xin quyền theo từng danh tính và từng phạm vi.

Đây là một bước tiến lớn về governance.

Nhưng nó cũng tạo ra một trung tâm quyền lực mới.

Khi table format và compute trở nên thay thế được, catalog trở thành nơi kiểm soát quan trọng nhất.

Quyền lực không biến mất.

Nó chỉ leo lên một tầng cao hơn.

Compute không còn là vua, compute trở thành đội thợ

Trong Lakehouse 2.0, không có một engine bắt buộc phải làm mọi việc.

Mỗi engine có thể được lựa chọn theo workload:

Điểm quan trọng không phải chọn đúng tên sản phẩm trong bảng.

Điểm quan trọng là dữ liệu không cần chuyển nhà mỗi khi ta đổi đội thợ.

Giả sử bảng Silver nằm trong Iceberg:

1s3://retail-lakehouse/silver/orders/

Spark có thể tạo bảng.

Flink cập nhật liên tục.

Trino chạy truy vấn cho analyst.

DuckDB đọc một lát dữ liệu nhỏ trên laptop.

Một engine realtime có thể đồng bộ phần dữ liệu cần thiết để phục vụ dashboard.

Không engine nào cần sở hữu toàn bộ đời sống của bảng.

1                         Spark
2                           |
3Flink -------- Iceberg Table -------- Trino
4                           |
5                         DuckDB

Đây là ý nghĩa của composable compute.

Compute trở thành một thành phần có thể thay đổi theo nhu cầu, chi phí và độ trễ.

Tuy nhiên, “nhiều engine cùng hỗ trợ Iceberg” không đồng nghĩa mọi engine có khả năng giống hệt nhau.

Có engine chỉ đọc.

Có engine đọc và append.

Có engine hỗ trợ MERGE, UPDATE, DELETE.

Có engine hiểu branching hoặc position delete.

Có engine chậm cập nhật phiên bản table format mới.

Trên tờ quảng cáo, tất cả cùng ngồi quanh một chiếc bàn rất vui vẻ.

Trong production, cần kiểm tra kỹ xem từng người có thật sự dùng được cùng loại muỗng hay không.

Object storage bắt đầu hiểu khái niệm bảng

Trong Lakehouse 1.0, object storage thường rất ngây thơ.

Nó chỉ biết:

1PUT object
2GET object
3DELETE object
4LIST prefix

Việc quản lý bảng nằm ở các job phía trên:

• Compact file nhỏ.
• Xóa snapshot cũ.
• Dọn file không còn được tham chiếu.
• Viết manifest.
• Tối ưu cách bố trí dữ liệu.
• Theo dõi transaction.

Đây là lý do nhiều Lakehouse nhìn rất đẹp trong sơ đồ nhưng sau hai năm lại có hàng chục triệu file nhỏ nằm dưới đáy hồ như những chai nhựa không ai vớt.

Một luồng streaming có thể liên tục tạo file:

110 KB
215 KB
38 KB
420 KB
512 KB

Query engine phải mở hàng trăm nghìn file nhỏ chỉ để đọc vài GB dữ liệu.

Mỗi lần mở file là một request.

Mỗi request là một chuyến tín hiệu xuyên qua mạng.

Một file 10 KB nhìn rất bé.

Nhưng một triệu file 10 KB là một triệu lần hệ thống phải tìm đường, kiểm tra quyền, đọc metadata và mở kết nối.

Lakehouse 2.0 đưa nhiều công việc này xuống gần storage hơn.

S3 Tables được giới thiệu cuối năm 2024 như một lớp lưu trữ bảng Apache Iceberg được quản lý. BigLake năm 2025 cũng đi theo hướng storage engine cho Iceberg với quản lý và tối ưu bảng tự động. (Amazon Web Services, Inc.)

Ý tưởng là:

1Trước đây:
2Object Storage + Một đống cron job tự chăm sóc bảng
3
4Sau này:
5Table-aware Storage + Dịch vụ maintenance được quản lý

Người dùng vẫn sở hữu dữ liệu ở định dạng mở.

Nhưng các công việc dọn dẹp bắt đầu được nền tảng đảm nhiệm.

Không phải vì compaction bỗng trở thành phép thuật.

Máy chủ vẫn phải đọc file cũ, giải nén dữ liệu, sắp xếp lại, ghi file mới rồi cập nhật metadata.

Con chip vẫn nóng.

Ổ đĩa vẫn nhận hàng tỷ thao tác.

Hệ thống làm mát vẫn phải gầm lên.

Chỉ là người vận hành không còn tự viết từng dòng cron để ra lệnh cho cỗ máy ấy.

Streaming không còn đứng ngoài cửa Lakehouse

Trong kiến trúc cũ, Kafka và Lakehouse thường là hai thế giới.

Kafka giữ dòng sự kiện nóng.

Lakehouse giữ dữ liệu lịch sử lạnh.

Muốn đi từ nóng sang lạnh, ta phải xây một cây cầu riêng.

Lakehouse 2.0 cố gắng biến table format thành điểm giao nhau giữa streaming và analytics.

Ví dụ:

1Đơn hàng mới
2    ↓
3Kafka Topic
4    ↓
5Tableflow / Flink / Managed CDC
6    ↓
7Iceberg hoặc Delta Table
8    ↓
9Trino / Spark / BI / AI

Tableflow được giới thiệu năm 2024 và GA cho Iceberg năm 2025 với khả năng biểu diễn Kafka topic thành bảng, chuyển dữ liệu sang Parquet, xuất bản metadata và xử lý schema evolution. (Confluent)

Các dịch vụ CDC cũng bắt đầu ghi trực tiếp thay đổi từ database vào Iceberg.

Điều này không có nghĩa Kafka biến mất.

Kafka vẫn phù hợp với:

• Giao tiếp sự kiện.
• Xử lý operational realtime.
• Consumer cần độ trễ rất thấp.
• Replay theo offset.
• Kết nối các ứng dụng đang chạy.

Iceberg phù hợp với:

• Lịch sử dài hạn.
• Truy vấn phân tích.
• Join dữ liệu lớn.
• Đọc bằng nhiều engine.
• Time travel và snapshot.

Hai hệ thống không thay thế nhau.

Chúng bắt đầu nối với nhau ít keo dán thủ công hơn.

Bronze, Silver và Gold có biến mất không?

Không.

Lakehouse 2.0 không đập bỏ mô hình Bronze, Silver và Gold.

Nó thay đổi cách ba tầng này được tạo ra và phục vụ.

Trong Lakehouse 1.0, ta thường hình dung:

1Bronze Batch
2    ↓
3Silver Batch
4    ↓
5Gold Batch

Trong Lakehouse 2.0, kiến trúc có thể trở thành:

1Kafka / CDC
2    ↓
3Bronze Streaming Table
4    ↓
5Silver Continuously Updated Table
6    ↓
7Gold Materialized Data Product

Bronze trong Lakehouse 2.0

Bronze vẫn giữ dữ liệu gần nguồn.

Nhưng dữ liệu có thể chảy liên tục thay vì đợi một file lớn cuối ngày.

1bronze.orders_cdc
2bronze.inventory_events
3bronze.customer_clicks

Bronze có thể lưu:

• Giá trị trước khi cập nhật.
• Giá trị sau khi cập nhật.
• Loại sự kiện INSERT, UPDATE, DELETE.
• Thời điểm xảy ra tại nguồn.
• Thời điểm được tiếp nhận.
• Offset hoặc sequence number.
• Schema version.

Silver trong Lakehouse 2.0

Silver vẫn chuẩn hóa và hợp nhất dữ liệu.

Nhưng thay vì mỗi đêm xây lại toàn bộ bảng, hệ thống có thể cập nhật liên tục bằng MERGE, incremental processing hoặc streaming state.

1bronze.orders_cdc
2        |
3        | chuẩn hóa, deduplicate, merge
4        v
5silver.orders

Một đơn hàng thay đổi trạng thái:

1CREATED
2    ↓
3PAID
4    ↓
5SHIPPED
6    ↓
7DELIVERED

không nhất thiết tạo ra bốn đơn hàng khác nhau.

Silver có thể giữ trạng thái hiện tại, trong khi lịch sử thay đổi vẫn được bảo toàn ở Bronze hoặc trong snapshot.

Gold trong Lakehouse 2.0

Gold vẫn phục vụ nghiệp vụ.

Điểm khác là một bảng Gold có thể được cập nhật nhanh hơn và được nhiều engine sử dụng:

1gold.hourly_store_revenue
2gold_realtime_inventory
3gold_customer_360
4gold_delivery_performance

Dashboard có thể đọc bằng một engine SQL.

Agent AI có thể dùng cùng metric đã được quản trị.

Một ứng dụng vận hành có thể lấy dữ liệu qua API.

Gold không chỉ là bảng cuối pipeline.

Nó bắt đầu được xem như một data product có:

• Chủ sở hữu.
• Định nghĩa nghiệp vụ.
• SLA.
• Quyền truy cập.
• Chất lượng dữ liệu.
• Lineage.
• Phiên bản.
• Hợp đồng với người sử dụng.

Ví dụ Lakehouse 2.0 cho hệ thống bán lẻ

Giả sử doanh nghiệp có:

• 1.000 cửa hàng.
• Một triệu đơn hàng mỗi ngày.
• Ba triệu dòng chi tiết đơn hàng.
• Hàng chục triệu lượt xem sản phẩm.
• Thay đổi tồn kho liên tục.
• Nhiều database vận hành.
• Kafka chứa sự kiện realtime.

Kiến trúc có thể được tổ chức như sau.

Bước 1: đưa thay đổi từ hệ thống nguồn vào event stream

1POS Database --------\
2OMS Database ---------+--> CDC / Kafka
3Inventory Database ---/
4Website Events -------/

Mỗi lần một đơn hàng được tạo, cập nhật hoặc hủy, hệ thống phát ra một sự kiện.

Ví dụ:

1{
2  "event_type": "ORDER_UPDATED",
3  "order_id": 918273645,
4  "old_status": "SHIPPED",
5  "new_status": "DELIVERED",
6  "event_time": "2026-07-24T10:31:22+07:00"
7}

Bước 2: materialize sự kiện thành bảng Bronze

Streaming engine hoặc dịch vụ được quản lý ghi sự kiện thành Iceberg hoặc Delta:

1bronze.order_events
2bronze.inventory_events
3bronze.payment_events

Table metadata được cập nhật liên tục.

Schema Registry hoặc data contract giúp kiểm soát cấu trúc sự kiện.

Bước 3: cập nhật Silver

Flink hoặc Spark xử lý:

• Deduplicate.
• Chuẩn hóa khóa.
• Ghép mã cửa hàng.
• Ghép mã sản phẩm.
• Xử lý dữ liệu đến trễ.
• Áp dụng INSERT, UPDATE, DELETE.
• Tạo trạng thái hiện tại của đơn hàng.

1silver.orders
2silver.order_items
3silver.inventory
4silver.products
5silver.customers

Bước 4: nhiều engine cùng dùng Silver

1                     Spark
2                       |
3Flink ---- silver.orders ---- Trino
4                       |
5                    DuckDB
6                       |
7                 AI Feature Job

Spark chạy job lớn.

Trino phục vụ analyst.

Flink tiếp tục cập nhật.

DuckDB dùng để kiểm tra một lát dữ liệu nhỏ.

Một pipeline AI đọc dữ liệu để tạo feature.

Không cần tạo bốn bản sao chỉ vì bốn nhóm thích bốn công cụ khác nhau.

Bước 5: tạo Gold theo từng data product

1gold.daily_revenue
2gold.realtime_inventory
3gold.return_rate
4gold.delivery_sla
5gold.product_conversion

Mỗi bảng có:

1owner: retail-analytics
2sla: 5_minutes
3catalog: retail
4classification: internal
5quality:
6  order_id_not_null: 100%
7  revenue_non_negative: 99.99%

Catalog giữ thông tin quyền truy cập, lineage và chủ sở hữu.

Dashboard, API và AI agent cùng đọc một định nghĩa doanh thu, thay vì mỗi hệ thống tự chế tạo một con số rồi mang vào phòng họp tranh luận.

Lakehouse 1.0 và Lakehouse 2.0 khác nhau thế nào?

Điểm cốt lõi là:

Lakehouse 1.0 thống nhất dữ liệu vào một nền tảng. Lakehouse 2.0 thống nhất dữ liệu bằng những giao thức mở để nhiều nền tảng cùng sử dụng.

“Zero copy” không có nghĩa là không có gì di chuyển

Lakehouse 2.0 thường đi cùng những cụm từ rất hấp dẫn:

• Zero copy.
• Zero ETL.
• Cross-cloud.
• Federation.
• One copy of data.

Những cụm từ này đúng trong một phạm vi nhất định.

Ví dụ một engine có thể đọc trực tiếp bảng Iceberg trên storage mà không cần tạo một bản dữ liệu lâu dài trong hệ thống của nó.

Nhưng dữ liệu vẫn phải chạy qua mạng.

1S3 tại AWS
2    ↓
3Mạng
4    ↓
5Compute ở một nơi khác

Nếu compute nằm khác vùng hoặc khác cloud, hệ thống có thể phát sinh:

• Network latency.
• Egress cost.
• Cache.
• Bản sao tạm thời.
• Kết nối xuyên cloud.
• Vấn đề chủ quyền dữ liệu.

Không có dữ liệu nào dịch chuyển bằng ý niệm.

Một truy vấn xuyên cloud vẫn kéo những electron thật chạy qua router thật, cáp quang thật và thiết bị mạng thật.

“Zero copy” thường có nghĩa:

Không cần duy trì thêm một bản dữ liệu lâu dài do người dùng chủ động xây pipeline sao chép.

Nó không có nghĩa:

Không byte nào từng rời khỏi nơi lưu trữ.

Những vấn đề Lakehouse 2.0 vẫn chưa giải quyết xong

Nhiều engine không đồng nghĩa hành vi giống nhau

Hai engine cùng ghi “hỗ trợ Iceberg” có thể hỗ trợ những phạm vi rất khác nhau.

Cần kiểm tra:

• Có đọc được table format version mới không?
• Có ghi được không?
• Có hỗ trợ MERGE không?
• Có hỗ trợ row-level delete không?
• Có xử lý schema evolution giống nhau không?
• Có cập nhật catalog đúng chuẩn không?
• Có tương thích với credential vending không?
• Có bảo toàn transaction khi nhiều writer chạy đồng thời không?

Logo đặt cạnh nhau trên sơ đồ không phải bằng chứng cho khả năng tương thích production.

Catalog có thể trở thành điểm nghẽn mới

Khi mọi engine đều hỏi catalog:

• Bảng nằm đâu?
• Ai có quyền?
• Snapshot nào hiện tại?
• Credential nào được cấp?

catalog trở thành một hệ thống cực kỳ quan trọng.

Nếu catalog chậm, truy vấn khởi tạo chậm.

Nếu catalog lỗi, nhiều engine cùng mất khả năng truy cập.

Nếu chính sách catalog sai, dữ liệu có thể bị lộ hoặc bị khóa nhầm.

Nếu toàn bộ tổ chức phụ thuộc vào một catalog độc quyền, vendor lock-in chỉ chuyển từ compute lên metadata.

Cái khóa cửa không biến mất.

Nó chỉ được treo ở một căn phòng cao hơn.

Streaming vẫn tạo ra file nhỏ

Dữ liệu chảy từng giây thường tạo ra những commit nhỏ.

Commit nhỏ tạo file nhỏ.

File nhỏ tạo nhiều metadata.

Nhiều metadata làm planning chậm.

Vì vậy hệ thống vẫn cần:

• Compaction.
• Snapshot expiration.
• Manifest rewrite.
• Orphan file cleanup.
• Clustering.
• Retention policy.

Dịch vụ managed có thể tự động hóa các việc này.

Nhưng chi phí compute và I/O vẫn tồn tại.

Không có ông tiên nào bay xuống gom file miễn phí vào ban đêm.

Một bản dữ liệu không có nghĩa là một sự thật nghiệp vụ

Mọi engine có thể đọc cùng một bảng silver.orders.

Nhưng nếu tài chính định nghĩa doanh thu theo ngày xuất hóa đơn, vận hành tính theo ngày giao hàng, còn marketing tính theo ngày đặt hàng, ba con số vẫn khác nhau.

Lakehouse 2.0 giải quyết sự thống nhất vật lý và kỹ thuật tốt hơn.

Nó không tự giải quyết sự thống nhất về ý nghĩa.

Doanh nghiệp vẫn cần:

• Metric definition.
• Semantic model.
• Data contract.
• Data ownership.
• Quy trình thay đổi.
• Kiểm tra chất lượng.

Một triệu engine cùng đọc một bảng sai chỉ giúp cái sai lan nhanh hơn.

Open format không xóa hoàn toàn vendor lock-in

Dữ liệu có thể nằm trong Iceberg.

Nhưng hệ thống vẫn có thể phụ thuộc vào:

• Catalog riêng.
• Chính sách bảo mật riêng.
• Công cụ orchestration.
• API quản trị.
• Cách tối ưu bảng.
• Cơ chế cache.
• SQL extension.
• Hệ thống billing.

Lakehouse 2.0 làm chi phí rời đi thấp hơn.

Nó không biến việc rời đi thành miễn phí.

Ngôi nhà có nhiều cửa hơn.

Nhưng chuyển nhà vẫn phải đóng thùng.

Có cần nâng cấp từ Lakehouse 1.0 lên 2.0 không?

Không phải lúc nào cũng cần.

Giả sử hệ thống hiện tại:

• Chủ yếu dùng một engine.
• Dữ liệu chạy batch mỗi ngày.
• Số lượng người dùng không lớn.
• Không có yêu cầu cross-cloud.
• Governance hiện tại đủ dùng.
• Chi phí vận hành ổn định.
• Không gặp vấn đề vendor lock-in.
• Bronze, Silver và Gold đang hoạt động tốt.

Khi đó, việc tháo kiến trúc thành nhiều thành phần có thể làm hệ thống phức tạp hơn mà chưa tạo thêm giá trị.

Lakehouse 2.0 phù hợp hơn khi:

• Nhiều nhóm cần dùng các compute engine khác nhau.
• Dữ liệu cần được cập nhật gần realtime.
• Kafka và database operational cần đổ trực tiếp vào Lakehouse.
• Doanh nghiệp muốn dùng open table format làm nền dữ liệu lâu dài.
• Cần governance thống nhất xuyên nhiều engine.
• Có nhu cầu chia sẻ dữ liệu mà không nhân bản.
• Muốn giảm phụ thuộc vào một compute engine hoặc một vendor.
• Khối lượng table maintenance đã vượt khả năng cron job tự quản lý.
• Dữ liệu cần phục vụ đồng thời BI, AI, ứng dụng và agent.

Câu hỏi không nên là:

Lakehouse 2.0 có mới hơn không?

Mà nên là:

Kiến trúc hiện tại đang bị khóa ở tầng nào, và việc mở tầng đó có đem lại giá trị đủ lớn không?

Tổng kết

Lakehouse 1.0 đã giải quyết một vấn đề lớn:

Đưa sự ngăn nắp của data warehouse xuống lớp lưu trữ rộng và rẻ của data lake.

Nhưng trong quá trình xây dựng, nhiều hệ thống lại tạo ra một căn nhà được tích hợp quá chặt:

• Một table format chính.
• Một catalog chính.
• Một compute engine chính.
• Một nền tảng giữ phần lớn quyền kiểm soát.

Lakehouse 2.0 cố gắng hoàn thành lời hứa mở còn dang dở.

Nó đưa kiến trúc theo hướng:

 1Open Storage
 2    +
 3Open Table Format
 4    +
 5Open Catalog API
 6    +
 7Composable Compute
 8    +
 9Streaming Tables
10    +
11Unified Governance

Bronze, Silver và Gold vẫn còn đó.

Nhưng dữ liệu không nhất thiết phải đợi đến nửa đêm mới bắt đầu đi tắm.

Nó có thể chảy liên tục từ database và Kafka vào Bronze, được chuẩn hóa ở Silver rồi nhanh chóng trở thành Gold cho dashboard, ứng dụng và AI.

Một đơn hàng vừa được khách bấm xác nhận ngoài cửa hàng có thể lập tức tạo ra một chuỗi phản ứng khổng lồ.

Database ghi transaction.

WAL sinh thêm byte.

CDC đọc thay đổi.

Kafka giữ sự kiện.

Streaming engine chuyển đổi schema.

Parquet được ghi xuống storage.

Table metadata tạo snapshot mới.

Catalog kiểm tra quyền.

Trino đọc bảng.

Dashboard sáng lên một con số.

AI agent nhìn thấy tồn kho vừa giảm.

Tất cả diễn ra trong vài giây, nhưng phía sau là hàng triệu transistor đóng mở, những chip silicon nóng dần, những luồng dữ liệu chạy xuyên cáp quang và những cỗ máy làm mát đang gầm gừ giữ cho cái gọi là “đám mây” không bốc khói.

Không có gì là hoàn toàn ảo.

Lakehouse 2.0 chỉ làm cho đoàn máy móc vật lý ấy biết nói chuyện với nhau bằng những ngôn ngữ mở hơn.

Nếu Lakehouse 1.0 là căn nhà được xây trên hồ, Lakehouse 2.0 là lúc người ta tháo căn nhà thành những mảnh Lego.

Mỗi mảnh có thể được thay.

Mỗi đội thợ có thể bước vào.

Nhưng bản vẽ, ổ cắm và luật xây dựng phải đủ rõ ràng để khi thay cái bếp, phòng khách không bất ngờ rơi xuống hồ.

Tham khảo

• Introducing Lakehouse 2.0: What Changes?
• Lakehouse 2.0: The Open System That Lakehouse 1.0 Was Meant to Be
• Open Sourcing Unity Catalog
• Apache Iceberg REST Catalog Specification
• Apache Polaris Project
• Apache Polaris Graduates to Top Level Project
• Delta Lake: State of the Project — Interoperability
• Introducing Tableflow
• Tableflow Is Generally Available
• Amazon S3 Tables
• Replicate Database Changes to Apache Iceberg Using Amazon Data Firehose
• Enhancing BigLake for Iceberg Lakehouses
• Extending the Google Data Cloud Lakehouse Architecture
• Google Cloud Next 2026 Wrap Up