数据湖技术Hudi表类型COW/MOR如何选择？互联网大厂实践案例参考

大数据从业者 2023-02-23

4766

前言

近年来，数据湖技术Apache Hudi利用Copy-On-Write(COW)和Merge-On-Read(MOR)两种存储/表格式，彻底改变了大数据分析领域认知。随着Hudi在越来越多的公司落地实施，相信很多人都会疑惑：如何抉择一个业务场景到底使用COW表还是MOR表呢？本文主要描述Hudi发源公司Uber和跨境电商公司Shopee使用HUdi真实落地的业务场景，相信能够给到大家一些启发。

Hudi诞生背景

2015年以前，Uber使用Spark作业周期地将出租车路线数据的变更情况(插入、更新、删除)保存到HDFS。随着Uber高速发展，业务量激增，写入HDFS的过程效率很低、速度很慢，Hudi由此诞生。使用Hudi使得原先数据变更需要重写整个表变为只需重写一个文件。

Copy-On-Write(COW)

写时复制（COW）是Hudi诞生时支持的第一种存储表类型。与Apache Spark的旧架构相比，Uber的写入效率提高了100多倍。

随着数据湖技术在大数据分析领域的普及，大数据分析需求从以往的批处理扩展到了需要分钟级延迟的流处理。即使是修改一条数据，COW都要重写整个文件。在流处理场景下使用COW表，表更新操作越多，意味着越多的文件版本和文件计数，这无疑会导致数据写入效率低和数据写入延迟高。

Merge-On-Read (MOR)

读时合并(MOR)是Hudi支持的第二种存储表类型，该类型表主要用于减少需要大量更新操作的COW表的写入放大影响。MOR不是重写整个文件，而是将更新操作写入到单独的日志变更文件。然后根据用户配置的合并策略，这些变更日志合并到新的文件版本中。多个日志变更文件一起合入，可以避免多次重写整个文件。

COW和MOR对比

两者都是Hudi支持的存储表类型，应用到不同的业务场景中：

COW

非常适合查询延迟低的场景
表更新效率不如MOR
Uber就使用COW表存储追加写的数据，比如记录用户交互的时间日志(用户点击按钮等)。
复制

MOR

非常适合频繁更新的场景
合并之前的查询性能低于COW表，但是合并之后的性能与COW表相同。MOR表避免了对数据文件不必要的重写，从而降低写入开销、降低了写入延迟。
复制

跨境电商Shopee就使用MOR表存储他们网站的频繁更新的分析数据(如购物者从购物车添加或者删除商品的行为记录)。简单总结，如图所示：

现实业务场景

COW场景

众所周知，Uber是世界上最大的打车公司之一。Uber每天写入数据湖的数量达到5000亿条数百PB级别。Uber跟踪记录每一次打车过程的所有事件，包括：打开Uber应用、发起打车、上车、到达目的地下车以及对司机的评价打分等等。

Uber使用COW表存储应用程序中用户交互的历史记录数据，这些历史记录一旦产生并不会发生追溯修改。这个案例场景中，就适合使用COW表，既能满足数据查询的性能也能满足数据查询的低延迟。这也有利于Uber内部工程师构造高性能低延迟的数据大盘。

MOR场景

Shopee是东南亚最大的在线购物平台，月访问量达3亿多，数据量也达到PB级别。Shopee数据团队基于Hudi构建了实时数据平台，充分利用Hudi强大的实时数据流功能。该网站的限时抢购活动，每天重置多次。

Shopee将用户数据实时导入到Hudi数据湖中，用来跟踪用户点击交易的时间、购买的时间、限购倒计时时间等。与Uber保存事件日志不同，Shopee希望实时跟踪用户的当前状态。由于数据随着用户与应用程序的交互而变化，Shopee需要实时更新每个用户相关的操作记录。如果使用COW表，更新成本会很高。所以，这种场景更加适用于MOR表，减少文件重写次数节省写入开销。