Tổng quan

Chúng tôi đã suy đoán rằng AMD Milan với các lõi Zen3 cho phép nhiều lõi hơn chia sẻ cùng một bộ đệm L3 có thể hoạt động tốt hơn cho các ứng dụng Trình tự thế hệ tiếp theo (NGS). So với AMD EPYC Rome tiền nhiệm, số lượng lõi chia sẻ bộ đệm L3 được tăng gấp đôi từ 4 lên 8 đối với kiểu bộ xử lý 64 lõi. Thêm vào đó, bộ đệm (cả L1 và L2) được nâng cấp với các trình tìm nạp trước mới và băng thông bộ nhớ được cải thiện.

Vì Milan và Rome dùng chung ổ cắm SP3, nên Dell EMC PowerEdge R6525 đã được chọn cho nghiên cứu điển hình và có thể giảm thiểu sự khác biệt giữa các hệ thống. Cấu hình máy chủ thử nghiệm được tóm tắt trong Bảng 1.

Bảng 1. Cấu hình nút điện toán đã thử nghiệm

Dữ liệu thử nghiệm được chọn từ một trong các Gen bạch kim của Illumina. ERR194161 đã được xử lý với Illumina HiSeq 2000 do Illumina gửi và có thể được lấy từ EMBL-EBI . Định danh DNA của cá nhân này là NA12878. Mô tả dữ liệu từ trang web được liên kết cho thấy rằng mẫu này có độ bao phủ >30x và đạt ~53x. 

Đánh giá hiệu suất

Mô tả các bước trong Đường ống BWA-GATK

Trong một quy trình BWA-GATK điển hình, có nhiều bước và mỗi bước bao gồm các ứng dụng khác nhau hoạt động khác biệt. Như được hiển thị trong Bảng 3, các ứng dụng trong một số bước không hỗ trợ hoạt động đa luồng. Các bước này có vấn đề vì chỉ có một số cách để cải thiện hiệu suất.

Bảng 2. Các bước trong quy trình BWA-GATK và các công cụ

Các ứng dụng luồng đơn, đặc biệt là các bước Hiệu chỉnh lại biến thể và Áp dụng hiệu chỉnh lại biến thể không hiển thị biến thể thời gian chạy do thuật toán xác định và đầu vào cho các bước này nhỏ. Do đó, hai bước này không được báo cáo trong Hình 1. Bước đầu tiên, Ánh xạ & Sắp xếp mở rộng quy mô khi số lượng lõi tăng lên (Hình 1, (a)). Ngoài ra, GVCF kiểu gen không được bao gồm trong Hình 1 mặc dù nó hỗ trợ hoạt động đa luồng vì một lý do tương tự.

Burrows-Wheeler Aligner (BWA) là một trong những bộ căn chỉnh trình tự ngắn phổ biến nhất để phân tích căn chỉnh không có khoảng cách. BWA mở rộng tốt cho đến 32 lõi và mức sử dụng CPU giảm đáng kể sau 32 lõi. Việc cải thiện thời gian chạy trở nên không đáng kể với số lõi cao hơn lớn hơn 32. Sử dụng hơn 80 lõi cho bước này là lãng phí tài nguyên.

Sambamba tương thích với Picard được sử dụng để đánh dấu các lần đọc trùng lặp. Hành vi của sambaba được vẽ trong Hình 1, (b). Do tính chất song song cao của thiết kế, mức tiêu thụ bộ nhớ tăng lên để tạo ra nhiều bảng băm hơn cho các luồng bổ sung. Thật đáng ngạc nhiên, trình tự bộ gen toàn bộ con người 50x (WGS) không đủ lớn để sử dụng hơn 13 lõi cho phần mềm được thiết kế tốt.

Sau bước Đánh dấu trùng lặp, Bộ công cụ phân tích bộ gen, tức là GATK, được viết bằng Java đóng vai trò quan trọng trong việc đo lường hiệu suất và tạo câu trả lời. Các bước này hoàn toàn không mở rộng như trong Hình 1, (c) (d) (e) và (f). Một cách tiếp cận tốt hơn sẽ được thảo luận trong công việc trong tương lai để xử lý hành vi sai trái trong môi trường đa lõi và nhiều ổ cắm.

Hiệu suất mẫu đơn

So sánh ổ cắm với ổ cắm

Thử nghiệm này không phải là một phép so sánh công bằng vì phần lớn các bước sẽ không tận dụng được lợi thế của việc sử dụng tất cả các lõi ngoại trừ 7543 với 32 lõi. Tuy nhiên, sự so sánh này sẽ giúp quyết định xem CPU nào là tốt nhất cho bài kiểm tra thông lượng.

Bảng 3 tóm tắt thời gian chạy tổng thể cho đường dẫn BWA-GATK và khó có thể nói cái nào tốt hơn về tổng thời gian chạy. Cần nhiều thử nghiệm hơn để phân biệt sự khác biệt về hiệu suất trong các bước GATK. Ngoài ra, kết quả từ 7502 và 7402 là từ các thử nghiệm trước đó với các môi trường khác nhau.

