基于混合架构的国产化大数据平台研究与应用

王新东 王一大 李昌盛 张亚威 郭 炜

中国联合网络通信有限公司济南软件研究院 济南 250100

引言

开源Hadoop平台在国内各领域应用广泛，但随着国产化芯片、操作系统、数据库等应用普及，Hadoop已无法完全适配国产化芯片和操作系统。现有大数据组件不能兼容传统X86主机和ARM主机，在麒麟操作系统中运行不稳定，且部分功能在麒麟操作系统中不适配，严重阻碍了国内大数据行业的发展。基于以上背景，本文研究了一种基于混合架构的国产化大数据平台，能够较好适配国产化芯片、操作系统等国产化组件。目前开源Hadoop平台仍存在以下几个问题。

1)分布式调度系统YARN调度功能不完善，资源无法复用。YARN的ResourceManager虽然支持Memory和CPU调度，但CPU资源调度功能不完善，且AppMaster无法复用资源，交互效率低[1]。

2)分布式存储系统HDFS存在单点故障问题。HDFS中所有Metadata操作均需要通过Namenode，数据量访问过大时，这种设计会成为系统中明显的单点故障源，影响Hadoop性能发挥，虽然引入Federation机制，使用多个独立NameSpace满足HDFS命名空间的水平扩展，但并未完全解决单点故障问题，在很大程度上制约了整个集群的扩展性和可靠性[2]。

3)海量数据处理场景受限，元数据不统一，缺少权限安全管理。应用开源Hadoop体系使我们从底层架构受制于人，无法满足海量数据处理场景，元数据不统一，无法进行全局的数据仓库规划，数据安全各自为战，缺乏权限安全管控[3]。

4)开源Hadoop平台无法实现高效存储、处理大量小文件[4]。小数据处理过程中，会出现配置任务时间超出运行计算时间的情况，且在HDFS中，每个文件对应一个数据块，若存储大量小文件，系统会消耗Namenode大量内存来保护这些数据块信息[5]。

针对上述问题并借鉴国内外相关文献，本文提出一种基于混合架构的国产化大数据平台。一方面摆脱了底层架构受限问题，可以很好地适配国产化ARM主机和传统X86主机，且全部功能均适配国产化麒麟操作系统，性能稳定可靠；另一方面解决开源Hadoop平台调度系统不完善、交互效率低和单点故障问题。

1 基于混合架构的国产化大数据平台架构

本文主要研究了适配国产化ARM主机和麒麟操作系统的大数据平台架构，下面分别从分布式调度系统、分布式存储系统、统一元数据及安全体系、运维监控告警平台、一站式数据智能研发与综合治理服务、适配X86与ARM主机、适配Centos与麒麟操作系统、部署架构八大方面详细阐述基于混合架构的国产化大数据平台。其中基于混合架构的国产化大数据平台整体架构如图1所示。

图1 基于混合架构的国产化大数据平台整体架构图

基于混合架构的国产化大数据平台架构由7层组成，包括主机资源层、操作系统层、分布式调度与存储层、大数据组件层、计算引擎层、接口层、应用层。如图1所示，其底座是由X86主机或ARM主机的主机资源层组成，基于混合架构的国产化大数据平台既支持单独部署在X86集群上，也支持单独部署在ARM集群上，还支持在ARM集群跟X86集群进行混合部署，实现了资源重复利用，部署更加灵活；上一层是操作系统层，包括Centos操作系统与麒麟操作系统，基于混合架构的国产化大数据平台既支持单独部署在Centos操作系统上，也支持单独部署在麒麟操作系统上，还支持混合部署，实现了平台的可移植性；在操作系统层之上为分布式调度与存储层，包括分布式调度系统及分布式存储系统，用于存储底层数据、调度任务作业等；分布式调度与存储层之上为大数据组件层，能够支撑多种大数据组件，包括HDFS、YARN、HIVE、HBASE、HUDI、FLINK等；大数据组件层之上为计算引擎层，基于混合架构的国产化大数据平台支持多种计算引擎，包括SQL、MapReduce、机器学习等；计算引擎层之上为接口层，基于混合架构的国产化大数据平台不仅支持RESTful API接口接入，也支持RPC API接口接入，同时兼容Java SDK、Python SDK、JDBC、Console等工具供开发者使用；接口层之上为应用层，目前已开发的应用有一站式数据智能研发平台、统一元数据及安全系统、运维监控告警平台。

