CN115374102A - 数据处理方法及*** - Google Patents

Abstract

本申请公开了一种数据处理方法及***，涉及大数据领域，其中该方法包括：通过canal服务将服务实例伪装成MySQL从库节点获取对应主库的数据操纵语言DML和数据定义语言DDL日志；将获取到的所述数据操纵语言DML和数据定义语言DDL日志输出到kafka中；根据设定业务的使用场景配置的同步任务将所述kafka中的binlog数据通过设定方式同步输出到设定的数据存储组件中；本申请提供的方法及***，可以帮业务部门人员快速接入数据，节省了传统数据同步带来的人力开发和维护成本，大大提高的工作效率，并能支持对异常数据的修复，满足多种数据组件间的数据同步需求，保证了按数据对业务决策的及时性。

Description

数据处理方法及***

技术领域

本发明涉及大数据和互联网技术领域，尤其是一种数据处理方法及***。

背景技术

传统的MySQL不能支撑对大量数据、按各种复杂的业务场景进行分析，即使采用了分库分表方案也很难针对海量业务实时生成决策报表；传统数据同步方案，是将数据表对应的schema维护到excel中，通过编写好的程序完成数据的一次性写入；这种管理方式只能进行T+1数据导入，无法实现数据的实时性，对于业务进度整体滞后；单次导入数据量过大严重影响数据组件的性能，很大情况下导入时数据组件不可用；大数据HDFS集群的存储空间也在不断增长，数据表和ETL任务数以万计，依靠人工处理已变得不可能，因此推出基于HIVE表的生命周期管理***，进行自动化处理。。

有鉴于此，需要提供一种支持多种类型数据和复杂业务场景的数据同步方法以解决上述问题。

发明内容

本发明实施例所要解决的一个技术问题是如何提供一种支持多种类型数据和复杂业务场景的数据同步处理方法及***以解决现有技术中的难题。

为了应对上述场景，第一方面，本申请的实施方式提供一种数据处理方法，包括：通过canal服务将服务实例伪装成MySQL从库节点获取对应主库的数据操纵语言DML和数据定义语言DDL日志；将获取到的所述数据操纵语言DML和数据定义语言DDL日志输出到kafka中；根据设定业务的使用场景配置的同步任务将所述kafka中的binlog数据通过设定方式同步输出到设定的数据存储组件中。

结合第一方面，在一些实施方式中，所述设定业务的使用场景配置的同步任务包括：任务创建时选择需要同步的库表，指定同步类型及同步方法，所述同步类型包括：存量与实时同步、存量同步、实时同步。

结合第一方面，在一些实施方式中，创建索引或表以支持根据待同步数据的schema自动创建tidb表或es索引模板。

结合第一方面，在一些实施方式中，同步至es时指定索引名并指定MySQL字段与es字段的映射关系；同步至tidb时指定目标集群、库、表。

结合第一方面，在一些实施方式中，所述将所述kafka中的binlog数据通过设定方式同步输出到设定的数据存储组件中包括：任务启动后在程序协调服务zookeeper中下发设定通知，数据同步服务监听到所述zookeeper下发的所述设定通知消息后，根据配置的kafka topic信息启动新的消费者线程，以设定时间间隔或批次大小拉取数据，当出现处理过程发生异常时将未处理成功的数据发送至kafka的临时topic中，任务在重试过程中重新消费处理异常的数据，其中，所述数据异常包括但是不限于依赖的组件服务异常、网络异常、云服务异常。

结合第一方面，在一些实施方式中，实时的对输出日志进行监控，发生异常时将异常条数和内容发送至设定客户端；在消费kafka消息如果业务量突增导致出现阻塞时，根据阻塞情况进行参数动态调优。

结合第一方面，在一些实施方式中，任务审批时核验数据处理时各部分准备工作是否都完善以保证数据同步的准确性；核验数据处理时驳回不合法的配置或驳回不适合同步的任务。

结合第一方面，在一些实施方式中，通过canal服务同步工具将数据写入到kafka对应的topic中，包含：数据库权限申请、白名单配置、topic映射配置、数据格式转换、数据写入。

结合第一方面，在一些实施方式中，用户根据需同步表所在的库申请对应主库的读权限以便开启canal拉取MySQL binlog的权限。

结合第一方面，在一些实施方式中，按照实际业务需求开启对应库表的白名单、屏蔽非必要的库表数据。

结合第一方面，在一些实施方式中，根据白名单配置自动生成映射关系，所述映射关系包括指定库表数据落入kafka的哪个设定主题，其中，可按库或表分别指定，配置完成后以支持kafka topic的自动创建。

结合第一方面，在一些实施方式中，将canal接入的binlog数据按照对象模式转换为json格式。

结合第一方面，在一些实施方式中，根据白名单与topic映射关系，将数据写入到指定的topic中。

结合第一方面，在一些实施方式中，还包括：数据输出支持输出的存储组件包括但不限于kudu，elasticsearch，tidb和hdfs；和/或，所述数据输出支持写入和/或数据修复的功能。

结合第一方面，在一些实施方式中，所述方法还包括：根据校验结果针对文件中的数据通过指定待修复数据的条件进行数据修复。

结合第一方面，在一些实施方式中，还包括：在设定时间段的设定时间校验上一个设定时间段的数据；将不一致的数据与原因输出到对应的文件中以便于问题定位与数据修复使用。

结合第一方面，在一些实施方式中，还包括：在数据深度学***台上创建同步任务后，调用审批接口将数据写入到分布式应用程序协调服务zookeeper中；数据同步服务通过监听分布式应用程序协调服务zookeeper节点变化，根据所述节点的变化情况决定是否启动新的同步任务；数据监控服务对新任务的数据一致性进行定时监控；新的同步任务启动后，根据配置时指定的输入和输出方式从数据源拉取数据；将获取的数据实时同步至数据存储组件中，如果在执行数据同步的过程中出现了数据不一致情况通过改流程创建存量数据同步任务修复数据。

第二方面，本申请的实施方式提供了一种数据处理方法，还包括：采用springboot进行构建数据处理服务，依托DI调度***建设元数仓；

zookeeper接收所述DI调度***发送的任务队列：

动态监听所述zookeeper节点的变化以实现数据生命周期管理DLM分布式部署；

数据生命周期管理DLM根据设定配置规则进行相关处理以实现HIVE表数据的全链路分析处理，所述处理包括但是不限于同步处理。

结合第二方面，在一些实施方式中，还包括：

采用springboot进行构建同步服务；

通过动态监听zookeeper节点新增、删除操作，发布和下线数据同步任务；

