Ngừng chờ Spark: Kích hoạt chế độ đồng thời cao trong Fabric Notebooks

Khi mở rộng quy mô phân tích dữ liệu doanh nghiệp, chúng tôi không ngừng tìm kiếm các phương pháp tối ưu hóa quy trình kỹ thuật dữ liệu. Chúng tôi xây dựng các đường ống dữ liệu tinh gọn, tỉ mỉ thiết kế logic chuyển đổi và điều phối các quy trình phức tạp. Tuy nhiên, bất chấp những nỗ lực tối ưu hóa mã lệnh, chúng tôi thường xuyên gặp phải một nút thắt cổ chai âm thầm làm tiêu tốn thời gian và ngân sách tính toán: độ trễ khởi tạo cụm. Chúng tôi vui mừng chia sẻ một phương pháp tiếp cận mang tính chuyển đổi đối với thách thức này. Trong bài phân tích chi tiết này, chúng tôi sẽ đi sâu vào chế độ High Concurrency (Đồng thời cao) trong Microsoft Fabric Notebooks, một tính năng cơ bản định nghĩa lại cách chúng tôi quản lý tính toán Spark. Bằng cách chuyển sang mô hình thực thi được tối ưu hóa này, chúng tôi sẽ giảm độ trễ của đường ống từ vài phút xuống chỉ còn vài giây, đồng thời tối đa hóa các khoản đầu tư vào Đơn vị Dung lượng (Capacity Unit - CU). **Vấn đề khởi động nguội Spark và độ trễ đường ống** Để đánh giá tác động sâu sắc của chế độ High Concurrency, trước tiên chúng ta phải xem xét thực tế cơ học của việc thực thi Spark tiêu chuẩn. Khi chúng tôi điều phối một nền tảng dữ liệu cấp doanh nghiệp, chúng tôi thường chia logic thành các sổ ghi chép (notebook) mô-đun, chuyên biệt theo từng miền. Chúng tôi có thể có một sổ ghi chép làm sạch dữ liệu bán hàng, một sổ ghi chép khác tổng hợp các chỉ số tiếp thị và một sổ ghi chép thứ ba tính toán dự báo tài chính. Mặc dù tính mô-đun này rất tốt cho việc duy trì mã lệnh, nhưng nó gây ra ma sát nghiêm trọng khi được điều phối trong một đường ống truyền thống. Khi chúng tôi khởi tạo một sổ ghi chép PySpark cho tác vụ tải dữ liệu hoặc học máy, chúng tôi phải chịu sự chậm trễ khởi tạo phiên, thường được gọi là khởi động nguội (cold starts). Có một độ trễ cố hữu trong việc cấp phát các vùng chứa (containers), tải các thư viện mở rộng và thiết lập môi trường phân tán. Trong cấu hình tiêu chuẩn, việc thực thi ba sổ ghi chép riêng biệt song song buộc công cụ cơ bản phải yêu cầu, cấp phát và khởi động ba cụm Spark riêng biệt. Quá trình cấp phát phần cứng này tốn thời gian. Không có gì lạ khi một lần khởi động nguội có thể thêm hai đến ba phút chi phí phụ trội thuần túy vào mỗi lần chạy đường ống. Nếu chúng ta đang chạy một kiến trúc vi lô (micro-batch) kích hoạt cứ sau mười lăm phút, việc dành ba phút chờ cấp phát cơ sở hạ tầng cho mỗi lần thực thi là không bền vững về mặt toán học. Trong suốt một ngày, chúng ta mất hàng giờ chờ đợi không hoạt động. Hơn nữa, chúng ta không chỉ mất thời gian; chúng ta đang tích cực đốt cháy ngân sách tính toán đã cấp phát chỉ để khởi động máy chủ. Rõ ràng chúng ta cần một sự thay đổi mô hình để loại bỏ chi phí phụ trội dư thừa này, và chế độ High Concurrency cung cấp chính xác giải pháp đó. **Cách thức hoạt động của High Concurrency: Cách ly phiên so với Chia sẻ cụm** Để giải quyết vấn đề độ trễ, chúng ta phải thay đổi cách các sổ ghi chép của chúng ta tương tác với nhóm tính toán cơ bản. Trong lịch sử, mối quan hệ giữa một sổ ghi chép và một cụm Spark là một-một một cách nghiêm ngặt. Chế độ High Concurrency phá vỡ sự kết nối cứng nhắc này, giới thiệu một kiến trúc một-nhiều hiệu quả cao. Khi chúng ta bật High Concurrency, chúng ta hướng dẫn Microsoft Fabric duy trì một phiên Spark duy nhất, mạnh mẽ và đang hoạt động. Khi đường ống điều phối của chúng ta kích hoạt các sổ ghi chép tiếp theo, chúng không còn yêu cầu phần cứng mới. Thay vào đó, chúng tự động gắn vào phiên Spark đã chạy. Bởi vì các vùng chứa đã được cấp phát, các thư viện đã được tải và các JVM đã sẵn sàng, độ trễ thực thi giảm từ vài phút xuống chỉ còn một phần nhỏ của giây. Sự xuất sắc của kiến trúc này nằm ở cách nó cân bằng giữa việc chia sẻ và an toàn. Chúng ta đang chia sẻ tài nguyên tính toán nặng nề cơ bản. cơ sở hạ tầng (các nút, vùng nhớ chung và lõi CPU), nhưng chúng tôi đang cô lập các ngữ cảnh thực thi. Hệ thống thực hiện ghép kênh một cách thông minh các lệnh sổ ghi chép đến, cho phép nhiều luồng mã xử lý đồng thời trên cùng một phần cứng mà không gây xung đột. Chúng tôi đạt được khả năng xử lý song song của một triển khai đa cụm quy mô lớn trong khi chỉ phải chi trả cho dấu chân của một cụm đơn lẻ, được tối ưu hóa cao. Kích hoạt tính năng: Cài đặt không gian làm việc và hộp kiểm hoạt động đường ống Việc triển khai chế độ Đồng thời cao yêu cầu một quy trình cấu hình hai bước có chủ đích. Chúng ta phải thiết lập khả năng này ở cấp độ không gian làm việc trước, sau đó phải gọi nó một cách rõ ràng trong các đường ống điều phối của chúng ta. Đầu tiên, chúng ta điều hướng đến cài đặt Microsoft Fabric Workspace của mình. Trong phần Kỹ thuật Dữ liệu (Data Engineering), chúng ta tìm cấu hình Spark Compute. Tại đây, chúng ta phải định nghĩa một nhóm Spark tùy chỉnh và bật rõ ràng khả năng Đồng thời cao (High Concurrency) cho nhóm đó. Chúng ta cần hết sức cẩn trọng trong giai đoạn này để định cỡ các nút một cách phù hợp, đảm bảo cụm dùng chung có đủ bộ nhớ và dung lượng lõi để xử lý tổng khối lượng công việc của nhiều sổ ghi chép chạy đồng thời. Chúng ta cũng cấu hình cài đặt thời gian chờ một cách chu đáo, cho phép cụm dùng chung tự động tắt một cách nhẹ nhàng khi tất cả các hoạt động đồng thời đã hoàn thành thành công. Sau khi không gian làm việc được chuẩn bị, chúng ta chuyển sang các đường ống điều phối Data Factory của mình. Khi chúng ta kéo một Hoạt động Sổ ghi chép (Notebook Activity) vào khung vẽ đường ống, chúng ta điều hướng đến bảng cài đặt cho hoạt động cụ thể đó. Chúng ta sẽ ngay lập tức nhận thấy một hộp kiểm chuyên dụng có nhãn “High Concurrency” (Đồng thời cao). Chúng ta phải chủ động chọn hộp này cho mọi hoạt động sổ ghi chép mà chúng ta muốn định tuyến vào nhóm phiên dùng chung. Nếu chúng ta để trống, đường ống sẽ trở về hành vi mặc định của nó, khởi tạo một cụm riêng biệt, tốn kém cho tác vụ cụ thể đó. Bằng cách bật tính năng này một cách có phương pháp trên toàn bộ kiến trúc đường ống của chúng ta, chúng ta buộc các khối lượng công việc của mình chia sẻ các tài nguyên tính toán đã được khởi động. Bảo mật & Cô lập biến: Ngăn chặn rò rỉ dữ liệu giữa các phiên dùng chung Khi chúng ta lần đầu giới thiệu khái niệm chia sẻ cụm cho các nhóm kỹ thuật dữ liệu của mình, một câu hỏi hợp lệ và quan trọng ngay lập tức nảy sinh: “Nếu sổ ghi chép Chuyển đổi Bán hàng (Sales Transformation) và sổ ghi chép Chuyển đổi Tài chính (Finance Transformation) của tôi đang chạy trên cùng một cụm Spark vào cùng một thời điểm, các biến của tôi có bị xung đột không? Chúng ta có gặp phải tình trạng lây nhiễm chéo dữ liệu không?” Chúng ta