Open Data Lakehouse Cloudera: Apache Iceberg & Lakehouse Optimizer

Nhiều tổ chức đang nuôi song song hai kho dữ liệu. Một bên là hồ dữ liệu (data lake) để chứa dữ liệu thô với chi phí thấp. Một bên là kho dữ liệu (data warehouse) để chạy báo cáo cho nhanh. Cùng một con số vì thế phải sao chép qua lại giữa hai nơi, mỗi nơi một phiên bản. Đội báo cáo và đội AI (Artificial Intelligence — trí tuệ nhân tạo) làm việc trên hai bản dữ liệu khác nhau, và khi số liệu lệch thì mất nhiều thời gian mới biết bản nào đúng.

Open Data Lakehouse — lakehouse mở — hợp nhất hai thứ đó lại: một bản dữ liệu duy nhất, nằm ở định dạng mở trên hạ tầng lưu trữ của chính bạn, phục vụ đồng thời báo cáo quản trị, truy vấn tương tác và huấn luyện mô hình. Cloudera hiện thực hóa lakehouse mở bằng Apache Iceberg.

flowchart TB
  subgraph STORE["Hạ tầng lưu trữ của bạn · trung tâm dữ liệu hoặc đám mây"]
    ICE["Bảng Apache Iceberg<br/>Parquet · ORC · metadata mở"]
  end
  DE["Data Engineering<br/>Apache Spark"] --> ICE
  DW["Data Warehouse<br/>truy vấn SQL"] --> ICE
  ODB["Operational Database<br/>dữ liệu vận hành"] --> ICE
  AI["Cloudera AI<br/>huấn luyện · suy luận"] --> ICE
  EXT["Nền tảng bên ngoài<br/>đọc trực tiếp · không sao chép"] --> ICE
  LO["Lakehouse Optimizer<br/>tự bảo trì · tự tối ưu"] -.-> ICE

Lakehouse mở là gì?

Lakehouse mở đứng trên ba nguyên tắc, và cả ba đều phải có thì mới gọi là “mở”:

Một bản dữ liệu, nhiều cách dùng. Báo cáo tài chính, dashboard vận hành, mô hình dự báo và tác tử AI cùng đọc một bảng. Không trích xuất, không đồng bộ đêm, không đối chiếu hai kho.
Định dạng mở. Dữ liệu nằm ở chuẩn cộng đồng mà nhiều công cụ đọc được, không phải định dạng riêng của một hãng.
Quản trị chặt như kho dữ liệu. Phân quyền, che dữ liệu nhạy cảm, nhật ký truy cập và truy vết nguồn gốc được đặt một lần ở lớp SDX (Shared Data Experience) rồi áp cho mọi dịch vụ đọc bảng đó.

Nhu cầu thực tế	Lakehouse mở đáp ứng thế nào
Báo cáo cuối ngày phải đúng và nhanh	Truy vấn SQL (Structured Query Language) chạy thẳng trên bảng Iceberg, không cần chuyển dữ liệu sang một kho riêng
Đội khoa học dữ liệu cần dữ liệu chi tiết	Đọc cùng bảng đó bằng Apache Spark, không phải xin bản trích xuất
Kiểm toán hỏi lại số liệu tháng trước	Ảnh chụp Iceberg cho phép đọc lại đúng trạng thái bảng ở thời điểm đó
Dữ liệu nhạy cảm không được rời vành đai	Bảng nằm trong trung tâm dữ liệu của bạn; công cụ tìm đến dữ liệu chứ dữ liệu không phải đi đâu cả

Apache Iceberg — dữ liệu vẫn là của bạn

Apache Iceberg là một định dạng bảng mở (open table format) do cộng đồng phát triển. Nó không phải một sản phẩm bạn mua, cũng không thuộc sở hữu của nhà cung cấp nào. Về bản chất, Iceberg gồm hai phần: file dữ liệu ở định dạng phổ biến như Parquet hoặc ORC, và lớp metadata mở mô tả bảng có những cột gì, phân vùng ra sao, gồm những file nào và đã đi qua những phiên bản nào.

Vì đặc tả này công khai, nhiều công cụ cùng đọc một bảng. Trong nền tảng Cloudera, các dịch vụ Data Engineering, Data Warehouse, Data Flow, Streaming và Cloudera AI đều làm việc trên cùng bảng Iceberg đó. Ngoài nền tảng, những công cụ khác hiểu chuẩn Iceberg cũng đọc được.

