高能物理實驗徑跡系統(tǒng)流式數(shù)據(jù)獲取框架的研究

吳 冶 章紅宇 朱科軍 王之濱 陳瑪麗 祁輝榮

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

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

高能物理實驗旨在研究基本粒子及其相互作用，通過獲取和分析高精度、高統(tǒng)計量的實驗數(shù)據(jù)，發(fā)現(xiàn)新粒子或測量已知粒子的特性。隨著高亮度加速器和高精度探測器的發(fā)展，高能物理實驗的規(guī)模不斷增大，實驗數(shù)據(jù)量急劇增長，海量數(shù)據(jù)的獲取、處理及分析將更具挑戰(zhàn)性。中國科學家在2012年9月提出了用于精確測量希格斯粒子特性的環(huán)形正負電 子 對 撞 機（Circular Electron Positron Collider，CEPC）方案，其核心探測器由硅像素頂點探測器、內(nèi)部硅徑跡室、時間投影室、外部硅徑跡室、量能器和繆子探測器等多個子探測器組成，結(jié)構(gòu)如圖1所示。其中，硅像素頂點探測器和時間投影室探測器是通道數(shù)最多、產(chǎn)生數(shù)據(jù)量最大的兩個子探測器。

圖1 CEPC核心探測器模型Fig.1 CEPC core detector model

根據(jù)CEPC概念設計報告［1］中的設計參數(shù)計算，當一級觸發(fā)為100 kHz時，CEPC所有探測器原始讀出的數(shù)據(jù)率約為2 TB·s-1，其中硅像素頂點探測器約有6.90×108個通道，讀出數(shù)據(jù)率約為830 GB·s-1，時間投影室（Time Projection Chamber，TPC）約有2×106個通道，讀出數(shù)據(jù)率約為500 GB·s-1，這兩種探測器的數(shù)據(jù)將占到CEPC數(shù)據(jù)讀出總帶寬的65%。

CEPC所需要的硅像素徑跡探測器、時間投影室徑跡探測器及其激光校正分別獲得了科技部重點研發(fā)項目和國家自然科學基金重點項目的資助，開展前期預研。作為以上探測器預研課題的一部分，為應對這兩種探測器超高數(shù)據(jù)率的數(shù)據(jù)采集和處理需求，本文嘗試結(jié)合目前成熟的大數(shù)據(jù)技術，進行新型數(shù)據(jù)獲取軟件的研究和探索，并在相關課題的原型機實驗中進行測試。

數(shù)據(jù)獲取系統(tǒng)（Data Acquisition System，DAQ）是高能物理實驗重要的子系統(tǒng)之一，其功能包括探測器電子學數(shù)據(jù)的高速讀出、事例組裝、事例篩選及運行控制與監(jiān)測等。大型高能物理實驗的數(shù)據(jù)獲取系統(tǒng)為大規(guī)模分布式系統(tǒng)，除了高帶寬的數(shù)據(jù)讀出具有挑戰(zhàn)性外，對每秒TB量級的數(shù)據(jù)流進行在線處理也具有相當大的挑戰(zhàn)性。

在高能物理實驗中，研制超大數(shù)據(jù)流、高性能、高可用的分布式數(shù)據(jù)獲取軟件，往往需要一個團隊多年的努力。

近年來，計算機領域中大數(shù)據(jù)處理技術發(fā)展迅速，超大數(shù)據(jù)流的處理在工業(yè)界已逐漸形成一套事實標準，即Hadoop［2］大數(shù)據(jù)處理框架。Hadoop框架是一個由Apache基金會開發(fā)的分布式系統(tǒng)基礎架構(gòu)，主要解決海量數(shù)據(jù)的存儲和海量數(shù)據(jù)的分析計算問題。Hadoop框架的核心是分布式文件系統(tǒng)（Hadoop Distributed File System，HDFS）［3］和資源管理器（Yet Another Resource Negotiator，YARN）［4］。

作為一種有意義的嘗試，本文通過分析高能物理實驗數(shù)據(jù)獲取軟件各項功能需求的特點，對比研究了大數(shù)據(jù)框架的各類組件和技術，引入了Hadoop框架中的一些組件，在其基礎上研制開發(fā)了一套新型的高能物理數(shù)據(jù)獲取軟件框架BigDataDAQ（以下簡稱BDDAQ），成功應用于時間投影室探測器的模型實驗，并在實驗室的服務器集群上對BDDAQ框架進行了性能測試。

1 BDDAQ軟件架構(gòu)

大型高能物理實驗的DAQ系統(tǒng)是一套分布式的軟件系統(tǒng)，它通過信息傳遞使得各個分散的、相互獨立的功能模塊能夠協(xié)調(diào)工作，完成物理數(shù)據(jù)的讀出、分發(fā)/重組和在線數(shù)據(jù)處理。