源数据按照设定规则从kafka消费以进行数据同步数据、并将消费得到的数据输出到指定的数据库组件中。

结合第二方面，在一些实施方式中，还包括：所述设定配置规则包括：

在深度学习DI***的集群表操作页面中加入基于Hive数据表的生命周期管理配置，用户在建表操作按照设定需求情况进行规则配置；

在深度学习DI***的配置定时任务按照预先设定规则自动对HIVE数据表进行生命周期规则配置。

结合第二方面，在一些实施方式中，还包括：元数仓建设包括数据终端的数据采集、根据标签规则进行数据清洗。

结合第二方面，在一些实施方式中，还包括：数据采集入仓包括：

针对数据抽取转换装载ETL任务，通过任务解析,SQL解析采集方式以调度任务上报入仓；针对h-HOOK，通过HIVE拦截用户执行SQL并解析以调度任务上报入仓；针对邮件***，通过邮件SQL解析,并邮件埋点打开数据上报，通过消费kafka入库,在通过调度任务上报入仓；针对报表***通过解析报表***中的SQL解析log日志并通过调度任务上报入仓；

结合第二方面，在一些实施方式中，还包括：创建元数仓调度并配置相关ETL任务，根据标签进行数据清洗。

结合第二方面，在一些实施方式中，还包括：通过zookeeper实现分布式部署并通过zookeeper作为消息一致性的通知媒介，执行任务计算的下发与执行。

第三方面，本申请的实施方式提供了一种数据同步处理***，其特征在于，包括：获取模块，被配置为通过canal服务将服务实例伪装成MySQL从库节点获取对应主库的数据操纵语言DML和数据定义语言DDL日志；发送模块，与所述获取模块相连接，被配置为将获取到的所述数据操纵语言DML和数据定义语言DDL日志输出到kafka中；处理模块，所述发送模块相连接，被配置为根据设定业务的使用场景配置的同步任务将所述kafka中的binlog数据通过设定方式同步输出到设定的数据存储组件中。

结合第三方面，在一些实施方式中，还包括：任务创建模块，被配置为选择需要同步的库表，指定同步类型及同步方法，所述同步类型包括：存量与实时同步、存量同步、实时同步；创建模块，被配置为创建索引或表以支持根据待同步数据的schema自动创建tidb表或es索引模板；其中，同步至es时指定索引名并指定MySQL字段与es字段的映射关系；同步至tidb时指定目标集群、库、表。

结合第三方面，在一些实施方式中，还包括：任务运行模块，被配置为任务启动后在程序协调服务zookeeper中下发设定通知，数据同步服务监听到所述zookeeper下发的所述设定通知消息后，根据配置的kafka topic信息启动新的消费者线程，以设定时间间隔或批次大小拉取数据，当出现处理过程发生异常时将未处理成功的数据发送至kafka的临时topic中，任务在重试过程中重新消费处理异常的数据，其中，所述数据异常包括但是不限于依赖的组件服务异常、网络异常、云服务异常；实时监控模块，实时的对输出日志进行监控，发生异常时将异常条数和内容发送至设定客户端；在消费kafka消息如果业务量突增导致出现阻塞时，根据阻塞情况进行参数动态调优。

结合第三方面，在一些实施方式中，任务审批模块，被配置为核验数据处理时各部分准备工作是否都完善以保证数据同步的准确性；和/或，任务审批模块还被配置为核验数据处理时驳回不合法的配置或驳回不适合同步的任务。

结合第三方面，在一些实施方式中，权限申请模块，被配置为通过canal服务同步工具将数据写入到kafka对应的topic中，包含：数据库权限申请、白名单配置、topic映射配置、数据格式转换、数据写入。

结合第三方面，在一些实施方式中，还包括权限申请模块，被配置为根据需同步表所在的库申请对应主库的读权限以便开启canal拉取MySQL binlog的权限。

结合第三方面，在一些实施方式中，还包括白名单模块，被配置为按照实际业务需求开启对应库表的白名单、屏蔽非必要的库表数据。

结合第三方面，在一些实施方式中，还包括映射配置模块，被配置为根据白名单配置自动生成映射关系，所述映射关系包括指定库表数据落入kafka的哪个设定主题，其中，可按库或表分别指定，配置完成后以支持kafka topic的自动创建。

结合第三方面，在一些实施方式中，还包括数据格式转换模块，被配置为将canal接入的binlog数据按照对象模式转换为json格式。

结合第三方面，在一些实施方式中，还包括数据写入模块，被配置为根据白名单与topic映射关系，将数据写入到指定的topic中。

结合第三方面，在一些实施方式中，还包括：数据输出模块，被配置为数据输出支持输出的存储组件包括但不限于kudu，elasticsearch，tidb和hdfs；和/或，所述数据输出模块支持写入和/或数据修复的功能；

结合第三方面，在一些实施方式中，还包括异常数据修复模块，被配置为根据校验结果针对文件中的数据通过指定待修复数据的条件进行数据修复。

结合第三方面，在一些实施方式中，还包括：数据校验模块，被配置为在设定时间段的设定时间校验上一个设定时间段的数据；将不一致的数据与原因输出到对应的文件中以便于问题定位与数据修复使用。

本申请实施例提供的基于大数据技术和互联网技术的数据同步方法及***，是一个资源智能自动优化***，可以帮业务部门人员快速接入数据，节省了传统数据同步带来的人力开发和维护成本，大大提高的工作效率，并能支持对异常数据的修复，满足多种数据组件间的数据同步需求，保证了按数据对业务决策的及时性。

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

附图说明

构成说明书的一部分的附图描述了本发明的实施例，并且连同描述一起用于解释本发明的原理。

参照附图，根据下面的详细描述，可以更加清楚地理解本发明，其中：

图1示出本申请一个实施例的数据处理方法的流程图。

图2示出本申请一个实施例的数据处理***的结构示意图。

图3示出本申请另一个实施例的数据处理方法的流程图。

图4示出本申请又一个实施例的数据处理方法的流程图。

图5示出本申请一个实施例的数据处理方法的***状态示意图。

图6示出本申请再一个实施例的数据处理方法的流程图。

图7示出本申请一个实施例的数据处理***的结构框图。

具体实施方式

下面结合具体实施例和附图对本申请做进一步说明。可以理解的是，本公开的说明性实施例包括但不限于相关的方法、设备和***，此处描述的具体实施例仅仅是为了解释本申请，而非对本申请的限定。此外，为了便于描述，附图中仅示出了与本申请相关的部分而非全部的结构或过程。

