一种业务数据分析方法、数据处理方法、数据分析系统和存储介质

技术领域

本申请涉及数据仓库技术，尤其是一种订单数据分析系统、方法和存储介质。

背景技术

随着互联网线上业务的快速发展，线上产品设计、界面优化和精准营销，提高用户的使用体验，需要基于业务方的需求输出某些指标数据，用于作为业务调整的决策参考。

例如在线教育产品业务场景下，需要通过用户对业务产品的反馈、和用户行为作为模型计算的输入，得到相关的数据指标。例如，某老师的授课转化率、续报率，某种课程产品的续保率等。通常以用户订单作为切入点，从订单明细中关联一些老师或者学生的维度数据，再经过统计分析得到相应的用于指导业务的指标。

发明内容

本申请提供一种业务数据分析方法。包括：

获取目标信息查询请求；

根据所述目标信息查询请求获得业务数据的处理逻辑，以及与所述处理逻辑相关的业务数据在分布式存储系统中的存储区域；

分别获得所述存储区域中的全部业务数据，所述业务数据具有业务标识；

根据所述处理逻辑以及业务数据的业务标识对业务数据进行处理，获得目标信息。

上述方法还包括：按照预置的策略将具有相同业务标识的业务数据存储于所述分布式存储系统中同一个存储区域。

上述方法还包括分别获得历史业务数据和实时业务数据。具体的，获得实时业务数据，并发送给所述分布式存储系统进行存储；以及，获得实时业务数据前，获得存储于数据仓库的历史业务数据，并发送给所述分布式存储系统。

上述方法中，所述处理逻辑根据所述业务标识对业务数据进行处理前还包括：利用处理逻辑中的业务标识对所述处理逻辑是否正确进行校验。

上述方法的一种实现方式为，利用Flink执行所述处理逻辑，根据所述业务标识对业务数据进行处理；以及，将具有相同业务标识的处理结果写入所述分布式存储系统的同一个存储区域。

上述方法中，将具有相同业务标识的处理结果写入所述分布式存储系统的同一个存储区域后还包括：所述分布式存储系统将所述运算结果输出到MySQL或Doris数据库；所述MySQL或Doris数据库作为输出单元展现运算结果，并输出所查询的目标信息。

一种业务数据处理方法，包括：获取业务数据，获得所述业务数据的业务标识；将具有相同业务标识的业务数据写入分布式存储系统中同一个存储区域。

其中，所述分布式存储系统为Kafka。

上述方法中，获取业务数据的方法包括：利用Canal获得实时业务数据；

或/和，利用Flink对存储于Kafka的第一层业务数据进行运算得到第二层业务数据；以及将具有相同业务标识的第二层业务数据写入Kafka中同一个存储区域。

上述方法中，所述获得业务数据的业务标识，将具有相同业务标识的业务数据写入Kafka同一个存储区域包括：根据预置的映射表中对业务标识的定义，从所获得的业务数据包中获得所述业务标识；按照预置的策略对所述业务标识进行分区运算，根据分区运算结果将业务数据写入Kafka的对应存储区域。

上述方法还包括：在满足预置条件时，在存储了具有相同业务标识的两个以上业务数据时，保留其中最新获得的业务数据，删除其余的业务数据。

一种业务数据分析系统，包括：

接收单元，获取目标信息查询请求；

分布式存储系统，用于存储业务数据，且具有相同业务标识的业务数据存储于分布式存储系统中的同一个存储区域；

处理单元，根据所述目标信息查询请求获得业务数据的处理逻辑，以及与所述处理逻辑相关的业务数据在分布式存储系统中的存储区域；获得所述存储区域中的全部业务数据，执行所述处理逻辑根据所述业务标识对业务数据进行处理，得到所述目标信息。

其中，所述分布式存储系统为Kafka；

以及还包括：增量数据订阅模块，用于同步用户的实时业务数据至Kafka；所述Kafka，将具有相同业务标识的业务数据存储于同一个存储区域。

其中，所述处理单元为Flink；

所述Flink，根据目标信息查询请求获得Kafka中存储的第一层业务数据并执行所述处理逻辑得到第二业务数据，将具有相同业务标识的第二层业务数据写入到Kafka同一个存储区域。

所述系统还包括：历史业务数据库，用于保存历史业务数据；

Kafka，获得历史业务数据后，获得所述增量数据订阅模块同步的实时业务数据。

上述系统中，包括多个Flink；所述多个Flink串联用于执行分层计算。

上述系统还包括：MySQL或Doris数据库；所述Kafka将Flink运算结果写入所述MySQL或Doris数据库。