ATLAS是歐洲核子中心大型強子對撞機（Large Hadron Collider，LHC）上的4個探測器之一，也是迄今為止世界上最大的探測器，TDAQ［5］（Trigger DAQ）是其數(shù)據(jù)獲取系統(tǒng)框架。

TDAQ主要包括兩個部分：數(shù)據(jù)流軟件（Data Flow Software）和在線軟件（Online Software）。數(shù)據(jù)流軟件包括讀出系統(tǒng)模塊（Readout System Module）、事例組裝模塊（Event Building Module）、多級事例篩選模塊（Event Filter Module）和數(shù)據(jù)存儲模塊（Data Storage Module）。在線軟件服務于數(shù)據(jù)流和整個實驗系統(tǒng)的各個方面，提供控制、監(jiān)測和錯誤顯示等各種服務。

BDDAQ軟件在系統(tǒng)整體架構(gòu)上也遵循TDAQ的設計思路，即同樣分為數(shù)據(jù)流軟件和在線軟件兩部分。但是在技術實現(xiàn)上有所不同。

相比較于TDAQ使用內(nèi)存做緩沖層，BDDAQ數(shù)據(jù)流軟件在讀出模塊和事例組裝模塊之間增加一個消息隊列模塊，使用內(nèi)存和硬盤一起作為數(shù)據(jù)讀出和處理的緩沖層，可以承受在超大數(shù)據(jù)率下網(wǎng)絡波動造成的數(shù)據(jù)累積，更大程度地防止由于內(nèi)存溢出導致的DAQ軟件崩潰。BDDAQ在線軟件一部分功能通過Hadoop的相關組件的內(nèi)置功能實現(xiàn)，減小了在線軟件的設計難度。

BDDAQ軟件整體的框架設計見圖2，其中FEE（Front End Electronics）部分是前端電子學系統(tǒng)。

圖2 BDDAQ軟件框架Fig.2 BDDAQ software framework

BDDAQ數(shù)據(jù)流軟件參考了高海拔宇宙線觀測站（Large High Altitude Air Shower Observatory，LHAASO）實驗的在線實時分布式數(shù)據(jù)處理經(jīng)驗［6］，主要功能由讀出組件模塊（Readout Service Module）、消 息 隊 列 組 件 模 塊（Message Queue Module）、事例處理任務構(gòu)建與發(fā)布組件模塊（Job Construction and Submission Module）、分布式計算引擎模塊（Distributed Processing Engine Module）和事例存儲模塊（Event Storage Module）實現(xiàn)。

BDDAQ在線軟件功能由配置模塊（Config Service）、信息協(xié)調(diào)模塊（Information Coordination）、資源調(diào)度模塊（Yarn）、運行控制模塊（Run Control Service）和在線可視化模塊（Online Visualization）實現(xiàn)。

BDDAQ軟件在數(shù)據(jù)流軟件和在線軟件兩部分都引入了Hadoop框架提供的分布式基礎組件，再結(jié)合高能物理徑跡探測器數(shù)據(jù)流的特點和需求進行本地化開發(fā)。接下來本文將從數(shù)據(jù)流和在線軟件兩部分介紹整個BDDAQ軟件。

2 BDDAQ數(shù)據(jù)流軟件

數(shù)據(jù)流軟件面向的對象是高能物理實驗數(shù)據(jù)流，主要負責對前端電子學輸出數(shù)據(jù)流進行讀出，進而完成事例片段的同步組裝、在線數(shù)據(jù)處理和數(shù)據(jù)存儲等任務。BDDAQ根據(jù)以上功能需求設計實現(xiàn)為讀出模塊、消息隊列、事例處理模塊和存儲模塊。

2.1 BDDAQ數(shù)據(jù)流處理需求分析

探測器電子學輸出的是TCP協(xié)議數(shù)據(jù)流，讀出模塊主要功能是讀取數(shù)據(jù)流并將數(shù)據(jù)流拆分為一個個單獨的數(shù)據(jù)包，這一步驟也稱作讀出分片，最后將一個個數(shù)據(jù)包作為消息發(fā)送到消息隊列。未來硅徑跡探測器和時間投影室產(chǎn)生的數(shù)據(jù)流可能需要多達近萬個連接進行數(shù)據(jù)讀出，需要使用NIO（Nonblocking I/O）模式，在單個線程內(nèi)輪詢處理多個TCP連接。

消息隊列用來接收讀出模塊發(fā)送的數(shù)據(jù)包，并向事例處理模塊提供數(shù)據(jù)，是數(shù)據(jù)讀出與處理之間的緩沖層。

