CN107679173A

CN107679173A - 一种实时数据处理方法及装置

Info

Publication number: CN107679173A
Application number: CN201710909133.4A
Authority: CN
Inventors: 孙迁; 叶国华; 钱津津; 吴金迎; 范东
Original assignee: Suning Commerce Group Co Ltd
Current assignee: Suning Commerce Group Co Ltd
Priority date: 2017-09-29
Filing date: 2017-09-29
Publication date: 2018-02-09

Abstract

本发明实施例公开了一种实时数据处理方法及装置，涉及互联网电子商务领域，能够提高对于异常数据的处理效率，减少异常数据造成的销售损失。本发明包括：在将接收到的实时流式数据导入STORM后，获取实时流式数据对应的业务主键；当在REDI S中检测到所述业务主键不存在时，将所述业务主键存入到所述RED I S中，并在二层检测开关开启时，检测在DB中是否存在所述业务主键；当在所述DB中检测到所述业务主键不存在时，将所述业务主键存入到所述DB中；当在所述RED I S和所述DB的任一项中，检测到所述业务主键已存在时，判定所述接收到的实时流式数据为异常数据。本发明适用于实时流式数据去重。

Description

一种实时数据处理方法及装置

技术领域

本发明涉及互联网电子商务领域，尤其涉及一种实时数据处理方法及装置。

背景技术

随着电子商务技术的发展，实时流式数据在订单处理、价格维护等实时性要求较高的场景中得到了推广和使用，尤其是对于网购平台上的价格维护，采用GMV(GrossMerchandise Volume，网站成交金额)系统处理实时流式数据。

但是，在实际使用的过程中，无论是上游数据重复采集，还是在业务处理过程中由于延时等原因造成的数据的重复下发，都会造成GMV的下游数据的不准确的问题，GMV的下游数据的不准确，就会造成价格维护的结果出错，使得运营商和用户无法获取正确的价格。又由于数据流是实时下发的，不便于异常数据原因的排查。异常数据最终所导致的错误的价格结果，就会给运营商造成销售损失。

目前用于解决价格维护中数据的重复下发问题的方案，主要是通过网络爬虫或者人工巡检员实时监控显示价格的页面，被动地发现已经出现的异常数据，再通知运维部门的人员异常数据，处理效率低，且难以减少异常数据造成的销售损失。

发明内容

本发明的实施例提供一种实时数据处理方法及装置，能够提高对于异常数据的处理效率，减少异常数据造成的销售损失。

为达到上述目的，本发明的实施例采用如下技术方案：

第一方面，本发明的实施例提供的方法，包括：

在将接收到的实时流式数据导入STORM后，获取实时流式数据对应的业务主键；

当在REDIS中检测到所述业务主键不存在时，将所述业务主键存入到所述REDIS中，并在二层检测开关开启时，检测在DB中是否存在所述业务主键；

当在所述DB中检测到所述业务主键不存在时，将所述业务主键存入到所述DB中；

当在所述REDIS和所述DB的任一项中，检测到所述业务主键已存在时，判定所述接收到的实时流式数据为异常数据。

结合第一方面，在第一方面的第一种可能的实现方式中，还包括：

当判定所述接收到的实时流式数据为异常数据之后，将所述业务主键记录到异常数据表中，并对所述异常数据进行去重处理。

结合第一方面的第一种可能的实现方式，在第二种可能的实现方式中，还包括：

当扫描到所述异常数据表出现增量信息后，查询所配置的客户端设备；

根据所述增量信息生成告警信息，并向所述客户端设备发送。

结合第一方面的第二种可能的实现方式，在第三种可能的实现方式中，还包括：

根据所述增量信息，确定所述异常数据对应的业务链路环节；

将所确定的业务链路环节记录在所述告警信息中。

结合第一方面的第三种可能的实现方式，在第四种可能的实现方式中，所述查询所配置的客户端设备，包括：

获取所述所确定的业务链路环节对应的员工标识；

查询与所述员工标识向关联的客户端设备。

第二方面，本发明的实施例提供的装置，包括：

提取模块，用于在将接收到的实时流式数据导入STORM后，获取实时流式数据对应的业务主键；

第一去重模块，用于当在REDIS中检测到所述业务主键不存在时，将所述业务主键存入到所述REDIS中，并在二层检测开关开启时，检测在DB中是否存在所述业务主键；

第二去重模块，用于当在所述DB中检测到所述业务主键不存在时，将所述业务主键存入到所述DB中；

异常处理模块，用于当在所述REDIS和所述DB的任一项中，检测到所述业务主键已存在时，判定所述接收到的实时流式数据为异常数据。

