基于Hadoop技術(shù)的加速器大數(shù)據(jù)安全存儲與高效分析系統(tǒng)設(shè)計

摘" 要： 為了解決當(dāng)前加速器控制系統(tǒng)在數(shù)據(jù)管理方面所面臨的海量數(shù)據(jù)安全存儲和高效分析處理的問題，在現(xiàn)有的基礎(chǔ)上引入了Hadoop大數(shù)據(jù)框架，并結(jié)合大數(shù)據(jù)其他相關(guān)組件，構(gòu)建一個分布式數(shù)據(jù)倉庫系統(tǒng)。文章詳細闡述了數(shù)據(jù)倉庫的搭建過程，包括軟硬件架構(gòu)以及將數(shù)據(jù)從現(xiàn)有數(shù)據(jù)庫抽取、轉(zhuǎn)換和加載到數(shù)據(jù)倉庫的方案。特別是針對系統(tǒng)歸檔數(shù)據(jù)的存儲和分析需求，根據(jù)實際應(yīng)用場景設(shè)計一個基于HBase的存儲解決方案。在系統(tǒng)部署完成后，進行了吞吐量測試，并與當(dāng)前使用的傳統(tǒng)數(shù)據(jù)庫進行性能對比。測試結(jié)果顯示，基于Hadoop的數(shù)據(jù)倉庫系統(tǒng)在海量數(shù)據(jù)存儲、高性能查詢以及數(shù)據(jù)分析處理方面都表現(xiàn)出明顯的優(yōu)勢。這一改進為加速器控制系統(tǒng)提供了更強大的數(shù)據(jù)管理和處理能力，有望為加速器在未來的發(fā)展提供更多可能性。

關(guān)鍵詞： 數(shù)據(jù)倉庫； Hadoop技術(shù)； 加速器； 大數(shù)據(jù)； 安全存儲； HBase； ETL

中圖分類號： TN911?34； TP311.1； TL53" " " " " " " 文獻標識碼： A" " " " " " " "文章編號： 1004?373X（2024）08?0009?09

Design secure storage and efficient analysis system for accelerator big data

based on Hadoop technology

ZHAO Zichen1， 2， YANG Feng1， GUO Yuhui1， CHEN Youxin1， LI Zhaoyang1， LIU Haitao1

（1. Institute of Modern Physics， Chinese Academy of Sciences， Lanzhou 730000， China;

2. School of Computer Science and Technology， University of Chinese Academy of Sciences， Beijing 100049， China）

Abstract： In order to address the challenges of massive data secure storage and efficient analysis in the data management of the current accelerator control system， the Hadoop big data framework is introduced on the existing foundation. In combination of various big data components， a distributed data warehouse system is constructed. The process of building a data warehouse is elaborated， including software and hardware architecture， as well as a solution for extracting， converting， and loading data from existing databases into the data warehouse. An HBase based storage solution is designed based on practical application scenarios for the storage and analysis requirements of system archived data. After the system deployment， throughput testing was conducted and performance comparisons were made with the traditional databases currently in use. The testing results show that the the Hadoop based data warehouse system has shown significant advantages in massive data storage， high?performance queries， and data analysis and processing. This improvement provides stronger data management and processing capabilities for accelerator control systems， and is expected to provide more possibilities for the future development of accelerator control.

Keywords： data warehouse; Hadoop technology; accelerator; big data; secure storage; HBase; ETL （extract， transform， load）

0" 引" 言

加速器驅(qū)動次臨界系統(tǒng)（Accelerator Driven Sub?critical System， ADS）是目前最有效的核廢料處理方案[1]。近代物理研究所承擔(dān)的中國ADS研究項目是加速器驅(qū)動嬗變研究裝置（China initiative Accelerator Driven System， CiADS）[2]，并且在2017年建成了質(zhì)子超導(dǎo)直線加速器前端示范樣機（Chinese ADS Front?end Demo Linac， CAFe）[3]。CAFe超導(dǎo)直線加速器樣機是由離子源、低能傳輸線、RFQ、中能傳輸線、超導(dǎo)加速段、高能傳輸線和束流收集器組成的一個龐大且復(fù)雜的實驗裝置[4]。作為加速器運行“大腦”的加速器控制系統(tǒng)，其復(fù)雜程度更是不言而喻。復(fù)雜的加速器控制系統(tǒng)意味著海量的控制數(shù)據(jù)。目前的數(shù)據(jù)存儲方式存在很多問題，如數(shù)據(jù)存儲分散、數(shù)據(jù)安全性差、數(shù)據(jù)訪問效率低以及當(dāng)前的PV歸檔數(shù)據(jù)庫功能單一，只能支持數(shù)據(jù)查詢操作等。如何將海量的數(shù)據(jù)安全存儲、高效利用是當(dāng)下面臨的重要問題。

基于Hadoop的大數(shù)據(jù)分布式處理架構(gòu)可以提高數(shù)據(jù)管理效率和計算性能。將加速器數(shù)據(jù)存儲在統(tǒng)一的分布式文件系統(tǒng)中，可以避免數(shù)據(jù)存儲分散的問題，方便數(shù)據(jù)的管理和維護。同時，基于HDFS的副本機制可以實現(xiàn)數(shù)據(jù)備份和容錯，以避免數(shù)據(jù)丟失。通過Hadoop的資源管理器Yarn，可以實現(xiàn)計算資源的統(tǒng)一管理和調(diào)度，提高計算性能。使用分布式計算框架如MapReduce、Spark等，可以高效地處理和分析大規(guī)模數(shù)據(jù)。此外，基于Hadoop的大數(shù)據(jù)分布式處理架構(gòu)具有良好的可擴展性，可以滿足不斷增長的數(shù)據(jù)存儲和計算需求?；谏鲜黾軜?gòu)可以有效解決加速器數(shù)據(jù)存儲和分析中的問題，提高數(shù)據(jù)管理效率和計算性能。本文將介紹如何搭建基于Hadoop的加速器數(shù)據(jù)倉庫，包括硬件架構(gòu)、軟件安裝，以及數(shù)據(jù)ETL和存儲方案等方面的實踐和技術(shù)選型，以滿足加速器控制中心的數(shù)據(jù)存儲和分析需求。

1" 架構(gòu)設(shè)計

1.1" 傳統(tǒng)架構(gòu)

Archiver Appliance[5]是當(dāng)前EPICS控制系統(tǒng)存檔器的實現(xiàn)基礎(chǔ)，也是當(dāng)前數(shù)據(jù)架構(gòu)的核心。它通過提供多個存儲階段來滿足不同的存儲需求，從而高效地滿足數(shù)據(jù)的檢索需求。然而，它的局限在于缺乏對數(shù)據(jù)的進一步處理和分析支持，這可能限制了研究人員發(fā)現(xiàn)控制數(shù)據(jù)之間模式、趨勢和關(guān)聯(lián)性的能力。RDB Channel Archiver[6]是EPICS控制系統(tǒng)存檔器的歷史版本，在底層使用關(guān)系數(shù)據(jù)庫存儲歷史數(shù)據(jù)和索引文件。因此，CAFe在2016—2018年期間的歷史數(shù)據(jù)，包含超過5 000個PV變量，數(shù)據(jù)總量達到570多億個，都保存在MySQL數(shù)據(jù)庫中。隨著EPICS控制系統(tǒng)存檔器的更新，MySQL還存儲了當(dāng)前Archiver Appliance歸檔數(shù)據(jù)庫的配置信息，包括歸檔PV變量的物理意義、IP地址和歸檔操作記錄等，數(shù)據(jù)量大約在1萬條。定時節(jié)點的配置信息存儲在MongoDB數(shù)據(jù)庫中，而模式管理的相關(guān)數(shù)據(jù)則存儲在PostgreSQL數(shù)據(jù)庫中，報警系統(tǒng)的配置信息和相關(guān)數(shù)據(jù)則存儲在ElasticSearch數(shù)據(jù)庫中。各種數(shù)據(jù)被存儲在不同子系統(tǒng)的服務(wù)器上，形成了一個綜合而復(fù)雜的數(shù)據(jù)存儲架構(gòu)。

現(xiàn)有存儲架構(gòu)下，當(dāng)研究人員有數(shù)據(jù)計算分析需求時，需要從遠端的Archiver Appliance和其他數(shù)據(jù)庫下載數(shù)據(jù)到本地，然后在本地計算機或者上傳到其他計算資源上進行計算分析[7]。之后根據(jù)計算結(jié)果，向IOC服務(wù)器下發(fā)控制指令，由于存儲和計算分離，這種方案下的數(shù)據(jù)傳輸消耗了大量的網(wǎng)絡(luò)帶寬資源，且由于計算資源有限，難以完成海量數(shù)據(jù)的計算分析。就目前現(xiàn)場設(shè)備的運行而言，CAFe已經(jīng)有超過20個IOC程序和6 000多個PV變量。在進行溫度相關(guān)分析時，低溫系統(tǒng)的工作人員需要下載近期幾個月低溫系統(tǒng)相關(guān)溫度數(shù)據(jù)。僅僅200～300個數(shù)據(jù)點的數(shù)據(jù)，就需要花費兩三天的下載時間。在后續(xù)流程中，工作人員將下載的數(shù)據(jù)以txt格式保存，然后導(dǎo)入到Excel中或者使用Python進行畫圖和分析。

上述數(shù)據(jù)流程時間跨度長，且使用辦公軟件進行數(shù)據(jù)分析存在一些限制。如果分析的時間跨度更長或者涉及更多設(shè)備的數(shù)據(jù)，此方案將變得難以實現(xiàn)。預(yù)計CiADS項目的總控系統(tǒng)將需要數(shù)百個IOC和超過10萬個PV變量。如此龐大的數(shù)據(jù)量，目前數(shù)據(jù)架構(gòu)是不能滿足數(shù)據(jù)分析要求的。同時，由于數(shù)據(jù)架構(gòu)和作業(yè)流程復(fù)雜，加速器的相關(guān)數(shù)據(jù)被存儲在多個系統(tǒng)或者個人計算機，導(dǎo)致數(shù)據(jù)存儲分散，數(shù)據(jù)冗余，且存在數(shù)據(jù)安全問題?，F(xiàn)有架構(gòu)下的數(shù)據(jù)流圖如圖1所示。

1.2" Hadoop架構(gòu)

基于上述傳統(tǒng)架構(gòu)存在的問題，提出一種基于Hadoop的數(shù)據(jù)存儲分析處理架構(gòu)。Hadoop 是一個開源的分布式計算框架[8]，旨在對大規(guī)模數(shù)據(jù)集進行存儲和處理。它最初由Apache軟件基金會開發(fā)，并成為Apache項目的一部分。Hadoop的優(yōu)勢在于其分布式計算和存儲能力，可以在廉價的硬件上構(gòu)建大規(guī)模的集群，并處理海量的數(shù)據(jù)。它具有高可靠性、高可擴展性和高性能的特點，適用于處理需要大規(guī)模并行計算的任務(wù)。Hadoop已經(jīng)成為大數(shù)據(jù)處理的事實標準，并在各個行業(yè)和領(lǐng)域得到廣泛應(yīng)用。

在實際的工程環(huán)境中，數(shù)據(jù)冷熱之分非常明顯，研究人員對數(shù)據(jù)的查詢一般集中在短期幾個小時或者幾天的數(shù)據(jù)。在此情境下，對于近期生成的數(shù)據(jù)，可以選擇將其保存在輕量級、便于查詢的數(shù)據(jù)庫中，以提供快速的數(shù)據(jù)訪問和查詢。另一方面，為了長期存儲和分析，可以定期將數(shù)據(jù)ETL（抽取、轉(zhuǎn)換和加載）[9]到數(shù)據(jù)倉庫中。如圖2所示，數(shù)據(jù)倉庫是一個面向分析的中心化存儲系統(tǒng)。在數(shù)據(jù)倉庫中，可以對數(shù)據(jù)進行更深入的分析、挖掘和建模，以獲取更全面的洞察和決策支持。最后，為了優(yōu)化存儲資源和性能，可以定期清理輕量級數(shù)據(jù)庫中的冷數(shù)據(jù)，根據(jù)業(yè)務(wù)需求設(shè)定冷數(shù)據(jù)的保留期限，過期的數(shù)據(jù)可以進行清理和歸檔，以釋放存儲空間和提高查詢性能。

