本发明涉及大数据分析技术领域，更具体的说，本发明涉及一种解决clickhouse删除和更新性能低下的同步方法。
背景技术：
随着物联网iot时代的来临，iot设备感知和报警存储的数据越来越大，有用的价值数据需要数据分析师去分析。大数据分析成了非常重要的环节。当然近两年开启的开源大潮，为大数据分析工程师提供了十分富余的工具。但这同时也增加了开发者选择合适的工具的难度，尤其对于新入行的开发者来说。学习成本，框架的多样化和复杂度成了很大的难题。例如kafka,hdfs,spark,hive等等组合才能产生最后的分析结果。把各种开源框架、工具、库、平台人工整合到一起所需工作之复杂，是大数据领域开发和数据分析师常有的抱怨之一，也是他们支持大数据分析平台简单化和统一化的首要原因。
clickhouse是yandex(俄罗斯最大的搜索引擎)开源的一个用于实时数据分析的基于列存储的数据库，其处理数据的速度比传统方法快100-1000倍。clickhouse的性能超过了目前市场上可比的面向列的dbms，每秒钟每台服务器每秒处理数亿至十亿多行和数十千兆字节的数据。
clickhouse对于低频率高吞吐量的查询写入速度非常快。特别适合使用在大量数据分析的场景。
clickhouse表中的数据存在以下问题：1、不支持真正的删除/更新，mergetree系列的表引擎虽然支持数据更新，但也只能保证最终一致性，在此之前会查询到多余数据。2、逐行insert或小批量的增、删、改操作时，底层会不断的做异步的数据合并影响提供服务的性能。
技术实现要素：
为了克服现有技术的不足，本发明提供一种解决clickhouse删除和更新性能低下的同步方法，可以实时准确返回增删改后的数据，解决clickhouse在小批量增、删、改操作所导致的性能问题。
本发明解决其技术问题所采用的技术方案是：一种解决clickhouse删除和更新性能低下的同步方法，其特征在于，该方法包括以下的步骤：
s1、将所需表的全量数据从源端数据库同步至目标数据库，并在同步过程中初始化数据；
s2、监听源端数据库中所需表的binlog，将二进制日志信息发送到kafka；
s3、存入已发送到kafka的binlog的位置到mongodb数据库；
s4、消费处理binlog中的增删改信息；
s5、设置当消费的binlog信息达到设定条数或者消费时间达到设定时间时，触发数据批量插入至目标数据库中的动作。
进一步的，步骤s1中，所需表的全量数据同步至目标数据库的过程为全量初始化数据。
进一步的，步骤s1中，源端数据库包括但不限于oracle数据库、mysql数据库、postgresql数据库以及mongodb数据库。
进一步的，步骤s1中，所述的目标数据库即为clickhouse。
进一步的，步骤s1中，通过datax工具或waterdrop工具实现全量数据的导入。
进一步的，步骤s4中，对于binlog中记录为更新的数据，将其改为insert的数据插入目标数据库对应的表中，并将操作标识字段op_type标记为更新而来的数据。
步骤s4中，对于删除数据，将表中删除标志置为1，并将操作标识字段op_type标记为删除数据,并以insert的形式插入目标数据库对应的表中。
进一步的，步骤s5中，设置消费的binlog信息的条数为5万条。
进一步的，步骤s5中，消费时间的设置值为1分钟。
进一步的，步骤s5中，将数据批量插入至目标数据库中的动作即为增量同步。
本发明的有益效果是：对于亿级别数据的聚合查询可以做到秒级甚至毫秒级返回；并且，可以准实时准确返回增删改后的数据，解决clickhouse在小批量增、删、改操作所导致的性能问题；另外，有比较好的容灾健壮性，可以处理同步进程崩溃或重启时导致的数据质量问题。通过引入kafka消息队列，对瞬时大事务同步时进行一个消峰，解决了大批量数据同步时的瞬时压力问题。
附图说明
图1为本发明的一种解决clickhouse删除和更新性能低下的同步方法的流程示意图。
图2为本发明的一种解决clickhouse删除和更新性能低下的同步方法的具体实施例图。
具体实施方式
下面结合附图和实施例对本发明进一步说明。
以下将结合实施例和附图对本发明的构思、具体结构及产生的技术效果进行清楚、完整地描述，以充分地理解本发明的目的、特征和效果。显然，所描述的实施例只是本发明的一部分实施例，而不是全部实施例，基于本发明的实施例，本领域的技术人员在不付出创造性劳动的前提下所获得的其他实施例，均属于本发明保护的范围。另外，专利中涉及到的所有联接/连接关系，并非单指构件直接相接，而是指可根据具体实施情况，通过添加或减少联接辅件，来组成更优的联接结构。本发明创造中的各个技术特征，在不互相矛盾冲突的前提下可以交互组合。
实施例1
参照图1、图2所示，本发明揭示了一种解决clickhouse删除和更新性能低下的同步方法，该方法包括以下的步骤：
s1、将所需表的全量数据从源端数据库同步至目标数据库；所需表的全量数据同步至目标数据库的过程为全量初始化数据；
本实施例中，通过datax工具或waterdrop工具实现全量数据的导入；如图2所示，源端数据库包括但不限于oracle数据库、mysql数据库、postgresql数据库以及mongodb数据库；并且，所述的目标数据库即为clickhouse。通过将数据同步到clickhouse，主要用来做分析统计。
s2、监听源端数据库中所需表的binlog，将二进制日志信息发送到kafka；
该步骤中，将消息发送到kafka是为了增加程序的健壮性、可靠性、可扩展性等。以及当数据库有大事务时还可以进行消峰，降低单台服务器的压力，根据业务情况通过分布式消费还可以增消费性能；
s3、存入已发送到kafka的binlog的位置到mongodb数据库；
考虑到有序的将binlog日志信息发送到kafka，并保证在同步增量数据的过程中程序出现异常也不会导致数据质量问题；由于数据库中的binlog是不断变化的，当程序进程出现异常重启时，可以查询意外中断时所保存的binlog位置，从此处继续监听binlog发送到kafka。不然如果一直监听最新的binlog会导致丢数据，如果从头开始监听会出现重复数据。
s4、消费处理binlog中的增删改信息；
对于binlog中记录为更新的数据，将其改为insert的数据插入目标数据库对应的表中，并将操作标识字段op_type标记为更新而来的数据。对于删除数据，将表中删除标志置为1，并将操作标识字段op_type标记为删除数据,并以insert的形式插入目标数据库对应的表中。
通过同一个消费组可以多个应用同时并发消费处理kafka上同一个binlog主题的消息，通过分布式消费可以增消费性能。由于业务都会有更新与删除，但是clickhouse的删除和更新性能非常低，clickhouse设计之初就不是为了存储需要频繁变动的数据，在建表时，会在表中多增加一个删除标志字段，当此数据有删除操作时会将其置1，查询时会屏蔽此标志位为1的数据。
s5、设置当消费的binlog信息达到设定条数，触发数据批量插入至目标数据库中的动作；在本实施例中，设置消费的binlog信息的条数为5万条。该过程即为增量同步。
步骤s5中，是为了解决clickhouse逐行插入或小批量的增、删、改操作时，底层不断做异步数据合并所导致的性能问题以及充分利用它批量写入的良好性能。对于大批量写入，clickhouse单机可以达到每秒10w条以上的写入速度。
实施例2
参照图1、图2所示，本发明揭示了一种解决clickhouse删除和更新性能低下的同步方法，该方法包括以下的步骤：
s1、将所需表的全量数据从源端数据库同步至目标数据库；所需表的全量数据同步至目标数据库的过程为全量初始化数据；
本实施例中，通过datax工具或waterdrop工具实现全量数据的导入；如图2所示，源端数据库包括但不限于oracle数据库、mysql数据库、postgresql数据库以及mongodb数据库；并且，所述的目标数据库即为clickhouse。通过将数据同步到clickhouse，主要用来做分析统计。
s2、监听源端数据库中所需表的binlog，将二进制日志信息发送到kafka；
该步骤中，将消息发送到kafka是为了增加程序的健壮性、可靠性、可扩展性等。以及当数据库有大事务时还可以进行消峰，降低单台服务器的压力，根据业务情况通过分布式消费还可以增消费性能；
s3、存入已发送到kafka的binlog的位置到mongodb数据库；
考虑到有序的将binlog日志信息发送到kafka，并保证在同步增量数据的过程中程序出现异常也不会导致数据质量问题；由于数据库中的binlog是不断变化的，当程序进程出现异常重启时，可以查询意外中断时所保存的binlog位置，从此处继续监听binlog发送到kafka。不然如果一直监听最新的binlog会导致丢数据，如果从头开始监听会出现重复数据。
s4、消费处理binlog中的增删改信息；
对于binlog中记录为更新的数据，将其改为insert的数据插入目标数据库对应的表中，并将操作标识字段op_type标记为更新而来的数据。对于删除数据，将表中删除标志置为1，并将操作标识字段op_type标记为删除数据,并以insert的形式插入目标数据库对应的表中。
通过同一个消费组可以多个应用同时并发消费处理kafka上同一个binlog主题的消息，通过分布式消费可以增消费性能。由于业务都会有更新与删除，但是clickhouse的删除和更新性能非常低，clickhouse设计之初就不是为了存储需要频繁变动的数据，在建表时，会在表中多增加一个删除标志字段，当此数据有删除操作时会将其置1，查询时会屏蔽此标志位为1的数据。
s5、消费时间达到设定时间时，触发数据批量插入至目标数据库中的动作；在本实施例中，消费时间的设置值为1分钟；该过程即为增量同步。
步骤s5中，是为了解决clickhouse逐行插入或小批量的增、删、改操作时，底层不断做异步数据合并所导致的性能问题以及充分利用它批量写入的良好性能。对于大批量写入，clickhouse单机可以达到每秒10w条以上的写入速度。
通过上述的陈述，本发明提供的一种解决clickhouse删除和更新性能低下的同步方法，对于亿级别数据的聚合查询可以做到秒级甚至毫秒级返回；并且，可以准实时准确返回增删改后的数据，解决clickhouse在小批量增、删、改操作所导致的性能问题；另外，有比较好的容灾健壮性，可以处理同步进程崩溃或重启时导致的数据质量问题。通过引入kafka消息队列，对瞬时大事务同步时进行一个消峰，解决了大批量数据同步时的瞬时压力问题。
以上是对本发明的较佳实施进行了具体说明，但本发明创造并不限于所述实施例，熟悉本领域的技术人员在不违背本发明精神的前提下还可做出种种的等同变形或替换，这些等同的变形或替换均包含在本申请权利要求所限定的范围内。
1.一种解决clickhouse删除和更新性能低下的同步方法，其特征在于，该方法包括以下的步骤：
s1、将所需表的全量数据从源端数据库同步至目标数据库；
s2、监听源端数据库中所需表的binlog，将二进制日志信息发送到kafka；
s3、存入已发送到kafka的binlog的位置到mongodb数据库；
s4、消费处理binlog中的增删改信息；
s5、设置当消费的binlog信息达到设定条数或者消费时间达到设定时间时，触发数据批量插入至目标数据库中的动作。
2.根据权利要求1所述的一种解决clickhouse删除和更新性能低下的同步方法，其特征在于，步骤s1中，所需表的全量数据同步至目标数据库的过程为全量初始化数据。
3.根据权利要求1所述的一种解决clickhouse删除和更新性能低下的同步方法，其特征在于，步骤s1中，源端数据库包括但不限于oracle数据库、mysql数据库、postgresql数据库以及mongodb数据库。
4.根据权利要求1所述的一种解决clickhouse删除和更新性能低下的同步方法，其特征在于，步骤s1中，所述的目标数据库即为clickhouse。
5.根据权利要求2所述的一种解决clickhouse删除和更新性能低下的同步方法，其特征在于，步骤s1中，通过datax工具或waterdrop工具实现全量数据的导入。
6.根据权利要求1所述的一种解决clickhouse删除和更新性能低下的同步方法，其特征在于，步骤s4中，对于binlog中记录为更新的数据，将其改为insert的数据插入目标数据库对应的表中，并将操作标识字段op_type标记为更新而来的数据。
7.根据权利要求6所述的一种解决clickhouse删除和更新性能低下的同步方法，其特征在于，步骤s4中，对于删除数据，将表中删除标志置为1，并将操作标识字段op_type标记为删除数据,并以insert的形式插入目标数据库对应的表中。
8.根据权利要求1所述的一种解决clickhouse删除和更新性能低下的同步方法，其特征在于，步骤s5中，设置消费的binlog信息的条数为5万条。
9.根据权利要求1所述的一种解决clickhouse删除和更新性能低下的同步方法，其特征在于，步骤s5中，消费时间的设置值为1分钟。
10.根据权利要求1所述的一种解决clickhouse删除和更新性能低下的同步方法，其特征在于，步骤s5中，将数据批量插入至目标数据库中的动作即为增量同步。
技术总结