结合第二方面，在第二方面的第一种可能的实现方式中，所述异常处理模块，还用于当判定所述接收到的实时流式数据为异常数据之后，将所述业务主键记录到异常数据表中，并对所述异常数据进行去重处理。

结合第二方面的第一种可能的实现方式，在第二种可能的实现方式中，还包括：

告警模块，用于当扫描到所述异常数据表出现增量信息后，查询所配置的客户端设备；根据所述增量信息生成告警信息，并向所述客户端设备发送。

结合第二方面的第二种可能的实现方式，在第三种可能的实现方式中，所述告警模块，还用于根据所述增量信息，确定所述异常数据对应的业务链路环节；并将所确定的业务链路环节记录在所述告警信息中。

结合第二方面的第三种可能的实现方式，在第四种可能的实现方式中，所述告警模块，具体用于获取所述所确定的业务链路环节对应的员工标识；并查询与所述员工标识向关联的客户端设备。

本发明实施例提供的实时数据处理方法及装置，当实时数据流下发的时候，根据业务主键查询REDIS，如果没有则将业务主键存入到REDIS，如果有则认为数据已下发无需再存入并作过滤。在DB防重层，采用的DB业务主键防重的方法，实时数据流流转至DB后，查找在DB表中是否存在这个业务主键，如果没有则插入，有则认为是重复下发的异常数据，需要进行过滤操作。相对于现有技术中被动地发现已经出现的异常数据，再通知运维部门的人员异常数据的处理方式，本发明实施例提高了对于异常数据的处理效率，减少异常数据造成的销售损失。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1a为本发明实施例提供的系统架构示意图；

图1b为本发明实施例提供的系统技术框架示意图；

图1c为本发明实施例提供的系统应用框架示意图；

图1d为本发明实施例提供的实时数据流的流向的示意图；

图2为本发明实施例提供的方法流程示意图；

图3、图4为本发明实施例提供的装置结构示意图。

具体实施方式

为使本领域技术人员更好地理解本发明的技术方案，下面结合附图和具体实施方式对本发明作进一步详细描述。下文中将详细描述本发明的实施方式，所述实施方式的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施方式是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的任一单元和全部组合。本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样定义，不会用理想化或过于正式的含义来解释。

本实施例中的方法流程，具体可以在一种如图1a所示的系统上执行，该系统包括：业务系统、GMV(Gross Merchandise Volume，网站成交金额)系统、数据库。其中：

本实施例中所揭示的业务系统，具体可以是在线购物平台，物流订单系统，库存系统等各类电子商务领域相关的在线系统。一般来说，业务系统主要用于与海量的消费者终端设备进行数据交互，比如：消费者或者商户通过操作智能手机向网站业务系统发送的访问消息，并在较高负载情况下对接收到的访问消息进行处理。本实施例中所揭示的业务系统，在硬件层面上具体可以是工作站、超级计算机等设备，或者是由多台服务器组成的一种用于数据处理的服务器集群。

分析系统在硬件层面上具体可以是由多台服务器组成的一种用于数据处理和存储的服务器集群。采用目前已有的GMV部署方式，在分析系统上部署GMV，比如：在分析系统上增设一个用于实时统计公司的销售量和销售金额的GMV功能模块。

本实施例中所揭示的数据库，具体可以用于存储业务系统在运行时所产生的日志数据、表格数据、历史记录等业务系统在运行时所产生的海量的后台数据。在实际应用中，接受业务系统实时数据流，实时数据流经过STORM(一种开源的分布式实时大数据处理框架)处理后导入DRUID(一种用于大数据实时处理的开源分布式系统，在本实施例中可以作为一种存储介质)。本实施例中所揭示的数据库，在硬件层面上具体可以是由多台服务器组成的一种用于数据处理和存储的服务器集群。

本发明实施例提供一种实时数据处理的方法，如图2所示，包括：

S1、在将接收到的实时流式数据导入STORM后，获取实时流式数据对应的业务主键。

例如：如图1b、1c所示的，实时流式数据具体可以是业务系统通过KAFKA传入数据库，并导入STORM，实时流式数据接入到STORM中，本实施例中的排重操作都可以基于STORM操作。业务主键可以是某个字段也可能是某几个字段的并集，实际应用中作为业务主键的字段可以随机制定，也可以根据不同的业务需求个性化制定，比如：可以采用商品编码、订单行等信息作为业务主键。

S2、当在REDIS中检测到所述业务主键不存在时，将所述业务主键存入到所述REDIS中，并在二层检测开关开启时，检测在DB中是否存在所述业务主键。

