How Uber Scaled Data Replication to Move Petabytes Every Day

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

Bối cảnh

• Data lake của Uber (hơn 350 PB) nằm ở cả on-premises lẫn cloud. HiveSync (dựng từ dự án ReAir của Airbnb) giữ các lake đồng bộ, cả bulk lẫn tăng dần, dùng Distcp của Hadoop (copy phân tán bằng MapReduce) cho bản sao lớn hơn 256 MB.
• Q3/2022, điểm gãy: lượng nhân bản mỗi ngày từ 250 TB lên 1 PB trong một quý. Hai nguyên nhân: năm 2022 Uber chuyển data lake sang active-passive để tiết kiệm, data center chính sinh 90% dữ liệu và chạy phần lớn batch, nên HiveSync thành đường DR duy nhất; và mọi dataset Hive on-prem được đưa vào HiveSync (từ 30.000 lên 144.000 dataset trong một quý). Số job nhân bản mỗi ngày từ 10.000 lên trung bình 374.000, tồn đọng lớn, khó giữ SLA độ trễ P100 4 giờ và SLO P99.9 20 phút. Chuyển lake lên cloud được dự báo gần gấp đôi tải nữa.

Thay đổi chính

• Dời việc chuẩn bị sang Application Master (AM): thread dump lúc sự cố cho thấy phần lớn thread chờ một khoá của HDFS client dùng chung trên server HiveSync; Copy Listing (liệt kê file, chia block) chiếm 90% thời gian submit job, và số lượt gọi NameNode tỉ lệ với số file. Chuyển Copy Listing và Input Splitting vào container AM của từng job: độ trễ submit giảm 90%.
• Song song hoá Copy Listing: file liệt kê song song được (thứ tự giữa các file không quan trọng) nhưng các chunk của một file phải liền và đúng thứ tự cho bước ghép; mỗi file một thread đẩy chunk vào blocking queue, một thread ghi tuần tự vào sequence file. Với 6 thread: p99 độ trễ listing −60%, tối đa −75%.
• Song song hoá Copy Committer: ghép chunk thành file vốn tuần tự, thư mục trên 500.000 file mất tới 30 phút; chuyển sang mỗi thread ghép một file.
• Uber job cho job nhỏ: khoảng 52% job chỉ cần một mapper (dưới 512 MB, dưới 200 file), thời gian chủ yếu là cấp container YARN và khởi động JVM; chạy mapper ngay trong JVM của AM (mapreduce.job.ubertask.*), bỏ khoảng 268.000 lần khởi động container mỗi ngày.
• Kết quả, theo Uber: năng lực nhân bản tăng dần trên on-prem gấp 5 trong một năm, không có sự cố do scale; đã chuyển hơn 306 PB lên cloud; thêm metric cho thời gian submit, copy rate p99, heap của container.
• Vấn đề khi rollout: AM bị OOM (stress test để tìm cấu hình bộ nhớ); submit nhanh hơn làm YARN báo "Queue Full", nên thêm circuit breaker tạm dừng submit mới cho tới khi retry thành công; tốc độ copy cao ăn băng thông mạng; Copy Listing chạy trong pha setup của AM có lúc quá 10 phút trong khi heartbeat tới Resource Manager chỉ bắt đầu sau setup, làm AM bị coi là chết, nên dời sang setup của output committer (sau khi heartbeat đã chạy).

Vì sao

• Distcp scale tốt phần copy dữ liệu nhưng làm phần lập kế hoạch ở phía client dùng chung; khi số job tăng 37 lần, phần nhỏ đó thành nút thắt.

Bài học cho SWE

• Đổi kiến trúc để tiết kiệm (active-passive) dồn tải vào một đường duy nhất (nhân bản DR); tính tải mới đó trước khi đổi.
• Tìm nút thắt bằng thread dump: một khoá trong client dùng chung có thể là trần của cả hệ.
• Với việc nhỏ, chi phí dựng môi trường (container, JVM) lấn át việc thật; gom vào tiến trình đã có.
• Bỏ một nút thắt sẽ đẩy tải xuống hạ nguồn (YARN queue); chuẩn bị circuit breaker trước.
• Việc dài trong pha khởi tạo có thể làm trễ heartbeat và bị coi là chết.

Liên quan

• Độ tin cậy và multi-region · Batching và khấu hao round-trip
• Cùng công ty: Uber 2026 (HiveSync trong kiến trúc Hudi)
• Cùng bài toán: Mercari 2026 (chi phí dựng môi trường lấn át việc thật)