Bước lập bản đồ & Sắp xếp là bước duy nhất mà chúng tôi có thể đạt được mức cao nhất của các biến thể hiệu suất thực trên các CPU khác nhau trong Bảng 3. Ước tính sơ bộ mức cải thiện hiệu suất từ ​​7702 lên 7763 là 7% trong khi mức tăng hiệu suất là 5% từ 7702 lên 7713.

Đáng ngạc nhiên là bước Hiệu chỉnh lại Cơ sở cho kết quả tương tự như bước Lập bản đồ & Sắp xếp, tức là cải thiện 8% và 3%.

Bảng 3. So sánh hiệu suất BWA-GATK giữa Milan và Rome. Số lượng lõi được sử dụng cho thử nghiệm được đặt trong ngoặc đơn.

Hiệu suất nhiều mẫu – Thông lượng

Một cách thông thường để chạy đường dẫn NGS là xử lý nhiều mẫu trên một nút điện toán và sử dụng nhiều nút điện toán để tối đa hóa thông lượng. Tuy nhiên, lần này các thử nghiệm được thực hiện trên một nút điện toán duy nhất do số lượng máy chủ khả dụng tại thời điểm này là có hạn.

Đường ống hiện tại gọi một số lượng lớn các thao tác đường ống trong bước đầu tiên để giảm thiểu số lượng ghi tệp trung gian. Mặc dù điều này giúp tiết kiệm một ngày thời gian chạy và giảm đáng kể mức sử dụng bộ nhớ, nhưng chi phí gọi đường ống khá nặng. Do đó, điều này giới hạn số lượng xử lý mẫu đồng thời. Thông thường, một quá trình âm thầm thất bại khi không còn đủ tài nguyên để bắt đầu một quá trình bổ sung.

Tuy nhiên, những thất bại gặp phải trong nghiên cứu này khá khác so với những quan sát trước đó. 10 đường ống bắt đầu trong R6525 với 2x 7763 chỉ duy trì trung bình 6 đường ống với 50x WGS của con người. Bốn đường ống không thành công với lỗi đường ống bị hỏng cho thấy một số loại hoạt động của tệp. Bộ lưu trữ BeeGFS hiện tại dành cho thử nghiệm được thiết kế để có dung lượng cao, băng thông ghi tuần tự theo lý thuyết là 25 GB/giây. Tuy nhiên, bạn có thể đạt được khoảng 16 GB/giây khi không có mức sử dụng nhiều được tải trên bộ nhớ này trong môi trường bộ nhớ dùng chung. Đây không phải là một môi trường lý tưởng cho bất kỳ thực hành điểm chuẩn nào; tuy nhiên, các kết quả ở đây khá hữu ích để xem hiệu suất của các hệ thống này trông như thế nào trong cuộc sống thực.

Như được hiển thị trong Bảng 4, số lượng mẫu tối đa có thể được xử lý cùng lúc là khoảng 4 hoặc 5 và thông lượng toàn bộ bộ gen của con người mỗi ngày là ~4,79 50x mỗi ngày có thể đạt được với môi trường hiện tại.

Bảng 4. Kiểm tra thông lượng cho Milan 7763

Phần kết luận

Lĩnh vực phân tích dữ liệu NGS đã và đang phát triển nhanh chóng về tốc độ tăng trưởng dữ liệu và các biến thể dữ liệu. Tuy nhiên, cộng đồng đã không làm được nhiều việc để thích nghi với các công nghệ mới có sẵn như máy gia tốc. Thay vì cải thiện chất lượng code, cộng đồng phải đối mặt với việc phân tích dữ liệu mà không xử lý đa luồng vì GATK phiên bản 4 trở lên không hỗ trợ đa luồng nữa trong khi số lượng lõi trong CPU tăng nhanh.

Đã đến lúc người dùng cần suy nghĩ về cách giải quyết vấn đề này. Một cách đơn giản để tránh vấn đề này là thực hiện song song hóa mức dữ liệu. Mặc dù việc đưa ra quyết định về thời điểm phân tách dữ liệu là khá khó khăn, nhưng chắc chắn có thể thực hiện được với các biện pháp can thiệp cẩn thận trong quy trình BWA-GATK hiện có mà không làm giảm sức mạnh thống kê với số lượng dữ liệu tuyệt đối. Nếu mỗi đoạn dữ liệu nhỏ hơn đi qua một đường ống riêng lẻ trên mỗi lõi và được hợp nhất ở cuối, thì có thể đạt được hiệu suất tốt hơn trên một mẫu đơn lẻ. Mức tăng hiệu suất này có thể dẫn đến thông lượng cao hơn nếu thời gian chạy tổng thể giảm đáng kể.

Tuy nhiên, Milan 7763 hoặc 7713 là một ứng cử viên xuất sắc để bao gồm cả các đường ống dựa trên đa luồng hiện tại và các đường ống dẫn hướng song song ở mức dữ liệu trong tương lai với nhiều lõi khả dụng hơn.