经过Apache Hudi和Alluxio建设高性能数据湖

T3出行的杨华和张永旭描述了他们数据湖架构的发展。该架构使用了众多开源技术，包括Apache Hudi和Alluxio。在本文中，您将看到咱们如何使用Hudi和Alluxio将数据摄取时间缩短一半。此外，数据分析人员如何使用Presto、Hudi和Alluxio让查询速度提升了10倍。咱们基于数据编排为数据管道的多个阶段（包括提取和分析）构建了数据湖。

1.T3出行数据湖总览

T3出行当前还处于业务扩张期，在构建数据湖以前不一样的业务线，会选择不一样的存储系统、传输工具以及处理框架，从而出现了严重的数据孤岛使得挖掘数据价值的复杂度变得很是高。因为业务的迅速发展，这种低效率成为了咱们的工程瓶颈。

咱们转向了基于阿里巴巴OSS（相似于AWS S3的对象存储）的统一数据湖解决方案，以遵循多集群、共享数据架构(Multi-cluster,Shared-data Architecture)的设计原则提供集中位置来存储结构化和非结构化数据。与不一样的数据孤岛相反，全部应用程序都将OSS存储做为事实的来源来访问。这种体系结构使咱们可以按原样存储数据，
而没必要先对数据进行结构化，并运行不一样类型的分析以指导更好的决策，经过大数据处理，实时分析和机器学习来构建仪表板和可视化。

2.使用Hudi进行高效的近实时分析

T3出行的智能出行业务推进了对近实时处理和分析数据的需求。使用传统的数据仓库，咱们面临如下挑战：

• 长尾更新引起冷数据频繁与级联更新
• 超长的业务窗口致使订单分析回溯成本高
• 随机更新及迟到数据没法预判
• 数据摄取Pipeline没法保证可靠性
• 分布式数据Pipeline中丢数据没法对帐
• 数仓数据摄取的延迟性很高

所以，咱们在OSS之上采用了Apache Hudi来解决这些问题。下图展现了Hudi的体系结构：

2.1启用近实时数据摄取和分析

T3出行数据湖支持Kafka 消息、Mysql binlog、GIS、业务日志等多种数据源近实时入湖，全公司60%以上的数据已经存入数据湖，而且这个比例还在不断扩大。
T3出行经过在数据管道中引入Hudi将数据的摄取时间缩短至几分钟，再结合大数据交互式查询与分析框架（如Presto和SparkSQL），能够实现更实时地对数据进行洞察、分析。

2.2启用增量处理管道

T3出行借助于Hudi提供的增量查询的能力，对于频繁变动场景中的多层数据加工的场景，能够只将增量的变动反馈给下游的派生表，下游的派生表只须要应用这些变动数据，就能够快速完成多层链路的局部数据更新，从而极大地下降了频繁变动场景下的数据更新的效率。有效地避免了传统Hive数仓中的全分区、冷数据更新。

2.3使用Hudi做为统一数据格式

传统的数据仓库一般部署Hadoop来存储数据并提供批处理分析，Kafka单独用于将数据分发到其余数据处理框架，从而致使数据重复。Hudi有效解决了这个问题,咱们始终使用Spark-kafka管道将最新更新的数据插入到Hudi表中，而后以增量方式读取Hudi表的更新。换句话说，Hudi统一了存储。

3.使用Alluxio进行高效的数据缓存

在早期版本的数据湖中并无使用Alluxio，Spark实时处理从Kafka接收的数据，而后使用Hudi DeltaStreamer任务将其写入OSS。执行这个流程时，Spark在直接写入OSS时网络延迟一般很是高。由于全部数据都存储在OSS中，致使数据缺失本地性，因此对Hudi数据的OLAP查询也很是慢。
为了解决延迟问题，咱们将Alluxio部署为数据编排层，与Spark和Presto等计算引擎共置一处，并使用Alluxio加速了对数据湖的读写，以下图所示：

