CN111835847A - 数据处理方法、装置、设备及存储介质 - Google Patents

数据处理方法、装置、设备及存储介质 Download PDF

Info

Publication number
CN111835847A
CN111835847A CN202010661383.2A CN202010661383A CN111835847A CN 111835847 A CN111835847 A CN 111835847A CN 202010661383 A CN202010661383 A CN 202010661383A CN 111835847 A CN111835847 A CN 111835847A
Authority
CN
China
Prior art keywords
server
messages
data
message
order
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
Application number
CN202010661383.2A
Other languages
English (en)
Other versions
CN111835847B (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.)
China United Network Communications Group Co Ltd
Original Assignee
China United Network Communications Group 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 China United Network Communications Group Co Ltd filed Critical China United Network Communications Group Co Ltd
Priority to CN202010661383.2A priority Critical patent/CN111835847B/zh
Publication of CN111835847A publication Critical patent/CN111835847A/zh
Application granted granted Critical
Publication of CN111835847B publication Critical patent/CN111835847B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • 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/23—Updating
    • G06F16/2365—Ensuring data consistency and integrity
    • 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
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
    • G06Q30/0635—Processing of requisition or of purchase orders

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Probability & Statistics with Applications (AREA)
  • Databases & Information Systems (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Fuzzy Systems (AREA)
  • Mathematical Physics (AREA)
  • Software Systems (AREA)
  • Computational Linguistics (AREA)
  • Debugging And Monitoring (AREA)
  • Computer And Data Communications (AREA)

Abstract

本申请实施例提供一种数据处理方法、装置、设备及存储介质，该方法包括：第一服务器接收第一Kafka实时发送的多条第一消息；所述第一服务器对所述多条第一消息进行数据关联，生成多个第一订单数据；所述第一服务器对所述多个第一订单数据进行标准化处理，得到多条第二消息；所述第一服务器将所述多条第二消息存储至第二Kafka中；第二服务器将监控得到的所述多条第一消息和所述多条第二消息进行比对，确定所述第一服务器的接入数据和所述第一服务器的落地数据是否一致。本申请实施例提供的方法能够克服现有技术中无法有效地实现对数据归集，进而无法实现监控消息接入数据与落地数据消息是否平衡的问题。

Description

数据处理方法、装置、设备及存储介质
技术领域
本申请实施例涉及数据处理技术领域，尤其涉及一种数据处理方法、装置、设备及存储介质。
背景技术
随着用户规模的增加、产生数据量的快速增长，云平台承载的用户所需的资源越来越多。为应对激烈的市场竞争，运营商越来越依赖精确化的数据统计分析以实现科学管理和决策。数据质量的好坏直接关系到信息提供的准确程度。数据质量问题得不到有效解决，数据资产将不能有效反映企业运营和市场事实，经营决策将失去可靠依据。
大数据时代，数据爆炸式增长。海量的数据为运营商带来大量的信息资产。因此，围绕企业大数据的生命周期，实现对关键数据的全过程质量监控尤为重要。
但是现有技术中在对消息的监控稽核时，无法有效地实现对数据归集，进而无法实时有效地监控消息接入数据与落地数据消息是否平衡。
发明内容
本申请实施例提供一种数据处理方法、装置、设备及存储介质，以克服现有技术中无法有效地实现对数据归集，进而无法实现监控消息接入数据与落地数据消息是否平衡的问题。
第一方面，本申请实施例提供一种数据处理方法，包括：
第一服务器接收第一Kafka实时发送的多条第一消息；
所述第一服务器对所述多条第一消息进行数据关联，生成多个第一订单数据，每个所述第一订单数据中包括属于相同业务的同一用户对应的至少一条第一消息；
所述第一服务器对所述多个第一订单数据进行标准化处理，得到多条第二消息；
所述第一服务器将所述多条第二消息存储至第二Kafka中；
第二服务器将监控得到的所述多条第一消息和所述多条第二消息进行比对，确定所述第一服务器的接入数据和所述第一服务器的落地数据是否一致；
其中，所述接入数据为所述多条第一消息，所述落地数据为所述多条第二消息。
在一种可能的设计中，在所述第一服务器接收第一Kafka实时发送的多条第一消息之后，所述方法还包括；
所述第二服务器监控所述多条第一消息的第一数据量，若所述第一数据量大于第一预设阈值，则确定所述第一服务器接收到的第一Kafka实时发送的多条第一消息存在消息的积压状态；和/或
在所述生成多个第一订单数据之后，所述方法还包括：
所述第二服务器监控所述多个第一订单数据的第二数据量，若所述第二数据量大于第二预设阈值，则确定所述第一服务器生成的多个第一订单数据存在消息的积压状态；和/或
在所述得到多条第二消息之后，所述方法还包括：
所述第二服务器监控所述多条第二消息的第三数据量，若所述第三数据量大于第三预设阈值，则确定所述第一服务器对所述多个第一订单数据进行标准化处理得到的多条第二消息存在消息的积压状态。
在一种可能的设计中，在所述第一服务器接收第一Kafka实时发送的多条第一消息之后，所述方法还包括：
所述第一服务器对每条所述第一消息添加唯一标识；
所述第一服务器将每条所述第一消息存储至预设数据库的消息表中，每条所述第一消息携带有用于表示消息是否完成的计数标记；
所述第一服务器根据接收每条所述第一消息的顺序，将每条所述第一消息的唯一标识存储至预设数据库的时序表中，所述时序表为所述消息表的二级索引。
在一种可能的设计中，在所述第一服务器对所述多条第一消息进行数据关联之前，所述方法还包括：
所述第二服务器通过所述预设数据库，查询每条所述第一消息携带的所述用于表示消息是否完成的计数标记；
若所述用于表示消息是否完成的计数标记表示消息未完成，则所述第二服务器向所述第一服务器发送数据处理指示信息，所述数据处理指示信息用于指示所述第一服务器对所述多条第一消息进行数据关联。
在一种可能的设计中，在所述第一服务器将所述多条第二消息存储至第二Kafka中之后，所述方法还包括：
所述第一服务器根据所述多条第二消息中包含的用户信息，对所述多条第二消息进行数据关联，生成多个第二订单数据，每个所述第二订单数据中包括属于不同业务的同一用户对应的至少一条第二消息；
所述第一服务器根据每个所述第二订单数据，在所述预设数据库中对每条所述第一消息标记用于表示消息完成的计数标记，并更新所述预设数据库。
在一种可能的设计中，在所述更新所述预设数据库之后，所述方法还包括：
所述第二服务器从更新后的时序表中查询预设时间段内的所有目标标识；
所述第二服务器从更新后的消息表中获取与各个所述目标标识匹配的第一目标消息；
若所述第一目标消息携带的所述用于表示消息是否完成的计数标记表示消息未完成，则所述第二服务器确定所述第一目标消息为丢失数据。
在一种可能的设计中，在所述生成多个第二订单数据之后，所述方法还包括：
所述第二服务器统计所述多个第二订单数据的订单数量以及所述多个第二订单数据对应的业务类型；
所述第二服务器将所述订单数量以及所述业务类型发送至预设网络设备，以使所述预设网络设备根据所述订单数量以及所述业务类型所述多个第二订单数据中的用户进行用户行为分析。
第二方面，本申请实施例提供一种数据处理方法，包括：
监控第一服务器接收到的多条第一消息并存储；
从第二Kafka中读取多条第二消息，所述多条第二消息是由所述第一服务器对所述多条第一消息进行数据关联，生成多个第一订单数据后，所述第一服务器对所述多个第一订单数据进行标准化处理得到的；
将监控得到的所述多条第一消息和所述多条第二消息进行比对，确定所述第一服务器的接入数据和所述第一服务器的落地数据是否一致；
其中，所述接入数据为所述多条第一消息，所述落地数据为所述多条第二消息。
第三方面，本申请实施例提供一种数据处理装置，包括：
第一消息监控模块，用于监控第一服务器接收到的多条第一消息并存储；
第二消息获取模块，用于从第二Kafka中读取多条第二消息，所述多条第二消息是由所述第一服务器对所述多条第一消息进行数据关联，生成多个第一订单数据后，所述第一服务器对所述多个第一订单数据进行标准化处理得到的；
数据监控模块，用于将监控得到的所述多条第一消息和所述多条第二消息进行比对，确定所述第一服务器的接入数据和所述第一服务器的落地数据是否一致；
其中，所述接入数据为所述多条第一消息，所述落地数据为所述多条第二消息。
第四方面，本申请实施例提供一种数据处理设备，包括：至少一个处理器和存储器；
所述存储器存储计算机执行指令；
所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如上第二方面所述的数据处理方法。
第五方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如上第二方面所述的数据处理方法。
本实施例提供的数据处理方法、装置、设备及存储介质，首先第一服务器接收第一Kafka实时发送的多条第一消息，然后所述第一服务器对多条第一消息进行数据处理，具体地，所述第一服务器对所述多条第一消息进行数据关联，生成多个第一订单数据，其中每个所述第一订单数据中包括属于相同业务的同一用户对应的至少一条第一消息，然后第一服务器对所述多个第一订单数据进行标准化处理，得到多条第二消息，且所述第一服务器再将所述多条第二消息存储至第二Kafka中，有效地实现了对消息的数据归集，然后第二服务器将监控得到的所述多条第一消息和所述多条第二消息进行比对，确定所述第一服务器的接入数据和所述第一服务器的落地数据是否一致，实现了消息接入数据与落地数据消息是否平衡的有效监控。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的数据处理系统的场景示意图；
图2为本申请实施例提供的数据处理方法的流程示意图；
图3为本申请另一实施例提供的数据处理方法的流程示意图；
图4为本申请又一实施例提供的数据处理方法的流程示意图；
图5为本申请再一实施例提供的数据处理方法的流程示意图；
图6为本申请又一实施例提供的数据处理方法的流程示意图；
图7为本申请另一实施例提供的数据处理方法的流程示意图；
图8为本申请又一实施例提供的数据处理方法的流程示意图；
图9为本申请实施例提供的数据处理装置的结构示意图；
图10为本申请实施例提供的数据处理设备的结构示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例，例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
为了解决无法有效地实现数据归集，进而无法实现监控消息接入数据与落地数据消息是否平衡的问题，本申请实施例提供一种数据处理方法、装置、设备以及存储介质。
参考图1，图1为本申请实施例提供的数据处理系统的场景示意图。在实际应用中，数据处理系统可以包括第一服务器10和第二服务器20。通过第一服务器对接入数据进行处理，有效地实现数据归集，第二服务器对第一服务器的各个环节中消息量的监控，然后通过第一服务器对落地数据的输出，第二服务器对第一服务器的接入数据和落地数据进行实施监控，确定消息进出是否平衡。
具体地，如何实现对数据处理的，参见图2所示，图2为为本申请实施例提供的数据处理方法的流程示意图。
参见图2，所述数据处理方法，包括：
S101、第一服务器接收第一Kafka实时发送的多条第一消息。
其中，在所述第一服务器接收第一Kafka实时发送的多条第一消息之后，所述方法还包括；
所述第二服务器监控所述多条第一消息的第一数据量，若所述第一数据量大于第一预设阈值，则确定所述第一服务器接收到的第一Kafka实时发送的多条第一消息存在消息的积压状态。
在实际应用中，CBSS端和省份BSS端以及第三方应用端可以提供数据来源，各个端产生的订单，可以作为一条消息，将消息通过第一Kafka的通道对消息进行消费，并将第一Kafka消费的多条第一消息发送至第一服务器，则第一服务器接收第一Kafka实时发送的多条第一消息，用以对第一消息进行数据归集。第二服务器可以实时监控第一服务器在该接收第一消息的环节上是否存在消息量的积压情况，若出现积压情况，则第二服务器可以立即报警，并向维修终端发送第一服务器接收第一Kafka实时发送的多条第一消息产生积压状态的报警信息。
S102、所述第一服务器对所述多条第一消息进行数据关联，生成多个第一订单数据，每个所述第一订单数据中包括属于相同业务的同一用户对应的至少一条第一消息。
其中，在所述生成多个第一订单数据之后，所述方法还包括：
所述第二服务器监控所述多个第一订单数据的第二数据量，若所述第二数据量大于第二预设阈值，则确定所述第一服务器生成的多个第一订单数据存在消息的积压状态。
本实施例中，数据归集将各系统(比如CBSS端和省份BSS端以及第三方应用端)订单数据上收后，根据业务规则进行同一业务订单归并。具体地，第一服务器对所述多条第一消息进行数据关联，针对多条第一消息，将多条第一消息中属于相同业务的同一用户对应的至少一条第一消息进行合并，得到多个第一订单数据。第二服务器可以实时监控第一服务器在对所述多条第一消息进行数据关联生成多个第一订单数据的环节上是否存在消息量的积压情况，若出现积压情况，则第二服务器可以立即报警，并向维修终端发送第一服务器对所述多条第一消息进行数据关联生成的多个第一订单数据产生积压状态的报警信息。
S103、所述第一服务器对所述多个第一订单数据进行标准化处理，得到多条第二消息。
其中，在所述得到多条第二消息之后，所述方法还包括：
所述第二服务器监控所述多条第二消息的第三数据量，若所述第三数据量大于第三预设阈值，则确定所述第一服务器对所述多个第一订单数据进行标准化处理得到的多条第二消息存在消息的积压状态。
本实施例中，由于来源于CBSS端和省份BSS端以及第三方应用端的数据的格式以及数据本身的标识可能不一致。其中，数据本身的标识的标准化：比如，性别男，在CBSS端和省份BSS端可能标示为1，在第三方应用端可能标示为0，在第一服务器对多个第一订单数据进行标准化处理时，将订单数据中出现的性别男统一更新为1或统一更新为0。数据的格式标准化：比如，来源于CBSS端或省份BSS端的某条消息的格式为格式1，而来源于第三方应用端的某条消息的格式为格式2，在第一服务器对多个第一订单数据进行标准化处理时，将订单数据中出现的数据格式统一转换成格式1或统一转换成格式2。第二服务器可以实时监控第一服务器对所述多个第一订单数据进行标准化处理得到的多条第二消息的环节上是否存在消息量的积压情况，若出现积压情况，则第二服务器可以立即报警，并向维修终端发送第一服务器对多个第一订单数据进行标准化处理得到的多条第二消息产生积压状态的报警信息。
S104、所述第一服务器将所述多条第二消息存储至第二Kafka中；
S105、第二服务器将监控得到的所述多条第一消息和所述多条第二消息进行比对，确定所述第一服务器的接入数据和所述第一服务器的落地数据是否一致。
其中，所述接入数据为所述多条第一消息，所述落地数据为所述多条第二消息。
本实施例中，第二服务器可以实时监控第一服务器在各个环节上的处理状态(包括监控消息量的积压情况、监控归并过程中的消息流向，比如消息归并失败后流向及分类与统计)，在第一服务器将所述多条第二消息存储至第二Kafka中时，为了确定消息的接入数据与落地数据消息是否平衡，第二服务器将监控得到的所述多条第一消息和所述多条第二消息进行比对，若多条第一消息和所述多条第二消息一致，这里的一致可以是消息量和消息本身均一致，则说明消息的接入数据与落地数据消息平衡；若不一致，则说明消息的接入数据与落地数据消息不平衡，可能在第一服务器处理消息的某个环节上出现消息遗漏或是同一消息被二次消费的情况，能够及时处理。本实施例能够及时有效地进行数据归集，同时能够实现消息的接入数据与落地数据消息是否平衡的监控。
本实施例中，首先第一服务器接收第一Kafka实时发送的多条第一消息，然后所述第一服务器对多条第一消息进行数据处理，具体地，所述第一服务器对所述多条第一消息进行数据关联，生成多个第一订单数据，其中每个所述第一订单数据中包括属于相同业务的同一用户对应的至少一条第一消息，然后第一服务器对所述多个第一订单数据进行标准化处理，得到多条第二消息，且所述第一服务器再将所述多条第二消息存储至第二Kafka中，有效地实现了对消息的数据归集，然后第二服务器将监控得到的所述多条第一消息和所述多条第二消息进行比对，确定所述第一服务器的接入数据和所述第一服务器的落地数据是否一致，实现了消息接入数据与落地数据消息是否平衡的有效监控。
在实际应用中，第一服务器可以为第二服务器，第二服务器可以为第一服务器，一个服务器处理消息，一个服务器监控处理消息时的各个环节的消息量等。第一服务器或第二服务器每个组件内置redis统计功能，通过自增的方式将数据量写入redis中，其中利用时间分片分别统计各个环节的消息量，比如10分钟等，和大屏展示类似。
为了实现第二服务器对第一服务器在各个环节上处理消息的监控，且防止接入进来的第一消息被第一服务器二次甚至多次处理或消费，第一服务器在处理完一条消息后可以对该条消息进行打标签，然后第二服务器通过监控标签的状态，来确定是否指示第一服务器对该条消息进行处理，参见图3所示，图3为本申请另一实施例提供的数据处理方法的流程示意图。本实施例在上述实施例的基础上，例如，在图2所述实施例的基础上，对数据处理方法进行了详细说明。在所述第一服务器接收第一Kafka实时发送的多条第一消息之后，所述方法还包括：
S201、所述第一服务器对每条所述第一消息添加唯一标识；
S202、所述第一服务器将每条所述第一消息存储至预设数据库的消息表中，每条所述第一消息携带有用于表示消息是否完成的计数标记；
S203、所述第一服务器根据接收每条所述第一消息的顺序，将每条所述第一消息的唯一标识存储至预设数据库的时序表中，所述时序表为所述消息表的二级索引。
在实际应用中，首先需要开启端到端审计功能，开启第二服务器的监控功能，第一服务器对每条接入消息都添加唯一标识，并存储到预设数据库hbase中，其中，存储时，需要记录到两个表中：消息表：用于记录整条消息和是否完成的计数标记；时序表：消息表的二级索引，记录消息表中按接入时间顺序排序的消息的唯一标识。第一服务器对处理完后的消息在hbase上进行标注计数，并更新消息表。比如，消息未处理时标记为0，处理过一次标记为1。
由于时序表为所述消息表的二级索引表，则通过时序表可以查询消息表中具体的消息。因此，在所述第一服务器对所述多条第一消息进行数据关联之前，为了防止消息的重复消费，参见图4所示，图4为本申请又一实施例提供的数据处理方法的流程示意图，本实施例在上述实施例的基础上，例如，在图3所述实施例的基础上，对数据处理方法进行了详细说明。在所述第一服务器对所述多条第一消息进行数据关联之前，所述方法还包括：
S301、所述第二服务器通过所述预设数据库，查询每条所述第一消息携带的所述用于表示消息是否完成的计数标记；
S302、若所述用于表示消息是否完成的计数标记表示消息未完成，则所述第二服务器向所述第一服务器发送数据处理指示信息，所述数据处理指示信息用于指示所述第一服务器对所述多条第一消息进行数据关联。
本实施例中，第二服务器可以在预设数据库中查询每条所述第一消息携带的用于表示消息是否完成的计数标记，消息未完成的计数标记可以为0，消息完成的计数标记可以为1。因此，第二服务器若监控到某条第一消息或第二消息对应的计数标记表示消息未完成0，则说明该第一消息或第二消息未被消费过，可以指示第一服务器对没有消费过的所有消息进行统一处理即第二服务器向所述第一服务器发送数据处理指示信息，用以指示第一服务器对所述多条第一消息进行数据关联。
在第一服务器将所述多条第二消息存储至第二Kafka中之后，第一服务器如何对多条第二消息进行二次归并，使得数据归集后对数据进行统一化管理，参见图5所示，图5为本申请再一实施例提供的数据处理方法的流程示意图，本实施例在上述实施例的基础上，例如，在图4的基础上对数据处理方法进行了详细说明。在所述第一服务器将所述多条第二消息存储至第二Kafka中之后，所述方法还包括：
S401、所述第一服务器根据所述多条第二消息中包含的用户信息，对所述多条第二消息进行数据关联，生成多个第二订单数据，每个所述第二订单数据中包括属于不同业务的同一用户对应的至少一条第二消息；
S402、所述第一服务器根据每个所述第二订单数据，在所述预设数据库中对每条所述第一消息标记用于表示消息完成的计数标记，并更新所述预设数据库。
本实施例中，多条第二消息中可能存在两条或以上第二消息属于同一用户的业务数据，因此，为了实现数据的整合以及实现对业务数据的分析，第一服务器根据所述多条第二消息中包含的用户信息，对所述多条第二消息进行数据关联，比如，将属于不同业务的同一用户对应的至少一条第二消息进行归并，形成多个第二订单数据，其中每个第二订单数据中可能包含至少一条第二消息(第二消息中包含至少一条第一消息)。在生成第二订单数据后，第一服务器对第一消息的处理完成，则第一服务器可以在所述预设数据库中对每条所述第一消息标记用于表示消息完成的计数标记，并更新所述预设数据库。
第二服务器在监控第一服务器在各个环节的消息量时，还可以监控订单归并缺失的情况，或监控归并过程中的消息流向。具体地，参见图6所示，图6为本申请又一实施例提供的数据处理方法的流程示意图，本实施例在上述实施例的基础上，例如，在图5所述实施例的基础上，对数据处理方法进行了详细说明。在所述更新所述预设数据库之后，所述方法还包括：
S501、所述第二服务器从更新后的时序表中查询预设时间段内的所有目标标识；
S502、所述第二服务器从更新后的消息表中获取与各个所述目标标识匹配的第一目标消息；
S503、若所述第一目标消息携带的所述用于表示消息是否完成的计数标记表示消息未完成，则所述第二服务器确定所述第一目标消息为丢失数据。
本实施例中，在更新所述预设数据库之后，第二服务器可以监控第一服务器进行消息处理时是否存在消息丢失或未消费的情况，首先第二服务器从更新后的时序表中查询预设时间段内的所有目标标识，即通过异步扫描时序表前N分钟的唯一标识，根据获取到的唯一标识从消息表获取与唯一标识匹配的数据，如果消息表中存在数据为0(即携带的述用于表示消息是否完成的计数标记为0)，则说明该条数据在流程中丢失，第二服务器可以获取这部分数据做后续处理。比如，第二服务器监控该数据是在第一服务器处理消息的哪个环节丢失的，第二服务器可以将丢失的数据和丢失数据的环节进行上报，实现了监控归并过程中的消息流向，比如消息归并失败后流向。
在所述生成多个第二订单数据之后，如何分析这些第二订单数据，参见图7所示，图7为本申请另一实施例提供的数据处理方法的流程示意图。本实施例在上述实施例的基础上，对数据处理方法进行了详细说明。在所述生成多个第二订单数据之后，所述方法还包括：
S601、所述第二服务器统计所述多个第二订单数据的订单数量以及所述多个第二订单数据对应的业务类型；
S602、所述第二服务器将所述订单数量以及所述业务类型发送至预设网络设备，以使所述预设网络设备根据所述订单数量以及所述业务类型所述多个第二订单数据中的用户进行用户行为分析。
本实施例中，第二服务器可以统计所述多个第二订单数据的订单数量以及所述多个第二订单数据对应的业务类型，并将所述订单数量以及所述业务类型发送至预设网络设备，这里的预设网络设备可以是CBSS端或省份BSS端等等，预设网络设备可以根据所述订单数量以及所述业务类型所述多个第二订单数据中的用户进行用户行为分析，分析哪些业务是影响较大的，哪些业务需要改进的，进一步地满足用户需求。
在实际应用中，通过第一服务器的数据归集将各系统订单数据上收后，根据业务规则进行同一业务订单归并，在此过程中第二服务器需要对各环节的消息量进行统计，从消息的进入到落地消息的数量应该保持平衡，并且第二服务器通过消息量的监控可以监控各环节消息处理是否出现积压、延迟等，如有积压需要及时告警。
此外，为了解决上述问题，本实施例还提供了一种数据处理方法。参见图8，图8为本申请又一实施例提供的数据处理方法的流程示意图；本实施例的执行主体可以为第二服务器，其中所述数据处理方法，包括：
S701、监控第一服务器接收到的多条第一消息并存储；
S702、从第二Kafka中读取多条第二消息，所述多条第二消息是由所述第一服务器对所述多条第一消息进行数据关联，生成多个第一订单数据后，所述第一服务器对所述多个第一订单数据进行标准化处理得到的；
S703、将监控得到的所述多条第一消息和所述多条第二消息进行比对，确定所述第一服务器的接入数据和所述第一服务器的落地数据是否一致；其中，所述接入数据为所述多条第一消息，所述落地数据为所述多条第二消息。
本实施例中，第二服务器通过监控第一服务器接收到的多条第一消息并存储，同时可以监控由所述第一服务器对所述多条第一消息进行数据关联，生成多个第一订单数据后，所述第一服务器对所述多个第一订单数据进行标准化处理得到的多条第二消息，然后通过将监控得到的所述多条第一消息和所述多条第二消息进行比对，确定所述第一服务器的接入数据和所述第一服务器的落地数据是否一致，实现了消息接入数据与落地数据消息是否平衡的有效监控。
在一种可能的设计中，所述监控第一服务器接收到的多条第一消息，包括：监控所述多条第一消息的第一数据量，若所述第一数据量大于第一预设阈值，则确定所述第一服务器接收到的第一Kafka实时发送的多条第一消息存在消息的积压状态。
在一种可能的设计中，在所述从第二Kafka中读取多条第二消息之前，所述方法还包括：在所述第一服务器生成多个第一订单数据之后，监控所述多个第一订单数据的第二数据量，若所述第二数据量大于第二预设阈值，则确定所述第一服务器生成的多个第一订单数据存在消息的积压状态。
在一种可能的设计中，在所述从第二Kafka中读取多条第二消息之后，所述方法还包括：监控所述多条第二消息的第三数据量，若所述第三数据量大于第三预设阈值，则确定所述第一服务器对所述多个第一订单数据进行标准化处理得到的多条第二消息存在消息的积压状态。
在一种可能的设计中，所述监控第一服务器接收到的多条第一消息，还包括：通过所述预设数据库查询每条所述第一消息携带的所述用于表示消息是否完成的计数标记，若所述用于表示消息是否完成的计数标记表示消息未完成，则向所述第一服务器发送数据处理指示信息，所述数据处理指示信息用于指示所述第一服务器对所述多条第一消息进行数据关联；其中，预设数据库包括消息表和时序表，消息表中存储有每条第一消息以及每条所述第一消息携带的用于表示消息是否完成的计数标记，时序表中存储有第一服务器在接收到第一Kafka实时发送的多条第一消息之后对每条所述第一消息添加的唯一标识；所述时序表为所述消息表的二级索引，是按第一服务器根据接收每条所述第一消息的顺序存储的。
在一种可能的设计中，在所述从第二Kafka中读取多条第二消息之后，所述方法还包括：
从更新后的时序表中查询预设时间段内的所有目标标识；从更新后的消息表中获取与各个所述目标标识匹配的第一目标消息；若所述第一目标消息携带的所述用于表示消息是否完成的计数标记表示消息未完成，则确定所述第一目标消息为丢失数据；其中，更新后的时序表和更新后的消息表形成更新后的数据库中，所述更新后的数据库是由第一服务器通过所述多条第二消息中包含的用户信息对所述多条第二消息进行数据关联生成的多个第二订单数据时，在所述预设数据库中对每条所述第一消息标记用于表示消息完成的计数标记后更新预设数据库得到的；其中每个所述第二订单数据中包括属于不同业务的同一用户对应的至少一条第二消息。
在一种可能的设计中，在所述从第二Kafka中读取多条第二消息之后，所述方法还包括：统计所述多个第二订单数据的订单数量以及所述多个第二订单数据对应的业务类型；将所述订单数量以及所述业务类型发送至预设网络设备，以使所述预设网络设备根据所述订单数量以及所述业务类型所述多个第二订单数据中的用户进行用户行为分析。
为了实现所述数据处理方法，本实施例提供了一种数据处理装置。参见图9，图9为本申请实施例提供的数据处理装置的结构示意图；所述数据处理装置90，包括：第一消息监控模块901、第二消息获取模块902以及数据监控模块903；第一消息监控模块901，用于监控第一服务器接收到的多条第一消息并存储；第二消息获取模块902，用于从第二Kafka中读取多条第二消息，所述多条第二消息是由所述第一服务器对所述多条第一消息进行数据关联，生成多个第一订单数据后，所述第一服务器对所述多个第一订单数据进行标准化处理得到的；数据监控模块903，用于将监控得到的所述多条第一消息和所述多条第二消息进行比对，确定所述第一服务器的接入数据和所述第一服务器的落地数据是否一致；其中，所述接入数据为所述多条第一消息，所述落地数据为所述多条第二消息。
本实施例通过设置第一消息监控模块901、第二消息获取模块902以及数据监控模块903，用于通过监控第一服务器接收到的多条第一消息并存储，同时可以监控由所述第一服务器对所述多条第一消息进行数据关联，生成多个第一订单数据后，所述第一服务器对所述多个第一订单数据进行标准化处理得到的多条第二消息，然后通过将监控得到的所述多条第一消息和所述多条第二消息进行比对，确定所述第一服务器的接入数据和所述第一服务器的落地数据是否一致，实现了消息接入数据与落地数据消息是否平衡的有效监控。
本实施例提供的装置，可用于执行上述方法实施例的技术方案，其实现原理和技术效果类似，本实施例此处不再赘述。
在一种可能的设计中，第一消息监控模块901，具体用于：监控所述多条第一消息的第一数据量，若所述第一数据量大于第一预设阈值，则确定所述第一服务器接收到的第一Kafka实时发送的多条第一消息存在消息的积压状态。
在一种可能的设计中，所述装置还包括：第一订单数据监控模块，用于在所述从第二Kafka中读取多条第二消息之前，且在所述第一服务器生成多个第一订单数据之后，监控所述多个第一订单数据的第二数据量，若所述第二数据量大于第二预设阈值，则确定所述第一服务器生成的多个第一订单数据存在消息的积压状态。
在一种可能的设计中，所述装置还包括：第二消息监控模块，用于在所述从第二Kafka中读取多条第二消息之后，监控所述多条第二消息的第三数据量，若所述第三数据量大于第三预设阈值，则确定所述第一服务器对所述多个第一订单数据进行标准化处理得到的多条第二消息存在消息的积压状态。
在一种可能的设计中，第一消息监控模块，还具体用于：通过所述预设数据库查询每条所述第一消息携带的所述用于表示消息是否完成的计数标记，若所述用于表示消息是否完成的计数标记表示消息未完成，则向所述第一服务器发送数据处理指示信息，所述数据处理指示信息用于指示所述第一服务器对所述多条第一消息进行数据关联；其中，预设数据库包括消息表和时序表，消息表中存储有每条第一消息以及每条所述第一消息携带的用于表示消息是否完成的计数标记，时序表中存储有第一服务器在接收到第一Kafka实时发送的多条第一消息之后对每条所述第一消息添加的唯一标识；所述时序表为所述消息表的二级索引，是按第一服务器根据接收每条所述第一消息的顺序存储的。
在一种可能的设计中，所述装置还包括：第一处理模块，用于在所述从第二Kafka中读取多条第二消息之后，从更新后的时序表中查询预设时间段内的所有目标标识；从更新后的消息表中获取与各个所述目标标识匹配的第一目标消息；若所述第一目标消息携带的所述用于表示消息是否完成的计数标记表示消息未完成，则确定所述第一目标消息为丢失数据；其中，更新后的时序表和更新后的消息表形成更新后的数据库中，所述更新后的数据库是由第一服务器通过所述多条第二消息中包含的用户信息对所述多条第二消息进行数据关联生成的多个第二订单数据时，在所述预设数据库中对每条所述第一消息标记用于表示消息完成的计数标记后更新预设数据库得到的；其中每个所述第二订单数据中包括属于不同业务的同一用户对应的至少一条第二消息。
在一种可能的设计中，所述装置还包括：第二处理模块，用于在所述从第二Kafka中读取多条第二消息之后，统计所述多个第二订单数据的订单数量以及所述多个第二订单数据对应的业务类型；将所述订单数量以及所述业务类型发送至预设网络设备，以使所述预设网络设备根据所述订单数量以及所述业务类型所述多个第二订单数据中的用户进行用户行为分析。
为了实现所述数据处理方法，本实施例提供了一种数据处理设备。图10为本申请实施例提供的数据处理设备的结构示意图。如图10所示，本实施例的数据处理设备100包括：处理器1001以及存储器1002；其中，存储器1002，用于存储计算机执行指令；处理器1001，用于执行存储器存储的计算机执行指令，以实现上述实施例中所执行的各个步骤。具体可以参见图8所述方法实施例中的相关描述。
本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如上图8所述的数据处理方法。
在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。例如，以上所描述的设备实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。另外，在本申请各个实施例中的各功能模块可以集成在一个处理单元中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个单元中。上述模块成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
上述以软件功能模块的形式实现的集成的模块，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(英文：processor)执行本申请各个实施例所述方法的部分步骤。应理解，上述处理器可以是中央处理单元(英文：Central Processing Unit，简称：CPU)，还可以是其他通用处理器、数字信号处理器(英文：Digital Signal Processor，简称：DSP)、专用集成电路(英文：Application SpecificIntegrated Circuit，简称：ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合发明所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。
存储器可能包含高速RAM存储器，也可能还包括非易失性存储NVM，例如至少一个磁盘存储器，还可以为U盘、移动硬盘、只读存储器、磁盘或光盘等。总线可以是工业标准体系结构(Industry Standard Architecture，ISA)总线、外部设备互连(PeripheralComponent，PCI)总线或扩展工业标准体系结构(Extended Industry StandardArchitecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本申请附图中的总线并不限定仅有一根总线或一种类型的总线。上述存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。存储介质可以是通用或专用计算机能够存取的任何可用介质。
一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于专用集成电路(Application Specific Integrated Circuits，简称：ASIC)中。当然，处理器和存储介质也可以作为分立组件存在于电子设备或主控设备中。
本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (11)

1.一种数据处理方法，其特征在于，包括：
第一服务器接收第一Kafka实时发送的多条第一消息；
所述第一服务器对所述多条第一消息进行数据关联，生成多个第一订单数据，每个所述第一订单数据中包括属于相同业务的同一用户对应的至少一条第一消息；
所述第一服务器对所述多个第一订单数据进行标准化处理，得到多条第二消息；
所述第一服务器将所述多条第二消息存储至第二Kafka中；
第二服务器将监控得到的所述多条第一消息和所述多条第二消息进行比对，确定所述第一服务器的接入数据和所述第一服务器的落地数据是否一致；
其中，所述接入数据为所述多条第一消息，所述落地数据为所述多条第二消息。
2.根据权利要求1所述的方法，其特征在于，在所述第一服务器接收第一Kafka实时发送的多条第一消息之后，所述方法还包括；
所述第二服务器监控所述多条第一消息的第一数据量，若所述第一数据量大于第一预设阈值，则确定所述第一服务器接收到的第一Kafka实时发送的多条第一消息存在消息的积压状态；和/或
在所述生成多个第一订单数据之后，所述方法还包括：
所述第二服务器监控所述多个第一订单数据的第二数据量，若所述第二数据量大于第二预设阈值，则确定所述第一服务器生成的多个第一订单数据存在消息的积压状态；和/或
在所述得到多条第二消息之后，所述方法还包括：
所述第二服务器监控所述多条第二消息的第三数据量，若所述第三数据量大于第三预设阈值，则确定所述第一服务器对所述多个第一订单数据进行标准化处理得到的多条第二消息存在消息的积压状态。
3.根据权利要求1所述的方法，其特征在于，在所述第一服务器接收第一Kafka实时发送的多条第一消息之后，所述方法还包括：
所述第一服务器对每条所述第一消息添加唯一标识；
所述第一服务器将每条所述第一消息存储至预设数据库的消息表中，每条所述第一消息携带有用于表示消息是否完成的计数标记；
所述第一服务器根据接收每条所述第一消息的顺序，将每条所述第一消息的唯一标识存储至预设数据库的时序表中，所述时序表为所述消息表的二级索引。
4.根据权利要求3所述的方法，其特征在于，在所述第一服务器对所述多条第一消息进行数据关联之前，所述方法还包括：
所述第二服务器通过所述预设数据库，查询每条所述第一消息携带的所述用于表示消息是否完成的计数标记；
若所述用于表示消息是否完成的计数标记表示消息未完成，则所述第二服务器向所述第一服务器发送数据处理指示信息，所述数据处理指示信息用于指示所述第一服务器对所述多条第一消息进行数据关联。
5.根据权利要求4所述的方法，其特征在于，在所述第一服务器将所述多条第二消息存储至第二Kafka中之后，所述方法还包括：
所述第一服务器根据所述多条第二消息中包含的用户信息，对所述多条第二消息进行数据关联，生成多个第二订单数据，每个所述第二订单数据中包括属于不同业务的同一用户对应的至少一条第二消息；
所述第一服务器根据每个所述第二订单数据，在所述预设数据库中对每条所述第一消息标记用于表示消息完成的计数标记，并更新所述预设数据库。
6.根据权利要求5所述的方法，其特征在于，在所述更新所述预设数据库之后，所述方法还包括：
所述第二服务器从更新后的时序表中查询预设时间段内的所有目标标识；
所述第二服务器从更新后的消息表中获取与各个所述目标标识匹配的第一目标消息；
若所述第一目标消息携带的所述用于表示消息是否完成的计数标记表示消息未完成，则所述第二服务器确定所述第一目标消息为丢失数据。
7.根据权利要求5或6所述的方法，其特征在于，在所述生成多个第二订单数据之后，所述方法还包括：
所述第二服务器统计所述多个第二订单数据的订单数量以及所述多个第二订单数据对应的业务类型；
所述第二服务器将所述订单数量以及所述业务类型发送至预设网络设备，以使所述预设网络设备根据所述订单数量以及所述业务类型所述多个第二订单数据中的用户进行用户行为分析。
8.一种数据处理方法，其特征在于，包括：
监控第一服务器接收到的多条第一消息并存储；
从第二Kafka中读取多条第二消息，所述多条第二消息是由所述第一服务器对所述多条第一消息进行数据关联，生成多个第一订单数据后，所述第一服务器对所述多个第一订单数据进行标准化处理得到的；
将监控得到的所述多条第一消息和所述多条第二消息进行比对，确定所述第一服务器的接入数据和所述第一服务器的落地数据是否一致；
其中，所述接入数据为所述多条第一消息，所述落地数据为所述多条第二消息。
9.一种数据处理装置，其特征在于，包括：
第一消息监控模块，用于监控第一服务器接收到的多条第一消息并存储；
第二消息获取模块，用于从第二Kafka中读取多条第二消息，所述多条第二消息是由所述第一服务器对所述多条第一消息进行数据关联，生成多个第一订单数据后，所述第一服务器对所述多个第一订单数据进行标准化处理得到的；
数据监控模块，用于将监控得到的所述多条第一消息和所述多条第二消息进行比对，确定所述第一服务器的接入数据和所述第一服务器的落地数据是否一致；
其中，所述接入数据为所述多条第一消息，所述落地数据为所述多条第二消息。
10.一种数据处理设备，其特征在于，包括：至少一个处理器和存储器；
所述存储器存储计算机执行指令；
所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如权利要求8所述的数据处理方法。
11.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如权利要求8所述的数据处理方法。
CN202010661383.2A 2020-07-10 2020-07-10 数据处理方法、装置、设备及存储介质 Active CN111835847B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010661383.2A CN111835847B (zh) 2020-07-10 2020-07-10 数据处理方法、装置、设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010661383.2A CN111835847B (zh) 2020-07-10 2020-07-10 数据处理方法、装置、设备及存储介质

Publications (2)

Publication Number Publication Date
CN111835847A true CN111835847A (zh) 2020-10-27
CN111835847B CN111835847B (zh) 2021-12-14

Family

ID=72900847

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010661383.2A Active CN111835847B (zh) 2020-07-10 2020-07-10 数据处理方法、装置、设备及存储介质

Country Status (1)

Country Link
CN (1) CN111835847B (zh)

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106055613A (zh) * 2016-05-26 2016-10-26 华东理工大学 一种基于混合范数的数据分类训练数据库清洗方法
CN106874327A (zh) * 2016-07-08 2017-06-20 阿里巴巴集团控股有限公司 一种针对业务数据的计数方法及装置
CN108234199A (zh) * 2017-12-20 2018-06-29 中国联合网络通信集团有限公司 基于Kafka的监控方法、装置及系统
CN109299183A (zh) * 2018-11-20 2019-02-01 北京锐安科技有限公司 一种数据处理方法、装置、终端设备和存储介质
CN110147470A (zh) * 2019-05-22 2019-08-20 武汉市公安局 一种跨机房数据比对系统及方法
US10536536B1 (en) * 2016-11-15 2020-01-14 State Farm Mutual Automobile Insurance Company Resource discovery agent computing device, software application, and method
CN110750562A (zh) * 2018-07-20 2020-02-04 武汉烽火众智智慧之星科技有限公司 基于Storm的实时数据比对预警方法及系统
CN110941525A (zh) * 2019-10-28 2020-03-31 苏宁云计算有限公司 一种数据积压预警方法及装置
CN110955390A (zh) * 2019-11-22 2020-04-03 北京达佳互联信息技术有限公司 数据处理方法、装置和电子设备
CN111078776A (zh) * 2019-12-10 2020-04-28 北京明略软件系统有限公司 数据表的标准化方法、装置、设备及存储介质

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106055613A (zh) * 2016-05-26 2016-10-26 华东理工大学 一种基于混合范数的数据分类训练数据库清洗方法
CN106874327A (zh) * 2016-07-08 2017-06-20 阿里巴巴集团控股有限公司 一种针对业务数据的计数方法及装置
US10536536B1 (en) * 2016-11-15 2020-01-14 State Farm Mutual Automobile Insurance Company Resource discovery agent computing device, software application, and method
CN108234199A (zh) * 2017-12-20 2018-06-29 中国联合网络通信集团有限公司 基于Kafka的监控方法、装置及系统
CN110750562A (zh) * 2018-07-20 2020-02-04 武汉烽火众智智慧之星科技有限公司 基于Storm的实时数据比对预警方法及系统
CN109299183A (zh) * 2018-11-20 2019-02-01 北京锐安科技有限公司 一种数据处理方法、装置、终端设备和存储介质
CN110147470A (zh) * 2019-05-22 2019-08-20 武汉市公安局 一种跨机房数据比对系统及方法
CN110941525A (zh) * 2019-10-28 2020-03-31 苏宁云计算有限公司 一种数据积压预警方法及装置
CN110955390A (zh) * 2019-11-22 2020-04-03 北京达佳互联信息技术有限公司 数据处理方法、装置和电子设备
CN111078776A (zh) * 2019-12-10 2020-04-28 北京明略软件系统有限公司 数据表的标准化方法、装置、设备及存储介质

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
" "FMC100016a1"", 《3GPP WORKSHOP\2010-02-18_FMC_BBF》 *
赵飞等: "元数据的数据解析技术及在卫星设计中的应用", 《航天器工程》 *

Also Published As

Publication number Publication date
CN111835847B (zh) 2021-12-14

Similar Documents

Publication Publication Date Title
CN110362455B (zh) 一种数据处理方法和数据处理装置
CN112311617A (zh) 一种配置化数据监控告警方法及系统
CN110335022B (zh) 自动稽核方法、装置、设备及存储介质
CN111371672B (zh) 消息推送方法及装置
CN109670091B (zh) 一种基于数据标准的元数据智能维护方法和装置
CN113157659A (zh) 一种日志处理方法和装置
CN110807050B (zh) 性能分析方法、装置、计算机设备及存储介质
CN113609409B (zh) 一种推荐浏览信息的方法及其系统、电子设备、存储介质
CN112395370B (zh) 一种数据处理方法、装置、设备和存储介质
CN111835847B (zh) 数据处理方法、装置、设备及存储介质
CN115994830A (zh) 取数模型的构建方法和数据归集方法及相关装置
CN115878707A (zh) 一种外汇行情数据处理方法、装置、存储介质及设备
CN113452533B (zh) 计费自巡检、自愈合方法、装置、计算机设备和存储介质
CN114996080A (zh) 数据处理方法、装置、设备及存储介质
JPWO2018122889A1 (ja) 異常検出方法、システムおよびプログラム
CN108629610B (zh) 推广信息曝光量的确定方法和装置
CN113342861B (zh) 业务场景下数据治理方法及装置
CN115604668B (zh) 短信发送和推送监控方法、装置、设备及存储介质
CN111222897B (zh) 基于客户上网满意度预测方法及装置
CN114841507A (zh) 一种物资质量检测管理系统
CN116719850A (zh) 流式数据处理方法、装置、设备及存储介质
CN115687313A (zh) 成本数据补全方法、设备和存储介质
CN115391374A (zh) 数据匹配方法、装置、电子设备及存储介质
CN117033142A (zh) 用户存储空间的计算方法、装置、物联网平台及介质
CN114546700A (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