新的架構(gòu)下，現(xiàn)場設(shè)備產(chǎn)生的數(shù)據(jù)在歸檔到Archiver Appliance數(shù)據(jù)庫的同時定時ETL到集群，科研人員不用下載數(shù)據(jù)到本地，只需向集群提交計算任務(wù)，集群完成計算任務(wù)。這種方式既避免了海量數(shù)據(jù)的傳輸時間問題，同時也滿足了高性能計算的需求。對于上述低溫系統(tǒng)的需求，系統(tǒng)已經(jīng)按照研究人員的分析需求定時將數(shù)據(jù)ETL到集群，研究人員只需要在本地使用數(shù)據(jù)庫管理客戶端工具，或者使用WebUI調(diào)用服務(wù)器端的數(shù)據(jù)可視化工具，拉取相應(yīng)的圖表就可以直接進行數(shù)據(jù)分析。基于Hadoop架構(gòu)的數(shù)據(jù)流圖如圖3所示。

2" 具體搭建

2.1" 硬件、軟件環(huán)境

本實驗使用DELL R450機架式服務(wù)器，以及DELL T630和T430兩臺塔式服務(wù)器，還整合了DELL XPS9360和DELL Vostro兩臺PC機，成功搭建了一個包括5個節(jié)點的Hadoop集群。表1、表2為實驗的軟硬件配置。在實際生產(chǎn)環(huán)境中，可以采用相同型號的服務(wù)器進行集群搭建，以確保系統(tǒng)的一致性和穩(wěn)定性。同時，Hadoop具有出色的可擴展性，因此可以根據(jù)實際需求逐步增加集群節(jié)點，以保證系統(tǒng)能夠應(yīng)對不斷增長的工作負載。

因為性能和實際部署要求，需要將NameNode、SecondaryNameNode以及ResourceManage安裝在不同的服務(wù)器節(jié)點上。Zookeeper集群規(guī)模過小，可能會導(dǎo)致負載過高，影響集群的性能和可靠性；如果集群規(guī)模過大，可能會浪費資源和增加維護成本。根據(jù)歷史工程經(jīng)驗，將Zookeeper設(shè)置為3個節(jié)點組成的集群。HBase也全部部署在5臺服務(wù)器上，Spark運行在Yarn上，同時還配置了歷史數(shù)據(jù)庫等相關(guān)服務(wù)。之后在性能較好的DELL R450上部署了Hive和Phoenix。

2.2" 搭建流程

Hadoop作為整個數(shù)據(jù)倉庫的基礎(chǔ)，首先進行安裝配置，再依次安裝相關(guān)組件。其中需要在core?site.xml、core?site.xml、yarn?site.xml、mapred?site.xml中配置集群節(jié)點的相關(guān)信息，以及不同組件的WebUI訪問端口。Hadoop使用Zookeeper來協(xié)調(diào)和管理分布式環(huán)境中的各個節(jié)點，Zookeeper也依賴于Hadoop來存儲其數(shù)據(jù)和元信息。安裝Zookeeper時，在zoo.cfg中配置相關(guān)信息。Nifi的分布式安裝需要在Zookeeper的基礎(chǔ)上進行，同時需要在state?management.xml文件中配置Zookeeper相關(guān)信息。雖然Hive和Hbase的使用不需要依賴Nifi，但在本文架構(gòu)下無論是結(jié)構(gòu)化還是非結(jié)構(gòu)化的數(shù)據(jù)，都需要Nifi同步到Hive和Hbase。同時，相應(yīng)的數(shù)據(jù)文件也需要存儲在Hadoop的HDFS分布式文件系統(tǒng)。接下來安裝Nifi數(shù)據(jù)同步工具；之后安裝Spark、Hive集成Hbase，進行高效數(shù)據(jù)分析；最后安裝Superset大數(shù)據(jù)可視化界面，實現(xiàn)對上述大數(shù)據(jù)分析的可視化展示。軟件安裝流程如圖4所示。

