Rowset 的元数据一直存储在内存中

全局 Schema Cache

由于 Rowset 的元数据一直存储在内存中，如果每个 RowsetMeta 都存储一份 Schema，会对内存造成较大的压力。为了解决这个问题，实现了一个全局的 Schema Cache 管理相同的 Schema，这样就算有成千上万个 Rowset，只要 Schema 相同，内存中只会存在一份 Schema。

支持物化视图

Light Schema Change 也实现了对物化视图的支持。对读写流程修改之后，物化视图也可以正常读写。同时，如果要删除的列在物化视图中是 Value 列，则会与主表一起触发 Light Schema Change；如果主表的 Value 列是物化视图中的 Key 列，则需要发起异步任务，对物化视图进行 Sort/Direct Schema Change。

解决数据重写问题

由于 Delete Predicate 绑定了 Rowset，且每个 Rowset 都绑定了 Schema，当 Delete Predicate 所涉及的列被删除后，可以通过寻找到对应的 Rowset，Merge 该列的信息进当前的 Schema 中，这样对 Delete Predicate 之前的数据也可以正常过滤。解决了数据中有 Delete Predicate 需要重写数据的问题。

以上就是 Light Schema Change 功能实现过程中对 Doris 进行的修改，在使用的时候只需在建表的时候指定参数即可打开 Light Schema Change 功能，如下所示：

CREATE TABLE IF NOT EXISTS `customer` (
  `c_custkey` int(11) NOT NULL COMMENT "",
  `c_name` varchar(26) NOT NULL COMMENT "",
  `c_address` varchar(41) NOT NULL COMMENT "",
  `c_city` varchar(11) NOT NULL COMMENT "",
  `c_nation` varchar(16) NOT NULL COMMENT "",
  `c_region` varchar(13) NOT NULL COMMENT "",
  `c_phone` varchar(16) NOT NULL COMMENT "",
  `c_mktsegment` varchar(11) NOT NULL COMMENT ""
)
DUPLICATE KEY(`c_custkey`)
DISTRIBUTED BY HASH(`c_custkey`) BUCKETS 32
PROPERTIES (
"replication_num" = "1",
"light_schema_change" = "true"
);
 

性能对比

为进一步体验 Light Schema Change 的执行效率，我们在 1 FE 1 BE 的集群上对加减列操作分别在有导入任务时和无导入任务时进行了对比。硬件配置为 16C 64G，数据均在 SSD 盘，使用了 TPC-H SF100 的 lineitem 表，数据量约 74G，具体测试对比如下：

无导入任务时

加列：

1. Hard Link Schema Change： 耗时 1s 310ms。

1. Light Schema Change： 耗时 7ms

减列:

1. Hard Link Schema Change： 耗时 1s 438ms

1. Light Schema Change： 耗时 3ms

由上面测试可以看出，Light Schema Change 加减列速度远快于 Hard Link Schema Change，并且随着 BE 节点和表数据量的增多，Hard Link Schema Change 的耗时是远高于 Light Schema Change 的，原因是 Light Schema Change 只需要和 FE Master 进行交互，并可以实现同步返回。