应用层中研发了一站式数据智能研发平台，封装了一系列操作，提供了统一的数据建模、数据采集、数据加工、调度等一系列能力。通过研发统一元数据及安全系统，基于混合架构的国产化大数据平台将所有元数据统一管理，有助于进行全局数据仓库规划；基于混合架构的国产化大数据平台将具备完善的安全体系，Capability机制、沙箱、IP白名单、多租户管理、数据分级打标、项目保护模式等可独立做数据权限管理。研发运维监控告警平台，实现了对基于混合架构的国产化大数据平台中集群、主机、项目、服务的全方位管控。

1.1 分布式调度系统

分布式调度系统主要负责任务调度与资源管理，目前常见的三种分布式调度系统主要有Hadoop MR、YARN、Mesos，它们均存在较多问题，Hadoop MR规模扩展存在瓶颈，容错性差，不利于功能扩展，可靠性差，资源利用率低；YARN的ResourceManager虽然支持内存和CPU调度，但CPU资源调度仍需完善，且AppMaster无法复用资源，交互效率低；Mesos计算框架只能被动接受Resource Offer，不能精确描述资源需求，且一次资源分配需要两次通信交互，调度效率低，不支持资源抢占等问题[6]。

在此基础上，研发了一种分布式调度系统，由资源调度和任务调度分离两层架构组成。本文提出通过资源调度器和agsou结构解决分布式调度中资源调度问题，将每个计算任务的APP Master及一组APP Worker组合起来解决分布式调度中的任务调度问题，其架构如图2所示。

图2 分布式调度系统架构图

Client负责接受用户请求；APP Master负责向资源调度器申请/释放资源，调度APP Worker到集群节点，分配Instance、APP Worker数据传输，管理APP Worker生命周期，故障重启等；APP Worker负责接收Instance，执行用户计算逻辑；agsou负责收集每个机器的硬件资源(CPU、Memory、Disk等)，发送给资源调度器；资源调度器作为中控节点，负责整个集群的调度。

集群部署完毕，分布式调度系统操作步骤如下：

1)用户通过Client向资源调度器提交计算任务；

2)资源调度器选择一台agsou启动计算任务对应的APP Master；

3)APP Master向资源调度器提交资源申请，资源调度器经过资源调度，将结果返回给APP Master；

4)APP Master进行任务调度，决定计算任务适配的机器，并将计算任务发送给对应机器上的agsou进程；

5)agsou接受命令，从程序包管理器中下载对应程序并解压，启动用户APP Worker；

6)APP Worker根据配置信息读取文件存储系统中的数据进行计算，并将计算结果发往下一个APP Worker。

本文提出的分布式调度系统相比现有的分布式调度系统有明显优势，包括：资源调度器扩展性强，针对不同任务在APP Master中可通过心跳监控选择不同调度策略，实现了负载均衡；通过对开源组件Ambari进行优化，实现了YARN、Zookeeper的复用，以支撑多种计算框架，达到资源复用的效果，提高了资源交互效率；分布式调度系统支持集群节点超大规模，水平扩展，能够支撑2000台大数据节点规模，另外支撑集群节点扩缩容；通过借鉴HDFS HA思想，对每个角色都部署多个节点，同时主节点与备节点保持心跳通信，以达到主节点发生故障可随时切换备节点，同时数据不丢失，实现了分布式调度系统的高容错性，任何角色故障不影响任务执行。

1.2 分布式存储系统

在超大规模分布式集群中，小概率故障成为常态，可能带来“雪崩效应”[6]。本文提出了一个稳定可靠的分布式存储系统，设置3个不同角色负责管理不同事务：元数据服务器(Master)、数据存储服务器(ChunkServer)、客户端(Client)，解决了集群小概率故障问题，同时确保数据具有强一致性、安全性、可靠性、可用性。分布式存储系统架构如图3所示。

图3 分布式存储系统架构图