在大數(shù)據(jù)處理領域，數(shù)據(jù)流處理模型一般分為批處理和流處理。批處理模型先緩存一批數(shù)據(jù)再進行計算，適用于實時性要求不高，但對數(shù)據(jù)的準確性和全面性要求更高的場景。流式處理模型更注重對流式數(shù)據(jù)的實時分析，數(shù)據(jù)以流的方式到達，攜帶了大量信息，經(jīng)過實時處理之后只有小部分的流式數(shù)據(jù)被保存在有限的內(nèi)存中。

高能物理實驗對數(shù)據(jù)流的處理有三種模式：1）數(shù)據(jù)包映射模式：此模式中輸入是單個數(shù)據(jù)包，根據(jù)映射規(guī)則輸出一個或多個數(shù)據(jù)包，這一過程不涉及其他數(shù)據(jù)包的信息，可以看成是一種流處理過程。2）事例組裝模式：此模式中輸入是滿足組裝條件的一組數(shù)據(jù)包，根據(jù)組裝規(guī)則輸出一個或多個事例，需要等待所有滿足組裝規(guī)則的數(shù)據(jù)包到達，可以看成是一種批處理過程。3）事例篩選模式：此模式中輸入是一個完整事例，根據(jù)物理算法對事例進行計算，輸出一個布爾值，根據(jù)布爾值來對事例進行過濾，是一種流處理過程。

由于高能物理實驗中DAQ的數(shù)據(jù)流處理既有流處理過程又有批處理過程，因此BDDAQ需要“批流一體式”的數(shù)據(jù)流處理架構(gòu)。

2.2 讀出模塊

BDDAQ的讀出模塊功能由Readout Service組件實現(xiàn)，整個Readout Service組件主要功能有：處理多個TCP連接；從TCP連接的數(shù)據(jù)流中解析出單個數(shù)據(jù)包并驗證數(shù)據(jù)格式的正確性和數(shù)據(jù)包的完整性；將已驗證數(shù)據(jù)包發(fā)送到內(nèi)存緩沖隊列；從內(nèi)存緩沖隊列獲取數(shù)據(jù)發(fā)送到消息隊列。下文將分別介紹每個功能的實現(xiàn)，最后介紹整個讀出模塊的系統(tǒng)架構(gòu)。

2.2.1 處理多TCP連接的網(wǎng)絡服務器

BDDAQ軟件使用NIO網(wǎng)絡通信模式，Java的NIO模式在Linux底層實現(xiàn)是使用epoll［7］不斷輪詢所負責的已注冊socket，當某個socket有數(shù)據(jù)到達，就通知用戶線程進行處理。

Netty［8］是一款基于Java的NIO客戶端/服務器編程框架，BDDAQ使用Netty快速開發(fā)了高性能、高可靠性的網(wǎng)絡服務器，實現(xiàn)了前端電子學的網(wǎng)絡數(shù)據(jù)讀出。

BDDAQ采用池化直接內(nèi)存（Pooled Direct Byte Buffer）作為IO操作的緩沖區(qū)，以提高運行效率。池化直接內(nèi)存的內(nèi)存管理機制參考了Jemalloc［9］，即提前申請一大塊內(nèi)存空間作為預分配內(nèi)存池，然后將這塊內(nèi)存空間分割為很多相等大小的頁（Page）來進行管理，根據(jù)申請的內(nèi)存大小使用不同的分配策略從預分配內(nèi)存池中分配內(nèi)存，銷毀內(nèi)存時只是將準備銷毀的內(nèi)存釋放回預分配內(nèi)存池，等待程序運行結(jié)束再對預分配內(nèi)存池統(tǒng)一銷毀，大大提高了內(nèi)存分配效率。

2.2.2 數(shù)據(jù)流解析驗證

高能物理實驗中的前端電子學一般都進行數(shù)據(jù)零壓縮，因此發(fā)送的數(shù)據(jù)包都是變長的，且具有事先約定的數(shù)據(jù)格式。BDDAQ設計實現(xiàn)了解碼器父類（Length Field Based Frame Decoder）進行數(shù)據(jù)包的解碼，校驗器父類（Frame Validator）對解碼出來的數(shù)據(jù)包進行校驗。對于不同的探測器只需要根據(jù)探測器數(shù)據(jù)格式的各自特點繼承解碼器和校驗器，編寫新的實現(xiàn)即可。

2.2.3 有界內(nèi)存緩沖隊列

