江苏龙网

  1. 首页 > 资讯 > 科技 > >

Hudi|技术干货 | Uber基于Apache Hudi构建PB级数据湖实践( 二 )


读时合并表类型使用列式（例如Apache Parquet）和基于行（例如Apache Avro）文件格式的组合来存储数据 。 更新记录到增量文件中 ， 然后以同步或异步压缩方式生成列文件的新版本 。
Hudi还支持两种查询类型：快照查询和增量查询 。 快照查询是从给定的提交或压缩操作开始对表进行"快照"的请求 。 利用快照查询时 ， 写时复制表类型仅暴露最新文件片中的基本/列文件 ， 并且与非Hudi表相比 ， 可保证相同的列查询性能 。 写入时复制提供了现有Parquet表的替代品 ， 同时提供了upsert/delete和其他功能 。 对于读时合并表 ， 快照查询通过动态合并最新文件切片的基本文件和增量文件来提供近乎实时的数据（分钟级） 。 对于写时复制表 ， 自给定提交或压缩以来 ， 增量查询将提供写入表的新数据 ， 并提供更改流以启用增量数据管道 。
3. Apache Hudi在Uber的使用
在Uber各种场景中都使用到了Hudi ， 从在Uber平台上提供有关行程的快速、准确的数据 ， 从检测欺诈到在Uber Eats平台上提供餐厅和美食推荐 。 为了演示Hudi的工作原理 ， 让其逐步了解如何确保Uber Marketplace中的行程数据在数据湖上是最新的 ， 从而改善Uber平台上的骑手和驾驶员的用户体验 。 行程的典型生命周期始于骑手提出的行程 ， 然后随着行程的进行而继续 ， 直到行程结束且骑手到达最终目的地时才结束 。 Uber的核心行程数据以表格形式存储在Uber的可扩展数据存储Schemaless中 。 行程表中的单个行程条目在行程的生命周期中可能会经历许多更新 。 在Uber使用Hudi之前 ， 大型Apache Spark作业会定期将整个数据集重新写入HDFS ， 以获取上游在线表的插入、更新和删除 ， 从而反映出行程状态的变化 。
就背景而言 ， 在2016年初（在构建Hudi之前） ， 一些最大的任务是使用1000个executors并处理超过20TB的数据 ， 此过程不仅效率低下 ， 而且难以扩展 。 公司的各个团队都依靠快速、准确的数据分析来提供高质量的用户体验 ， 为满足这些要求 ， Uber当前的解决方案无法扩展进行数据湖上的增量处理 。 使用快照和重新加载解决方案将数据移至HDFS时 ， 这些低效率的处理正在写到到所有数据管道 ， 包括使用此原始数据的下游ETL ， 可以看到这些问题只会随着规模的扩大而加剧 。
在没有其他可行的开源解决方案可供使用的情况下 ， Uber于2016年末为Uber构建并启动了Hudi ， 以构建可促进大规模快速 ， 可靠数据更新的事务性数据湖 。 Uber的第一代Hudi利用了写时复制表类型 ， 该表类型每30分钟将作业处理速度提高到20GB ， I/O和写入放大减少了100倍 。 到2017年底 ， Uber的所有原始数据表都采用了Hudi格式 ， 运行着地球上最大的事务数据湖之一 。
Hudi|技术干货 | Uber基于Apache Hudi构建PB级数据湖实践
本文插图
图2. Hudi的写时复制功能使我们能够执行文件级更新 ， 从而大大提高数据的新鲜度

4. 改进Apache Hudi
随着Uber数据处理和存储需求的增长 ， Uber开始遇到Hudi的写时复制功能的局限性 ， 主要是需要继续提高数据的处理速度和新鲜度 ， 即使使用Hudi"写时复制"功能 ， Uber的某些表收到的更新也分散在90％的文件中 ， 从而导致需要重写数据湖中任何给定的大型表的数据 ， 重写数据量大约为100TB 。 由于写时复制甚至为单个修改的记录重写整个文件 ， 因此写复制功能导致较高的写放大和损害的新鲜度 ， 从而导致HDFS群集上不必要的I/O以及更快地消耗磁盘空间 ， 此外 ， 更多的数据表更新意味着更多的文件版本 ， 以及HDFS文件数量激增 ， 反过来 ， 这些需求导致HDFS Namenode节点不稳定和较高的计算成本 。
为了解决这些日益增长的担忧 ， Uber实现了第二种表类型 ， 即"读时合并" 。 由于读时合并通过动态合并数据来使用近实时的数据 ， 为避免查询端的计算成本 ， 需要合理使用此模式 。 "读时合并"部署模型包括三个独立的作业 ， 其中包括一个摄取作业 ， 包括由插入、更新和删除组成的新数据 ， 一个次要的压缩作业 ， 以异步方式主动地压缩少量最新分区的更新/删除内容 ， 以及一个主要的压缩作业 ， 该作业会缓慢稳定地压缩大量旧分区中的更新/删除 。 这些作业中的每一个作业都以不同的频率运行 ， 次要作业和提取作业的运行频率比主要作业要高 ， 以确保其最新分区中的数据以列格式快速可用 。 通过这样的部署模型 ， Uber能够以列式为数千个查询提供新鲜数据 ， 并将查询侧合并成本限制在最近的分区上 。 使用读时合并 ， Uber能够解决上面提到的所有三个问题 ， 并且Hudi表几乎不受任何对数据湖的更新或删除的影响 。 现在 ， 在Uber大家会根据不同场景同时使用Apache Hudi的写时复制和读时合并功能 。


推荐阅读


上一篇：御鼠|王牌御鼠IP授权防伪管控

下一篇：鱼侃侃侃科技|MIUI确认在MIUI12中已将剪切板权限独立拆分，确保隐私安全