盧曉旭 顧旻皓,3 朱科軍,3 李 飛,3

1（中國科學院高能物理研究所 核探測與核電子學國家重點實驗室 北京 100049）

2（中國科學院大學 物理科學學院 北京 100049）

3（中國科學院高能物理研究所 天府宇宙線研究中心 成都 610000）

高海拔宇宙線觀測站（Large High Altitude Air Shower Observatory，LHAASO）是“十二五”期間批復立項的國家重大科技基礎設施，是一個正在邊建設邊運行的處于國際領先水平的高海拔宇宙線觀測項目。項目選址位于四川省稻城縣海子山，海拔4 410 m，投資超過10億元人民幣。項目的核心科學目標為：探索高能宇宙線起源并開展相關的高能輻射、天體演化、甚至于暗物質分布等基礎科學的研究［1-2］。

LHAASO現(xiàn)在的設計中，共有三種探測陣列，包括地面簇射粒子陣列（square KiloMeter detector Array，KM2A）、水切倫科夫探測器陣列（Water Cherenkov Detector Array，WCDA）［3］和廣角切倫科夫望遠鏡陣列（Wide Field Cherenkov Telescope Array，WFCTA）。其中地面簇射粒子陣列（KM2A）分布在方圓1 km2，由5 242個電磁粒子探測器（Electromagnetic Detector，ED）和1 171個繆子探測器（Muon Detector，MD）組成［4］，具體分布如圖1所示。4種探測器獨立運行，產(chǎn)生的數(shù)據(jù)共同參與軟件觸發(fā)，對空氣簇射的不同組成部分進行區(qū)分，從而實現(xiàn)對于宇宙線和γ射線的高精度測量。

圖1 LHAASO各探測器分布Fig.1 Distribution of LHAASO detectors

作為LHAASO的重要組成部分，地面簇射粒子陣列主要科學目標是借助1 km2的觀測面積，以及大視場、全天候的工作特點，覆蓋20 TeV～20 PeV，對γ射線源的巡天靈敏度在50 TeV附近達到1%蟹狀星云流強［5］。KM2A采樣探測廣延空氣簇射（Extensive Air Shower，EAS）到達地面的次級粒子，包括正負電子、γ和μ等。ED主要用于探測正負電子、正負μ和γ，精確測量這些粒子在某一位置處的數(shù)目密度和到達時間。多個ED共同觀測，實現(xiàn)對簇射事例的方向、簇射芯位與能量的重建。ED是塑料閃爍體探測器，閃爍體產(chǎn)生的光子經(jīng)光纖收集傳輸?shù)焦怆姳对龉苻D化成電信號讀出。ED表面覆蓋鉛板，用于將EAS中的光子轉化成電子以提高探測效率和角分辨。MD是水切倫科夫探測器，表面覆蓋厚土層，厚土層用于吸收電子與光子。由于原初宇宙線強子簇射中產(chǎn)生的繆子數(shù)與原初強子的核子數(shù)相關，因此，MD提供的繆子數(shù)可以用于區(qū)分原初強子成分。而通過測量簇射中次級繆子成分進行原初粒子識別，KM2A可以進行γ射線源百TeV能譜測量。

圖2為典型的高能物理實驗的結構示意框圖。探測器系統(tǒng)負責偵測微弱的粒子信號，并將之轉化為電信號，電子學系統(tǒng)負責將電信號轉化為數(shù)字信號，并打包成數(shù)據(jù)包。觸發(fā)判選系統(tǒng)負責完成數(shù)據(jù)的篩選工作。數(shù)據(jù)獲取系統(tǒng)負責進行高速海量數(shù)據(jù)讀取、在線處理與存儲［6］。LHAASO數(shù)據(jù)獲取系統(tǒng)主要分為數(shù)據(jù)流軟件與在線軟件。在線軟件作為一個分布式數(shù)據(jù)獲取系統(tǒng)的架構系統(tǒng)，為數(shù)據(jù)流軟件提供通用框架服務。而數(shù)據(jù)流軟件對于原始物理數(shù)據(jù)的海量數(shù)據(jù)進行獲取、傳輸、處理與存儲［7］。

值得注意的是，對于LHAASO實驗而言，并沒有設計硬件觸發(fā)系統(tǒng)，因此，LHAASO實驗的觸發(fā)判選功能由軟件承擔。所以，必須需要設計一個在線分布式軟件，作為數(shù)據(jù)流軟件的一部分，用來對陣列完成在線的數(shù)據(jù)篩選處理，執(zhí)行“觸發(fā)判選”的功能。

圖2 典型高能物理實驗結構圖Fig.2 Structural diagram of a typical high-energy physics experiment

1 需求分析

LHAASO KM2A設計由5 242個ED和1 171個MD組成，ED估算總數(shù)據(jù)量為230 MB·s-1，MD估算數(shù)據(jù)量為316 MB·s-1，總數(shù)據(jù)量約546 MB·s-1。由于KM2A并不具備硬件觸發(fā)能力，需要設計一套LHAASO地面簇射粒子陣列在線分布式數(shù)據(jù)處理軟件，通過對輸入數(shù)據(jù)進行在線的處理，降低數(shù)據(jù)量的同時，篩選有效數(shù)據(jù)，從而送入磁盤陣列，進行數(shù)據(jù)存儲。

功能上，這個在線分布式數(shù)據(jù)處理軟件采用基于標準以太網(wǎng)和TCP/IP協(xié)議的數(shù)據(jù)傳輸方案，需要能夠接收包括來自所有探測器單元的同一時間的組包完畢的數(shù)據(jù)，利用配置的觸發(fā)算法對數(shù)據(jù)包進行在線處理與計算，將具有物理意義的數(shù)據(jù)提取、打包，組成為一個個標有物理標簽的事例，并按照配置的輸出規(guī)則將這些事例送出至不同的接收方。

性能上，數(shù)據(jù)處理軟件既不能在在線處理與計算前，丟失來自某些探測器的數(shù)據(jù)；也不能將數(shù)據(jù)包處理與計算的時間拉的過長；同時，處理完的事例要及時送出。

2 框架設計與功能實現(xiàn)

2.1 軟件框架概述

由于對于該在線數(shù)據(jù)處理軟件性能要求較高，且出于配置靈活性等方面的考慮，軟件設計采用在線分布式數(shù)據(jù)處理方案。

軟件配有一個管理節(jié)點和多個處理節(jié)點。處理節(jié)點負責進行數(shù)據(jù)的接收與處理，并將處理后的數(shù)據(jù)依照輸出規(guī)則配置文件，將不同標簽的事例發(fā)送至不同的接收節(jié)點。管理節(jié)點負責對于所有處理節(jié)點進行性能監(jiān)督與調度。

軟件采用ZeroMQ作為消息和數(shù)據(jù)通信中間件，采用Protobuf進行消息的（逆）序列化，采用Redis作為信息共享平臺，負責發(fā)布軟件各個節(jié)點的運行信息。軟件的業(yè)務層框架設計如圖3所示。

2.2 軟件運行流程

圖4為軟件的運行示意圖。軟件的運行分為配置階段與數(shù)據(jù)處理階段。

圖3 軟件業(yè)務層框架圖Fig.3 Business layer framework diagram of software

圖4 軟件運行示意圖Fig.4 Software operation system

配置階段，主要完成的是對于軟件節(jié)點部署與節(jié)點內參數(shù)的配置。節(jié)點部署，即配置軟件一共需要的節(jié)點種類，各種類型的節(jié)點個數(shù)，節(jié)點運行位置，節(jié)點ID，節(jié)點是否啟用等。節(jié)點內參數(shù)配置，即配置某個節(jié)點的內部參數(shù)，如節(jié)點內Worker數(shù)量，節(jié)點掛載的動/靜態(tài)鏈接庫，節(jié)點是否開啟輸出/節(jié)點內部存盤功能，節(jié)點調用的數(shù)據(jù)處理階段需要使用的參數(shù)配置文件等。

軟件數(shù)據(jù)處理階段，主要完成的是數(shù)據(jù)消息的傳入、處理以及數(shù)據(jù)的傳出。

軟件的輸入為REQUEST類型消息與FRAGMENT類型消息。軟件每次信息交互，首先是管理節(jié)點收到的REQUEST類型消息。REQUEST類型消息主要意義為請求分配當前最空閑處理節(jié)點。當收到此類型消息后，管理節(jié)點會返回一個NEXTPRO類型消息，其內容為當前最空閑處理節(jié)點ID。

隨后，軟件的處理節(jié)點會收到FRAGMENT類型的消息，消息內容是打包好的某一時間段的來自全部種類全部探測器的數(shù)據(jù)。在線分布式數(shù)據(jù)處理軟件的配置會為該節(jié)點選好需要加載的觸發(fā)算法。當該節(jié)點在運行過程中收到消息后，會利用加載的觸發(fā)算法對于數(shù)據(jù)進行在線的數(shù)據(jù)處理與篩選。對于篩選后需要保留的事例，依據(jù)觸發(fā)算法的不同，根據(jù)數(shù)據(jù)單元的類型，每一個保留的事例打一個類型標記。隨后，根據(jù)配置的輸出規(guī)則，處理節(jié)點可以將不同的事例類型發(fā)送向不同的輸出端。

當處理節(jié)點完成某個FRAGMENT的處理與發(fā)送后，處理節(jié)點會向管理節(jié)點發(fā)送CLEAR類型消息以進行匯報，通知管理節(jié)點更改自身的工作狀態(tài)的記錄。

2.3 軟件各功能模塊詳述

2.3.1 軟件管理模塊

軟件管理模塊對所有處理節(jié)點進行性能監(jiān)督與調度。模塊分為模塊管理單元、模塊配置單元、模塊處理單元、模塊信息管理單元等，如圖5所示。

圖5 管理模塊結構圖Fig.5 Managing module structure diagram

1）模塊管理單元。App單元是軟件管理模塊的管理單元。在軟件初始化階段，App單元負責調用配置單元，設定軟件管理模塊的運行參數(shù)，并初始化模塊處理單元與模塊信息管理單元。在軟件數(shù)據(jù)處理階段，App單元負責接收所有流入軟件管理模塊的消息，進行消息解析，判斷消息類型，調用模塊處理單元完成消息處理。

2）模塊配置單元。Config單元為模塊的配置單元，負責在初始化階段完成參數(shù)設定?？紤]到配置單元僅需要實現(xiàn)一次，該單元采用單例模式實現(xiàn)。而考慮到多線程的運行環(huán)境下仍需要保證該單元的參數(shù)不會被多個線程同時改變，單元采用餓漢模式實現(xiàn)單例［8］。

3）模塊處理單元。模塊處理單元負責在軟件數(shù)據(jù)處理過程中，對于流入軟件管理模塊的不同類型的消息進行不同的處理。該單元主要需要處理的消息類型為REQUEST類型消息與CLEAR類型消息。

處理單元內部存有表格，表格內容節(jié)點ID，節(jié)點當前任務數(shù)量，節(jié)點Worker數(shù)量，節(jié)點CPU效率因子等。同時，會利用這些參數(shù)，計算出每個節(jié)點ID對應的節(jié)點綜合負載量。當收到REQUEST類型消息時，處理單元會查詢表格，尋找到綜合負載量最小的節(jié)點，將其ID返回，同時更新此ID的當前任務數(shù)量，并重新計算此ID對應的節(jié)點綜合負載量。

當收到CLEAR類型消息時，處理單元會查找表格，更新消息發(fā)送節(jié)點的當前任務數(shù)量，同時更新該節(jié)點的綜合負載量。

4）模塊信息管理單元。Info單元為模塊的信息管理單元。該單元在模塊的配置階段，會配置好所有需要進行信息管理的鍵。在模塊的數(shù)據(jù)處理階段，所有其他單元會在有消息操作時，更改模塊信息管理單元相關鍵對應的值。而模塊信息管理單元會定期將所有鍵與值發(fā)布到Redis數(shù)據(jù)庫上，以供用戶查詢運行狀態(tài)。

考慮到多線程安全問題，模塊信息管理單元也采用的是餓漢模式實現(xiàn)的單例模式。

2.3.2 軟件處理模塊

軟件處理模塊主要工作內容為對流入模塊的消息與數(shù)據(jù)進行處理，對處理后的消息數(shù)據(jù)參照配置的發(fā)送規(guī)則進行發(fā)送，以及對于軟件管理模塊進行狀況匯報。軟件處理模塊分為模塊管理單元、模塊配置單元、模塊計算單元、軟件輸出單元、軟件信息管理單元等，如圖6所示。

圖6 處理模塊結構圖Fig.6 Processing module structure diagram