上述系统还包括校验单元，利用处理逻辑中的业务标识对所述处理逻辑是否正确进行校验。

上述数据分析方法、数据处理方法以及系统中，所述业务标识包括但不限于以下一种标识或者两种以上标识的组合：订单号、班课ID、老师ID、用户ID、学期ID、课程项目ID。

一种非暂时性机器可读存储介质，其上存储有可执行代码，当所述可执行代码被计算设备的处理器执行时，使所述处理器执行如上所述的方法。

由于业务状态实时变化，本发明为了获得业务指标，从而采用流数据处理的方法，以实时业务数据作为输入，得到业务所需的业务指标。尤其本发明实施例基于Kafka和Flink的对实时数据流处理的机制计算并输出所述业务指标。

采用对业务状态变化的跟踪实现对业务侧的分析，得到面向销售端的业务转化率、续单率等指标。现实中，对于一个业务而言，其状态存在变化的可能，例如对于一个订单，包括用户下单、撤回订单、订单后支付等行为均导致订单数据状态的变化，订单状态的变化将直接影响后续对相关业务的分析。

因此本发明提供的业务数据分析方法、业务数据处理方法。

首先，为了业务分析的需要，本发明获得业务全量历史数据，进而通过对业务增量数据监听的方式获得业务的状态变化数据。从而在数据获取方式上满足了对业务分析的数据需求。

其次，本发明提供的业务数据分析方法和系统采用Kafka分布式存储系统，并采用Flink流式处理对分布式系统，实现对实时数据及时高效的处理分析。

最后，基于本发明分布式结构的特点，为了得到准确的业务数据状态的变化，保证分布式消息系统中存储的业务数据的时序性不发生混乱，将业务数据的业务标识作为Kafka存储表的主键，其中每个业务数据具有唯一的业务标识。进一步，所述主键作为分配策略的变量进行分区计算，决定业务数据应当被分配的存储区域。从而能够将具有相同主键的业务数据进入到Kafka分布式系统的相同的存储区域，避免相同订单数据被存储到不同的存储区域出现时序发生混乱的情况，保证对订单数据处理的顺序与用户对订单操作的顺序相一致。

综上，采用本发明的链路结构和数据分析方法对订单业务的分析更加准确可靠。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

通过结合附图对本申请示例性实施方式进行更详细的描述，本申请的上述以及其它目的、特征和优势将变得更加明显，其中，在本申请示例性实施方式中，相同的参考标号通常代表相同部件。

图1是本发明一个实施例示出的链路结构示意图；

图2是现有技术flink计算时产生实时数据时序性偏差的示意图。

具体实施方式

下面将参照附图更详细地描述本申请的优选实施方式。虽然附图中显示了本申请的优选实施方式，然而应该理解，可以以各种形式实现本申请而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了使本申请更加透彻和完整，并且能够将本申请的范围完整地传达给本领域的技术人员。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语“第一”、“第二”、“第三”等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本申请的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

本发明目的在于获得一个或多个在线产品的某些业务指标。

以下以在线教育产品为例对本发明实施方式进行说明。

以在线教育服务行业为例，在线课程的订购一定程度上受到服务提供者的教学能力、课程设计的连续性等方面十分相关。因此需要通过对课程订单状态分析以及订单状态变化的分析反映相关课程设计的合理性等问题，以指导业务的改进。所需的分析指标例如包括：业务转化率，课程续单率等。

现实中，在线产品的业务状态会发生变化，从而顺序的产生一系列的业务数据。例如，在线课程订单业务中，当创建了初始订单数据后，其状态往往存在变化，例如用户下单、撤回订单、订单后支付等行为，这些行为均可导致订单数据状态的变化，订单数据状态的变化将直接影响后续对相关业务的分析。除订单数据外，还包括用户数据、老师数据、班课数据、学期数据等。

本发明提供了一种业务数据分析方法、一种业务数据处理方法、一种业务数据分析系统。利用本发明能够更好符合订单业务场景的需求。

本申请提供一种订单数据分析方法。包括：

步骤11：获取业务需求，即目标信息查询请求，例如对某些业务指标的查询请求，业务指标可以为某老师的当前订单数量、老师的续课率等；

步骤12：根据所述目标信息查询请求获得业务数据的处理逻辑，以及与所述处理逻辑相关的业务数据在分布式存储系统中的存储区域；

根据目标信息查询请求，获得相应的业务处理逻辑，在处理逻辑中记载逻辑计算方法以及实现逻辑计算的数据源，进而通过该处理逻辑中描述的数据源，能够得到执行该处理逻辑所需数据的存储地址。

步骤13：分别获得所述存储区域中的全部业务数据，所述业务数据具有业务标识。

实现处理逻辑所需的业务数据可能被存储在分布式存储系统的多个区域中，分别获得这些存储区域中的全部业务数据。

本发明实施例中，业务数据存储于分布式存储系统；以及，按照预先的定义，每个业务数据均有唯一的业务标识；以及，根据预置的策略，以所述业务标识作为变量运算可以确定相关业务数据被分配的分布式存储系统中的存储区域。根据本方法，具有相同业务标识的业务数据存储于所述分布式存储系统中同一个存储区域。

步骤14：根据所述处理逻辑以及业务数据的业务标识对业务数据进行处理，获得目标信息。

利用分布式逻辑处理引擎实现处理逻辑，分别对于每个存储区域获得的全部数据进行逻辑处理，所述处理逻辑中利用到业务数据的业务标识，根据业务标识对业务数据进行处理。例如，基于业务标识，判断业务数据是否对应于同一个订单，从而对同一个订单的数据进行筛选、订单状态变化分析等。

上述方法中，分布式存储系统中存储的业务数据包括实时业务数据和历史业务数据。

例如，利用Canal从MySQL数据库中获得实时业务数据，并将该实时业务数据发送给所述分布式存储系统进行存储。所述实时业务数据可以是订单的增量数据，例如基于用户行为生成了订单、取消订单、支付订单等，或者老师个人信息的变更、老师岗位变化，或者针对课程的上课时间变化、课程时长的变化等都将产生所述的实时业务数据；

在获得实时业务数据前，可以先导入存储于数据仓库的历史业务数据，并发送给所述分布式存储系统。

所述Canal主要用途是基于MySQL数据库增量日志解析，提供增量数据订阅和消费。

作为较优的实现方式，所述分布式存储系统可以为Kafka。

Kafka为分布式发布订阅消息系统，是一种高吞吐量分布式发布订阅消息系统，处理消费者在网站中的所有动作流数据。

上述方法中，可以采用Flink执行所述处理逻辑。

Flink是面向分布式数据流处理和批量数据处理的分布式处理引擎，提供支持流处理和批处理两种类型应用的功能。在Flink框架当中，所有的任务当成流来处理，因此实现了更低延迟的实时流处理。

利用Flink对存储于所述分布式存储系统的业务数据执行逻辑运算；对于Flink的运算结果得到的业务数据，通过定义业务数据的业务标识，将该业务标识作为预置策略的变量，决定业务数据在Kafka中的存储区域。采用本方法，能够将具有相同业务标识的运算结果写入所述分布式存储系统的同一个存储区域。

在较佳的实施例中，在Flink执行处理逻辑运算前，还可以对处理逻辑是否正确进行校验。

对于确定的处理逻辑，预先定义处理逻辑得到的业务数据保存到Kafka应采用的业务标识，以保证完成处理逻辑运算后，所得到的业务数据能够正确的存储，以实现业务需求。

在Flink执行处理逻辑运算前，如果判断处理逻辑中采用了Kafka存储该逻辑处理结果数据的业务标识，则表明业务逻辑正确；如果Kafka存储该逻辑处理结果数据所依据的业务标识不包含计算逻辑中计算依据的键，则表明该处理逻辑不正确。

所述方法还包括：所述分布式存储系统将所述运算结果输出到MySQL或Doris数据库。所述MySQL或Doris数据库作为输出单元展现运算结果，以响应业务需求，输出所查询的目标信息。当所述计算结果为Flink多层计算的中间结果时，MySQL或Doris数据库可以作为工具对Flink的计算结果进行校验，例如与上一层Flink计算结果进行对比，或者输出进行人为校验。

本发明实施例还提供一种业务数据处理方法，包括：

获取业务数据，

获得所述业务数据的业务标识；

将具有相同业务标识的业务数据写入分布式存储系统中同一个存储区域。

作为一种实现方式，所述分布式存储系统为Kafka，然而本发明并不限制其他分布式存储系统应用于本发明。

本实施例中，获取业务数据的途径至少包含以下两种：

利用Canal获得实时业务数据；例如通过Canal监听MySQL数据库得到实时业务数据；

利用Flink对已存储于Kafka的业务数据(此处称作第一层业务数据)进行处理逻辑的运算，基于Flink的运算，例如join、group by等运算得到的业务数据(此处称作第二层业务数据)；即第二层业务数据由第一层业务数据通过相关运算得到，进而，根据第二层业务数据的业务标识按照预置的策略进行分区计算决定第二层业务数据的存储区域，Kafka按照分区计算结果对所述第二层业务数据进行保存。通过本方法，能够将具有相同业务标识的第二层业务数据写入Kafka中同一个存储区域。

