ROOT: phân tích dữ liệu petabyte theo cách khoa học

 (root.cern)
1 điểm bởi GN⁺ 2024-06-02 | 1 bình luận | Chia sẻ qua WhatsApp
  • Hỗ trợ xử lý dữ liệu quy mô lớn và phân tích khoa học cần thiết trong các nghiên cứu quy mô lớn như vật lý năng lượng cao; hiện các tệp ROOT đang lưu trữ hơn 2 exabyte dữ liệu
  • ROOT cũng được dùng trong phát hiện Higgs, là một công cụ có trường hợp ứng dụng thực tế đã được kiểm chứng trong phân tích dữ liệu thực nghiệm
  • Là mã nguồn mở nên có thể tự do sử dụng và chỉnh sửa, đồng thời tiếp nhận đóng góp từ người dùng thông qua quy trình phát triển công khai
  • Trình thông dịch C++ đi kèm phù hợp cho tạo mẫu nhanh, và có thể truy cập mọi thành phần thông qua binding động cho Python
  • Cũng hỗ trợ Jupyter Notebook, mở rộng phân tích dựa trên C++·Python sang môi trường notebook; các tin tức về bản phát hành, đào tạo và hackathon cũng liên tục được công bố

Vai trò của ROOT trong phân tích dữ liệu

  • ROOT là công cụ cho phép xử lý và phân tích khoa học đối với dữ liệu quy mô lớn

Phát triển mã nguồn mở và đóng góp

Cách sử dụng dựa trên C++·Python·notebook

Blog và tin tức phát hành

  • Các bài blog gần đây gồm lời mời công chiếu phim tài liệu C++ trên YouTube, trailer phim tài liệu về ROOT và C++, ROOT Advanced Course 2026, và bài viết liên quan đến 3rd ROOT Hackathon
  • Danh sách bản phát hành mới nhất bao gồm các phiên bản sau

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-06-02
Các ý kiến trên Hacker News

  • Gợi lại nhiều ký ức cũ. Khi làm trong lĩnh vực vật lý hạt, tôi dùng ROOT rất nhiều và có quan hệ vừa yêu vừa ghét với nó.
    Một mặt nó có rất nhiều nợ kỹ thuật và quán tính kỳ lạ, nhưng mặt khác có khá nhiều việc trong ROOT lại dễ hơn so với các lựa chọn “hiện đại” hơn như matplotlib. Ví dụ như histogram, dữ liệu có cấu trúc cao khi đưa các đối tượng có field vào “cột”, hay vẽ trực tiếp một hàm mà không cần cấp phát riêng mảng x/y.
    Tôi cũng thích API hướng đối tượng trực quan của nó. Nó gần với C++ hoặc Java kiểu cũ hơn là method chaining của pandas/matplotlib, việc lạm dụng cú pháp [], và đủ thứ hành vi như ma thuật. Không thanh nhã và khá dài dòng, nhưng trong phân tích khoa học thì đó lại có thể là ưu điểm.
    Khi tôi rời đi khoảng 5 năm trước, ROOT đang thay đổi: đã loại bỏ trình thông dịch CINT cũ và chuyển sang codebase dựa trên clang. Theo tôi biết hiện nay có thể chạy phân tích trong Jupyter bằng C++ hoặc Python, và nghe nói chất lượng mã cũng đã tốt hơn nhiều.

    • Điểm hay nhất của ROOT là cách nạp dữ liệu. TTree, đọc cắt theo cột từ đĩa, thực sự là một ý tưởng rất tốt; sau khi tốt nghiệp và chuyển sang ngành công nghiệp, tôi vẫn luôn tìm thứ hoạt động theo cùng cách đó.
    • Có lẽ vì matplotlib không lấy histogram làm trung tâm, hoặc vì ngày nay RAM đã đủ nhiều, mà tôi thường thấy những biểu đồ phân tán vô dụng với quá nhiều điểm chồng lên nhau. Nhìn rất khổ sở.
    • Ai cũng có quan hệ vừa yêu vừa ghét với ROOT. Hơi giống hội chứng Stockholm.
    • Tôi tự hỏi Haskell có phù hợp để làm những thứ như thế này không.
    • Ngày nay nhờ ChatGPT, API kinh khủng của matplotlib không còn là vấn đề lớn như trước nữa.

  • Không có nhiều lý do để một phân tích mới phải mặc định dùng ROOT. Tốt hơn nên dùng thứ thân thiện với người dùng và tỉnh táo hơn, như uproot.
    Có thể có workflow legacy, hoặc từng thí nghiệm đã chồng rất nhiều bản vá tùy chỉnh lên ROOT, nhưng nếu chỉ xét phân tích vật lý thì đó có thể là lựa chọn tự hành hạ bản thân.
    Tôi cũng thích trang 404 của họ. Và không phải đang nói về phòng 404.
    https://github.com/scikit-hep/uproot5
    https://root.cern/404/

    • Một phê bình phổ biến về uproot là nó không linh hoạt khi các phép tính theo từng hàng trở nên phức tạp. Lý do là vòng lặp for của Python quá chậm.
      Khi đó có thể dùng Numba, hoặc nếu mọi thứ hoạt động tốt; còn không, cho phép tôi tự quảng bá một chút: có thể dùng Julia: https://github.com/JuliaHEP/UnROOT.jl
      Thảo luận HN trước đây về việc dùng Julia trong vật lý hạt: https://news.ycombinator.com/item?id=38512793

  • Thật thú vị khi thấy các dự án phần mềm quy mô lớn được dùng cho khám phá khoa học.
    Một ví dụ khác: LIGO đã dùng GStreamer để tìm sóng hấp dẫn: https://lscsoft.docs.ligo.org/gstlal/

    • Ở đây thì gần như ngược lại. CERN cần một framework phân tích dữ liệu, nên CERN đã phát triển, duy trì và công khai nó.
      Nhưng tôi không chắc người ngoài thực sự dùng nó có phải là ý hay không. Kinh nghiệm của tôi có thể đã hơi cũ, nhưng nó khá thô và lỗi thời. Ưu điểm lớn trong công việc tại CERN hoặc vật lý hạt là nó gần như là chuẩn, nên hợp tác nội bộ dễ hơn.
    • Hai ví dụ này khá khác nhau. ROOT là một framework phân tích dữ liệu mạnh, nhưng dù mạnh như vậy, nó không được làm đủ tổng quát và dễ dùng để lan ra ngoài vật lý năng lượng cao.
      Ngược lại, GStreamer là một nền tảng được thiết kế đẹp; nhờ kiến trúc tốt, nó có thể được trừu tượng hóa và tái sử dụng dễ dàng trong những kịch bản hoàn toàn khác mà những người tạo ra ban đầu có lẽ cũng không tưởng tượng tới.
    • Điểm không thú vị là ROOT được “thiết kế” và xây dựng bởi những người hoàn toàn không biết cách vận hành một dự án phần mềm quy mô lớn.
      Dấu vết của điều đó hiện diện khắp nơi. Nó là một khối nguyên khối khổng lồ, nên chỉ cần muốn làm điều gì hơi khác thường là phải liên tục vật lộn với nó. May là tôi không phải dùng thường xuyên, nhưng vẫn còn phải chạm vào ở mức nào đó.
    • “LIGO tìm sóng hấp dẫn bằng GStreamer” á? Cái gì cơ?!

  • Cá nhân tôi thấy ROOT cố làm quá nhiều thứ, thiết kế API không tốt, và quan trọng nhất là ROOT như một thư viện không được tách khỏi ROOT như một chương trình.
    Có nhiều trạng thái toàn cục, và mặc định ngầm là mọi người phải dùng nó theo kiểu chương trình ROOT. ROOT 6 đã bắt đầu sửa một phần, nhưng sẽ mất thời gian; cá nhân tôi cho rằng việc dựa quá sâu vào llvm và clang đã làm thời gian build dài hơn và khiến dự án khó sửa hơn.
    Trong một thời gian dài, tài liệu về định dạng nhập/xuất cũng nghèo nàn và chỉ có một triển khai duy nhất.
    Hiện nay nhờ groot, uproot, freehep, openscientist, v.v., có thể đọc và ghi dữ liệu ROOT mà không cần kéo toàn bộ ROOT vào. Tôi cho rằng khả năng tương tác của dữ liệu là cực kỳ quan trọng. Đó là điều cần thiết nếu muốn có hy vọng đọc lại dữ liệu duy nhất ấy sau 20 hay 30 năm nữa.
    https://go-hep.org/x/hep/groot
    Tôi là maintainer chính của go-hep.

    • Theo tôi biết, uproot vẫn chưa triển khai đúng việc đọc TEfficiency, nói thật là đáng tiếc.

  • À, root… khiến tôi biết ơn vì không phải dùng các phiên bản trước 6 mỗi ngày.

    • Root là một trong những lý do khiến tôi quyết định không theo học vật lý hạt.
    • Tôi vẫn đang chờ phiên bản 7, bản được hứa là cuối cùng sẽ làm root trở nên tốt hơn, dù có phá vỡ interface. Hình như tôi nghe lần đầu vào khoảng năm 2016; đúng là một lời hứa như đã bốc hơi.

  • Tôi nhớ lại những đêm muộn debug mã do các nhà vật lý xuất sắc nhưng không có nền tảng khoa học máy tính viết.

    • Khoảng năm 2013, tôi làm ở một website cho vay trực tuyến; họ đã thuê các nhà vật lý hạt để xây dựng mô hình dự đoán rủi ro.
      Họ dùng ROOT để mô hình hóa và dùng Ruby để làm interface; nhìn từ góc độ kỹ nghệ phần mềm thì đúng là một quái vật. Nhưng từ góc độ thống kê thì khá ổn.
      Khi đó còn rất lâu trước khi hệ sinh thái Python nổi lên, và các gói machine learning của R cũng mới chỉ bắt đầu.
    • Tôi có thể tưởng tượng một main() dài 2000 dòng.

  • Đúng là Root là xương sống của lượng công việc khổng lồ trong vật lý hạt thực nghiệm, nhưng nó cũng là cơn ác mộng đối với nghiên cứu sinh mới.
    Nó gần như đã bám rễ sâu trong vật lý hạt, nên có vẻ sẽ không thay đổi trong tương lai gần.

    • Hiện nay có pyroot và uproot, nên nghiên cứu sinh mới cũng có các lựa chọn dễ học hơn; vì vậy cũng không đến nỗi tệ.
      Vấn đề thường nằm ở mã legacy phải bảo trì như một phần của các dịch vụ thí nghiệm.

  • Phần Root tôi dùng là Cling, trình thông dịch C++, và Xeus cho notebook Jupyter.
    Một đêm nọ tôi thử so sánh chương trình n-body nhanh nhất trên benchmarkgames giữa Xeus và Python 3. Trên cùng một instance Binder, Xeus mất 15,58 giây, còn khi chạy mã Python nhanh nhất bằng kernel Python3 thì mất 5 phút. Kết quả xuất ra ở cả hai lần chạy đều giống hệt nhau.
    Ngay cả nếu tính overhead thực thi C++ động trong chương trình này là khoảng 300%, Cling vẫn rất nhanh. Tôi không dùng SIMD hay vector hóa, chỉ dùng đúng mã từ benchmarkgames. Tôi chủ yếu dùng Cling như một thay thế JIT nhanh cho các ngôn ngữ biên dịch sang C++.

    • Tôi đang dùng Cling để biên dịch JIT cho phương ngữ Clojure native của mình: https://github.com/jank-lang/jank
      Đây là nỗ lực đưa C++ vào thế giới Clojure, và đưa Clojure cùng lập trình tương tác vào thế giới C++.

  • Mã nguồn: https://github.com/root-project

  • “Debug script CERN ROOT và chương trình dựa trên ROOT trong Eclipse IDE” ư?
    Trời ơi, gợi lại ác mộng. Điều đó rõ ràng cho thấy có thể tạo ra những thứ phi thường ngay cả trong môi trường tồi tệ.

    • Không rõ có phải đang nói về Eclipse không.