2.3" 數(shù)據(jù)遷移ETL

系統(tǒng)中用各式各樣的數(shù)據(jù)庫儲存著不同設(shè)備或者不同子系統(tǒng)產(chǎn)生的數(shù)據(jù)，需要搭建Nifi[10]數(shù)據(jù)同步工具將不同數(shù)據(jù)源的數(shù)據(jù)ETL到數(shù)據(jù)倉庫。關(guān)系型數(shù)據(jù)通過Nifi抽取到集群，集群通過Hive統(tǒng)一訪問關(guān)系型數(shù)據(jù)。非關(guān)系型數(shù)據(jù)通過Nifi抽取到HBase。Archiver Appliance的PV歸檔數(shù)據(jù)通過編寫Java代碼，設(shè)置定時運行，將每天新生成的數(shù)據(jù)歸檔到Hbase分布式數(shù)據(jù)庫。其他文件數(shù)據(jù)可以直接通過HDFS的WebUI上傳到分布式集群。數(shù)據(jù)ETL方案如圖5所示。

關(guān)系型數(shù)據(jù)庫通過Nifi抽取到集群，集群通過Hive統(tǒng)一訪問關(guān)系型數(shù)據(jù)。以MySQL為例，QueryDatabaseTable組件連接到MySQL數(shù)據(jù)庫，執(zhí)行SQL查詢語句，從指定的表中抽取數(shù)據(jù)。ConvertAvroToJSON組件將查詢結(jié)果轉(zhuǎn)換為JSON格式。SplitJson組件將JSON數(shù)據(jù)拆分為多個單獨的JSON對象。EvaluateJsonPath組件解析JSON數(shù)據(jù)，提取需要的字段或?qū)傩?。ReplaceText組件對提取的數(shù)據(jù)進行文本替換操作，修正格式或去除特殊字符。PutHDFS組件將處理后的數(shù)據(jù)寫入HDFS中的指定路徑，保存為文件。上層Hive可以直接讀取所存儲的文件并進行分析。關(guān)系型數(shù)據(jù)ETL流程如圖6所示。

非關(guān)系型數(shù)據(jù)庫通過Nifi抽取到HBase。以MongoDB為例，GetMongo組件連接到MongoDB數(shù)據(jù)庫，執(zhí)行查詢操作，從指定的集合中獲取數(shù)據(jù)。EvaluateJsonPath、ReplaceText這兩個組件和上述在同步MySQL數(shù)據(jù)時的功能相同。PutHBaseJSON組件將處理后的數(shù)據(jù)以JSON格式寫入HBase表中。非關(guān)系型數(shù)據(jù)ETL流程如圖7所示。

3" 應(yīng)用與性能測試

3.1" Hbase存儲方案與Rowkey設(shè)計

HBase[11]和MySQL數(shù)據(jù)庫的表組織方式類似，HBase根目錄下有很多個類似庫的Namespace，每個Namespace之下有很多個表。

將不同子系統(tǒng)的數(shù)據(jù)存儲在不同的Namespace下，一個Namespace下的不同表存儲不同采樣頻率或者不同功能的PV變量。一般來說，相同功能的PV變量會被同時處理分析，這種存儲方案將方便研究人員同時獲取所需要的PV變量。

圖8是使用CSS?Pheobus制作的電源系統(tǒng)超導(dǎo)電源[12]的控制界面，每個CM模塊有6個子模塊，每個子模塊有螺線管、水平矯正、垂直矯正3組設(shè)備，每組設(shè)備又有運行故障狀態(tài)和電流電壓讀數(shù)[13]。整個超導(dǎo)電源子系統(tǒng)約有500個PV，在Archiver Appliance歸檔系統(tǒng)中，所有PV單獨存儲，進行數(shù)據(jù)分析時，只能逐個下載PV。本文將上述子系統(tǒng)的所有PV存儲到HBase的一張數(shù)據(jù)表中，不同的設(shè)備作為不同的列族，具體的PV由列限定符和RowKey共同設(shè)定。

