Hudi 表类型定义了数据的存储方式以及如何在表上执行写入操作（即如何写入数据）。反过来，查询类型定义了如何将底层数据暴露给查询（即如何读取数据）。

Hudi 引入了以下目前已在业界广泛使用的表类型，根据实际情况权衡取舍。Copy On Write ：Merge On Read：读取时合并 (MoR) 表类型通过使用定期压缩将轻量级日志文件与基础文件合并，从而平衡写入和读取性能。数据更新和删除操作会写入日志文件（以基于行的格式，例如 Avro 或列式/基础文件格式），然后在查询执行期间将日志文件中的这些更改与基础文件动态合并。这种方法降低了写入延迟，并支持近乎实时的数据可用性。但是，查询性能可能会因日志文件是否压缩而有所不同。核心事务功能（例如原子写入、索引）以及独特的新功能（例如增量查询、自动文件大小调整和可扩展表元数据跟踪）均在两者中提供，且与表类型无关。

写时复制 (COW) 表类型针对读取密集型工作负载进行了优化。在此模式下，记录更新或删除会触发在文件组中创建新的基础文件，并且不会写入日志文件。这确保每个查询仅读取基础文件，从而提供较高的读取性能，而无需动态合并日志文件。虽然 COW 表非常适合 OLAP 扫描/查询，但由于在更新或删除期间重写基础文件的开销，即使每个文件中只修改了少量记录，它们的写入操作也可能较慢。 下面从概念上说明了当数据写入时复制表并在其上运行两个查询时其工作原理。

随着数据的写入，对现有文件组的更新会为该文件组生成一个新的切片，并标记与提交请求的时刻相关联；而插入操作则会分配一个新的文件组，并为该文件组写入其第一个切片。这些文件切片及其提交完成的时刻已在上方以同一颜色编码。针对上图 SQL 查询首先检查已完成写入的时间线，并过滤每个文件组除最新文件切片之外的所有文件切片。如您所见，较旧的查询不会看到当前正在进行的提交的文件（以粉红色编码），但提交后启动的新查询会获取新数据。因此，查询不会受到任何写入失败/部分写入的影响，并且只会读取已提交的数据。

读取时合并 (MOR) 表类型通过使用定期压缩将轻量级日志文件与基文件合并，从而平衡写入和读取性能。数据更新和删除操作会写入日志文件（以基于行的格式，例如 Avro 或列式/基文件格式），然后在查询执行期间将日志文件中的这些更改动态地与基文件合并。这种方法可以降低写入延迟并支持近乎实时的数据可用性。但是，查询性能可能会因日志文件是否被压缩而有所不同。

下面说明了 MOR 表的工作原理，并展示了两种类型的查询 - 快照查询和读取优化查询。

这个例子中发生了很多有趣的事情，方法出方法的微妙之处。

1）如上图所示，可以做到每一分钟提交一次写入操作2）查询表的方式有两种，Read Optimized query和Snapshot query,取决于我们选择是要查询性能还是数据最新
3）如上图所示，Read Optimized query查询不到10:05之后的数据（查询不到增量日志里的数据，没有合并到base文件），而Snapshot query则可以查询到全量数据（基本列数据+行式的增量日志数据）