CN116501715A - 一种多表全量数据的实时关联更新方法及装置 - Google Patents
一种多表全量数据的实时关联更新方法及装置 Download PDFInfo
- Publication number
- CN116501715A CN116501715A CN202310478152.1A CN202310478152A CN116501715A CN 116501715 A CN116501715 A CN 116501715A CN 202310478152 A CN202310478152 A CN 202310478152A CN 116501715 A CN116501715 A CN 116501715A
- Authority
- CN
- China
- Prior art keywords
- data
- full
- change operation
- change
- operation record
- 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.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 44
- 230000008859 change Effects 0.000 claims abstract description 355
- 238000013507 mapping Methods 0.000 claims abstract description 115
- 238000004364 calculation method Methods 0.000 claims abstract description 47
- 238000012545 processing Methods 0.000 claims abstract description 20
- 238000012544 monitoring process Methods 0.000 claims abstract description 15
- 238000005096 rolling process Methods 0.000 claims description 22
- 238000012423 maintenance Methods 0.000 claims description 21
- 238000004590 computer program Methods 0.000 claims description 17
- 238000010586 diagram Methods 0.000 description 7
- 238000000605 extraction Methods 0.000 description 5
- 238000004891 communication Methods 0.000 description 4
- 230000008569 process Effects 0.000 description 4
- 230000004044 response Effects 0.000 description 4
- 238000013075 data extraction Methods 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 239000002699 waste material Substances 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000013481 data capture Methods 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 238000007781 pre-processing Methods 0.000 description 1
- 238000012163 sequencing technique Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
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
-
- 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/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
-
- 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/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/284—Relational databases
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Memory System Of A Hierarchy Structure (AREA)
Abstract
本申请涉及数据处理领域，提供了一种多表全量数据的实时关联更新方法及装置。该方法包括：读取源数据库中与业务需求信息关联的多个全量数据表并写入缓存数据库中；对多个全量数据表进行实时关联计算，得到目标宽表和映射关系表并存储至缓存数据库中，将目标宽表的副本推送至目标数据库；实时监听并获取源数据库的的数据变更操作记录和变更时间戳；根据初始化时间戳、数据变更操作记录和变更时间戳，对缓存数据库中的数据表进行实时关联更新，得到更新结果并推送至更新消息队列中。本申请无需多次读取业务数据库，节约计算资源，可有效缓解高并发的计算量导致的超时问题，无需占用过多的内存资源，且应用范围较广。
Description
技术领域
本申请涉及数据处理领域，尤其涉及一种多表全量数据的实时关联更新方法及装置。
背景技术
在现有技术中，针对多表全量数据进行实时关联计算的技术方案主要有以下三种方案：第一，在关系型数据库执行实时关联计算；第二，基于Flink(一个批处理和流处理结合的统一计算框架，其核心是一个提供了数据分发以及并行化计算的流数据处理引擎)的常规关联操作实现实时关联计算；第三，基于Flink的时间窗口关联操作实现实时关联计算。
然而，上述的第一种方案需要对关系型数据库进行多次的读取查询，且每次读取查询都需要进行一次计算，导致计算资源的浪费，此外，该方案在面对数据量持续增加的场景，因无法承担高并发的计算量而容易导致计算超时的问题。上述第二种方案则需要将全量数据均保存在内存中，随着时间的增长，需要保存的历史数据也随之无止境地增长，导致很不合理的内存磁盘资源占用，而且单个元素的匹配效率也会越来越低。上述第三种方案则需要对输入的数据分配一个时间界限，但是在很多场景下，设定时间界限是不合适的，因为某些数据始终存在变更的可能性，需要对这些数据进行持续的监听，以免漏掉重要信息。
可见，现有的实时关联计算方案需要对业务数据库进行多次读取查询，对业务数据库的负担较大，且需要浪费大量的计算资源，同时也无法承担高并发的计算量而容易导致超时；需要占用过多的内存资源，资源利用率较低，且无法适用于对于需要持续监听的数据的实时关联更新的场景，应用范围较局限。
发明内容
有鉴于此，本申请实施例提供了一种多表全量数据的实时关联更新方法及装置，以解决现有技术需要多次读取业务数据库，对业务数据库的负担较大且需要浪费大量的计算资源，同时无法承担高并发的计算量而容易导致超时，还需要占用过多的内存资源，资源利用率较低，且应用范围较局限的问题。
本申请实施例的第一方面，提供了一种多表全量数据的实时关联更新方法，包括：
获取业务需求信息；
读取源数据库中与业务需求信息具有关联逻辑关系的多个全量数据表并将其写入缓存数据库中，记录每一个全量数据表中的每一条数据的初始化时间戳，多个全量数据表包括一个全量数据主表和至少一个全量数据维表，全量数据主表与全量数据维表具有关联关系；
对多个全量数据表进行实时关联计算，得到目标宽表以及全量数据主表与每一个全量数据维表之间的映射关系表，并将目标宽表和映射关系表均存储至缓存数据库中，将目标宽表的副本推送至目标数据库；
实时监听源数据库的多个全量数据表的数据变更操作，以获取源数据库的数据变更操作记录和变更时间戳；
根据初始化时间戳、数据变更操作记录和变更时间戳，对缓存数据库中的目标宽表，以及全量数据主表、全量数据维表、映射关系表中的至少一个进行实时关联更新，得到更新结果，并将更新结果推送至更新消息队列中，以使目标数据库实时读取更新消息队列中的更新结果，并根据更新结果同步更新目标宽表的副本。
本申请实施例的第二方面，提供了一种多表全量数据的实时关联更新装置，包括：
获取模块，被配置为获取业务需求信息；
读取模块，被配置为读取源数据库中与业务需求信息具有关联逻辑关系的多个全量数据表并将其写入缓存数据库中，记录每一个全量数据表中的每一条数据的初始化时间戳，多个全量数据表包括一个全量数据主表和至少一个全量数据维表，全量数据主表与全量数据维表具有关联关系；
计算模块，被配置为对多个全量数据表进行实时关联计算，得到目标宽表以及全量数据主表与每一个全量数据维表之间的映射关系表，并将目标宽表和映射关系表均存储至缓存数据库中，将目标宽表的副本推送至目标数据库；
监听模块，被配置为实时监听源数据库的多个全量数据表的数据变更操作，以获取源数据库的数据变更操作记录和变更时间戳；
更新模块，被配置为根据初始化时间戳、数据变更操作记录和变更时间戳，对缓存数据库中的目标宽表，以及全量数据主表、全量数据维表、映射关系表中的至少一个进行实时关联更新，得到更新结果，并将更新结果推送至更新消息队列中，以使目标数据库实时读取更新消息队列中的更新结果，并根据更新结果同步更新目标宽表的副本。
本申请实施例的第三方面，提供了一种电子设备，包括存储器、处理器以及存储在存储器中并且可在处理器上运行的计算机程序，该处理器执行计算机程序时实现上述方法的步骤。
本申请实施例的第四方面，提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序被处理器执行时实现上述方法的步骤。
本申请实施例与现有技术相比，其有益效果至少包括：通过在获取到业务需求信息时，读取源数据库中与业务需求信息具有关联逻辑关系的多个全量数据表并将其写入缓存数据库中，记录每一个全量数据表中的每一条数据的初始化时间戳；对多个全量数据表进行实时关联计算，并将得到的目标宽表和全量数据主表与每一个全量数据维表之间的映射关系表存储至缓存数据库中，同时将目标宽表的副本推送至目标数据库，以便于后续的数据查询操作；通过采用缓存与消息队列相结合的方式存储实时关联计算的所需数据和目标结果数据(用于表征目标宽表的数据现状的数据)，可将实时关联更新计算所需数据与查询所需数据隔离，避免资源冲突，且此种方式对并发查询友好，可有效缓解因高并发的计算量导致的超时问题，而且无需占用过多的内存资源，资源利用率较高；进一步，通过实时监听源数据库的多个全量数据表的数据变更操作，获取源数据库的数据变更操作记录和变更时间戳，可避免多次读取源数据库(即业务数据库)中的数据，不会增加业务数据库的负担(如频繁响应所造成的响应负担等)；之后，根据初始化时间戳、数据变更操作记录和变更时间戳，对缓存数据库中的目标宽表，以及全量数据主表、全量数据维表、映射关系表中的至少一个进行实时关联更新，可实现对源数据库的全量数据表的时序化处理，尽量避免因乱序造成更新错误的问题，同时还可将每个数据变更所涉及的计算量控制在最小范围，不仅可节约计算资源，还可提高实时关联更新计算的效率。此外，本申请实施例提供的技术方案无需为每个输入的数据流(全量数据表)设置一个有效时间范围，可适用于对于需要持续监听的数据的实时关联更新的场景，应用范围较广。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。
图1是本申请实施例的一种应用场景的场景示意图；
图2是本申请实施例提供的一种多表全量数据的实时关联更新方法的流程示意图；
图3是本申请的一个实施例提供的针对全量数据主表的变更的实时关联更新流程示意图；
图4是本申请的一个实施例提供的针对全量数据维表的变更的实时关联更新流程示意图；
图5是本申请实施例提供的一种多表全量数据的实时关联更新装置的结构示意图；
图6是本申请实施例提供的一种电子设备的结构示意图。
具体实施方式
以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。
下面将结合附图详细说明根据本申请实施例的一种多表全量数据的实时关联更新方法和装置。
图1是本申请实施例的一种应用场景的场景示意图。该应用场景可以包括源数据库101、数据处理器102、缓存数据库103、目标数据库104以及网络105。
源数据库101，也可称为业务数据库，主要用于存储各种全量数据表。全量数据表包括存量数据和增量数据。通常一项指标对应一个设置全量数据表。例如，用于存储所有车型的车型数据表为一个全量数据表；又例如，用于存储各个车型所搭载的零件的零件数据表为一个全量数据表。
数据处理器102，可以是一个流数据处理引擎(如Flink的MySQL-CDC(Change DateCapture，变更数据捕获)引擎)，主要用于实现从源数据库的数据变更到目标数据库104中的目标宽表的副本的同步更新。
缓存数据库103，可以是Redis缓存数据库。Redis是一个开源的使用ANSIC语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。
目标数据库104，主要是用于存储经实时关联更新处理后的目标宽表的副本，并响应用户针对目标宽表的相关数据的各种查询操作。
网络105可以是采用同轴电缆、双绞线和光纤连接的有线网络，也可以是无需布线就能实现各种通信设备互联的无线网络，例如，蓝牙(Bluetooth)、近场通信(Near FieldCommunication，NFC)、红外(Infrared)等，本申请实施例对此不作限制。
数据处理器102可通过网络105与源数据库101、缓存数据库103、目标数据库104建立通信连接，以接收或发送信息。
在本申请实施例中，数据处理器102在获取到业务需求信息时，读取源数据库102中与该业务需求信息具有关联逻辑关系的多个全量数据表，并将读取到的多个全量数据表写入缓存数据库103中，同时记录每一个全量数据表的每一条数据的初始化时间戳；然后，在源数据库102中执行一次多个全量数据表的实时关联计算，并将得到目标宽表以及全量数据主表与每一个全量数据维表之间的映射关系表存储至缓存数据库103中，与此同时还会将该目标宽表的副本推送至目标数据库104，目标数据库104存储该目标宽表的副本，以便于后续的数据查询操作；通过采用缓存与消息队列相结合的方式存储实时关联计算中的数据和目标结果数据(用于表征目标宽表的数据现状的数据)，可将实时关联更新计算所需数据与查询所需数据隔离，避免资源冲突，且此种方式对并发查询友好，可有效缓解因高并发的计算量导致的超时问题，而且无需占用过多的内存资源，资源利用率较高；进一步，源数据库102实时监听源数据库102中的各个全量数据表的数据表更操作，获取源数据库的数据变更操作记录和变更时间戳，可避免多次读取源数据库(即业务数据库)中的数据，不会增加业务数据库的负担(如频繁响应所造成的响应负担等)；然后，根据记录的每一个全量数据表的每一条数据的初始化时间戳，以及监听到的源数据库的数据变更操作记录和变更时间戳，对缓存数据库103中的目标宽表，以及全量数据主表、全量数据维表、映射关系表中的至少一个进行实时关联更新，得到更新结果，可实现对源数据库的全量数据表的时序化处理，尽量避免因乱序造成更新错误的问题，同时还可将每个数据变更所涉及的计算量控制在最小范围，不仅可节约计算资源，还可提高实时关联更新计算的效率；最后，将更新结果推送至更新消息队列(如Kafka消息队列)中，使得目标数据库104可以通过实时读取该更新消息队列中的更新结果，并根据该更新结果同步更新目标宽表的副本。
需要说明的是，源数据库101、数据处理器102、缓存数据库103、目标数据库104以及网络105的具体类型、数量和组合可以根据应用场景的实际需求进行调整，本申请实施例对此不作限制。例如，源数据库的数量可以是一个或者多个，即多个全量数据表可能是来自于同一个源数据库中的多个表格，也可能是分别来自不同源数据库的多个表格。
图2是本申请实施例提供的一种多表全量数据的实时关联更新方法的流程示意图。图2的多表全量数据的实时关联更新方法可以由图1的数据处理器102执行。如图2所示，该多表全量数据的实时关联更新方法包括：
步骤S201，获取业务需求信息。
业务需求信息，通常是指针对某项业务指标进行业务数据统计的相关需求。例如，针对某个品牌的车辆的零件版本更新业务指标需要对该品牌的所有车辆中各种零件的当前版本信息进行统计的需求。
作为一示例，当用户需要查询某个品牌的所有车辆中各种零件的当前版本信息时，可以通过终端设备(如手机、电脑等)向目标数据库104发起查询请求；目标数据库104响应该查询请求，并将该查询请求中携带的业务需求信息转发给数据处理器102，此时，数据处理器102即可获取到业务需求信息。
步骤S202，读取源数据库中与业务需求信息具有关联逻辑关系的多个全量数据表并将其写入缓存数据库中，记录每一个全量数据表中的每一条数据的初始化时间戳，多个全量数据表包括一个全量数据主表和至少一个全量数据维表，全量数据主表与全量数据维表具有关联关系。
与业务需求信息具有关联逻辑关系，可以理解为全量数据表中存在与业务需求信息中所涉及到的统计对象相关联的表格字段。
例如，业务需求信息为需要统计某个品牌的所有车辆中各种零件的当前版本信息，其涉及的统计对象包括车辆品牌、车辆零件。若某全量数据表中包含有车辆品牌、车辆零件的表格字段，则可认为该全量数据与与该业务需求信息具有关联逻辑关系。
作为一示例，假设业务需求信息为需要统计某个品牌的所有车辆中各种零件的当前版本信息；源数据库中存储有业务库表X、业务库表Y、业务库表Z，其中，业务库表X中存储有所有车型(如共有x个车型)及每个车型对应的车辆品牌的数据；业务库表Y中存储有各个车型对应搭载的零件的数据；业务库表Z存储有每台实际真车及其实际搭载的零件的数据，那么在此示例中，业务库表X、业务库表Y、业务库表Z均包含有与该业务需求信息所涉及的统计对象相关的字段，由此可确定业务库表X、业务库表Y、业务库表Z与该业务需求信息均具有关联逻辑关系。
以业务库表X为例，假设业务库表X中存储了x个车型及其对应的车辆品牌数据，如下表1所示。
表1
| 车辆-车型 | 车辆-品牌 |
| type1 | BrandA |
| type2 | BrandA |
| type3 | BrandA |
| type4 | BrandB |
| ... | ... |
如表1所示，业务库表X中包含有x个车型及其对应的车辆品牌，表1中的每一行每一列对应一条数据，例如，第1行第1列对应的数据为一条数据，第1行第2列对应的数据为另一条数据，在将表X写入缓存数据库时，记录每一条数据的存储初始时间(即存储到缓存数据库中的时间点)，即初始化时间戳。
在本申请实施例中，可将同时包含有车辆和零件实体信息的事实表Z(即业务库表Z)作为全量数据主表，记为table_main，将只含有车型及其对应的车辆品牌信息的业务库表X，只含有各个车型对应搭载的零件信息的业务库表Y作为全量数据维表，分别记为table_dim[x](对应业务库表X)、table_dim[y](对应业务库表Y)。全量数据主表与全量数据维表之间具有关联关系，具体是指全量数据主表与全量数据维表之间具有相关的字段。例如，业务库表Z与业务库表X均包含有“车辆-车型”字段，则可通过“车辆-车型”字段将业务库表Z与业务库表X关联起来。又例如，业务库表Z与业务库表Y均包含有“零件-零件码”字段，则可通过“零件-零件码”字段将业务库表Z与业务库表Y关联起来。
在本申请实施例中，可将业务库表X、业务库表Y、业务库表Z在T0时刻的快照数据存储至缓存数据库中，后续在执行实时关联更新计算时，可以直接从缓存数据库中读取计算所需的数据，从而尽可能减少对源数据库的读取次数，避免增加源数据库的负担。
步骤S203，对多个全量数据表进行实时关联计算，得到目标宽表以及全量数据主表与每一个全量数据维表之间的映射关系表，并将目标宽表和映射关系表均存储至缓存数据库中，将目标宽表的副本推送至目标数据库。
作为一示例，在将业务库表Z、业务库表X和业务库表Y写入缓存数据库时，在源数据库中执行一次业务库表Z、业务库表X和业务库表Y的实时关联更新计算，将得到的T0时刻(即存储初始时间)的目标宽表(车辆-零件详情宽表)以及全量数据主表与每一个全量数据维表之间的映射关系表存储至源数据库中，并将目标宽表的副本推送至目标数据库中存储，以便于用户后续的查询操作。在此示例中，目标宽表是指包含有业务库表Z、业务库表X和业务库表Y的所有信息的表格。映射关系表包括业务库表Z与业务库表X的映射关系表，记为table_relation[x]，业务库表Z与业务库表Y的映射关系表，记为table_relation[y]。目标宽表的副本可以理解为是目标宽表的复制品，该复制品的内容与目标宽表完全一致。
本申请实施例提供的技术方案，通过采用Redis缓存与Kafka消息队列相结合的方式存储实时关联计算的所需数据和目标结果数据(用于表征目标宽表的数据现状的消息)，可将实时关联计算所需数据与查询所需数据进行隔离，从而避免资源冲突，且此种方式对并发查询友好，可有效缓解因高并发的计算量导致的超时问题，而且无需占用过多的内存资源，资源利用率较高。
步骤S204，实时监听源数据库的多个全量数据表的数据变更操作，以获取源数据库的数据变更操作记录和变更时间戳。
数据变更操作，主要包括对全量数据表中的数据的增加(写入)、删除和更改(更新)操作。
变更时间戳，是指执行对对全量数据表中的数据的增加(写入)、删除和更改(更新)操作的时间点。
在一实施例中，假设源数据库为MySQL(关系型数据库)，那么数据处理器可以通过监听源数据库的多个全量数据表的binlog日志来获取该源数据库的数据变更操作记录和变更时间戳。binlog是一个二进制格式的文件，用于记录用户对数据库更新的SQL语句信息，例如更改数据库表和更改内容的SQL语句都会记录到binlog里，但是对库表等内容的查询不会记录。
作为一示例，从T0时刻起，数据处理器102对源数据库中的多个全量数据表的数据变更操作进行实时监听，即监听MySQL的binlog日志，以获取针对每个全量数据表(即业务库表X、业务库表Y和业务库表Z)的数据写入、删除及更新操作的相关内容(即数据变更操作记录)及操作的时间戳(即变更时间戳)。
通过监听源数据库的binlog日志，可以在不直接查询MySQL表的情况下，跟踪MySQL表的数据变更操作，可以避免多次读取源数据库数据，对源数据库无负担。
步骤S205，根据初始化时间戳、数据变更操作记录和变更时间戳，对缓存数据库中的目标宽表，以及全量数据主表、全量数据维表、映射关系表中的至少一个进行实时关联更新，得到更新结果，并将更新结果推送至更新消息队列中，以使目标数据库实时读取更新消息队列中的更新结果，并根据更新结果同步更新目标宽表的副本。
本申请实施例提供的技术方案，通过采用缓存与消息队列相结合的方式存储实时关联计算的所需数据和目标结果数据(用于表征目标宽表的数据现状的数据)，可将实时关联更新计算所需数据与查询所需数据隔离，避免资源冲突，且此种方式对并发查询友好，可有效缓解因高并发的计算量导致的超时问题，而且无需占用过多的内存资源，资源利用率较高；进一步，通过监听源数据库的binlog日志的方式获取源数据库的数据变更操作记录和变更时间戳，可以避免多次读取源数据库数据，对源数据库无负担；根据初始化时间戳、数据变更操作记录和变更时间戳，对缓存数据库中的目标宽表，以及全量数据主表、全量数据维表、映射关系表中的至少一个进行实时关联更新可实现对源数据库的全量数据表的时序化处理，尽量避免因乱序造成更新错误的问题，同时还可将每个数据变更所涉及的计算量控制在最小范围，不仅可节约计算资源，还可提高实时关联更新计算的效率。此外，本申请实施例提供的技术方案无需为每个输入的数据流(全量数据表)设置一个有效时间范围，可适用于对于需要持续监听的数据的实时关联更新的场景，应用范围较广。
在一些实施例中，上述步骤S203，具体包括如下步骤：
确定全量数据主表与全量数据维表的关联字段；
获取与业务需求信息对应的待填充宽表；
将待填充宽表与全量数据主表进行对比，确定待填充宽表中的第一待填充位置和第二待填充位置；
从全量数据维表中提取出与关联字段对应的维度数据；
将维度数据填充至待填充宽表中的第一待填充位置，将全量数据主表中的主表数据填充至待填充宽表中的第二待填充位置，得到目标宽表；
提取全量数据主表中的唯一标识字段，根据关联字段和唯一标识字段之间的映射关系，获得全量数据主表与每一个全量数据维表之间的映射关系表。
作为一示例，假设业务库表Y中存储了x个车型所对应的搭载零件数据，如下表2所示。
表2
| 零件-零件码 | 零件-分类 |
| Code1 | CategoryA |
| Code2 | CategoryB |
| Code3 | CategoryA |
| Code4 | CategoryC |
| ... | ... |
假设业务库表Z中存储了每台实际真车及其实际搭载的零件，其中涉及m台真车，假设每台车实际搭载n个零件，那么业务库表Z中存储的数据共z＝m*n条，如下表3所示。
表3
| 事实ID | 车辆ID | 零件ID | 车辆-车型 | 零件-零件码 | 零件-版本 | ... |
| Z1 | M1 | N1 | type1 | Code1 | Version1.0 | ... |
| Z2 | M1 | N2 | type1 | Code2 | Version1.0 | ... |
| Z3 | M2 | N3 | type2 | Code1 | Version1.1 | ... |
| Z4 | M2 | N4 | type2 | Code3 | Version2.1 | ... |
| Z5 | M3 | N5 | type4 | Code2 | Version1.0 | ... |
| Z6 | M3 | N6 | type4 | Code1 | Version2.3 | ... |
| Z7 | M4 | N7 | type3 | Code4 | Version1.0 | ... |
| ... | ... | ... | ... | ... | ... | ... |
结合表1、2、3，首先，可确定全量数据主表table_main与全量数据维表table_dim[x]的关联字段为“车辆-车型”字段，table_main与table_dim[y]的关联字段为“零件-零件码”字段。
在实际应用中，可以根据不同的业务需求信息设置对应的待填充宽表的表结构，并将该表结构存储在缓存数据库中，以便于后续的调用。
若是需要统计某个品牌的所有车辆中某个分类下的所有零件的当前版本信息，则可从缓存数据库中调取出对应的待填充宽表。其中，调取出的待填充宽表的表结构可如下表4所示。
表4
接下来，将该待填充宽表(表4)与全量数据主表(业务库表Z)进行对比，以确定表4中的每一列所需要填充的数据，并由此将表4的所有列划分为用于填充全量数据维表中与关联字段对应的维度数据的第一待填充位置(即表4中的第5列和表4中的第8列)，以及用于填充全量数据主表中的主表数据的第二待填充位置(即表4中除了第5列和第8列之外的其他列)。
从全量数据维表table_dim[x]中提取出与全量数据主表table_main的关联字段“车辆-车型”对应的维度数据(即表1中的第2列数据)；从全量数据维表table_dim[y]中提取出与全量数据主表table_main的关联字段“零件-零件码”对应的维度数据(即表2中的第2列数据)。然后，将表1中的第2列数据填充至表4中的第5列中，将表2中的第2列数据填充至表4中的第8列。将表3中的各列数据分别对应填充至表4中除了第5列和第8列之外的其他列中，得到如下表5所示的目标宽表。
表5
提取出全量数据主表table_main中的唯一标识字段(可以是“事实ID”、“车辆ID”、“零件ID”中的任意一个)，根据全量数据维表table_dim[x]的唯一标识字段(以“事实ID”为例)与全量数据主表table_main的关联字段“车辆-车型”之间的映射关系，构建得到二者的映射关系表，记为X-relation(或记为table_relation[x])，如下表6所示。
表6
| type1 | Z1，Z2 |
| type2 | Z3，Z4 |
| type3 | Z7 |
| type4 | Z5，Z6 |
根据全量数据维表table_dim[y]的唯一标识字段(以“事实ID”为例)与全量数据主表table_main的关联字段“零件-零件码”之间的映射关系，构建得到二者的映射关系表，记为Y-relation(或记为table_relation[y])，如下表7所示。
表7
| Code1 | Z1，Z3，Z6 |
| Code2 | Z2，Z5 |
| Code3 | Z4 |
| Code4 | Z7 |
将表5、表6和表7均存储至缓存数据库中，同时将表5的副本推送至目标数据库中。
在一些实施例中，上述步骤S205，包括：
若数据变更操作记录为针对全量数据主表的主表变更操作记录，且主表变更操作记录对应的主表变更时间戳大于主表变更操作记录对应的初始化时间戳，则从缓存数据库的全量数据主表中提取出与主表变更操作记录相关的主表数据；
根据与主表变更操作记录对应的主表变更数据对主表数据进行更新，得到更新全量数据主表；
若主表变更操作记录涉及到与全量数据维表关联的关联字段，则确定主表变更操作记录涉及到变更关联字段；
从缓存数据库的映射关系表中提取出与变更关联字段对应的映射字段；
根据主表变更操作记录，级联更新变更关联字段与映射字段的对应关系，得到更新映射关系表；
根据更新全量数据主表和更新映射关系表，对目标宽表进行更新，得到更新目标宽表；
将更新目标宽表推送至更新消息队列中。
作为一示例，若数据变更操作记录为针对全量数据主表table_main(即业务库表Z)的主表变更操作记录，例如，该主表变更操作记录为将表3中的“Z1”所在行的“零件-零件码”从“Code1”变更为“Code3”的变更操作记录，且该主表变更操作记录对应的主表变更时间戳(即将表3中的“Z1”所在行的“零件-零件码”从“Code1”变更为“Code3”的变更时间点)大于主表变更操作记录对应的初始化时间戳(将表3存储至缓存数据库中的初始化时间点)，则从缓存数据库的业务库表Z中提取出与主表变更操作记录相关的主表数据，即从业务库表Z提取出“Code3”的相关数据，并将该“Code3”的相关数据替换到表3中的“Z1”所在行的“零件-零件码”的“Code1”的位置，得到更新全量数据主表，如下表8所示。
表8
| 事实ID | 车辆ID | 零件ID | 车辆-车型 | 零件-零件码 | 零件-版本 | ... |
| Z1 | M1 | N1 | type1 | Code3 | Version1.0 | ... |
| Z2 | M1 | N2 | type1 | Code2 | Version1.0 | ... |
| Z3 | M2 | N3 | type2 | Code1 | Vetsion1.1 | ... |
| Z4 | M2 | N4 | type2 | Code3 | Version2.1 | ... |
| Z5 | M3 | N5 | type4 | Code2 | Version1.0 | ... |
| Z6 | M3 | N6 | type4 | Code1 | Version2.3 | ... |
| Z7 | M4 | N7 | type3 | Code4 | Vetsion1.0 | ... |
| ... | ... | ... | ... | ... | ... | ... |
结合上述示例，由于该主表变更操作记录涉及到全量数据主表table_main与全量数据维表table_dim[y]关联的关联字段“零件-零件码”的变更，则可确定主表变更操作记录涉及到变更关联字段为“零件-零件码”中的“Code1”和“Code3”。接着，从缓存数据库中，从映射关系表Y-relation中将与“Code1”对应的映射字段“Z1，Z3，Z6”以及与“Code3”对应的映射字段“Z4”均提取出来。之后，从Y-relation中的“Code1”的value(值)中删除“Z 1”，变为“Z3，Z6”；向Y-relation中的“Code3”的value中增加“Z1”，变为“Z1，Z4”，由此得到更新映射关系表，如下表9所示。
表9
| Code1 | Z3，Z6 |
| Code2 | Z2，Z5 |
| Code3 | Z1，Z4 |
| Code4 | Z7 |
之后，根据更新全量数据主表和更新映射关系表，对目标宽表进行更新，得到更新目标宽表，如下表10所示。
表10
在另一些实施例中，上述步骤S205，包括：
若数据变更操作记录为针对全量数据维表的维表变更操作记录，且维表变更操作记对应的维表变更时间戳大于维表变更操作记录对应的初始化时间戳，则从缓存数据库中提取出与维表变更操作记录相关的维表数据；
根据与维表变更操作记录对应的维表变更数据对维表数据进行更新，得到更新全量数据维表；
若维表变更操作记录涉及到与全量数据主表关联的关联字段，则确定维表变更操作记录涉及到的变更字段；
从缓存数据库的映射关系表中提取出与变更字段对应的映射关系字段；
根据维表变更操作记录，级联更新变更字段与映射关系字段的对应关系，得到变更映射关系表；
根据更新全量数据维表和变更映射关系表对目标宽表进行更新，得到更新目标宽表；
将更新目标宽表推送至更新消息队列中。
作为一示例，若数据变更操作记录为针对全量数据维表的维表变更操作记录，例如，维表变更操作记录为删除全量数据维表table_dim[x](即业务库表X)中的“type1”所在行，且维表变更操作记对应的维表变更时间戳(即删除全量数据维表table_dim[x](即业务库表X)中的“type1”所在行的时间点)大于维表变更操作记录对应的初始化时间戳(即表1存储至缓存数据库中的初始化时间点)，则从缓存数据库中提取出与该维表变更操作记录相关的维表数据，即提取出table_dim[x]中的“type1”所在行的数据，并删除“type1”所在行的数据，得到更新全量数据维表，如下表11所示。
表11
| 车辆-车型 | 车辆-品牌 |
| type2 | BrandA |
| type3 | BrandA |
| type4 | BrandB |
| ... | ... |
结合该示例，由于该维表变更操作记录涉及到与全量数据主表关联的关联字段“type1”的变更，由此可确定该维表变更操作记录涉及到的变更字段为“type1”。
接着，从缓存数据库的映射关系表X-relation中提取出与该变更字段“type1”对应的映射关系字段“Z1，Z2”，并根据维表变更操作记录，级联更新变更字段与映射关系字段的对应关系，即删除映射关系表X-relation中的“type1”所在行，得到变更映射关系表，如下表12所示。
表12
| type2 | Z3，Z4 |
| type3 | Z7 |
| type4 | Z5，Z6 |
之后，根据表11和表12对目标宽表进行更新，得到更新目标宽表，如下表13所示。
表13
即需要从缓存数据库中取出X-relation中的type1对应的值“Z1，Z2”，对应删除目标宽表中来自全量数据维表table_dim[x]的字段数据“BrandA”。值得注意的是，来自全量数据主表table_main的车辆-车型字段对应的“type1”需要保留，因为这个数据不受全量数据维表table_dim[x]中是否存在“type1”影响。
在又一些实施例中，上述步骤S205，包括：
若数据变更操作记录为针对全量数据维表的维表变更操作记录，且维表变更操作记对应的维表变更时间戳大于维表变更操作记录对应的初始化时间戳，则从缓存数据库中提取出与维表变更操作记录相关的维表数据；
根据与维表变更操作记录对应的维表变更数据对维表数据进行更新，得到更新全量数据维表；
若维表变更操作记录涉及到目标宽表中的宽表字段，宽表字段与关联字段不同，则从缓存数据库的映射关系表中提取出维表数据对应的关系字段；
根据关系字段与宽表字段的对应关系，更新目标宽表中与宽表字段对应的宽表数据，得到更新目标宽表；
将更新目标宽表推送至更新消息队列中。
作为一示例，若数据变更操作记录为针对全量数据维表的维表变更操作记录，例如，该维表变更操作记录为将全量数据维表table_dim[x](即业务库表X)中的“type2”所在行的“车辆-品牌”从“BrandA”变更为“BrandC”，且维表变更操作记对应的维表变更时间戳(即将业务库表X中的“type2”所在行的“车辆-品牌”从“BrandA”变更为“BrandC”的时间点)大于维表变更操作记录对应的初始化时间戳(即表1存储至缓存数据库中的初始化时间点)，则从缓存数据库中提取出与维表变更操作记录相关的维表数据，即提取出全量数据维表table_dim[x]中的“type2”所在行的“车辆-品牌”的“BrandA”，并将“BrandA”更新为“BrandC”，得到更新全量数据维表，如下表14所示。
表14
| 车辆-车型 | 车辆-品牌 |
| type1 | BrandA |
| type2 | BrandC |
| type3 | BrandA |
| type4 | BrandB |
| ... | ... |
结合该示例，由于上述维表变更操作记录涉及到目标宽表中的宽表字段“type2”的变更，则可从缓存数据库中提取出映射关系表X-relation中与“type2”对应的关系字段“Z3，Z4”，并根据“type2”与“Z3，Z4”的对应关系，将缓存数据库中的目标宽表中的“Z3，Z4”所在行所对应的“车辆-品牌”的值(宽表数据)“BrandA”更新为“BrandC”，得到更新目标宽表，如下表15所示。
表15
需要说明的是，在执行上述实时关联更新操作之后，将初始化时间戳替换为变更时间戳，也即每次更新完毕之后，需要更新一次变更操作记录对应的初始化时间戳。当再次针对该变更操作记录对应的数据进行更新时，可在前一次更新的基础上进行，保证数据的更新时效性。
对于来自于同一连接同一个数据流的多个全量数据表，由于数据的到来是有序的，无需考虑时序的问题。但是，若是参与实时关联计算的多个全量数据表来自于不同的数据流(不同数据源)，则还需要解决不同数据源的数据到达时间错位而导致更新错误的问题。为了解决不同数据源的数据到达错位导致更新错误的问题，本申请实施例提供的技术方案采用流式处理，对不同数据源的流式数据进行时序化预处理，尽量避免乱序造成更新错误。具体方案如下：
上述步骤S205，具体包括：
在第一预设滚动窗口中接收数据变更操作记录和变更时间戳；
剔除变更时间戳小于初始化时间戳的数据变更操作记录，得到过滤后变更操作记录；
按照变更时间戳对过滤后变更操作记录进行排序，得到排序结果；
根据排序结果依次查看并处理过滤后变更操作记录，以对缓存数据库中的目标宽表，以及全量数据主表、全量数据维表、映射关系表中的至少一个进行实时关联更新，得到实时关联更新结果。
在实际应用中，可先设置好第一预设滚动窗口的数据接收时间区间，该数据接收时间区间可以根据实际情况设置，例如，可以设置为30秒、1分钟等，在此不做具体限制。
从T0时刻起，打开第一预设滚动窗口，在第一预设滚动窗口内接收T0时刻到T1时刻之间到达的数据变更操作记录和变更时间戳。示例性的，若第一预设滚动窗口的数据接收时间区间为1分钟，那么T0时刻到T1时刻之间的时间差值为1分钟，例如，T0时刻为11:00，那么T1时刻为11:01，在第一预设滚动窗口内接收11:00～11:01之间到达的数据变更操作记录和变更时间戳。
然后，比较每一条数据变更操作记录对应的变更时间戳与其初始化时间戳的大小，剔除其中变更时间戳中小于初始化时间戳的数据变更操作记录，得到过滤后变更操作记录。通过该剔除操作，可以将变更时间戳小于初始化时间戳的异常变更操作记录过滤掉，有利于节省计算资源，提高实时关联计算效率。
接下来，按照变更时间戳从小到大的顺序对过滤后变更操作记录进行排序，得到排序结果。之后，根据该排序结果依次查看并处理每一条过滤后变更操作记录。例如，在11:00～11:01之间到达第一预设滚动窗口的数据变更操作记录和变更时间戳有5条，那么可先对这5条数据变更操作记录对应的变更时间戳与其初始化时间戳进行对比，过滤掉其中变更时间戳中小于初始化时间戳的数据变更操作记录，得到过滤后变更操作记录。假设这5条数据变更操作记录对应的变更时间戳均大于其对应的初始化时间戳，那么这5条数据变更操作记录都是正常的。然后，按照这5条数据变更操作记录对应的变更时间戳从小到大的顺序进行排序，得到排序结果。若排序结果为数据变更操作记录A1＜A5＜A3＜A2＜A4，则按照A1→A5→A3→A2→A4的顺序依次查看并参照上述步骤处理这5条数据变更操作记录。
在一些实施例中，在步骤S205之后，还包括：
若在关闭了第一预设滚动窗口后且打开了第二预设滚动窗口时，接收到迟到数据变更操作记录，则提取缓存数据库中与迟到数据变更操作记录对应的现有数据变更时间戳，其中，迟到数据变更操作记录的迟到变更时间戳在第一预设滚动窗口的时间区间内；
若现有数据变更时间戳小于迟到变更时间戳，则对缓存数据库中的目标宽表，以及全量数据主表、全量数据维表、映射关系表中的至少一个进行实时关联更新，得到更新结果。
结合上述示例，假设当前处于从T1时刻～T2时刻(11:01～11:02)之间，已经关闭了第一预设滚动窗口并打开了第二预设滚动窗口，此时接收到变更时间戳为11点00分30秒(在第一预设滚动窗口的时间区间内)的迟到数据变更操作记录，则从缓存数据库中提取与该迟到数据变更操作记录对应的现有数据变更时间戳(即最近变更时间戳)。比较现有数据变更时间戳与迟到变更时间戳的大小，若现有数据变更时间戳小于迟到变更时间戳，则对缓存数据库中的目标宽表，以及全量数据主表、全量数据维表、映射关系表中的至少一个进行实时关联更新，得到更新结果。若现有数据变更时间戳大于或等于迟到变更时间戳，则不处理该条迟到数据变更操作记录。
本申请实施例提供的技术方案，通过设置合适的滚动窗口接收监听到的数据变更操作记录和变更时间戳，并依据变更时间戳从小到大进行依次处理过滤后的数据变更操作记录，可以很好地解决来自不同数据源的流式数据的实时关联更新计算，避免更新错漏，有利于提高实时关联更新的质量。
上述所有可选技术方案，可以采用任意结合形成本申请的可选实施例，在此不再一一赘述。
图3是本申请的一个实施例提供的针对全量数据主表的变更的实时关联更新流程示意图。如图3所示，该实时关联更新方法包括如下步骤：
步骤S301，初始化。对写入缓存数据库中的多个全量数据表进行初始化，并记录每一个全量数据表中的每一条数据的初始化时间戳，对多个全量数据表进行实时关联计算，得到目标宽表以及全量数据主表与每一个全量数据维表之间的映射关系表，并将目标宽表和映射关系表均存储至缓存数据库中，将目标宽表的副本推送至目标数据库。
步骤S302，实时监听源数据库中的多个全量数据表的数据变更操作，以获取源数据库的数据变更操作记录和变更时间戳。
步骤S303，按照变更时间戳从小到大的顺序对监听到的数据变更操作记录进行排序，得到排序结果。
步骤S304，按照步骤S303中的排序结果依次判断该数据变更操作记录是否为针对全量数据主表的变更。
步骤S305，若该数据变更操作记录是针对全量数据主表的变更，则判断针对全量数据主表的变更是否涉及到其与全量数据维表关联的关联字段。
步骤S306，若针对全量数据主表的变更不涉及其与全量数据维表关联的关联字段(例如，将如业务库表Z中的Z1所在行的“零件-版本”从“Version1.0”变更为“Version1.1”)，则直接更新缓存数据库中的全量数据主表对应的主表数据，并对目标宽表进行更新，推送更新目标宽表至Kafka消息队列。
步骤S307，若针对全量数据主表的变更涉及到其与全量数据维表关联的关联字段，则根据与该关联字段的相关主表数据对全量数据主表进行更新，并根据该关联字段，更新该全量数据维表与全量数据主表的映射关系。例如，该主表变更操作记录为将表3中的“Z1”所在行的“零件-零件码”从“Code1”变更为“Code3”的变更操作记录，可参照前文描述的关于该示例的实时关联更新步骤来实现对全量数据主表、映射关系表、目标宽表的实时关联更新，在此不再赘述。
其中，上述步骤S307可包括：若针对全量数据主表的变更涉及到其与全量数据维表关联的关联字段，则判断针对全量数据主表的变更的全量数据主表的key(关键字)是否发生变化；若针对全量数据主表的变更的全量数据主表的key(关键字)发生变化(如增加key或删除key)，则在全量数据主表增加key，同时更新每个全量数据维表与全量数据主表的映射关系表，或者删除全量数据主表中与该key(关键字)对应的行的数据，并删除每个全量数据维表与全量数据主表的映射关系表中的与该key(关键字)对应的映射关系。若针对全量数据主表的变更的全量数据主表的key(关键字)没有发生变化，则更新全量数据主表中的与该key对应的主表数据，并判断全量数据维表的key(关键字)是否发生变化。若是全量数据维表的key(关键字)发生变化，则从全量数据维表与全量数据主表的映射关系表中删除全量数据维表的key(关键字)发生变化之前的映射关系，并增加全量数据维表的key(关键字)发生变化之后的映射关系。
图4是本申请的一个实施例提供的针对全量数据维表的变更的实时关联更新流程示意图。如图4所示，该实时关联更新方法包括如下步骤：
步骤S401，与上述步骤S301相同。
步骤S402，与上述步骤S302相同。
步骤S403，与上述步骤S303相同。
步骤S404，按照步骤S403中的排序结果依次判断该数据变更操作记录是否为针对全量数据维表的变更。
步骤S405，若该数据变更操作记录是针对全量数据维表的变更，则判断针对全量数据维表的变更所涉及的相关字段的类型；
步骤S406，若针对全量数据维表的变更所涉及的相关字段不涉及到与目标宽表相关的字段，则直接更新全量数据维表中与该相关字段对应的维表数据。
步骤S407，若针对全量数据维表的变更所涉及到的相关字段涉及到宽表字段，则更新全量数据维表中与该宽表字段对应的维表数据，并根据全量数据维表与全量数据主表的映射关系表中与该宽表字段对应的映射关系字段，对目标宽表进行更新。例如，该数据变更操作记录为将全量数据维表table_dim[x](即业务库表X)中的“type2”所在行的“车辆-品牌”从“BrandA”变更为“BrandC”，可参照前文描述的关于该示例的实时关联更新步骤来实现对全量数据维表、目标宽表的实时关联更新，在此不再赘述。
步骤S408，若针对全量数据维表的变更所涉及到的相关字段涉及到其与全量数据主表关联的关联字段，则从全量数据维表与全量数据主表的映射关系表中提取出与该关联字段对应的映射关系，并根据该映射关系对目标宽表进行更新。例如，该数据变更操作记录为删除全量数据维表table_dim[x](即业务库表X)中的“type1”所在行，可参照前文描述的关于该示例的实时关联更新步骤来实现对全量数据维表、映射关系表、目标宽表的实时关联更新，在此不再赘述。
下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。
图5是本申请实施例提供的一种多表全量数据的实时关联更新装置的示意图。如图5所示，该多表全量数据的实时关联更新装置包括：
获取模块501，被配置为获取业务需求信息；
读取模块502，被配置为读取源数据库中与业务需求信息具有关联逻辑关系的多个全量数据表并将其写入缓存数据库中，记录每一个全量数据表中的每一条数据的初始化时间戳，多个全量数据表包括一个全量数据主表和至少一个全量数据维表，全量数据主表与全量数据维表具有关联关系；
计算模块503，被配置为对多个全量数据表进行实时关联计算，得到目标宽表以及全量数据主表与每一个全量数据维表之间的映射关系表，并将目标宽表和映射关系表均存储至缓存数据库中，将目标宽表的副本推送至目标数据库；
监听模块504，被配置为实时监听源数据库的多个全量数据表的数据变更操作，以获取源数据库的数据变更操作记录和变更时间戳；
更新模块505，被配置为根据初始化时间戳、数据变更操作记录和变更时间戳，对缓存数据库中的目标宽表，以及全量数据主表、全量数据维表、映射关系表中的至少一个进行实时关联更新，得到更新结果，并将更新结果推送至更新消息队列中，以使目标数据库实时读取更新消息队列中的更新结果，并根据更新结果同步更新目标宽表的副本。
本申请实施例提供的技术方案，通过采用缓存与消息队列相结合的方式存储实时关联计算的所需数据和目标结果数据(用于表征目标宽表的数据现状的数据)，可将实时关联更新计算所需数据与查询所需数据隔离，避免资源冲突，且此种方式对并发查询友好，可有效缓解因高并发的计算量导致的超时问题，而且无需占用过多的内存资源，资源利用率较高；进一步，通过监听源数据库的binlog日志的方式获取源数据库的数据变更操作记录和变更时间戳，可以避免多次读取源数据库数据，对源数据库无负担；根据初始化时间戳、数据变更操作记录和变更时间戳，对缓存数据库中的目标宽表，以及全量数据主表、全量数据维表、映射关系表中的至少一个进行实时关联更新可实现对源数据库的全量数据表的时序化处理，尽量避免因乱序造成更新错误的问题，同时还可将每个数据变更所涉及的计算量控制在最小范围，不仅可节约计算资源，还可提高实时关联更新计算的效率。此外，本申请实施例提供的技术方案无需为每个输入的数据流(全量数据表)设置一个有效时间范围，可适用于对于需要持续监听的数据的实时关联更新的场景，应用范围较广。
在一些实施例中，上述计算模块503，具体包括：
确定单元，被配置为确定全量数据主表与全量数据维表的关联字段；
获取单元，被配置为获取与业务需求信息对应的待填充宽表；
位置确定单元，被配置为将待填充宽表与全量数据主表进行对比，确定待填充宽表中的第一待填充位置和第二待填充位置；
提取单元，被配置为从全量数据维表中提取出与关联字段对应的维度数据；
填充单元，被配置为将维度数据填充至待填充宽表中的第一待填充位置，将全量数据主表中的主表数据填充至待填充宽表中的第二待填充位置，得到目标宽表；
字段提取单元，被配置为提取全量数据主表中的唯一标识字段，根据关联字段和唯一标识字段之间的映射关系，获得全量数据主表与每一个全量数据维表之间的映射关系表。
在一些实施例中，上述更新模块505，具体包括：
接收单元，被配置为在第一预设滚动窗口中接收数据变更操作记录和变更时间戳；
剔除单元，被配置为剔除变更时间戳小于初始化时间戳的数据变更操作记录，得到过滤后变更操作记录；
排序单元，被配置为按照变更时间戳对过滤后变更操作记录进行排序，得到排序结果；
处理单元，被配置为根据排序结果依次查看并处理过滤后变更操作记录，以对缓存数据库中的目标宽表，以及全量数据主表、全量数据维表、映射关系表中的至少一个进行实时关联更新，得到实时关联更新结果。
在一些实施例中，上述装置还包括：
接收模块，被配置为若在关闭了第一预设滚动窗口后且打开了第二预设滚动窗口时，接收到迟到数据变更操作记录，则提取缓存数据库中与迟到数据变更操作记录对应的现有数据变更时间戳，其中，迟到数据变更操作记录的迟到变更时间戳在第一预设滚动窗口的时间区间内；
关联更新模块，被配置为若现有数据变更时间戳小于迟到变更时间戳，则对缓存数据库中的目标宽表，以及全量数据主表、全量数据维表、映射关系表中的至少一个进行实时关联更新，得到更新结果。
在一些实施例中，上述更新模块505，具体包括：
主表数据提取单元，被配置为若数据变更操作记录为针对全量数据主表的主表变更操作记录，且主表变更操作记录对应的主表变更时间戳大于主表变更操作记录对应的初始化时间戳，则从缓存数据库的全量数据主表中提取出与主表变更操作记录相关的主表数据；
主表更新单元，被配置为根据与主表变更操作记录对应的主表变更数据对主表数据进行更新，得到更新全量数据主表；
关联字段确定单元，被配置为若主表变更操作记录涉及到与全量数据维表关联的关联字段，则确定主表变更操作记录涉及到变更关联字段；
映射字段提取单元，被配置为从缓存数据库的映射关系表中提取出与变更关联字段对应的映射字段；
级联更新单元，被配置为根据主表变更操作记录，级联更新变更关联字段与映射字段的对应关系，得到更新映射关系表；
第一宽表更新单元，被配置为根据更新全量数据主表和更新映射关系表，对目标宽表进行更新，得到更新目标宽表；
第一消息推送单元，被配置为将更新目标宽表推送至更新消息队列中。
在一些实施例中，上述更新模块505，具体包括：
维表数据提取单元，被配置为若数据变更操作记录为针对全量数据维表的维表变更操作记录，且维表变更操作记对应的维表变更时间戳大于维表变更操作记录对应的初始化时间戳，则从缓存数据库中提取出与维表变更操作记录相关的维表数据；
维表更新单元，被配置为根据与维表变更操作记录对应的维表变更数据对维表数据进行更新，得到更新全量数据维表；
变更字段提取单元，被配置为若维表变更操作记录涉及到与全量数据主表关联的关联字段，则确定维表变更操作记录涉及到的变更字段；
映射关系字段提取单元，被配置为从缓存数据库的映射关系表中提取出与变更字段对应的映射关系字段；
关系更新单元，被配置为根据维表变更操作记录，级联更新变更字段与映射关系字段的对应关系，得到变更映射关系表；
第二宽表更新单元，被配置为根据更新全量数据维表和变更映射关系表对目标宽表进行更新，得到更新目标宽表；
第二消息推送单元，被配置为将更新目标宽表推送至更新消息队列中。
在一些实施例中，上述更新模块505，具体包括：
数据提取单元，被配置为若数据变更操作记录为针对全量数据维表的维表变更操作记录，且维表变更操作记对应的维表变更时间戳大于维表变更操作记录对应的初始化时间戳，则从缓存数据库中提取出与维表变更操作记录相关的维表数据；
数据更新单元，被配置为根据与维表变更操作记录对应的维表变更数据对维表数据进行更新，得到更新全量数据维表；
关系字段提取单元，被配置为若维表变更操作记录涉及到目标宽表中的宽表字段，宽表字段与关联字段不同，则从缓存数据库的映射关系表中提取出维表数据对应的关系字段；
第三宽表更新单元，被配置为根据关系字段与宽表字段的对应关系，更新目标宽表中与宽表字段对应的宽表数据，得到更新目标宽表；
第三消息推送单元，被配置为将更新目标宽表推送至更新消息队列中。
应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
图6是本申请实施例提供的电子设备6的示意图。如图6所示，该实施例的电子设备6包括：处理器601、存储器602以及存储在该存储器602中并且可在处理器601上运行的计算机程序603。处理器601执行计算机程序603时实现上述各个方法实施例中的步骤。或者，处理器601执行计算机程序603时实现上述各装置实施例中各模块/单元的功能。
电子设备6可以是桌上型计算机、笔记本、掌上电脑及云端服务器等电子设备。电子设备6可以包括但不仅限于处理器601和存储器602。本领域技术人员可以理解，图6仅仅是电子设备6的示例，并不构成对电子设备6的限定，可以包括比图示更多或更少的部件，或者不同的部件。
处理器601可以是中央处理单元(Central Processing Unit，CPU)，也可以是其它通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。
存储器602可以是电子设备6的内部存储单元，例如，电子设备6的硬盘或内存。存储器602也可以是电子设备6的外部存储设备，例如，电子设备6上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。存储器602还可以既包括电子设备6的内部存储单元也包括外部存储设备。存储器602用于存储计算机程序以及电子设备所需的其它程序和数据。
所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，计算机程序可以存储在计算机可读存储介质中，该计算机程序在被处理器执行时，可以实现上述各个方法实施例的步骤。计算机程序可以包括计算机程序代码，计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。计算机可读介质可以包括：能够携带计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、电载波信号、电信信号以及软件分发介质等。需要说明的是，计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如，在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。
以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。
Claims (10)
1.一种多表全量数据的实时关联更新方法，其特征在于，包括：
获取业务需求信息；
读取源数据库中与所述业务需求信息具有关联逻辑关系的多个全量数据表并将其写入缓存数据库中，记录每一个全量数据表中的每一条数据的初始化时间戳，所述多个全量数据表包括一个全量数据主表和至少一个全量数据维表，所述全量数据主表与所述全量数据维表具有关联关系；
对所述多个全量数据表进行实时关联计算，得到目标宽表以及所述全量数据主表与每一个全量数据维表之间的映射关系表，并将所述目标宽表和映射关系表均存储至缓存数据库中，将所述目标宽表的副本推送至目标数据库；
实时监听源数据库的多个全量数据表的数据变更操作，以获取所述源数据库的数据变更操作记录和变更时间戳；
根据所述初始化时间戳、数据变更操作记录和变更时间戳，对所述缓存数据库中的目标宽表，以及所述全量数据主表、全量数据维表、映射关系表中的至少一个进行实时关联更新，得到更新结果，并将所述更新结果推送至更新消息队列中，以使所述目标数据库实时读取所述更新消息队列中的更新结果，并根据所述更新结果同步更新所述目标宽表的副本。
2.根据权利要求1所述的方法，其特征在于，对所述多个全量数据表进行实时关联计算，得到目标宽表以及所述全量数据主表与每一个全量数据维表之间的映射关系表，包括：
确定所述全量数据主表与所述全量数据维表的关联字段；
获取与所述业务需求信息对应的待填充宽表；
将所述待填充宽表与所述全量数据主表进行对比，确定所述待填充宽表中的第一待填充位置和第二待填充位置；
从所述全量数据维表中提取出与所述关联字段对应的维度数据；
将所述维度数据填充至所述待填充宽表中的第一待填充位置，将所述全量数据主表中的主表数据填充至所述待填充宽表中的第二待填充位置，得到目标宽表；
提取所述全量数据主表中的唯一标识字段，根据所述关联字段和唯一标识字段之间的映射关系，获得所述全量数据主表与每一个全量数据维表之间的映射关系表。
3.根据权利要求1所述的方法，其特征在于，根据所述初始化时间戳、数据变更操作记录和变更时间戳，对所述缓存数据库中的目标宽表、全量数据主表、全量数据维表、映射关系表进行实时关联更新，得到更新结果，包括：
在第一预设滚动窗口中接收所述数据变更操作记录和变更时间戳；
剔除变更时间戳小于所述初始化时间戳的数据变更操作记录，得到过滤后变更操作记录；
按照所述变更时间戳对所述过滤后变更操作记录进行排序，得到排序结果；
根据所述排序结果依次查看并处理所述过滤后变更操作记录，以对所述缓存数据库中的目标宽表，以及所述全量数据主表、全量数据维表、映射关系表中的至少一个进行实时关联更新，得到实时关联更新结果。
4.根据权利要求3所述的方法，其特征在于，根据所述排序结果依次查看并处理所述过滤后变更操作记录，以对所述缓存数据库中的目标宽表，以及所述全量数据主表、全量数据维表、映射关系表中的至少一个进行实时关联更新，得到实时关联更新结果之后，还包括：
若在关闭了所述第一预设滚动窗口后且打开了第二预设滚动窗口时，接收到迟到数据变更操作记录，则提取所述缓存数据库中与所述迟到数据变更操作记录对应的现有数据变更时间戳，其中，所述迟到数据变更操作记录的迟到变更时间戳在第一预设滚动窗口的时间区间内；
若所述现有数据变更时间戳小于所述迟到变更时间戳，则对所述缓存数据库中的目标宽表，以及所述全量数据主表、全量数据维表、映射关系表中的至少一个进行实时关联更新，得到更新结果。
5.根据权利要求1所述的方法，其特征在于，根据所述初始化时间戳、数据变更操作记录和变更时间戳，对所述缓存数据库中的目标宽表，以及所述全量数据主表、全量数据维表、映射关系表中的至少一个进行实时关联更新，得到更新结果，并将所述更新结果推送至更新消息队列中，包括：
若所述数据变更操作记录为针对全量数据主表的主表变更操作记录，且所述主表变更操作记录对应的主表变更时间戳大于所述主表变更操作记录对应的初始化时间戳，则从缓存数据库的全量数据主表中提取出与所述主表变更操作记录相关的主表数据；
根据与所述主表变更操作记录对应的主表变更数据对所述主表数据进行更新，得到更新全量数据主表；
若所述主表变更操作记录涉及到与所述全量数据维表关联的关联字段，则确定所述主表变更操作记录涉及到变更关联字段；
从缓存数据库的映射关系表中提取出与所述变更关联字段对应的映射字段；
根据所述主表变更操作记录，级联更新所述变更关联字段与映射字段的对应关系，得到更新映射关系表；
根据所述更新全量数据主表和更新映射关系表，对所述目标宽表进行更新，得到更新目标宽表；
将所述更新目标宽表推送至更新消息队列中。
6.根据权利要求1所述的方法，其特征在于，根据所述初始化时间戳、数据变更操作记录和变更时间戳，对所述缓存数据库中的目标宽表，以及所述全量数据主表、全量数据维表、映射关系表中的至少一个进行实时关联更新，得到更新结果，并将所述更新结果推送至更新消息队列中，包括：
若所述数据变更操作记录为针对全量数据维表的维表变更操作记录，且所述维表变更操作记对应的维表变更时间戳大于所述维表变更操作记录对应的初始化时间戳，则从缓存数据库中提取出与所述维表变更操作记录相关的维表数据；
根据与所述维表变更操作记录对应的维表变更数据对所述维表数据进行更新，得到更新全量数据维表；
若所述维表变更操作记录涉及到与所述全量数据主表关联的关联字段，则确定所述维表变更操作记录涉及到的变更字段；
从缓存数据库的映射关系表中提取出与所述变更字段对应的映射关系字段；
根据所述维表变更操作记录，级联更新所述变更字段与映射关系字段的对应关系，得到变更映射关系表；
根据所述更新全量数据维表和变更映射关系表对所述目标宽表进行更新，得到更新目标宽表；
将所述更新目标宽表推送至更新消息队列中。
7.根据权利要求1所述的方法，其特征在于，根据所述初始化时间戳、数据变更操作记录和变更时间戳，对所述缓存数据库中的目标宽表，以及所述全量数据主表、全量数据维表、映射关系表中的至少一个进行实时关联更新，得到更新结果，并将所述更新结果推送至更新消息队列中，包括：
若所述数据变更操作记录为针对全量数据维表的维表变更操作记录，且所述维表变更操作记对应的维表变更时间戳大于所述维表变更操作记录对应的初始化时间戳，则从缓存数据库中提取出与所述维表变更操作记录相关的维表数据；
根据与所述维表变更操作记录对应的维表变更数据对所述维表数据进行更新，得到更新全量数据维表；
若所述维表变更操作记录涉及到目标宽表中的宽表字段，所述宽表字段与关联字段不同，则从缓存数据库的映射关系表中提取出所述维表数据对应的关系字段；
根据所述关系字段与宽表字段的对应关系，更新所述目标宽表中与所述宽表字段对应的宽表数据，得到更新目标宽表；
将所述更新目标宽表推送至更新消息队列中。
8.一种多表全量数据的实时关联更新装置，其特征在于，包括：
获取模块，被配置为获取业务需求信息；
读取模块，被配置为读取源数据库中与所述业务需求信息具有关联逻辑关系的多个全量数据表并将其写入缓存数据库中，记录每一个全量数据表中的每一条数据的初始化时间戳，所述多个全量数据表包括一个全量数据主表和至少一个全量数据维表，所述全量数据主表与所述全量数据维表具有关联关系；
计算模块，被配置为对所述多个全量数据表进行实时关联计算，得到目标宽表以及所述全量数据主表与每一个全量数据维表之间的映射关系表，并将所述目标宽表和映射关系表均存储至缓存数据库中，将所述目标宽表的副本推送至目标数据库；
监听模块，被配置为实时监听源数据库的多个全量数据表的数据变更操作，以获取所述源数据库的数据变更操作记录和变更时间戳；
更新模块，被配置为根据所述初始化时间戳、数据变更操作记录和变更时间戳，对所述缓存数据库中的目标宽表，以及所述全量数据主表、全量数据维表、映射关系表中的至少一个进行实时关联更新，得到更新结果，并将所述更新结果推送至更新消息队列中，以使所述目标数据库实时读取所述更新消息队列中的更新结果，并根据所述更新结果同步更新所述目标宽表的副本。
9.一种电子设备，包括存储器、处理器以及存储在所述存储器中并且可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至7中任一项所述方法的步骤。
10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7中任一项所述方法的步骤。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310478152.1A CN116501715B (zh) | 2023-04-28 | 2023-04-28 | 一种多表全量数据的实时关联更新方法及装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310478152.1A CN116501715B (zh) | 2023-04-28 | 2023-04-28 | 一种多表全量数据的实时关联更新方法及装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN116501715A true CN116501715A (zh) | 2023-07-28 |
| CN116501715B CN116501715B (zh) | 2024-03-12 |
Family
ID=87321245
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310478152.1A Active CN116501715B (zh) | 2023-04-28 | 2023-04-28 | 一种多表全量数据的实时关联更新方法及装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116501715B (zh) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117390040A (zh) * | 2023-12-11 | 2024-01-12 | 深圳大道云科技有限公司 | 基于实时宽表的业务请求处理方法、设备及存储介质 |
Citations (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20140160281A1 (en) * | 2012-12-10 | 2014-06-12 | Pixia Corp. | Method and system for wide area motion imagery discovery using kml |
| US9037614B1 (en) * | 2012-02-24 | 2015-05-19 | Amazon Technologies, Inc. | Secondary mappings to enable code changes without schema updates |
| US20160350392A1 (en) * | 2015-05-29 | 2016-12-01 | Nuodb, Inc. | Table partitioning within distributed database systems |
| CN110209677A (zh) * | 2018-02-06 | 2019-09-06 | 北京京东尚科信息技术有限公司 | 更新数据的方法和装置 |
| CN111339103A (zh) * | 2020-03-13 | 2020-06-26 | 河南安冉云网络科技有限公司 | 一种基于全量分片和增量日志解析的数据交换方法及系统 |
| US20200364201A1 (en) * | 2019-05-13 | 2020-11-19 | Snowflake Inc. | Journaled tables in database systems |
| CN113157734A (zh) * | 2021-04-20 | 2021-07-23 | 平安银行股份有限公司 | 基于搜索框架的数据处理方法、装置、设备及存储介质 |
| CN113434501A (zh) * | 2021-06-23 | 2021-09-24 | 平安国际智慧城市科技股份有限公司 | 关系型数据库表的存储方法、设备及可读存储介质 |
| CN114036119A (zh) * | 2021-09-30 | 2022-02-11 | 河海大学 | 一种基于kettle和数据库日志的数据同步方法 |
| CN114201496A (zh) * | 2021-12-15 | 2022-03-18 | 中国建设银行股份有限公司 | 数据更新方法、装置、电子设备、系统及存储介质 |
| CN114265875A (zh) * | 2022-03-03 | 2022-04-01 | 深圳钛铂数据有限公司 | 一种基于流数据的实时建宽表的方法 |
| CN114579668A (zh) * | 2022-05-06 | 2022-06-03 | 中建电子商务有限责任公司 | 一种数据库数据同步方法 |
| CN115292327A (zh) * | 2022-08-16 | 2022-11-04 | 北京京东振世信息技术有限公司 | 多表关联方法及装置、设备及存储介质 |
| CN115587118A (zh) * | 2022-09-26 | 2023-01-10 | 新华三技术有限公司 | 任务数据的维表关联处理方法及装置、电子设备 |
| CN115630070A (zh) * | 2022-10-28 | 2023-01-20 | 海尔优家智能科技（北京）有限公司 | 一种信息推送方法、计算机可读的存储介质及电子装置 |
-
2023
- 2023-04-28 CN CN202310478152.1A patent/CN116501715B/zh active Active
Patent Citations (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9037614B1 (en) * | 2012-02-24 | 2015-05-19 | Amazon Technologies, Inc. | Secondary mappings to enable code changes without schema updates |
| US20140160281A1 (en) * | 2012-12-10 | 2014-06-12 | Pixia Corp. | Method and system for wide area motion imagery discovery using kml |
| US20160350392A1 (en) * | 2015-05-29 | 2016-12-01 | Nuodb, Inc. | Table partitioning within distributed database systems |
| CN110209677A (zh) * | 2018-02-06 | 2019-09-06 | 北京京东尚科信息技术有限公司 | 更新数据的方法和装置 |
| US20200364201A1 (en) * | 2019-05-13 | 2020-11-19 | Snowflake Inc. | Journaled tables in database systems |
| CN111339103A (zh) * | 2020-03-13 | 2020-06-26 | 河南安冉云网络科技有限公司 | 一种基于全量分片和增量日志解析的数据交换方法及系统 |
| CN113157734A (zh) * | 2021-04-20 | 2021-07-23 | 平安银行股份有限公司 | 基于搜索框架的数据处理方法、装置、设备及存储介质 |
| CN113434501A (zh) * | 2021-06-23 | 2021-09-24 | 平安国际智慧城市科技股份有限公司 | 关系型数据库表的存储方法、设备及可读存储介质 |
| CN114036119A (zh) * | 2021-09-30 | 2022-02-11 | 河海大学 | 一种基于kettle和数据库日志的数据同步方法 |
| CN114201496A (zh) * | 2021-12-15 | 2022-03-18 | 中国建设银行股份有限公司 | 数据更新方法、装置、电子设备、系统及存储介质 |
| CN114265875A (zh) * | 2022-03-03 | 2022-04-01 | 深圳钛铂数据有限公司 | 一种基于流数据的实时建宽表的方法 |
| CN114579668A (zh) * | 2022-05-06 | 2022-06-03 | 中建电子商务有限责任公司 | 一种数据库数据同步方法 |
| CN115292327A (zh) * | 2022-08-16 | 2022-11-04 | 北京京东振世信息技术有限公司 | 多表关联方法及装置、设备及存储介质 |
| CN115587118A (zh) * | 2022-09-26 | 2023-01-10 | 新华三技术有限公司 | 任务数据的维表关联处理方法及装置、电子设备 |
| CN115630070A (zh) * | 2022-10-28 | 2023-01-20 | 海尔优家智能科技（北京）有限公司 | 一种信息推送方法、计算机可读的存储介质及电子装置 |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117390040A (zh) * | 2023-12-11 | 2024-01-12 | 深圳大道云科技有限公司 | 基于实时宽表的业务请求处理方法、设备及存储介质 |
| CN117390040B (zh) * | 2023-12-11 | 2024-03-29 | 深圳大道云科技有限公司 | 基于实时宽表的业务请求处理方法、设备及存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN116501715B (zh) | 2024-03-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110750562B (zh) | 基于Storm的实时数据比对预警方法及系统 | |
| CN109213792B (zh) | 数据处理的方法、服务端、客户端、装置及可读存储介质 | |
| CN111352902A (zh) | 日志处理方法、装置、终端设备及存储介质 | |
| CN111597257A (zh) | 数据库的同步方法、装置、存储介质及终端 | |
| CN116501715B (zh) | 一种多表全量数据的实时关联更新方法及装置 | |
| CN112084161B (zh) | 基于数据库的数据处理方法、装置以及可读存储介质 | |
| CN111241177A (zh) | 数据采集方法、系统及网络设备 | |
| CN113672627B (zh) | Elasticsearch搜索引擎索引构建方法及装置 | |
| CN109360106B (zh) | 画像构建方法、系统、介质和计算机系统 | |
| CN110851474A (zh) | 数据查询方法、数据库中间件、数据查询设备及存储介质 | |
| CN113256355A (zh) | 一种积分权益实时确定方法、装置、介质、设备和系统 | |
| CN117493319A (zh) | 数据去重方法、装置、电子设备及存储介质 | |
| CN111563115B (zh) | 一种分布式数据库中数据分布信息的统计方法及装置 | |
| CN112527839A (zh) | 多源数据处理方法、系统、设备及存储介质 | |
| CN110046172B (zh) | 在线计算数据处理方法及系统 | |
| CN112905677A (zh) | 数据处理方法及装置、业务处理系统和计算机设备 | |
| CN112527900A (zh) | 一种数据库读多副本一致性的方法、装置、设备及介质 | |
| CN111209284B (zh) | 基于元数据的分表方法及装置 | |
| CN115794806A (zh) | 金融数据的网格化处理系统及方法、装置、计算设备 | |
| CN113626516A (zh) | 数据增量同步方法和系统 | |
| CN111966650A (zh) | 一种运维大数据共享数据表的处理方法、装置及存储介质 | |
| CN111158994A (zh) | 一种压测性能测试方法及装置 | |
| CN112862606A (zh) | 一种电力交易高并发数据申报方法及系统 | |
| CN116703184B (zh) | 数据处理方法、数据处理装置、电子设备及可读存储介质 | |
| CN116756247B (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 | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20240117 Address after: No. 13 Xingxiang Road, Zengjia Town, High tech Zone, Shapingba District, Chongqing, 400039 Applicant after: Chongqing Selis Phoenix Intelligent Innovation Technology Co.,Ltd. Address before: 610095 No. 2901, floor 29, unit 1, building 1, No. 151, Tianfu Second Street, high tech Zone, China (Sichuan) pilot Free Trade Zone, Chengdu, Sichuan Province Applicant before: Chengdu Thalys Technology Co.,Ltd. |
|
| TA01 | Transfer of patent application right | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |