基于flink实现的端到端一致性数据实时处理方法及介质
技术领域：
：1.本发明涉及一种端到端一致性数据处理方法，尤其是涉及一种基于flink实现的端到端一致性数据实时处理方法及介质。
背景技术：
：：2.在数据实时处理相关业务系统中为了水平扩展，达到提高并发的目的，一般通过直接利用其底层组件的(或者间接实现)分布式特性实现。而在分布式系统中，通常由于各底层组件对于分布式的特性及性能表现不同，会产生数据不一致的情况。在本数据实时处理方案中，以技术选型为debezium、kafka、flink组件分别提供采集、传输、处理功能为例，为保证业务的正常运行，必须提供任务级端到端的一致性方案。3.端到端一致性是指在涉及cdc(变化数据捕捉)，如数据库实时同步、构建数据仓库、数据湖、实时分析、数据大屏等相关场景中，源端数据库经过过滤、清洗、脱敏、加密、转换等处理后，写入到目标端数据库时保证不会出现数据的丢失、重复、乱序等情况。当源端数据发生更改时，保证目标端及时、正确、持久的写入更改数据。端到端一致性包括两部分：严格的顺序保证、一致性语义exactlyonce(当流处理应用程序发生故障恢复时，同步到目标端的数据没有丢失或冗余重复)的保证。4.现有技术处理端到端一致性上还存在无法全面考虑各环节关系、一致性处理可靠性不高的不足。技术实现要素：5.本发明的目的就是为了克服上述现有技术存在的缺陷而提供一种保证端到端始终一致的基于flink实现的端到端一致性数据实时处理方法。6.本发明的目的可以通过以下技术方案来实现：7.一种基于flink实现的端到端一致性数据实时处理方法，该方法应用于flink流式数据处理运行环境，包括以下步骤：8.1)获取topic，所述topic包括schematopic和datatopic，将每一topic转换为一条数据流，所述数据流包括schemastream和datastream；9.2)对每一所述数据流进行数据预处理；10.3)对所述schemastream按设定键进行分流，将切分出的数据与该设定键对应的datastream融合，形成重新融合后的多条数据流；11.4)基于watermark和窗口技术对接收的数据流进行排序及相应业务处理；12.5)采用两阶段提交方式将处理后数据插入到目标端。13.进一步地，所述schematopic包含所有库和表的数据定义语句。14.进一步地，每张表对应一个所述datatopic，该datatopic包含关于该表的数据操纵语句。15.进一步地，所述数据预处理包括将json转为pojo以及空数据过滤。16.进一步地，所述设定键为库名与表名的结合。17.进一步地，所述多条数据流包括融合后的数据流以及schemastream中其余数据形成的数据流。18.进一步地，所述基于watermark和窗口技术对接收的数据流进行排序具体为：19.为每一条数据流配置对应的watermark、事件时间、窗口大小以及窗口函数；20.在接收每一条数据流时，基于watermark等待迟到数据，并基于所述窗口大小将窗口内数据按照事件时间排序，触发后续的窗口函数。21.进一步地，所述业务处理包括数据库实时同步、构建数据仓库、数据湖、实时分析和/或数据大屏处理。22.进一步地，所述两阶段提交方式具体为：23.51)上一个数据库事件完成时，开启一个新的事务，本次事务中每条数据到来时触发一次数据写入；当前数据库事件到来时，对本次事务进行预提交，如果数据写入和预提交全部成功，则表示第一个阶段成功，否则触发终止回滚事务；24.52)当所有的操作实例完成数据库事件，且都执行完预提交时，产生所有操作实例执行正式提交的指令，完成正式提交。25.本发明还提供一种计算机可读存储介质，包括供电子设备的一个或多个处理器执行的一个或多个程序，所述一个或多个程序包括用于执行如上所述基于flink实现的端到端一致性数据实时处理方法的指令。26.与现有技术相比，本发明具有以下有益效果：27.1)通过watermark、窗口解决kafka单分区内部的乱序问题，通过全局watermark解决流级别多分区之间的乱序问题，可达到表级别的实时同步，行级别的端到端一致性。28.2)通过将schemastream和datastream分流与融合的方式解决了schematopic和datatopic的乱序问题，保证了表结构增量修改前后，端到端始终一致。29.3)2pc中通过开启事务避免了容错恢复时导致目标端出现的幂等性问题，本发明仅解析before、after数据，避免了直接执行sql语句导致的幂等性问题。30.4)异常、任务暂停等情况下通过checkpoint和savepoint支持断点续传，不影响端到端的一致性。附图说明31.图1为kafka消息分区示意图；32.图2为flink并行任务处理示意图；33.图3为本发明应用的整体框架示意图；34.图4为处理数据时顺序的理想情况和实际情况；35.图5为流级顺序示意图；36.图6为独立处理schemastream、datastream导致的任务级乱序问题；37.图7为解决任务级乱序问题设计的分流与融合的方案；38.图8为本发明端到端一致性数据处理的流程图。具体实施方式39.下面结合附图和具体实施例对本发明进行详细说明。本实施例以本发明技术方案为前提进行实施，给出了详细的实施方式和具体的操作过程，但本发明的保护范围不限于下述的实施例。40.1、问题的提出41.端到端一致性涉及的各组件debezium、kafka、flink，构成了端到端一致性中至关重要的每一环。为了实现更可靠的端到端一致性数据实时处理，需要充分考虑、分析各组件的对于顺序、一致性语义特性的支持。42.(1)顺序保证43.debezium作为采集组件，为采集到的表结构、行数据都提供了事件时间字段，为后续按照事件时间处理数据提供了依据。kafka为了做到水平扩展，将一个topic的数据分布到多个partition(分区)中，每个partition是一个有序的队列，如图1所示，而各个partition中的消息比较独立，很难有一种高效的方法来判断不同partition中数据的顺序。44.flink本质上是分布式框架。每个算子可以单独设置并行度，由此产生一个或多个算子子任务，每个子任务彼此独立，并在不同的线程、节点或容器中运行，如图2所示。flink算子之间可以通过一对一模式或重分区模式传输数据。45.如图2中的source和map算子之间采用的一对一模式，该模式可以保留元素的分区和顺序信息。即同一分区的数据只会进入到下游算子的同一分区；如图2中的map和keyby/window算子之间，以及keyby/window和sink算子之间采用的重分区模式，该模式会更改数据所在的流分区，把数据发送到不同的目标子任务。当涉及到重分区的算子时，不同键的数据到达下游的顺序是不确定的。46.debezium通过kafkatopic(包括schematopic用于记录表结构变化、datatopic用于记录行数据变化)将采集到的数据发送出去，但当schematopic中涉及到增量表结构修改时，无法保证schematopic中表结构变化数据与datatopic中数据之间的顺序。47.(2)一致性保证48.为实现exactlyonce语义的一致性，必须提供处理过程的容错性以及处理结果的幂等性。处理过程的容错性是指当计算过程中数据还没插入目标端就发生网络异常等情况导致程序重启，会出现数据丢失的问题，为此源端必须可重设数据的读取位置，同时配合flink内部的checkpoint机制来解决这个问题。kafka可以设置读取的offset，每次做checkpoint的时候，会把当前消费kafka的offset、计算结果等写入到状态后端中。任务异常恢复的时候，只需要从最近的一次成功的checkpoint中拿到offset和计算结果，从当前offset继续消费和计算即可。幂等性指的是要求目标端从故障恢复时，数据不会因为重设读取位置和重新计算，而被重复写入到外部系统。49.因此，为实现端到端一致性的数据实时处理方案，必须解决顺序保证中的三大难点：kafka多分区、flink重分区、schematopic和datatopic的乱序；一致性保证中的一大难点：数据插入到目标端的幂等性。50.2、本发明构思51.无论在数据库实时同步、构建数据仓库、数据湖、实时分析、数据大屏等任一相关场景中，端到端一致性都是衡量业务功能正确性的重要标准，当源端发生表结构(schema)、行数据(data)的更改时，需要保证数据在经过相应处理之后，能够正确、及时地写入到以满足上任一场景的目标端。其中schema的正确同步是data正确同步的重要前提。本发明通过分析上述各底层组件基本特性对于一致性的支持情况，结合数据库实时同步、构建数据仓库、数据湖、实时分析、数据大屏等场景，提出了一种基于flink实现的端到端一致性数据实时处理方法。具体地，本发明从分区级、流级、任务级提出了能够保证schema、data的一致性，同时克服了kafka多分区、flink重分区乱序的问题；在容错性的基础上引入两阶段提交的方式解决了exactlyonce语义一致性保证中的幂等性问题。52.本发明的应用场景整体框架结构如图3所示，其中，datasource(源端)、datasink(目标端)中的rds代表关系型数据库，以技术选型为debezium、kafka、flink组件分别提供采集、传输和处理服务。本发明将问题拆分为两方面解决，并提供了对应的解决方案：顺序保证、一致性保证。53.(1)顺序保证54.用flink处理来自kafka的数据时，可为每一个topic(schematopic、datatopic)创建一个消费者，对应转换为一条流(schemastream、datastream)，每一个流单独处理，互不影响。但流内数据依然存在上述的kafka多分区、flink多并行度、schematopic和datatopic的乱序导致的乱序问题。55.11)单分区顺序56.为解决乱序问题，需要对数据进行排序，但是对于一个无界数据数据流无法进行排序，由此引入窗口的概念，将有界数据流切分为一个个有界的窗口，在窗口内便于执行排序操作。57.本发明通过引入watermark(数据流中的watermark用于表示事件时间小于watermark的数据都已经到达了)和窗口(在窗口内按照事件时间处理该窗口内的数据)的特性，以保证单分区内数据处理顺序。达到的实际效果如图4所示，假设窗口时间是5秒，圆圈中的数字代表该数据的事件时间(以秒为单位)，当数据5到来时不应该立即关闭该窗口并触发计算，而应该将本窗口中的数据暂存于内存中，等到数据2、3到来时，再关闭窗口及触发后续的窗口函数。58.12)流级顺序59.上述使用watermark和窗口可以解决单分区内部的乱序问题，并不能保证多分区乱序，而watermark是一个流层面全局的概念，即一个流中维护一个全局的watermark，通过使用全局watermark可以保证流中多并行任务之间的顺序，如图5所示。60.全局watermark的值取决于并行子任务watermark的最小值。图5中流的并行度为4，partitionwm代表单个并行子任务的watermark，event-timeclock代表该流中全局watermark。上图中四个时刻的event-timeclock均为各分区partitionwm的最小值，其他分区中所有大于event-timeclock的数据均暂存于内存中，对下游算子及目标端不可见，由此保证流内多分区之间的顺序。61.在优选的实施方式中，为减小各分区之间的watermark差值，可以在kafka分区使用轮询策略。62.13)任务级顺序63.上述流内乱序引入window、watermark之后即可解决，但是为达到任务级别的顺序要求，不能只解决流内乱序，因为schemastream和datastream并非完全独立。64.如图6所示，假设表tab1的原始结构为：(`uid`bigint(20),`name`varchar(50))，alter代表：altertable`tab1`changecolumn`name``uname`varchar(50)。图中，当schemastream中的alter语句已经处理完毕，而datastream中的数据出现堆积，则会在数据插入到目标端时，出现unknowncolumnname(数据库表中对应列不存在)的错误；当datastream中的数据已经到来，而schemastream中的数据出现堆积时，则会出现unknowncolumnuname(数据库表中对应列不存在)的错误。65.以上两个实例说明schemastream和datastream之间可能出现乱序的情况，为了保证任务级顺序，需要在多流之间进行分流与融合的操作，如图7所示：将schemastream中关于tab1的数据分出来，与tab1的datastream进行融合。同时保证分区内顺序和流级顺序，即可解决任务级乱序问题。66.(2)一致性保证67.实现一致性的难点在于目标端要求从故障恢复时，数据不能重复写入外部系统，对于关系型数据库来说，开启事务即可避免此问题，但对于一个分布式处理系统，如何开启一个分布式事务，或者目标端本身是否支持(分布式)事务成为关键，由此引入两阶段提交的概念。68.两阶段提交(two-phasecommit，以下简称2pc)是指在计算机网络以及数据库领域内，为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法。在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时，为了保持事务的acid(原子性、一致性、隔离性、持久性)特性，需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果，并最终指示这些节点是否要把操作结果进行真正的提交。因此，2pc的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈信息决定各参与者是否要提交操作还是中止操作。69.flink将2pc的逻辑放在checkpoint的过程之中，并给出了实现模板类twophasecommitsinkfunction，twophasecommitsinkfunction中定义了5个抽象方法：begintransaction()用于开启事务，可从连接池中获取连接，并返回事务句柄；invoke()每来一条数据就会触发一次，当前数据为schema时，可直接执行对应的query语句，当前数据为data时，按照元数据中的变更类型r(全量)、c(增量插入)、u(增量更新)、d(增量删除)、before(变更前数据)、after(变更后数据)、db(库名)、table(表名)等信息重组对应的sql语句，将数据写入到已开启的事务中；precommit()预提交后的事务将不会再接收数据的写入；commit()提交指定事务；abort()用于终止并回滚指定事务。twophasecommitsinkfunction中的上述抽象方法与两阶段提交的执行流程如下：70.21)上一个checkpoint完成时，会开启一个新的事务begintransaction，本次事务中每条数据到来时触发一次invoke；当前checkpoint到来时，会对本次事务进行预提交precommit。如果invoke和precommit全部成功了，才表示第一个阶段成功了。如果在第一个阶段中有机器故障，或者invoke、precommit失败，则会触发abort方法。71.22)当所有的operator实例做完checkpoint，并且都执行完precommit时，会把快照完成的消息发送给jobmanager，jobmanager收到后认为本次checkpoint全部完成了，通知所有operator实例执行commit方法正式提交。72.另对于关系型数据库以外的其他目标端，可采用以下方式实现一致性保证：73.1)对于非关系型数据库的目标端如hbase、redis和cassandra这样的key-value数据库，由于其自身维护了行键(rowkey是用来检索记录的主键)，因此其自身是幂等的，不需要实现外部一致性保证。74.2)对于文件系统类型的目标端如ftp(远程文件传输协议)、hdfs(hadoop分布式文件系统)等，可以使用其内部的二阶段提交协议，假如数据写入完成，进度记录失败，将会回滚(删除)已写入目标端的数据。75.3)对于数据仓库或数据湖类型的目标端如hive、hudi、iceberg等，可以使用预写日志的方式，将所有的变化数据在真正提交之前先写入日志文件中，而在flink中可以将其先当成状态保存，在收到checkpoint完成的通知时，再一次性写入目标端。76.4)对于kafka目标端，可以使用kafka本身的事务功能，在进度被提交成功前，kafka内的数据无法消费，以保证写入数据的数据一致性。77.上述为实现数据实时处理的端到端一致性，将问题拆分为两方面解决，并提供了对应的解决方案：顺序保证、一致性保证，包括以下步骤：1)获取topic，所述topic包括schematopic和datatopic，将每一topic转换为一条数据流，所述数据流包括schemastream和datastream；2)对每一所述数据流进行数据预处理；3)对所述schemastream按设定键进行分流，将切分出的数据与该设定键对应的datastream融合，形成重新融合后的多条数据流；4)基于watermark和窗口技术对接收的数据流进行排序及相应业务处理；5)采用两阶段提交方式将处理后数据插入到目标端。78.下面将方案作为整体流程给出实施实例。79.如图8所示，主要包括三大步骤：source、process、sink，详细步骤如下：80.1)开始并创建flink流式数据处理运行环境，并进行相应配置，执行步骤2。81.2)解析、校验kafkatopic及目标端等参数，执行步骤3。82.3)创建一个消费者，订阅schematopic(该topic中包含所有库、表的ddl)，为每个datatopic(debezium为每张表一个datatopic，其中包含关于该表的dml语句)创建一个消费者，执行步骤4。83.4)将消费者中的读取到数据转为数据流(schemastream、datastream)，执行步骤5。84.5)将schemastream、datastream流中的数据经过map算子将json转为pojo、filter过滤空数据等，执行步骤6。85.6)按照"库名.表名"作为键，将schemastream分流，执行步骤7。86.7)将切分出的schemastream与对应的datastream融合，融合后的数据流以及schemastream中其余数据流继续执行以下操作，执行步骤8。87.8)为每一条数据流配置watermark(用于等待迟到数据，可根据业务场景设置具体数值，对于实时性要求较高的场景建议设置毫秒级watermark)和事件时间(用于后续按照事件时间在窗口内部排序)，执行步骤9。88.9)为每一条数据流配置窗口大小(窗口大小同样影响到程序的实时性，建议设置毫秒级窗口大小)以及窗口函数，执行步骤10。89.10)将窗口内数据按照事件时间排序，执行步骤11。90.11)业务处理(包含数据库实时同步、构建数据仓库、数据湖、实时分析、数据大屏等场景的业务逻辑，不进行详细展开)，执行步骤12。91.12)2pcsink：实现twophasecommitsinkfunction中的相关函数，将数据插入到目标端，执行步骤13。92.13)执行步骤4，继续处理流式程序中的下一条数据。93.以上详细描述了本发明的较佳具体实施例。应当理解，本领域的普通技术人员无需创造性劳动就可以根据本发明的构思作出诸多修改和变化。因此，凡本
技术领域：
：中技术人员依本发明的构思在现有技术的基础上通过逻辑分析、推理或者有限的实验可以得到的技术方案，皆应在由权利要求书所确定的保护范围内。当前第1页12当前第1页12