HBase的數(shù)據(jù)存儲方式是將表按行進行水平分割，并將每個分割后的部分作為一個Region。Region是HBase中數(shù)據(jù)存儲和負載均衡的基本單元，每個Region都包含多個連續(xù)的行，并且按照行鍵（Rowkey）[14]的順序進行排序。行鍵被用于將數(shù)據(jù)分布到不同的Region中，并且在數(shù)據(jù)檢索時提供高效的訪問。當(dāng)數(shù)據(jù)寫入HBase時，HBase會根據(jù)行鍵的范圍將數(shù)據(jù)分配到相應(yīng)的Region中。行鍵在HBase中扮演著至關(guān)重要的角色，因此需要根據(jù)實際需求合理地設(shè)計行鍵。

編碼方式如下：

2023?07?01?00?00?000：CM1_01 （1）

CM1_01：2023?07?01?00?00?000 （2）

00CM1_01：2023?07?01?00?00?000 （3）

RowKey若采用編碼方式（1），當(dāng)查詢一段時間，這張表所有模塊的PV友好，但是當(dāng)查詢一個模塊PV的所有時間，需要過濾很多次，因為不同模塊的PV會離散儲存在不同的Region中。

采用編碼方式（2），由于一張表中的模塊是可以枚舉的，無論是按照時間查找還是按照模塊查找都可以相對較好的滿足。但是由于是按照RowKey進行存儲的，如此編號會導(dǎo)致CM1_01的PV集中儲存在一個Region，進而導(dǎo)致負載不均衡。

編碼方式（3）是在方式（2）的基礎(chǔ)上進行提前預(yù)分區(qū)，分區(qū)號設(shè)置為PV+時間月份的哈希值取余分區(qū)數(shù)，解決了上述出現(xiàn)的問題。

在對數(shù)個月的數(shù)據(jù)進行分析時，數(shù)據(jù)被分散在每個節(jié)點上，實現(xiàn)了良好的負載均衡。HBase的超導(dǎo)電源表結(jié)構(gòu)如圖9所示。

3.2" HBase吞吐量測試

完成數(shù)據(jù)表的設(shè)計和數(shù)據(jù)存儲后，使用YCSB[15]工具對HBase分布式數(shù)據(jù)庫進行了不同規(guī)模數(shù)據(jù)集和不同并發(fā)量下的讀寫吞吐量測試。測試數(shù)據(jù)見圖10。

隨著數(shù)據(jù)集規(guī)模從百條數(shù)據(jù)到千萬條數(shù)據(jù)逐漸擴大，HBase在數(shù)據(jù)檢索與寫入方面的性能呈現(xiàn)出了相對的穩(wěn)定性，運行速度并不會隨著數(shù)據(jù)集的增大而變慢，維持了令人滿意的水平，足以滿足實際應(yīng)用需求。這一結(jié)果的穩(wěn)定性與HBase分布式、可伸縮的架構(gòu)密不可分，使其能夠有效地處理不同規(guī)模的數(shù)據(jù)集。

HBase不同訪問并發(fā)量下讀寫性能測試如圖11所示。隨著并發(fā)量的增加，HBase的運行時間相對于擴大的并發(fā)負載而言，僅呈現(xiàn)了相對緩慢的變化，增長幅度僅為并發(fā)量增長幅度的[110]。這表明HBase滿足當(dāng)下研究人員的訪問需求，展現(xiàn)出了卓越的并發(fā)處理能力。

3.3" MySQL與Hive、SparkSQL性能測試對比

在低溫系統(tǒng)數(shù)據(jù)的基礎(chǔ)上，進行不同數(shù)量級的數(shù)據(jù)采樣，并對數(shù)據(jù)進行了檢索性能測試以及分類聚合性能測試。這系列實驗旨在深入了解Hive和Spark SQL[16]在不同規(guī)模數(shù)據(jù)集下的處理性能，用以評估其在大規(guī)模數(shù)據(jù)集上的查詢和分類聚合表現(xiàn)。