以下由特定的具体实施例说明本申请的实施方式，本领域技术人员可由本说明书所揭示的内容轻易地了解本申请的其他优点及功效。虽然本申请的描述将结合较佳实施例一起介绍，但这并不代表此发明的特征仅限于该实施方式。恰恰相反，结合实施方式作发明介绍的目的是为了覆盖基于本申请的权利要求而有可能延伸出的其它选择或改造。为了提供对本申请的深度了解，以下描述中将包含许多具体的细节。本申请也可以不使用这些细节实施。此外，为了避免混乱或模糊本申请的重点，有些具体细节将在描述中被省略。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

此外，各种操作将以最有助于理解说明性实施例的方式被描述为多个离散操作；然而，描述的顺序不应被解释为暗示这些操作必须依赖于顺序。特别是，这些操作不需要按呈现顺序执行。

除非上下文另有规定，否则术语“包含”，“具有”和“包括”是同义词。

本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。短语“A/B”表示“A或B”。

本申请中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a,b,或c中的至少一项(个)，可以表示：a,b,c,a-b,a-c,b-c,或a-b-c，其中a,b,c可以是单个，也可以是多个。

在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

在一些情况下，所公开的实施例可以以硬件、固件、软件或其任何组合来实现。所公开的实施例还可以被实现为由一个或多个暂时或非暂时性机器可读(例如，计算机可读)存储介质承载或存储在其上的指令，其可以由一个或多个处理器读取和执行。例如，指令可以通过网络或通过其他计算机可读介质的途径分发。因此，机器可读介质可以包括用于以机器(例如，计算机)可读的形式存储或传输信息的任何机制、但不限于、软盘、光盘、光盘、只读存储器(CD-ROM)、磁光盘、只读存储器(ROM)、随机存取存储器(RAM)、可擦除可编程只读存储器(EPROM)、电可擦除可编程只读存储器(EEPROM)、磁卡或光卡、闪存、或用于通过电、光、声或其他形式的传播信号(例如，载波、红外信号、数字信号等)通过因特网传输信息的有形的机器可读存储器。因此，机器可读介质包括适合于以机器(例如，计算机)可读的形式存储或传输电子指令或信息的任何类型的机器可读介质。

在附图中，以特定布置和/或顺序示出一些结构或方法特征。然而，应该理解，可以不需要这样的特定布置和/或排序。在一些实施例中，这些特征可以以不同于说明性附图中所示的方式和/或顺序来布置。另外，在特定图中包含结构或方法特征并不意味着暗示在所有实施例中都需要这样的特征，并且在一些实施例中，可以不包括这些特征或者可以与其他特征组合。

应当理解的是，虽然在这里可能使用了术语“第一”、“第二”等等来描述各个单元或是数据，但是这些单元或数据不应当受这些术语限制。使用这些术语仅仅是为了将一个特征与另一个特征进行区分。举例来说，在不背离示例性实施例的范围的情况下，第一特征可以被称为第二特征，并且类似地第二特征可以被称为第一特征。

应注意的是，在本说明书中，相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请的实施方式作进一步地详细描述。

如本文所使用的，术语“模块或单元”可以指或者包括专用集成电路(ASIC)、电子电路、执行一个或多个软件或固件程序的处理器(共享的、专用的或组)和/或存储器(共享的、专用的或组)、组合逻辑电路、和/或提供所描述的功能的其他合适的组件，或者可以是专用集成电路(ASIC)、电子电路、执行一个或多个软件或固件程序的处理器(共享的、专用的或组)和/或存储器(共享的、专用的或组)、组合逻辑电路、和/或提供所描述的功能的其他合适的组件的一部分。

现在将参照附图来详细描述本发明的各种示例性实施例。应注意到：除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本发明的范围。

同时，应当明白，为了便于描述，附图中所示出的各个部分的尺寸并不是按照实际的比例关系绘制的。

以下对至少一个示例性实施例的描述实际上仅仅是说明性的，决不作为对本发明及其应用或使用的任何限制。

对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为说明书的一部分。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。

本发明实施例可以应用于计算机***/服务器，其可与众多其它通用或专用计算***环境或配置一起操作。适于与计算机***/服务器一起使用的众所周知的计算***、环境和/或配置的例子包括但不限于：个人计算机***、服务器计算机***、瘦客户机、厚客户机、手持或膝上设备、基于微处理器的***、机顶盒、可编程消费电子产品、网络个人电脑、小型计算机***﹑大型计算机***和包括上述任何***的分布式云计算技术环境，等等。

计算机***/服务器可以在由计算机***执行的计算机***可执行指令(诸如程序模块)的一般语境下描述。通常，程序模块可以包括例程、程序、目标程序、组件、逻辑、数据结构等等，它们执行特定的任务或者实现特定的抽象数据类型。计算机***/服务器可以在分布式云计算环境中实施，分布式云计算环境中，任务是由通过通信网络链接的远程处理设备执行的。在分布式云计算环境中，程序模块可以位于包括存储设备的本地或远程计算***存储介质上。

现有技术是数据同步处理按照业务按照需求迭代，开发任务进行数据同步耗时周期长并且易造成大量的重复性工作，特别是同步时涉及到的存量数据与实时数据衔接问题，对保证同步前后的数据一致性造成困难，很大程度上需要人为干预，增加了维护成本。

图1示出本申请一个实施例的数据处理方法的流程图，如图1所示，该方法流程包括：

步骤101，通过canal服务将服务实例伪装成MySQL从库节点获取对应主库的数据操纵语言DML和数据定义语言DDL日志。

步骤102、将获取到的所述数据操纵语言DML和数据定义语言DDL日志输出到kafka中。

步骤103、根据设定业务的使用场景配置的同步任务将所述kafka中的binlog数据通过设定方式同步输出到设定的数据存储组件中。

在一个具体的实施例中，根据与源存储组件对应的接入配置信息将源存储组件中每个服务实例对应的源数据实时写入分布式日志***Kafka的对应主题中；当监听到存在待处理的同步任务时获取同步任务的配置数据配置数据包括源存储组件、Kafka的目标主题和目的存储组件的地址信息；根据配置数据执行同步任务。

在一个具体的实施例中，MySQL语言共分为四大类：数据查询语言DQL，数据操纵语言DML，数据定义语言DDL，数据控制语言DCL。

数据查询语言DQL基本结构是由SELECT子句，FROM子句，WHERE，子句组成的查询块：，SELECT<字段名表>，FROM<表或视图名>，WHERE<查询条件>。

数据操纵语言DML主要有三种形式：1)***：INSERT；2)更新：UPDATE；3)删除：DELETE。

