干货 | ALLUXIO在携程大数据平台中的应用与实践

作者简介

郭建华，携程技术中心软件研发工程师，2016年加入携程，在大数据平台部门从事基础框架的研究与运维，主要负责HDFS、Alluxio等离线平台的研发运维工作。

进入大数据时代，实时作业有着越来越重要的地位，并且部分实时和离线作业存在数据共享。实践中使用统一的资源调度平台能够减少运维工作，但同时也会带来一些问题。

本文将介绍携程大数据平台是如何引入Alluxio来解决HDFS停机维护影响实时作业的问题，并在保证实时作业不中断的同时，减少对HDFSNameNode的压力，以及加快部分Spark SQL作业的处理效率。

背景

携程作为中国旅游业的龙头，早在2003年就在美国上市，发展到现在，携程对外提供酒店、机票、火车票、度假、旅游等线上服务产品, 每天线上有上亿的访问量，与此同时，海量的用户和访问也产生了大量的数据，这些数据包括日志以及访问记录，这些数据都需要落地到大数据平台上。

为了对这些数据进行分析, 我们在大数据方面有着大量的离线和实时作业。主集群已突破千台的规模, 有着超过50PB的数据量，每日的增量大概在400TB。巨大的数据量且每天的作业数达到了30万，给存储和计算带来了很大的挑战。

HDFS NameNode在存储大量数据的同时，文件数和block数给单点的NameNode处理能力带来了压力。因为数据存在共享，所以只能使用一套HDFS来存储数据，实时落地的数据也必须写入HDFS。

为了缓解和优化NameNode的压力，我们会对NameNode进行源码优化，并进行停机维护。而HDFS的停机会导致大量的需要数据落地到HDFS的Spark Streaming作业出错，对那些实时性要求比较高的作业，比如实时推荐系统，这种影响是需要极力避免的。

图1 携程大数据平台架构图

图1为携程大数据平台架构图，DataSource为不同的数据源，有日志信息、订单信息。它们通过携程自己研发的中间件或者直接落地到HDFS或者被Spark Streaming消费之后再落地到HDFS。

Streaming计算的结果有的直接落地到Redis或者ElasticSearch等快速查询平台，而有些Streaming计算的实时数据需要和历史数据进行再计算，则需要落地到HDFS上。

按照业务层不同的需求，我们提供了不同的执行引擎来对HDFS上的数据进行计算。执行快速的Spark SQL和Kylin主要用在OLAP上，Hive和Spark SQL同时用在ETL作业上，Presto主要用在adhoc查询。

上述架构能够满足大部分的工作要求，但是随着集群规模的增大，业务作业的增多，集群面临了很大的挑战，其中也存在着诸多不足。

上述架构存在以下几个问题：

1. SparkStreaming依赖于HDFS，当HDFS进行停机维护的时候，将会导致大量的Streaming作业出错。

2. SparkStreaming在不进行小文件合并的情况下会生成大量的小文件，假设Streaming的batch时间为10s，那么使用Append方式落地到HDFS的文件数在一天能达到8640个文件，如果用户没有进行Repartition来进行合并文件，那么文件数将会达到Partition*8640。我们具有接近400个Streaming作业，每天落地的文件数量达到了500万，而目前我们集群的元数据已经达到了6.4亿，虽然每天会有合并小文件的作业进行文件合并，但太大的文件增量给NameNode造成了极大的压力。

3. SparkStreaming长时间占用上千VCores会对高峰时期的ETL作业产生影响，同时，在高峰期如果Streaming出错，作业重试可能会出现长时间分配不到资源的情况。

为了解决上述问题，我们为SparkStreaming搭建了一套独立的Hadoop集群，包括独立的HDFS、Yarn等组件。

虽然上述问题得到了很好的解决，但这个方案仍然会带来一些问题。如果主集群想访问实时集群中的数据时，需要用户事先将数据DistCp到主集群，然后再进行数据分析。架构如图2所示。除了DistCp能够跨集群传输数据之外，我们第一个想到的就是Alluxio。

图2 独立集群架构: HDFS2独立与主集群HDFS1以提供资源隔离