其中，二层检测开关具体可以理解一种通过程序设计的功能开关，在开启时本实施例中采用两层排重操作，即对于实时数据流的排重操作主要分了两层，第一层是基于REDIS(一种开源的，使用ANSIC语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库)的排重操作，根据业务主键进行判断在REDIS中是否存在，如果不存在则将业务主键存入到REDIS中，如果存在则认为该条数据已经下发，是异常数据。在二层检测开关关闭时，则仅采用第一层是基于REDIS的排重操作，即不继续在所述DB中检测所述业务主键是否存在。

S3、当在所述DB中检测到所述业务主键不存在时，将所述业务主键存入到所述DB中。

在本实施例中，实时数据流的排重操作主要分了两层，第二层是基于DB的排重操作的，将业务主键记录到DB(DataBase，关系型数据库)中，无业务主键的情况下则正常的记录，有的情况下则报异常，并将异常数据记录到异常表中。

例如：S2-S3所提出的两层防重方式，可以如图1b所示的系统技术框架，采用分析系统，对订单系统产生实时采集支付订单的日志，并计算出当天的实时的订单数量和销售金额。其中，无论在FLUME采集的时候出现重复采集还是上游大数据部门在给订单数据做相关清洗的时候各种原因导致的数据重复下发，都会导致GMV的数据不准确。本实施例中，可以采用如图1c所示的系统应用框架，基于对STORM的实时数据流防重，以订单行做为业务主键，经过第一层REDIS后，我们先查看在REDIS中是否存在这个订单行的业务主键，如果没有则存入这个订单行，有则说明这个订单行已经下发，是上游重复下发的异常数据需要进行过滤。

实时数据流再经第二层DB防重，先根据这个订单行去查询DB中是否存在，如果不存在，则将该订单行加入到DB中，如果存在，说明是异常数据，需要进行过滤操作。经过这两层基于STORM的防重操作，保证了实时数据流数据准确性。

S4、当在所述REDIS和所述DB的任一项中，检测到所述业务主键已存在时，判定所述接收到的实时流式数据为异常数据。

在目前的应用中，由于实时数据流的时效性是非常高，处理实时数据流的时候用STORM技术比较多，然而面对上游数据的重复下发。且实时数据重复下发的原因有很多，无论是FLUME采集时数据的重复采集，还是消费的超时导致重复消费都会导致下游数据的重复下发，这些都没有做相关的处理，这样就经常会不可避免的出现实时数据的不准确。

本实施例中，基于STORM在对于流转的实时数据流，进行了两层防重，第一层是REDIS防重，第二层是DB的业务主键防重，例如图1d中的实时数据流的流向。当实时数据流下发的时候，根据业务主键查询REDIS，如果没有则将业务主键存入到REDIS，如果有则认为数据已下发无需再存入并作过滤，为了保持数据的一致性，可以在检测的过程中采用REDIS的分布式锁SETNX。在DB防重层，采用的DB业务主键防重的方法，实时数据流流转至DB后，查找在DB表中是否存在这个业务主键，如果没有则插入，有则认为是重复下发的异常数据，需要进行过滤操作。经过测试，经过这两层防重后实施数据的时效性未收到较大的影响，可在秒级完成。最终提高了对于异常数据的处理效率，减少异常数据造成的销售损失。

进一步的，还包括：当判定所述接收到的实时流式数据为异常数据之后，将所述业务主键记录到异常数据表中，并对所述异常数据进行去重处理。其中，在经过S1-S4后，若在所述REDIS和所述DB的中都没有检测到已存在的业务主键，则记录为正常状态。

需要说明的是，在实时性要求特别高的情况下，可以通过开关控制，只在REDIS部署防重策略，即流程可以简化为：在将接收到的实时流式数据导入STORM后，获取实时流式数据对应的业务主键；当在REDIS中检测到所述业务主键不存在时，将所述业务主键存入到所述REDIS中；当在所述REDIS中，检测到所述业务主键已存在时，判定所述接收到的实时流式数据为异常数据。所述去重处理，具体可以包括：将重复数据过滤，记录异常的重复数据等过程。

在本实施例中，可以根据对数据时效性的要求，灵活选择是一层REDIS防重还是两层REDIS和DB防重，根据记录的异常数据可对整个数据链路进行CHECK,从而达到优化全链路的目的，从而提高下游数据的准确性。在本实施例中，记录到异常数据表中的可以是包含业务主键在内的，整条实时数据流的整体信息。

可选的，当扫描到所述异常数据表出现增量信息后，查询所配置的客户端设备。根据所述增量信息生成告警信息，并向所述客户端设备发送。

本实施例中所揭示的客户端设备具体可以实做成单独一台装置，或整合于各种不同的媒体数据播放装置中，诸如移动电话、平板电脑(Tablet Personal Computer)、膝上型电脑(Laptop Computer)、个人数字助理(personal digital assistant，简称PDA)等。

