Apache Spark Resource Optimization: Lessons From Eight Million Jobs a Day

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

Có nhắc một "agentic profiling skill" sinh SQL từ câu hỏi tự nhiên; wiki chỉ ghi ngắn phần đó.

Bối cảnh

• Data 360 của Salesforce chạy khoảng 8 triệu lần Spark mỗi ngày (2026), từ job ngắn tới job xử lý TB trong nhiều giờ. Hoá đơn compute tăng trong khi job vẫn thành công. Theo bài: thành công chỉ chứng minh cấu hình chạy được, không chứng minh nó hiệu quả.
• Ví dụ: một workload xin 40 executor lúc khởi động mà phần lớn không có việc: pod churn, node churn, năng lực bỏ không, nhưng không bao giờ lỗi. Ước tính theo tenant hay khối lượng dữ liệu chỉ giúp chọn cấu hình trước khi chạy, không cho biết nó dùng thế nào lúc chạy.

Thay đổi chính

• Thu telemetry ở chỗ dùng chung, không sửa code ứng dụng: mọi Spark được nộp qua Data Processing Controller (DPC), gateway chung. Gắn plugin listener của Spark (mở rộng từ DataFlint) ở đó, đẩy metric vào Kafka. An toàn: listener dùng hàng đợi listener-bus riêng; nếu instrumentation không cấu hình được thì job vẫn chạy; có alert cho lỗi xuất và lỗ hổng telemetry.
• Diễn giải đúng trước khi kết luận: lớp phân tích Silver (ứng dụng, job, stage attempt, executor) mã hoá ngữ nghĩa: chỉ dùng lần chạy hoàn chỉnh trong cùng phạm vi workload và môi trường; stage chạy lại là việc tốn tiền thêm nhưng không phải việc logic mới; memory spill và disk spill là hai biểu hiện của cùng một áp lực, cộng lại là sai; ghi rõ chỗ thiếu số đo; chi phí = pod driver + mọi pod executor của ứng dụng.
• Hỏi đúng câu trước: workload đắt nào lặp đi lặp lại cấp executor hoàn thành 0 task? Xếp hạng top 10 theo chi phí phục vụ, CPU rảnh, executor 0 task. Phân biệt: executor 0 task ủng hộ thử cấp ít hơn lúc đầu; CPU rảnh cao ở executor có việc là mẫu khác; fetch failure khi shuffle nặng là vấn đề độ tin cậy riêng, không phải thừa tài nguyên.
• Kiểm chứng ở production: workload 40 executor giảm initialExecutors còn 4, giữ dynamic allocation: hơn một tháng không xấu về runtime, retry, lỗi. Một nhóm khác (executor rảnh trên 90%) giảm trần executor khoảng 20%. Rollout theo tầng môi trường; trước mỗi bước kiểm p95 runtime, retry, OOM, spill, cùng pod churn, node churn, tiêu thụ IP prefix và áp lực etcd (phải ổn cho cả ứng dụng lẫn nền tảng chạy nó).
• Kết quả: chi phí compute theo tuần của các workload mục tiêu giảm 31% (so bốn tuần trước và sau), trong khi số job khởi chạy tăng hơn 7%.

Vì sao

• Không ai nhìn thấy lãng phí khi tín hiệu duy nhất là "job thành công"; phải so năng lực xin với việc thật trên dữ liệu thu nhất quán (Chi phí hạ tầng và build vs buy, Pipeline dữ liệu và analytics).

Bài học cho SWE

• Coi ước tính tài nguyên là giả thuyết; dùng dữ liệu chạy thật để chọn thay đổi, và lần chạy sau để xác nhận.
• Tìm một ranh giới dùng chung (gateway nộp job) để instrument mọi workload mà không cần team ứng dụng làm gì; instrumentation hỏng không được làm hỏng job.
• Trước khi tin một con số tổng hợp, xác định nó đếm gì, gồm lần chạy nào, thiếu dữ liệu ở đâu.
• Thay đổi tài nguyên phải kiểm cả tác động lên nền tảng (churn, IP, etcd), không chỉ lên job.

Liên quan

• Notion 2026 · Salesforce 2019 · Medium 2016
• Chi phí hạ tầng và build vs buy · Pipeline dữ liệu và analytics