（1）Copy on Write:使用列式存储来存储数据（例如：parquet）,通过在写入期间执行同步合并来简朴地更新和重现文件
（2）Merge on Read:使用列式存储（parquet）+行式文件（arvo）组合存储数据。更新记录到增量文件中，然后进行同步或异步压缩来天生新版本的列式文件。
下面总结了两种表类型之间的权衡
Query Types:
（1）Snapshot Queries:快照查询，在此视图上的查询将看到某个提交和压缩操纵的最新快照。对于merge on read的表，它通过即时合并最新文件切片的根本文件和增量文件来展示近乎及时的数据（几分钟）。对于copy on write的表，它提供了对现有parquet表的直接替代，同时提供了upsert/delete和其他写入功能。
（2）Incremental Queries:增量查询，该视图智能看到从某个提交/压缩写入数据集的新数据。该视图有效地提供了chang stream,来支持增量视图
（3）Read Optimized Queries:读优化视图，在此视图上的查询将查看到给定提交或压缩操纵中的最新快照。该视图将最新文件切片的列暴露个查询，并保证与非hudi列式数据集相比，具有雷同列式查询功能。
下面总结了两种查询的权衡
Copy on Write Table
Copy on Write表中的文件切片仅包含根本/列文件，并且每次提交都会天生新版本的根本文件。换句话说，每次提交操纵都会被压缩，以便存储列式数据，因此Write Amplification写入放大非常高（即使只有一个字节的数据被提交修改，我们也必要重写整个列数据文件），而读取数据成本则没有增加，所以这种表适合于做分析工作，读取麋集型的操纵。
下图说明了copy on write的表是如何工作的
随着数据被写入，对现有文件组的更新会为该文件组天生一个带有提交即时间标记的新切片，而插入分配一个新文件组并写入该文件组第一个切片。这些切片和提交即时时间在上图用同一颜色标识。针对图上右侧sql查询，起首检查时间轴上的最新提交并过滤掉之前的旧数据（根据时间查询最新数据），如上图所示粉色数据在10:10被提交，第一次查询是在10:10之前，所以出现不到粉色数据，第二次查询时间在10:10之后，可以查询到粉色数据（以被提交的数据）。
Copy on Write表从根本上改进表的管理方式
（1）在原有文件上进行主动更新数据，而不是重新刷新整个表/分区
（2）可以或许只读取修改部分的数据，而不是浪费查询无效数据
（3）严格控制文件巨细来保证查询性能（小文件会显著降低查询性能）
Merge on Read Table
Merge on Read表是copy on write的超集，它仍然支持通过仅向用户公开最新的文件切片中的根本/列来对表进行查询优化。用户每次对表文件的upsert操纵都会以增量日记的形式进行存储，增量日记会对应每个文件最新的ID来资助用户完成快照查询。因此这种表类型，可以或许智能平衡读取和写放大（wa）,提供近乎及时的数据。这种表最重要的是压缩器，它用来选择将对应增量日记数据压缩到表的根本文件中，来保持查询时的性能（较大的增量日记文件会影响合并时间和查询时间）
下图说明了该表的工作原理，并显示两种查询类型：快照查询和读取优化查询
（1）如上图所示，现在每一分钟提交一次，这种操纵是在别的表里（copy on write table）无法做到的
（2）现在有一个增量日记文件，它生存对根本列文件中记录的传入更新（对表的修改），在图中，增量日记文件包含从10:05到10:10的所有数据。根本列文件仍然使用commit来进行版本控制，因此如果只看根本列文件，那么表的表的布局就像copy on write表一样。
（3）定期压缩过程会调和增量日记文件和根本列文件进行合并，并天生新版本的根本列文件，就如图中10：05所发生的环境一样。
（4）查询表的方式有两种，Read Optimized query和Snapshot query,取决于我们选择是要查询性能还是数据新鲜度
（5）如上图所示，Read Optimized query查询不到10:05之后的数据（查询不到增量日记里的数据），而Snapshot query则可以查询到全量数据（根本列数据+行式的增量日记数据）。
（6）压缩触发是办理所有难题的关键，通过实验压缩策略，会快速缩新分区数据，来保证用户使用Read Optimized query可以查询到X分钟内的数据
Merge on Read Table是直接在DFS上启用近及时（near real-time）处理惩罚，而不是将数据复制到外部专用系统中。该表还有些次要的长处，例如通过克制数据的同步合并来淘汰写入放大（WA）。
写时复制（COW）与读时合并（MOR）区别
写时复制（Copy On Write）：此存储类型使客户端可以或许以列式文件格式（当前为parquet）摄取数据。使用COW存储类型时，任何写入Hudi数据集的新数据都将写入新的parquet文件。更新现有的行将导致重写整个parquet文件（这些parquet文件包含要更新的受影响的行）。因此，所有对此类数据集的写入都受parquet写性能的限制，parquet文件越大，摄取数据所耗费的时间就越长。
读时合并（Merge On Read）：此存储类型使客户端可以快速将数据摄取为基于行（如avro）的数据格式。使用MOR存储类型时，任何写入Hudi数据集的新数据都将写入新的日记/增量文件，这些文件在内部将数据以avro进行编码。压缩（Compaction）过程（配置为嵌入式或异步）将日记文件格式转换为列式文件格式（parquet）。
两种不同的格式提供了两种不同视图（读优化视图和及时视图），读优化视图取决于列式parquet文件的读取性能，而及时视图取决于列式和/或日记文件的读取性能。
更新现有的行将导致：a）写入从以前通过压缩（Compaction）天生的基础parquet文件对应的日记/增量文件更新；或b）在未进行压缩的环境下写入日记/增量文件的更新。因此，对此类数据集的所有写入均受avro /日记文件写入性能的限制，其速度比parquet快得多（写入时必要复制）。虽然，与列式（parquet）文件相比，读取日记/增量文件必要更高的成本（读取时必要合并）。
使用场景