使用Apache Hudi 加速传统的批处理模式的方法

目录
  • 1. 现状说明
    • 1.1 数据湖摄取和计算过程 - 处理更新
    • 1.2 当前批处理过程中的挑战
  • 2. Hudi 数据湖 — 查询模式
    • 2.1 面向分析师的表/OLAP(按 created_date 分区)
    • 2.2 面向ETL(按更新日期分区)
      • 1. “created_date”分区的挑战
      • 2. “updated_date”分区的挑战
    • 3. “新”重复数据删除策略
    • 4. Apache Hudi 的优势

Apache Hudi(简称:Hudi)使得您能在hadoop兼容的存储之上存储大量数据,同时它还提供两种原语,使得除了经典的批处理之外,还可以在数据湖上进行流处理。

1. 现状说明

1.1 数据湖摄取和计算过程 - 处理更新

在我们的用例中1-10% 是对历史记录的更新。当记录更新时,我们需要从之前的 updated_date 分区中删除之前的条目,并将条目添加到最新的分区中,在没有删除和更新功能的情况下,我们必须重新读取整个历史表分区 -> 去重数据 -> 用新的去重数据覆盖整个表分区

1.2 当前批处理过程中的挑战

这个过程有效,但也有其自身的缺陷:

  1. 时间和成本——每天都需要覆盖整个历史表
  2. 数据版本控制——没有开箱即用的数据和清单版本控制(回滚、并发读取和写入、时间点查询、时间旅行以及相关功能不存在)
  3. 写入放大——日常历史数据覆盖场景中的外部(或自我管理)数据版本控制增加了写入放大,从而占用更多的 S3 存储

借助Apache Hudi,我们希望在将数据摄取到数据湖中的同时,找到更好的重复数据删除和数据版本控制优化解决方案。

2. Hudi 数据湖 — 查询模式

当我们开始在我们的数据湖上实现 Apache Hudi 的旅程时,我们根据表的主要用户的查询模式将表分为 2 类。

  • 面向ETL :这是指我们从各种生产系统摄取到数据湖中的大多数原始/基本快照表。 如果这些表被 ETL 作业广泛使用,那么我们将每日数据分区保持在 updated_date,这样下游作业可以简单地读取最新的 updated_at 分区并(重新)处理数据。
  • 面向分析师:通常包括维度表和业务分析师查询的大部分计算 OLAP,分析师通常需要查看基于事务(或事件)created_date 的数据,而不太关心 updated_date。

这是一个示例电子商务订单数据流,从摄取到数据湖到创建 OLAP,最后到业务分析师查询它

由于两种类型的表的日期分区列不同,我们采用不同的策略来解决这两个用例。

2.1 面向分析师的表/OLAP(按 created_date 分区)

在 Hudi 中,我们需要指定分区列和主键列,以便 Hudi 可以为我们处理更新和删除。
以下是我们如何处理面向分析师的表中的更新和删除的逻辑:

  • 读取上游数据的 D-n 个 updated_date 分区。
  • 应用数据转换。 现在这个数据将只有新的插入和很少的更新记录。
  • 发出 hudi upsert 操作,将处理后的数据 upsert 到目标 Hudi 表。

由于主键和 created_date 对于退出和传入记录保持相同,Hudi 通过使用来自传入记录 created_date 和 primary_key 列的此信息获取现有记录的分区和分区文件路径。

2.2 面向ETL(按更新日期分区)

当我们开始使用 Hudi 时,在阅读了许多博客和文档之后,在 created_date 上对面向 ETL 的表进行分区似乎是合乎逻辑的。
此外 Hudi 提供增量消费功能,允许我们在 created_date 上对表进行分区,并仅获取在 D-1 或 D-n 上插入(插入或更新)的那些记录。

1. “created_date”分区的挑战