Hệ quả quan trọng nhất nằm ở quyền sở hữu: dữ liệu vẫn là của khách hàng. Nó nằm trên hạ tầng lưu trữ của khách, ở một định dạng có đặc tả công khai. Nếu mai này chiến lược thay đổi, bạn đổi công cụ chứ không phải bốc cả kho dữ liệu đi chuyển đổi định dạng.

Một bản dữ liệu, phục vụ cả báo cáo lẫn AI

Trong kiến trúc tách hồ và kho, đội AI thường là bên chịu thiệt thòi nhất. Kho dữ liệu chỉ giữ những gì đã tổng hợp theo nhu cầu báo cáo, trong khi mô hình lại cần dữ liệu chi tiết. Thế là mỗi dự án AI bắt đầu bằng một yêu cầu trích xuất, chờ vài tuần, rồi làm việc trên một bản sao mà không ai dám chắc còn khớp với báo cáo hay không.

Lakehouse mở bỏ hẳn bước đó. Trên cùng một bảng Iceberg:

Đội báo cáo truy vấn bằng SQL qua Data Warehouse để dựng dashboard và báo cáo định kỳ.
Đội kỹ thuật dữ liệu dùng Apache Spark qua Data Engineering để làm sạch và biến đổi.
Đội AI đọc dữ liệu chi tiết cho huấn luyện và suy luận qua Cloudera AI — ngay tại nơi dữ liệu đang nằm, không cần đưa dữ liệu đi đâu.
Luồng dữ liệu chuyển động ghi dữ liệu mới vào chính bảng đó, không tạo nhánh riêng.

Khi báo cáo và mô hình cùng đọc một bảng, câu hỏi “vì sao mô hình nói một đằng, báo cáo nói một nẻo” phần lớn tự biến mất — đơn giản vì không còn hai bản dữ liệu để lệch nhau.

Bảng Iceberg làm được gì

Giao dịch ACID

Iceberg đưa giao dịch ACID (Atomicity, Consistency, Isolation, Durability — nguyên tử, nhất quán, cô lập, bền vững) vào lớp dữ liệu lớn. Ý nghĩa vận hành rất cụ thể: một lần ghi hoặc thành công trọn vẹn, hoặc không có gì thay đổi. Sẽ không còn cảnh job nạp liệu chết giữa chừng để lại một bảng dở dang mà báo cáo sáng hôm sau vẫn vô tư đọc phải.

Iceberg cũng cho đọc và ghi diễn ra đồng thời. Người dùng đang chạy truy vấn sẽ thấy phiên bản bảng nhất quán tại thời điểm họ bắt đầu, trong khi luồng nạp liệu vẫn ghi tiếp ở phía sau.

Đổi schema an toàn

Nghiệp vụ thay đổi thì bảng phải đổi theo — thêm cột, đổi tên cột, bỏ cột không dùng nữa. Iceberg theo dõi mỗi cột bằng định danh nội bộ chứ không dựa vào tên hay vị trí cột. Nhờ vậy, đổi schema là một thao tác trên metadata: không phải ghi lại toàn bộ bảng, không làm hỏng những truy vấn viết từ trước, và không có chuyện đổi tên cột xong dữ liệu cột này nhảy sang cột kia.

Cách phân vùng cũng đổi được tương tự. Bảng đang chia theo tháng, dữ liệu lớn dần cần chia theo ngày — Iceberg cho đổi cách phân vùng từ thời điểm đó trở đi mà dữ liệu cũ vẫn đọc bình thường.

Du hành thời gian và ảnh chụp

Mỗi lần bảng thay đổi, Iceberg tạo một ảnh chụp (snapshot) — một phiên bản bất biến của bảng. Từ đó bạn có ba việc rất giá trị:

Đọc lại quá khứ. Truy vấn bảng đúng như nó ở thời điểm hôm qua, hoặc tại một ảnh chụp cụ thể.
Quay lui. Job nạp sai dữ liệu thì trả bảng về ảnh chụp liền trước, không cần phục hồi từ bản sao lưu.
So sánh phiên bản. Biết chính xác lần ghi nào đã làm con số thay đổi.

Năng lực Iceberg	Ý nghĩa với người vận hành
Giao dịch ACID	Không còn bảng dở dang khi job lỗi giữa chừng
Đọc ghi đồng thời	Nạp liệu ban đêm không chặn người chạy báo cáo
Đổi schema an toàn	Nghiệp vụ đổi mà không phải dừng hệ thống hay ghi lại bảng
Đổi cách phân vùng	Bảng lớn dần vẫn tối ưu được, dữ liệu cũ giữ nguyên
Ảnh chụp và du hành thời gian	Trả lời được câu hỏi kiểm toán; sửa sai bằng thao tác quay lui