以上第一层与第二层的描述表明两层数据间的关系，并非指Flink运算只能进行一次运算。将Flink运算模块串联，可以执行多层计算。例如，在上文实施例基础上，Flink继续利用第二层业务数据，通过执行处理逻辑的运算得到第三层业务数据，并将具有相同业务标识的第三层业务数据存储到Kafka的同一个存储区域。

本方法实施例中，所述的将具有相同业务标识的业务数据写入Kafka同一个存储区域的方法包括：预置有映射表，所述映射表中保存有业务标识的定义，根据该定义能够从获得的业务数据包中得到业务标识，例如定义业务数据包中的某个字段，或者某几个字段的组合作为业务标识；

将业务标识参与预置策略的运算，即分区运算，经过分区运算得到业务数据应当被分配到Kafka的哪个存储区域，从而根据分区运算结果，将业务数据写入Kafka的对应存储区域。

本发明实施例的业务数据处理方法，还包括对存储区域的数据进行压缩。所述数据压缩基于业务标识进行，具体的，在满足预置条件时，在存储了具有相同业务标识的两个以上业务数据时，保留其中最新获得的业务数据，删除其余的业务数据。

相应的，本发明实施例还提供了一种业务数据分析系统，包括：

接收单元，获取目标信息查询请求；

分布式存储系统，用于存储业务数据，且具有相同业务标识的业务数据存储于分布式存储系统中的同一个存储区域；

处理单元，根据所述目标信息查询请求获得业务数据的处理逻辑，以及与所述处理逻辑相关的业务数据在分布式存储系统中的存储区域；获得所述存储区域中的全部业务数据，执行所述处理逻辑根据所述业务标识对业务数据进行处理，得到所述目标信息。

其中，优选的，所述分布式存储系统为Kafka；

以及还包括：增量数据订阅模块，用于同步用户的实时业务数据至Kafka；所述Kafka，将具有相同业务标识的业务数据存储于同一个存储区域。

其中，优选的，所述处理单元为Flink；所述Flink，根据目标信息查询请求获得Kafka中存储的第一层业务数据并进行执行处理逻辑得到第二业务数据，将具有相同业务标识的第二层业务数据写入到Kafka同一个存储区域。

所述系统还包括：历史业务数据库，用于保存历史业务数据；Kafka，获得历史业务数据后，获得所述增量数据订阅模块同步的实时业务数据。

本发明系统实施例中，可能包括多个Flink，所述多个Flink串联用于执行分层计算。

上述系统还包括：MySQL或Doris数据库；所述Kafka将Flink运算结果写入所述MySQL或Doris数据库。

上述系统还包括：校验单元，利用处理逻辑中的业务标识对所述处理逻辑是否正确进行校验。

上述数据分析方法、数据处理方法以及系统中，所述业务标识包括但不限于以下一种标识或者两种以上标识的组合：订单号、班课ID、老师ID、用户ID、学期ID、课程项目ID。

以下结合附图具体说明本发明业务数据系统的结构以及相关方法的执行过程。

图1示出了本发明提供的一种业务数据分析系统。将hive数据仓库中的历史数据导入到Kafka中；并且，通过Canal来同步MySQL的实时数据；中间层使用Doris和MySQL来进行数据的校对；使用Kafka做流量数据中间层，用Flink来串联实现分层计算逻辑，最终将结果输出到MySQL或者Doris中提供业务分析服务。

如图1所示，该业务数据分析系统包括：增量数据订阅模块、Hive数据仓库、Kafka分布式发布订阅消息系统，以及Flink计算模块。

增量数据订阅模块，利用增量数据订阅模块从数据源数据库(例如MySQL数据库)同步实时数据。

所述增量数据订阅模块可以由Canal实现。所述Canal主要用途是基于MySQL数据库增量日志解析，提供增量数据订阅和消费。本实施例中，利用Canal从MySQL实时获得业务数据的增量数据。对于订单数据而言所述增量数据包括新增的订单数据以及对已有订单操作的数据。

具体的，Canal模拟MySQL slave的交互协议向MySQL Mater发送dump协议，MySQLmater收到Canal发送过来的dump请求，开始推送二进制日志(binary log)给Canal，然后Canal解析二进制日志(binary log)，再发送到存储目的地，如本发明采用的Kafka分布式发布订阅消息系统。

Hive数据仓库，存储量了用户订单历史数据。所述Hive是基于Hadoop的一个数据仓库工具，用来进行数据提取、转化、加载。

Kafka分布式发布订阅消息系统首先从Hive数据仓库一次性获得业务历史数据。获得用户订单的历史数据后，Kafka分布式发布订阅消息系统通过增量数据订阅模块(例如Canal)监听到增量数据并实时同步增量数据。

