Data Preprocessing in Uber ETA
Tiền xử lý trong ETA của Uber
Công ty nào đang ứng dụng Tiền xử lý dữ liệu?
Bạn mở ứng dụng Uber, màn hình hiện “Tài xế đến trong 4 phút.” Con số đó không phải đoán mò — nó đến từ DeepETA, hệ thống học sâu của Uber, phục vụ hàng triệu chuyến đi mỗi ngày ở hơn 10.000 thành phố.
Trước khi bất kỳ mô hình nào chạy, Uber phải giải bài toán “rửa rau”: dữ liệu GPS từ hàng triệu điện thoại bị nhiễu, toạ độ nhảy giữa các toà nhà cao tầng, mất tín hiệu trong hầm, và múi giờ lộn xộn giữa các chuyến. Không có bước tiền xử lý, ETA có thể sai hàng chục phút.
Vấn đề công ty cần giải quyết
Mỗi chiếc điện thoại trong chuyến đi liên tục gửi toạ độ về Uber. Nhưng tín hiệu thô cực kỳ bẩn:
Urban canyon
Tín hiệu từ vệ tinh bật qua các toà nhà trước khi đến điện thoại → vị trí lệch 20–50 m giữa phố cổ hoặc khu đô thị mới.
Mất tín hiệu
Hầm đỗ xe, garage ngầm, đường hầm → GPS mất hàng chục giây. Chuỗi toạ độ xuất hiện 'lỗ đen' mà model không biết cách xử lý.
Điểm trùng lặp
Điện thoại gửi cùng toạ độ 2–3 lần do lỗi mạng / retry. Nếu đếm cả điểm trùng, model nghĩ xe đang đứng yên.
Múi giờ lộn xộn
Có thiết bị gửi UTC, có thiết bị gửi giờ thành phố. Trừ nhầm múi giờ → sai giờ đón 7 tiếng.
Giao thông thì biến động liên tục: một tai nạn có thể biến đoạn 5 phút thành 30 phút. “Garbage in, garbage out” — nếu không làm sạch, DeepETA không thể dự đoán sát thực tế.
Cách Tiền xử lý dữ liệu giải quyết vấn đề
Khử nhiễu GPS bằng map-matching.GPS thô báo bạn đang đứng giữa toà nhà, nhưng thực ra bạn đang đi trên đường. Uber dùng Hidden Markov Model (HMM — mô hình Markov ẩn) để “kéo” mỗi điểm về đoạn đường gần nhất trong bản đồ. Hệ thống có hai tầng: online matcher cho hiển thị thời gian thực, và offline reprocess chạy lại chính xác hơn để huấn luyện model. Bước này giảm sai số vị trí từ 50–100 m xuống dưới 5 m.
Xử lý missing bằng sensor fusion.Khi GPS mất tín hiệu (hầm, garage), Uber không “bỏ qua” như một imputer thông thường. Thay vào đó, hệ thống kết hợp gia tốc kế, con quay hồi chuyển, và áp kế trên điện thoại để ước lượng vị trí — giống như đi với la bàn khi bạn bịt mắt. Đây là cách “điền missing” ở quy mô công nghiệp.
Feature discretization (rời rạc hoá đặc trưng). DeepETA không dùng giá trị liên tục trực tiếp. Khoảng cách, giờ trong ngày, ngày trong tuần đều được gộp thành bucket (nhóm). Toạ độ (lat, lon) được mã hoá vào lưới đa phân giải — trung tâm Manhattan cần ô lưới nhỏ, vùng ngoại ô dùng ô to. Thực nghiệm của Uber cho thấy bucketing giúp model học pattern tốt hơn raw value.
Feature real-time qua Kafka. Mỗi yêu cầu ETA cần đặc trưng cập nhật trong mili-giây: tốc độ trung bình từng đoạn đường (tính từ stream GPS của mọi tài xế), thời gian đã đi qua segment, và đặc trưng hiệu chỉnh phân biệt loại chuyến (giao hàng, đi chung, chuyến riêng). Pipeline này chạy trên Kafka với độ trễ dưới 100 ms.
Thử tự tay
Sandbox 1 — Chạy lại từng bước làm sạch một vệt GPS
Bấm qua các tab dưới đây. Mỗi lần bấm, bạn sẽ thấy vệt GPS từ “loạn xạ” dần dần gọn lại thành một đường đi có thật. Quan sát số điểm, số duplicate, và sai số ETA thay đổi như thế nào.
Bản đồ nội thành (giản lược)
GPS thô — 13 điểm, loạn và lệch
Sai số ETA mô phỏng
± 23 phút
raw, sai số ETA lên tới ±23 phút — lý do mà app giao hàng những năm 2010 liên tục “đánh lừa” khách. Khi toàn bộ pipeline chạy xong, sai số rớt còn ±2 phút, gần sát khoảng Uber công bố trên blog DeepETA.Sandbox 2 — Feature engineering trên từng chuyến đi
Chọn một đặc trưng, xem Uber rời rạc hoá giá trị liên tục thành nhóm thế nào. Mỗi cột là một “bucket” — số chuyến đi được đếm vào ô tương ứng.
Sandbox 3 — Pipeline từ GPS tới ETA, theo thứ tự
Bấm “Tiếp tục” để mở từng giai đoạn. Đây là bộ khung mà mọi ứng dụng vị trí thời gian thực (Grab, Gojek, Lyft, ShopeeFood) đều có, dù chi tiết khác nhau.
Thu dữ liệu GPS và context
Mỗi chuyến đi bắn hàng chục nghìn điểm GPS, kèm tốc độ, hướng, ID chuyến, loại chuyến (giao hàng / đi chung / chuyến riêng). Stream đi vào Kafka với độ trễ ms.
Đoạn pandas ngắn mô phỏng bước 2 của pipeline
import pandas as pd
gps = pd.read_parquet("trip_gps.parquet")
gps = gps.drop_duplicates(subset=["trip_id", "ts", "lat", "lon"])
gps["ts"] = pd.to_datetime(gps["ts"], utc=True)
gps["ts_local"] = gps["ts"].dt.tz_convert("Asia/Ho_Chi_Minh")Đoạn pandas cho bước rời rạc hoá đặc trưng
gps["hour_bucket"] = (gps["ts_local"].dt.hour // 2).astype("int8")
gps["dow_bucket"] = gps["ts_local"].dt.dayofweek.astype("int8")
gps["dist_bucket"] = pd.cut(
gps["distance_km"], bins=[0, 1, 3, 7, 15, 50], labels=[0, 1, 2, 3, 4]
).astype("int8")Thử thách nhanh
Tài xế của bạn chạy vào một hầm đỗ xe 500 m. GPS mất tín hiệu suốt 45 giây. Hệ thống Uber sẽ làm gì?
DeepETA biến cột 'giờ đặt chuyến' thành 48 bucket (mỗi bucket 30 phút). Lợi ích quan trọng nhất?
Vì sao Uber phải giữ 2 tầng: online matcher và offline reprocess cho map-matching?
- GPS thô bẩn hơn bạn tưởng — map-matching giảm sai số vị trí từ 50–100 m xuống dưới 5 m.
- Missing values không chỉ điền bằng mean — sensor fusion là 'điền missing' ở quy mô production.
- Rời rạc hoá đặc trưng (bucketing) không phải thủ thuật — DeepETA đo được accuracy tốt hơn raw.
- Feature real-time qua Kafka: bước tiền xử lý không dừng khi train xong, mà chạy liên tục khi serve.
Kiểm tra hiểu biết
Kiểm tra hiểu biết
Tín hiệu GPS ở trung tâm thành phố hay bị lệch 20–50 m vì sao?
Con số thật
- DeepETA giảm sai số trung bình so với routing engine truyền thống, triển khai trên hơn 10.000 thành phố [1]
- Xử lý hàng tỷ điểm GPS mỗi ngày, sau khử nhiễu sai số giảm từ 50–100 m xuống dưới 5 m [3]
- Feature discretization (bucketing) cho accuracy tốt hơn dùng giá trị liên tục trực tiếp [1]
- Pipeline real-time feature computation xử lý với độ trễ dưới 100 ms qua Kafka [2]
Nếu không có Tiền xử lý dữ liệu, app sẽ ra sao?
Bỏ qua bước tiền xử lý, GPS nhiễu sẽ khiến model nghĩ tài xế đang ở toà nhà bên cạnh thay vì trên đường — ETA có thể sai hàng chục phút. Ngoại lai (tốc độ 300 km/h do GPS nhảy) kéo lệch mọi thống kê trung bình. Dữ liệu thiếu trong hầm và garage tạo “lỗ đen”, khiến model không thể tính thời gian qua đoạn.
Tiền xử lý biến dữ liệu thô đầy nhiễu thành đầu vào sạch: map matching sửa vị trí, sensor fusion lấp lỗ hổng, bucketing chuẩn hoá thang đo, và pipeline real-time đảm bảo đặc trưng luôn mới. Đây là lý do 80% công sức ML nằm ở xử lý dữ liệu — muốn luyện tập thêm kỹ năng pandas cốt lõi, ghé Tiền xử lý dữ liệu và Python cho ML.