共计 2974 个字符，预计需要花费 8 分钟才能阅读完成。
怎么通过 Apache Hudi 和 Alluxio 建设高性能数据湖，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。
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 互联，提升数据湖以及围湖生态的读写效率。
看完上述内容，你们掌握怎么通过 Apache Hudi 和 Alluxio 建设高性能数据湖的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注丸趣 TV 行业资讯频道，感谢各位的阅读！