如上所述，使用Canal采集MySQL数据库的日志数据并进行数据实时增量的同步。Canal作为Kafka的消息提供者，把MySQL数据库中对数据的插入insert、更新update和删除delete操作通过日志的形式传给Kafka。

Kafka分布式发布订阅消息系统具有多个存储区域，Kafka对将获得的业务数据分配到不同的存储区域进行存储。

本发明实施例中，Kafka维护有映射表，通过映射表保存作为主键的业务标识信息，记录哪种类别的业务数据以哪个或那些字段作为主键，从而在Kafka获得业务数据后，从业务数据中获取到作为主键的内容。相应的预设的分配策略以所述主键作为变量，计算得到业务数据被分配的存储区域。从而具有相同业务标识的业务数据被发送至Kafka中的同一个存储区域进行存储。

由于Kafka为分布式存储系统，存储区域以集群的形式存在。因而所述映射表中还保存有存储区域描述信息，通过该信息可以链接到Kafka相应的存储区域，实现数据的写入和读取。

本发明对于作为主键的业务标识并不限定，所述业务标识例如可以包括以下一种标识或者两种以上标识的组合：订单号、班课ID(班级编号、课程进度编号，或班级即课程进度编号)、老师ID(老师身份标识)、用户ID(用户身份标识)、学期ID(或学季编号，用于表明课程阶段)、课程项目ID(表明课程类型，如语文、思维)等。

以下实施例中，以所述业务标识为订单号，Kafka表中采用订单号作为主键，在获得MySQL数据库的订单增量数据后，按照订单策略不同订单号的业务数据执行分发并分区域存储。本发明并不限制采用其他的字段或字段的组合，只要该字段或字段组合能够从MySQL数据库中获得，且该字段或字段组合与订单具有一一对应关系即可。

本发明并不限定具体分发策略的设置，只要具有相同订单号的订单数据被分发到同一个存储区域即可。

具体举例，假设MySQL数据库中的订单数据结构是id和value，所述id可以为订单号。Canal监听到MySQL数据库中对数据(1，a)和(2，b)的插入操作。Kafka系统中维护的表设置的主键为所述的id，从而将id作为变量，根据相应的策略，决定相关id的数据被分发到哪个存储区域。拥有相同id的数据将被分发的同一个存储区域。以数据(1，a)和(2，b)的插入操作为例，(1，a)会被写入Kafka分区1中，(2，b)会被写入Kafka分区2中。

Flink计算模块对Kafka分布式发布订阅消息系统中各分布式存储区域获得的增量数据进行预设的统计分析。

具体的，Canal将数据库MySQL的数据变更日志传给Kafka，Kafka按照主键的策略对订单增量数据进行分区存储。从而，根据用户对订单状态的变更，同一订单的增量数据在同一个Kafka存储区域中被按照订单变更的顺序存储，根据订单数据的插入和删除操作的订单数据变更顺序，Flink流计算引擎就可以在每个计算算子按照订单数据的变更顺序对算子的状态数据进行计算。

现有技术中，Kafka只能保证单分区数据的顺序性，但是，如果具有顺序性的多个数据被分配到不同的存储区域后，Kafka无法保证这些本身具有顺序性的分别在不同存储区域的数据间的顺序不被打乱。同样，现有技术中，Flink默认的写入Kafka的方式是一个分区对应一个并行度或者多个并行度。这样一条数据的增删改查记录就有可能会落在不同的存储区域中，最终会由于数据顺序的打乱而使得Flink的流数据处理结果发生错误。

例如，历史数据通过Hive写入Kafka。输入流数据时，一个并行度只会写入一个存储区域，并且流数据中会有更改历史数据的变更记录。在没有采用本发明实施例Kafka主键的方法时，对相同历史数据的变更记录可能被分配到不同的存储区域，这有可能导致在进行处理时，所获得变更记录的顺序与用户实际更改订单状态的顺序不一致。

因而，本发明通过定义主键以确定实时数据应被分配到的存储区域。具体到Flink，给Flink映射到Kafka的映射表设置主键，在Flink将流处理后的数据写入Kafka的时候，基于主键制定的数据分配策略，Kafka按照将处理后的数据存储到相应的存储区域，所述主键与一条数据(例如一条订单数据)具有一一对应的关系，例如订单号作为主键。基于主键的数据分配策略，保证了每一条数据(订单数据)的变更记录(状态变化数据)都能够被存储在同一个存储区域。进而，在同一个存储区中，保证了变化数据之间的有序性。保证实时计算得出的每条记录都是最新且正确的值，同时也保证了数据链路的横向扩展能力。