Cloudera Lakehouse Optimizer

Bảng Iceberg dùng lâu sẽ tự sinh ra gánh nặng: mỗi lần ghi để lại thêm file, luồng nạp liệu liên tục tạo ra rất nhiều file nhỏ, ảnh chụp cũ tích tụ, và những file không còn bảng nào tham chiếu vẫn nằm chiếm chỗ. Hệ quả là truy vấn chậm dần và hóa đơn lưu trữ phình ra — dù dữ liệu nghiệp vụ chẳng tăng bao nhiêu. Việc bảo trì này thường rơi vào tay đội kỹ thuật dữ liệu, dưới dạng những script dọn dẹp viết tay chạy hằng đêm.

Cloudera Lakehouse Optimizer nhận lấy phần việc đó. Dịch vụ này theo dõi bảng Iceberg và tự tối ưu: gộp file nhỏ thành file có kích thước hợp lý, dọn ảnh chụp đã hết hạn, thu hồi file không còn được tham chiếu — dựa trên chính sách bạn đặt, chứ không phải chờ ai đó nhớ ra.

Theo Cloudera công bố, Lakehouse Optimizer giúp truy vấn nhanh hơn 38% và giảm 36% dung lượng lưu trữ. Mức cải thiện thực tế phụ thuộc hình dạng dữ liệu và cách bảng được ghi, nhưng hướng tác động thì rõ: bảng gọn hơn thì đọc ít file hơn, và đọc ít file hơn thì truy vấn nhanh hơn.

Ở góc rộng hơn, việc bỏ được các bản sao dữ liệu và bước trích xuất trung gian còn cắt cả chi phí vận hành. Theo Cloudera công bố, kiến trúc lakehouse mở trên Iceberg giúp giảm độ phức tạp để đội kỹ thuật dữ liệu dành thời gian cho việc giá trị cao hơn — khách hàng báo cáo cải thiện tới 20% năng suất kỹ thuật dữ liệu — và nhờ đọc trực tiếp một bản dữ liệu thay vì nhân bản, giảm tới 50% chi phí lưu trữ. Các mức này là số liệu hãng công bố, thay đổi theo khối lượng công việc thực tế.

Hai kiểu cập nhật theo dòng: Copy-on-Write và Merge-on-Read

Khi cần sửa hoặc xóa một tập bản ghi trong bảng Iceberg, có hai cách thực hiện, và chọn đúng cách quyết định phần lớn hiệu năng của tải ghi. Đây không phải lựa chọn “cái nào tốt hơn” — mà là chọn theo đặc tính công việc.

Kiểu	Cách làm	Hợp với
Copy-on-Write (ghi bản mới khi sửa)	Sửa một dòng thì ghi lại nguyên file dữ liệu chứa dòng đó	Xử lý theo lô (batch), huấn luyện mô hình — ghi nặng nhưng đọc gọn
Merge-on-Read (gộp lúc đọc)	Ghi thay đổi thành file phụ, gộp lại khi truy vấn đọc	Streaming, BI thời gian thực — ghi nhẹ, cập nhật liên tục

Cách nhớ: Copy-on-Write trả giá lúc ghi để đọc nhanh; Merge-on-Read trả giá lúc đọc để ghi nhanh. Một bảng cập nhật theo lô mỗi đêm hợp với Copy-on-Write; một bảng nhận dòng sự kiện liên tục hợp với Merge-on-Read. Hiểu cách dữ liệu được nạp, xử lý và tiêu thụ trước, rồi mới chọn kiểu — đặt sai kiểu thì hoặc ghi chậm, hoặc đọc chậm, tùy hướng đặt nhầm.

Đây cũng là một trong bốn vấn đề vận hành mà trang Vận hành Iceberg trong production nói kỹ hơn — kiểu ghi ảnh hưởng trực tiếp tới xung đột commit và khuếch đại metadata.

Tăng tốc truy vấn: khung nhìn vật chất hóa, cache metadata, nén

Ngoài việc bảo trì bảng tự động, Cloudera bổ sung vài cách tăng tốc truy vấn ngay trên bảng Iceberg (theo Cloudera công bố):