数据定义语言DDL用来创建数据库中的各种对象、表、视图、索引、同义词、聚簇等如：CREATE TABLE表/VIEW视图/INDEX索引/SYN同义词/CLUSTER簇。

数据控制语言DCL用来授予或回收访问数据库的某种特权，并控制数据库操纵事务发生的时间及效果，对数据库实行监视等。如：1)GRANT：授权。2)ROLLBACK[WORK]TO[SAVEPOINT]：回退到某一点。回滚---ROLLBACK，回滚命令使数据库状态回到上次最后提交的状态。其格式为：SQL>ROLLBACK；3)COMMIT[WORK]：提交。

在数据库的***、删除和修改操作时，只有当事务在提交到数据库时才算完成。在事务提交前，只有操作数据库的这个人才能有权看到所做的事情，别人只有在最后提交完成后才可以看到。提交数据有三种类型：显式提交、隐式提交及自动提交。下面分别说明这三种类型。(1)显式提交，用COMMIT命令直接完成的提交为显式提交。其格式为：SQL>COMMIT；(2)隐式提交；用SQL命令间接完成的提交为隐式提交。这些命令是：ALTER，AUDIT，COMMENT，CONNECT，CREATE，DISCONNECT，DROP，EXIT，GRANT，NOAUDIT，QUIT，REVOKE，RENAME。(3)自动提交若把AUTOCOMMIT设置为ON，则在***、修改、删除语句执行后，***将自动进行提交，这就是自动提交。其格式为：SQL>SET AUTOCOMMIT ON。

图2示出本申请一个实施例的数据处理***的结构示意图，如图2所示，***包括：MySQL数据库、canal同步工具、实时同步框架，数据接入、数据处理、数据输出、数据校验、数据修复，架构图如下:

结合图1、图2、在一个实施例中，mysql同步工具canal将服务实例伪装成一个mysql从库节点实时获取对应主库的DML和DDL日志，并将获取到的日志输出到kafka中，然后根据业务的使用场景，将kafka中的binlog数据，输出到不同数据存储组件中，当前支持输出到kudu，elasticsearch，tidb和hdfs中，业务方可以根据分析场景自助配置同步任务。

在一个实施例中，数据接入阶段通过canal同步工具将数据写入到kafka对应的topic中，包含：数据库权限申请、白名单配置、topic映射配置、数据格式转换、数据写入。

在一个实施例中，可以设置数据库权限申请管理，具体的，用户根据需同步表所在的库申请对应主库的读权限，目的是开启canal拉取mysql binlog的权限。

在一个实施例中，可以设置白名单，具体的，按照实际业务需求，开启对应库表的白名单，屏蔽非必要的库表数据，减少后续处理数据时的资源消耗。

在一个实施例中，可以设置topic映射配置，根据白名单配置自动生成映射关系，该关系主要指定库表数据最终落入kafka的哪个主题，可按库或表分别指定，配置完成后可支持kafka topic的自动创建。

在一个实施例中，可以设置数据格式转换，将canal接入的binlog数据按照对象模式转换为json格式，为了更好的兼容后续组件的使用。

在一个实施例中，可以支持数据写入，具体的，***根据白名单与topic映射关系，将数据写入到指定的topic中。

在一个实施例中，数据处理阶段为数据的输出做准备，具体的处理流程包括：任务创建、索引或表创建、任务审批、任务启动、任务运行。

步骤201，选择需要同步的库表，指定同步类型，类型包括：存量与实时同步、存量同步、实时同步。同步至es时，需要指定索引名，并指定mysql字段与es字段的映射关系，目的是为了构建相对精确mapper，支持业务查询索引的场景，以及提升查询性能；同步至tidb时，需要指定目标集群、库、表。

步骤202，创建索引或表，具体的，可以支持根据待同步数据的schema，自动创建tidb表或es索引模板。

步骤203，任务审批时核验数据处理时各部分准备工作是否都完善以保证数据同步的准确性，驳回不合法的配置或驳回不适合同步的任务。

步骤204，通过任务审批后，任务启动后在程序协调服务zookeeper中下发设定通知，数据同步服务监听到所述zookeeper下发的所述设定通知消息后，根据配置的kafkatopic信息启动新的消费者线程，以设定时间间隔或批次大小拉取数据，当出现处理过程发生异常时将未处理成功的数据发送至kafka的临时topic中，任务在重试过程中重新消费处理异常的数据，其中，所述数据异常包括但是不限于依赖的组件服务异常、网络异常、云服务异常。通过以上方式可以保证了数据最终的一致性。

在一个实施例中，设定时间间隔或批次大小拉取数据可以是以每500毫秒或2000的批次大小拉取数据，本领域人员可以理解，该时间与数据批次大小可以根据实际情况调节。

步骤205，实时的对输出日志进行监控，发生异常时将异常条数和内容发送至设定客户端；在消费kafka消息如果业务量突增导致出现阻塞时，根据阻塞情况进行参数动态调优。

在一个实施例中，数据输出中支持输出的存储组件包括但是不限于kudu，elasticsearch，tidb和hdfs；所述数据输出支持写入和/或数据修复的功能。

在一个实施例中，数据校验的流程可以包括：步骤a)在设定时间段的设定时间校验上一个设定时间段的数据；步骤b)、将不一致的数据与原因输出到对应的文件中以便于问题定位与数据修复使用。具体的，可以在每个小时的第5分钟校验上小时的数据，并将不一致的数据与原因输出到对应的文件中；还可以每隔半个小时或40分钟校验上一个时间段的数据。

在一个实施例中，kafka可以提供数据查询、消费查询的功能。具体的，数据查询可以通过offset查询对应offset的数据，也可以通过进入Kafka的大致时间，查询那段内的数据，可以看到每条信息的partition，offset，入Kafka的时间，AVRO的版本信息等。消费查询可以查看一条消息，了解哪些consumer group已经消费了，哪些没有消费。同时可以查看它现在正在被哪个IP进行消费，这时我们可以方便地定位到有个consumer没有关闭，它是在哪台机器上。还可以看到每个consumer group的消费延迟情况，精确到条数，partition的延迟。也可以看到partition消息总数，可以排查一些消息不均的问题。

在一个实施例中，通过实时监控与异常报警可以了解Topic的流入、流出数据，每秒写入多少条消息，多大的size，每秒流出的情况。实时监控报警是对Topic建一些流量报警或是一些延迟报警，建好之后只需要用户订阅一下即可，非常方便用户操作与管理异常数据处理过程。

在一个实施例中，异常数据修复包括：根据校验结果针对文件中的数据通过指定待修复数据的条件进行数据修复。