Flink与Kafka类似是一个分布式系统，需要同一条数据的变更记录在一个并行度内进行处理。在执行group by或者join的时候，数据会按照group by或者join的key进行哈希分区，在一些场景下就会造成数据乱序的问题。

其中，所述group by的功能是用于根据by对数据按照特定字段进行分组，或者是特定的几个字段进行分组。所述join用于基于一定的条件进行数据关联，例如将A表和B表关联，表示为A inner join B。

参见图2。假设id为订单号，图中处理器1(Operator1)中的三个实时数据按顺序分别为：1)插入操作(Insert)，订单数据id号为1且值(Value)为A，2)删除操作(Delete)，订单数据id号为1且值(Value)为A，3)插入操作(Insert)，订单数据id号为1且值(Value)为B。以上过程，处理器1中的订单数据的值(Value)应该从A变为B的。

处理器1的数据基于哈希算法(HASH)决策数据分配到哪个存储区域，在未采用订单数据id(假设id为订单号)作为主键时，相同订单数据会被分配到不同的存储区域1和存储区域2。如果算子进行group by id(id为订单号)订单数据进行操作时，将会出现图2右部所示的情况。如图，由于每个算子的处理能力以及数据的数据量存在偏差，有可能造成存储分区2(partition2)的值(Value)为B的数据先被处理，即先插入了订单号为1值为B的订单数据；而存储分区1(Parttition1)的值(Value)是A的数据最终被删除操作(delete)。这样到最后输出时数据就会出现错误。

例如，对于用户生成订单1并付款的过程。假设值A代表用户订单下单操作，值B代表用户订单付款操作，实时数据正确的时序为：插入订单号1的下单数据，删除订单号1的下单数据，插入订单号1的付款数据。然而，图2所示的订单数据间时序性被改变，将导致这个过程的错误。

所以在Flink实时计算数据变更日志(cdc数据流)的时候，涉及到执行包括groupby或者join这些需要重新对数据进行分区的算子时，计算对象采用以上实施例所述的主键，从而保证输出时数据的时序性不变。

Flink在将数据处理分析结果写入Kafka时，根据Kafka映射表中维护的主键信息，按照预置的策略对数据中作为主键的字段进行计算，字段值不同的数据被写入Kafka中不同的存储区中。

基于本发明实施例所述主键(例如订单号)的使用，本发明链路结构中，使用Kafka做流量数据中间层，采用Flink串联实现分层计算逻辑，得到面向订单的分层数据指标。Kafka将各层流数据计算结果，输出到MySQL或Doris数据库，提供业务服务。

以下为本发明Flink两层计算的具体举例。

实时数据的获取阶段，假设用户A下单购买了老师B的课程，订单号为X；对于订单的实时数据，Kafka以订单号作为主键分配订单实时数据的存储区域。

按照订单号作为主键进行存储分配，使得在订单X状态发生改变时，可以将订单号为X的不同时间产生的实时数据存储到Kafka的同一个存储区域。

假设需要统计老师B负责哪些课程，则借助Flink需要进行如下两层的计算。

根据所述业务需求，第一层的处理逻辑是将订单数据与老师数据进行数据关联。在预置的该处理逻辑中，描述了用于实现逻辑计算的订单数据和老师数据在Kafka中的存储区域。具体的，可以在处理逻辑中分别引用用于描述订单数据存储地址的Kafka映射表和用于描述老师数据存储地址的Kafka映射表。

例如，处理逻辑X inner join Y，该处理逻辑中引用了描述订单数据存储地址的映射表X和用于描述老师数据存储地址的映射表Y。

所述映射表中记录了主键信息，记录哪种类型的业务数据的哪个字段或哪些字段作为主键，可以基于业务数据获取到作为主键的内容。以及，所述映射表描述在Kafka的存储区域的集群中如何找到特定的存储区域，从而通过映射表可以链接到相应的存储区域实现业务数据存取。

例如，映射表X中记录作为主键的订单号获得方法，以及存储区域的描述信息。

获得订单数据和老师数据后，Flink执行第一层处理逻辑的join运算。对Kafka中存储订单数据的存储区域中的数据与Kafka中存储老师数据的存储区域中的数据进行join运算。通过join运算，将订单数据与老师的数据建立关联。

按照订单号与老师ID组合的字符串作为主键分配相应数据的存储区域。Flink完成join运算，将订单与老师绑定的数据写入到Kafka时，以订单号与老师ID组合的字符串为主键作为相应分配策略的变量，得到所述关联数据分配到的存储区域。从而，具有相同所述订单号与老师ID组合的字符串的数据被写入到同一个Kafka存储区域。