Client负责接受用户请求，部分用户偏向高性能，部分用户偏向大存储，针对用户不同需求，系统采用多线程同步，同时支撑不同用户。Master负责管理整个存储集群的元数据，采用Paxos选主，而非Zookeeper的外部服务，支撑海量存储稳定运行。ChunkServer负责磁盘管理，将闪存和机械硬盘相结合，数据前台先写入闪存，后台转储到机械硬盘上，实现了在关键节点使用闪存以代替全部使用闪存的方式，解决了存储皆使用闪存导致存储成本高的问题。

数据高可用：由于对外服务器数量固定，单纯增加服务器数量无法实现数据的高可用，将目录树分割成volume，通过不同volume实现Master水平扩展，保证了数据高可用。

数据高可靠：分布式存储系统中，采用多副本机制，设置多副本位于不同故障域，当有数据节点故障时，Master就会发起复制机制，在ChunkServer间复制数据，保证了数据高可靠。

数据完整性：在小概率事件下，内存或磁盘存储的数据可能会发生改变。每段数据后面设置循环冗余校验(CRC)，进行数据周期性扫描，若发现数据与CRC无法匹配，则认为此段数据发生了位反转，此时采用完整副本覆盖发生位反转副本，保证了数据完整性。

1.3 统一元数据及安全体系

基于混合架构的国产化大数据平台将元数据统一管理，提供了项目元数据视图和作业历史视图，可查看元数据，使用历史数据、项目内的作业历史等信息。为管控元数据安全查看，设置用户访问权限，若项目内其他用户或角色需要查看时，需申请授权。

基于混合架构的国产化大数据平台提供完善的安全管理体系，主要包含用户及授权管理(负责用户认证、用户管理、授权、角色管理及权限查看)、列级别访问控制(设置安全策略，对敏感数据划分等级，实现用户对列级敏感数据访问)、数据下载权限管控、项目空间安全配置(支持多种正交授权机制，定制鉴权模型)、项目空间数据保护(自行设置数据保护机制，防止敏感数流出)、IP白名单(限制白名单以外设备访问项目空间)等。

1.4 运维监控告警平台

运维监控告警平台是为基于混合架构的国产化大数据平台研发的运维管控平台，支持从业务、集群、服务和主机维度对大数据组件进行运维管理。

1)业务运维

业务运维功能包括项目管理(负责展示项目列表及项目详情、元仓资源授权、数据存储加密、容灾查看及切换、项目迁移)，队列管理(负责展示、新增及修改项目队列、查看详情)，作业管理(展示集群所有作业、查看运行日志、终止作业)。

2)集群运维

集群运维功能包括集群概况(CPU、磁盘、内存、服务状态、LOAD、PACKAGE等运行信息)、集群健康管理(查看集群检查项)、机器列表(展示集群主机信息)。

3)服务运维

服务运维包括控制服务运维、分布式调度系统运维、分布式存储系统运维和数据通道运维。控制服务运维主要负责查看服务总体运行状态，查看服务检查项及详情，查看服务元仓状况，启停服务，采集服务日志。分布式调度系统运维主要监控分布式调度系统的关键运行指标(服务状态、CPU和内存使用情况、计算节点使用情况等)、分布式调度系统健康状况管理(检查项、检查状态等)、分布式调度系统队列管理。分布式存储系统运维主要管理关键运行指标、健康状况、存储节点和服务实例(展示分布式存储系统的Master主机和服务角色信息)。数据通道管理数据流量分析。

4)主机运维

主机运维功能包括主机概况(展示集群中主机信息、运行健康、以及机器CPU、内存、存储、负载等信息)，主机健康管理(查看主机检查项及详情)，主机服务(查看主机所属集群、主机运行服务实例等)。

除此之外，运维监控告警平台还支持对大数据组件自定义监控告警，当指标超出设定阈值，监控系统会通过短信、钉钉、电话等多种形式自动向运维人员发送报警信息，通过监控大盘界面也可实时观察监控指标变化。

1.5 一站式数据智能研发与综合治理服务

一站式数据智能研发与综合治理服务是集ETL、数据质量检测、智能调度和数据血缘管理于一体的全方位多功能平台，与基于混合架构的国产化大数据平台深度集成，支持多种计算和存储引擎服务。