1）模塊管理單元。App單元是軟件觸發(fā)模塊的管理單元。在軟件初始化階段，App單元負責調用配置單元讀取環(huán)境變量，完成基本參數(shù)設定，隨后根據(jù)參數(shù)配置初始化一定數(shù)量的模塊計算單元與模塊輸出單元，加載用戶指定的觸發(fā)算法庫。而在軟件的數(shù)據(jù)處理階段，模塊管理單元作為軟件處理模塊的消息接收節(jié)點，接收所有流入軟件處理模塊的消息并進行處理。軟件管理模塊對消息解析與類型判斷。當消息類型確認為FRAGMENT類型后，管理單元會將消息放入模塊輸入隊列，以供計算單元進行后續(xù)處理。

2）模塊配置單元。Config單元為模塊的配置單元。該單元主要任務為，讀取環(huán)境變量，加載關鍵配置參數(shù)，如模塊實現(xiàn)的Worker數(shù)量，模塊調用的觸發(fā)算法庫的路徑與名稱，模塊的本地存儲與輸出功能的開關等。

3）模塊計算單元。Worker是模塊中擔任在線數(shù)據(jù)計算處理的單元。在線分布式數(shù)據(jù)處理軟件中，Worker數(shù)量用戶可以根據(jù)需求自行配置。Worker的主要任務就是從前面的輸入隊列中拿到數(shù)據(jù)包，調用配置指定的觸發(fā)算法，對于數(shù)據(jù)包進行在線的數(shù)據(jù)計算與篩選，并將處理后的數(shù)據(jù)依照物理意義封裝成事例，并打上對應物理意義的標簽，放入輸出隊列中，以供模塊輸出單元進行數(shù)據(jù)輸出。

KM2A的具體觸發(fā)策略等在§3.4將給出詳細描述。

4）模塊輸出單元。Output是模塊中負責處理后的數(shù)據(jù)分發(fā)的單元。當觸發(fā)模塊打開本地存儲功能時，模塊輸出單元會從輸出隊列中拿取處理好的數(shù)據(jù)存儲到本地磁盤。當觸發(fā)模塊打開數(shù)據(jù)輸出功能時，模塊在完成本地存儲相關工作后，會將數(shù)據(jù)擬成消息格式，進行消息的序列化，并判斷數(shù)據(jù)類型，將序列化的數(shù)據(jù)發(fā)向所有配置時指定該類型需要發(fā)送的節(jié)點。當發(fā)送完成后，會將相關的內存刪除。

5）模塊信息管理單元。Info單元為模塊的信息管理單元。該單元主要功能與執(zhí)行方式與軟件管理模塊的信息管理單元相同。

2.4 軟件通用模塊概述

軟件的內存管理主要由隊列模塊、內存池實現(xiàn)。軟件內部節(jié)點間信息交換采用Protobuf進行消息的序列/逆序列化，采用ZeroMQ作為消息中間件。

2.4.1 隊列模塊

軟件處理模塊內部符合生產(chǎn)者-消費者模型，因此，考慮引入數(shù)據(jù)模型作為數(shù)據(jù)的緩沖區(qū)，從而使得模塊可以在異步的狀態(tài)工作，達到提高其抗性能波動能力的目的［9］。通常在此情況下考慮的數(shù)據(jù)模型有隊列、環(huán)形緩沖區(qū)［10］等。本軟件采用的是隊列模型。首先，隊列模型的隊列長度可以自由變化；其次，隊列的長度易于觀察，從而能夠在調試與運行階段更加便捷地觀察生產(chǎn)者與消費者間的性能差異與性能波動。隊列模塊相較于其他數(shù)據(jù)模型（如環(huán)形緩沖區(qū)）的開發(fā)與測試難度也更低。

2.4.2 內存池模塊

Memory是一個內存池［11］。由于軟件需要不停地創(chuàng)建和銷毀內存，而大量的創(chuàng)建、銷毀操作會產(chǎn)生很大的時間開銷與內存碎片，因此，軟件設計采用了內存池的內存管理方法。在軟件開始接收數(shù)據(jù)之前，Memory負責創(chuàng)建好一定量的不同大小的內存。每次節(jié)點需要創(chuàng)建一個內存，實際操作就是從內存池拿一塊已經(jīng)創(chuàng)建好、最接近所需內存大小且比所需內存大的內存，并在拿取內存后設置內存的實際使用大小。而每次節(jié)點需要銷毀內存，實際的對應操作就是將內存歸還到內存池。如果內存池里的某大小內存“售罄”，則內存池在下次收到此大小內存的獲取操作時，將創(chuàng)建一個具有這個大小的內存到內存池中，再將這塊內存交給節(jié)點調用。當軟件收到結束指令后，內存池里的內存統(tǒng)一銷毀。

