Running Cost-Efficient Export Workloads at Uber

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

Bối cảnh

Export workload (tuân thủ, quyền riêng tư, xuất dữ liệu vận hành; ví dụ DSAR, yêu cầu của một người xem dữ liệu cá nhân mà công ty giữ): query điểm hoặc predicate hẹp theo rider/driver/courier ID trên bảng giao dịch Hudi lớn chia partition theo ngày, chạy nhiều lần mỗi tuần, cùng mẫu khác tham số, kết quả rất nhỏ, nhưng vẫn quét cả bảng.
Lakehouse của Uber nằm trên Google Cloud Storage với Autoclass: dữ liệu ít đụng tới tự xuống lớp rẻ hơn. Analytics thường quét nhiều nhưng ở partition gần đây, để dữ liệu cũ nguội đi; export thì ngược lại, mò kim đáy bể trên toàn bộ lịch sử, giữ mọi file "nóng", chặn chuyển lớp, tăng chi phí lưu trữ, phí truy xuất, phí thao tác metadata loại B (objects.get, objects.list), egress và latency.

Secondary index của Hudi không giúp đủ: bản ghi của cùng một người rải trên hầu hết các file, nên index tìm được dòng ứng viên nhưng vẫn trỏ tới một tập file lớn, cộng thêm chi phí metadata và vận hành.
Thống kê cột trong metadata table của Hudi (min, max, số null, số dòng cho mỗi file) để loại file mà không mở file. Thống kê trong footer Parquet không đủ: đọc footer vẫn là đụng tới file, vẫn giữ file nóng.
Sắp xếp bảng theo cột predicate (ID của người): gom khoá giống nhau vào ít file, thu hẹp khoảng min/max của từng file, nên việc loại file thật sự chọn lọc. Thống kê cột là cơ chế, sắp xếp làm cơ chế hiệu quả. Benchmark trên một partition thật với 100 tới 5.000 ID: số file Parquet chứa các dòng cần tìm giảm mạnh sau khi sắp xếp.
Không cần cả sắp xếp lẫn secondary index: thống kê cột tăng theo số file và số cột được theo dõi, còn secondary index phải giữ ánh xạ cho từng giá trị; sau khi đã sắp xếp, thống kê cột đủ và nhẹ hơn.
Hudi Table Service lo backfill sắp xếp, dựng index, sắp xếp tăng dần. Hướng tiếp: Z-order cho bảng có nhiều cột predicate khác nhau; tự phát hiện mẫu truy cập "kim đáy bể" và chỉ chạy tối ưu bố cục khi lợi đủ bù chi phí.

Chi phí lưu trữ cloud phụ thuộc vào cách dữ liệu bị đụng tới chứ không chỉ vào dung lượng; một query nhỏ mà chạy lặp trên toàn lịch sử có thể quyết định lớp lưu trữ của cả bảng.

Mẫu truy cập quyết định chi phí: phân biệt quét rộng trên dữ liệu gần với tra hẹp trên toàn lịch sử.
Cắt file bằng metadata nằm ngoài file dữ liệu; đọc footer cũng là một lần truy cập.
Bố cục vật lý (sắp xếp theo cột hay lọc) là điều kiện để thống kê min/max có tác dụng.
Viết lại bảng một lần tốn tiền trước nhưng giữ được tiết kiệm lâu dài; nếu không thiết kế đầu–cuối, chi phí chỉ chuyển từ lớp này sang lớp khác.