1)数据集成

在复杂网络环境下，异构数据源之间数据传输与同步困难，数据集成模块是一个可跨异构数据进行数据传输的稳定、安全可靠的数据同步平台。数据集成模块包括离线和实时数据同步两种方式，不仅提供不同网络环境下全量或增量数据同步，而且提供批量创建同步任务，实现数据库内所有表批量上传到基于混合架构的国产化大数据平台中，提高了工作效率。

2)数据开发

数据开发模块支持开发、生产相隔离，提供了更稳定、更可靠的生产环境。数据开发模块还支持开发者自主组合SQL、MapReduce、Flink和机器学习等各项任务的混编工作流，实现分钟级调度、逻辑控制等。除此以外，开发者可以从业务角度管控工作流，将同类型业务组织为解决方案，实现沉浸式开发。

3)数据质量检测

数据质量检测支持多种异构数据源的质量校验、通知及管理，支持基于混合架构的国产化大数据平台数据表和实时数据流。

4)智能调度

智能调度模块通过设置调度参数、时间属性、资源属性、调度依赖等不同调度配置实现强大的调度功能，支持通过时间属性和调度依赖配置进行任务触发，时间属性包含实例生成方式、调度类型、重跑属性及调度周期等配置。调度依赖即上游节点输出作为下游节点输入，形成依赖关系，防止下游节点调用上游数据时，上游数据未正常产出而影响下游节点运行。同时，智能调度模块支持按月、周、小时和分钟等多种调度周期配置，支持每日千万级别任务调度，可通过DAG图准确、准时地运行。

5)数据血缘管理

数据血缘管理是在元数据基础上提供数据目录管理模块，支持全局数据检索、查看元数据详情、血缘管理等功能，让数据资产尽可能在组织内被更好地共享、发现，从而提升数据使用率、降低数据重复率。元数据接入时，可通过数据血缘管理服务对基于混合架构的国产化大数据平台引擎直接进行表元数据管理操作，也可以对不同数据源的元数据导入数据血缘管理服务中统一管理。通过血缘管理可视化节点的依赖关系图和内部血缘图，方便研发人员快速清晰地理解数据生成路径。

1.6 适配X86与ARM主机

开源大数据平台为原生HDP大数据平台，主要包括Ambari管理平台以及各大数据服务组件(HDFS、YARN、HIVE等)。而国产化平台采购的主机主要包括X86架构主机和ARM架构主机。我们需要解决HDP大数据平台在这两种机型的安装，以便实现两种机型的混合部署，从而规避产业链中潜在的卡脖子风险。

适配主机的本质，就是将HDP大数据平台的rpm安装包中的各类文件，如jar包文件、静态链接库文件(.a)、动态链接库文件(.so)、二进制执行文件、配置文本文件等，以及这些文件的目录层级关系安装到所适配架构的主机上。

1.6.1 X86主机适配

由于HDP大数据平台官网提供针对X86芯片的安装包，因此针对X86芯片主机并不需要做单独适配工作，经测试可以直接使用官方提供的X86安装包在X86主机上进行安装使用，性能与Intel X86并无明显差异。

1.6.2 ARM主机适配

针对ARM芯片，由于其芯片架构与X86有较大差异，因此在该芯片架构上安装HDP大数据平台，需要专门适配，基于混合架构的国产化大数据平台基于原生HDP大数据集群，包括Ambari管理平台以及各大数据服务组件(HDFS、Yarn、Hive、HBase等)。

本次rpm包的架构适配实际上是rpm安装包中静态、动态链接库和二进制执行文件的适配，即通过将同版本源码在需要适配的架构上(本次适配的是采用arm v8的linux aarch64架构)进行编译，得到的编译产物就是对应架构的安装包。

本次编译过程总体分为三大步，具体如下。

1)安装编译前置依赖，如rpm-build、gcc-c++、python-devel、gulp、git等。

2)安装编译工具，如phantomjs、frontend-mavenplugin、leveldb/jni等。

3)Ambari源码编译。从官方下载源码后需要将部分pom文件中的X86和amd64修改为arm和aarch64，以适配ARM芯片架构，涉及的文件列表如下：

