Scaling data access by moving an exabyte of data to Google Cloud

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

Bối cảnh

2019: Twitter muốn "dân chủ hoá" việc phân tích dữ liệu cho nhân viên và tăng tốc ML. Họ hợp tác với Google Cloud để chuyển một phần hạ tầng dữ liệu sang GCP (BigQuery, Dataflow, Data Studio).
Dữ liệu cũ chủ yếu trên HDFS on-prem, định dạng Thrift, xử lý bằng job Scalding (map-reduce).
Cách đầu tiên: mỗi team tự đưa dữ liệu của mình vào BigQuery bằng thư viện Scalding được cung cấp. Vấn đề:
- proxy giới hạn 77 Gbit/s từ data center sang GCP;
- map-reduce chậm;
- mỗi dataset mất ~2 tuần phát triển (cấp quyền, học công cụ);
- mỗi pipeline tự quản nên không ai thấy bức tranh tổng.

Thay đổi chính

Framework tập trung, tự động, xây trên các dịch vụ có sẵn (Dataflow, Airflow): ingest hơn 1.000 dataset chỉ bằng một file cấu hình.
Chuyển logic xử lý phức tạp từ Scalding sang Dataflow; tận dụng auto-scaling của GCP thay vì tự cân dung lượng on-prem.
Tự phát hiện schema, partition theo giờ, nên tỷ lệ lỗi giảm. Có hệ thống giám sát tập trung.
Bản đầu tiên xong trong dưới 3 tháng.

Kết quả (5/2022)

Hơn 10 triệu query/tháng trên gần một exabyte dữ liệu trong BigQuery; phục vụ phân tích sản phẩm Ads, sinh feature cho ML, một phần mô hình cá nhân hoá.
Thời gian ingest một dataset mới: 2 tuần → 1 giờ; throughput ingest +100%.
Người dùng nội bộ: ~50 → ~500; data availability +165% trong chưa tới 6 tháng.

Vì sao

Theo Twitter: on-prem giới hạn dung lượng xử lý và đòi hỏi lên kế hoạch cẩn thận; cloud cho auto-scaling và công cụ có sẵn, để kỹ sư tập trung vào logic xử lý.

Bài học cho SWE

"Mỗi team tự làm" không scale; một framework cấu hình hoá biến việc mất hai tuần thành việc mất một giờ. Cùng tinh thần Nền tảng nội bộ cho service (đường ray chung).
Hybrid hợp lý: phần serving vẫn on-prem, phần phân tích lên cloud. Chiều ngược với Dropbox, vốn kéo storage từ cloud về (Dropbox 2016).
Bài không nói chi phí so với on-prem, nên không suy ra được cloud rẻ hơn hay đắt hơn.