使用场景：
kafka consumer
JSON 里的update 操作只带需要的列，非全部列，consumer 遇
到这种情况，会先根据JSON 里的主键去8A 库里查询这一行的所有列的值，然
后把要更新的列替换为新值，再根据主键执行delete，最后insert 一行。
使用方法：
1.需配置参数：
gcluster_kafka_ignore_pos_field = 1，配置这个参数让consumer 不检查POS。
_t_gcluster_kafka_ignore_when_update_not_hit = 1
当查询没命中时，consumer 忽
略当前这个操作，不对其进行同步。
这种情况下，JSON 里的OP_TYPE="UN"，而不是"U"。
2.
增加统计功能，统计每个批次的数据在kafka consumer 环节的延迟时间
需要配置参数：
gcluster_kafka_consumer_latency_time_statistics = 1
打开参数后，
consumer 会对checkpoint table 的列数进行扩充，
增加三列，
分别是：
GBase 8a MPP Cluster 产品手册
5 数据库管理指南
文档版本953（2022-09-15）
南大通用数据技术股份有限公司
1274
本批数据被consumer 接收到时的时间、consumer 对本批数据完成提交的时间、
本批次数据包含多少个dml 操作。
3.
支持对字符串中的0 进行转义，转为“\0”。
招行项目偶发性出现字符串中包含0（注意不是'\'+'0')，造成consumer 最终拼写
的sql 被这个0 截断。
需要配置参数gcluster_kafka_consumer_escape_zero=1.
非全列更新优化：
操作步骤:
1.
需要业务方保证源端表结构与8a 的表结构完全一致
2.
打开非全列更新控制参数
gcluster_kafka_consumer_support_partial_update
3.
确认更新不存在的记录时，是选择报错还是丢掉该记录继续同步数据，由参
数_t_gcluster_kafka_ignore_when_update_not_hit 控制，该参数值为1 时将丢
掉该记录继续同步；该参数值为0 时则报错停止同步。
优化实现：
非全列更新优化控制参数：gcluster_kafka_consumer_support_partial_update。打开
该参数，consumer 支持非全列更新功能，并且优化性能；关闭该参数，consumer
遇到非全列更新操作会报错。
注意：
该参数打开后，会增加consumer 的所有数据操作（insert，delete，全列update，
非全列update）的延迟，原理如下：
1.
非全列更新是根据更新条件（主键值），
先解析即从8a 中将该条件对应的整
条记录全列数据提出来，再入库即将提出来的整条记录做全列更新，更新语
句转化为delete+insert 执行。
2.
为了提高性能，非全列更新将攒批进行更新，即
(1)攒批到了commit_batch 的一半
(2)已经攒了2 秒钟的数据。
攒批的数据通过临时表储存，成批后统一到源表中提取全列数据做
delete+insert，这样对每个目标表来说，只执行一次查询动作，批量越大，单
条代价越小。
3.
解析和入库这两个环节串行化，前一批数据完成入库提交了，再解析下一批
数据。这样查询和提交串行化，优化了硬盘的使用。
注：
1.
consumer 对非全列更新操作的支持限制：当库里没这行数据时会造成丢数据
非全列更新时consumer 从kafka 读取的消息示例如下：
{“table”:”BDTEST.TEST4”,”op_type”:”UN”,”op_ts”:”2020-10-27
09:32:33.705303”,”current_ts”:”
2020-10-27
17:32:36.839000”,”pos”:”00000000030000002612”,”primary_keys”:{“
A”},”before”:{“A”:2},”after”:{“A”:2,”B”:200}}
其中before 域是主键信息，after 域是需要更新的字段信息，after 域并没有将所有
列update后的值都列出来，
相当于：
update BDTEST.TEST4 set A=2,B=200 where
A=2;
GBase 8a MPP Cluster 产品手册
5 数据库管理指南
文档版本953（2022-09-15）
南大通用数据技术股份有限公司
1275
2.
非全列更新性能优化后的提升还是比较明显，但是由于当前实现，非全列更
新还是很难完全达到全列更新的效率。