考慮到Hive底層采用的是MapReduce分布式處理框架，該框架在Map和Reduce階段需要進行磁盤I/O操作。因此，在進行輕量級的數(shù)據(jù)檢索操作時，選擇將MySQL和SparkSQL進行對比，如圖12所示。結(jié)果顯示，在數(shù)據(jù)集不斷增大的情況下，MySQL的檢索速度呈現(xiàn)出與數(shù)據(jù)集倍數(shù)增加的趨勢，運行時間逐步延長；相反，SparkSQL在進行檢索時幾乎沒有明顯的速度減緩。

相對于進行簡單的檢索，在進行大規(guī)模數(shù)據(jù)集上的分類聚合時，性能挑戰(zhàn)更加顯著。通過對MySQL、Hive和SparkSQL在不同規(guī)模數(shù)據(jù)集下的分類聚合性能進行比較，發(fā)現(xiàn)MySQL在10萬及以下數(shù)據(jù)集規(guī)模下表現(xiàn)相對有優(yōu)勢；但隨著數(shù)據(jù)集規(guī)模倍增，其運行時間呈現(xiàn)出顯著的增長趨勢。相較之下，Hive和SparkSQL在更高量級的數(shù)據(jù)集上展現(xiàn)了更為出色的性能，盡管Hive底層使用的是MapReduce，略慢于SparkSQL。在數(shù)據(jù)集達到千萬級時，可能會面臨由于數(shù)據(jù)量超過HDFS數(shù)據(jù)塊大小而引起的集群節(jié)點間的數(shù)據(jù)同步和負載均衡開銷。但總體而言，Hive和SparkSQL相較于輕量級數(shù)據(jù)庫MySQL，在大規(guī)模數(shù)據(jù)集上呈現(xiàn)出更為卓越的性能。MySQL和Hive、SparkSQL分類聚合性能對比如圖13所示。

3.4" 數(shù)據(jù)可視化

在數(shù)據(jù)倉庫的建設(shè)中，數(shù)據(jù)可視化階段起到了至關(guān)重要的作用。本文選擇采用Superset作為數(shù)據(jù)可視化工具，以實現(xiàn)對數(shù)據(jù)倉庫中龐大而復(fù)雜數(shù)據(jù)集的直觀展示和深入分析。Superset的靈活性使得用戶能夠輕松創(chuàng)建交互式的儀表板和定制化圖表，以及應(yīng)用各種過濾器和參數(shù)，從而滿足不同用戶對數(shù)據(jù)的個性化需求。這一數(shù)據(jù)可視化階段的引入不僅提升了數(shù)據(jù)的理解和解釋能力，同時也為決策制定提供了更有力的支持。Superset可視化數(shù)據(jù)分析界面如圖14所示。

4" 結(jié)" 語

本文引言中指出了CAFe超導(dǎo)直線加速器樣機作為一個復(fù)雜的實驗裝置，其加速器控制系統(tǒng)面臨著海量的控制數(shù)據(jù)和數(shù)據(jù)管理的挑戰(zhàn)。傳統(tǒng)的數(shù)據(jù)存儲方式存在如數(shù)據(jù)分散、安全性差、處理分析效率低等問題。為了解決這些問題，本文提出一種基于Hadoop的數(shù)據(jù)安全存儲和高效處理體系，并將其應(yīng)用于加速器數(shù)據(jù)倉庫建設(shè)中。在此之后，具體講述了硬件架構(gòu)的配置和軟件的安裝，以及實現(xiàn)不同類型數(shù)據(jù)的ETL方案。針對當(dāng)前加速器場景下的具體PV變量，提出一個基于HBase的存儲方案，并進行了YCSB吞吐量測試。測試結(jié)果顯示該方案滿足多用戶訪問數(shù)據(jù)的需求。最后，本文基于加速器低溫系統(tǒng)的數(shù)據(jù)，在不同數(shù)據(jù)規(guī)模下對比了MySQL和Hive、SparkSQL的查詢和分類聚合性能。

