T3Go是中国第一个基于车联网的智能出行平台。在这篇文章中，T3Go的Trevor Zhang和Vino Yang描述了他们的数据湖架构的演变，该架构建立在云原生或开源技术上，包括阿里巴巴OSS、Apache Hudi和Alluxio。今天，他们的数据湖存储了PB级的数据，每天支持数百条管道和数万个任务。它对T3Go的业务部门至关重要，包括数据仓库、车联网、订单调度、机器学习和自助查询分析。
在这篇博客中，你将看到我们如何使用Hudi和Alluxio将数据摄取时间缩短一半。此外，使用Presto、Hudi和Alluxio的数据分析师看到查询的速度提高了10倍。我们在数据管道的多个阶段，包括摄取和分析，基于数据协调建立了我们的数据湖。
1.T3Go数据湖概述
在建立数据湖之前，T3Go 的不同业务部门管理着自己的数据处理解决方案，利用不同的存储系统、ETL 工具和数据处理框架。每个单位的数据都是孤立的，大大增加了成本和复杂性。由于T3Go的快速业务扩张，这种低效率成为我们的工程瓶颈。
我们转向基于阿里巴巴OSS的统一数据湖解决方案，这是一个类似于AWS S3的对象存储，提供一个集中的位置来存储结构化和非结构化的数据，遵循多集群共享数据架构的设计原则；所有的应用程序访问OSS存储作为真理的来源，而不是不同的数据仓。这种架构使我们能够按原样存储数据，而不必首先对数据进行结构化处理，并运行不同类型的分析以指导更好的决策，从大数据处理、实时分析和机器学习中构建仪表盘和可视化。
2.使用胡迪的高效近实时分析
我们在智能旅行方面的业务促使我们需要以接近实时的方式处理和分析数据。使用传统的数据仓库，我们面临着以下挑战。
- 由于长尾延迟，更新时的开销很大。
- 由于业务环节的长窗口，订单分析的高成本。
- 由于迟来的或临时的更新而降低了查询的准确性。
- 数据摄取管道的不可靠。
- 分布式数据管道中的数据丢失，无法调和。
- 访问数据存储的高延迟。
因此，我们在OSS的基础上采用了Apache Hudi来解决这些问题。下图概述了该架构。
实现近乎实时的数据摄取和分析
有了Hudi，我们的数据湖支持多种数据源，包括Kafka、MySQL binlog、GIS和其他业务日志的近实时数据。因此，公司60%以上的数据都存储在数据湖中，而且这个比例还在不断增加。
通过在数据管道中引入Apache Hudi，我们还能将数据摄取时间加快到几分钟。结合大数据交互式查询和分析框架，如Presto和SparkSQL，实现了实时数据分析和洞察力。
启用增量处理管道
在Hudi的帮助下，当上游表频繁更新时，有可能为下游衍生表提供增量变化。即使有大量的相互依赖的表，我们也可以快速运行部分数据更新。这也有效地避免了在传统的Hive数据仓库中更新冷表的全部分区。
使用Hudi作为统一格式访问数据
传统的数据仓库通常部署Hadoop来存储数据并提供批量分析。Kafka被单独用来将Hadoop数据分配给其他数据处理框架，导致数据重复。Hudi有助于有效解决这个问题；我们总是使用Spark管道向Hudi表插入新的更新，然后递增地读取Hudi表的更新。换句话说，Hudi表被作为统一的存储格式来访问数据。
3.使用Alluxio进行高效的数据缓存
在我们没有Alluxio的数据湖的早期版本中，从Kafka实时接收的数据由Spark处理，然后使用Hudi DeltaStreamer任务写入OSS数据湖。在这种架构下，Spark在直接写入OSS时经常会遭遇高网络延迟。由于所有的数据都在OSS存储中，由于缺乏数据定位，对Hudi数据的OLAP查询也可能很慢。
为了解决延迟问题，我们将Alluxio部署为数据协调层，与Spark和Presto等计算引擎共存，并使用Alluxio来加速数据湖的读写，如下图所示。
Hudi、Parquet、ORC和JSON等格式的数据主要存储在OSS上，占95%的数据。计算引擎，如Flink、Spark、Kylin和Presto，分别部署在独立的集群中。当每个引擎访问OSS时，Alluxio作为一个虚拟的分布式存储系统来加速数据，与每个计算集群共处一地。
具体来说，以下是一些在T3Go数据湖中利用Alluxio的应用。
数据湖摄取
我们将相应的OSS路径挂载到Alluxio文件系统中，并将Hudi的*"目标-基地-路径"*参数值设置为使用Alluxio://方案，以取代oss://方案。带有Hudi的Spark管道不断地将数据摄入到Alluxio。数据被写入Alluxio后，每分钟从Alluxio缓存中异步持久化到远程OSS。这些修改允许Spark写到本地Alluxio节点，而不是写到远程OSS，大大减少了数据摄入后在数据湖中可用的时间。
湖中的数据分析
我们使用Presto作为一个临时的查询引擎来分析湖中的Hudi表，在每个Presto工作节点上共同安置Alluxio工作者。当Presto和Alluxio服务在同一地点运行时，Alluxio会将输入的数据缓存在Presto工作者的本地，这对Presto的后续检索大有好处。在缓存命中时，Presto可以以内存速度从本地Alluxio工作者的存储中读取数据，而无需通过网络进行额外的数据传输。
跨越多个存储系统的并发访问
为了确保训练样本的准确性，我们的机器学习团队经常将生产中的脱敏数据同步到离线机器学习环境中。在同步过程中，数据在多个文件系统中流动，从生产OSS到离线HDFS，然后是另一个离线机器学习HDFS。
这种数据迁移过程对于建模者来说不仅效率低下，而且容易出错，因为涉及到多个不同配置的存储空间。Alluxio通过将目标存储系统挂载在同一个文件系统下，通过Alluxio命名空间中相应的逻辑路径进行访问，来帮助解决这一特定情况。通过对物理存储的解耦，允许具有不同API的应用程序无缝访问和传输数据。这种数据访问布局也提高了性能。
微观基准测试
总的来说，我们观察到Alluxio有以下改进。
- 它支持分层的、透明的缓存机制。
- 它支持读取时的缓存促进全模式。
- 它支持异步写入模式。
- 它支持LRU回收策略。
- 它有引脚和TTL功能。
经过比较和验证，我们选择使用Spark SQL作为查询引擎。我们的性能测试查询Hudi表，将Alluxio+OSS一起与OSS直接以及HDFS进行比较。
在上图的压力测试中，在数据量大于一定量级（2400W）后，使用Alluxio+OSS的查询速度超过了混合部署的HDFS查询速度。在数据量大于1E后，查询速度开始翻倍。在达到6E的数据后，比查询本地OSS的速度高12倍，比查询本地HDFS的速度高8倍。这种改进取决于机器的配置。
根据我们的性能基准测试，我们发现在Alluxio的帮助下，性能可以提高10倍以上。此外，数据规模越大，性能改善越突出。
4.下一步工作
随着T3Go的数据湖生态系统的扩大，我们将继续面临计算和存储隔离的关键场景。随着T3Go的数据处理需求不断增长，我们的团队计划在更大范围内部署Alluxio，以加速我们的数据湖存储。
除了在数据湖计算引擎上部署Alluxio，目前主要是SparkSQL，我们计划在使用Apache Kylin的OLAP集群和使用Presto的ad_hoc集群中增加一层Alluxio。目标是让Alluxio覆盖所有的计算场景，每个场景之间都有Alluxio互联，以提高数据湖和周边湖泊生态的读写效率。
5.结语
如前所述，Hudi和Alluxio覆盖了Hudi在DFS上的近实时摄取、近实时分析、增量处理和数据分发等所有场景，在数据湖的数据摄取和数据分析上发挥了强大的加速器作用。在Hudi和Alluxio的配合下，我们的研发工程师将数据摄入湖中的时间缩短了2倍。数据分析师在使用Presto、Hudi和Alluxio查询湖中的数据时，其查询速度提高了10倍。 此外，数据规模越大，性能的提高就越突出。Alluxio是T3Go成为中国领先的企业数据湖计划的一个重要组成部分。我们期待着在T3Go的数据湖生态系统中看到与Alluxio的进一步整合。
