Diving into Uber's cutting-edge data infrastructure

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

Nguồn thứ cấp: Onehouse (công ty do người tạo ra Hudi ở Uber lập) tóm tắt talk của Girish Baliga, Director of Engineering ở Uber, tại Open Source Data Summit 2023. Company ghi theo sheet. Mọi nhận định là theo Uber qua lời kể của Onehouse; không có số liệu nội bộ ngoài quy mô kinh doanh.

Bối cảnh

• Uber (2023): hơn 10.000 thành phố, 137 triệu người dùng/tháng, 25 triệu chuyến/ngày. Khách nội bộ của đội Data Infrastructure (vận hành cộng đồng, ML, growth marketing) đều muốn insight từ dữ liệu nhưng khác nhau về độ tươi, quy mô và công cụ.
• Bốn loại nhu cầu: streaming (dưới một phút, ví dụ cân bằng surge pricing, nối với Kafka); real-time (món phổ biến gần bạn trên Uber Eats, tươi nhanh, tới khoảng 2.000 QPS qua RPC); interactive (báo cáo ngày cho chủ nhà hàng); batch (xu hướng một năm).

Thay đổi chính

• Lambda architecture: một luồng dữ liệu vào phục vụ cả hai nhánh. Nhánh realtime: Kafka → Flink → Pinot, trên đó một lớp Presto tự viết cho phép viết Presto SQL chạy trên Pinot như backend production. Nhánh batch: ingest bằng Spark vào data lake (Parquet trên HDFS), Hive dựng data model.
• Hudi (khởi đầu ở Uber, vào Apache năm 2016): theo Onehouse, đưa upsert xuống khoảng 10 phút và độ tươi đầu-cuối từ 24 giờ xuống một giờ, vì xử lý tăng dần thay vì nạp lại; Record Level Index bỏ được kho khoá–giá trị phụ (HBase).
• Ba tầng truy vấn: Presto SQL mặc định (hàng nghìn người dùng, soạn trong QueryBuilder, chạy production qua orchestrator uWorc); Flink SQL/Spark SQL cho UDF và job lớn (hàng trăm người); API lập trình trên Flink/Spark cho ca phức tạp nhất.
• Độ tin cậy và scale: định tuyến truy vấn nặng và nhẹ sang cụm khác nhau; cụm riêng cho interactive và cho job theo lịch; Hive Sync chép dữ liệu sang region phụ, khi mất region thì một cụm Presto dự phòng chạy job ưu tiên cao, còn lại chạy với SLA giảm; retry tự động khi deploy/restart cụm; nhiều bản sao dữ liệu; thêm replica cho shard nóng; erasure coding và tiered storage cho dữ liệu cũ.
• Hiệu năng: reader vector hoá, nested column, predicate pushdown trong Presto; thư viện Alluxio trong worker Presto dùng SSD cục bộ làm cache, kèm affinity scheduling để truy vấn rơi đúng chỗ đã cache.
• Hybrid cloud: đang đưa dữ liệu lên Google Cloud (Hive Sync từ HDFS sang GCS); router Presto hỏi Hive Metastore xem bảng nằm on-prem hay cloud để đặt truy vấn; Presto đọc GCS qua một HDFS client tự viết như thể đọc HDFS.

Vì sao

• Theo Uber, các nhu cầu khác nhau về độ tươi và tải được gom vào một kiến trúc có hai nhánh dùng chung nguồn, thay vì mỗi nhu cầu một hệ (Pipeline dữ liệu và analytics); đường lùi khi mất region là chạy phần quan trọng trước và chấp nhận SLA giảm cho phần còn lại (Độ tin cậy và multi-region).

Bài học cho SWE

• Phân loại khách theo độ tươi và QPS trước khi chọn engine; một engine khó phục vụ cả bốn loại.
• Tách cụm theo loại truy vấn (nặng/nhẹ, interactive/lịch) để truy vấn lớn không làm chậm truy vấn nhỏ.
• Cache cục bộ chỉ có ích khi scheduler gửi việc về đúng nơi đã cache.

Liên quan

• Stream processing
• Netflix 2014 · Stripe 2025 (Pinot cho analytics thời gian thực) · Uber 2025 · Grab 2026
• Pipeline dữ liệu và analytics · Độ tin cậy và multi-region