在一个实施例中，除了canal开源服务外其他同步服务采用springboot进行构建，通过动态监听zookeeper节点新增、删除操作，发布和下线数据同步任务，源数据从kafka消费并将消费得到的数据输出到指定的数据库组件中。

图3示出本申请另一个实施例的数据处理方法的流程图，参照图3，如图3所示，该方法流程包括：

步骤301，在数据深度学***台上创建同步任务后，调用审批接口将数据写入到分布式应用程序协调服务zookeeper中；

步骤302，数据同步服务通过监听分布式应用程序协调服务zookeeper节点变化，根据所述节点的变化情况决定是否启动新的同步任务；

步骤303，数据监控服务对新任务的数据一致性进行定时监控；

步骤304，新的同步任务启动后，根据配置时指定的输入和输出方式从数据源拉取数据；

步骤305，将获取的数据实时同步至数据存储组件中，如果在执行数据同步的过程中出现了数据不一致情况通过改流程创建存量数据同步任务修复数据。

本申请提供一种统一数据服务的DI平台，该平台主要面向大数据、跨归属部门的数据查询服务，无需编写查询代码，在平台上配置即可，提供数据表、查询条件、查询字段、排序字段等。平台可以根据客户端的qps要求、安全保障级别来决定服务的部署节点，平台提供限流功能、熔断，最大限度保障服务稳定。

DI平台主要基于spring cloud体系开发，部署采用k8s，***主要分三大模块，核心模块、web管理模块和client模块，client模块主要负责feign接口提供，分流参数设置；web管理模块主要负责api服务的创建、审批、服务授权等；核心模块主要负责client过来的请求的处理，中间包括基于客户端的apikey，获取apikey的定义，拼接成sql，通过自研的水坝去各个引擎(mysql、tidb、clickhouse等)上查询数据；其中，通过申请的数据处理***进行同步，把原始数据通过数据同步平台实时同步到其他引擎上，避免对业务库造成压力。在DI***提供的页面，直接申请接口，经过审批后，服务发布，发布完成后，接口服务就处于可用状态了。在创建接口时，会经过审批，保证调用都是合法的；同时设置的common模块会有审计功能，记录每一次查询的sql和返回的数据，保证每一次查询都可查询。

在一个实施例中，***Kafka用于复制数据，把一个数据从data source转到Kafka，再从Kafka转到其它地方，支持批和流，同时支持实时和批处理，比如5min同步一次。它支持多个***之间互相复制，数据源可能是Mysql、SQL Server也可能是Oracle。sink可以是Hbase、Hive等。它自己定义了一套plugin接口，可以自己写很多数据源和不支持的sink。并且他自己做到了分布式并行，支持完善的HA和load balance，还提供方便的RESTful接口。

在没有Kafka插件之前，运维ETL非常麻烦；拿canal来说，canal有server和client都需手动部署，如果有100台canal节点1000个数据库，管理员如何知道哪台机器上跑了哪些库表，新增的任务又放在哪台机来运行。此外，如果Mysql修改了一个字段，还需要让程序员去机器上看一下那张表是如何修改的，相应的所有下游都需相应的完成表结构修改之后，才能跑起来，响应速度非常慢。

在一个实施例中，如果上游数据根据兼容性进行的修改，Kafka会在下游同样做一些兼容性的修改，自动更改下游表结构，减轻了运维负担。Kafka会把所有信息存到Kafka中，其中config topic存元数据，Stutas topic指当前哪些节点正在跑什么样的job，offset topic指当前比如某个Topic的某个partitions到底消费到哪条数据。WorKer都是无状态的，在上面可以跑许多task，同样一个task1，可能对应5个partitions，如果只给它三个并发，它会分布在三台机器上。如果一台机器挂了，这些job都会分配到另外两台机器，而且是实时同步的。

在一个实施例中，可以通过canal做成了Kafka的plugin；原生的canal、Maxwell不支持AVRO，通过debezium思想对Maxwell进行了修改，使其支持avro格式，并用Mysql管理meta，并且支持Mysql的数据库切换。

在一个实施例中，针对HDFS数据，采用的confluence公司的hdfs插件，但是其本身存在很多问题，比如写入hive的时候会把当做partition的列也写到主表数据中，虽然不影响hive的使用，但是影响presto读取hive，这里我们改了源码，去掉了主表中的这些列；Hdfs在插件重启时会去hdfs中读取所有文件来确定从哪个offset继续，这里会有两个问题：耗时太长，切换集群时offset无法接续。可以在plugin写入hive时支持用Kafka的timestamp做分区，也支持用数据内的某些列做分区，但是不支持两者同时用，我们也修改了一下。

在一个实施例中，Hbase的plugin只支持最原始的导出，有些特殊的需求，比如对rowkey自定义一下，通常mysql主键是自增ID，hbase不推荐用自增ID做rowkey，我们会有reverse的需求，还有多列联合做rowkey的需求等，这个我们也改了源码，支持通过配置自定义rowkey生成；原始plugin不支持kerberos，而online hbase是带权限的，可以所有类型都先转成string再存，支持delete，支持json等。

在一个实施例中，KUDU的使用很多，kudu开源的plugin有些bug，Kudu的数据来源都是mysql，但是经常会有mysql刷库的情况，这时量就会很大，kudu sink会有较大的延时，我们改了一下plugin，添加了自适应流量控制，自动扩充成多线程处理，也会在流量小时，自动缩容。

对于需要实时更新的数据操纵，数据通过canal服务、maxwell服务进入Kafka，这部分流程共用，然后增量数据会实时通过kudu的插件写入kudu中，再通过impala做ETL，生成数据对外提供T+0.1或T+0.01的查询，通过Flink直接读取Kafka中数据来做实时ETL，提高实时性。

本申请实施例提供的基于大数据技术和互联网技术的数据同步方法，可以帮业务部门人员快速接入数据，节省了传统数据同步带来的人力开发和维护成本，大大提高的工作效率，并能支持对异常数据的修复，满足多种数据组件间的数据同步需求，保证了按数据对业务决策的及时性。

现有技术中，大数据HDFS集群的存储空间巨大，数据表和ETL任务数以万计，依靠人工处理已变得不可能，因此推出基于HIVE表的生命周期管理***，进行自动化处理。基于HIVE表的资源目前分为存储资源、计算资源，存储资源基于HDFS存储，依托自带的管理***进行空间监控与报警，然后人工参数，从上万张表中选择部分删除，释放控制；计算资源主要集中在调度任务中，每日大约有6000+任务反复执行，依托资源监控***进行告警，之后人工介入，进行任务分析，以及一些过期任务的清理。存储资源优化，人工从上万张表中选择删除，覆盖率低，释放空间有限，且占用人力，效果不显著。计算资源优化，人工从上万个任务中优化，需耗费大量的精力进行筛选，并要解决任务依赖问题等，成本较高。