这种方法在理论上效果很好,但在改造传统的日常批处理过程中的增量消费时,它带来了其他一系列挑战:
Hudi 维护了在不同时刻在表上执行的所有操作的时间表,这些提交包含有关作为 upsert 的一部分插入或重写的部分文件的信息,我们将此 Hudi 表称为 Commit Timeline。
这里要注意的重要信息是增量查询基于提交时间线,而不依赖于数据记录中存在的实际更新/创建日期信息。

  • 冷启动:当我们将现有的上游表迁移到 Hudi 时,D-1 Hudi 增量查询将获取完整的表,而不仅仅是 D-1 更新。发生这种情况是因为在开始时,整个表是通过在 D-1 提交时间线内发生的单个初始提交或多个提交创建的,并且缺少真正的增量提交信息。
  • 历史数据重新摄取:在每个常规增量 D-1 拉取中,我们期望仅在 D-1 上更新的记录作为输出。但是在重新摄取历史数据的情况下,会再次出现类似于前面描述的冷启动问题的问题,并且下游作业也会出现 OOM。

历史数据重新摄取:在每个常规增量 D-1 拉取中,我们期望仅在 D-1 上更新的记录作为输出。但是在重新摄取历史数据的情况下,会再次出现类似于前面描述的冷启动问题的问题,并且下游作业也会出现 OOM。

作为面向 ETL 的作业的解决方法,我们尝试将数据分区保持在 updated_date 本身,然而这种方法也有其自身的挑战。

2. “updated_date”分区的挑战

我们知道 Hudi 表的本地索引,Hudi 依靠索引来获取存储在数据分区本地目录中的 Row-to-Part_file 映射。因此,如果我们的表在 updated_date 进行分区,Hudi 无法跨分区自动删除重复记录。
Hudi 的全局索引策略要求我们保留一个内部或外部索引来维护跨分区的数据去重。对于大数据量,每天大约 2 亿条记录,这种方法要么运行缓慢,要么因 OOM 而失败。
因此,为了解决更新日期分区的数据重复挑战,我们提出了一种全新的重复数据删除策略,该策略也具有很高的性能。

3. “新”重复数据删除策略

  • 查找更新 - 从每日增量负载中,仅过滤掉更新(1-10% 的 DI 数据)(其中 updated_date> created_date)(快速,仅映射操作)
  • 找到过时更新 - 将这些“更新”与下游 Hudi 基表广播连接。 由于我们只获取更新的记录(仅占每日增量的 1-10%),因此可以实现高性能的广播连接。 这为我们提供了与更新记录相对应的基础 Hudi 表中的所有现有记录
  • 删除过时更新——在基本 Hudi 表路径上的这些“过时更新”上发出 Hudi 删除命令
  • 插入 - 在基本 hudi 表路径上的完整每日增量负载上发出 hudi insert 命令

进一步优化用 true 填充陈旧更新中的 _hoodie_is_deleted 列,并将其与每日增量负载结合。 通过基本 hudi 表路径发出此数据的 upsert 命令。 它将在单个操作(和单个提交)中执行插入和删除。

4. Apache Hudi 的优势

  • 时间和成本——Hudi 在重复数据删除时不会覆盖整个表。 它只是重写接收更新的部分文件。 因此较小的 upsert 工作
  • 数据版本控制——Hudi 保留表版本(提交历史),因此提供实时查询(时间旅行)和表版本回滚功能。
  • 写入放大——由于只有部分文件被更改并保留用于数据清单版本控制,我们不需要保留完整数据的版本。 因此整体写入放大是最小的。

作为数据版本控制的另一个好处,它解决了并发读取和写入问题,因为数据版本控制使并发读取器可以读取数据文件的版本控制副本,并且当并发写入器用新数据覆盖同一分区时不会抛出 FileNotFoundException 文件。