2.4.3 消息序列化與逆序列化

消息從結構化數(shù)據(jù)到流的解析過程成為序列化，反之為逆序列化。軟件的序列化與逆序列化采用的是Protobuf工具。Protobuf是一種以字節(jié)流為載體的序列化協(xié)議和工具套件，規(guī)模小、速度快、性能高，所以廣泛應用于通信協(xié)議、數(shù)據(jù)存儲［12］。軟件采用Protobuf對于消息進行序列化封裝，隨后采用ZeroMQ進行消息發(fā)送。消息接收方在利用ZeroMQ完成消息接收后，再采用Protobuf進行消息逆序列化解析，即可以得到消息的內容。

2.4.4 消息中間件

軟件采用的是分布式結構，各節(jié)點間通信尤為重要，軟件選取ZeroMQ完成此項工作。ZeroMQ是一個基于消息隊列的套接字通信并發(fā)框架。它是一個面向消息的、開源的、跨語言的簡單靈活的網(wǎng)絡通信庫，且在數(shù)據(jù)量很大的使用場景下依然能保持高性能數(shù)據(jù)傳輸，而且能屏蔽底層通信細節(jié)?？紤]到性能優(yōu)秀、開發(fā)簡單等諸多優(yōu)點，軟件選組ZeroMQ完成節(jié)點間通信［13］。

3 觸發(fā)算法實現(xiàn)

該軟件為用戶提供了N-Hit觸發(fā)算法作為樣例，為用戶開發(fā)個性化觸發(fā)算法的參考。LHAASO地面簇射粒子陣列中，主要設計采用的就是N-Hit算法。

Hit，即擊中數(shù)據(jù)包。N-Hit觸發(fā)算法是指在某個時間窗口內，著火探測單元的數(shù)量大于“N”時，判定觸發(fā)，這是當今宇宙線實驗中最常見的觸發(fā)方式。在整體實驗中，只有電磁粒子探測器參與觸發(fā)條件判選，當滿足觸發(fā)條件時，將觸發(fā)時間內來自電磁粒子探測器的數(shù)據(jù)包和繆子探測器的數(shù)據(jù)包統(tǒng)一進行打包，封裝成事例。軟件設計中，采用滑動時間窗口的方式，從排序后的擊中數(shù)據(jù)流中挑選滿足“N”觸發(fā)條件的事例的算法。

3.1 擊中數(shù)據(jù)包排序

算法的第一步是對所有擊中數(shù)據(jù)包進行排序。輸入在線分布式數(shù)據(jù)處理軟件的擊中數(shù)據(jù)包是按照單個通道保序的，但不同通道的擊中數(shù)據(jù)包之間不遵循序列號遞增的原則。因此，為滿足滑動時間窗口的條件，需要進行擊中數(shù)據(jù)包間排序。

算法采用的排序方法為合并排序方法。將兩個有序數(shù)列合并為一個有序數(shù)列為“歸并”。合并排序是建立于歸并操作上的一種非常有效的排序算法。屬于分治法的一個典型應用。合并排序的主要作用為：將兩個或者兩個以上的有序表合并成一個新的有序表。首先，將待排序的序列分成若干個子序列，每個子序列都是有序的。然后再把有序的子序列合并為整體有序的序列。

3.2 滑動時間窗“N-Hit”算法

該算法在時間保序的擊中數(shù)據(jù)包數(shù)組上實現(xiàn)，主要負責挑選滿足“n＞N”的觸發(fā)條件的時間窗內數(shù)據(jù)，并打包成事例。首先，算法會開一個Tw時間寬度的時間窗，搜索整個數(shù)據(jù)包，當發(fā)現(xiàn)時間窗內“n＞N”時，記錄“觸發(fā)開始”；隨后，當發(fā)現(xiàn)時間窗內“n＜N”時，記錄“觸發(fā)結束”?！坝|發(fā)開始”與“觸發(fā)結束”之間的擊中數(shù)據(jù)包會被打包成新的事例。算法時間復雜度為O（N）。

假設N設為25，則算法處理示例如圖7所示。

圖7 N-Hit算法示例圖Fig.7 N-Hit algorithm diagram

3.3 數(shù)據(jù)包邊界處理