綜上，本文通過基于Hadoop的大數(shù)據(jù)分布式處理架構(gòu)解決了加速器數(shù)據(jù)存儲和處理分析中的問題，并通過實踐和測試展示了其在加速器大數(shù)據(jù)處理分析中的潛力。這種數(shù)據(jù)存儲管理體系具有高效性、可擴展性和安全性，為加速器控制中心提供了更好的數(shù)據(jù)存儲和分析解決方案。

注：本文通訊作者為楊鋒。

參考文獻

[1] 詹文龍，徐瑚珊.未來先進核裂變能：ADS嬗變系統(tǒng)[J].中國科學(xué)院院刊，2012，27（3）：375?381.

[2] 趙紅衛(wèi)，徐瑚珊，肖國青，等.惠州加速器集群裝置及其未來發(fā)展[J].中國科學(xué)：物理學(xué) 力學(xué) 天文學(xué)，2020，50（11）：77?94.

[3] 蔣天才.雙熱窗耦合器研制及穩(wěn)定性問題研究[D].北京：中國科學(xué)院大學(xué)，2019.

[4] 汪柏帆，袁辰彰，蔡漢杰，等.CAFe DUMP前刮束器的設(shè)計研制[J].原子核物理評論，2022，39（3）：326?333.

[5] 沈文文.CAFe控制系統(tǒng)時序數(shù)據(jù)分析與存儲研究[D].北京：中國科學(xué)院大學(xué)，2023.

[6] 李嘉曾，韓利峰，李丹清，等.基于大數(shù)據(jù)平臺的EPICS歷史數(shù)據(jù)歸檔系統(tǒng)[J].核技術(shù)，2019，42（11）：92?98.

[7] 宋一凡.大科學(xué)裝置控制系統(tǒng)架構(gòu)和歷史數(shù)據(jù)存檔技術(shù)研究[D].合肥：中國科學(xué)技術(shù)大學(xué)，2019.

[8] 楚江濤.基于Hadoop的電商大數(shù)據(jù)分析系統(tǒng)的設(shè)計與實現(xiàn)[D].西寧：青海師范大學(xué)，2021.

[9] 蔡一鳴.面向BI平臺的大數(shù)據(jù)ETL系統(tǒng)的設(shè)計與實現(xiàn)[D].南京：南京大學(xué)，2021.

[10] 周健鈞.智能車站設(shè)備數(shù)據(jù)分析系統(tǒng)的設(shè)計與實現(xiàn)[D].廣州：廣東工業(yè)大學(xué)，2020.

[11] 楊力，陳建廷，向陽.基于HBase的工業(yè)時序大數(shù)據(jù)分布式存儲性能優(yōu)化策略[J].計算機應(yīng)用，2023，43（3）：759?766.

[12] 王斌.重離子加速器磁鐵電源用矩陣變換器的設(shè)計及研究[D].北京：中國科學(xué)院研究生院，2016.

[13] 陳思明.40T混合磁體外超導(dǎo)磁體電源柔性無功補償?shù)难芯颗c設(shè)計[D].合肥：中國科學(xué)技術(shù)大學(xué)，2017.

[14] 蔣葉林.基于HBase數(shù)據(jù)庫的時空大數(shù)據(jù)存儲與索引研究[D].昆明：昆明理工大學(xué)，2021.

[15] 熊文.大數(shù)據(jù)系統(tǒng)基準測試和性能優(yōu)化關(guān)鍵技術(shù)研究[D].北京：中國科學(xué)院大學(xué)，2018.

[16] 馮興杰，王文超.Hadoop與Spark應(yīng)用場景研究[J].計算機應(yīng)用研究，2018，35（9）：2561?2566.

作者簡介：趙子晨（1997—），男，山西晉中人，工程碩士，研究方向為加速器控制技術(shù)、大數(shù)據(jù)技術(shù)。

楊" 鋒（1975—），男，甘肅蘭州人，工學(xué)博士，高級工程師，研究方向為加速器控制技術(shù)、醫(yī)用重離子加速器控制技術(shù)。