图4示出本申请一个实施例的数据处理方法的***状态示意图，如图4所示，该***还包括生命周期管理配置、规则引擎翻译、元数仓建设、DLM处理，具体的，依靠DI-ETL***以及对整体数据流转链条的梳理，对ETL任务解析，邮件SQL解析并加入埋点日志，HIVE-HOOK采集用户执行SQL并解析，各个报表***的日志采集与解析等，实现了对数据终端的监控，达到了整体数据的全链路分析。

图5示出本申请又一个实施例的数据处理方法的流程图，如图5所示，该方法包括：

步骤501、生命周期管理配置。

步骤502、规则引擎翻译。

步骤503、元数仓建设。

步骤504、数据生命周期管理(DLM)处理。

在一个实施例中，生命周期管理配置阶段分为两个步骤进行配置，包含：用户页面配置、***定时扫描统一配置。

具体的步骤可以包括：步骤5011，在深度学习DI***的集群表操作页面中加入生命周期管理配置，用户在建表操作按照设定需求情况进行规则配置。步骤5012，在深度学习DI***的配置定时任务按照预先设定规则自动对HIVE数据表进行生命周期规则配置。

具体的，用户页面配置在DI-ETL(DI数据转换)***的集群表操作页面中，加入生命周期管理配置，用户在建表操作时，可按需进行规则配置，否则将按照默认规则配置。默认规则-下线任务：最近三个月访问次数为0&被依赖任务数为0。***定时扫描，在DI-ETL***的配置定时任务，根据与数仓约定好的规则，自动对HIVE数据表进行生命周期规则配置。

在一个实施例中，可以进行表1如下的规则设定：

表1

在一个实施例中，规则引擎翻译可以包括规则管理，规则翻译，其中，规则管理是用户在配置生命周期规则时，可自动组合各种标签以及计算表达式,需要提供方便的操作并将用户配置内容进行记录。

在一个实施例中，规则引擎提供等于，大于，小于，大于等于，小于等于，不等于，IN比较运算符，并且提供并和或关系运算符以及括号，讲多个表达式关联起来

在一个实施例中，规则翻译是指为用户在页面配置的规则信息需翻译为后续模块处理的任务语法，例如：

[[{"tag":"last_three_month_visit_num","op":"＝","other":0,"tagType":"bigint","tagDict":"","enumValueList":[]},{"condition":"&&"},{"tag":"depended_task_num","op":"＝","other":0,"tagType":"bigint","tagDict":"","enumValueList":[]}]]

在一个实施例中，元数仓建设首次接入了业务元数据，在以往的数据表画像中，只接入技术元数据，例如：表的分区数，分区大小，数据行数等。但本次接入了业务元数据相关，例如：在etl任务有多少任务使用，任务是否存活，在邮件以及报表中使用频率。并且通过埋点技术手段，实现了邮件和报表的打开率监控，感知邮件和报表的存活，进一步来确认该数据表的活动情况。通过业务元数据的抓取以及对ETL任务的链路分析，完善了数据表从数据产出到数据转化，到终端的数据展示，以及最终零使用率的一个完整链路画像。

在一个实施例中，元数仓建设分为两个部分，一个是数据终端的数据采集，一个是根据标签规则进行数据清洗。

表2示出了数据终端的数据采集并入仓的规则，如表2所示

表2

在一个实施例中，根据标签规则进行数据清洗，在DI-ETL***创建元数仓调度(每日执行)，配置相关ETL任务，根据标签进行数据清洗。

图6示出本申请一个实施例的数据处理方法的流程图，如图6所示，DLM处理模块作为本次架构另外一个核心功能，通过zookeeper实现分布式部署，并通过zookeeper作为消息一致性的通知媒介，完成任务计算的下发与执行。并且因为涉及到核心的HDFS文件删除功能，为防止误删，文件会先进入HDFS回收站，7天内可恢复。在下线任务方面，在下线任务时会做多重的判断，任务是否有下游依赖，是否有最近使用等画像标签，当都满足时才进行下线操作，并且会进行该任务当前的血缘依赖关系快照，当出现问题可以快速恢复依赖DAG关系。并且提供了整套完整的告警通知及时，对一些***无法自动化的表和任务，通知数仓手动处理。在以往是由数仓定时进行人工手动处理以上内容，风险较大，容易破坏任务的依赖，并且HDFS删除不净。而DLM模块完全自动化处理，目前可覆盖HIVE60％的表，大量的节约人力，并有记录可查。

在一个实施例中，数据经过元数仓处理后进入DLM进行最终处理，根据规则引擎翻译后的执行计划，进行相关的操作，并有告警提示。除告警外，在***中有对应页面可以查看历史执行情况。

在一个具体的实施例中，整体服务采用springboot进行构建，通过动态监听zookeeper节点新增、删除操作等实现DLM分布式部署。依托内部的DI-ETL调度***，进行元数仓的整体建设。DLM执行器根据规则进行相关处理，最终实现HIVE表数据的全链路分析。

本申请实施例提供的基于大数据技术和互联网技术构建的一个数据处理的资源自动优化***，能大幅减低人工维护的成本，并且进一步减低集群存储成本的50％，自动下线任务达15％，大幅降低集群计算压力。

图7示出本申请一个实施例的数据处理***的结构框图，如图7所示，***包括：

获取模块401，被配置为通过canal服务将服务实例伪装成MySQL从库节点获取对应主库的数据操纵语言DML和数据定义语言DDL日志。

发送模块402，与所述获取模块相连接，被配置为将获取到的所述数据操纵语言DML和数据定义语言DDL日志输出到kafka中。

处理模块403，所述发送模块相连接，被配置为根据设定业务的使用场景配置的同步任务将所述kafka中的binlog数据通过设定方式同步输出到设定的数据存储组件中。

在一个实施例中，该***还包括：任务创建模块，被配置为选择需要同步的库表，指定同步类型及同步方法，所述同步类型包括：存量与实时同步、存量同步、实时同步；其中，同步至es时指定索引名并指定MySQL字段与es字段的映射关系；同步至tidb时指定目标集群、库、表。

在一个实施例中，该***还包括创建模块，被配置为创建索引或表以支持根据待同步数据的schema自动创建tidb表或es索引模板；