以上算法可以從一個數(shù)據(jù)包內挑出滿足“NHit”條件的事例，但是若單純逐個數(shù)據(jù)包處理，則會遺失跨兩個數(shù)據(jù)包的滿足“N-Hit”條件的事例。為防止此類事例丟失，算法對于輸入的打包數(shù)據(jù)有一定的要求，需要輸入的每個數(shù)據(jù)包內保留一小段后一個數(shù)據(jù)包的時間的數(shù)據(jù)。這樣，跨數(shù)據(jù)包的事例將會在前一個數(shù)據(jù)包的在線數(shù)據(jù)處理中被處理，從而防止了跨數(shù)據(jù)包事例的漏處理。

3.4 KM2A觸發(fā)策略

KM2A選取N-Hit作為觸發(fā)算法。采用部分探測器參與觸發(fā)判選，全部探測器參與數(shù)據(jù)打包的策略。在KM2A觸發(fā)過程中，首先進行ED擊中數(shù)據(jù)包時間提取與時間排序。隨后，利用滑動時間窗“NHit”算法對于ED進行時間窗搜索。當搜索到“觸發(fā)開始”和“觸發(fā)結束”后，對于此區(qū)間內ED與MD的數(shù)據(jù)包進行打包，從而達到ED重建出原初宇宙線粒子的能量和方向，MD區(qū)分質子與γ，和鑒別原初強子宇宙線的種類的功能。

4 軟件測試

軟件的測試分為模擬測試與實際運行測試兩方面。模擬測試采用模擬數(shù)據(jù)輸入，主要用于測試軟件的功能，軟件的實際運行測試采用真實探測器系統(tǒng)進行測試，主要用于測試軟件是否滿足性能需求。

4.1 模擬測試

為了方便用戶對于個性化開發(fā)的觸發(fā)算法進行功能測試，另外提供了離線觸發(fā)算法測試的軟件，以及數(shù)據(jù)解析軟件。離線觸發(fā)測試軟件的主要功能：接收FRAGMENT類型消息作為輸入，調用某一指定的觸發(fā)算法對消息進行處理，并將處理后的事例進行存儲。數(shù)據(jù)解析軟件的主要功能：讀取離線觸發(fā)測試軟件產(chǎn)生的存儲文件，對其中的數(shù)據(jù)進行格式解析，檢查數(shù)據(jù)格式是否符合約定。

圖8為N-Hit算法產(chǎn)生的數(shù)據(jù)文件開頭部分的截圖。數(shù)據(jù)文件采用的是“文件頭+事例”的格式標準。前256字節(jié)為文件頭，主要包含文件的基本描述性信息，如文件格式版本號、運行編號、文件開始/結束錄入時間、文件名、文件名大小、文件頭保留位等。事例采用的是“事例頭+事例數(shù)據(jù)內容”的格式，事例頭包括事例頭標志位、事例頭長度、事例長度、事例編號、事例時間、事例流標志位等。事例數(shù)據(jù)內容包括事例類型標簽與事例數(shù)據(jù)包。

如圖8所示，“ee34 12ee”為事例頭標志位，“2400 0000”為事例頭長度。“0000 0000”為事例頭擴展部分長度，“8e12 0000”為事例總長度，“0100 0000”為事例類型標簽。綜合數(shù)據(jù)文件與數(shù)據(jù)解析程序分析，N-Hit算法能產(chǎn)生符合要求的數(shù)據(jù)。

圖8 N-Hit產(chǎn)生數(shù)據(jù)文件的數(shù)據(jù)片段Fig.8 Data fragment in data file generated by N-Hit

4.2 實際運行測試

實際運行測試：將該在線分布式數(shù)據(jù)處理軟件集成到數(shù)據(jù)流軟件中，在數(shù)據(jù)獲取系統(tǒng)對實際的地面簇射粒子陣列進行數(shù)據(jù)采集與處理工作時，對數(shù)據(jù)處理軟件的功能與性能進行測試。

數(shù)據(jù)獲取系統(tǒng)硬件采用的是兩組共28片刀片服務器，CentOS Linux release 7.4.1708版本64位操作系統(tǒng)，內核版本采用的是3.10.0，CPU配置為48×3.00 GHz CPU（超線程開），CPU型號為Intel（R）Xeon（R）Gold 6136 CPU@3.00 GHz。