到此这篇关于Apache Hudi 如何加速传统的批处理模式的文章就介绍到这了,更多相关Apache Hudi 批处理模式内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • Apache Hudi的多版本清理服务彻底讲解

    目录 1. 回收空间以控制存储成本 2. 问题描述 3. 深入了解 Hudi清理服务 4. 清理服务 5. 例子 6. 配置 7. 运行命令 8. 未来计划 Apache Hudi提供了MVCC并发模型,保证写入端和读取端之间快照级别隔离.在本篇博客中我们将介绍如何配置来管理多个文件版本,此外还将讨论用户可使用的清理机制,以了解如何维护所需数量的旧文件版本,以使长时间运行的读取端不会失败. 1. 回收空间以控制存储成本 Hudi 提供不同的表管理服务来管理数据湖上表的数据,其中一项服务称为Cle

  • Apache Pulsar结合Hudi构建Lakehouse方案分析

    目录 1. 动机 2. 分析 3. 当前方案 4. 新的Lakehouse存储方案 4.1 新的存储布局 4.2 支持高效Upserts 4.3 将Hudi表当做Pulsar Topic 4.4 可扩展的元数据管理 5. 引用 1. 动机 Lakehouse最早由Databricks公司提出,其可作为低成本.直接访问云存储并提供传统DBMS管系统性能和ACID事务.版本.审计.索引.缓存.查询优化的数据管理系统,Lakehouse结合数据湖和数据仓库的优点:包括数据湖的低成本存储和开放数据格式访

  • Apache Hudi集成Spark SQL操作hide表

    目录 1. 摘要 2. 环境准备 2.1 启动spark-sql 2.2 设置并发度 3. Create Table 4. Insert Into 4.1 Insert 4.2 Select 5. Update 5.1 Update 5.2 Select 6. Delete 6.1 Delete 6.2 Select 7. Merge Into 7.1 Merge Into Insert 7.2 Select 7.4 Merge Into Update 7.5 Select 7.6 Merge

  • 基于Apache Hudi在Google云构建数据湖平台的思路详解

    自从计算机出现以来,我们一直在尝试寻找计算机存储一些信息的方法,存储在计算机上的信息(也称为数据)有多种形式,数据变得如此重要,以至于信息现在已成为触手可及的商品.多年来数据以多种方式存储在计算机中,包括数据库.blob存储和其他方法,为了进行有效的业务分析,必须对现代应用程序创建的数据进行处理和分析,并且产生的数据量非常巨大!有效地存储数PB数据并拥有必要的工具来查询它以便使用它至关重要,只有这样对该数据的分析才能产生有意义的结果.大数据是一门处理分析方法.有条不紊地从中提取信息或以其他方式处

  • 使用Apache Hudi 加速传统的批处理模式的方法

    目录 1. 现状说明 1.1 数据湖摄取和计算过程 - 处理更新 1.2 当前批处理过程中的挑战 2. Hudi 数据湖 — 查询模式 2.1 面向分析师的表/OLAP(按 created_date 分区) 2.2 面向ETL(按更新日期分区) 1. “created_date”分区的挑战 2. “updated_date”分区的挑战 3. “新”重复数据删除策略 4. Apache Hudi 的优势 Apache Hudi(简称:Hudi)使得您能在hadoop兼容的存储之上存储大量数据,同时

  • Apache Hudi数据布局黑科技降低一半查询时间

    目录 1. 背景 2. Clustering架构 2.1 调度Clustering 2.2 运行Clustering 2.3 Clustering配置 3. 表查询性能 3.1 进行Clustering之前 3.2 进行Clustering之后 4. 总结 1. 背景 Apache Hudi将流处理带到大数据,相比传统批处理效率高一个数量级,提供了更新鲜的数据.在数据湖/仓库中,需要在摄取速度和查询性能之间进行权衡,数据摄取通常更喜欢小文件以改善并行性并使数据尽快可用于查询,但很多小文件会导致查

  • 深入解析Apache Hudi内核文件标记机制

    目录 1. 摘要 2. 为何引入Markers机制 3. 现有的直接标记机制及其局限性 4. 基于时间线服务器的标记机制提高写入性能 5. 标记相关的写入选项 6. 性能 7. 总结 1. 摘要 Hudi 支持在写入时自动清理未成功提交的数据.Apache Hudi 在写入时引入标记机制来有效跟踪写入存储的数据文件. 在本博客中,我们将深入探讨现有直接标记文件机制的设计,并解释了其在云存储(如 AWS S3.Aliyun OSS)上针对非常大批量写入的性能问题. 并且演示如何通过引入基于时间轴服

  • Vertica集成Apache Hudi重磅使用指南

    目录 1. 摘要 2. Apache Hudi介绍 3. 环境准备 4. Vertica和Apache Hudi集成 4.1 在 Apache Spark 上配置 Apache Hudi 和 AWS S3 4.2 配置 Vertica 和 Apache HUDI 集成 4.3 如何让 Vertica 查看更改的数据 4.3.1 写入数据 4.3.2 更新数据 4.3.3 创建和查看数据的历史快照 1. 摘要 本文演示了使用外部表集成 Vertica 和 Apache Hudi. 在演示中我们使用

  • Apache Hudi异步Clustering部署操作的掌握

    目录 1. 摘要 2. 介绍 3. Clustering策略 3.1 计划策略 3.2 执行策略 3.3 更新策略 4. 异步Clustering 4.1 HoodieClusteringJob 4.2 HoodieDeltaStreamer 4.3 Spark Structured Streaming 5. 总结和未来工作 1. 摘要 在之前的一篇博客中,我们介绍了Clustering(聚簇)的表服务来重新组织数据来提供更好的查询性能,而不用降低摄取速度,并且我们已经知道如何部署同步Clust

  • Apache Hudi基于华米科技应用湖仓一体化改造

    目录 1. 应用背景及痛点介绍 2. 技术方案选型 3. 问题与解决方案 3.1.增量数据字段对齐问题 3.2 全球存储兼容性问题 3.3 云主机时区统一问题 3.4 升级新版本问题 3.5 多分区Upsert性能问题 3.6 数据特性适应问题 4. 上线收益 4.1 成本方面 4.2 效率方面 4.3 稳定性层面 4.4 查询性能层面 5. 总结与展望 1. 应用背景及痛点介绍 华米科技是一家基于云的健康服务提供商,拥有全球领先的智能可穿戴技术.在华米科技,数据建设主要围绕两类数据:设备数据和

  • OnZoom基于Apache Hudi的一体架构实践解析

    1. 背景 OnZoom是Zoom新产品,是基于Zoom Meeting的一个独一无二的在线活动平台和市场.作为Zoom统一通信平台的延伸,OnZoom是一个综合性解决方案,为付费的Zoom用户提供创建.主持和盈利的活动,如健身课.音乐会.站立表演或即兴表演,以及Zoom会议平台上的音乐课程. 在OnZoom data platform中,source数据主要分为MySQL DB数据和Log数据. 其中Kafka数据通过Spark Streaming job实时消费,MySQL数据通过Spark

  • Apache Hudi基于华米科技应用湖仓一体化改造

    目录 1. 应用背景及痛点介绍 2. 技术方案选型 3. 问题与解决方案 3.1.增量数据字段对齐问题 3.2 全球存储兼容性问题 3.3 云主机时区统一问题 3.4 升级新版本问题 3.5 多分区Upsert性能问题 3.6 数据特性适应问题 4. 上线收益 4.1 成本方面 4.2 效率方面 4.3 稳定性层面 4.4 查询性能层面 5. 总结与展望 1. 应用背景及痛点介绍 华米科技是一家基于云的健康服务提供商,拥有全球领先的智能可穿戴技术.在华米科技,数据建设主要围绕两类数据:设备数据和

  • Apache Hudi异步Clustering部署操作的掌握

    目录 1. 摘要 2. 介绍 3. Clustering策略 3.1 计划策略 3.2 执行策略 3.3 更新策略 4. 异步Clustering 4.1 HoodieClusteringJob 4.2 HoodieDeltaStreamer 4.3 Spark Structured Streaming 5. 总结和未来工作 1. 摘要 在之前的一篇博客中,我们介绍了Clustering(聚簇)的表服务来重新组织数据来提供更好的查询性能,而不用降低摄取速度,并且我们已经知道如何部署同步Clust

随机推荐