#将noarch改为aarch64

ambari-logsearch/pom.xml

ambari-funtest/pom.xml

ambari-metrics/ambari-metrics-grafana/pom.xml

#将amd64或i386 amd64改为arm64

ambari-agent/pom.xml

ambari-logsearch/pom.xml

ambari-server/pom.xml

contrib/views/ambari-views-package/pom.xml

ambari-client/python-client/pom.xml

ambari-shell/ambari-python-shell/pom.xml

#将X86改为aarch64

ambari-agent/pom.xml

ambari-metrics/ambari-metircs-assembly/pom.xml

ambari-server/pom.xml

修改芯片架构参数后仍需要按照上述2步安装的依赖与编译工具版本修改对应pom文件中的版本号，涉及的文件列表如下：

ambari-logsearch/pom.xml

ambari-funtest/pom.xml

ambari-metrics/ambari-metrics-grafana/pom.xml

ambari-metrics/pom.xml

ambari-admin/pom.xml

最后需要将ambari-web/package.json中的emberhandlerbars-brunch修改为github，链接如下：

“ember-handlerbars-brunch”:“git://github.com/ember-handlerbars-brunch.git#540127137296a 09601cbd215dcf4da4d27bcfb9e”

以上配置修改完后即可完成编译，rpm包将会存储在对应target路径下。

1.7 适配Centos与麒麟操作系统

在操作系统层面主要使用了Centos操作系统与麒麟操作系统。我们的目标是不仅实现大数据平台在这些操作系统上安装，还要实现混合部署，以具备可移植性和灵活性。

针对Centos：开源HDP均在Centos主机上安装且十分成熟，因此大数据平台安装包无需更改即可平滑安装于Centos主机。

针对麒麟操作系统：由于开源HDP并未对麒麟操作系统进行兼容适配，需对ambari-agent下的相关脚本和配置进行修改，以完成对麒麟操作系统的适配，修改内容涉及以下几个方面。

1)配置操作系统校验，将Ambari agent校验中添加麒麟操作系统，需要修改操作系统校验相关脚本，路径为：/usr/lib/ambariagent/lib/ambari_commons/os_check.py。在207行添加：

elif _is_kylin_linux():

distribution = (“Centos”,“7.6.1810”,“LTS”)

意思为若操作系统判断为麒麟操作系统，则返回麒麟操作系统的版本。

2)按照适配的HDP版本号，固定安装脚本中的版本号信息。需要修改的脚本路径为：/usr/lib/ambari-agent/lib/resource_management/libraries/script/script.py和/usr/lib/ambari-agent/lib/ambari_commons/repo_manager/yum_manager.py。由于自行适配的版本针对3.1.0进行，因此将所有脚本中的版本号固定为3.1.0，防止出现yum自动安装时版本不一致的问题，其中script.py需要修改89行如下：

STACK_VERSION_PLACEHOLDER=“3_1_0_0_78”

yum_mamager.py需要修改yum_check_package_available函数，该函数的作用为在yum安装之前校验安装包是否存在，将版本校验部分逻辑修改为只校验3.1.0版本安装包，强行使安装包校验这一步通过，修改如下：

if name.find(“stack_version”) != -1:

name=name.replace(“${stack_version}”，“3_1_0_0_78”)

3)固定yum源地址。由于Centos和麒麟混部需求，因此自动化安装需要配置两套yum源，其中一套yum源为Centos版本，另外一套为麒麟版本，其中在麒麟版本安装时，将yum源校验这部分脚本代码修改为固定地址，即强行使麒麟主机安装各组件的过程通过设置单一yum源下载安装包，以解决麒麟版本对Centos版本yum源误扫描的问题，需要修改的脚本路径为：/usr/lib/ambari-agent/lib/resource_management/libraries/functions/repository_util.py。修改内容如下：

base_url=“http://{kylin-yumip:port}/HDP/Centos7/3.1.0.0-78”

1.8 基于混合架构的国产化大数据平台部署架构

1)基于混合架构的国产化大数据平台支持X86主机与ARM主机混合部署，其架构如图4所示。