數(shù)據(jù)流解析驗證生成大量通過驗證的數(shù)據(jù)包，這些數(shù)據(jù)包需要被傳送到后續(xù)的Kafka［10］集群中。數(shù)據(jù)流解析驗證過程可以被看作是生產(chǎn)者，把數(shù)據(jù)包發(fā)送至Kafka集群的過程可以被看作是消費者，由于這兩個過程的數(shù)據(jù)處理速率可能會產(chǎn)生波動，因此兩者之間需要內(nèi)存緩沖隊列作為緩沖層，Java中的阻塞隊列性能較低，BDDAQ軟件使用了開源無鎖的高性能緩沖隊列Disruptor［11］。

2.2.4 讀出組件的結(jié)構(gòu)說明

讀出組件（Readout Service）的系統(tǒng)構(gòu)成如圖3所示，它采用反應器（Reactor）事件驅(qū)動模式，注冊了一個單獨的連接事件處理線程（Reactor Thread）作為TCP連接分發(fā)器，一個NIO工作線程池（NIO Work Thread Pool）來處理TCP連接讀數(shù)據(jù)事件，一個Kafka生產(chǎn)者線程池（Kafka Producer Thread Pool）負責發(fā)送數(shù)據(jù)包到Kafka集群。

整個處理流程如下：

1）多個TCP客戶端連接注冊到Reactor Thread上，此線程只處理TCP連接的accept事件，并將處理完成的TCP連接輪流綁定到NIO工作線程池的某個線程上。

2）NIO工作線程池中的線程按照處理流水線（Channel Pipe Line）的流程運行。首先循環(huán)檢測綁定到自身的TCP連接是否有讀事件，檢測到讀事件之后，讀取數(shù)據(jù)并將數(shù)據(jù)傳遞到解碼器解碼、校驗器驗證，最后將驗證正確的單獨數(shù)據(jù)包放入Disruptor內(nèi)存緩沖隊列。

3）Kafka生產(chǎn)者線程池中的線程從Disruptor內(nèi)存緩沖隊列讀取數(shù)據(jù)并發(fā)送到Kafka集群。

2.3 消息隊列模塊

BDDAQ軟件使用消息隊列（Message Queue Module）的主要目的是：平衡電子學數(shù)據(jù)讀取和流式平臺數(shù)據(jù)處理的數(shù)據(jù)速率波動；作為整個讀出模塊與事例處理部分的緩沖層；將讀出模塊與流式事例處理模塊解耦。

這種解耦架構(gòu)的優(yōu)勢是將高能物理數(shù)據(jù)流的數(shù)據(jù)包分片階段和處理階段拆分成兩個互相獨立的組件，各自實現(xiàn)自己的處理邏輯，通過消息隊列提供的消息寫入和消費接口實現(xiàn)對消息的連接處理。這樣的設計可以降低系統(tǒng)開發(fā)復雜度，提高系統(tǒng)穩(wěn)定性，有利于之后的擴展升級。

圖3 Readout service組件結(jié)構(gòu)Fig.3 Components structure of readout service

BDDAQ軟件采用Kafka集群實現(xiàn)分布式消息隊列，使數(shù)據(jù)獲取系統(tǒng)具備了如下特點：

高吞吐率：Kafka使用Linux系統(tǒng)提供的零拷貝技術減少消息的網(wǎng)絡傳輸時間，提供端到端的消息壓縮傳輸和磁盤順序?qū)懭耄蟠筇岣吡藢懭胄阅?，實現(xiàn)了高吞吐率。

高容錯、高可用：允許配置多副本，將副本均勻地分配到不同機器存儲，多副本之間有消息同步機制，當集群某個機器進程意外退出后，集群能夠自動發(fā)現(xiàn)處理，并繼續(xù)提供讀寫服務。

可擴展性：能夠方便地增減消息隊列集群規(guī)模。

Exactly-once語義：即使消息發(fā)送者重試發(fā)送消息，消息消費者也只會消費一次消息。

事務能力：消費者消費時，在一個事務里面，事務執(zhí)行成功則認為消息被消費，否則事務將回滾，需要重新處理。

2.4 流式事例處理模塊

從§2.1的需求分析可知，BDDAQ軟件的事例處理模塊（Streaming Event Process Module）是“流批一體式”的分布式數(shù)據(jù)流處理系統(tǒng)。大數(shù)據(jù)框架中常見的分布式流處理引擎有Storm、Spark Streaming和Flink［12］等。其中Flink是開源社區(qū)中一種集高吞吐、低延遲、高性能三者于一身的分布式“流批一體式”數(shù)據(jù)流處理框架。

