Đây là phần giới thiệu chuyên sâu về khả năng cô lập khối lượng công việc của . Nhưng trước hết, tại sao và khi nào bạn cần tách biệt khối lượng công việc? Nếu bạn liên quan đến bất kỳ tình huống nào sau đây, hãy đọc tiếp và bạn sẽ tìm ra giải pháp: Apache Doris Bạn có các bộ phận kinh doanh hoặc đối tượng thuê khác nhau chia sẻ cùng một cụm và bạn muốn ngăn chặn sự can thiệp của khối lượng công việc. Bạn có các nhiệm vụ truy vấn ở nhiều mức độ ưu tiên khác nhau và bạn muốn ưu tiên cho các nhiệm vụ quan trọng của mình (chẳng hạn như phân tích dữ liệu theo thời gian thực và giao dịch trực tuyến) về mặt tài nguyên và khả năng thực thi. Bạn cần tách biệt khối lượng công việc nhưng cũng muốn có hiệu quả chi phí và tỷ lệ sử dụng tài nguyên cao. Apache Doris hỗ trợ cách ly khối lượng công việc dựa trên Thẻ tài nguyên và Nhóm khối lượng công việc. Thẻ tài nguyên tách biệt tài nguyên CPU và bộ nhớ cho các khối lượng công việc khác nhau ở cấp nút phụ trợ, trong khi cơ chế Nhóm khối lượng công việc có thể phân chia thêm các tài nguyên trong nút phụ trợ để sử dụng tài nguyên cao hơn. https://www.youtube.com/watch?v=Wd3l5C4k8Ok&embedable=true Cách ly tài nguyên dựa trên Thẻ tài nguyên Hãy bắt đầu với kiến trúc của Apache Doris. Doris có hai : giao diện người dùng (FE) và phụ trợ (BE). Các nút FE lưu trữ siêu dữ liệu, quản lý cụm, xử lý yêu cầu của người dùng và phân tích kế hoạch truy vấn, trong khi các nút BE chịu trách nhiệm tính toán và lưu trữ dữ liệu. Do đó, các nút BE là người tiêu dùng tài nguyên chính. loại nút Ý tưởng chính của giải pháp cách ly dựa trên Thẻ tài nguyên là chia tài nguyên máy tính thành các nhóm bằng cách gán thẻ cho các nút BE trong một cụm, trong đó các nút BE của cùng một thẻ tạo thành Nhóm tài nguyên. Nhóm tài nguyên có thể được coi là một đơn vị lưu trữ và tính toán dữ liệu. Đối với dữ liệu được đưa vào Doris, hệ thống sẽ ghi các bản sao dữ liệu vào các Nhóm tài nguyên khác nhau tùy theo cấu hình. Các truy vấn cũng sẽ được chỉ định cho tương ứng để thực thi. Nhóm tài nguyên Ví dụ: nếu bạn muốn tách khối lượng công việc đọc và ghi trong cụm 3-BE, bạn có thể làm theo các bước sau: : Liên kết 2 BE với thẻ "Đọc" và 1 BE với thẻ "Ghi". Gán Thẻ tài nguyên cho các nút BE : Giả sử rằng Bảng 1 có 3 bản sao, hãy liên kết 2 trong số chúng với thẻ "Đọc" và 1 với thẻ "Ghi". Dữ liệu ghi vào Replica 3 sẽ được đồng bộ với Replica 1 và Replica 2, đồng thời quá trình đồng bộ dữ liệu tiêu tốn ít tài nguyên BE 1 và BE2. Gán Thẻ tài nguyên cho bản sao dữ liệu : Các truy vấn bao gồm thẻ "Đọc" trong SQL của chúng sẽ được tự động định tuyến đến các nút được gắn thẻ "Đọc" (trong trường hợp này là BE 1 và BE 2). Đối với các tác vụ ghi dữ liệu, bạn cũng cần gán cho chúng thẻ "Write" để chúng có thể được định tuyến đến nút tương ứng (BE 3). Bằng cách này, sẽ không có sự tranh chấp tài nguyên giữa khối lượng công việc đọc và ghi ngoại trừ chi phí đồng bộ hóa dữ liệu từ bản sao 3 đến bản sao 1 và 2. Chỉ định các nhóm khối lượng công việc cho Thẻ tài nguyên Thẻ tài nguyên cũng cho phép trong Apache Doris. Ví dụ: tài nguyên máy tính và lưu trữ được gắn thẻ "Người dùng A" chỉ dành cho Người dùng A, trong khi những tài nguyên được gắn thẻ "Người dùng B" là dành riêng cho Người dùng B. Đây là cách Doris thực hiện cách ly tài nguyên nhiều người thuê với Thẻ tài nguyên ở phía BE . nhiều người thuê Việc chia các nút BE thành các nhóm đảm bảo : mức độ cô lập cao CPU, bộ nhớ và I/O của các đối tượng thuê khác nhau được cách ly về mặt vật lý. Một đối tượng thuê sẽ không bao giờ bị ảnh hưởng bởi lỗi (chẳng hạn như sự cố quy trình) của đối tượng thuê khác. Nhưng nó có một số nhược điểm: Trong phân tách đọc-ghi, khi quá trình ghi dữ liệu dừng lại, các nút BE được gắn thẻ "Ghi" sẽ không hoạt động. Điều này làm giảm việc sử dụng cụm tổng thể. Trong chế độ nhiều đối tượng thuê, nếu bạn muốn tách biệt hơn nữa các khối lượng công việc khác nhau của cùng một đối tượng thuê bằng cách chỉ định các nút BE riêng biệt cho từng đối tượng thuê, bạn sẽ phải chịu chi phí đáng kể và mức sử dụng tài nguyên thấp. Số lượng người thuê được gắn với số lượng bản sao dữ liệu. Vì vậy, nếu bạn có 5 người thuê, bạn sẽ cần 5 bản sao dữ liệu. Đó là sự dư thừa lưu trữ rất lớn. . Để cải thiện vấn đề này, chúng tôi cung cấp giải pháp cách ly khối lượng công việc dựa trên Nhóm khối lượng công việc trong Apache Doris 2.0.0 và cải tiến giải pháp này trong Apache Doris 2.1.0 Cách ly khối lượng công việc dựa trên Nhóm khối lượng công việc Giải pháp dựa trên thực hiện việc phân chia tài nguyên chi tiết hơn. Nó tiếp tục phân chia tài nguyên CPU và bộ nhớ trong các tiến trình trên nút BE, nghĩa là các truy vấn trong một nút BE có thể tách biệt với nhau ở một mức độ nào đó. Điều này tránh sự cạnh tranh tài nguyên trong các quy trình BE và tối ưu hóa việc sử dụng tài nguyên. Workload Group Người dùng có thể liên kết các truy vấn với Nhóm khối lượng công việc, do đó hạn chế tỷ lệ phần trăm tài nguyên CPU và bộ nhớ mà truy vấn có thể sử dụng. Dưới tải cụm cao, Doris có thể tự động loại bỏ các truy vấn tiêu tốn nhiều tài nguyên nhất trong Nhóm khối lượng công việc. Trong điều kiện tải cụm thấp, Doris có thể cho phép nhiều Nhóm khối lượng công việc chia sẻ tài nguyên nhàn rỗi. Doris hỗ trợ cả giới hạn mềm CPU và giới hạn cứng CPU. Giới hạn mềm cho phép Nhóm khối lượng công việc phá vỡ giới hạn và tận dụng các tài nguyên nhàn rỗi, cho phép sử dụng hiệu quả hơn. Giới hạn cứng là sự đảm bảo cứng rắn cho hiệu suất ổn định vì nó ngăn chặn tác động lẫn nhau của Nhóm khối lượng công việc. (Giới hạn mềm của CPU và giới hạn cứng của CPU trái ngược nhau. Bạn có thể chọn giữa chúng tùy theo trường hợp sử dụng của riêng bạn.) Sự khác biệt của nó so với giải pháp dựa trên Thẻ tài nguyên bao gồm: Nhóm khối lượng công việc được hình thành trong các quy trình. Nhiều Nhóm khối lượng công việc cạnh tranh để giành tài nguyên trong cùng một nút BE. Việc xem xét phân phối bản sao dữ liệu là không cần thiết vì Nhóm khối lượng công việc chỉ là một cách quản lý tài nguyên. Giới hạn mềm CPU Giới hạn mềm CPU được triển khai bởi tham số , về mặt khái niệm tương tự như trọng số. Nhóm khối lượng công việc có cao hơn sẽ được phân bổ nhiều thời gian CPU hơn trong một khoảng thời gian. cpu_share cpu_share Ví dụ: nếu Nhóm A được định cấu hình với là 1 và Nhóm B là 9. Trong khoảng thời gian 10 giây, khi cả Nhóm A và Nhóm B đều được tải đầy đủ, Nhóm A và Nhóm B sẽ có thể tiêu thụ 1 giây và thời gian CPU tương ứng là 9 giây. cpu_share Điều xảy ra trong các trường hợp thực tế là không phải tất cả khối lượng công việc trong cụm đều chạy hết công suất. Theo giới hạn mềm, nếu Nhóm B có khối lượng công việc thấp hoặc bằng 0 thì Nhóm A sẽ có thể sử dụng tất cả 10 giây thời gian của CPU, do đó làm tăng mức sử dụng CPU tổng thể trong cụm. Giới hạn mềm mang lại sự linh hoạt và tỷ lệ sử dụng tài nguyên cao hơn. Mặt khác, nó có thể gây ra biến động về hiệu suất. Giới hạn cứng CPU Giới hạn cứng CPU trong Apache Doris 2.1.0 được thiết kế dành cho người dùng yêu cầu hiệu năng ổn định. Nói một cách đơn giản, giới hạn cứng của CPU xác định rằng Nhóm khối lượng công việc không thể sử dụng nhiều tài nguyên CPU hơn giới hạn của nó cho dù có tài nguyên CPU nhàn rỗi hay không. Đây là cách nó hoạt động: Giả sử rằng Nhóm A được đặt với và Nhóm B với . Nếu cả Nhóm A và Nhóm B đều chạy ở mức đầy tải thì Nhóm A và Nhóm B sẽ lần lượt sử dụng 10% và 90% tổng thời gian của CPU. Sự khác biệt nằm ở chỗ khối lượng công việc của nhóm B giảm đi. Trong những trường hợp như vậy, bất kể tải truy vấn của Nhóm A có cao đến đâu, nó cũng không nên sử dụng quá 10% tài nguyên CPU được phân bổ cho nó. cpu_hard_limit=10% cpu_hard_limit=90% Ngược lại với giới hạn mềm, giới hạn cứng đảm bảo hiệu suất hệ thống ổn định nhưng phải trả giá bằng tính linh hoạt và khả năng sử dụng tài nguyên cao hơn. Giới hạn tài nguyên bộ nhớ Bộ nhớ của nút BE bao gồm các phần sau: Bộ nhớ dành riêng cho hệ điều hành. Bộ nhớ bị tiêu tốn bởi các truy vấn không phải là truy vấn, không được xem xét trong thống kê bộ nhớ của Nhóm khối lượng công việc. Bộ nhớ được sử dụng cho các truy vấn, bao gồm cả việc ghi dữ liệu. Điều này có thể được theo dõi và kiểm soát bởi Workload Group. Tham số xác định bộ nhớ (%) tối đa có sẵn cho Nhóm khối lượng công việc trong quy trình BE. Nó cũng ảnh hưởng đến mức độ ưu tiên của Nhóm tài nguyên. memory_limit Ở trạng thái ban đầu, Nhóm tài nguyên có mức ưu tiên cao sẽ được cấp nhiều bộ nhớ hơn. Bằng cách đặt , bạn có thể cho phép Nhóm tài nguyên chiếm nhiều bộ nhớ hơn giới hạn khi còn chỗ trống. Khi bộ nhớ chật hẹp, Doris sẽ hủy các tác vụ để lấy lại tài nguyên bộ nhớ mà chúng đã cam kết. Trong trường hợp này, hệ thống sẽ giữ lại càng nhiều tài nguyên bộ nhớ cho các nhóm tài nguyên có mức độ ưu tiên cao càng tốt. enable_memory_overcommit Hàng đợi truy vấn Điều này xảy ra là cụm đang đảm nhận nhiều tải hơn khả năng xử lý của nó. Trong trường hợp này, việc gửi yêu cầu truy vấn mới sẽ không những không có kết quả mà còn làm gián đoạn các truy vấn đang diễn ra. Để cải thiện điều này, Apache Doris cung cấp cơ chế . Người dùng có thể đặt giới hạn về số lượng truy vấn có thể chạy đồng thời trong cụm. Một truy vấn sẽ bị từ chối khi hàng đợi truy vấn đầy hoặc sau khi hết thời gian chờ, do đó đảm bảo tính ổn định của hệ thống khi tải cao. xếp hàng truy vấn Cơ chế xếp hàng truy vấn bao gồm ba tham số: , và . max_concurrency max_queue_size queue_timeout Kiểm tra Để chứng minh tính hiệu quả của giới hạn mềm và giới hạn cứng của CPU, chúng tôi đã thực hiện một số thử nghiệm. Môi trường: máy đơn, 16 lõi, 64GB Triển khai: 1 FE + 1 BE Bộ dữ liệu: ClickBench, TPC-H Công cụ kiểm tra tải: Apache JMeter Kiểm tra giới hạn mềm CPU Bắt đầu hai ứng dụng khách và liên tục gửi truy vấn (ClickBench Q23) có và không sử dụng Nhóm khối lượng công việc tương ứng. Lưu ý nên tắt Page Cache để tránh ảnh hưởng đến kết quả kiểm tra. So sánh thông lượng của hai khách hàng trong cả hai thử nghiệm, có thể kết luận rằng: , hai máy khách sẽ tiêu thụ tài nguyên CPU trên cơ sở như nhau. Nếu không định cấu hình Nhóm khối lượng công việc và đặt thành 2:1, tỷ lệ thông lượng của hai máy khách là 2:1. Với cao hơn, Máy khách 1 được cung cấp phần tài nguyên CPU cao hơn và mang lại thông lượng cao hơn. Định cấu hình Nhóm khối lượng công việc cpu_share cpu_share Kiểm tra giới hạn cứng của CPU Khởi động một ứng dụng khách, đặt cho Nhóm khối lượng công việc và thực thi ClickBench Q23 trong 5 phút ở mức đồng thời lần lượt là 1, 2 và 4. cpu_hard_limit=50% Khi truy vấn đồng thời tăng lên, tỷ lệ sử dụng CPU vẫn ở mức khoảng 800%, nghĩa là 8 lõi được sử dụng. Trên máy 16 lõi, , đúng như mong đợi. Ngoài ra, do giới hạn cứng của CPU được áp đặt nên độ trễ TP99 tăng lên khi tốc độ xử lý đồng thời tăng lên cũng là một kết quả được mong đợi. mức sử dụng đó là 50% Thử nghiệm trong môi trường sản xuất mô phỏng Trong quá trình sử dụng trong thế giới thực, người dùng đặc biệt quan tâm đến độ trễ truy vấn thay vì chỉ thông lượng truy vấn vì độ trễ dễ được nhận biết hơn trong trải nghiệm người dùng. Đó là lý do tại sao chúng tôi quyết định xác nhận tính hiệu quả của Workload Group trong môi trường sản xuất mô phỏng. Chúng tôi đã chọn một bộ SQL bao gồm các truy vấn cần hoàn thành trong vòng 1 giây (ClickBench Q15, Q17, Q23 và TPC-H Q3, Q7, Q19), bao gồm các truy vấn tổng hợp một bảng và truy vấn nối. Kích thước của tập dữ liệu TPC-H là 100GB. Tương tự, chúng tôi tiến hành kiểm tra có và không có cấu hình Nhóm khối lượng công việc. Như kết quả cho thấy: (so sánh Kiểm tra 1 và 2): Khi quay số đồng thời của Máy khách 2, cả hai máy khách đều gặp phải độ trễ truy vấn tăng 2~3 lần. Không có Nhóm khối lượng công việc (so sánh Thử nghiệm 3 và 4): Khi tính đồng thời của Máy khách 2 tăng lên, biến động hiệu suất trong Máy khách 1 nhỏ hơn nhiều, đây là bằng chứng cho thấy nó được bảo vệ hiệu quả bằng cách cô lập khối lượng công việc. Định cấu hình Nhóm khối lượng công việc Khuyến nghị & kế hoạch Giải pháp dựa trên Thẻ tài nguyên là một kế hoạch cách ly khối lượng công việc kỹ lưỡng. Giải pháp dựa trên Nhóm khối lượng công việc mang lại sự cân bằng tốt hơn giữa việc cách ly và sử dụng tài nguyên, đồng thời được bổ sung bằng cơ chế xếp hàng truy vấn để đảm bảo tính ổn định. Vậy bạn nên chọn cái nào cho trường hợp sử dụng của mình? Đây là khuyến nghị của chúng tôi: : dành cho các trường hợp sử dụng trong đó các ngành nghề kinh doanh khác nhau của các bộ phận chia sẻ cùng một cụm, do đó tài nguyên và dữ liệu được cách ly về mặt vật lý đối với những đối tượng thuê khác nhau. Thẻ tài nguyên : dành cho các trường hợp sử dụng trong đó một cụm đảm nhận nhiều khối lượng công việc truy vấn khác nhau để phân bổ tài nguyên linh hoạt. Nhóm khối lượng công việc Trong các bản phát hành trong tương lai, chúng tôi sẽ tiếp tục cải thiện trải nghiệm người dùng của Nhóm khối lượng công việc và các tính năng hàng đợi truy vấn: Giải phóng không gian bộ nhớ bằng cách hủy truy vấn là một phương pháp tàn bạo. Chúng tôi dự định triển khai điều đó bằng cách tràn ổ đĩa, điều này sẽ mang lại sự ổn định cao hơn cho hiệu suất truy vấn. Do bộ nhớ được sử dụng bởi các truy vấn không phải trong BE không được bao gồm trong thống kê bộ nhớ của Nhóm khối lượng công việc, nên người dùng có thể quan sát thấy sự chênh lệch giữa mức sử dụng bộ nhớ của quy trình BE và mức sử dụng bộ nhớ của Nhóm khối lượng công việc. Chúng tôi sẽ giải quyết vấn đề này để tránh nhầm lẫn. Trong cơ chế hàng đợi truy vấn, tải cụm được kiểm soát bằng cách đặt đồng thời truy vấn tối đa. Chúng tôi dự định kích hoạt tính năng đồng thời truy vấn tối đa động dựa trên tính sẵn có của tài nguyên tại BE. Điều này tạo ra áp lực ngược về phía khách hàng và do đó cải thiện tính khả dụng của Doris khi khách hàng tiếp tục gửi tải cao. Ý tưởng chính của Thẻ tài nguyên là nhóm các nút BE, trong khi ý tưởng của Nhóm khối lượng công việc là phân chia thêm tài nguyên của một nút BE. Để nắm bắt được những ý tưởng này, trước tiên người dùng cần tìm hiểu về khái niệm nút BE trong Doris. Tuy nhiên, từ góc độ vận hành, người dùng chỉ cần hiểu tỷ lệ phần trăm tiêu thụ tài nguyên trong từng khối lượng công việc của họ và mức độ ưu tiên họ nên có khi tải cụm bão hòa. Vì vậy, chúng tôi sẽ cố gắng tìm ra cách làm phẳng quá trình học tập cho người dùng, chẳng hạn như giữ khái niệm về nút BE trong hộp đen. Để được hỗ trợ thêm về cách ly khối lượng công việc trong Apache Doris, hãy tham gia . cộng đồng Apache Doris