在一个实施例中，该***还包括任务运行模块，被配置为任务启动后在程序协调服务zookeeper中下发设定通知，数据同步服务监听到所述zookeeper下发的所述设定通知消息后，根据配置的kafka topic信息启动新的消费者线程，以设定时间间隔或批次大小拉取数据，当出现处理过程发生异常时将未处理成功的数据发送至kafka的临时topic中，任务在重试过程中重新消费处理异常的数据，其中，所述数据异常包括但是不限于依赖的组件服务异常、网络异常、云服务异常；

在一个实施例中，该***还包括实时监控模块，实时的对输出日志进行监控，发生异常时将异常条数和内容发送至设定客户端；在消费kafka消息如果业务量突增导致出现阻塞时，根据阻塞情况进行参数动态调优。

在一个实施例中，该***还包括任务审批模块，被配置为核验数据处理时各部分准备工作是否都完善以保证数据同步的准确性。

在一个实施例中，该***还包括任务审批模块，还被配置为核验数据处理时驳回不合法的配置或驳回不适合同步的任务。

在一个实施例中，该***还包括权限申请模块，被配置为通过canal服务同步工具将数据写入到kafka对应的topic中，包含：数据库权限申请、白名单配置、topic映射配置、数据格式转换、数据写入。

在一个实施例中，该***还包括权限申请模块，被配置为根据需同步表所在的库申请对应主库的读权限以便开启canal拉取MySQL binlog的权限。

在一个实施例中，该***还包括白名单模块，被配置为按照实际业务需求开启对应库表的白名单、屏蔽非必要的库表数据。

在一个实施例中，该***还包括映射配置模块，被配置为根据白名单配置自动生成映射关系，所述映射关系包括指定库表数据落入kafka的哪个设定主题，其中，可按库或表分别指定，配置完成后以支持kafka topic的自动创建。

在一个实施例中，该***还包括数据格式转换模块，被配置为将canal接入的binlog数据按照对象模式转换为json格式。

在一个实施例中，该***还包括数据写入模块，被配置为根据白名单与topic映射关系，将数据写入到指定的topic中。

在一个实施例中，该***还包括数据输出模块，被配置为数据输出支持输出的存储组件包括但不限于kudu，elasticsearch，tidb和hdfs；所述数据输出模块支持写入和/或数据修复的功能。

在一个实施例中，该***还包括异常数据修复模块，被配置为根据校验结果针对文件中的数据通过指定待修复数据的条件进行数据修复。

在一个实施例中，该***还包括数据校验模块，被配置为在设定时间段的设定时间校验上一个设定时间段的数据；将不一致的数据与原因输出到对应的文件中以便于问题定位与数据修复使用。

本申请还提供一种数据处理******包括：元数仓模块，被配置为采用springboot进行构建数据处理服务，依托DI调度***建设元数仓；zookeeper模块，用于接收所述DI调度***发送的任务队列并监听节点的变化：数据生命周期管理模块，被配置为动态监听所述zookeeper节点的变化以实现数据生命周期管理DLM分布式部署；数据生命周期管理DLM根据设定配置规则进行相关处理以实现HIVE表数据的全链路分析处理，所述处理包括但是不限于同步处理。

在一个实施例中，生命周期管理配置模块包括：页面配置单元以及定时扫描单元，其中，页面配置单元被配置为在深度学习DI***的集群表操作页面中加入基于Hive数据表的生命周期管理配置，用户在建表操作按照设定需求情况进行规则配置；定时扫描单元被配置为在深度学习DI***的配置定时任务按照预先设定规则自动对HIVE数据表进行生命周期规则配置。

在一个实施例中元数仓模块包括数据采集单元以及数据清洗单元，数据采集单元用户针对数据抽取转换装载ETL任务，通过任务解析,SQL解析采集方式以调度任务上报入仓；针对h-HOOK，通过HIVE拦截用户执行SQL并解析以调度任务上报入仓；针对邮件***，通过邮件SQL解析,并邮件埋点打开数据上报，通过消费kafka入库,在通过调度任务上报入仓；针对报表***通过解析报表***中的SQL解析log日志并通过调度任务上报入仓；和/或，数据清洗单元用于创建元数仓调度并配置相关ETL任务，根据标签进行数据清洗。

数据生命周期管理模块被配置为通过zookeeper实现分布式部署并通过zookeeper作为消息一致性的通知媒介，执行任务计算的下发与执行。

规则引擎翻译模块，包括规则管理单元以及规则翻译单元。具体的，规则管理单元用于在用户在配置生命周期规则时，可自动组合各种标签以及计算表达式,需要提供方便的操作并将用户配置内容进行记录；2、规则翻译单元用于为用户在页面配置的规则信息，需翻译为后续模块处理的任务语法。

该***还包括同步处理模块，被配置为采用springboot进行构建同步服务；通过动态监听zookeeper节点新增、删除操作，发布和下线数据同步任务；源数据按照设定规则从kafka消费以进行数据同步数据、并将消费得到的数据输出到指定的数据库组件中。

该***的执行流程与执行方法可以参照以上方法步骤，本部分不再赘述。本申请实施例提供的基于大数据技术和互联网技术的数据同步***，可以帮业务部门人员快速接入数据，节省了传统数据同步带来的人力开发和维护成本，大大提高的工作效率，并能支持对异常数据的修复，满足多种数据组件间的数据同步需求，保证了按数据对业务决策的及时性。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包括一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘(Solid State Disk，SSD))等。

本申请实施例中所描述的各种说明性的逻辑单元和电路可以通过通用处理器，数字信号处理器，专用集成电路(ASIC)，现场可编程门阵列(FPGA)或其它可编程逻辑装置，离散门或晶体管逻辑，离散硬件部件，或上述任何组合的设计来实现或操作所描述的功能。通用处理器可以为微处理器，可选地，该通用处理器也可以为任何传统的处理器、控制设备、微或状态机。处理器也可以通过计算装置的组合来实现，例如数字信号处理器和微处理器，多个微处理器，一个或多个微处理器联合一个数字信号处理器核，或任何其它类似的配置来实现。

本申请实施例中所描述的方法或算法的步骤可以直接嵌入硬件、处理器执行的软件单元、或者这两者的结合。软件单元可以存储于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动磁盘、CD-ROM或本领域中其它任意形式的存储媒介中。示例性地，存储媒介可以与处理器连接，以使得处理器可以从存储媒介中读取信息，并可以向存储媒介存写信息。可选地，存储媒介还可以集成到处理器中。处理器和存储媒介可以设置于ASIC中。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

本说明书中各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似的部分相互参见即可。对于***实施例而言，由于其与方法实施例基本对应，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