Flink將所有的輸入數(shù)據(jù)都視為數(shù)據(jù)流，其中流式處理代表無界的數(shù)據(jù)流處理，批處理代表有界的數(shù)據(jù)流處理。Flink具有如下優(yōu)點：1）函數(shù)式原語；2）支持有狀態(tài)計算（Stateful Computations）；3）支持事件時間（Event Time）概念；4）支持高度靈活的窗口（Window）操作。因此BDDAQ軟件選擇了Flink作為分布式數(shù)據(jù)流處理引擎。

2.5 事例處理任務構(gòu)建與發(fā)布模塊

事例處理任務構(gòu)建與發(fā)布模塊（Job Construction and Submission Module）主要負責根據(jù)不同探測器電子學事例處理模塊的處理邏輯構(gòu)建相應的Flink處理流程，并打包成Flink作業(yè)上傳到Flink計算集群中運行。

通過Flink的函數(shù)式原語可以根據(jù)不同電子學產(chǎn)生的數(shù)據(jù)特點方便地編寫不同的數(shù)據(jù)流處理邏輯。

通過Flink有狀態(tài)計算可以獲取流處理過程中的實時統(tǒng)計數(shù)據(jù)，用于實時在線監(jiān)測。

BDDAQ軟件通過Flink的窗口功能實現(xiàn)了不同的事例組裝邏輯。在高能物理的事例組裝過程中，組裝條件一般分為兩種：

1）按觸發(fā)號組裝：對于具有公共觸發(fā)信號的多個子探測器產(chǎn)生的數(shù)據(jù)，將所有觸發(fā)號相同的子探測器數(shù)據(jù)包組裝成完整的事例。BDDAQ軟件使用Flink對數(shù)據(jù)包內(nèi)的觸發(fā)信息進行KeyBy分組操作，開啟一個指定大小的計數(shù)窗口（Count Windows），觸發(fā)信息相同的數(shù)據(jù)包被緩存到同一個計數(shù)窗口，當這個計數(shù)窗口的數(shù)據(jù)包數(shù)量達到指定大小后，對這一批數(shù)據(jù)包按照提交的運算邏輯進行組裝操作，輸出一個事例。

2）按時間片組裝：將數(shù)據(jù)包產(chǎn)生的時間線（Time Line）分為很多時間單元，將某個時間單元內(nèi)的所有數(shù)據(jù)包組裝成事例。BDDAQ軟件使用Flink的事件時間（Event Time）概念，將事件時間設為數(shù)據(jù)包內(nèi)的時間戳字段，之后開啟時間窗口（Time Windows）。對于每一個數(shù)據(jù)包，根據(jù)其時間戳信息劃分到相應的時間窗口，并通過Flink的watermark概念來靈活地平衡處理數(shù)據(jù)的延時和完整性。當時間窗口結(jié)束時對本時間窗口的數(shù)據(jù)包做組裝處理。

事例篩選功能是對每一個組裝好的完整事例或時間片數(shù)據(jù)依照物理篩選算法進行計算，決定是否保留該事例或挑選感興趣的事例，若需要保留，則將該事例傳輸至后續(xù)的存儲模塊。BDDAQ軟件通過Flink的過濾算子實現(xiàn)了事例篩選功能。

2.6 存儲模塊

BDDAQ的事例存儲模塊（Event Storage Module）是對事例進行持久化存儲?，F(xiàn)有的存儲方法是將事例以文件形式保存到數(shù)據(jù)中心的中央存儲系統(tǒng)。當需要搜尋歷史事例進行事例分析或進行一些可視化繪圖操作時，需要從中央存儲系統(tǒng)中讀取相應文件，再進行分析。通常這類搜尋事例的速度很慢，為此BDDAQ軟件在保留現(xiàn)有的存儲方法外，增加了分布式存儲和分布式數(shù)據(jù)庫兩種方式來存儲部分事例，在超大數(shù)據(jù)量下可以通過索引工具迅速搜尋到相應事例。

2.6.1 分布式文件系統(tǒng)

分布式文件系統(tǒng)（Distributed File System，DFS）是指文件系統(tǒng)管理的物理存儲資源不一定直接連接在本地節(jié)點上，而是通過計算機網(wǎng)絡與節(jié)點相連；或是若干不同的邏輯磁盤分區(qū)或卷標組合在一起而形成的完整的有層次的文件系統(tǒng)。

BDDAQ軟件使用了HDFS作為分布式文件系統(tǒng)組件。HDFS是基于流數(shù)據(jù)模式訪問和超大文件處理的需求而開發(fā)的，可以運行于廉價的商用服務器上，具有高容錯、高可靠性、高可擴展性、高獲得性和高吞吐率等特征，為海量數(shù)據(jù)提供了安全可靠的分布式存儲。

2.6.2 分布式數(shù)據(jù)庫