基于第一层处理的结果，第二层的处理逻辑是以老师ID作为条件，执行聚合运算，得到每位老师负责的订单数量。

获得订单与老师绑定的数据后，Flink执行第二层处理逻辑的聚合运算(group by运算)。聚合计算group by时，以老师ID作为条件，运算得到每位老师负责的订单数量，其中包含老师B的订单数量。

聚合运算的结果写入到Kafka时，以老师ID作为主键，按照相应的策略，根据老师ID决定数据存储的存储区域。

基于以上的分析结构，如果某位老师负责的订单发生变化，例如订单课程由老师B转到老师C，则通过以上两层的计算，老师B订单数量发生变化的数据与老师B订单的已有数据写入到Kafka的同一个存储区域，以及老师C订单数量发生变化的数据与老师C订单的已有数据写入到Kafka的同一个存储区域。

为了实现以上实时数据的分区存储，本发明实施例中，Kafka维护有映射表。在所述映射表中记录主键信息，记录何种数据以哪个或那些字段作为主键，从实时数据中获取到作为主键的内容。例如本实施例中，获得实时订单数据，从订单数据中获得订单号；获得Flink第一层运算结果时，从数据中获得订单号与老师ID的组合字符串；获得Flink第二层运算结果时，从数据中获得老师ID。从而，利用分配策略，对所述主键进行计算，确定相关数据所分配的存储区域。

上述实施例基础上，本发明在Flink执行处理逻辑运算前，还可以对处理逻辑的正确性进行检查。

例如，具体到以上实施例，在Flink分别执行每层处理逻辑计算前，可以对该层处理逻辑是否正确进行校验。

具体的，对于确定的处理逻辑，预先定义Kafka映射表，所述映射表用于描述该处理逻辑运算结果的业务数据应按照那种业务标识分配存储区域。在Flink执行处理逻辑运算前，如果处理逻辑的运算键采用了映射表中作为主键的业务标识，即映射表描述的主键中包含了处理逻辑计算中的键，则处理逻辑是正确的。

例如，以上实施例的第二层处理逻辑是以老师ID为条件得到每个老师负责的订单数。具体是以老师ID作为条件执行聚合运算，则该逻辑运算的键为老师ID。并且，对于第二层运算的结果数据，以老师ID作为映射表的主键，分配运算结果的存储区域。因而可以判断该运算逻辑正确。如果映射表中定义的主键仅为老师ID，而第二层处理逻辑中没有采用老师ID进行运算，则表明处理逻辑不正确。

例如在以上实施例的X inner join Y处理逻辑中，如果在逻辑运算中具体采用了订单号和老师ID作为运算键；在映射表中，以订单号和老师ID的字符串组合作为主键，因而，可以判断该处理逻辑是正确的。

上文实施例中通过将业务标识作为主键决定Kafka系统中数据存储区域的分配，保证实时业务数据在Kafka系统中的时序性。基于本发明的链路结构，作为主键的业务标识还用于在Kafka系统中的数据压缩。

Kafka作为一个消息系统，保留全量的变更数据会使得Kafka中有大量的不需要的变更记录，占用大量无用存储，也会造成下游其他任务从头启动时，读取了过多不必要的数据，拖慢读取性能，产生大量不必要的开销。需要采用相关的机制对Kafka中的数据进行清理。

现有技术中，Kafka系统中设置有数据过期时间，丢弃Kafka系统中存储时长大于过期时间的数据。

本发明实施例利用Kafka映射表的主键，对具有相同主键的数据，仅保留其中最新的数据。

由于本发明中Kafka每获得一个实时数据，按照该实时数据的主键，将该实时数据分配到存储了具有该相同主键实时数据的存储分区中。由于相同主键的实时数据进入到同一个存储分区，并且Kafka的同一个存储分区中存储的数据具有时序性。因而，在每个Kafka的分区中，能够获得具有相同主键的多个实时数据中的最新的实时数据。

按照上述方法，在对Kafka中的数据进行压缩时，本发明对于存储分区中存在多个具有相同主键的实时数据时，仅保留其中最新的实时数据。

采用现有方法利用到订单相关业务时，如果订单状态长时间未发生变化，即长时间没有产生实时订单数据，则采用现有方法，将会从Kafka库中删除该订单的所有数据，造成订单数据的丢失。另一方面，对于近期发生过多次状态变化的订单，则对于一个订单保留了多个实时数据，出现了数据冗余。采用本发明实施例的方法避免了以上情况的出现，避免数据丢失的同时具有很高的压缩率，并且，更加符合基于订单状态的变化进行业务分析的需求。