Alluxio作为全球第一个基于内存级别的文件系统，具有高效的读写性能，同时能够提供统一的API来访问不同的存储系统。它架构在传统分布式文件系统和分布式计算框架之间，为上层计算框架提供了内存级别的数据读写服务。

如图3所示，Alluxio可以支持目前几乎所有的主流分布式存储系统，可以通过简单配置或者Mount的形式将HDFS、S3等挂载到Alluxio的一个路径下。这样我们就可以统一的通过Alluxio提供的Schema来访问不同存储系统的数据，极大的方便了客户端程序开发。

同时，对于存储在云端的数据或者计算与存储分离的场景，可以通过将热点数据load到Alluxio，然后再使用计算引擎进行计算，这极大的提高了计算的效率，而且减少了每次计算需要从远程拉去数据的所导致的网络IO。而我们利用Alluxio统一入口的特性，挂载了两个HDFS集群，从而实现了从Alluxio一个入口读取两个集群的功能，而具体访问哪个底层集群，完全由Alluxio帮我们实现了。

图3 Alluxio 统一存储和抽象

解决方案

为了解决数据跨集群共享的问题，我们引入了国际知名并且开源的Alluxio。部署的Alluxio1.4 具有良好的稳定性和高效性，在引入Alluxio之后，架构如图4所示。

图4 改进后架构图

从图4可以看到，Spark Streaming数据直接落地到Alluxio，Alluxio通过将HDFS1和HDFS2分别挂载到两个路径下。简单的通过命令：

$ alluxiofs mount /path/on/alluxio hdfs://namenode:port/path/on/hdfs

就能分别挂载这两个HDFS集群。

HDFS-2集群专门负责存储流计算的数据。数据收集到Kafka之后，Spark Streaming对其进行消费，计算后的数据直接写挂载了HDFS-2集群的路径。

Alluxio很友好的为Client提供了三种写策略，分别是：MUST_CACHE、CACHE_THROUGH、THROUGH，这三种策略分别是只写Alluxio，同步到HDFS，只写HDFS。这里可以根据数据的重要性，采用不同的策略来写Alluxio，重要的数据需要同步到HDFS，允许数据丢失的可以采用只写Alluxio策略。

采用上述策略方案之后，我们发现Alluxio在一定程度上减少了NameNode的压力。部分热点数据并且多次使用的数据，我们会通过定时作业将该部分数据加载到Alluxio，一方面加快了计算引擎加载数据的速度，另外一方面减少了对NameNode的数据访问请求数。

此外, Alluxio自身实现了一个叫做TTL（Time To Live）的功能，只要对一个路径设置了TTL，Alluxio内部会对这部分数据进行检测，当前时间减去路径的创建时间大于TTL数值的路径会触发TTL功能。

考虑到实用性，Alluxio为我们提供了Free和Delete两种Action。Delete会将底层文件一同删除，Free只删Alluxio而不删底层文件系统。为了减少Alluxio内存压力，我们要求写到Alluxio中的数据必须设置一个TTL，这样Alluxio会自动将过期数据删除（通过设置Free Action策略，可以删除Alluxio而不删除HDFS）。对于从Alluxio内存中加载数据的Spark Sql作业，我们拿取了线上的作业和从HDFS上读数据进行了对比，普遍提高了30%的执行效率。

后记

从调研Alluxio到落地上线Alluxio，整个过程下来，我们碰到过一系列的问题, 针对这些问题以及业务需求, 开发了一系列的功能并回馈了Alluxio社区。

1. Alluxio在写HDFS的时候，需要使用HDFS的Root账号权限，对于带Kerberos的HDFS集群，会出现无权限写。为了解决这个问题，我们为Alluxio单独建了一个Hadoop账号，所有落地到HDFS的数据通过该账号来写。

2. 1.4版本的Alluxio不支持以文件夹的形式进行TTL的设置，我们进行了功能的完善并贡献给社区(出现在1.5以及后续版本中)。

3. 1.4版本不支持TTL使用Free策略来删除数据，我们对该功能进行了完善并贡献给社区(出现在1.5以及后续版本中)。

4. 1.4版本底层文件发生修改，对于Alluxio来说是不感知的，而通过Alluxio读取的数据可能出现不准确（1.7版本得到了彻底解决），我们开发了一个shell命令checkConsistency和repairConsistency来解决这个问题。