分布式數(shù)據(jù)庫主要用來存儲數(shù)據(jù)流處理過程中的一些中間結(jié)果和部分事例，方便在線軟件查詢實時狀態(tài)，以及進行歷史數(shù)據(jù)的在線可視化。BDDAQ軟件使用的分布式數(shù)據(jù)庫由Hive和Hbase兩種組件構(gòu)成。

Hive［13］是基于Hadoop的一個數(shù)據(jù)倉庫工具，支持結(jié)構(gòu)化查詢語句（Structured Query Language，SQL）［14］進行數(shù)據(jù)關聯(lián)查詢。HBase［15］是一個開源的非關系型分布式數(shù)據(jù)庫，只支持主鍵數(shù)據(jù)查詢。

如果用戶不需要進行大規(guī)模的數(shù)據(jù)關聯(lián)查詢則BDDAQ軟件將直接使用Hbase存儲事例。反之，先將數(shù)據(jù)存儲成Hive數(shù)據(jù)倉庫表的形式，之后構(gòu)建SQL語句對Hive表進行關聯(lián)查詢，并將查詢結(jié)果存儲到Hbase表中。

3 在線軟件

在線軟件（Online Software）是負責對整個數(shù)據(jù)獲取系統(tǒng)進行靈活的運行控制、軟硬件配置、在線監(jiān)控、進程管理和信息共享等的分布式軟件系統(tǒng)，為數(shù)據(jù)流軟件提供保障和監(jiān)控功能，并向外部提供信息查詢接口。

BDDAQ在線軟件由5個模塊構(gòu)成：

1）配置模塊（Config Service Module）：此組件提供用戶層面的軟硬件配置服務和前端電子學的配置服務，并集成到圖形化用戶界面程序（GUI）中。

2）運行控制模塊（Run Control Service Module）：此組件對整個數(shù)據(jù)獲取系統(tǒng)各個模塊的運行流程進行管理。

3）在線可視化模塊（Online Visualization Module）：此組件通過讀取分布式數(shù)據(jù)庫的數(shù)據(jù)來發(fā)布數(shù)據(jù)獲取流程中的統(tǒng)計直方圖、單通道信號波形重建等可視化圖形。

4）信 息 協(xié) 調(diào) 模 塊（Information Coordination Module）：此組件使用了Hadoop的Zookeeper組件作為信息協(xié)調(diào)中心，實現(xiàn)了控制信息的傳遞、運行信息的匯總以及運行狀態(tài)監(jiān)控等功能。

5）資源調(diào)度模塊（Yarn）：此組件使用了Hadoop的集群資源框架Yarn來統(tǒng)一向數(shù)據(jù)流處理過程中的各進程分配資源，開啟任務，管理每一個進程，提供進程日志查看，進程終止服務，實現(xiàn)了靈活的資源控制管理、作業(yè)調(diào)度功能、進程的管理和監(jiān)控。

4 BDDAQ軟件在LTPC實驗中的應用

作為徑跡探測器的時間投影室（TPC）是一種氣體探測器，在建造和運行過程中，其內(nèi)部結(jié)構(gòu)應力、外部溫度、氣壓的變化等因素均會影響到徑跡的精確測量，需要進行實驗標定。激光標定是在TPC探測器實驗中的一種非常實用和有效的標定方法。LTPC實驗［16］是以GEM氣體探測器為原型機進行激光標定實驗的研究項目，整個原型機的結(jié)構(gòu)如圖4所示。

LTPC實驗原型機采用266 nm紫外激光束結(jié)合高精度微反射鏡陣列產(chǎn)生42束窄激光束，設計激光沿Z方向共9層分布，其中橫向的6層只有一束激光，縱向的3層中每層12束激光，LTPC原型機激光分布如圖5所示。

圖4 時間投影室探測器結(jié)構(gòu)Fig.4 TPC detector structure

LTPC讀出端蓋的通道模型如圖6所示。LTPC探測器電子學共有20塊數(shù)據(jù)采集板，每塊采集板64個通道，各通道對過閾信號進行40 MHz時鐘的波形采樣，輸出波形數(shù)據(jù)，電子學系統(tǒng)整體讀出速率最大可達100 MB·s-1。

LTPC實驗電子學數(shù)據(jù)流輸出構(gòu)成為：每一次觸發(fā)信號到達，會先輸出一個觸發(fā)時間包，之后每個有響應的通道輸出一個觸發(fā)采樣包，再等待下一個觸發(fā)信號到達。

圖5 LTPC原型機激光光路分布Fig.5 Laser distribution of LTPC prototype

圖6 LTPC讀出端蓋通道分布模型Fig.6 Distribution model of LTPC read-out end-plate channel

