Apache Hudi at Uber: Engineering for Trillion-Record-Scale Data Lake Operations

Uber · 2026 · 3. Quy mô lớn · Độ khó: Khó — bài gốc

Bối cảnh

• Khoảng 2015, data lake chuẩn của ngành là file, chỉ append, batch. Workload quan trọng của Uber thì khác: dữ liệu thay đổi (vòng đời chuyến, trạng thái đơn, thuộc tính thiết bị), stream có tỉ lệ update cao, và cần xử lý tăng dần thay vì tính lại cả bảng. Uber tự làm Hudi (sau thành dự án Apache): đưa ACID transaction, index + upsert nhanh, và đọc tăng dần (chỉ đọc phần đổi từ commit trước) vào data lake.

Thay đổi chính

• Quy mô 2026, theo Uber: 19.500 dataset Hudi; 6 nghìn tỉ dòng và 3 triệu file mới mỗi ngày; 350 PB logic trên HDFS và Google Cloud Storage; 10 PB ingest mỗi ngày; 350.000 commit/ngày; 70.000 lượt table service (compaction, clean, clustering) mỗi ngày; 4 triệu query/tuần qua Presto và Spark; bảng lớn nhất trên 400 tỉ dòng cập nhật liên tục.
• Bốn lớp workload, cấu hình khác nhau: append-only (11.200 bảng, bulk insert, tốc độ quyết định SLA độ tươi), upsert nặng (4.400 bảng, tra index), dẫn xuất (1.600 bảng, đọc tăng dần từ bảng nguồn; bảng nguồn append-only nhưng bảng tổng hợp tăng dần thành dữ liệu thay đổi), real-time bằng Flink (500 bảng, độ tươi dưới 15 phút; tối ưu file chạy bất đồng bộ qua Table Services Platform để không chặn ingest).
• Metadata Table (MDT): list file làm quá tải NameNode của HDFS khi có hàng chục nghìn dataset, mỗi cái hàng nghìn partition và hàng triệu file. MDT là kho key-value do Hudi quản lý (HFile, dạng SSTable) giữ danh sách file, thống kê cột (min/max mỗi file Parquet), bloom filter; list thư mục thành một lượt tra khoá. Đã bật cho hơn 90% dataset.
• Record Index (RI): upsert phải tìm đúng file chứa bản ghi; bloom filter hay quét file không đủ ở quy mô nghìn tỉ. Ban đầu dùng index HBase bên ngoài (mạnh nhưng thêm phụ thuộc vận hành), sau thay bằng RI nằm trong MDT, ánh xạ khoá → file group. Dùng cho 3.600 bảng; bảng trên 300 tỉ dòng chia RI thành tới 10.000 HFile để tra song song; tra một khoá mất 1–2 ms; khởi tạo RI cho bảng 300 tỉ dòng mất khoảng 7 giờ với khoảng 4.000 executor.
• HiveSync cho nhiều data center và cloud: dataset chính + bản sao ở vùng khác; commit timeline nguyên tử của Hudi cho phép đẩy mọi lần ghi sang vùng phụ một cách nhất quán; công cụ đối chiếu giữ hai bên khớp; dịch vụ availability nâng bản phụ khi có sự cố, query được định tuyến tới vùng gần hoặc khoẻ nhất. Một phần lake đã chuyển lên cloud không downtime.
• Bài học, theo Uber: schema evolution là chuyện hạng nhất từ ngày đầu (một lần đổi tên vô hại có thể làm vỡ hàng nghìn job hạ nguồn); lên kế hoạch quanh workload khó nhất trước (index là xương sống của lake có dữ liệu thay đổi); nhiều sự cố khó nhất đến từ lỗi âm thầm (file hỏng, cấu hình sai, bug mã nguồn mở) nên cần công cụ kiểm tra tự động; quản lý cấu hình thành nút thắt nhanh hơn gần như mọi thứ (vài override mỗi dataset thành hàng chục nghìn cấu hình khác nhau) nên có Hudi Config Store tập trung để rollout thay đổi trên hàng nghìn dataset; shadow pipeline, backfill và sửa tự động biến phục hồi từ nhiều ngày thành runbook.
• Hướng tiếp: IngestionNext chuyển ingest batch → streaming, ghi checkpoint ID của Flink vào commit metadata để phục hồi tất định không trùng dữ liệu, merge theo row group làm compaction nhanh hơn 10 lần, độ trễ từ giờ xuống phút. Làm với Onehouse để đưa commit của bản fork nội bộ về upstream và lên Hudi 1.x, thử ghi kép sang Iceberg để có dữ liệu cho quyết định định dạng bảng.

Vì sao

• Không có hệ nào lúc đó cho bảng tươi, query được, có ACID và upsert nhanh trên dữ liệu thay đổi liên tục; Uber cần đặc tính của database mà không bỏ tính mở và quy mô của data lake.

Bài học cho SWE

• Ở quy mô lớn, metadata (danh sách file, thống kê) là tải riêng cần kho riêng; đừng để mọi thao tác hỏi filesystem.
• Phụ thuộc ngoài (HBase làm index) giải được bài toán ban đầu nhưng là chi phí vận hành; khi đủ quy mô thì đưa về trong hệ.
• Cấu hình theo từng dataset sẽ trôi; tập trung hoá trước khi có hàng chục nghìn biến thể.
• Bản fork nội bộ sống lâu là nợ; kế hoạch đưa về upstream là một dự án riêng.

Liên quan

• Pipeline dữ liệu và analytics · Độ tin cậy và multi-region
• Cùng công ty: Uber 2026 (HiveSync/Distcp) · Onehouse 2024