Using Presto in our Big Data Platform on AWS
Bài tóm tắt Netflix 2014 3. Quy mô lớn Độ khó: Trung bình
Netflix · 2014 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc
Bối cảnh
- Nền big data của Netflix (2014) đặt data warehouse trên S3: compute tách khỏi storage, nhiều cụm (chạy dài hay tạm) cùng đọc chung dữ liệu. User viết job Pig hoặc Hive cho ETL và phân tích; một phần nhỏ kết quả và dữ liệu tổng hợp chuyển sang Teradata cho truy vấn tương tác và báo cáo.
- Còn thiếu: khám phá dữ liệu tương tác, latency thấp, trên toàn bộ dữ liệu ở S3. DW khoảng 10 PB; user ở nhiều bộ phận truy vấn đủ loại dataset trên khoảng thời gian dài, nên cache một dataset trong bộ nhớ không hiệu quả (tỉ lệ trúng rất thấp trừ khi cache to vô lý).
Thay đổi chính
- Chọn Presto (Facebook vừa mở mã): kiến trúc DAG dạng streaming hợp với kiểu khám phá rời rạc; connector thân thiện Hadoop nên cắm được file system S3 (một tháng làm cùng Facebook là chạy thử); ANSI SQL; đã chạy production ở Facebook; họ benchmark, stress test và đọc code trước khi quyết.
- Production (bảy tháng): khoảng 250 worker m2.4xlarge, coordinator r3.4xlarge, khoảng 2.500 query mỗi ngày làm việc. Cụm Presto cách ly hoàn toàn khỏi các cụm Hadoop, nhưng cùng đọc DW trên S3. Không dùng đĩa (không HDFS). Hầu hết job nghẽn CPU; bộ nhớ task đặt cao (7 GB, chấp nhận rủi ro nhỏ quá cấp) cho join lớn.
- Phân vai: user vào Presto trước để có câu trả lời nhanh; Presto không làm được (join/aggregation vượt bộ nhớ, UDF thiếu) thì quay về Hive/Pig. Presto không dùng cho pipeline production quan trọng; muốn đưa query vào production phải viết lại bằng HiveQL hay Pig.
- Benchmark trên dữ liệu và query thật của họ (không dùng TPC-H/TPC-DS): query một–hai pha MapReduce nhanh hơn 10–100 lần trên Presto, tỉ lệ thuận với số job MR; query chỉ quét bảng thì phụ thuộc tốc độ đọc của format file.
- Đóng góp ngược: file system S3, tối ưu multipart upload, tắt liệt kê thư mục đệ quy, xử lý timeout socket S3; hỗ trợ Parquet (predicate pushdown, truy cập cột theo vị trí vì schema evolution làm trên Hive metastore là nguồn sự thật), ODBC/JDBC cho Tableau, kiểu map (event qua pipeline Suro lưu dạng key/value trong cột map; tra một key từng phải đổi cột sang JSON rồi parse). Muốn không giữ bản vá riêng, đóng góp hết lên upstream.
- Mong muốn: join bảng lớn (hash join phân tán, sort-merge join), và thu nhỏ cụm êm (drain node trước khi tắt) để co cụm ngoài giờ làm việc.
Vì sao
- Khi dữ liệu nằm ở S3 chứ không trong cụm, thêm một engine mới chỉ là dựng thêm một cụm compute đọc cùng chỗ đó, không phải chép dữ liệu (Tách compute khỏi storage).
- Mỗi engine một vai: Pig/Hive cho ETL production, Presto cho tương tác, Teradata cho báo cáo; không ép một hệ làm mọi việc (Chọn database theo workload, Pipeline dữ liệu và analytics).
Bài học cho SWE
- Benchmark bằng query của chính mình; con số tương đối mới dịch được ra kỳ vọng thực tế.
- Workload truy vấn rời rạc trên dữ liệu khổng lồ không cứu được bằng cache; cần engine quét nhanh.
- Dùng open source ở quy mô lớn thì đóng góp ngược để không phải giữ bản vá riêng.
- Tách compute khỏi storage mở đường cho co giãn theo giờ, nhưng engine phải hỗ trợ rút node êm thì mới tận dụng được.
Liên quan
Được nhắc tới trong
Công ty (1)
Bài tóm tắt (1)