觸發(fā)采樣包的采樣點采集過程為：觸發(fā)信號到來后電子學通道開始等待信號過閾，在信號過閾后開啟一定長度的采樣時間窗口，一個采樣時間窗口內(nèi)會收集不同平面內(nèi)平行的激光徑跡的采樣信號。

圖7 、8分別為觸發(fā)時間包和觸發(fā)采樣包具體數(shù)格式。

圖7 LTPC觸發(fā)時間包詳細數(shù)據(jù)格式Fig.7 Detailed data format of LTPC trigger time packet

事例處理流程分為以下三步：1）數(shù)據(jù)包轉(zhuǎn)換過程：根據(jù)數(shù)據(jù)包格式中特定字段的標識，區(qū)分觸發(fā)時間包和觸發(fā)采樣包。如果是觸發(fā)時間包則輸出時間戳；如果是觸發(fā)采樣包則根據(jù)數(shù)據(jù)包的通道位置將多個平面平行激光徑跡上的過閾波形采樣點區(qū)分為不同組，對于每一組采樣點輸出一個包含觸發(fā)號信息、激光徑跡信息、本組采樣數(shù)據(jù)的數(shù)據(jù)包。2）事例組裝過程：將同一個觸發(fā)信號下的同一條徑跡的數(shù)據(jù)包組裝為一個事例。3）事例篩選過程：對一個完整事例中各響應通道的信號波形進行尋峰操作，得到每一個響應通道的信號幅值，相鄰通道的信號幅值通過重心法計算得到重心位置，再判斷這一完整事例中所有重心的分布是否與激光徑跡相符合，進行事例篩選。

LTPC模型系統(tǒng)數(shù)據(jù)獲取軟件基于BDDAQ軟件框架編寫，為了方便實驗人員操作將參數(shù)配置、運行控制以及數(shù)據(jù)可視化功能都集成到了如圖9所示的圖形化軟件界面。

圖8 LTPC觸發(fā)采樣包詳細數(shù)據(jù)格式Fig.8 Detailed data format of LTPC trigger sample packet

圖9 LTPC DAQ用戶圖形控制界面Fig.9 Graphical user control interface of LTPC DAQ

LTPC的事例先存儲到Hive數(shù)據(jù)倉庫，之后根據(jù)需求進行SQL查詢得到結(jié)果子集，最后將結(jié)果子集存儲到Hbase數(shù)據(jù)庫。圖10所示的LTPC探測器可視化模型是根據(jù)實驗原型機讀出端蓋各通道幾何尺寸等比例繪制的視圖，圖中每一個矩形小塊代表一個探測器通道，其顏色深淺表示該通道電子學采樣波形的峰值大小。

在可視化模型窗口內(nèi)點擊某個擊中通道，會彈出一個窗口，顯示該通道的采樣信號波形圖，如圖11所示。

LTPC實驗數(shù)據(jù)可視化功能除以上兩種功能外還包括：取數(shù)狀態(tài)監(jiān)測、數(shù)據(jù)質(zhì)量監(jiān)測報告、多種物理量的統(tǒng)計直方圖。由于可視化所需要的事例都存儲在分布式數(shù)據(jù)庫，因此搜尋事例的速度快，可視化功能的響應時間都在秒級，性能遠遠高于讀取數(shù)據(jù)存儲文件再進行分析并搜尋事例的傳統(tǒng)方法。

圖10 LTPC探測器可視化模型Fig.10 Visualization model of LTPC detector

圖11 通道采樣波形Fig.11 Vaveform of channel sampling

使用分布式數(shù)據(jù)庫存儲部分事例可以大大提高事例的查詢性能，為抽樣數(shù)據(jù)分析、可視化功能、實時數(shù)據(jù)監(jiān)測等需求提供了有力支持。

實驗結(jié)果不僅表明BDDAQ架構(gòu)的可用性，也表明結(jié)合大數(shù)據(jù)技術處理高能物理實驗數(shù)據(jù)流的技術路線是可行的。

5 模擬數(shù)據(jù)源性能測試

由于LTPC原型機通道數(shù)較少，實驗室進行的激光校準實驗事例率較低，無法直接測試出BDDAQ軟件的性能指標。因此使用實驗室服務器模擬數(shù)據(jù)源，對BDDAQ軟件進行了數(shù)據(jù)處理性能的測試和評估。

在操作系統(tǒng)為Centos7的15臺高密度服務器上部署了BDDAQ集群，其中1個節(jié)點作為整個集群的控制節(jié)點，不參與實際運算，剩下14個節(jié)點作為工作節(jié)點，所有節(jié)點通過萬兆網(wǎng)線或光纖連接到交換機。整個集群由8臺型號A和7臺型號B的計算機構(gòu)成，具體硬件參數(shù)見圖12。

