0 引言
大型对撞机在高能物理研究中扮演着至关重要的角色,它是探索新粒子的关键工具。大型对撞机产生的数据量巨大,这些数据具有多样性、高维度和高吞吐量的特性。如北京正负电子对撞机重大改造工程(BEPCII) 已经累积了 10 PB 的实验数据,并且数据量还在不断增加[1] 。高能物理研究工作正是基于大型对撞机产生的海量数据。
当前,高能物理实验的规模通常很大,需要成百上千位科学家参加。处理这些数据则需要借助大型集群系统。构建这样的集群系统,一般采用市面上可采购的廉价的 CPU 、主板、存储设备、网络设备。
粒子在高能物理实验的探测器中的运动过程被捕获,产生了大量的电子学信号。然后,通过触发判选和在线选择的事例,由在线数据获取系统(data acquisition , DAQ)以二进制文件的形式记录下来。这种数据被称作原始数据。对原始数据进行刻度和重建后,生成重建数据,供物理分析使用。
物理学家通常选择特定的数据集进行分析,批处理作业在多个合适的计算节点上运行,持续时间可能达到数小时甚至数天。批处理作业的状态信息(包括资源消耗、运行时长等)对于系统管理人员和物理学家来说都非常重要。系统管理人员可以利用这些状态信息提高资源利用率,而物理学家可以预期作业完成时间或发现作业异常,从而改进分析方法。
为物理学家提供定制的可视化界面,帮助他们直观了解作业状态和运行时间等信息,以及存储资源和计算资源的使用状况,可以提升研究效率和质量。另一方面,物理学家更有效的利用系统资源,也能减轻计算机集群在存储和计算方面的压力。
1 研究背景
1.1 高能物理大型集群系统
国家高能物理科学数据中心由中国科学院高能物理研究所建设和运行,主要由北京数据中心和大湾区分中心组成,以高能物理领域科研活动中产生的科学数据为核心实现数据资源、软件工具、数据分析等资源能力的汇交和共享[2]。
国家高能物理科学数据中心的计算环境如图 1 所示,其核心是一个高速、高可靠的网络子系统,其它子系统连接到这个核心网络上,包括前端登录集群、海量存储系统、计算节点集群、备份与分级存储系统、管理系统等。不同的子系统具有不同的功能和配置,功能上相互独立,整体上协同工作。
图 1 典型的高能物理计算环境及其组件
为了满足用户更精细的需求,同时进一步提高系统性能,在这些子系统的基础上,衍生出更多的子系统。
1.2 作业批处理
高能物理数据以非结构化数据为主。
高能物理数据分析是典型的数据密集型计算。计算集群把一组计算机通过高速网络连接在一起。从作业流程来看,可以分为用户交互节点、计算节点、存储节点、资源管理节点、作业调度节点等[3]。
高能物理数据分析,具体而言就是高能物理学家使用开发的算法或分析程序对一组数据文件进行处理。这些数据文件,通常在逻辑上被划分为一个数据集。分析程序被调度到多个合适的计算节点上,持续运行数小时、甚至数天,通常这样的分析程序被称为批处理作业。因此数据存储管理和作业调度是两个重要的侧面。
作业批处理系统的主要组件如图 2 所示,作业批处理系统与用户交互的控制信息,包括用户的作业脚本、命令参数、作业执行结果、错误信息、标准输出等。通常这类信息以文件的形式存在,便于用户随时查看。但是这类控制信息文件并不被存储系统管理。
图 2 作业批处理系统框架
1.3 问题与讨论
高性能计算环境提供给用户的使用方式主要包括命令行(command line)、图形用户界面(GUI)和网站门户(Web portal)3 种。命令行方式操作灵活、功能全面,但需要用户具备较高水平的编程能力。PBS 作业调度系统中用户使用 qsub 命令查看作业状态如图 3 所示, GUI 方式的用户交互方式极少。基于 Web portal 的使用方式,由于其简单易用性,已经成为当前主流模式,如中国科学院超级计算环境、中国国家高性能计算环境、美国 TeraGrid Portal群等都使用这种方式。
图 3 PBS 作业调度系统中使用qsub 命令查看作业状态
批处理作业的状态,包括资源消耗、运行时长、数据集、提交人、提交时间等信息。
在用户有大量作业提交的情况下,往往难以弄清楚作业的状态,尤其是资源的使用情况,对多个作业的整体概况更难以理清。
系统管理人员可以利用这些状态信息进一步提高资源利用率,但是需要进一步的分析,显然目前的交互方式缺乏这方面的功能。
2 可视化作业状态
2.1 数据的可视化趋势
数据的可视化是近年来的趋势,数据可视化可以增强交互性、用户体验。通过实时更新数据和图表,用户可以更好地理解数据的动态变化,从而更准确的预测、发现隐藏的模式和趋势。
当前的数据可视化,面临的数据具有大规模、高维度、多来源、动态演化的特点。相应的,我们一般依赖两种主要的解决手段,数据转换和视觉转换[4] 。有鉴于数据的复杂性,在展示之前,我们一般会使用多种方式对数据进行简化。
ECharts(Enterprise Charts)是国内的一款非常优秀的可视化图表控件,它底层依赖轻量级的 Canvas 类库 ZRender,提供直观、生动、可交互、可高度个性化定制的数据可视化图表。 ECharts 的设计是面向数据的,基于数据来驱动图形的生成,通过改变数据来改变图表的表现形式[5]。
2.2 用户及作业
对于一个自上世纪 90 年代持续演化的系统,作业管理系统、用户、作业的基本属性保持稳定,如研究室、课题组等;也有演化的因素,如引入了 GPU 资源。因此,我们抽取出两个相对稳定的核心要素:用户、作业,尽量对齐这两个要素的属性。
用户的属性从管理系统中的用户表中抽取基本信息,并从其他子系统抽取课题信息、数据集、存储配额等信息。作业信息抽取自作业管理系统、存储管理系统,及集群实时状态信息。
2.3 数据汇聚
对于作业管理系统来说,一般仅在作业运行期间保存中间状态;作业完成,或者因错误中止后,持久化保存作业的输出、日志。作业运行过程中内存占用率、CPU 占用率、文件打开数等信息,需要二次开发代理(Agent)组件,实时收集并发送相关数据。
图 4 作业管理系统的计算节点中加入 Agent
作业的实时信息聚合到 InfluxDB 数据库中。InfluxDB 是一种业界广泛使用的开源时序数据库,使用 Go 语言编写,它的数据模型基于时间序列,时间戳作为索引,不支持对历史数据的修改,因此特别适合写多读少、无事务要求、海量高并发数据的持续写入、基于时间区间聚合分析和快速查询的场景[6]。
InfluxDB 数据库的一个常用的应用场景就是监控数据统计,即每毫秒记录一下计算机的内存、CPU 等资源的使用情况。
图 5 数据汇入 InfluxDB 数据库
2.4 数据展示
集群系统的某段时间内的磁盘读写速率的聚合数据如图 6 所示,某段时间内系统已完成作业数的聚合数据如图 7 所示。
图 6 某段时间系统读写速率
图 7 某段时间内系统已完成作业直方图
3 用户行为分析
在此基础上,我们期望在以下方面发现深层的用户行为习惯:
(1)时间序列分析:作业提交、在运行作业、网络带宽、CPU 载荷、GPU 载荷等
(2)作业分类汇总:HPC(高性能计算,High Performance Computing)作业、HTC(高通量计算,High-throughput computing)作业
(3)研究课题分类汇总
(4)用户资源占用排名等
3.1 系统架构
该子系统采用多层架构如图 8 所示,主要采用 ElasticSearch 、InfluxDB 作为我们数据湖的核心组件。
Django 是一个强大的 Python 后端框架,能够快速构建可靠的 Web 应用,同时 Django提供 API 供前端获取数据。为了实现高效便捷的网页开发,本项目选择使用 HBuilder X 进行
图 8 系统层次结构图
我们注意到数据的来源比较复杂,大致可以分为三部分。首先,用户、组、实验组的关联信息数据存储在 CCS 系统(机房管理系统)中。有一部分作业相关的数据已经存储在计算中心的已有 ElasticSearch 存储系统中,可以直接读取。这部分可以直接复用。作业执行过程消耗的 CPU 、内存等资源的实时信息,由于作业、节点数目巨大,造成总体数据巨大,需要我们在集群的各个节点上根据需要实时采集[7][8]。
另外,系统的实时性要求体现在两个方面。用户点击页面之后,不能有明显的卡顿,否则影响用户体验。表面来看,这个过程和普通的Web 系统响应用户请求区别不大。但是集群资源相关的实时数据仍然分散在多个节点中,数据从集群节点到 Web 服务器,再到用户界面,都需要考虑延迟。根据经验,集群节点的数据采集,这个过程的时间延迟要保证在两分钟之内。
我们的数据湖汇集了多种类型的高能物理科研数据,其中包括实验数据、模拟数据以及分析结果等,我们在确保数据完整性和安全性的同时,也使得这些数据变得更加易于管理和使用。
3.2 数据实时采集
我们借鉴成熟的 ELK 框架,结合 Spark 的大数据采集、清洗技术,采用的流程处理数据如图 9 所示。
大型集群系统,一般使用 ELK 框架收集日志。该框架包括 Elasticsearch、Logstash、Kibana和 Beat 等开源软件。 日志以时间戳为索引存储在 Elasticsearch 数据库中。
图 9 在集群节点上采集资源使用信息流程
在这里,我们使用流处理工具 Kafka 连接 ELK 和 Spark 。打上时间戳的实时资源使用信息包装成消息,发送给 Kafka ,处理后的数据,被 Kafka 发送给 Logstash。
大型系统网络数据簇发、磁盘故障、软件错误、业务上的异常等原因,都可能造成数据损坏,因此这些资源使用信息,需要进行清洗。操作系统的版本不同、组件版本不同等各种原因,可能造成数据格式差异,属性命名各异,数据也需要转化、格式化为统一标准。
3.3 数据缓存
目前,系统中的 ElasticSearch 存储数据已达 800 多亿,数据检索时间长。我们进行了测试,直接使用 ElasticSearch 进行数据检索和聚合等操作的情况下,响应速度太慢。
我们设计了 InfluxDB 作为缓存数据库如图 10 所示,也就是 Logstash 同时把数据存储到ElasticSearch 和 InfluxDB 中。
图 10 InfluxDB 缓存 Elasticsearch 数据
在响应用户请求的时候,针对实时性要求高、频繁访问的数据,Web 服务器从 InfluxDB缓存中获取数据。其他情况下,则直接从 ElasticSearch 中获取数据。
3.4 用户作业分析
我们为用户及管理员提供多种图形化方式,展示作业运行状态、资源占用统计。为某个用户在一段时间内的统计数据如图 11 所示。从图中可以看到用户提交的是 HTC(高通量计算)类作业,排队的作业数持续下降、运行平稳,整体状况良好。这段时间,该用户没有提交 HPC(高性能计算)类作业,也就是说,该用户没有使用 GPU 资源。
图 11 用户某段事件作业运行状态、磁盘及文件统计
4 讨论与后续工作
我们通过收集集群系统的作业信息、节点负载信息、用户信息,在数据湖中进一步关联数据,为用户提供了直观可视化的作业运行信息,为系统管理人员进一步分析资源使用规律提供了方便的查询手段。
接下来,我们将进一步收集数据,努力提供用户预警信息,预测资源瓶颈及可能的时间段。
参考文献(References):
[1] 基于国产处理器架构的高能物理数据处理系统,程耀东 程垚松, 大数据期刊
[2] 2021-10-18 https://www.modb.pro/db/396955?utm_source=index_ai
[3] 国家高能物理科学数据中心, https://www.nhepsdc.cn/
[4] 高能物理实验的离线计算, 李卫东 石京燕, 现代物理知识 . 2016 ,28 (03)
[5] 大数据系统和分析技术综述, 程学旗 靳小龙, 软件学报 . 2014 ,25 (09)
[6] Apache ECharts, https://echarts.apache.org/zh/index.html
[7] InfluxDB , https://www.influxdata.com/
[8] 高能物理计算环境概述. 程耀东;石京燕; 陈刚.科研信息化技术与应用,2014(03)
[9] 基于 Elasticsearch 的实时集群日志采集和分析系统实现. 胡庆宝;姜晓巍;石京燕;程耀东;梁翠萍.科研信息化技术与应用,2016(03)35