EventDB: 基于NoSQL的高能物理事例管理 程耀东 中科院高能所计算中心 chyd@ihep.ac.cn 2016-9-19

大规模半结构化数据管理关键技术及系统 科学大数据管理系统：课题四 问题 主要 内容 研究 目标 如何实现万亿级事例数据的高效管理和处理？ 面向事例的大规模半结构化数据模型和存储结构 面向事例的大规模数据多维特征索引结构和查询技术 面向事例数据处理的并行与性能加速技术 与现有系统对接的数据服务接口标准与规范 主要 内容 研究 目标 大规模半结构化数据管理关键技术 高能物理事例数据管理系统 能实现对万亿级高能物理实验事例的管理，同等TCO条件下，典型场景应用（以的J/ψK+ K- π0衰变分析为例）性能提高50%（1400个/秒 2100个/秒）。

研究思路 万亿级事例 数据库 本项目：基于事例的数据管理 传统方式：基于文件的数据管理 基于单域的事例文件管理 跨域的事例数据管理 基于文件的事例读取与分析 基于事例的并行处理 基于文件的事例过滤和筛选 基于数据库的事例过滤和筛选 事例特征抽取 传统文件--》事例半结构化 事例索引、检索、缓存 事例文件 事例文件 事例文件 事例文件 传统方式：基于文件的数据管理 本项目：基于事例的数据管理

系统组成部分 新开发 EventDB (hbase) 事例基本信息：RunID, VersionID, EventID 物理变量：TAG 文件信息： FileID 事例索引 部分 文件基本信息：FileID 文件位置： SITE, PATH 物理意义：RunID, conditions, … FileDB (hbase/RDMS) ESD/DST: reconstructed hits, Reconstructed objects (tracks, vertices, jets, electrons, muons, etc.) ; Used by all Early Analysis, and by some detailed Analyses AOD: Reconstructed objects (tracks, vertices, jets, electrons, muons, etc.); Possible small quantities of very localized hit information; Used by most Physics Analysis TAG: event-level metadata for fast search and selection in a database; Self describing data, can be processed without any experiment code 文件索引/数据集 已有 事例文件 RAW, ESD/DST, AOD, TAG, … 事例文件 RAW, ESD/DST, AOD, TAG, … 分布式文件系统 Site A Site B

事例索引 为每个事例创建索引 调用NoSQL的接口，写入数据库 引入TagSet 实验组定义TAG组成 扫描DST等文件或者重建完成后产生索引信息 EventID, RunID, VersionID, FileID, TAG EventID是否可以作为唯一Event的唯一标识符？ 调用NoSQL的接口，写入数据库 数据库建立多维索引 引入TagSet 单个用户在条件查找后，产生的结果生成一个TagSet，TagSet支持命 名，内容包含多个EventID 用户通过接口方便列出自己的“TagSet”，查看TagSet的基本属性， 比如事例数、事例的查询条件等 TagSet可以作为分析程序的输入参数 用户修改分析算法后，重用TagSet，不需要多次筛选事例 用户生成的样本不需要真正存储，节省空间 Event1 Tag1 Event2 Tag2 TagSet1 Event3 Tag3 TagSet2 Event4 Tag4

文件索引 数据集、File Catalogue、Bookkeeping 记录文件逻辑名（UUID）与物理名（Site:PATH）的对应关系 真实数据、模拟数据及其元数据 物理意义：刻度常数、运行状态、软件版本等 记录文件逻辑名（UUID）与物理名（Site:PATH）的对应关系 ATLAS、CMS等大型实验都开发了自己的数据集管理系统 ATLAS: AMI (Atlas Metadata Interface), DQ2 (Distributed Data Management) CMS: Global DBS (Dataset Bookkeeping Service) 挑战 物理路径可能会改变 所有产生的文件都需要与bookkeeping系统接口 任何的文件删除与移动都需要通知bookkeeping 文件数目与并发都很大，性能和可扩展性 一致性问题 如何解决 File Catalogue的功能，首先建立逻辑文件名与物理文件名的关系？ 自动扫描分布式文件系统，填充基本的bookkeeping信息？？

事例管理服务 基于事例索引和文件索引及文件存储建立事例索引服务 主要功能 主要提供如下几个接口 TAG管理 TAGSet管理 分布式文件管理、Bookkeeping管理 事例的缓存、传输与并行处理 主要提供如下几个接口 事例TAG创建/修改/删除接口： 管理员调用 事例TAG查询接口： 普通用户调用 事例ID到物理文件名的转换： 普通用户调用 TAGSet创建/查询/删除接口： 普通用户调用 TAGSet到物理文件名转换： 普通用户调用 物理分析程序Wrapper： 普通用户调用

主要功能组件 FileDB EventDB 用户分析脚本 数据传输服务器 Wrapper (eg TagBoss, …) 事例传输 并行传输 分块传输 xrootd FUSE EventDB Client 事例缓存 数据传输客户端 事例缓存 分布式文件系统 主站点 远程站点

用户使用流程 用户编写分析程序的脚本，筛选事例或者调用物理软件的Wrapper。这 个Wrapper支持以TagSet作为参数 Wrapper得到TagSet后，转换成包含Event的Root文件 得到EventID：通过EventDB Client查找TagSet对应的EventID列表 得到文件列表：将EventID列表作为参数调用数据传输客户端 数据传输客户端的工作 1）首先查找本地缓存，如果有缓存，就把缓存文件的路径返回给Wrapper 2）如果没有该EventID发到远程的数据传输服务器。 远程数据传输服务器的流程 查看调用者是否是“本地”，即是否是同一个站点，如果是同一个站点就将缓 存文件，或者直接调用FileDB得到包含EventID的文件路径发给数据传输客户端 如果调用者是“远程”，则从FileDB中得到包含EventID的文件，并从中抽取出相 应的Event，组成新的root文件，将文件内容发送到数据传输客户端。 3）判断远程传输服务器发送过来的是文件名还是文件内容，如果是文件名直接返回 给上层；如果是文件内容，则接收文件保存到本地缓存中，并把文件名返回给上层 Wrapper按照原有的模式调用物理软件，比如boss.exe，所有参数均不变 化，不需要任何修改，通过xrootd或者fuse直接访问文件

物理软件框架扩展 BOSS BEAN NuWa LoadStar EventDB Services 用户分析程序（筛选事例、数据分析…） 支持面向事例管理的功能 BOSS BEAN NuWa LoadStar 接口调用：1) Tag/TagSet管理； 2) 基于事例的数据传输 EventDB Services 需要标准化Event Services的接口 Event Service类似于一个中间件，物理软件框架类似于它的APP

方案的说明 独立于物理框架软件，用户可以直接调用 后期EventDB Services形成标准的接口，发布SDK，各个物理框架 软件可以集成该功能 为什么要使用EventDB Services？ 筛选事例快 基于事例的SSD高速缓存，访问快 基于事例的传输，传输快 远程透明调用，使用灵活 支持MPI并行处理？？