然后通过结构聚合模块传播并在目标产品实体上聚合商品属性和属性值信息。商品实体的最终表示可以用于各种下游任务。
一、场景业务模型构建：重点在于如何自动化的构建出场景化的模型数据。大致的思路为：1）线上执行过后的订单数据存在诸多特征；2）根据线上落盘数据进行特征值分析；3）构建数据特征集合与对应的样本数据；
、特征决策：针对聚合出来的潜在特征，进行基于代码、经验、默认值等多种维度的判断，最终进行特征的推荐，这部分因为业务属性比较重，我们在推荐出来的同时
也就是为每条记录保存多份历史数据供读事务访问，新的写入只需要添加新的版本即可，无需等待。InnoDB在这里复用了Undo Log中已经记录的历史版本数据来满足MVCC的需求。
当前Page还空闲部分的开头，也就是下一条Undo Record要写入的位置。Undo Segment中的第一个Undo Page还会在56字节到86字节记录Undo Segment Header
其中Record 1在Undo Page 1中，Record 2，3在Undo Page 2中，先通过从Undo Segment Header中记录的Page List找到当前事务的最后一个Undo Page的Header
update类型的undo包括TRX_UNDO_UPD_EXIST_REC，TRX_UNDO_DEL_MARK_REC和TRX_UNDO_UPD_DEL_REC三种情况，他们的Undo回滚都是在row_undo_mod中进行，
之后在trx_sys_init_at_db_start中会扫描Undo的磁盘结构，遍历所有的Rollback Segment和其中所有的Undo Segment，通过读取Undo Segment Header中的State，
哪些事务已经提交哪些还在运行，根据Read Committed的要求，未提交的事务的修改就是不应该被看见的，对应地，已经提交的事务的修改应该被看到。
循环处理coordinator分配来的每一个Undo Records，先通过row_purge_parse_undo_rec，依次从Undo Record中解析出type、table_id、rollptr、对应记录的主键信息以及update vector。
