Alluxio助力中国联通构建高效Spark计算服务平台

最新推荐文章于 2023-10-19 09:40:18 发布

Hadoop技术博文

最新推荐文章于 2023-10-19 09:40:18 发布

阅读量338

点赞数

640?wx_fmt=gif

作者简介：张策，2017年5月进入联通软研院Spark项目组实习，2018年7月从北京交通大学软件学院毕业，并正式加入软研院。目前担任Spark研发工程师，负责Spark，Alluxio等相关系统的运营、优化；租户Spark任务的优化；以及自研系统的研发工作。

640?wx_fmt=gif

1 前言

中国联通是世界上最大的电信运营商之一，也是移动通信，固定通信，宽带接入和各类电信增值服务的引领者。中国联通软件研究院是中国联通下属的软件研发公司，主要承担中国联通业务支撑系统、大数据平台的研发工作，以及前瞻性技术的研究与应用。4G以及即将到来的5G对数据的处理能力提出了巨大挑战，以Alluxio为重要组成部分的新一代分布式技术架构走进了我们的视野。

中国联通传统的业务系统架构主要由IBM小型机、Oracle数据库、和EMC存储设备组成。伴随着中国联通业务的飞速发展，用户量快速增长，传统架构已无法满足业务需求。随后引进的Hadoop生态系统架构以及Greenplum数据库对海量数据处理性能仍然难以满足所有的业务场景的需求。为了满足日益发展的业务需求，基于多样化场景的、烟囱式的、分散的计算应用模块大量涌现，这使得现有计算平台呈现碎片化的趋势，缺乏高效复用能力，资源利用率不高，从而造成了计算资源的浪费和处理效率的低下。

为了解决上述问题，我们引入了以Apache Spark与Alluxio为核心的新型大数据技术生态体系，规划构建统一的、以内存为中心的分布式数据处理平台，集中平台资源，提升大数据平台的计算能力。

2 系统平台架构

我们基于Alluxio的系统平台架构如图1所示。

640?wx_fmt=jpeg

图1.平台架构

平台根据业务的性能要求和计算特点，基于独立的物理机集群提供批处理服务，并且基于联通容器化平台“天宫”提供流处理服务。

批处理服务所承载业务的原始数据主要存储于Oracle和DRDS（分布式关系型数据库系统）中。这些数据通过数据交换中心抽取至批处理集群后，再由Hive进行ETL，最后存储至Alluxio中。批处理业务运行的常规处理流程包括：首先读取Alluxio中的parquet文件注册成Spark临时表，然后运行SQL语句，将中间结果以及最终结果写回Alluxio。待计算任务完成后，将结果数据备份到Hive，最后将结果发送至下游处理系统。

流处理服务所承载业务的原始数据存储于Kafka中。这些数据经过流处理任务消费后，采用Alluxio存储检查点，经过计算后写入下游的Redis和HBase中。由于业务侧使用的Kafka版本有所差异，任务使用Spark Streaming（DStream）和Structed Streaming两种流计算处理引擎。

3 Alluxio发挥的作用

Alluxio是源于UC Berkeley AMPLab的基于内存存储的开源大数据分布式文件系统。关于Alluxio的更多介绍，可以参考官网上的文档：https://www.alluxio.org/docs/1.8/en/Overview.html。在我们平台的整个处理流程中，Alluxio发挥了如下作用：

统一命名空间

如上文所述，批处理任务使用的原始数据大多来自于业务侧的Oracle和DRDS数据库。除此之外，有一部分特殊业务拥有独立的存储集群，这些业务的原始数据保存在其独立集群的HDFS中。因此有必要向用户提供统一的访问入口，并且尽可能避免使用耗时的数据抽取、复制的方式在集群中共享数据。Alluxio具有的统一命名空间的特性，支持对不同集群的HDFS路径进行挂载，用户可以通过Alluxio直接读写本地集群存储的数据。此外，Alluxio统一命名空间的透明命名机制消除了用户在使用此特性时的潜在障碍。 Alluxio统一命名空间的示意图如图3-1所示：

640?wx_fmt=jpeg

图3-1 Alluxio统一命名空间的示意图

关于更多Alluxio的统一命名空间的用法，可以参阅Alluxio的官方介绍：http://www.alluxio.org/docs/1.8/en/advanced/Namespace-Management.html

提升数据读写速度

Spark从Hive中读写数据通常需要花费大量时间。经过ETL后Hive表内的小文件较多，且分布不均匀。在这种场景下，Spark直接从Hive中读取数据进行关联计算容易造成数据倾斜，降低计算速度，增加任务失败的概率。在我们的实验中，100G以上量级的数据由Spark导出至Hive的速度十分缓慢，某业务侧将数量级为TB的计算结果导出至Hive平均耗时30分钟。在利用了Alluxio之后，将结果数据导出至Alluxio平均耗时4分钟，这7.5倍的提速，极大地提升了结果数据导出的性能。

下表以40G数据读取、写入HDFS的平均性能为例展示Alluxio带来的数据读取性能提升：

表3-1 Alluxio数据读取性能提升展示表

640?wx_fmt=png

如上表所示，Alluxio提升了数据读取速度，降低了GC时间，极大地提升了系统的数据读取性能。

加速查询业务

平台承载的业务中包含报表类业务。此类业务的特点是一次计算多次查询。Alluxio内数据的副本数目会随着数据访问的热度而提升，并且尽可能的与计算节点的物理位置保持一致，从而提升数据读取性能。如下图所示，Alluxio能够有效地提升频繁查询的报表类业务的性能。

提升系统稳定性

Alluxio存储能够显著地提高Spark处理小文件多的任务以及读写海量数据时的稳定性，极大地降低读取失败的可能性。由于关联计算产生的数据倾斜无法避免，中间结果经常会产生大量的1000 KB左右的小文件。这些小文件夹杂在100 MB左右的大文件中，直接从HDFS上读取这些数据参与后续关联计算容易导致Spark任务失败。将这些中间结果储存在Alluxio中能够极大地降低Spark任务的失败概率。在我们的应用场景中，通过Alluxio存储的方式能够将每个业务周期内Spark任务的平均失败个数降成功到1以下，从而保障了任务执行的稳定性。