例如，假设有1000个订单，由于该1000个订单状态可能发生变化，因而Kafka系统中可能存在很多实时数据，例如3500条实时数据。

按照本发明的方法，经过数据压缩后将保存该1000个订单的最新的1000个实时数据，即保存了该1000个订单的最新订单状态。对于每个订单，通常只有最新的实时数据是业务分析所需的，因此，本发明实施例方法很好的满足了业务分析的需求。

假设按照现有技术，经过数据压缩后依然保留了1000个实时数据，但该1000个实时数据可能是800个订单状态变化产生的。因此现有的压缩方法出现了订单丢失的情况，并且，对于800个订单保存了1000个实时数据，压缩后依然存在数据冗余。从而现有方法不满足订单业务分析的需求。

作为对压缩方法的进一步改进，本发明执行数据压缩时，以存储空间的占用比例作为决定是否执行数据压缩的变量。例如，当存储区域数据占用存储空间达到60％时，执行上述方法的压缩处理。或者通过其他基于空间占用率为变量的策略得到是否执行数据压缩的判断方法，本发明并不限制。本方法更适用于本发明所采用的基于Kafka主键的数据压缩方式。

以上业务数据分析系统还包括MySQL或Doris数据库。Kafka将Flink写入的计算结果输出到MySQL或Doris数据库。所述MySQL或Doris数据库作为输出单元展现所述计算结果。当所述计算结果为Flink多层计算的中间结果时，MySQL或Doris数据库可以作为工具对Flink的计算结果进行校验，例如与上一层Flink计算结果进行对比，或者输出进行人为校验。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关方法的实施例中进行了详细描述，此处将不再做详细阐述说明。

上文中已经参考附图详细描述了本申请的方案。在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详细描述的部分，可以参见其他实施例的相关描述。本领域技术人员也应该知悉，说明书中所涉及的动作和模块并不一定是本申请所必须的。另外，可以理解，本申请实施例语调评分方法中的步骤可以根据实际需要进行顺序调整、合并和删减，本申请实施例装置中的模块可以根据实际需要进行合并、划分和删减。

本发明还提供一种计算设备，包括存储器和处理器。

处理器可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器可以包括各种类型的存储单元，例如系统内存、只读存储器(ROM)，和永久存储装置。其中，ROM可以存储处理器或者计算机的其他模块需要的静态数据或者指令。永久存储装置可以是可读写的存储装置。永久存储装置可以是即使计算机断电后也不会失去存储的指令和数据的非易失性存储设备。在一些实施方式中，永久性存储装置采用大容量存储装置(例如磁或光盘、闪存)作为永久存储装置。另外一些实施方式中，永久性存储装置可以是可移除的存储设备(例如软盘、光驱)。系统内存可以是可读写存储设备或者易失性可读写存储设备，例如动态随机访问内存。系统内存可以存储一些或者所有处理器在运行时需要的指令和数据。此外，存储器可以包括任意计算机可读存储媒介的组合，包括各种类型的半导体存储芯片(DRAM，SRAM，SDRAM，闪存，可编程只读存储器)，磁盘和/或光盘也可以采用。在一些实施方式中，存储器可以包括可读和/或写的可移除的存储设备，例如激光唱片(CD)、只读数字多功能光盘(例如DVD-ROM，双层DVD-ROM)、只读蓝光光盘、超密度光盘、闪存卡(例如SD卡、min SD卡、Micro-SD卡等等)、磁性软盘等等。计算机可读存储媒介不包含载波和通过无线或有线传输的瞬间电子信号。

存储器上存储有可执行代码，当可执行代码被处理器处理时，可以使处理器执行上文述及的方法中的部分或全部。

此外，根据本申请的语调评分方法还可以实现为一种计算机程序或计算机程序产品，该计算机程序或计算机程序产品包括用于执行本申请的上述语调评分方法中部分或全部步骤的计算机程序代码指令。

或者，本申请还可以实施为一种非暂时性机器可读存储介质(或计算机可读存储介质、或机器可读存储介质)，其上存储有可执行代码(或计算机程序、或计算机指令代码)，当所述可执行代码(或计算机程序、或计算机指令代码)被计算设备(或电子设备、服务器等)的处理器执行时，使所述处理器执行根据本申请的上述语调评分方法的各个步骤的部分或全部。

本领域技术人员还将明白的是，结合这里的申请所描述的各种示例性逻辑块、模块、电路和算法步骤可以被实现为电子硬件、计算机软件或两者的组合。

附图中的流程图和框图显示了根据本申请的多个实施例的系统和语调评分方法的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标记的功能也可以以不同于附图中所标记的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

以上已经描述了本申请的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。