Hudi，Parquet，ORC和JSON等格式的数据大部分存储在OSS上，占95％的数据。 Flink，Spark，Kylin和Presto等计算引擎分别部署在隔离的群集中。当每一个引擎访问OSS时，Alluxio充当虚拟分布式存储系统来加速数据，并与每一个计算群集共存。
下面介绍一下T3出行数据湖中使用Alluxio的案例：

3.1数据入湖

咱们将Alluxio与计算集群共置部署。在数据入湖前，将对应的OSS路径挂载至alluxio文件系统中，而后设置Hudi的"--target-base-path"参数 从oss://... 改成 alluxio://... 。在数据入湖时，咱们使用Spark引擎拉起Hudi程序不断摄入数据，数据此时在alluxio中流转。Hudi程序拉起后，设置每分钟将数据从Allxuio缓存中异步同步至远程OSS。这样Spark从以前的写远程OSS转变为写本地的Alluxio，缩短了数据入湖的时长。

3.2湖上数据分析

咱们使用Presto做为自助查询引擎，分析湖上的Hudi表。在每个Presto worker节点共置Alluxio。当Presto与Alluxio服务共置运行时，Alluxio可能会将输入数据缓存到Presto worker的本地，并之内存速度提供下次检索。在这种状况下，Presto能够利用Alluxio从本地的Alluxio worker存储读取数据（称之为短路读取），无需任何额外的网络传输。

3.3跨多个存储系统的并发访问

为了确保训练样本的准确性，咱们的机器学习团队常常将生产中的脱敏数据同步到离线机器学习环境。在同步期间，数据跨多个文件系统流动，从生产OSS到线下数据湖集群HDFS，最后同步到机器学习集群的HDFS。
对于数据建模人员来讲，数据迁移过程不只效率低下，并且会因错误配置而致使出错，由于其中涉及多个不一样配置的文件系统。因而咱们引入Alluxio,将多个文件系统都挂载到同一个Alluxio下，统一了命名空间。端到端对接时，使用各自的Alluxio路径，这保证了具备不一样API的应用程序无缝访问和传输数据。这种数据访问布局还能够提升性能。

3.4基准测试

整体而言，咱们观察到了Alluxio的如下优点：

• Alluxio 支持层次化且透明的缓存机制；
• Alluxio 支持读取时缓存 promote 模式；
• Alluxio 支持异步写模式；
• Alluxio 支持 LRU 回收策略；
• Alluxio 拥有 pin 以及 TTL 特性；

通过比较和验证后，咱们选择使用Spark SQL做为查询引擎，查询了Hudi表，存储层分别是Alluxio + OSS、OSS、HDFS这三组不一样文件系统。
压测时发现，数据量大于必定量级（2400W）后，使用alluxio+oss的查询速度超越了混合部署的HDFS查询速度，数据量大于1E后，查询速度开始成倍提高。到达6E数据后，相对于查询原生oss达到12倍提高，相对于查询原生HDFS达到8倍提高。数据规模越大，性能提高越显著，提高的倍数取决于机器配置。

4.展望

随着T3出行的数据湖生态系统的扩展，咱们将继续面对计算和存储隔离的关键场景随着T对数据处理需求的增加，咱们的团队计划大规模部署Alluxio，以增强数据湖查询能力。
因此除了数据湖计算引擎（主要是Spark SQL）上会部署Alluxio外，后续在OLAP集群（Apache Kylin）和ad_hoc集群(Presto)上架一层Alluxio。Alluxio将覆盖全场景，每一个场景间Alluxio互联，提高数据湖以及围湖生态的读写效率。

5.结论

正如前面所讲，Alluxio覆盖了Hudi近实时摄取，近实时分析，增量处理，DFS上数据分发等全部场景，在数据入湖和湖上数据分析链路上都扮演了强力加速器的角色，二者可谓强强联手。落地到具体场景上，研发工程师将数据入湖时间缩短了1-2倍。数据分析人员使用Presto+Hudi+Alluxio查询湖上数据的速度提升了10倍以上。Alluxio是T3出行成为中国领先的企业级数据湖计划中重要组成部分，咱们期待在T3出行的数据湖生态系统中与Alluxio进一步集成。