具体的，后台运行的调度任务(一种可以利用现有方案根据所监控和处理数据的不同，开发的实时调度任务模块，用于监控和处理数据事件)实时扫描异常的异常数据表，根据配置的技术人员，将告警信息发送/提示给技术人员的客户端设备。

其中，异常数据表中的增量信息，可以理解为异常数据表每次刷新后新出现的信息，比如：由于检测到异常数据，将异常数据对应的业务主键记录在异常数据表，则新记录进异常数据表的业务主键则作为增量信息。

在本实施例中，可以通过告警信息向客户端设备展示发生异常的业务链路环节，以便于接收到告警信息的技术人员立刻得知出现异常的业务链路环节，省去了对于异常数据进行溯源的过程，从而减少排查异常数据的时间消耗。具体包括：

根据所述增量信息，确定所述异常数据对应的业务链路环节(业务链路环节就是指业务系统从上而下的数据的各个分发环节，完整的业务链路即可呈现出完整的数据流向)。将所确定的业务链路环节记录在所述告警信息中。一旦异常数据下发，则会实时的记录下来并且推送给相关的技术人员，进而对全链路各个环节进行检查，看异常数据在哪个环节产生，以便于技术人员快速优化业务链路。

具体的，所述查询所配置的客户端设备，包括：获取所述所确定的业务链路环节对应的员工标识。查询与所述员工标识向关联的客户端设备。其中，员工标识可以是员工的通讯工具的账号、工号、姓名等用于标识单个员工的作为标签使用的信息；也可以是权限标识，比如：在同一权限等级下包括了多个账号，出现异常后则需将告警信息向同一权限等级下的多个账号分别发送。

通过对实时数据流在不同的场景下产生的重复下发数据进行去重，并记录异常，再将信息推送给相关负责人，从而不断地修复、优化整个的数据链路。实现了在不重大影响实时数据流的时效性的情况下，做到实时数据流的去重、异常数据的推送以及全链路的修复和优化。从而缓减下游数据产生重复异常的可能性，提高数据的准确性。最终提高了对于异常数据的处理效率，减少异常数据造成的销售损失。

本发明实施例还提供一种实时数据处理的装置，如图3所示的，包括：

其中，所述异常处理模块，还用于当判定所述接收到的实时流式数据为异常数据之后，将所述业务主键记录到异常数据表中，并对所述异常数据进行去重处理。

本实施例中基于STORM在防重方面做了两层，第一层是REDIS防重，第二层是DB的业务主键防重。当实时数据流下发的时候，根据业务主键查询REDIS，如果没有则将业务主键存入到REDIS，如果有则认为数据已下发无需再存入并作过滤，为了保持数据的一致性，可以在检测的过程中采用REDIS的分布式锁SETNX。在DB防重层，采用的DB业务主键防重的方法，实时数据流流转至DB后，查找在DB表中是否存在这个业务主键，如果没有则插入，有则认为是重复下发的异常数据，需要进行过滤操作。经测试，经过这两层防重后实时数据的时效性未受到较大的影响。最终提高了对于异常数据的处理效率，减少异常数据造成的销售损失。

进一步的，如图4所示的，还包括：

其中，所述告警模块，还用于根据所述增量信息，确定所述异常数据对应的业务链路环节；并将所确定的业务链路环节记录在所述告警信息中。

具体的，所述告警模块，具体用于获取所述所确定的业务链路环节对应的员工标识；并查询与所述员工标识向关联的客户端设备。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围为准。

Claims

1.一种实时数据处理的方法，其特征在于，包括：

2.根据权利要求1所述的方法，其特征在于，还包括：

3.根据权利要求2所述的方法，其特征在于，还包括：

4.根据权利要求3所述的方法，其特征在于，还包括：

将所确定的业务链路环节记录在所述告警信息中。

5.根据权利要求4所述的方法，其特征在于，所述查询所配置的客户端设备，包括：

获取所述所确定的业务链路环节对应的员工标识；

查询与所述员工标识向关联的客户端设备。

6.一种实时数据处理的装置，其特征在于，包括：

7.根据权利要求6所述的方法，其特征在于，所述异常处理模块，还用于当判定所述接收到的实时流式数据为异常数据之后，将所述业务主键记录到异常数据表中，并对所述异常数据进行去重处理。

8.根据权利要求7所述的方法，其特征在于，还包括：

9.根据权利要求8所述的方法，其特征在于，所述告警模块，还用于根据所述增量信息，确定所述异常数据对应的业务链路环节；并将所确定的业务链路环节记录在所述告警信息中。

10.根据权利要求9所述的方法，其特征在于，所述告警模块，具体用于获取所述所确定的业务链路环节对应的员工标识；并查询与所述员工标识向关联的客户端设备。