此時數(shù)據(jù)獲取系統(tǒng)共計連接2 380臺ED和570臺MD，數(shù)據(jù)獲取系統(tǒng)總計輸入帶寬約230 MB·s-1。共計配置處理節(jié)點27個，管理節(jié)點1個。由于軟件管理節(jié)點負荷很輕，此處給出處理節(jié)點負荷變化。圖9、10與表1為實際運行一段時間后某一節(jié)點的負荷情況，每45 min采樣一次，共采樣約8 h。值得提出的是，出于對前期觸發(fā)產(chǎn)生事例的分析考慮，實際觸發(fā)算法較原設計N-Hit觸發(fā)策略稍有修改，如此處采用的是ED與MD均可參與觸發(fā)的方式等。

圖9 某處理節(jié)點輸入帶寬Fig.9 Input bandwidth of one processing node

表1 某處理節(jié)點待處理任務數(shù)量Table 1 Amount of buffered packs in one processing node

圖10 某處理節(jié)點輸出帶寬Fig.10 Output bandwidth of one processing node

圖9 ～12與表1～2為某段運行時間內不同時刻節(jié)點統(tǒng)計數(shù)據(jù)。圖9～10與表1為單節(jié)點統(tǒng)計數(shù)據(jù)，圖11～12與表2為所有處理節(jié)點總計統(tǒng)計數(shù)據(jù)。圖9統(tǒng)計了軟件某節(jié)點輸入數(shù)據(jù)包的速率，可以看出，輸入帶寬相對比較穩(wěn)定，沒有隨著時間的推移而出現(xiàn)顯著的帶寬不斷上升或下降的趨勢。表1為該節(jié)點的待處理數(shù)據(jù)包的數(shù)量。從表1可以看出，該節(jié)點待處理數(shù)據(jù)包在幾次觀測點均為0，證明所有輸入到該節(jié)點的數(shù)據(jù)包均迅速完成了數(shù)據(jù)處理，不存在節(jié)點內部數(shù)據(jù)包堆積的現(xiàn)象。圖10為該節(jié)點輸出數(shù)據(jù)包的速率。從圖10可以看出，節(jié)點的輸出帶寬雖然出現(xiàn)了部分抖動，但是抖動均不超過某一范圍。

圖11為軟件所有處理節(jié)點總輸入帶寬。從圖11中可以看出，處理節(jié)點總輸入帶寬與預計帶寬稍有偏高但相差不大。由于不同時刻不同探測器的擊中情況不同，導致預計帶寬時只能依照設計指標與前期運行情況給出大致統(tǒng)計。而由于數(shù)據(jù)在全部數(shù)據(jù)流軟件中進行傳遞時會進行多次格式變動（如數(shù)據(jù)組裝時會添加部分數(shù)據(jù)格式），因此，可認為處理節(jié)點總輸入帶寬基本與預期相差無幾。圖12為軟件所有處理節(jié)點的輸出帶寬，從圖12可以看出，總輸出帶寬在某一范圍內有一定抖動變化。抖動的產(chǎn)生與影響因素有很多，比如不同時刻輸入帶寬的變化，網(wǎng)絡的性能抖動，以及節(jié)點的緩存機制，數(shù)據(jù)的統(tǒng)計方式等。雖然輸出帶寬存在較大抖動，但是長時間內軟件處理節(jié)點輸入帶寬與預期基本相符，節(jié)點基本不存在任務堆積，處理節(jié)點不存在資源緊張問題，且產(chǎn)生的事例文件速率與預期差別不大，因此，可以認為軟件并沒有呈現(xiàn)出性能不足的問題。表2為所有處理節(jié)點總待處理任務數(shù)量。從表2可以看出，大部分觀測時間點所有節(jié)點都沒有待處理任務堆積，某個別時間點，可能存在少量的待處理任務堆積，但是隨即被節(jié)點內部消化掉了，沒有造成后續(xù)影響。

圖11 總處理節(jié)點輸入帶寬Fig.11 Input bandwidth of all processing nodes

圖12 總處理節(jié)點輸出帶寬Fig.12 Output bandwidth of all processing nodes

表2 某處理節(jié)點待處理任務數(shù)量Table 2 Amount of buffered packs in one processing node

圖13為此次觀測時間段內產(chǎn)生的某一個事例數(shù)據(jù)文件的文件頭部分。軟件實際運行產(chǎn)生的數(shù)據(jù)與模擬運行產(chǎn)生的數(shù)據(jù)格式?jīng)]有區(qū)別。因此，可以套用§4.1中對于模擬數(shù)據(jù)的格式分析，對于圖13的格式進行分析檢查。