圖12 集群計算機硬件參數(shù)Fig.12 Computer hardware parameters in the cluster

整個集群的工作節(jié)點共560個CPU核。每臺服務器保留20%的內(nèi)存，約38.4 GB自用，剩下的內(nèi)存分出33.6 GB用于運行Hadoop相關進程，剩下120 GB內(nèi)存分配給Yarn組件進行管理，整個集群一共1.64 TB內(nèi)存可用于YARN任務的內(nèi)存分配。

為了測試整個集群的數(shù)據(jù)處理速率上限，Kafka和Flink組件部署在全部工作節(jié)點上，F(xiàn)link作業(yè)的事例處理流程為讀取Kafka集群的消息到內(nèi)存后，進行簡單的數(shù)據(jù)包映射處理之后存儲數(shù)據(jù)到文件。采用Kafka自帶的專用測試工具測試，當消息大小為8 kB時，Kafka集群中單個Kafka節(jié)點寫入性能極限為每秒76 800條消息，吞吐量達到600 MB·s-1，集群整體寫入帶寬上限為8.7 GB·s-1。BDDAQ集群的數(shù)據(jù)處理帶寬受制于這一Kafka集群的總寫入帶寬。

BDDAQ框架性能測試使用的數(shù)據(jù)包長度為7～8 kB，數(shù)據(jù)包頭帶有包長字段。設置Kafka集群消息保存時間1 min，超時之后消息自動刪除。在集群中選擇1臺服務器啟動讀出模塊連接模擬數(shù)據(jù)源，讀出分片線程和Kafka生產(chǎn)者線程數(shù)為4：4時，數(shù)據(jù)包分片和發(fā)送速度達到一致，讀出模塊穩(wěn)定運行的吞吐率達到2 GB·s-1。

單個模擬數(shù)據(jù)源在保證每一讀出節(jié)點帶寬穩(wěn)定在2 GB·s-1左右的情況下，最多可以同時向4個讀出節(jié)點發(fā)送數(shù)據(jù)。此時整個BDDAQ集群的數(shù)據(jù)處理帶寬達到8 GB·s-1，基本接近Kafka集群寫入性能上限。

在上述測試條件下，通過觀察Kafka集群中消息的累積速度來判斷整個BDDAQ的運行狀態(tài)，在長達3 h的運行測試實驗中，Kafka集群的消息累積量在10萬條左右小范圍波動，可以通過每條數(shù)據(jù)大小乘以10萬條再除以數(shù)據(jù)處理帶寬，計算出約為100 ms的數(shù)據(jù)量累積。因此，實驗結(jié)果證明了BDDAQ系統(tǒng)可以保持在低延時狀態(tài)長期穩(wěn)定運行。

目前，由于實驗室條件限制，測試實驗數(shù)據(jù)率在GB量級，但是BDDAQ使用大數(shù)據(jù)集群的優(yōu)勢就是在于可以很方便地通過水平擴展集群規(guī)模來提高整個集群的數(shù)據(jù)獲取和處理能力。

6 結(jié)語

本文以未來大型高能物理實驗徑跡探測器的數(shù)據(jù)獲取系統(tǒng)為項目背景與研究目標，為多連接讀出和并行處理設計實現(xiàn)了一套分布式數(shù)據(jù)獲取系統(tǒng)BDDAQ。該系統(tǒng)結(jié)合Hadoop大數(shù)據(jù)技術，引入了一些成熟的開源組件，簡化了分布式數(shù)據(jù)獲取軟件的開發(fā)流程，降低了分布式數(shù)據(jù)獲取軟件的開發(fā)難度，提供了靈活的集群水平擴展能力，實現(xiàn)了簡潔直觀的WebUI控制界面。

使用BDDAQ軟件架構(gòu)，按照LTPC實驗需求編寫的DAQ軟件，可以充分滿足該實驗對在線數(shù)據(jù)處理和快速數(shù)據(jù)質(zhì)量檢查的需求，大大提高了實驗數(shù)據(jù)處理和可視化的速度，軟件部署方便快捷。BDDAQ集群性能測試結(jié)果表明：BDDAQ架構(gòu)下集群中的單臺機器數(shù)據(jù)處理性能接近于Kafka組件的寫入能力上限，未來根據(jù)實驗需求可以通過水平擴展服務器數(shù)量來提升整個集群的數(shù)據(jù)處理帶寬。BDDAQ架構(gòu)作為流式數(shù)據(jù)獲取框架為高能物理實驗數(shù)據(jù)獲取系統(tǒng)提供了一種可行的解決方案，也可為未來自行研制流式數(shù)據(jù)處理架構(gòu)提供借鑒。