图4 基于混合架构的国产化大数据平台X86与ARM混部架构图

本文提出的基于混合架构的国产化大数据平台既支持单独部署在X86集群上，也支持单独部署在ARM集群上，还支持在ARM集群跟X86集群进行混合部署，实现了资源重复利用，部署更加灵活。

2)基于混合架构的国产化大数据平台支持Centos操作系统与麒麟操作系统混合部署，其架构如图5所示。

图5 基于混合架构的国产化大数据平台Centos与麒麟混部架构图

本文提出的基于混合架构的国产化大数据平台既支持单独部署在Centos操作系统上，也支持单独部署在麒麟操作系统上，还支持Centos操作系统与麒麟操作系统混合部署，实现了平台的可移植性。

3)基于混合架构的国产化大数据平台支持跨机房部署，其架构如图6所示。

图6 基于混合架构的国产化大数据平台跨机房部署架构图

相比于开源Hadoop平台，本文提出的基于混合架构的国产化大数据平台支持跨机房部署，如图6所示，控制集群和计算集群均可以部署在不同机房，保证了集群的高可用。

2 基于混合架构的国产化大数据平台应用

为进一步分析基于混合架构的国产化大数据平台应用，本文通过TPCDS SQL性能实验、批量数据加工实验进行两组对比实验，分析开源Hadoop平台与本文提出的基于混合架构的国产化大数据平台的性能对比。

2.1 TPCDS SQL性能实验

对100台物理机资源部署集群平台，分别选50台机器部署开源Hadoop平台，50台机器部署基于混合架构的国产化大数据平台。集群部署正常且运行正常情况下，通过TPC-DS工具在集群上构建实验数据，规模为100TB TPC-DS实验数据。通过TPC-DS工具依次运行99条标准SQL，记录每条SQL执行时间，分别得到开源Hadoop平台和基于混合架构的国产化大数据平台运行99条标准SQL的整体耗时对比结果，如图7所示。

图7 TPCDS 99条SQL运行结果对比图

由图7可知，对2个平台分别运行了两次99条TPCDS SQL，整体耗时方面，基于混合架构的国产化大数据平台比开源Hadoop平台耗时缩短一倍，运行速度得到较大提升，说明本文提出的基于混合架构的国产化大数据平台优于开源Hadoop平台。

2.2 批量数据加工实验

分别针对基于混合架构的国产化大数据平台与开源Hadoop平台创建离线加工租户，均分配2560Hz的CPU资源、10T内存，建表并导入数据，其中包含6个数据库，涉及32张表，共计2.4T数据量，进行一系列数据加工流程：依次执行SRC→ODS加工流程，ODS→DWD加工流程，DWD→DWA加工流程，DWA→DM加工流程，并记录每个加工流程的耗时，分别得到基于混合架构的大数据平台和开源Hadoop平台对批量数据加工实验的整体耗时对比结果，如图8所示。

图8 批量加工流程整体耗时对比图

由图8可知，批量数据加工过程中，开源Hadoop平台整体耗时0.927小时，基于混合架构的国产化大数据平台整体耗时0.256小时，数据表明，本文提出的基于混合架构的国产化大数据平台运行效率更优。

3 结论

基于混合架构的国产化大数据平台通过对开源Hadoop平台进行改进，通过研发了一套分布式调度系统和分布式存储系统，一方面摆脱了底层架构受限问题，可以很好地适配ARM主机和传统X86主机，且全部功能均适配麒麟操作系统，性能稳定可靠；另一方面解决开源Hadoop平台调度系统不完善、交互效率低和单点故障问题。通过统一元数据及安全管理体系，将元数据统一规划，节省存储费用，提高安全管控能力。并通过业界通用的TPCDS SQL实验及批量数据加工实验，证明了基于混合架构的国产化大数据平台具有一定的可行性及有效性。

基于混合架构的国产化大数据平台还有很多地方需要改进，由于本文特定场景的需求并没有引入其它实时业务场景，在今后的研究工作中将引入实时场景进行多项验证，探索能否形成一套通用平台，既可应用于离线大数据任务也可应用于实时大数据任务，以便应用于不同生产系统，从而大大提高平台的灵活性。