圖13 事例數(shù)據(jù)文件中數(shù)據(jù)片段Fig.13 Data fragment in event data file

圖14 為通過離線格式檢查程序對事例數(shù)據(jù)文件進行初步檢查。從圖14可以看出，事例數(shù)據(jù)文件通過了格式檢查，不存在格式錯誤問題。由圖14可見，處理節(jié)點完成了數(shù)據(jù)篩選的功能，且性能足夠滿足需求。

5 系統(tǒng)部署與運行狀況

LHAASO地面簇射粒子陣列在線分布式數(shù)據(jù)處理軟件，已經(jīng)作為LHAASO數(shù)據(jù)流軟件的一個重要組成部分，集成到了LHAASO數(shù)據(jù)獲取系統(tǒng)中。

圖14 事例數(shù)據(jù)文件檢查Fig.14 Event data file check

2018年，LHAASO數(shù)據(jù)獲取系統(tǒng)已經(jīng)部署到了四川省稻城縣海子山的計算機房。從2018年起，LHAASO數(shù)據(jù)獲取系統(tǒng)已經(jīng)配合著地面簇射粒子陣列的擴建，邊調整部署邊運行取數(shù)實驗。2019年9月19～20日，LHAASO數(shù)據(jù)獲取系統(tǒng)1/4規(guī)模的鑒定驗收會在LHAASO測控基地（稻城）召開，會議針對數(shù)據(jù)獲取開展了現(xiàn)場測試?，F(xiàn)場測試表明，數(shù)據(jù)獲取系統(tǒng)各項性能指標均達到LHAASO 1/4實驗要求。專家組一致同意數(shù)據(jù)獲取1/4系統(tǒng)通過鑒定。這表明數(shù)據(jù)獲取系統(tǒng)數(shù)據(jù)流軟件搭載的本在線分布式數(shù)據(jù)處理軟件功能與性能均達到了項目的需求，能順利完成軟件的任務。

截止2020年1月6日，KM2A共計建成并投入科學運行2 398臺ED和574臺MD，達到了LHAASO實驗1/2的規(guī)模。在此規(guī)模下，分布式在線處理軟件運行良好。

6 結語

本文以LHAASO實驗為項目背景與目標，設計與實現(xiàn)了一套針對地面簇射粒子陣列的在線分布式數(shù)據(jù)處理軟件。該軟件提供了無硬件觸發(fā)的高能物理實驗背景下，一種在線實時完成軟件觸發(fā)與數(shù)據(jù)篩選的通用解決方案與解決平臺。一方面，在線分布式數(shù)據(jù)處理可以保證實時得到觸發(fā)結果，便于掌握實驗狀況進行實驗調整，另一方面，在線完成數(shù)據(jù)處理可以減輕數(shù)據(jù)存儲負擔，將冗余數(shù)據(jù)在存儲前剔除掉。與此同時，可以掛載不同的觸發(fā)算法并對觸發(fā)算法的參數(shù)進行靈活調整，也保證了這種通用解決方案與平臺的高可用性。該在線數(shù)據(jù)處理軟件功能上能夠靈活掛載多種多樣的觸發(fā)算法，性能上充分滿足了LHAASO地面簇射粒子陣列及類似規(guī)模物理實驗的性能需求。此外，軟件設計結構簡潔，模塊劃分合理，還具有高度的可移植性。

軟件目前已集成到數(shù)據(jù)獲取系統(tǒng)。至2020年1月6日，地面簇射粒子陣列1/2規(guī)模已完成建設并投入科學運行，在此規(guī)模下，軟件運行穩(wěn)定，狀態(tài)良好?？紤]到1/2規(guī)模下，軟件運行壓力適中，且只要增加處理節(jié)點個數(shù)即可提高軟件性能，因此，當實驗規(guī)模繼續(xù)擴展時，可以通過繼續(xù)增添硬件設備，靈活調整部署方案，使得軟件也能滿足全陣列規(guī)模的運行。下一步，該軟件將繼續(xù)作為數(shù)據(jù)獲取系統(tǒng)數(shù)據(jù)流軟件的一部分，配合項目陣列的擴展繼續(xù)調整部署擴展運行。同時還將針對多陣列聯(lián)合觸發(fā)的需求與實際情況，對于多種觸發(fā)算法聯(lián)合掛載開發(fā)更加貼合實際需求的解決方案。