Real-Time Data Lake Ingestion Is Saying Goodbye to ETL: Architectural Subtraction from Kafka to Iceberg

Alibaba · 2026 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bài của team Messaging của Alibaba Cloud, quảng bá tính năng ApsaraMQ for Kafka × OSS Tables (đang beta theo lời mời). Không có số liệu vận hành, chỉ có thông số thiết kế; mọi nhận định ghi "theo Alibaba". Phần "AI era" chỉ là khung kể, tóm tắt ngắn.

Bối cảnh

• Bộ ba Kafka + Iceberg + object storage thành tổ hợp phổ biến: Kafka nhận dòng dữ liệu, Iceberg tổ chức thành bảng có schema và query được, object storage giữ lịch sử rẻ. Theo Alibaba, S3 Tables (AWS, 2024) làm hướng này rõ hơn.
• Đường truyền thống: Kafka → Flink/Spark Streaming → bảng → object storage. Vẫn đúng khi cần làm sạch phức tạp, tổng hợp theo cửa sổ, join nhiều stream. Nhưng nhiều nơi chỉ cần "đổ dữ liệu từ Kafka vào bảng" mà vẫn phải nuôi một job stream cho việc đó.

Thay đổi chính (thiết kế)

• Bớt kiến trúc (Zero-ETL): chuyển các việc chung của đổ dữ liệu vào lake (giải mã message, map schema, quản offset, commit transaction, kiểm soát file nhỏ, phục hồi lỗi) từ job ngoài vào sát broker Kafka. Theo Alibaba, cái bị bỏ không phải việc xử lý dữ liệu mà là một tầng di chuyển dữ liệu, một mớ logic viết lại ở mỗi job, và phần vận hành không tạo giá trị.
• Ba bước từ message tới bảng: (1) chuyển record (giải mã Avro/Protobuf, unwrap CDC của Debezium, gắn topic/partition/offset); (2) tự tiến hoá schema với thay đổi tương thích (thêm cột optional, bắt buộc → optional, int → long): flush lô hiện tại, áp schema mới, ghi tiếp; (3) ghi file cột lên object storage theo partition, chế độ append hoặc upsert (data file + delete file cho insert/update/delete), commit snapshot Iceberg nguyên tử.
• Trạng thái gom vào metadata của leader Kafka: tiến độ đổ vào lake lưu trong metadata của leader, không cần KV ngoài. Compute tách khỏi lưu trữ bền, nên bỏ được giao thức ISR nặng: replica follower chỉ là hot standby cho phần compute, node mới nhận việc nhanh khi failover hay scale.
• Hai đường đồng bộ: đường tiền đồng bộ liên tục đọc, chuyển, ghi file giữa các lần commit; lúc commit chỉ còn phần nhỏ, nên cải thiện cả latency lẫn throughput (thay vì đổi cái này lấy cái kia qua tần suất commit).
• Nhúng hay tách tiến trình: chạy chung process với broker thì rẻ hơn nhưng tăng áp lực GC, có thể ảnh hưởng latency gửi/nhận; chạy riêng thì tốn hơn nhưng cách ly.
• File nhỏ xử lý nhiều tầng: gộp trong bộ đệm, micro-batch 32 MB, file đích 64 MB, cuối cùng compaction nền. Partition theo trường, theo thời gian, bucket, truncate, kết hợp nhiều chiều.

Vì sao

• Theo Alibaba: đường dài thì nhiều ranh giới hệ thống, bề mặt lỗi lớn, đường phục hồi phức tạp; chi phí còn tiến tới "Kafka + object storage" thay vì "Kafka + ETL + object storage". Độ tươi dữ liệu xuống mức phút, có lúc gần mức giây.
• Giới hạn tự nêu: tổng hợp theo cửa sổ, join nhiều stream, tra bảng chiều, state lớn thì vẫn cần Flink/Spark. Hai bên là phân công, không thay thế.

Bài học cho SWE

• Một job stream chỉ để "chép từ Kafka vào bảng" là ứng viên để thay bằng năng lực có sẵn của nền tảng; job tính toán thật thì giữ (Pipeline dữ liệu và analytics).
• Ghi liên tục vào lake sinh file nhỏ: phải kiểm soát từ lúc ghi (gom lô, kích thước đích), không chỉ trông vào compaction sau.
• Đánh đổi kinh điển giữa tần suất commit (độ tươi) và chi phí metadata (throughput) có thể nới bằng cách làm phần nặng trước, commit phần nhỏ sau.
• Khi lưu trữ bền nằm ở object storage, replica của tầng compute chỉ cần là standby nhẹ, không cần giao thức nhân bản dữ liệu nặng (Tách compute khỏi storage).

Liên quan

• Batching và khấu hao round-trip
• Stream processing
• Grab 2026 · ClickHouse 2025 · Alibaba 2026 · Alibaba 2018
• Pipeline dữ liệu và analytics · Tách compute khỏi storage · Event-driven, message queue và Kafka