CN110543472B - 数据对账方法及相关装置 - Google Patents

数据对账方法及相关装置 Download PDF

Info

Publication number
CN110543472B
CN110543472B CN201910736400.1A CN201910736400A CN110543472B CN 110543472 B CN110543472 B CN 110543472B CN 201910736400 A CN201910736400 A CN 201910736400A CN 110543472 B CN110543472 B CN 110543472B
Authority
CN
China
Prior art keywords
data
reconciliation
theoretical
partition
data volume
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201910736400.1A
Other languages
English (en)
Other versions
CN110543472A (zh
Inventor
王亮
何林强
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Zhejiang Dahua Technology Co Ltd
Original Assignee
Zhejiang Dahua Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Zhejiang Dahua Technology Co Ltd filed Critical Zhejiang Dahua Technology Co Ltd
Priority to CN201910736400.1A priority Critical patent/CN110543472B/zh
Publication of CN110543472A publication Critical patent/CN110543472A/zh
Application granted granted Critical
Publication of CN110543472B publication Critical patent/CN110543472B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases
    • G06F16/215—Improving data quality; Data cleansing, e.g. de-duplication, removing invalid entries or correcting typographical errors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/242—Query formulation
    • G06F16/2433—Query languages
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
    • G06F16/2462—Approximate or statistical queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/258—Data format conversion from or to a database

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Mathematical Physics (AREA)
  • Computational Linguistics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Quality & Reliability (AREA)
  • Fuzzy Systems (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请公开了一种数据对账方法及相关装置。其中，数据对账方法包括：获取到目的端在设定时间段内从源端接收到的实际数据量；利用每条数据的对账编号获取到设定时间段内从源端接收到的理论数据量；其中，对账编号包括数据的分区的编号以及偏移量，每个分区内的偏移量连续递增；判断实际数据量与理论数据量是否相等；如果实际数据量与理论数据量不相等，补充缺失的数据或删除重复的数据。上述方案，能够减少数据对账时长、提高数据对账效率。

Description

数据对账方法及相关装置
技术领域
本申请涉及数据处理技术领域，特别是涉及一种数据对账方法及相关装置。
背景技术
随着信息技术的快速发展，人们在日常生活中进行网购、聊天都会产生出海量数据。为了突破集中式存储处理海量数据时在可靠性、安全性等方面的瓶颈，逐渐发展出了分布式存储技术，例如Kafka消息队列等等。
在数据实时同步的场景下，特别是在跨网数据传输过程中，当出现网络不稳定、服务器异常、消息积压等异常情况时，源端数据库和目的端数据库的数据可能会不一致，例如：目的端数据库数据缺失，或者目的端数据库数据重复。为了补充缺失数据、消除重复数据，有必要对源端数据库和目的端数据库进行数据对账。目前，数据对账需要针对业务表全表进行数据对账。然而，在面对海量数据时，采用全表数据对账存在对账耗时长、对账效率低的问题。有鉴于此，如何减少数据对账耗时、提高数据对账效率成为亟待解决的问题。
发明内容
本申请主要解决的技术问题是提供一种数据对账方法及相关装置，能够减少数据对账时长、提高数据对账效率。
为了解决上述问题，本申请第一方面提供了一种数据对账方法，包括：获取到目的端在设定时间段内从源端接收到的实际数据量；利用每条数据的对账编号获取到设定时间段内从源端接收到的理论数据量；其中，对账编号包括数据的分区的编号以及偏移量，每个分区内的偏移量连续递增；判断实际数据量与理论数据量是否相等；如果实际数据量与理论数据量不相等，补充缺失的数据或删除重复的数据。
为了解决上述问题，本申请第二方面提供了一种数据对账装置，包括实际数据量获取模块、理论数据量获取模块、判断模块以及响应模块；实际数据量获取模块用于获取到目的端在设定时间段内从源端接收到的实际数据量；理论数据量获取模块用于利用每条数据的对账编号获取到设定时间段内从源端接收到的理论数据量；其中，对账编号包括数据的分区的编号以及偏移量，每个分区内的偏移量连续递增；判断模块用于判断实际数据量与理论数据量是否相等；响应模块用于在实际数据量与理论数据量不相等时，补充缺失的数据或删除重复的数据。
为了解决上述问题，本申请第三方面提供了一种数据对账装置，包括相互耦接的存储器和处理器；处理器用于执行存储器存储的程序指令，以实现上述第一方面的方法。
为了解决上述问题，本申请第四方面提供了一种存储装置，存储有能够被处理器运行的程序指令，程序指令用于实现上述第一方面的方法。
上述方案中，当存在设定时间内目的端从源端接收到的实际数据量，以及设定时间段内从源端接收到的理论数据量之间不相等的情况时，可以确定目的端存在数据重复或数据缺失，由于无需针对业务表全表进行数据对账，只需比较在设定时间段内的数据量，故此，可以节省数据对账时间，从而提升数据对账效率。
此外，当源端采用Kafka消息队列时，由于无法基于Kafka集群内部的磁盘数据进行结构化查询语言(Structured Query Language，SQL)运算而获取理论数据量，然而，本方案采用每条数据的对账编号获取设定时间段内从源端接收到的理论数据量，从而只需统计目的端接收到的数据，无需对源端进行SQL运算，进而可以大大提高对于各类数据库的兼容性。
附图说明
图1是本申请数据对账方法一实施例的流程示意图；
图2是Kafka消息队列的Topic存储格式示意图；
图3是图1中步骤S12一实施例的流程示意图；
图4是图1中源端和目的端数据对账情况一实施例的框架示意图；
图5是图1中源端和目的端数据对账情况另一实施例的框架示意图；
图6是本申请数据对账方法另一实施例的流程示意图；
图7是本申请数据对账方法又一实施例的流程示意图；
图8是图1中源端和目的端数据对账情况又一实施例的框架示意图；
图9是本申请数据对账装置一实施例的框架示意图；
图10是本申请数据对账装置另一实施例的框架示意图；
图11是本申请存储装置一实施例的框架示意图。
具体实施方式
下面结合说明书附图，对本申请实施例的方案进行详细说明。
以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、接口、技术之类的具体细节，以便透彻理解本申请。
本文中术语“系统”和“网络”在本文中常被可互换使用。本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。此外，本文中的“多”表示两个或者多于两个。
请参阅图1，图1是本申请数据对账方法一实施例的流程示意图。具体而言，可以包括：
步骤S11：获取到目的端在设定时间段内从源端接收到的实际数据量。
目的端可以为数据库，例如分布式数据库、集中式数据库。源端可以为消息队列，例如Kafka消息队列、ActiveMQ，RabbitMQ、RocketMQ等等，本实施例在此不再一一举例。关于分布式数据库、集中式数据库、消息队列为本领域的现有技术，本实施例在此不做具体限制。
设定时间段可以根据当前数据对账时间和上次数据对账时间而设置，例如，当前数据对账时间为2019年1月31日，上次数据对账时间为2019年1月1日，则设定时间段为2019年1月1日与2019年1月31日之间。设定时间段还可以自定义设置，例如将每天分为两个设定时间段，其中一个设定时间段为0点至12点，另一个设定时间段为12点至24点，或者将每周分为三个设定时间段，其中一个设定时间段为周一至周三，另一个设定时间段为周四至周五，还有一个设定时间段是周六至周日，在其他实施场景中，还可以根据实际情况进行设定时间段的设置，例如将每月分为三个设定时间段，其中一个设定时间段为每月一日至十日，另一个设定时间段为每月十一日至二十日，还有一个设定时间段为每月二十一日至月末。此外，还可以对每个季度、每年进行设定时间段的设置，本实施例在此不做具体限制。
步骤S12：利用每条数据的对账编号获取到设定时间段内从源端接收到的理论数据量。
对账编号是唯一标识每条数据的编号，从而可以利用对账编号计算设定时间段内从源端接收到的理论数据量。对账编号包括数据的分区的编号以及偏移量，每个分区内的偏移量连续递增，数据的分区是指数据所在的大类区域，数据的偏移量是指数据所在的小区域。举例来说，对于Kafka消息队列，数据的大区域是指数据所在的分区(Partition)，数据的小区域是指数据的偏移量(Offset)，对于其他消息队列，可以以此类推，本实施例在此不再一一举例。在一个实施场景中，为了确保每条数据的对账编号的唯一性，且尽量简化编号规则，可以将分区的编号以及偏移量分别转换为二进制并组成二进制对账编码，且偏移量的二进制码的字段位于分区的编号的二进制码后面，从而将组成的二进制对账编码转换为十进制后得到对账编号。以源端采用Kafka消息队列为例，请结合参阅图2，图2是Kafka消息队列存储格式示意图。Kafka消息队列中Topic属于相同消息的集合，Topic由若干个分区(Partition)组合，分区内部的消息通过偏移量(Offset)严格递增。例如，分区0(Partition0)可以采用三十二位二进制编号表示为“00000000000000000000000000000000”，分区1(Partition 1)可以采用三十二位二进制编号表示为“00000000000000000000000000000001”，分区2(Partition 2)可以采用三十二位二进制编号表示为“00000000000000000000000000000010”，以此类推，本实施例在此不再一一举例。进一步地，偏移量0可以采用三十二位二进制编号表示为“00000000000000000000000000000000”，偏移量1可以采用三十二位二进制编号表示为“00000000000000000000000000000001”，偏移量2可以采用三十二位二进制编号表示为“00000000000000000000000000000010”，以此类推，本实施例在此不再一一举例。通过组合分区的编号和偏移量的编号可以表示为任意分区中偏移量，即数据的对账编号，例如，分区0中偏移量0可以采用六十四位二进制编号表示为“0000000000000000000000000000000000000000000000000000000000000000”，采用十进制表示为0，即分区0中偏移量0的数据的对账编号为0，以此类推，分区1偏移量0可以采用六十四位二进制编号表示为“0000000000000000000000000000000100000000000000000000000000000000”，采用十进制表示为4294967296，即分区1偏移量0的数据的对账编号为4294967296，以此类推，分区2偏移量0可以采用十进制表示为8589934592，即分区2偏移量0的数据的对账编号为8589934592，以此类推，本实施例在此不再一一举例。
由此可见，通过上述方式对数据进行编号，可以使得数据的对账编号具有唯一性，且不断递增。本实施例所举的采用三十二位二进制编码对分区和偏移量进行编号仅仅是实际应用中可能存在的一种方式，在其他实施场景中，还可以具体根据数据库所设计的存储量限定编码位数，例如十六位二进制、二十位二进制等等，本实施例在此不做具体限制。
由于对账编号具有唯一性且在分区内具有连续递增性，因此，在一个实施场景中，为了快速、准确地利用对账编号计算出从源端接收到的理论数据量，可以利用该性质统计出每一分区的理论数据量，最终计算出所有分区的理论数据量。
步骤S13：判断实际数据量与理论数据量是否相等，若否，则执行步骤S14。
当确定目的端在设定时间段内从源端接收到的实际数据量，以及从源端接收到的理论数据量后，通过比较实际数据量与理论数据量是否相等，可以确定数据对账的最终结果，例如：存在数据缺失或者数据重复等数据异常问题，或者数据对账无误。
步骤S14：补充缺失的数据或删除重复的数据。
当判断实际数据量与理论数据量不相等时，则可以确定目的端存在数据缺失或者数据重复等数据异常问题，从而可以进一步补充缺失的数据或者删除重复的数据。
在一个实施场景中，为了确定目的端所存在的数据对账不一致问题具体是数据缺失还是数据重复，从而可以针对性地补充缺失的数据或删除重复的数据，进而使得目的端的数据完整，还可以比较实际数据量是否大于理论数据量，如果实际数据量大于理论数据量，则可以确定存在数据重复问题，如果实际数据量小于理论数据量，则可以确定存在数据缺失问题。
在一个实施场景中，当上述步骤S13“判断实际数据量与理论数据量是否相等”的判断结果为是时，则可以执行下述步骤S15。
步骤S15：确定数据对账无误。
当判断到实际数据量与理论数据量相等时，说明数据对账无误。
上述方案中，当比较到设定时间内目的端从源端接收到的实际数据量，以及设定时间段内从源端接收到的理论数据量之间不相等时，可以确定目的端存在数据重复或数据缺失，由于无需针对业务表全表进行数据对账，只需比较在设定时间段内的数据量，故此，可以节省数据对账时间，从而提升数据对账效率。
此外，当源端采用Kafka消息队列时，由于无法基于Kafka集群内部的磁盘数据进行结构化查询语言(Structured Query Language，SQL)运算而获取理论数据量，然而，本方案采用每条数据的对账编号获取设定时间段内从源端接收到的理论数据量，从而只需统计目的端接收到的数据，无需对源端进行SQL运算，进而可以大大提高对于各类数据库的兼容性。
请参阅图3，图3是图1中步骤S12一实施例的流程示意图，具体而言，上述步骤S12可以包括：
步骤S121：统计各个分区的起始对账编号以及结尾对账编号。
请结合参阅图4，图4是图1中源端和目的端数据对账情况一实施例的框架示意图。图4所示的每个对账编号所对应的数据内容，例如：姓名、数学、语文等仅为示例，在其他实施场景中，还可以根据实际应用进行具体设置，例如：身高、体重、性别等等，本实施例在此不做具体限制。此外，图4所示的入库时间，为目的端接收到数据的时间，例如对于对账编号为0的数据，入库时间为2019-01-01 00:00:00，表示目的端接收到对账编号为0的数据的时间为2019-01-01 00:00:00，其他数据可以依次类推，本实施例在此不再一一举例。由于采用分区编号与偏移量编号结合的方式为对账数据编号，因此，通过对账编号可以明确每条数据所属的分区。例如，针对图4，统计分区0的起始对账编号为0，结尾对账编号为2，统计分区1的起始对账编号为4294967296，结尾对账编号为4294967297，分区2的起始对账编号为8589934592，结尾对账编号为8589934593。
步骤S122：通过起始对账编号以及结尾对账编号确定每个分区的理论数据量。
具体地，可以通过如下公式计算得到每个分区的理论数据量Ni：
Ni＝Nn-N0+1
其中，Nn为每个分区的结尾对账编号，N0为每个分区的起始对账编号。
请继续参阅图4，例如，针对分区0，通过分区0的起始对账编号0，结尾对账编号2，依据上式可以计算得到分区0的理论数据量N1＝2-0+1＝3，即分区0的理论数据量为3；针对分区1，通过分区1的起始对账编号4294967296，结尾对账编号4294967297，依据上式可以计算得到分区1的理论数据量N2＝4294967297-4294967296+1＝2；针对分区2，通过分区2的起始对账编号8589934592，结尾对账编号8589934593，依据上式可以计算得到分区2的理论数据量N3＝8589934593-8589934592+1＝2。
步骤S123：将各个分区的理论数据量进行求和，并将求和结果确定为设定时间段内从源端接收到的理论数据量。
具体地，可以通过如下公式计算得到设定时间段内从源端接收到的理论数据量Ns：
Figure BDA0002162307660000081
请继续结合参阅图4，例如已经计算得到分区0的理论数据量为3，分区1的理论数据量为2，分区2的理论数据量为2，因此，依据上式可计算得到设定时间段内从源端接收到的理论数据量Ns＝N0+N1+N2＝7，即图4所示的目的端在设定时间段内从源端接收到的理论数据量为7。
其中，在一个实施例中，如果实际数据量与理论数据量不相等，上述步骤S14“补充缺失的数据或删除重复的数据”具体可以包括：如果实际数据量小于理论数据量，通过各个分区的起始对账编号以及结尾对账编号确定缺失的数据，并重新采集缺失的数据。请继续结合参阅图4，图4所示的目的端在设定时间段内接收到的理论数据量为7，而实际数据量为6，实际数据量少于理论数据量1条数据，则确定图4所示的目的端缺失数据，进一步可以在每个分区查找是否存在不连续的对账编号，则可以确定缺失的数据为对账编号处于不连续的对账编号之间的数据，例如，图4中分区0的数据具有对账编号0、2，显然并不连续，因此可以确定缺失对账编号为1的数据，正好可以对应实际数据量少于理论数据量1条数据，从而可以重新采集对账编号为1的数据，以在重新采集得到对账编号为1的数据后，确保目的端在设定时间段内采集得到的数据的完整性。
其中，在另一个实施例中，如果实际数据量与理论数据量不相等，上述步骤S14“补充缺失的数据或删除重复的数据”具体可以包括：如果实际数据量大于理论数据量，删除重复的数据。请结合参阅图5，图5是图1中源端和目的端数据对账情况另一实施例的框架示意图。如图5所示，通过对每个分区的起始对账编号和结尾对账编号按照如上述步骤S123所示的公式进行计算，可以得到图5所示的目的端分区0中的理论数据量为2，分区1中的理论数据量为2，分区2中的理论数据量为2，从而可以确定目的端在设定时间段内从源端接收到的理论数据量为6，然而实际数据量为7，显然可以确定存在重复的数据，进一步可以依次在每个分区查找是否存在对账编号重复的数据，从而可以保留其中一条数据，删除其余数据，进而确保目的端的数据无重复。例如，在图5所示的分区0中查找到两个对账编号为1的数据，因此可以删除其中一条对账编号为1的数据，从而只保留一条对账编号为1的数据，进而可以确保分区0中的数据无重复，以此类推，可以确定分区1和分区2中的数据无重复，进而可以确保目的端在设定时间段内采集得到的数据无多余，提高了数据存储效率。
通过上述方案，由于每条数据都具有唯一标识的对账编号，从而不仅可以实现判断实际数据量存在异常的种类，如数据缺失或数据重复，而且还可以进一步精确定位异常数据的对账编号，如重复数据的对账编号，或者缺失数据的对账编号，进而使得数据对账的可靠性大幅提高。
其中，在又一个实施例中，当源端为Kafka消息队列时，上述步骤S11具体可以包括获取到从源端Kafka消息队列中传送的数据信息，并将数据信息存储到目的端数据库中。Kafka消息队列为本领域中的现有技术，本实施例在此不再赘述。
请参阅图6，图6是本申请数据对账方法另一实施例的流程示意图。具体而言，上述步骤S11之前，可以包括：
步骤S61：判断当前是否为首次数据对账。若是，则执行步骤S62，否则执行步骤S63。
首次数据对账是指在一个对账周期内首次进行数据对账，一个对账周期结束后，可以将该对账周期内的数据进行“封存”，以免本对账周期内的数据影响到下一个对账周期的数据对账工作。请结合参阅图8，图8是图1中源端和目的端数据对账情况又一实施例的框架示意图。图8所示的阴影区域为数据量，假设预先设置的对账周期为一天，例如，第一次对账时间为0点到6点，第二次对账时间为6点到12点，第三次对账时间为12点到18点，第四次对账时间为18点到24点，对应于图8中，则初始时间为0点、第一次对账时间为6点、第二次对账时间为12点、第三次对账时间为18点、第四次对账时间为24点。
步骤S62：将目的端将接收到第一条数据的时间作为设定时间段的起始时间，将接收到最后一条数据的时间确定为设定时间段的结束时间。
如果在本对账周期内尚未进行数据对账，则可以确定本次数据对账为首次数据对账。此时，可以将目的端接收到第一条数据的时间作为设定时间段的起始时间，将接收到最后一条数据的时间确定为设定时间段的结束时间。例如，请结合参阅图4，当判断本次数据对账为首次数据对账，则将目的端接收到的对账编号为0的数据的时间，即2019-01-0100:00:00，作为设定时间段的起始时间，将目的端接收到的对账编号为8589934593的数据的时间，即2019-01-01 00:00:06，作为设定时间段的结束时间。
步骤S63：将上一次对账的结束时间确定为设定时间段的起始时间，并将本次接收到最后一条数据的时间确定为设定时间段的结束时间。
请结合参阅图5，如果在本对账周期内已进行数据对账，并已对账完成对账编号为0、4294967296的数据。则将上一次对账的结束时间2019-02-01 00:00:01作为设定时间段的起始时间，并将本次对账接收到最后一条对账编号为8589934593的数据的时间，即2019-02-01 00:00:06作为设定时间段的结束时间。
上述方案，通过确定设定时间段的起始时间和结束时间，可以将设定时间段与上次对账的时间段区分，进而可以只对增量数据进行对账，提高了对账效率。
下面整体说明本申请数据对账方法，请参阅图7，图7是本申请数据对账方法另一实施例的流程示意图。具体而言，可以包括：
步骤S701：判断当前是否为首次数据对账。若是，则执行步骤S702，否则执行步骤S703。
首次数据对账是指在一个对账周期内首次进行数据对账，一个对账周期结束后，可以将该对账周期内的数据进行“封存”，以免本对账周期内的数据影响到下一个对账周期的数据对账工作。例如，预先设置的对账周期为一天，设定时间段为0点到7点，8点到15点，16点到23点，相应的第一次数据对账为0点到7点的数据，第二次数据对账为8点到15点的数据，第三次数据对账为16点到23点的数据。
步骤S702：将目的端将接收到第一条数据的时间作为设定时间段的起始时间，将接收到最后一条数据的时间确定为设定时间段的结束时间。
具体可参阅上述实施例中步骤S62。
步骤S703：将上一次对账的结束时间确定为设定时间段的起始时间，并将本次接收到最后一条数据的时间确定为设定时间段的结束时间。
具体可参阅上述实施例中步骤S63。
步骤S704：获取到目的端在设定时间段内从源端接收到的实际数据量。
具体可参阅上述实施例中步骤S11。
步骤S705：统计各个分区的起始对账编号以及结尾对账编号。
对账编号是通过将分区的编号以及偏移量分别转换为二进制并组成二进制对账编码后，将二进制对账编码转换为十进制后得到的，其中，偏移量的二进制码的字段位于分区的编号的二进制码后面。具体而言，可以参阅上述实施例中步骤S121。
步骤S706：通过起始对账编号以及结尾对账编号确定每个分区的理论数据量。
具体地，可以通过如下公式计算得到每个分区的理论数据量Ni：
Ni＝Nn-N0+1
其中，Nn为每个分区的结尾对账编号，N0为每个分区的起始对账编号。具体而言，可以参阅上述实施例中的步骤S122。
步骤S707：将各个分区的理论数据量进行求和，并将求和结果确定为设定时间段内从源端接收到的理论数据量。
具体地，可以通过如下公式计算得到设定时间段内从源端接收到的理论数据量Ns：
Figure BDA0002162307660000121
其中，k为数据对账所涉及到的分区数。具体而言，可以参阅上述实施例中的步骤S123。
步骤S708：判断实际数据量与理论数据量是否相等，若不相等，则执行步骤S709，若相等，则执行步骤S710。
具体可以参阅上述实施例中的步骤S13。
步骤S709：补充缺失的数据或删除重复的数据。
具体而言，如果实际数据量大于理论数据量，删除重复的数据；如果实际数据量小于理论数据量，通过各个分区的起始对账编号以及结尾对账编号确定缺失的数据，并重新采集缺失的数据。
步骤S710：确定数据对账无误。
如果实际数据量与理论数据量相等，则可以确定数据对账无误。
上述方案中，当比较到设定时间内目的端从源端接收到的实际数据量，以及设定时间段内从源端接收到的理论数据量之间不相等时，可以确定目的端存在数据重复或数据缺失，由于无需针对业务表全表进行数据对账，只需比较在设定时间段内的数据量，故此，可以节省数据对账时间，从而提升数据对账效率。
此外，当源端采用Kafka消息队列时，由于无法基于Kafka集群内部的磁盘数据进行结构化查询语言(Structured Query Language，SQL)运算而获取理论数据量，然而，本方案采用每条数据的对账编号获取设定时间段内从源端接收到的理论数据量，从而只需统计目的端接收到的数据，无需对源端进行SQL运算，进而可以大大提高对于各类数据库的兼容性。
请参阅图9，图9是本申请数据对账装置90一实施例的框架示意图。具体而言，数据对账装置90包括实际数据量获取模块91、理论数据量获取模块92、判断模块93以及响应模块94，实际数据量获取模块91用于获取到目的端在设定时间段内从源端接收到的实际数据量；理论数据量获取模块92用于利用每条数据的对账编号获取到设定时间段内从源端接收到的理论数据量；其中，对账编号包括数据的分区的编号以及偏移量，每个分区内的偏移量连续递增；判断模块93用于判断实际数据量与理论数据量是否相等；响应模块94用于在实际数据量与理论数据量不相等时，补充缺失的数据或删除重复的数据。
本实施例数据对账装置90可以集成于目的端，从而使目的端自身可以执行上述任一数据对账方法的实施例中的步骤。此外，本实施例中的数据对账装置90也可以独立于源端、目的端，本实施例在此不做具体限制。
上述方案中，当比较到设定时间内目的端从源端接收到的实际数据量，以及设定时间段内从源端接收到的理论数据量之间不相等时，可以确定目的端存在数据重复或数据缺失，由于无需针对业务表全表进行数据对账，只需比较在设定时间段内的数据量，故此，可以节省数据对账时间，从而提升数据对账效率。
此外，当源端采用Kafka消息队列时，由于无法基于Kafka集群内部的磁盘数据进行结构化查询语言(Structured Query Language，SQL)运算而获取理论数据量，然而，本方案采用每条数据的对账编号获取设定时间段内从源端接收到的理论数据量，从而只需统计目的端接收到的数据，无需对源端进行SQL运算，进而可以大大提高对于各类数据库的兼容性。
其中，在一些实施例中，理论数据量获取模块92包括编号统计模块，用于统计各个分区的起始对账编号以及结尾对账编号，理论数据量获取模块92还包括分区数据量确定模块，用于通过起始对账编号以及结尾对账编号确定每个分区的理论数据量，理论数据量获取模块92还包括求和模块，用于将各个分区的理论数据量进行求和，并将求和结果确定为设定时间段内从源端接收到的理论数据量。
其中，在一些实施例中，分区数据量确定模块通过如下公式计算得到每个分区的理论数据量Ni：
Ni＝Nn-N0+1
其中，Nn为每个分区的结尾对账编号，N0为每个分区的起始对账编号。
其中，在一些实施例中，判断模块93包括第一子判断模块，用于判断实际数据量是否大于理论数据量，响应模块94包括第一子响应模块，用于响应于实际数据量大于理论数据量，删除重复的数据；判断模块93还包括第二子判断模块，用于判断实际数据量是否小于理论数据量，响应模块94还包括第二子响应模块，用于响应于实际数据量小于理论数据量，通过各个分区的起始对账编号以及结尾对账编号确定缺失的数据，并重新采集缺失的数据。
其中，在一些实施例中，实际数据量获取模块91还用于获取到从源端Kafka消息队列中传送的数据信息，并将数据信息存储到目的端数据库中。
其中，在一些实施例中，数据对账装置90还包括设定时间段确定模块，用于判断当前是否为首次数据对账，如果当前为首次数据对账，将目的端将接收到第一条数据的时间作为设定时间段的起始时间，将接收到最后一条数据的时间确定为设定时间段的结束时间；如果当前不为首次数据对账，将上一次对账的结束时间确定为设定时间段的起始时间，并将本次接收到最后一条数据的时间确定为设定时间段的结束时间。
其中，在一些实施例中，对账编号是通过将分区的编号以及偏移量分别转换为二进制并组成二进制对账编码后，将二进制对账编码转换为十进制后得到的，其中，偏移量的二进制码的字段位于分区的编号的二进制码后面。
请参阅图10，图10为本申请数据对账装置100一实施例的框架示意图。数据对账装置100包括相互耦接的存储器101和处理器102，处理器102用于执行存储器101存储的程序指令，以实现上述任一实施例中的数据对账方法。
具体而言，处理器102用于控制其自身以及存储器101以实现上述任一实施例中的数据对账方法。处理器102还可以称为CPU(Central Processing Unit，中央处理单元)。处理器102可能是一种集成电路芯片，具有信号的处理能力。处理器102还可以是通用处理器、数字信号处理器(Digital Signal Processor,DSP)、专用集成电路(ApplicationSpecific Integrated Circuit,ASIC)、现场可编程门阵列(Field-Programmable GateArray,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。另外，处理器102可以由多个集成电路芯片共同实现。
本实施例中，处理器102用于获取到目的端在设定时间段内从源端接收到的实际数据量；处理器102还用于利用每条数据的对账编号获取到设定时间段内从源端接收到的理论数据量；其中，对账编号包括数据的分区的编号以及偏移量，每个分区内的偏移量连续递增；处理器102还用于判断实际数据量与理论数据量是否相等；处理器102还用于如果实际数据量与理论数据量不相等，补充缺失的数据或删除重复的数据。
本实施例数据对账装置100可以集成于目的端，从而使目的端自身可以执行上述任一数据对账方法的实施例中的步骤。此外，本实施例中的数据对账装置100也可以独立于源端、目的端，本实施例在此不做具体限制。
上述方案中，当比较到设定时间内目的端从源端接收到的实际数据量，以及设定时间段内从源端接收到的理论数据量之间不相等时，可以确定目的端存在数据重复或数据缺失，由于无需针对业务表全表进行数据对账，只需比较在设定时间段内的数据量，故此，可以节省数据对账时间，从而提升数据对账效率。
此外，当源端采用Kafka消息队列时，由于无法基于Kafka集群内部的磁盘数据进行结构化查询语言(Structured Query Language，SQL)运算而获取理论数据量，然而，本方案采用每条数据的对账编号获取设定时间段内从源端接收到的理论数据量，从而只需统计目的端接收到的数据，无需对源端进行SQL运算，进而可以大大提高对于各类数据库的兼容性。
其中，在一些实施例中，处理器102还用于统计各个分区的起始对账编号以及结尾对账编号；处理器102还用于通过起始对账编号以及结尾对账编号确定每个分区的理论数据量；处理器102还用于将各个分区的理论数据量进行求和，并将求和结果确定为设定时间段内从源端接收到的理论数据量。
其中，在一些实施例中，处理器102还用于通过如下公式计算得到每个分区的理论数据量Ni：
Ni＝Nn-N0+1
其中，Nn为每个分区的结尾对账编号，N0为每个分区的起始对账编号。
其中，在一些实施例中，处理器102还用于判断如果实际数据量大于理论数据量，删除重复的数据；处理器102还用于判断如果实际数据量小于理论数据量，通过各个分区的起始对账编号以及结尾对账编号确定缺失的数据，并重新采集缺失的数据。
其中，在一些实施例中，处理器102还用于获取到从源端Kafka消息队列中传送的数据信息，并将数据信息存储到目的端数据库中。
其中，在一些实施例中，处理器102还用于判断当前是否为首次数据对账；处理器102还用于判断如果当前为首次数据对账，将目的端将接收到第一条数据的时间作为设定时间段的起始时间，将接收到最后一条数据的时间确定为设定时间段的结束时间；处理器102还用于判断如果当前不为首次数据对账，将上一次对账的结束时间确定为设定时间段的起始时间，并将本次接收到最后一条数据的时间确定为设定时间段的结束时间。
其中，在一些实施例中，对账编号是通过将分区的编号以及偏移量分别转换为二进制并组成二进制对账编码后，将二进制对账编码转换为十进制后得到的，其中，偏移量的二进制码的字段位于分区的编号的二进制码后面。
请参阅图11，图11为本申请存储装置110一实施例的框架示意图。存储装置110存储有能够被处理器运行的程序指令111，程序指令111用于实现上述任一实施例中的数据对账方法。
上述方案中，当比较到设定时间内目的端从源端接收到的实际数据量，以及设定时间段内从源端接收到的理论数据量之间不相等时，可以确定目的端存在数据重复或数据缺失，由于无需针对业务表全表进行数据对账，只需比较在设定时间段内的数据量，故此，可以节省数据对账时间，从而提升数据对账效率。
此外，当源端采用Kafka消息队列时，由于无法基于Kafka集群内部的磁盘数据进行结构化查询语言(Structured Query Language，SQL)运算而获取理论数据量，然而，本方案采用每条数据的对账编号获取设定时间段内从源端接收到的理论数据量，从而只需统计目的端接收到的数据，无需对源端进行SQL运算，进而可以大大提高对于各类数据库的兼容性。
在本申请所提供的几个实施例中，应该理解到，所揭露的方法和装置，可以通过其它的方式实现。例如，以上所描述的装置实施方式仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性、机械或其它的形式。
作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施方式方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施方式方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

Claims (9)

1.一种数据对账方法，其特征在于，包括：
获取到目的端在设定时间段内从源端接收到的实际数据量；
在所述目的端，利用每条数据的对账编号获取到所述设定时间段内从源端接收到的理论数据量；其中，所述每条数据为已经从所述源端接收到的数据，所述对账编号包括所述数据在所述源端的分区的编号以及偏移量，每个所述分区内的偏移量连续递增，且所述对账编号是唯一标识每条数据的编号；
判断所述实际数据量与所述理论数据量是否相等；
如果所述实际数据量与所述理论数据量不相等，补充缺失的数据或删除重复的数据；其中，所述缺失的数据为所述分区中所述对账编号处于不连续的对账编号之间的数据；所述重复的数据为所述分区中所述对账编号重复的数据；
其中，所述利用每条数据的对账编号获取到所述设定时间段内从源端接收到的理论数据量，包括：
统计各个分区的起始对账编号以及结尾对账编号；
通过所述起始对账编号以及结尾对账编号确定每个所述分区的理论数据量；
将各个所述分区的理论数据量进行求和，并将求和结果确定为所述设定时间段内从源端接收到的理论数据量。
2.根据权利要求1所述的数据对账方法，其特征在于，所述通过所述起始对账编号以及结尾对账编号确定每个所述分区的理论数据量的步骤包括：
通过如下公式计算得到每个所述分区的理论数据量Ni：
Ni＝Nn-N0+1；
其中，Nn为每个所述分区的结尾对账编号，N0为每个所述分区的起始对账编号。
3.根据权利要求1或2所述的数据对账方法，其特征在于，所述如果所述实际数据量与所述理论数据量不相等，补充缺失的数据或删除重复的数据的步骤具体包括：
如果所述实际数据量大于所述理论数据量，删除重复的数据；如果所述实际数据量小于所述理论数据量，通过所述各个分区的起始对账编号以及结尾对账编号确定缺失的数据，并重新采集所述缺失的数据。
4.根据权利要求1所述的数据对账方法，其特征在于，所述获取到目的端在设定时间段内从源端接收到的实际数据量的步骤包括：
获取到从源端Kafka消息队列中传送的数据信息，并将所述数据信息存储到目的端数据库中。
5.根据权利要求1或4所述的数据对账方法，其特征在于，所述获取到目的端在设定时间段内从源端接收到的实际数据量的步骤之前，包括：
判断当前是否为首次数据对账；
如果当前为首次数据对账，将所述目的端将接收到第一条数据的时间作为所述设定时间段的起始时间，将接收到最后一条数据的时间确定为所述设定时间段的结束时间；
如果当前不为首次数据对账，将上一次对账的结束时间确定为所述设定时间段的起始时间，并将本次接收到最后一条数据的时间确定为所述设定时间段的结束时间。
6.根据权利要求1或4所述的数据对账方法，其特征在于，所述对账编号是通过将所述分区的编号以及所述偏移量分别转换为二进制并组成二进制对账编码后，将所述二进制对账编码转换为十进制后得到的，其中，所述偏移量的二进制码的字段位于所述分区的编号的二进制码后面。
7.一种数据对账装置，其特征在于，所述数据对账装置包括实际数据量获取模块、理论数据量获取模块、判断模块以及响应模块；
所述实际数据量获取模块用于获取到目的端在设定时间段内从源端接收到的实际数据量；
所述理论数据量获取模块用于在所述目的端，利用每条数据的对账编号获取到所述设定时间段内从源端接收到的理论数据量；其中，所述每条数据为已经从所述源端接收到的数据，所述对账编号包括所述数据在所述源端的分区的编号以及偏移量，每个所述分区内的偏移量连续递增，且所述对账编号是唯一标识每条数据的编号；
所述判断模块用于判断所述实际数据量与所述理论数据量是否相等；
所述响应模块用于在所述实际数据量与所述理论数据量不相等时，补充缺失的数据或删除重复的数据；且所述缺失的数据为所述分区中所述对账编号处于不连续的对账编号之间的数据；所述重复的数据为所述分区中所述对账编号重复的数据；
其中，理论数据量获取模块包括编号统计模块，用于统计各个分区的起始对账编号以及结尾对账编号，理论数据量获取模块包括分区数据量确定模块，用于通过起始对账编号以及结尾对账编号确定每个分区的理论数据量，理论数据量获取模块还包括求和模块，用于将各个分区的理论数据量进行求和，并将求和结果确定为设定时间段内从源端接收到的理论数据量。
8.一种数据对账装置，其特征在于，包括相互耦接的存储器和处理器；
所述处理器用于执行所述存储器存储的程序指令，以实现权利要求1至6任一项所述的方法。
9.一种存储装置，其特征在于，存储有能够被处理器运行的程序指令，所述程序指令用于实现权利要求1至6任一项所述的方法。
CN201910736400.1A 2019-08-09 2019-08-09 数据对账方法及相关装置 Active CN110543472B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910736400.1A CN110543472B (zh) 2019-08-09 2019-08-09 数据对账方法及相关装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910736400.1A CN110543472B (zh) 2019-08-09 2019-08-09 数据对账方法及相关装置

Publications (2)

Publication Number Publication Date
CN110543472A CN110543472A (zh) 2019-12-06
CN110543472B true CN110543472B (zh) 2022-08-09

Family

ID=68710199

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910736400.1A Active CN110543472B (zh) 2019-08-09 2019-08-09 数据对账方法及相关装置

Country Status (1)

Country Link
CN (1) CN110543472B (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111210299B (zh) * 2019-12-25 2024-04-19 深圳猛犸电动科技有限公司 一种单号生成及管理方法及装置
CN111177221B (zh) * 2019-12-26 2021-05-04 苏州亿歌网络科技有限公司 一种统计数据采集方法、装置及设备
CN113656511B (zh) * 2021-10-20 2022-02-18 天津南大通用数据技术股份有限公司 一种基于源库不停机的异构数据库增量同步方法及系统

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TR201112086A2 (tr) * 2011-12-06 2012-05-21 Krea İçeri̇k Hi̇zmetleri̇ Ve Prodüksi̇yon Anoni̇m Şi̇rketi̇ Kaynak veritabanından hedef veritabanına hızlı veri aktarıma yöntemi ve sistemi.
EP3001329A1 (en) * 2014-09-25 2016-03-30 Fujitsu Limited Method, controller, program and data storage system for performing reconciliation processing
CN104462568B (zh) * 2014-12-26 2018-07-31 山东中创软件商用中间件股份有限公司 一种数据对账方法、装置和系统
CN107122355B (zh) * 2016-02-24 2021-07-06 阿里巴巴集团控股有限公司 数据迁移系统和方法
CN107315814B (zh) * 2017-06-29 2021-03-02 苏州浪潮智能科技有限公司 一种kdb数据库数据迁移后数据一致性验证方法及系统
CN109587192B (zh) * 2017-09-28 2021-09-07 北京国双科技有限公司 数据同步方法及装置
CN109388677B (zh) * 2018-08-23 2022-10-11 顺丰科技有限公司 集群之间数据同步方法、装置、设备及其存储介质

Also Published As

Publication number Publication date
CN110543472A (zh) 2019-12-06

Similar Documents

Publication Publication Date Title
CN110543472B (zh) 数据对账方法及相关装置
CN111344706B (zh) 管理区块链上的交易的方法和系统
WO2018149271A1 (zh) 数据查询方法、装置及计算设备
CN110599169B (zh) 数据处理方法、装置、终端及介质
US10372504B2 (en) Global usage tracking and quota enforcement in a distributed computing system
CN108874803A (zh) 数据存储方法、装置及存储介质
CN106599104A (zh) 一种基于redis集群的海量数据关联方法
CN110334094B (zh) 一种基于倒排索引的数据查询方法、系统、装置及设备
CN109146677B (zh) 并行构建区块链视图的方法、计算机系统和可读存储介质
WO2021051782A1 (zh) 区块链的共识方法、装置及设备
CN111061758B (zh) 数据存储方法、装置及存储介质
CN112612827A (zh) 数据库分页查询方法、装置、计算机设备及存储介质
CN113420026A (zh) 数据库表结构变更方法、装置、设备及存储介质
CN111064776B (zh) 区块链中区块的生成方法、记账节点及存储介质
CN111522811A (zh) 数据库的处理方法及装置、存储介质、终端
WO2022179122A1 (zh) 基于大数据的数据存储方法、装置、电子设备及存储介质
Subramanyam et al. Idempotent distributed counters using a forgetful bloom filter
CN108418746B (zh) 一种邮件同步方法、装置与计算机可读存储介质
US10606829B1 (en) Methods and systems for identifying data inconsistencies between electronic record systems using data partitioning
CN111857981A (zh) 一种数据处理方法以及装置
CN116303789A (zh) 多分片多副本数据库并行同步方法、装置及可读介质
CN114297318A (zh) 数据处理方法及装置
CN109063201B (zh) 一种基于混合存储方案的impala在线交互式查询方法
CN115210694A (zh) 数据传输方法及装置
CN115221245B (zh) 智能数据采集同步方法、系统及设备

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant