Chúng tôi đã cắt giảm 44% chi phí tính toán Spark bằng AI và Datadog Jobs Monitoring

Theo dõi Cách chúng tôi cắt giảm 44% chi phí tính toán Spark bằng AI tác tử và Datadog Jobs Monitoring quan sát dữ liệu spark ai Đã xuất bản 1/6/2026 Thời gian đọc 9 phút Charles Yu Meghna Banerjee Eddie Cai Các tác vụ Spark ngày càng trở nên đắt đỏ và khó gỡ lỗi khi chúng mở rộng quy mô. Đây là một vấn đề mà chúng tôi đã gặp phải. Nhóm Nền tảng Dữ liệu Tham chiếu của chúng tôi xây dựng và duy trì biểu đồ tri thức ánh xạ các mối quan hệ giữa các thực thể quan sát của khách hàng. ServiceQueryEdge là trung tâm của biểu đồ đó, ánh xạ các thực thể dịch vụ tới các truy vấn chỉ số và nhật ký liên quan của chúng. Nó chạy hàng ngày trên bảy trung tâm dữ liệu, với các phân vùng riêng lẻ xử lý tới 27 TB dữ liệu đầu vào và 16 tỷ bản ghi. Ở quy mô đó, chúng tôi đã chi trung bình 1.500 USD chi phí cơ sở hạ tầng mỗi ngày, với mỗi lần chạy mất hơn 17 giờ. Các tác tử AI dường như là một giải pháp phù hợp tự nhiên cho vấn đề này. Chúng giỏi trong việc suy luận về mã, kết nối các triệu chứng với nguyên nhân gốc rễ và nhanh chóng tạo ra các giả thuyết. Nhưng một tác tử chỉ làm việc dựa trên mã vẫn chỉ là phỏng đoán. Nó cần biết điều gì thực sự chậm. Trong bài đăng này, chúng tôi sẽ trình bày cách chúng tôi sử dụng Datadog’s Data Observability Jobs Monitoring và một tác tử AI được xây dựng trên Claude để gỡ lỗi và tối ưu hóa ServiceQueryEdge. Chúng tôi sẽ đề cập đến những gì đã hiệu quả, những gì không, và những thay đổi cụ thể đã cắt giảm 44% chi phí tính toán hàng ngày và giảm 60% thời gian chạy tại US1, trung tâm dữ liệu lớn nhất của chúng tôi. Thu hẹp khoảng cách giữa Jobs Monitoring và cơ sở mã Để hiểu được những điểm không hiệu quả, chúng tôi dựa vào Jobs Monitoring với Spark SQL Plan để có được một biểu diễn trực quan, tương tác của toàn bộ kế hoạch thực thi. Tuy nhiên, ngay cả với khả năng hiển thị đó, việc tương quan một toán tử chậm trong SQL Plan trở lại phần mã ứng dụng có liên quan vẫn có thể mất thời gian, đặc biệt đối với một tác vụ lớn, phức tạp như ServiceQueryEdge. Để tăng tốc gỡ lỗi, chúng tôi đã xây dựng một tác tử AI để làm nổi bật bất kỳ nút thắt nào trên biểu đồ thực thi và đề xuất các bản sửa lỗi. Chúng tôi đã tạo một cấu trúc lời nhắc tùy chỉnh để nhập cùng một dữ liệu được hiển thị trong Jobs Monitoring, chẳng hạn như các chỉ số giai đoạn, kế hoạch thực thi SQL và dữ liệu đo từ xa, cùng với mã nguồn. Điều này cho phép tác tử thực hiện công việc tương quan mà thông thường sẽ do một trong các kỹ sư của nhóm đảm nhiệm, tiết kiệm hàng giờ điều tra thủ công. Đối với mỗi vấn đề mà tác tử gắn cờ, kỹ sư sẽ trực tiếp đến nút có liên quan với ngữ cảnh về lý do tại sao nó quan trọng. Thu nhận tín hiệu từ nhiễu: giới hạn phạm vi dữ liệu để gỡ lỗi có hỗ trợ AI Ban đầu, chúng tôi gặp vấn đề với việc Claude cạn kiệt ngữ cảnh khi thực hiện các lệnh gọi Giao thức Ngữ cảnh Mô hình (MCP) thông qua Máy chủ MCP Datadog của chúng tôi để thu thập dữ liệu Spark từ Giám sát Tác vụ. Tác nhân đã kéo dữ liệu đo từ xa về chạy tác vụ, được biểu thị dưới dạng dấu vết, bằng cách sử dụng các công cụ get_datadog_trace, apm_search_spans và apm_explore_trace. Nhiều lần chạy đã làm cho vấn đề trở nên tồi tệ hơn. Tác nhân đã cạn kiệt cửa sổ ngữ cảnh trước khi hoàn thành phân tích có ý nghĩa. Các đề xuất trở nên không đầy đủ hoặc không mạch lạc. Chúng tôi đã khắc phục điều này bằng cách sử dụng các tác nhân phụ ủy quyền việc thu thập thông tin cụ thể vào các tác vụ có mục tiêu, giữ lại ngữ cảnh cho công việc phân tích thực sự quan trọng. Chất lượng đầu ra của tác nhân ít phụ thuộc vào khối lượng dữ liệu hơn là vào mức độ chính xác của việc giới hạn phạm vi dữ liệu đó. Tuy nhiên, các đề xuất ban đầu của tác nhân không hiệu quả. Nhiều khuyến nghị hoặc là không đúng trọng tâm hoặc là giải quyết các triệu chứng thay vì nguyên nhân gốc rễ. Ví dụ, tác nhân đề xuất cắt bớt các cột đọc để giảm dữ liệu đầu vào, điều này là thừa vì Spark đã xử lý tối ưu hóa đó. Bản năng đầu tiên của chúng tôi là cố gắng giảm nhiễu bằng cách đưa các nhúng sâu hơn của thông tin thời gian chạy Spark và các số liệu từ Giám sát Tác vụ vào tác nhân. Ngữ cảnh bổ sung đã giúp tác nhân xác định nhiều vấn đề hơn và tạo ra nhiều khuyến nghị hơn. Nhưng số lượng dương tính giả cũng tăng lên đáng kể. Bước tiếp theo của chúng tôi là thêm một tác nhân phụ khác để lọc các vấn đề mà chúng tôi cho là không liên quan hoặc hình thức. Trình xác thực hoạt động như một người chấm điểm hơn là một người tạo ra. Nó kéo cùng ngữ cảnh với tác nhân chính, tình trạng tác vụ và kế hoạch SQL, nhưng công việc của nó là tìm ra lý do tại sao một bản sửa lỗi được đề xuất sẽ không hoạt động. Cửa sổ Terminal 1 Tối ưu hóa #2: Áp dụng bộ lọc thư rác trước phép nối chính (dòng 766) 2 3 Kiểm tra chống chỉ định: 4 1. ❌ Bộ lọc thư rác có thực sự giảm đáng kể số hàng không? — Phép nối LeftAnti xuất ra 3.406.939.340 hàng — giống như đầu vào bên trái (3.406.939.340 từ 5 Exchange). Điều này có nghĩa là 628 số liệu thư rác đóng góp gần như bằng không vào tổng số 3,4 tỷ. Bộ lọc thư rác loại bỏ các số liệu theo (org_id, metric_id) nhưng khóa nối chính 6 là (org_id, metric_name). Ngay cả khi 628 số liệu này được loại bỏ sớm hơn, phía số liệu 3,4 tỷ của phép nối chính sẽ hầu như không giảm. 7 2. ✅ Bộ lọc đã được áp dụng trước phép nối chính chưa? — Nhìn vào luồng dữ liệu: metricsWithTagsRaw → bộ lọc thư rác → metricsWithTags → salt → 8 metricsWithTagsSalted → phép nối chính tại dòng 766. Bộ lọc thư rác ĐÃ được áp dụng.