可能以许多方式来实现本发明的方法和***。例如，可通过软件、硬件、固件或者软件、硬件、固件的任何组合来实现本发明的方法和***。用于所述方法的步骤的上述顺序仅是为了进行说明，本发明的方法的步骤不限于以上具体描述的顺序，除非以其它方式特别说明。此外，在一些实施例中，还可将本发明实施为记录在记录介质中的程序，这些程序包括用于实现根据本发明的方法的机器可读指令。因而，本发明还覆盖存储用于执行根据本发明的方法的程序的记录介质。

本发明的描述是为了示例和描述起见而给出的，而并不是无遗漏的或者将本发明限于所公开的形式。很多修改和变化对于本领域的普通技术人员而言是显然的。选择和描述实施例是为了更好说明本发明的原理和实际应用，并且使本领域的普通技术人员能够理解本发明从而设计适于特定用途的带有各种修改的各种实施例。

Claims (10)

1.一种数据处理方法，其特征在于，包括：

通过canal服务将服务实例伪装成MySQL从库节点获取对应主库的数据操纵语言DML和数据定义语言DDL日志；

将获取到的所述数据操纵语言DML和数据定义语言DDL日志输出到kafka中；

根据设定业务的使用场景配置的同步任务将所述kafka中的binlog数据通过设定方式同步输出到设定的数据存储组件中。

2.根据权利要求1所述的方法，其特征在于，所述设定业务的使用场景配置的同步任务包括：

任务创建时选择需要同步的库表，指定同步类型及同步方法，所述同步类型包括：存量与实时同步、存量同步、实时同步；

创建索引或表以支持根据待同步数据的schema自动创建tidb表或es索引模板；

其中，

同步至es时指定索引名并指定MySQL字段与es字段的映射关系；

同步至tidb时指定目标集群、库、表。

3.根据权利要求2所述的方法，其特征在于，所述将所述kafka中的binlog数据通过设定方式同步输出到设定的数据存储组件中包括：

任务启动后在程序协调服务zookeeper中下发设定通知，数据同步服务监听到所述zookeeper下发的所述设定通知消息后，根据配置的kafka topic信息启动新的消费者线程，以设定时间间隔或批次大小拉取数据，当出现处理过程发生异常时将未处理成功的数据发送至kafka的临时topic中，任务在重试过程中重新消费处理异常的数据，其中，所述数据异常包括但是不限于依赖的组件服务异常、网络异常、云服务异常；

实时的对输出日志进行监控，发生异常时将异常条数和内容发送至设定客户端；在消费kafka消息如果业务量突增导致出现阻塞时，根据阻塞情况进行参数动态调优。

4.根据权利要求1-3中任一所述的方法，其特征在于，还包括：

通过canal服务同步工具将数据写入到kafka对应的topic中，包含：数据库权限申请、白名单配置、topic映射配置、数据格式转换、数据写入；

和/或

用户根据需同步表所在的库申请对应主库的读权限以便开启canal拉取MySQL binlog的权限；

和/或

按照实际业务需求开启对应库表的白名单、屏蔽非必要的库表数据；

和/或

根据白名单配置自动生成映射关系，所述映射关系包括指定库表数据落入kafka的哪个设定主题，其中，可按库或表分别指定，配置完成后以支持kafka topic的自动创建；

和/或

将canal接入的binlog数据按照对象模式转换为json格式；

和/或

根据白名单与topic映射关系，将数据写入到指定的topic中。

5.根据权利要求4所述的方法，其特征在于，还包括：

数据输出支持输出的存储组件包括但不限于kudu，elasticsearch，tidb和hdfs；

和/或

所述数据输出支持写入和/或数据修复的功能；

和/或

所述方法还包括：

根据校验结果针对文件中的数据通过指定待修复数据的条件进行数据修复；

和/或

所述方法还包括：在设定时间段的设定时间校验上一个设定时间段的数据；将不一致的数据与原因输出到对应的文件中以便于问题定位与数据修复使用；

和/或

任务审批时核验数据处理时各部分准备工作是否都完善以保证数据同步的准确性；

和/或

核验数据处理时驳回不合法的配置或驳回不适合同步的任务。

6.一种数据处理方法，其特征在于，还包括：

采用springboot进行构建数据处理服务，依托DI调度***建设元数仓；

zookeeper接收所述DI调度***发送的任务队列：

动态监听所述zookeeper节点的变化以实现数据生命周期管理DLM分布式部署；

数据生命周期管理DLM根据设定配置规则进行相关处理以实现HIVE表数据的全链路分析处理，所述处理包括但是不限于同步处理。

7.根据权利要求6所述的方法，其特征在于，所述处理包括但是不限于同步处理，还包括：

采用springboot进行构建同步服务；

通过动态监听zookeeper节点新增、删除操作，发布和下线数据同步任务；

源数据按照设定规则从kafka消费以进行数据同步数据、并将消费得到的数据输出到指定的数据库组件中。

8.根据权利要求6所述的方法，其特征在于，所述设定配置规则包括：

在深度学习DI***的集群表操作页面中加入基于Hive数据表的生命周期管理配置，用户在建表操作按照设定需求情况进行规则配置；

在深度学习DI***的配置定时任务按照预先设定规则自动对HIVE数据表进行生命周期规则配置。

9.根据权利要求6-8中任一所述的方法，其特征在于，包括：

元数仓建设包括数据终端的数据采集、根据标签规则进行数据清洗；

其中，

数据采集入仓包括：

针对数据抽取转换装载ETL任务，通过任务解析,SQL解析采集方式以调度任务上报入仓；

针对h-HOOK，通过HIVE拦截用户执行SQL并解析以调度任务上报入仓；

针对邮件***，通过邮件SQL解析,并邮件埋点打开数据上报，通过消费kafka入库,在通过调度任务上报入仓；

针对报表***通过解析报表***中的SQL解析log日志并通过调度任务上报入仓；

和/或

创建元数仓调度并配置相关ETL任务，根据标签进行数据清洗；

和/或

通过zookeeper实现分布式部署并通过zookeeper作为消息一致性的通知媒介，执行任务计算的下发与执行。

10.一种数据处理***，其特征在于，包括：

获取模块，被配置为通过canal服务将服务实例伪装成MySQL从库节点获取对应主库的数据操纵语言DML和数据定义语言DDL日志；

发送模块，与所述获取模块相连接，被配置为将获取到的所述数据操纵语言DML和数据定义语言DDL日志输出到kafka中；

处理模块，所述发送模块相连接，被配置为根据设定业务的使用场景配置的同步任务将所述kafka中的binlog数据通过设定方式同步输出到设定的数据存储组件中。

Images