Scaling Grab's Data Lake: Our journey to Apache Iceberg adoption

Grab · 2026 · 4. Điều chỉnh · Độ khó: Trung bình — bài gốc

Bối cảnh

• Data lake của Grab: hàng petabyte, hàng tỉ object trên S3, phục vụ cả metric gần thời gian thực lẫn batch lớn qua hai nền tảng nội bộ (Slide cho batch, Hugo cho ingest từ hệ online). Nhiều năm, phần lớn bảng là Hive Parquet quản lý bằng Hive Metastore (HMS) với bố cục theo thư mục.
• Bốn nút cổ chai khi dữ liệu lớn lên:
  • HMS thành điểm lỗi trung tâm; thời gian lập kế hoạch truy vấn tăng tuyến tính theo số partition do phải liệt kê.
  • File nhỏ: vài dataset ML trung bình dưới 1 MB/file, hàng nghìn file mỗi partition, làm tăng chi phí API S3 và chậm scan.
  • Việc tay: đăng ký partition thủ công; không có ACID (không UPSERT/DELETE) nên phải làm vòng.
  • Catalog và storage lệch nhau: HMS là nguồn sự thật, sửa thẳng trên S3 làm catalog cũ.

Thay đổi chính

• Chọn Apache Iceberg làm định dạng mặc định (theo Grab vì quản trị cộng đồng, tương thích engine, linh hoạt lâu dài), nhưng vẫn muốn giữ khả năng không phụ thuộc định dạng.
• Chuyển dần, bảng giá trị cao trước, không đổi cả lake một lần, để không làm hỏng consumer hạ tầng đang đọc bảng bằng nhiều engine. Kết quả theo Grab:
  • Bảng điều hướng truy cập nhiều: Z-ordering cho Trino bỏ qua file không liên quan, truy vấn từ 70 xuống 6 giây.
  • Bảng vận hành truy vấn nhiều: chi phí API S3 mỗi ngày giảm tới 95% mà không đổi truy vấn (file lớn hơn, bỏ liệt kê object).
  • Dataset phân tích phễu: tài nguyên cluster giảm khoảng một nửa.
• UnifiedSparkCatalog (mở mã nguồn): Spark chỉ có một catalog mặc định, nên khi Iceberg, Delta, Hudi, Hive cùng tồn tại người dùng phải gõ tiền tố theo định dạng, và mỗi lần một bảng đổi định dạng thì mọi truy vấn hạ nguồn có tiền tố cứng đều hỏng. Catalog mới đọc metadata từ HMS, nhận diện định dạng, chuyển thao tác sang catalog riêng của định dạng đó (ý tưởng từ Table Redirection của Trino). Tự đặt tên spark_catalog để giữ các đường code Hive cũ; khởi tạo lười; thiếu JAR của định dạng nào thì bỏ qua định dạng đó; không thấy bảng thì rơi về catalog gốc.
• Trục trặc khi rollout: khoá "zombie" trong HMS chặn commit do read timeout thấp dưới tải (tăng timeout, chỉnh retry); Spark 3.4 dùng TIMESTAMP_NTZ còn Iceberg mặc định TIMESTAMP_LTZ, lệch với view Hive cũ (workflow migration riêng, vá Trino); sinh metadata Iceberg phải đọc dữ liệu cũ nên gây spike chi phí một lần khi file chuyển tầng lưu trữ S3, nên ưu tiên migration theo tần suất scan và chi phí API thay vì đổi hết.

Vì sao

• Bố cục theo thư mục với một metastore trung tâm không scale theo số partition và số file; định dạng bảng giữ metadata cùng dữ liệu bỏ được việc liệt kê và cho ACID.

Bài học cho SWE

• Migration định dạng dữ liệu nên chọn bảng theo giá trị và chi phí, không đổi tất cả cùng lúc (Migration không downtime).
• Khi hai định dạng phải sống chung lâu, đặt một lớp chuyển hướng để người dùng không phải biết bảng đang ở định dạng nào; migration không làm vỡ truy vấn hạ nguồn.
• Tính cả chi phí một lần của chính migration (đọc lại dữ liệu lạnh) vào kế hoạch (Chi phí hạ tầng và build vs buy).
• Cùng hướng với Meta 2026: thay nền tảng dữ liệu dần dần, giữ giao diện cho người dùng (Meta 2026).

Liên quan

• Pipeline dữ liệu và analytics
• Cùng công ty: Grab 2016 · Grab 2017 · Grab 2018 · Grab 2019 · Grab 2022 · Grab 2024 · Grab 2025
• Migration không downtime · Chi phí hạ tầng và build vs buy