1.本技术涉及数据传输与处理
技术领域：
：，尤其涉及一种数据同步方法、系统、电子装置及计算机可读存储介质。
背景技术：
：：2.目前对于从数据源到数据湖表的数据同步过程，一般只能将全量数据的同步和增量数据的同步分开进行。例如按天拉取全量数据，每小时拉取增量数据，并对所述全量数据和所述增量数据进行在线合并。该方案只能实现小时级数据同步，处理时效性低，并且用户体验不透明。3.需要说明的是，上述内容并不用于限制申请保护范围。技术实现要素：4.本技术的主要目的在于提出一种数据同步方法、系统、电子装置及计算机可读存储介质，旨在解决如何打通全量数据和增量数据的同步，以及提高处理时效性和透明性的问题。5.为实现上述目的，本技术实施例提供了一种数据同步方法，所述方法包括：6.从数据源中采集全量数据和增量数据；7.为采集的每一条数据分配有序且唯一的编号；8.对所述数据按照所述编号进行全局有序排列和去重处理；及9.将处理后的数据按顺序写入数据湖表中。10.可选地，所述方法还包括：11.根据从所述数据源中采集的至少部分数据与所述数据湖表中对应的至少部分数据，检验数据传输质量。12.可选地，所述从数据源中采集全量数据和增量数据包括：13.通过快照技术按天采集所述全量数据，通过读取增量日志分钟级采集所述增量数据。14.可选地，所述从数据源中采集全量数据和增量数据包括：15.针对第一预设类型数据源，基于flinkcdc，通过全量快照技术拉取得到所述全量数据，通过读取binlog日志得到所述增量数据。16.可选地，所述从数据源中采集全量数据和增量数据还包括：17.针对第二预设类型数据源，通过代理采集从节点的dump文件得到所述全量数据，通过读取binlog日志得到所述增量数据。18.可选地，所述为采集的每一条数据分配有序且唯一的编号包括：19.记录当前的系统生成时间，作为一个时间戳；20.生成一个单调递增编号；21.将所述时间戳加上所述单调递增编号作为所述有序且唯一的编号分配给当前数据。22.可选地，所述方法在所述为采集的每一条数据分配有序且唯一的编号和所述对所述数据按照所述编号进行全局有序排列和去重处理之间还包括：23.将带有编号的所述数据推送到kafka消息队列中；24.从所述kafka消息队列中消费当前数据。25.此外，为实现上述目的，本技术实施例还提供一种数据同步系统，所述系统包括：26.采集模块，用于从数据源中采集全量数据和增量数据；27.分配模块，用于为采集的每一条数据分配有序且唯一的编号；28.处理模块，用于对所述数据按照所述编号进行全局有序排列和去重处理；29.写入模块，用于将处理后的数据按顺序写入数据湖表中。30.为实现上述目的，本技术实施例还提供一种电子装置，所述电子装置包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的数据同步程序，所述数据同步程序被所述处理器执行时实现如上述的数据同步方法。31.为实现上述目的，本技术实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有数据同步程序，所述数据同步程序被处理器执行时实现如上述的数据同步方法。32.本技术实施例提出的数据同步方法、系统、电子装置及计算机可读存储介质，能够对全量数据和增量数据进行一体化打通，并实现分钟级数据同步和一键增量化入仓。通过向每条数据分配有序且唯一的编号，保证了所述全量数据和所述增量数据的有序性和唯一性，保障了数据传输质量。附图说明33.图1为实现本技术各个实施例的一种应用环境架构图；34.图2为本技术第一实施例提出的一种数据同步方法的流程图；35.图3为图2中步骤s202的细化流程示意图；36.图4为本技术第二实施例提出的一种数据同步方法的流程图；37.图5为本技术中一种具体应用实例的示意图；38.图6为本技术第三实施例提出的一种电子装置的硬件架构示意图；39.图7为本技术第四实施例提出的一种数据同步系统的模块示意图；40.图8为本技术第五实施例提出的一种数据同步系统的模块示意图。具体实施方式41.为了使本技术的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本技术进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本技术，并不用于限定本技术。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。42.需要说明的是，在本技术实施例中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本技术要求的保护范围之内。43.为了方便理解，以下提供了一些术语解释：44.etl，是一种数据仓库技术，是抽取(extract)、转换(transform)、加载(load)的缩写。etl是将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程，目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析依据。etl是商业智能(businessintelligence，bi)项目重要的一个环节。45.flink集群(flinkcluster)，是一个分布式系统，用于对无界和有界数据流进行有状态计算。flink设计为在所有常见的集群环境中运行，以内存速度和任何规模执行计算。46.cdc(changedatacapture)，是oracle在数据库级别实现的增量抽取解决方案。它是一个比较广义的概念，只要能捕获变更的数据，都可以称为cdc。业界主要有基于查询的cdc和基于日志的cdc。47.kafka，是一个分布式、分区的、多副本的、多订阅者，基于zookeeper协调的分布式日志系统，也可以作为消息队列系统。kafka可以用于web/nginx日志、访问日志，消息服务等。kafka是按秒进行任务的计算和应用，用于实时推荐、实时计算等场景中。48.sink，在无线传感器网络指汇聚结点，主要负责传感器网与外网(例如gprs、internet等)的连接，可看作网关节点。49.mysql，是一种关系型数据库管理系统，关系数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。mysql所使用的sql语言是用于访问数据库的最常用标准化语言。50.tidb，是一种开源分布式关系型数据库，同时支持在线事务处理与在线分析处理(hybridtransactionalandanalyticalprocessing，htap)，具备水平扩容或者缩容、金融级高可用、实时htap、云原生的分布式数据库、兼容mysql5.7协议和mysql生态等重要特性。目标是为用户提供一站式联机事务处处理(onlinetransactionalprocessing，oltp)、联机分析处理(onlineanalyticalprocessing，olap)、htap解决方案。tidb适合高可用、强一致要求较高、数据规模较大等各种应用场景。51.hudi(hadoopupdatesandincrementals，hadoop更新与增量)，采用并管理通过dfs(hdfs或云存储)存储大型分析数据集，支持在当前数据表中进行更新操作。hudi将表组织成hdfs上某个指定目录(basepath)下的目录结构，表被分成多个分区，分区是以目录的形式存在，每个目录下面会存在属于该分区的多个文件，类似hive表，每个hudi表分区通过一个分区路径(partitionpath)来唯一标识。52.snapshot，也就是快照技术或磁盘快照。snapshot是针对整个磁盘卷册进行快速的档案系统备份，与其它备份方式最主要的不同点在于速度。进行磁盘快照时，并不牵涉到任何档案复制动作。就算数据量再大，一般来说，通常可以在一秒之内完成备份动作。53.binlog日志，是记录所有数据库表结构变更(如create、altertable)及表数据修改(insert、update、delete)的二进制日志。binlog日志的格式为json。54.请参阅图1，图1为实现本技术各个实施例的一种应用环境架构图。本技术可应用于包括，但不仅限于数据源平台2、数据同步服务平台4、下游服务平台6的应用环境中。55.其中，所述数据源平台2用于提供数据源。所述数据源平台2可以包括内部数据源，也可以是连接外部数据源的数据接口。所述数据源平台2中可以有多种格式的数据，例如，app和web的上报数据是http(hypertexttransferprotocol，超文本传输协议)格式的数据，服务端的内部通信数据是rpc(remoteprocedurecall，远程过程调用)格式的数据。所述数据源平台2的数据可以是通过一个或多个边缘节点接收的移动终端上报的日志数据等，也可以是数据库(例如mysql、tidb)、日志代理(logagent)等各个系统或设备提供的数据。56.所述数据同步服务平台4用于从所述数据源平台2中采集全量和/或增量数据，为每一条数据分配有序且唯一的编号，然后按照所述编号对所述数据进行全局有序排列和去重处理，最后按顺序写入数据湖表中。所述数据同步服务平台4可以是服务器。所述服务器可以是机架式服务器、刀片式服务器、塔式服务器或机柜式服务器等计算设备，可以是独立的服务器，也可以是多个服务器所组成的服务器集群。57.所述下游服务平台6用于从所述数据湖表中读取数据并进行下一步处理。58.所述数据源平台2、数据同步服务平台4、下游服务平台6之间通过网络通信连接，以进行数据传输和交互。所述网络可以是企业内部网(intranet)、互联网(internet)、全球移动通讯系统(globalsystemofmobilecommunication，gsm)、宽带码分多址(widebandcodedivisionmultipleaccess，wcdma)、4g网络、5g网络、蓝牙(bluetooth)、wi‑fi等无线或有线网络。59.实施例一60.如图2所示，为本技术第一实施例提出的一种数据同步方法的流程图。可以理解，本方法实施例中的流程图不用于对执行步骤的顺序进行限定。根据需要，还可以对该流程图中的部分步骤进行添加或删减。下面以所述数据同步服务平台作为执行主体对该方法进行说明。61.该方法包括以下步骤：62.s200，从数据源中采集全量数据和增量数据。63.所述数据源来自所述数据源平台，在本实施例中，可以是例如mysql、tidb等数据库。64.针对现有技术只能将全量数据和增量数据分开进行同步，且处理不够及时的缺陷，本实施例可以对全量数据和增量数据一体化打通处理，并且实现分钟级的同步。在本实施例中，主要通过快照技术按天采集所述全量数据，通过读取增量日志分钟级采集所述增量数据。65.举例而言，针对mysql数据源，基于flinkcdc，通过snapshot的全量快照拉取得到所述全量数据(snapshotreader)，通过读取binlog日志得到所述增量数据(binlogreader)。66.针对tidb数据源，由于tidb通过select拉取数据效率和性能过差(线上也不允许)，因此采用代理(agent)采集从节点(slave节点)的dump(进程的内存镜像)文件得到所述全量数据(filereader)，并同样通过读取binlog日志得到所述增量数据(binlogreader)。67.s202，为采集的每一条数据分配有序且唯一的编号(id)。68.在从数据源拉取数据到写入hudi的数据同步过程中，由于数据量庞大，可能会出现乱序或者重复。尤其当全量数据和增量数据一体化打通之后，更需要保证数据的有序性和唯一性。在本实施例中，通过为采集的每一条数据分配有序且唯一的id来保证每条数据的有序性和唯一性。为了使该id有序且唯一，本实施例采用了时间戳(timestamp)加单调递增id(seq_id)相结合的方式。69.具体而言，进一步参阅图3，为上述步骤s202的细化流程示意图。可以理解，该流程图不用于对执行步骤的顺序进行限定。根据需要，还可以对该流程图中的部分步骤进行添加或删减。在本实施例中，所述步骤s202具体包括：70.s2020，记录当前的系统生成时间，作为一个时间戳。71.所述数据的采集是从数据源中串行拉取，每条数据都有一个对应的时间戳。所述时间戳可以采用纳秒级单位。72.s2022，生成一个单调递增id。73.在所述时间戳之外，还为每条数据生成一个seq_id。所述seq_id为实例级单调递增id，没有状态，重启会重置。74.s2024，将所述时间戳加上所述单调递增id作为所述有序且唯一的编号分配给当前数据。75.所述时间戳保证了每条数据的顺序，所述单调递增id保证了相同时间内即使有多条数据也不会有重复编号，结合所述时间戳和所述单调递增id，保证了每条数据的编号有序且唯一。76.并且，在本实施例中还可以对所述全量数据和所述增量数据均进行格式标准化，便于后续处理。在最后将所述数据传输给下游之前，还可以根据所述标准化的格式解析数据，则下游服务平台不需要再另外进行解析，可以直接使用所述数据。77.回到图2，s204，对所述数据按照所述编号进行全局有序排列和去重处理。78.在本实施例中，分配所述编号之后的数据可以经由消息系统传输至flinkhudi。所述消息系统可以由一个或多个kafka集群构成，用于将所述数据发布到相应的主题下。不同重要性、优先级、数据吞吐量的数据，可以被分流到不同的kafka集群中，以保障不同类型数据的价值，避免系统故障影响整体数据。79.具体而言，kafkasink将带有编号的所述数据推送到kafka消息队列中，flinkhudi从所述kafka消息队列中消费当前数据，然后对所述数据按照所述编号进行全局有序排列和去重处理。80.由于每条数据都带有所述编号，且所述编号是全局有序编号，因此可以对数据乱序进行过滤处理，将所有数据进行全局有序排列。又因为所述编号是全局唯一编号，因此当出现相同编号时则表示数据重复，可以根据所述编号进行去重处理，保障数据质量。81.s206，将处理后的数据按顺序写入数据湖表中。82.当对所述数据经过全局有序排列和去重处理后，可以将处理后的数据通过hudisink写入相应的hudi表中。83.本实施例提出的数据同步方法，可以对全量数据和增量数据进行一体化打通，数据格式标准化，并实现分钟级数据同步和一键增量化入仓。通过向每条数据分配有序且唯hudi从所述kafka消息队列中消费当前数据，然后对所述数据按照所述编号进行全局有序排列和去重处理。99.由于每条数据都带有所述编号，且所述编号是全局有序编号，因此可以对数据乱序进行过滤处理，将所有数据进行全局有序排列。又因为所述编号是全局唯一编号，因此当出现相同编号时则表示数据重复，可以根据所述编号进行去重处理，保障数据质量。100.s306，将处理后的数据按顺序写入数据湖表中。101.当对所述数据经过全局有序排列和去重处理后，可以将处理后的数据通过hudisink写入相应的hudi表中。102.s308，根据从所述数据源中采集的至少部分数据与所述数据湖表中对应的至少部分数据，检验数据传输质量。103.在本实施例中，对所述数据进行阻断式dqc(数据质量检测)，可以保障下游的数据质量。即，在数据全部湖化前，湖仓的过程中存在联动，通过所述检测对数据质量兜底。104.在本实施例中，比对从所述数据源中采集的至少部分数据与所述数据湖表中对应的至少部分数据是否一致；及根据比对结果确定所述数据传输质量。105.若对比结果为一致，则说明数据写入质量高，可以交由下游使用。106.若对比结果不一致，则说明数据写入质量低，不可以交由下游使用。107.所述“至少部分数据”可以是按照预设比例进行采样得到的数据，例如所述比例可以是10％；也可以是预先按照固定频次安排的打桩数据，例如每分钟向mysql数据库中插入一千条数据(包含更新)，根据所述打桩数据和hudi表中对应的数据进行比对。108.值得注意的是，在其他实施例中，所述“至少部分数据”也可以是其他形式的数据，或者所述dqc还可以采用其他可行的检测方式，又或者还可以将多种检测方案相结合，综合判断所述数据传输质量。109.s310，提交所述数据的分区信息。110.其中，所述分区信息包括hudi表的huid分区信息和兼容hive表的hive分区信息。111.通过提供hive分区信息，可以将hudi表作为hive表使用。可以打通湖仓链路且使下游透明，例如：兼容hive，每小时/天分区，使得etl调度透明。112.本实施例提出的数据同步方法，可以对全量数据和增量数据进行一体化打通，数据格式标准化，并实现分钟级数据同步和一键增量化入仓。通过向每条数据分配有序且唯一的编号，保证了所述全量数据和所述增量数据的有序性和唯一性，保障了数据传输质量。另外，该方法引入校验机制，可以对数据质量进行兜底。并且兼容hive分区，可以打通湖仓链路且使下游透明。113.如图5所示，为本技术中一种具体应用实例的示意图。114.在图5中，基于flinkcdc，通过snapshotreader采集mysql数据源的全量数据。采用agent，通过filereader采集slave节点的dump文件得到tidb数据源的全量数据。而mysql数据源和tidb数据源的增量数据均可通过binlogreader读取binlog日志得到。115.在transform中对所采集到的全量数据和增量数据中每一条数据分别分配有序且唯一的id，并进行格式标准化。然后由kafkasink将带有该id的数据推送到kafka消息队列中。flinkhudi从所述kafka消息队列中消费当前数据，hudiformat对所述数据按照所述id进行全局有序排列和去重处理。处理后的数据通过hudisink写入相应的hudi表中。阻断式dqc对从数据湖中采集的数据和hudi表中的对应数据进行比对，保障下游的数据质量。当检测通过后才能创建分区，提交所述数据的分区信息。所述分区信息包括hudi表的huid分区信息和兼容hive表的hive分区信息。116.实施例三117.如图6所示，为本技术第三实施例提出一种电子装置20的硬件架构示意图。本实施例中，所述电子装置20可包括，但不仅限于，可通过系统总线相互通信连接的存储器21、处理器22、网络接口23。需要指出的是，图6仅示出了具有组件21‑23的电子装置20，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。在本实施例中，所述电子装置20可以是所述数据同步服务平台4。118.所述存储器21至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，sd或dx存储器等)、随机访问存储器(ram)、静态随机访问存储器(sram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、可编程只读存储器(prom)、磁性存储器、磁盘、光盘等。在一些实施例中，所述存储器21可以是所述电子装置20的内部存储单元，例如该电子装置20的硬盘或内存。在另一些实施例中，所述存储器21也可以是所述电子装置20的外部存储设备，例如该电子装置20上配备的插接式硬盘，智能存储卡(smartmediacard,smc)，安全数字(securedigital,sd)卡，闪存卡(flashcard)等。当然，所述存储器21还可以既包括所述电子装置20的内部存储单元也包括其外部存储设备。本实施例中，所述存储器21通常用于存储安装于所述电子装置20的操作系统和各类应用软件，例如数据同步系统60的程序代码等。此外，所述存储器21还可以用于暂时地存储已经输出或者将要输出的各类数据。119.所述处理器22在一些实施例中可以是中央处理器(centralprocessingunit，cpu)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器22通常用于控制所述电子装置20的总体操作。本实施例中，所述处理器22用于运行所述存储器21中存储的程序代码或者处理数据，例如运行所述数据同步系统60等。120.所述网络接口23可包括无线网络接口或有线网络接口，该网络接口23通常用于在所述电子装置20与其他电子设备之间建立通信连接。121.实施例四122.如图7所示，为本技术第四实施例提出一种数据同步系统60的模块示意图。所述数据同步系统60可以被分割成一个或多个程序模块，一个或者多个程序模块被存储于存储介质中，并由一个或多个处理器所执行，以完成本技术实施例。本技术实施例所称的程序模块是指能够完成特定功能的一系列计算机程序指令段，以下描述将具体介绍本实施例各程序模块的功能。123.在本实施例中，所述数据同步系统60包括：124.采集模块600，用于从数据源中采集全量数据和增量数据。125.所述数据源来自所述数据源平台，在本实施例中，可以是例如mysql、tidb等数据库。126.针对现有技术只能将全量数据和增量数据分开进行同步，且处理不够及时的缺陷，本实施例可以对全量数据和增量数据一体化打通处理，并且实现分钟级的同步。在本实施例中，主要通过快照技术按天采集所述全量数据，通过读取增量日志分钟级采集所述增量数据。127.举例而言，针对mysql数据源，基于flinkcdc，通过snapshot的全量快照拉取得到所述全量数据(snapshotreader)，通过读取binlog日志得到所述增量数据(binlogreader)。128.针对tidb数据源，由于tidb通过select拉取数据效率和性能过差(线上也不允许)，因此采用代理(agent)采集从节点(slave节点)的dump(进程的内存镜像)文件得到所述全量数据(filereader)，并同样通过读取binlog日志得到所述增量数据(binlogreader)。129.分配模块602，用于为采集的每一条数据分配有序且唯一的编号(id)。130.在从数据源拉取数据到写入hudi的数据同步过程中，由于数据量庞大，可能会出现乱序或者重复。尤其当全量数据和增量数据一体化打通之后，更需要保证数据的有序性和唯一性。在本实施例中，通过为采集的每一条数据分配有序且唯一的id来保证每条数据的有序性和唯一性。为了使该id有序且唯一，本实施例采用了时间戳(timestamp)加单调递增id(seq_id)相结合的方式。所述时间戳可以采用纳秒级单位。131.所述时间戳保证了每条数据的顺序，所述单调递增id保证了相同时间内即使有多条数据也不会有重复编号，结合所述时间戳和所述单调递增id，保证了每条数据的编号有序且唯一。132.并且，在本实施例中还可以对所述全量数据和所述增量数据均进行格式标准化，便于后续处理。在最后将所述数据传输给下游之前，还可以根据所述标准化的格式解析数据，则下游服务平台不需要再另外进行解析，可以直接使用所述数据。133.处理模块604，用于对所述数据按照所述编号进行全局有序排列和去重处理。134.在本实施例中，分配所述编号之后的数据可以经由消息系统传输至flinkhudi。所述消息系统可以由一个或多个kafka集群构成，用于将所述数据发布到相应的主题下。不同重要性、优先级、数据吞吐量的数据，可以被分流到不同的kafka集群中，以保障不同类型数据的价值，避免系统故障影响整体数据。135.具体而言，kafkasink将带有编号的所述数据推送到kafka消息队列中，flinkhudi从所述kafka消息队列中消费当前数据，然后对所述数据按照所述编号进行全局有序排列和去重处理。136.由于每条数据都带有所述编号，且所述编号是全局有序编号，因此可以对数据乱序进行过滤处理，将所有数据进行全局有序排列。又因为所述编号是全局唯一编号，因此当出现相同编号时则表示数据重复，可以根据所述编号进行去重处理，保障数据质量。137.写入模块606，用于将处理后的数据按顺序写入数据湖表中。138.当对所述数据经过全局有序排列和去重处理后，可以将处理后的数据通过hudisink写入相应的hudi表中。139.本实施例提出的数据同步系统，可以对全量数据和增量数据进行一体化打通，数据格式标准化，并实现分钟级数据同步和一键增量化入仓。通过向每条数据分配有序且唯一的编号，保证了所述全量数据和所述增量数据的有序性和唯一性，保障了数据传输质量。140.实施例五141.如图8所示，为本技术第五实施例提出一种数据同步系统60的模块示意图。在本实施例中，所述数据同步系统60除了包括第四实施例中的所述采集模块600、分配模块602、处理模块604、写入模块606之外，还包括检测模块608、分区模块610。142.所述检测模块608，用于根据从所述数据源中采集的至少部分数据与所述数据湖表中对应的至少部分数据，检验数据传输质量。143.在本实施例中，对所述数据进行阻断式dqc(数据质量检测)，可以保障下游的数据质量。即，在数据全部湖化前，湖仓的过程中存在联动，通过所述检测对数据质量兜底。144.在本实施例中，比对从所述数据源中采集的至少部分数据与所述数据湖表中对应的至少部分数据是否一致；及根据比对结果确定所述数据传输质量。145.若对比结果为一致，则说明数据写入质量高，可以交由下游使用。146.若对比结果不一致，则说明数据写入质量低，不可以交由下游使用。147.所述“至少部分数据”可以是按照预设比例进行采样得到的数据，例如所述比例可以是10％；也可以是预先按照固定频次安排的打桩数据，例如每分钟向mysql数据库中插入一千条数据(包含更新)，根据所述打桩数据和hudi表中对应的数据进行比对。148.值得注意的是，在其他实施例中，所述“至少部分数据”也可以是其他形式的数据，或者所述dqc还可以采用其他可行的检测方式，又或者还可以将多种检测方案相结合，综合判断所述数据传输质量。149.所述分区模块610，用于提交所述数据的分区信息。150.其中，所述分区信息包括hudi表的huid分区信息和兼容hive表的hive分区信息。151.通过提供hive分区信息，可以将hudi表作为hive表使用。可以打通湖仓链路且使下游透明，例如：兼容hive，每小时/天分区，使得etl调度透明。152.本实施例提出的数据同步系统，通过引入校验机制，可以对数据质量进行兜底。并且兼容hive分区，可以打通湖仓链路且使下游透明。153.实施例六154.本技术还提供了另一种实施方式，即提供一种计算机可读存储介质，所述计算机可读存储介质存储有数据同步程序，所述数据同步程序可被至少一个处理器执行，以使所述至少一个处理器执行如上述的数据同步方法的步骤。155.需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。156.上述本技术实施例序号仅仅为了描述，不代表实施例的优劣。157.显然，本领域的技术人员应该明白，上述的本技术实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本技术实施例不限制于任何特定的硬件和软件结合。158.以上仅为本技术实施例的优选实施例，并非因此限制本技术实施例的专利范围，凡是利用本技术实施例说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的
技术领域：
：，均同理包括在本技术实施例的专利保护范围内。当前第1页12当前第1页12
技术领域：
：，尤其涉及一种数据同步方法、系统、电子装置及计算机可读存储介质。
背景技术：
：：2.目前对于从数据源到数据湖表的数据同步过程，一般只能将全量数据的同步和增量数据的同步分开进行。例如按天拉取全量数据，每小时拉取增量数据，并对所述全量数据和所述增量数据进行在线合并。该方案只能实现小时级数据同步，处理时效性低，并且用户体验不透明。3.需要说明的是，上述内容并不用于限制申请保护范围。技术实现要素：4.本技术的主要目的在于提出一种数据同步方法、系统、电子装置及计算机可读存储介质，旨在解决如何打通全量数据和增量数据的同步，以及提高处理时效性和透明性的问题。5.为实现上述目的，本技术实施例提供了一种数据同步方法，所述方法包括：6.从数据源中采集全量数据和增量数据；7.为采集的每一条数据分配有序且唯一的编号；8.对所述数据按照所述编号进行全局有序排列和去重处理；及9.将处理后的数据按顺序写入数据湖表中。10.可选地，所述方法还包括：11.根据从所述数据源中采集的至少部分数据与所述数据湖表中对应的至少部分数据，检验数据传输质量。12.可选地，所述从数据源中采集全量数据和增量数据包括：13.通过快照技术按天采集所述全量数据，通过读取增量日志分钟级采集所述增量数据。14.可选地，所述从数据源中采集全量数据和增量数据包括：15.针对第一预设类型数据源，基于flinkcdc，通过全量快照技术拉取得到所述全量数据，通过读取binlog日志得到所述增量数据。16.可选地，所述从数据源中采集全量数据和增量数据还包括：17.针对第二预设类型数据源，通过代理采集从节点的dump文件得到所述全量数据，通过读取binlog日志得到所述增量数据。18.可选地，所述为采集的每一条数据分配有序且唯一的编号包括：19.记录当前的系统生成时间，作为一个时间戳；20.生成一个单调递增编号；21.将所述时间戳加上所述单调递增编号作为所述有序且唯一的编号分配给当前数据。22.可选地，所述方法在所述为采集的每一条数据分配有序且唯一的编号和所述对所述数据按照所述编号进行全局有序排列和去重处理之间还包括：23.将带有编号的所述数据推送到kafka消息队列中；24.从所述kafka消息队列中消费当前数据。25.此外，为实现上述目的，本技术实施例还提供一种数据同步系统，所述系统包括：26.采集模块，用于从数据源中采集全量数据和增量数据；27.分配模块，用于为采集的每一条数据分配有序且唯一的编号；28.处理模块，用于对所述数据按照所述编号进行全局有序排列和去重处理；29.写入模块，用于将处理后的数据按顺序写入数据湖表中。30.为实现上述目的，本技术实施例还提供一种电子装置，所述电子装置包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的数据同步程序，所述数据同步程序被所述处理器执行时实现如上述的数据同步方法。31.为实现上述目的，本技术实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有数据同步程序，所述数据同步程序被处理器执行时实现如上述的数据同步方法。32.本技术实施例提出的数据同步方法、系统、电子装置及计算机可读存储介质，能够对全量数据和增量数据进行一体化打通，并实现分钟级数据同步和一键增量化入仓。通过向每条数据分配有序且唯一的编号，保证了所述全量数据和所述增量数据的有序性和唯一性，保障了数据传输质量。附图说明33.图1为实现本技术各个实施例的一种应用环境架构图；34.图2为本技术第一实施例提出的一种数据同步方法的流程图；35.图3为图2中步骤s202的细化流程示意图；36.图4为本技术第二实施例提出的一种数据同步方法的流程图；37.图5为本技术中一种具体应用实例的示意图；38.图6为本技术第三实施例提出的一种电子装置的硬件架构示意图；39.图7为本技术第四实施例提出的一种数据同步系统的模块示意图；40.图8为本技术第五实施例提出的一种数据同步系统的模块示意图。具体实施方式41.为了使本技术的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本技术进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本技术，并不用于限定本技术。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。42.需要说明的是，在本技术实施例中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本技术要求的保护范围之内。43.为了方便理解，以下提供了一些术语解释：44.etl，是一种数据仓库技术，是抽取(extract)、转换(transform)、加载(load)的缩写。etl是将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程，目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析依据。etl是商业智能(businessintelligence，bi)项目重要的一个环节。45.flink集群(flinkcluster)，是一个分布式系统，用于对无界和有界数据流进行有状态计算。flink设计为在所有常见的集群环境中运行，以内存速度和任何规模执行计算。46.cdc(changedatacapture)，是oracle在数据库级别实现的增量抽取解决方案。它是一个比较广义的概念，只要能捕获变更的数据，都可以称为cdc。业界主要有基于查询的cdc和基于日志的cdc。47.kafka，是一个分布式、分区的、多副本的、多订阅者，基于zookeeper协调的分布式日志系统，也可以作为消息队列系统。kafka可以用于web/nginx日志、访问日志，消息服务等。kafka是按秒进行任务的计算和应用，用于实时推荐、实时计算等场景中。48.sink，在无线传感器网络指汇聚结点，主要负责传感器网与外网(例如gprs、internet等)的连接，可看作网关节点。49.mysql，是一种关系型数据库管理系统，关系数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。mysql所使用的sql语言是用于访问数据库的最常用标准化语言。50.tidb，是一种开源分布式关系型数据库，同时支持在线事务处理与在线分析处理(hybridtransactionalandanalyticalprocessing，htap)，具备水平扩容或者缩容、金融级高可用、实时htap、云原生的分布式数据库、兼容mysql5.7协议和mysql生态等重要特性。目标是为用户提供一站式联机事务处处理(onlinetransactionalprocessing，oltp)、联机分析处理(onlineanalyticalprocessing，olap)、htap解决方案。tidb适合高可用、强一致要求较高、数据规模较大等各种应用场景。51.hudi(hadoopupdatesandincrementals，hadoop更新与增量)，采用并管理通过dfs(hdfs或云存储)存储大型分析数据集，支持在当前数据表中进行更新操作。hudi将表组织成hdfs上某个指定目录(basepath)下的目录结构，表被分成多个分区，分区是以目录的形式存在，每个目录下面会存在属于该分区的多个文件，类似hive表，每个hudi表分区通过一个分区路径(partitionpath)来唯一标识。52.snapshot，也就是快照技术或磁盘快照。snapshot是针对整个磁盘卷册进行快速的档案系统备份，与其它备份方式最主要的不同点在于速度。进行磁盘快照时，并不牵涉到任何档案复制动作。就算数据量再大，一般来说，通常可以在一秒之内完成备份动作。53.binlog日志，是记录所有数据库表结构变更(如create、altertable)及表数据修改(insert、update、delete)的二进制日志。binlog日志的格式为json。54.请参阅图1，图1为实现本技术各个实施例的一种应用环境架构图。本技术可应用于包括，但不仅限于数据源平台2、数据同步服务平台4、下游服务平台6的应用环境中。55.其中，所述数据源平台2用于提供数据源。所述数据源平台2可以包括内部数据源，也可以是连接外部数据源的数据接口。所述数据源平台2中可以有多种格式的数据，例如，app和web的上报数据是http(hypertexttransferprotocol，超文本传输协议)格式的数据，服务端的内部通信数据是rpc(remoteprocedurecall，远程过程调用)格式的数据。所述数据源平台2的数据可以是通过一个或多个边缘节点接收的移动终端上报的日志数据等，也可以是数据库(例如mysql、tidb)、日志代理(logagent)等各个系统或设备提供的数据。56.所述数据同步服务平台4用于从所述数据源平台2中采集全量和/或增量数据，为每一条数据分配有序且唯一的编号，然后按照所述编号对所述数据进行全局有序排列和去重处理，最后按顺序写入数据湖表中。所述数据同步服务平台4可以是服务器。所述服务器可以是机架式服务器、刀片式服务器、塔式服务器或机柜式服务器等计算设备，可以是独立的服务器，也可以是多个服务器所组成的服务器集群。57.所述下游服务平台6用于从所述数据湖表中读取数据并进行下一步处理。58.所述数据源平台2、数据同步服务平台4、下游服务平台6之间通过网络通信连接，以进行数据传输和交互。所述网络可以是企业内部网(intranet)、互联网(internet)、全球移动通讯系统(globalsystemofmobilecommunication，gsm)、宽带码分多址(widebandcodedivisionmultipleaccess，wcdma)、4g网络、5g网络、蓝牙(bluetooth)、wi‑fi等无线或有线网络。59.实施例一60.如图2所示，为本技术第一实施例提出的一种数据同步方法的流程图。可以理解，本方法实施例中的流程图不用于对执行步骤的顺序进行限定。根据需要，还可以对该流程图中的部分步骤进行添加或删减。下面以所述数据同步服务平台作为执行主体对该方法进行说明。61.该方法包括以下步骤：62.s200，从数据源中采集全量数据和增量数据。63.所述数据源来自所述数据源平台，在本实施例中，可以是例如mysql、tidb等数据库。64.针对现有技术只能将全量数据和增量数据分开进行同步，且处理不够及时的缺陷，本实施例可以对全量数据和增量数据一体化打通处理，并且实现分钟级的同步。在本实施例中，主要通过快照技术按天采集所述全量数据，通过读取增量日志分钟级采集所述增量数据。65.举例而言，针对mysql数据源，基于flinkcdc，通过snapshot的全量快照拉取得到所述全量数据(snapshotreader)，通过读取binlog日志得到所述增量数据(binlogreader)。66.针对tidb数据源，由于tidb通过select拉取数据效率和性能过差(线上也不允许)，因此采用代理(agent)采集从节点(slave节点)的dump(进程的内存镜像)文件得到所述全量数据(filereader)，并同样通过读取binlog日志得到所述增量数据(binlogreader)。67.s202，为采集的每一条数据分配有序且唯一的编号(id)。68.在从数据源拉取数据到写入hudi的数据同步过程中，由于数据量庞大，可能会出现乱序或者重复。尤其当全量数据和增量数据一体化打通之后，更需要保证数据的有序性和唯一性。在本实施例中，通过为采集的每一条数据分配有序且唯一的id来保证每条数据的有序性和唯一性。为了使该id有序且唯一，本实施例采用了时间戳(timestamp)加单调递增id(seq_id)相结合的方式。69.具体而言，进一步参阅图3，为上述步骤s202的细化流程示意图。可以理解，该流程图不用于对执行步骤的顺序进行限定。根据需要，还可以对该流程图中的部分步骤进行添加或删减。在本实施例中，所述步骤s202具体包括：70.s2020，记录当前的系统生成时间，作为一个时间戳。71.所述数据的采集是从数据源中串行拉取，每条数据都有一个对应的时间戳。所述时间戳可以采用纳秒级单位。72.s2022，生成一个单调递增id。73.在所述时间戳之外，还为每条数据生成一个seq_id。所述seq_id为实例级单调递增id，没有状态，重启会重置。74.s2024，将所述时间戳加上所述单调递增id作为所述有序且唯一的编号分配给当前数据。75.所述时间戳保证了每条数据的顺序，所述单调递增id保证了相同时间内即使有多条数据也不会有重复编号，结合所述时间戳和所述单调递增id，保证了每条数据的编号有序且唯一。76.并且，在本实施例中还可以对所述全量数据和所述增量数据均进行格式标准化，便于后续处理。在最后将所述数据传输给下游之前，还可以根据所述标准化的格式解析数据，则下游服务平台不需要再另外进行解析，可以直接使用所述数据。77.回到图2，s204，对所述数据按照所述编号进行全局有序排列和去重处理。78.在本实施例中，分配所述编号之后的数据可以经由消息系统传输至flinkhudi。所述消息系统可以由一个或多个kafka集群构成，用于将所述数据发布到相应的主题下。不同重要性、优先级、数据吞吐量的数据，可以被分流到不同的kafka集群中，以保障不同类型数据的价值，避免系统故障影响整体数据。79.具体而言，kafkasink将带有编号的所述数据推送到kafka消息队列中，flinkhudi从所述kafka消息队列中消费当前数据，然后对所述数据按照所述编号进行全局有序排列和去重处理。80.由于每条数据都带有所述编号，且所述编号是全局有序编号，因此可以对数据乱序进行过滤处理，将所有数据进行全局有序排列。又因为所述编号是全局唯一编号，因此当出现相同编号时则表示数据重复，可以根据所述编号进行去重处理，保障数据质量。81.s206，将处理后的数据按顺序写入数据湖表中。82.当对所述数据经过全局有序排列和去重处理后，可以将处理后的数据通过hudisink写入相应的hudi表中。83.本实施例提出的数据同步方法，可以对全量数据和增量数据进行一体化打通，数据格式标准化，并实现分钟级数据同步和一键增量化入仓。通过向每条数据分配有序且唯hudi从所述kafka消息队列中消费当前数据，然后对所述数据按照所述编号进行全局有序排列和去重处理。99.由于每条数据都带有所述编号，且所述编号是全局有序编号，因此可以对数据乱序进行过滤处理，将所有数据进行全局有序排列。又因为所述编号是全局唯一编号，因此当出现相同编号时则表示数据重复，可以根据所述编号进行去重处理，保障数据质量。100.s306，将处理后的数据按顺序写入数据湖表中。101.当对所述数据经过全局有序排列和去重处理后，可以将处理后的数据通过hudisink写入相应的hudi表中。102.s308，根据从所述数据源中采集的至少部分数据与所述数据湖表中对应的至少部分数据，检验数据传输质量。103.在本实施例中，对所述数据进行阻断式dqc(数据质量检测)，可以保障下游的数据质量。即，在数据全部湖化前，湖仓的过程中存在联动，通过所述检测对数据质量兜底。104.在本实施例中，比对从所述数据源中采集的至少部分数据与所述数据湖表中对应的至少部分数据是否一致；及根据比对结果确定所述数据传输质量。105.若对比结果为一致，则说明数据写入质量高，可以交由下游使用。106.若对比结果不一致，则说明数据写入质量低，不可以交由下游使用。107.所述“至少部分数据”可以是按照预设比例进行采样得到的数据，例如所述比例可以是10％；也可以是预先按照固定频次安排的打桩数据，例如每分钟向mysql数据库中插入一千条数据(包含更新)，根据所述打桩数据和hudi表中对应的数据进行比对。108.值得注意的是，在其他实施例中，所述“至少部分数据”也可以是其他形式的数据，或者所述dqc还可以采用其他可行的检测方式，又或者还可以将多种检测方案相结合，综合判断所述数据传输质量。109.s310，提交所述数据的分区信息。110.其中，所述分区信息包括hudi表的huid分区信息和兼容hive表的hive分区信息。111.通过提供hive分区信息，可以将hudi表作为hive表使用。可以打通湖仓链路且使下游透明，例如：兼容hive，每小时/天分区，使得etl调度透明。112.本实施例提出的数据同步方法，可以对全量数据和增量数据进行一体化打通，数据格式标准化，并实现分钟级数据同步和一键增量化入仓。通过向每条数据分配有序且唯一的编号，保证了所述全量数据和所述增量数据的有序性和唯一性，保障了数据传输质量。另外，该方法引入校验机制，可以对数据质量进行兜底。并且兼容hive分区，可以打通湖仓链路且使下游透明。113.如图5所示，为本技术中一种具体应用实例的示意图。114.在图5中，基于flinkcdc，通过snapshotreader采集mysql数据源的全量数据。采用agent，通过filereader采集slave节点的dump文件得到tidb数据源的全量数据。而mysql数据源和tidb数据源的增量数据均可通过binlogreader读取binlog日志得到。115.在transform中对所采集到的全量数据和增量数据中每一条数据分别分配有序且唯一的id，并进行格式标准化。然后由kafkasink将带有该id的数据推送到kafka消息队列中。flinkhudi从所述kafka消息队列中消费当前数据，hudiformat对所述数据按照所述id进行全局有序排列和去重处理。处理后的数据通过hudisink写入相应的hudi表中。阻断式dqc对从数据湖中采集的数据和hudi表中的对应数据进行比对，保障下游的数据质量。当检测通过后才能创建分区，提交所述数据的分区信息。所述分区信息包括hudi表的huid分区信息和兼容hive表的hive分区信息。116.实施例三117.如图6所示，为本技术第三实施例提出一种电子装置20的硬件架构示意图。本实施例中，所述电子装置20可包括，但不仅限于，可通过系统总线相互通信连接的存储器21、处理器22、网络接口23。需要指出的是，图6仅示出了具有组件21‑23的电子装置20，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。在本实施例中，所述电子装置20可以是所述数据同步服务平台4。118.所述存储器21至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，sd或dx存储器等)、随机访问存储器(ram)、静态随机访问存储器(sram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、可编程只读存储器(prom)、磁性存储器、磁盘、光盘等。在一些实施例中，所述存储器21可以是所述电子装置20的内部存储单元，例如该电子装置20的硬盘或内存。在另一些实施例中，所述存储器21也可以是所述电子装置20的外部存储设备，例如该电子装置20上配备的插接式硬盘，智能存储卡(smartmediacard,smc)，安全数字(securedigital,sd)卡，闪存卡(flashcard)等。当然，所述存储器21还可以既包括所述电子装置20的内部存储单元也包括其外部存储设备。本实施例中，所述存储器21通常用于存储安装于所述电子装置20的操作系统和各类应用软件，例如数据同步系统60的程序代码等。此外，所述存储器21还可以用于暂时地存储已经输出或者将要输出的各类数据。119.所述处理器22在一些实施例中可以是中央处理器(centralprocessingunit，cpu)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器22通常用于控制所述电子装置20的总体操作。本实施例中，所述处理器22用于运行所述存储器21中存储的程序代码或者处理数据，例如运行所述数据同步系统60等。120.所述网络接口23可包括无线网络接口或有线网络接口，该网络接口23通常用于在所述电子装置20与其他电子设备之间建立通信连接。121.实施例四122.如图7所示，为本技术第四实施例提出一种数据同步系统60的模块示意图。所述数据同步系统60可以被分割成一个或多个程序模块，一个或者多个程序模块被存储于存储介质中，并由一个或多个处理器所执行，以完成本技术实施例。本技术实施例所称的程序模块是指能够完成特定功能的一系列计算机程序指令段，以下描述将具体介绍本实施例各程序模块的功能。123.在本实施例中，所述数据同步系统60包括：124.采集模块600，用于从数据源中采集全量数据和增量数据。125.所述数据源来自所述数据源平台，在本实施例中，可以是例如mysql、tidb等数据库。126.针对现有技术只能将全量数据和增量数据分开进行同步，且处理不够及时的缺陷，本实施例可以对全量数据和增量数据一体化打通处理，并且实现分钟级的同步。在本实施例中，主要通过快照技术按天采集所述全量数据，通过读取增量日志分钟级采集所述增量数据。127.举例而言，针对mysql数据源，基于flinkcdc，通过snapshot的全量快照拉取得到所述全量数据(snapshotreader)，通过读取binlog日志得到所述增量数据(binlogreader)。128.针对tidb数据源，由于tidb通过select拉取数据效率和性能过差(线上也不允许)，因此采用代理(agent)采集从节点(slave节点)的dump(进程的内存镜像)文件得到所述全量数据(filereader)，并同样通过读取binlog日志得到所述增量数据(binlogreader)。129.分配模块602，用于为采集的每一条数据分配有序且唯一的编号(id)。130.在从数据源拉取数据到写入hudi的数据同步过程中，由于数据量庞大，可能会出现乱序或者重复。尤其当全量数据和增量数据一体化打通之后，更需要保证数据的有序性和唯一性。在本实施例中，通过为采集的每一条数据分配有序且唯一的id来保证每条数据的有序性和唯一性。为了使该id有序且唯一，本实施例采用了时间戳(timestamp)加单调递增id(seq_id)相结合的方式。所述时间戳可以采用纳秒级单位。131.所述时间戳保证了每条数据的顺序，所述单调递增id保证了相同时间内即使有多条数据也不会有重复编号，结合所述时间戳和所述单调递增id，保证了每条数据的编号有序且唯一。132.并且，在本实施例中还可以对所述全量数据和所述增量数据均进行格式标准化，便于后续处理。在最后将所述数据传输给下游之前，还可以根据所述标准化的格式解析数据，则下游服务平台不需要再另外进行解析，可以直接使用所述数据。133.处理模块604，用于对所述数据按照所述编号进行全局有序排列和去重处理。134.在本实施例中，分配所述编号之后的数据可以经由消息系统传输至flinkhudi。所述消息系统可以由一个或多个kafka集群构成，用于将所述数据发布到相应的主题下。不同重要性、优先级、数据吞吐量的数据，可以被分流到不同的kafka集群中，以保障不同类型数据的价值，避免系统故障影响整体数据。135.具体而言，kafkasink将带有编号的所述数据推送到kafka消息队列中，flinkhudi从所述kafka消息队列中消费当前数据，然后对所述数据按照所述编号进行全局有序排列和去重处理。136.由于每条数据都带有所述编号，且所述编号是全局有序编号，因此可以对数据乱序进行过滤处理，将所有数据进行全局有序排列。又因为所述编号是全局唯一编号，因此当出现相同编号时则表示数据重复，可以根据所述编号进行去重处理，保障数据质量。137.写入模块606，用于将处理后的数据按顺序写入数据湖表中。138.当对所述数据经过全局有序排列和去重处理后，可以将处理后的数据通过hudisink写入相应的hudi表中。139.本实施例提出的数据同步系统，可以对全量数据和增量数据进行一体化打通，数据格式标准化，并实现分钟级数据同步和一键增量化入仓。通过向每条数据分配有序且唯一的编号，保证了所述全量数据和所述增量数据的有序性和唯一性，保障了数据传输质量。140.实施例五141.如图8所示，为本技术第五实施例提出一种数据同步系统60的模块示意图。在本实施例中，所述数据同步系统60除了包括第四实施例中的所述采集模块600、分配模块602、处理模块604、写入模块606之外，还包括检测模块608、分区模块610。142.所述检测模块608，用于根据从所述数据源中采集的至少部分数据与所述数据湖表中对应的至少部分数据，检验数据传输质量。143.在本实施例中，对所述数据进行阻断式dqc(数据质量检测)，可以保障下游的数据质量。即，在数据全部湖化前，湖仓的过程中存在联动，通过所述检测对数据质量兜底。144.在本实施例中，比对从所述数据源中采集的至少部分数据与所述数据湖表中对应的至少部分数据是否一致；及根据比对结果确定所述数据传输质量。145.若对比结果为一致，则说明数据写入质量高，可以交由下游使用。146.若对比结果不一致，则说明数据写入质量低，不可以交由下游使用。147.所述“至少部分数据”可以是按照预设比例进行采样得到的数据，例如所述比例可以是10％；也可以是预先按照固定频次安排的打桩数据，例如每分钟向mysql数据库中插入一千条数据(包含更新)，根据所述打桩数据和hudi表中对应的数据进行比对。148.值得注意的是，在其他实施例中，所述“至少部分数据”也可以是其他形式的数据，或者所述dqc还可以采用其他可行的检测方式，又或者还可以将多种检测方案相结合，综合判断所述数据传输质量。149.所述分区模块610，用于提交所述数据的分区信息。150.其中，所述分区信息包括hudi表的huid分区信息和兼容hive表的hive分区信息。151.通过提供hive分区信息，可以将hudi表作为hive表使用。可以打通湖仓链路且使下游透明，例如：兼容hive，每小时/天分区，使得etl调度透明。152.本实施例提出的数据同步系统，通过引入校验机制，可以对数据质量进行兜底。并且兼容hive分区，可以打通湖仓链路且使下游透明。153.实施例六154.本技术还提供了另一种实施方式，即提供一种计算机可读存储介质，所述计算机可读存储介质存储有数据同步程序，所述数据同步程序可被至少一个处理器执行，以使所述至少一个处理器执行如上述的数据同步方法的步骤。155.需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。156.上述本技术实施例序号仅仅为了描述，不代表实施例的优劣。157.显然，本领域的技术人员应该明白，上述的本技术实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本技术实施例不限制于任何特定的硬件和软件结合。158.以上仅为本技术实施例的优选实施例，并非因此限制本技术实施例的专利范围，凡是利用本技术实施例说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的
技术领域：
：，均同理包括在本技术实施例的专利保护范围内。当前第1页12当前第1页12
再多了解一些
本文用于企业家、创业者技术爱好者查询，结果仅供参考。