Khung nhìn vật chất hóa (materialized view). Đây là năng lực quen thuộc của kho dữ liệu, nay áp dụng được trên bảng Iceberg: kết quả tổng hợp hay biến đổi hay dùng được tính sẵn và lưu lại, để truy vấn sau đọc thẳng thay vì tính lại từ đầu. Vì khung nhìn vật chất hóa cũng nằm trong bảng Iceberg, các engine khác đọc được — nên đội dữ liệu dựng, bảo trì và tiến hóa các “bản nhìn nghiệp vụ” ở một định dạng liên thông, không khóa vào một công cụ.

Cache metadata. Iceberg lập kế hoạch truy vấn bằng cách đọc các file manifest nhỏ mô tả bảng. Khi bảng có nhiều file, việc đọc lặp lại các manifest này từ kho lưu trữ ở xa trở thành chi phí đáng kể. Cache metadata giữ chúng gần engine, và theo Cloudera công bố, giúp lập kế hoạch truy vấn nhanh hơn tới 12 lần — Cloudera cho biết đã đóng góp tính năng này lên cộng đồng mã nguồn mở của Iceberg.

Nén dữ liệu. Chọn thuật toán nén là cân bằng giữa tốc độ và dung lượng. Nén Snappy cho truy vấn nhanh nhất nhưng tốn dung lượng hơn; nén Gzip cho dung lượng nhỏ nhất nhưng truy vấn chậm hơn. Chọn theo cam kết thời gian (SLA — Service Level Agreement) của người dùng cuối, không theo một mặc định.

Chia sẻ dữ liệu — đọc trực tiếp, không sao chép

Cách chia sẻ dữ liệu quen thuộc là xuất một bản sao rồi gửi đi. Cách đó tạo ra bốn vấn đề cùng lúc: tốn dung lượng, số liệu hai nơi lệch nhau theo thời gian, bản sao nằm ngoài tầm quản trị, và mỗi bản sao là một cửa rò rỉ tiềm tàng.

Vì Iceberg là định dạng mở, Cloudera cho phép nền tảng bên ngoài đọc trực tiếp bảng Iceberg do Cloudera quản trị — không sao chép. Bên nhận làm việc trên chính bảng gốc, nên luôn thấy dữ liệu mới nhất. Bên chủ dữ liệu giữ nguyên quyền kiểm soát: bảng vẫn nằm ở chỗ cũ, chính sách vẫn quản lý tập trung ở lớp SDX, và không phát sinh thêm bản dữ liệu nào phải trông coi.

Hiện đại hóa từ cụm Hadoop sẵn có

Cloudera xuất thân từ hệ sinh thái Hadoop, và nhiều tổ chức tại Việt Nam đang vận hành cụm Hadoop đã đầu tư từ nhiều năm trước: dữ liệu đầy đủ, đội ngũ quen việc, nhưng bảng thì khó đổi schema, khó quản phiên bản, và mỗi thay đổi đều tốn kém. Đưa những bảng đó lên Iceberg là con đường tự nhiên — giữ lại dữ liệu và kỹ năng đã có, thêm vào năng lực của một lakehouse hiện đại, thay vì làm lại từ đầu trên một nền tảng khác.

Các sai lầm dễ mắc phải

Xem lakehouse chỉ là chỗ lưu trữ mới. Giá trị nằm ở chỗ một bản dữ liệu phục vụ mọi nhu cầu. Nếu vẫn tiếp tục trích xuất ra các kho nhỏ bên cạnh, ranh giới cũ chỉ đổi tên chứ không mất đi.
Bỏ quên việc bảo trì bảng. Bảng Iceberg không tự gọn. Hoặc đặt Lakehouse Optimizer lo, hoặc phải có người lo — không có phương án thứ ba.
Giữ ảnh chụp vô thời hạn. Du hành thời gian rất hữu ích, nhưng mỗi ảnh chụp giữ lại là dung lượng thật. Nên đặt thời hạn theo yêu cầu kiểm toán thực tế.
Nghĩ định dạng mở là đủ để tránh bị khóa. Cần mở ở cả ba lớp: định dạng file, metadata bảng, và nơi dữ liệu được lưu.

Đọc tiếp

Data Engineering (Spark) Dựng & điều phối luồng xử lý dữ liệu bằng Apache Spark ngay trên bảng Iceberg.

Data Warehouse Phân tích khối dữ liệu rất lớn với hàng nghìn người dùng truy vấn đồng thời.