CN113254466A - 一种数据处理方法、装置、电子设备和存储介质 - Google Patents

Abstract

本申请涉及计算机技术领域，尤其涉及一种数据处理方法、装置、电子设备和存储介质，用以提高数据存储的安全性和数据处理效率。其中，方法包括：通过事件收集模块从第一数据库中批量获取采样数据；将获得的采样数据写入消息队列，并通过消息队列向事件分发模块推送基于采样数据生成的数据变更消息；通过事件分发模块将数据变更消息映射为业务事件，并存储至事件池中；接收到消息获取方发送的事件获取请求时，基于事件获取请求中的索引信息，从事件池中获取与索引信息对应的业务事件并发送至消息获取方。本申请解除业务模块的耦合，引入事件中心机制，基于事件中心机制统一对象事件管理，提高了数据存储的安全性和数据处理效率。

Description

一种数据处理方法、装置、电子设备和存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种数据处理方法、装置、电子设备和存储介质。

背景技术

对象体系是作者在客户端侧内容产品平台上的通行证，也是作者在内容产品平台上获取价值的媒介。

相关技术中，通过内容中心对象体系可以实现作者的对象数据的存储和处理。在数据更新时，内容中心对象体系中的各个模块之前需要相互同步，来通知各个业务方去做相应的更新调整。业务模块耦合严重，业务大量定时任务全表扫描，效率低下。

发明内容

本申请实施例提供一种数据处理方法、装置、电子设备和存储介质，用以提高数据存储的安全性和数据处理效率。

本申请实施例提供的一种数据处理方法，包括：

通过事件收集模块从第一数据库中批量获取采样数据，所述第一数据库中存储有与指定业务方相关的各个对象对应的采样数据；

将获得的采样数据写入消息队列，并通过所述消息队列向事件分发模块推送基于所述采样数据生成的数据变更消息；

通过所述事件分发模块将所述数据变更消息映射为业务事件，并存储至事件池中；

接收到消息获取方发送的事件获取请求时，基于所述事件获取请求中的索引信息，从所述事件池中获取与所述索引信息对应的业务事件并发送至所述消息获取方。

本申请实施例提供的一种数据处理装置，包括：

收集单元，用于通过事件收集模块从第一数据库中批量获取采样数据，所述第一数据库中存储有与指定业务方相关的各个对象对应的采样数据；

消息单元，用于将获得的采样数据写入消息队列，并通过所述消息队列向事件分发模块推送基于所述采样数据生成的数据变更消息；

映射单元，用于通过所述事件分发模块将所述数据变更消息映射为业务事件，并存储至事件池中；

订阅单元，用于接收到消息获取方发送的事件获取请求时，基于所述事件获取请求中的索引信息，从所述事件池中获取与所述索引信息对应的业务事件并发送至所述消息获取方。

可选的，所述消息单元具体用于：

根据所述采样数据对应的模块标识对所述采样数据进行分区处理，其中，具有相同模块标识的采样数据划分为同一分区，所述采样数据对应的模块标识是通过对所述采样数据的对象标识进行取模得到的；

将分区后的采样数据并行写入所述消息队列。

可选的，所述装置还包括：

第一读写单元，用于在所述收集单元通过事件收集模块从第一数据库中批量获取采样数据之前，获取所述指定业务方在预置时间段内相关的各个对象对应的采样数据；

通过事物写操作将所述采样数据写入所述第一数据库。

可选的，所述装置还包括：

第二读写单元，用于在所述收集单元通过事件收集模块从第一数据库中批量获取采样数据之前，获取所述指定业务方在预置时间段内相关的各个对象对应的基础数据，并通过事物写的方式将所述基础数据写入第二数据库；以及

获取所述指定业务方在预置时间段内相关的各个对象对应的特征数据，并将所述特征数据写入文档型的第三数据库。

可选的，所述装置还包括：

特征处理单元，用于基于所述特征数据对各个对象进行等级划分，并将划分结果发送给推荐系统，以使所述推荐系统针对不同等级对象分发不同内容。

可选的，所述装置还包括：

业务单元，用于在所述收集单元通过事件收集模块从第一数据库中批量获取采样数据之前，还包括：

通过预设读写模块为所述指定业务方接入不同类型的对象，并对所述各个对象统一进行权限检查和频率控制。

可选的，所述索引信息为事件获取偏移量；所述订阅单元具体用于：

根据所述事件获取请求中的事件获取偏移量，确定待获取的业务事件的地址信息；

根据所述地址信息从所述事件池中获取对应的业务事件，并发送至所述消息获取方。

可选的，所述装置还包括：

清理单元，用于在所述订阅单元从所述事件池中获取与所述索引信息对应的业务事件并发送至所述消息获取方之后，通过代理服务器存储所述消息获取方对应的事件获取记录；

基于所述事件获取记录以及预设事件清理策略，清理所述事件池中的业务事件。

本申请实施例提供的一种电子设备，包括处理器和存储器，其中，所述存储器存储有程序代码，当所述程序代码被所述处理器执行时，使得所述处理器执行上述任意一种数据处理方法的步骤。

本申请实施例提供一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。电子设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该电子设备执行上述任意一种数据处理方法的步骤。

本申请实施例提供一种计算机可读存储介质，其包括程序代码，当所述程序产品在电子设备上运行时，所述程序代码用于使所述电子设备执行上述任意一种数据处理方法的步骤。

本申请有益效果如下：

本申请实施例提供了一种数据处理方法、装置、电子设备和存储介质。由于本申请实施例解除了业务模块的耦合，引入了事件中心机制，基于事件中心机制统一对象事件管理，实现了消息实时通知和消息数据的可靠性，消息数据独立存储，不占用业务系统资源，降低业务系统与消息系统之间的耦合，尽量与业务隔离，防止消息系统异常影响基本存储访问。针对不同的业务产品，给用户提供安全、高可靠的对象数据存储，并且基于事件中心机制统一对象事件管理，提高数据存储的安全性和数据处理效率。

本申请的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请而了解。本申请的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为相关技术中的一种内容中心对象体系的一个可选的示意图；

图2为本申请实施例中的一种应用场景的一个可选的示意图；

图3为本申请实施例中的一种数据处理方法的实施流程图；

图4为本申请实施例中的一种业务事件映射和存储的方法流程示意图；

图5为本申请实施例中的另一种数据处理方法的实施流程图；

图6为本申请实施例中的一种分布式对象云存储系统的框架示意图；

图7为本申请实施例中的另一种分布式对象云存储系统的框架示意图；

图8为本申请实施例中的一种事件中心机制的具体流程示意图；

图9为本申请实施例中的一个账号数据处理的完整方法流程图；

图10为本申请实施例中的一种数据处理装置的组成结构示意图；

图11为应用本申请实施例的一种电子设备的一个硬件组成结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请技术方案的一部分实施例，而不是全部的实施例。基于本申请文件中记载的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请技术方案保护的范围。

下面对本申请实施例中涉及的部分概念进行介绍。

事物写：在数据的存储过程中，通常需要确保数据的完整性和同步性，即需要对多块不同地址的数据进行同步操作，保证所有数据要么全部完整的写入目标区域，要么目标区域保持原状，没有数据被写入，这种写操作即为事物写。在本申请实施例中，可通过事物写操作写入基础数据和采样数据。

分布式：是计算机的一种算法，当计算机的程序和数据通过网络分布在多于一个的计算机上时，计算就成为“分布式的”。分布式计算是一门计算机科学，它研究如何把一个需要非常巨大的计算能力才能解决的问题分成许多小的部分，然后把这些部分分配给许多计算机进行处理，最后把这些计算结果综合起来得到最终的结果。分布式网络存储技术是将数据分散的存储于多台独立的机器设备上。

令牌桶：令牌桶算法是网络流量整形（Traffic Shaping）和速率限制（RateLimiting）中最常使用的一种算法。典型情况下，令牌桶算法用来控制发送到网络上的数据的数目，并允许突发数据的发送。

特征数据：用于描述对象相关的特征。在本申请实施例中，对象可以指用户，或用户所登录的账号等。账号特征数据则是指与用户所登录的账号相关的特征数据，用于描述信息内容或数据等，其使用目的在于：识别内容；评价内容；追踪内容在使用过程中的变化。可基于账号特征分析用户画像，对用户进行内容推荐。其中，用户画像时一种勾画目标用户、联系用户诉求与设计方向的有效工具。

基础数据：用于描述对象相关的基本属性的数据。在本申请实施例中，账号基础数据则是指用户所登录账号相关的基本属性的数据，例如用户的年龄，性别，地址等。本申请实施例中的特征数据和基础数据存储分离。

采样数据：用于描述对象相关的流水数据。在本申请实施例中，账号采样数据指用户所登录的账号相关的内容变更所产生的流水数据，例如用户通过在应用上登录的账号发布新内容，或者是更改基本信息（例如头像，昵称）等时，都会产生变更流水，即本申请实施例中的账号流水数据。

Kafka和Ckafka：Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。Ckafka是基础架构部开发的高性能、高可用消息队列，也称消息中间件，其主要用于消息传输、网站活动追踪、运营监控、日志聚合、流式处理、事件追踪、提交日志等等需要高性能的场景。Ckafka完全兼容Kafka协议，使Kafka用户可以零成本迁入Ckafka。Ckafka基于Kafka进行了扩展开发和优化。

事件池：用于记录所有字段变更事件的存储池，在本申请实施例中，字段变更事件是指对基于采样数据生成的数据变更消息，进行映射得到的业务事件。常见的字段变更事件如：第一次写入、更新、变更为预期值等。

事务回滚：事务是一组组合成逻辑工作单元的操作，虽然系统中可能会出错，但事务将控制和维护事务中每个操作的一致性和完整性。例如，在将资金从一个帐户转移到另一个帐户的银行应用中，一个帐户将一定的金额贷记到一个数据库表中，同时另一个帐户将相同的金额借记到另一个数据库表中。由于计算机可能会因停电、网络中断等而出现故障，因此有可能更新了一个表中的行，但没有更新另一个表中的行。如果数据库支持事务，则可以将数据库操作组成一个事务，以防止因这些事件而使数据库出现不一致。如果事务中的某个点发生故障，则所有更新都可以回滚到事务开始之前的状态。如果没有发生故障，则通过以完成状态提交事务来完成更新。

云技术（Cloud technology）是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。

云技术基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，只能通过云计算来实现。

本申请主要涉及云技术中的云存储和数据库这两个方向。云存储（cloudstorage）是在云计算概念上延伸和发展出来的一个新的概念，分布式云存储系统（以下简称存储系统）是指通过集群应用、网格技术以及分布存储文件系统等功能，将网络中大量各种不同类型的存储设备（存储设备也称之为存储节点）通过应用软件或应用接口集合起来协同工作，共同对外提供数据存储和业务访问功能的一个存储系统。

数据库（Database），简而言之可视为电子化的文件柜，存储电子文件的处所，用户可以对文件中的数据进行新增、查询、更新、删除等操作。所谓“数据库”是以一定方式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。数据库管理系统（Database Management System，DBMS）是为管理数据库而设计的电脑软件系统，一般具有存储、截取、安全保障、备份等基础功能。

本申请实施例中提出的用于存储对象数据的系统即分布式对象云存储系统，其包含多个数据库，用于对对象数据、业务事件等分类存储，实现基础数据、特征数据、采样数据、业务事件等元数据的存储。

下面对本申请实施例的设计思想进行简要介绍：

对象体系是作者在客户端侧内容产品平台上的通行证，也是作者在内容产品平台上获取价值的媒介。通过内容中心对象体系可以实现作者的对象数据的存储和处理。以对象为账号为例，账号是数字时代的代表，就是每个人在特定的项目中所代表自己的一些数字等。

参阅图1所示，其为相关技术中的一种内容中心账号体系的示意图。由图1可知，该内容中心账号体系对接的来源方众多，包括图1所示的内容开放平台，视频软件、浏览器、直播软件等等，维护了多个开号服务、写服务。账号的元数据信息存储在三个数据库（Database，DB）中，即图1中的账号唯一标识（puin）资料DB，公众号DB，媒体平台（mediapublic，MP）平台DB，数据存储分散，也要维护多个DB，保证每个DB的数据的同步。另外，在数据更新时，各个模块之前需要相互同步，来通知各个业务方去做相应的更新调整。然而，图1所示的内容中心账号体系业务模块耦合严重，缺少事件通知机制，业务大量定时任务全表扫描，时效T+1（当天的下一天），效率低下。

有鉴于此，本申请实施例提出了一种数据处理方法、装置、电子设备和存储介质。由于本申请实施例解除了业务模块的耦合，引入了事件中心机制，基于事件中心机制统一对象事件管理，实现了消息实时通知和消息数据的可靠性，消息数据独立存储，不占用业务系统资源，降低业务系统与消息系统之间的耦合，尽量与业务隔离，防止消息系统异常影响基本存储访问。针对不同的业务产品，给用户提供安全、高可靠的对象数据存储，并且基于事件中心机制统一对象事件管理，提高数据存储的安全性和数据处理效率。

以下结合说明书附图对本申请的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本申请，并不用于限定本申请，并且在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

如图2所示，其为本申请实施例的应用场景示意图。其为本申请实施例的应用场景示意图。该应用场景图中包括两个终端设备210和若干服务器220。终端设备210与服务器220之间可以通过通信网络进行通信。

需要说明的是，图2所示只是举例说明，实际上终端设备和服务器的数量不受限制，在本申请实施例中不做具体限定。

在一种可选的实施方式中，通信网络是有线网络或无线网络。终端210以及服务器220可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

在本申请实施例中，终端设备210为用户使用的电子设备，该电子设备可以是个人计算机、手机、平板电脑、笔记本、电子书阅读器、车载终端等具有一定计算能力并且运行有即时通信类软件及网站或者社交类软件及网站的电子设备。各终端设备210通过无线网络与服务器220连接，服务器220可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络（Content DeliveryNetwork，CDN）、以及大数据和人工智能平台等基础云计算服务的云服务器。终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

其中，用户可通过终端设备210浏览其他用户分享的内容，终端设备210上可以安装有分享内容相关的应用，例如视频软件，短视频软件，浏览器，内容分享平台等，本申请实施例涉及的应用可以是软件，也可以是网页、小程序等客户端，服务器则是与软件或是网页、小程序等相对应的后台服务器，不限制应用的具体类型。

在本申请实施例中，用户可通过对象登录终端设备210上的相关应用来发布新的内容，修改基础信息等等，在这些对象数据发生变化时，都会产生变更流水，即本申请中的采样数据，本文主要是以账号流水数据进行举例说明的。需要说明的是，本申请实施例中的数据处理方法可以由服务器或终端设备单独执行，也可以由服务器和终端设备共同执行。

需要说明的是，本申请实施例中的采样数据，基础数据和特征数据等都是在用户已知并同意的前提下采集的，关于这些数据的采集和处理主要是为了提升业务性能。例如，可以事先与用户签订相关协议，或者当用户在一些关键节点进行操作时，可向用户进行提示，并在用户同意的前提下采集数据等等，以避免平台侵犯用户隐私数据。

另外需要说明的是，如本申请所公开的数据处理方法或装置，其中这些数据可保存在区块链上。其中多个服务器可组成为一区块链，而服务器为区块链上的节点。

下面结合上述描述的应用场景，参考附图来描述本申请示例性实施方式提供的数据处理方法，需要注意的是，上述应用场景仅是为了便于理解本申请的精神和原理而示出，本申请的实施方式在此方面不受任何限制。

参阅图3所示，其为本申请实施例提供的一种数据处理方法的实施流程图，以服务器执行为例进行举例说明，该方法的具体实施流程如下：

S31：通过事件收集模块从第一数据库中批量获取采样数据，第一数据库中存储有与指定业务方相关的各个对象对应的采样数据；

例如浏览器、新闻软件、短视频软件、内容分享平台等应用，在这些应用上，用户可以发布一些文章，新闻，日志，短视频，直播等内容，这些进行内容分享的用户可以称作作者，作者通过在应用上登录的账号发布新内容，或者是更改基本信息（例如头像，昵称）等时，都会产生变更流水，即本申请实施例中的作者账号相关的账号流水数据。

S32：将获得的采样数据写入消息队列，并通过消息队列向事件分发模块推送基于采样数据生成的数据变更消息；

其中，消息队列可以为Ckafka，本申请实施例中基于Ckafka来实现消息的推送，具体的，通过在Ckafka中开启分割器（partitioner）的配置，使用hase选项，通过puin进行分区。

S33：通过事件分发模块将数据变更消息映射为业务事件，并存储至事件池中；

S34：接收到消息获取方发送的事件获取请求时，基于事件获取请求中的索引信息，从事件池中获取与索引信息对应的业务事件并发送至消息获取方。

其中，消息获取方即订阅方，推荐系统等。在本申请实施例中，事件分发模块主要用于将消息队列推送的数据变更消息映射为业务事件后，进行事件分离和分发，即根据一定的规则配置，进行分类，然后分发给不同的消息获取方，并存储至事件池中与相应的消息获取方相对应的事件数据库中，由消息获取方主动从事件池中拉取业务事件，以实现对象变更信息的推送。

在上述实施方式中，解除了业务模块的耦合，引入了事件中心机制，基于事件中心机制统一对象事件管理，实现了消息实时通知和消息数据的可靠性，消息数据独立存储，不占用业务系统资源，降低业务系统与消息系统之间的耦合，尽量与业务隔离，防止消息系统异常影响基本存储访问。针对不同的业务产品，给用户提供安全、高可靠的对象数据存储，并且基于事件中心机制统一对象事件管理，提高数据存储的安全性和数据处理效率。

在一种可选的实施方式中，可以按照如图4所示的流程图实施S33，其为本申请实施例中的一种业务事件映射和存储的方法流程示意图，包括以下步骤：

S401：通过事件分发模块获取预设的事件映射配置信息，基于事件映射配置信息，确定数据变更消息中的变更字段对应的业务事件类型后，将数据变更消息映射为业务事件类型对应的业务事件，其中，事件映射配置信息用于表征字段与业务事件类型之间的映射关系；

需要说明的是，本申请实施例中的字段与业务事件类型之间为多对多的映射关系，即一个字段可以对应一个或多个业务事件类型，一个业务事件类型可以对应一个或多个字段。

例如，字段x1对应业务事件类型A和业务事件类型B，字段x2对应业务事件类型B，字段x3对应业务事件类型B和业务事件类型C，字段x4对应业务事件类型D，字段x5对应业务事件类型E和业务事件类型F等等。

S402：通过事件分发模块获取预设的订阅映射配置信息，基于订阅映射配置信息，确定各个业务事件对应的消息获取方，其中，订阅映射配置信息用于表征业务事件与消息获取方之间的映射关系；

在本申请实施例中，订阅映射配置信息可以是预设设置好的业务事件与订阅方之间的映射表，各个业务事件各自对应有相应的订阅方。

S403：根据各个业务事件对应的消息获取方，将各个业务事件写入到事件池中对应的事件数据库，其中，不同消息获取方在事件池中对应不同的事件数据库。

由于本申请中的各个业务事件都对应有相应的消息获取方，且事件池中有多个事件数据库，不同的事件数据库对应不同的消息获取方。因而，在将业务事件写入事件池中时，具体是根据各个业务事件对应的消息获取方来写入的。

例如，消息获取方1对应事件数据库1，消息获取方2对应事件数据库2，消息获取方3对应事件数据库3等等。当业务事件1对应消息获取方2时，则应将业务事件1存储于事件池中的事件数据库2，以此类推即可。

在上述实施方式中，通过事件中心机制，实现消息实时通知。

在一种可选的实施方式中，数据变更消息包含多个对应同一业务事件类型的变更字段；该情况下，在将数据变更消息映射为业务事件类型对应的业务事件时，需要分别将数据变更消息中的各个变更字段映射为业务事件类型对应的业务事件。

例如，数据变更消息包含三个字段：变更字段1，变更字段2，变更字段3。其中，变更字段1是字段x1，对应业务事件类型A和业务事件类型B，变更字段2是字段x2，对应业务事件类型B，变更字段3是字段x3，对应业务事件类型B和业务事件类型C。其中，上述所列举的可以是一条数据变更消息包含三个变更字段，也可以是一条数据变更消息包含一个变更字段，共三条数据变更消息。

该情况下，需要将变更字段1，变更字段2，变更字段3分别映射为业务事件类型对应的业务事件。即，将变更字段1映射为A类型的业务事件1和B类型的业务事件2；将变更字段2映射为B类型的业务事件3；将变更字段3映射为B类型的业务事件4和C类型的业务事件5。

在上述实施方式中，在将数据变更消息映射为业务事件类型对应的业务事件之后，还可以将基于多个对应同一业务事件类型的变更字段映射得到的多个业务事件，进行事件合并。

例如，对于上述所列举的这三个变更字段，都对应有同一业务事件类型B，对应的映射得到的业务事件为业务事件2，业务事件3和业务事件4，对于这三个同一类型的业务事件，可合并为一个业务事件，例如业务事件6。

综上，将三个变更字段进行映射得到的业务事件为：业务事件1，业务事件5和业务事件6。

在上述实施方式中，通过记录事件流水，支持流水回放，支持事件合并，可以有效减少存储操作和事件冲突。

在一种可选的实施方式中，在将获得的采样数据写入消息队列时，可进一步分区处理，具体过程如下：

根据采样数据对应的模块标识对采样数据进行分区处理，将分区后的采样数据并行写入消息队列，其中，具有相同模块标识的采样数据划分为同一分区，采样数据对应的模块标识是通过对采样数据的对象标识进行取模得到的。

在本申请实施例中，对象标识指对象唯一标识，例如账号标识，可用puin表示，模块标识（ID）可表示为modID，modID是指对puin进行取模生成的模块ID，对于不同的puin，通过取模得到的modID可能相同。

因而，通过上述实施方式，将modID相同的账号流水数据划分为同一分区，将数据写入到多个队列中，然后通过多任务写入到Ckafka中，可保证单个分区数据局部有序。

在本申请实施例中，还可通过统一读写服务对账号流水数据，账号基础数据和账号特征数据进行读写，不需要维护多个读写服务，有效提高了系统的可维护性。具体的，这些数据统一存储在数据支持层，但是各类数据各自对应有不同的存储位置，便于后续维护，可有效减少数据不一致的情况，提高数据存储的安全可用性。

一种可选的实施方式为，在通过事件收集模块从第一数据库中批量获取采样数据之前，通过预设读写模块为指定业务方接入不同类型的对象，并对各个对象统一进行权限检查和频率控制。

在本申请实施例中，预设读写模块指用于提供统一读写服务的模块，通过统一读写服务可以为业务方接入不同类型的对象，例如接入不同类型的账号。另外，在进行读写数据时，还需要进行权限检查和频率控制。其中，权限检查具体是指判断用户是否具有读写权限等。上游的接入层会统一调用读写服务，但并非所有的用户都可以调用，通过权限检查可以做到权限保护的工作。例如，权限指可以向数据库中存数据，可以发一些事件消息等，在进行权限检查时，需要检查用户是否能正常的读写数据，是否有权限发一些事件等。

其中，频率控制则是考虑到了负载的要求，由于底层的机器资源是有限的，系统本身有一定的负载能力，比如一分钟只能支持一万个请求时，如果一分钟接收到了两万个请求，中央处理器（Central Processing Unit，CPU）和内存不能支持这么多流量。

在本申请实施例中，为了保持负载均衡，防止突发流量导致服务崩掉，而对请求进行频率控制，具体可通过令牌桶有效控制进入系统的请求量，同时允许突发流量，来对系统进行过载保护。

在上述实施方式中，通过统一收拢读写服务，能够支持多服务接入订阅，当订阅方和订阅内容变更时不需要服务变更，并且增加了统一读写鉴权、字段鉴权（appid+skey）、过载保护等，可有效屏蔽底层实现。

在一种可选的实施方式中，在通过事件收集模块从第一数据库中批量获取采样数据之前，还需要获取指定业务方在预置时间段内相关的各个对象对应的采样数据；通过事物写操作将采样数据写入第一数据库。

其中，预置时间段可以是几个小时，一天，一周等等，可根据实际情况进行设置。在上述实施方式中，写采样数据时采用事物写的方式，可以有效确保数据可回溯。

在一种可选的实施方式中，在通过事件收集模块从第一数据库中批量获取采样数据之前，还需要获取指定业务方在预置时间段内相关的各个对象对应的基础数据，并通过事物写的方式将基础数据写入第二数据库；以及，获取指定业务方在预置时间段内相关的各个对象对应的特征数据，并将特征数据写入文档型的第三数据库。

其中，文档型数据库引入了特征数据表，可存储用户画像的大json字段，特征标签等。相比于相关技术中，在关系型数据库管理系统（MySQL）中使用innodb（是MySQL的数据库引擎之一）存储用户画像的特征字段的大脚本（json）的方式，更加安全可靠。

在上述实施方式中，写基础数据时采用事物写的方式，确保数据的可回溯。另外，本申请提出了账号基础信息与账号特征信息分离的方案，分离账号基础信息和账号特征信息，使用文档型数据库存储账号特征数据，降低了存储成本，提高的数据的可维护性和可用性。

在一种可选的实施方式中，还可基于特征数据对各个对象进行等级划分，并将划分结果发送给推荐系统，以使推荐系统针对不同等级对象分发不同内容。

在本申请实施例中，对各个对象进行等级划分时，可通过算法模型检测优质对象、低质对象、对象品类，对接内容链路，将各类对象特征提供给推荐侧使用，针对不同等级对象分发不同内容。

在一种可选的实施方式中，索引信息为事件获取偏移量，指上次最后一次获取事件的位置与最新事件位置的距离；在基于事件获取请求中的索引信息，从事件池中获取与索引信息对应的业务事件并发送至消息获取方时，具体过程如下：

根据事件获取请求中的事件获取偏移量，确定待获取的业务事件的地址信息；根据地址信息从事件池中获取对应的业务事件，并发送至消息获取方。其中，事件获取偏移量也称拉取偏移量，消息获取方传入拉取偏移量，根据拉取偏移量，通过事件获取代理服务器（proxy）来拉取事件，并发送至相应的订阅方。

其中，事件获取偏移量指上次最后一次获取事件的位置与最新事件位置的距离，基于该信息即可确定最新事件位置，即地址信息，具体表示待拉取的业务事件在事件池中的哪一个事件数据库中的哪一位置处。

在本申请实施例中，之所以采用由消息获取方拉取（pull）事件的方式，是因为推送（push）模式很难适应消费速率不同的消费者（consumer，即消息获取方），因为消息的发送速率由缓存代理（broker）决定，可能会导致consumer来不及处理（拒绝服务，网络阻塞），pull模式可以让消费者使用适合自身的速率来消费，每次订阅方获取的值为最终态的全量订阅字段。

在一种可选的实施方式中，在从事件池中获取与索引信息对应的业务事件并发送至消息获取方之后，还可进一步对事件池中的业务事件进行清理，如图5所示，其为本申请实施例中的又一种数据处理方法的实施流程图，包括以下步骤：

S51：通过事件收集模块从第一数据库中批量获取采样数据；

S52：将获得的采样数据写入消息队列，并通过消息队列向事件分发模块推送基于采样数据生成的数据变更消息；

S53：通过事件分发模块将数据变更消息映射为业务事件，并存储至事件池中；

S54：接收到消息获取方发送的事件获取请求时，基于事件获取请求中的索引信息，从事件池中获取与索引信息对应的业务事件并发送至消息获取方；

S55：通过代理服务器存储消息获取方对应的事件获取记录；

S56：基于事件获取记录以及预设事件清理策略，清理事件池中的业务事件。

其中，事件获取记录也可称作消费记录。例如，预设事件清理策略为按天清理，通过在proxy存储当前订阅方消费记录，用以进行告警和事件清理。

在一种可选的实施方式中，本申请实施例还提供一种账号数据处理系统，参阅图6所示，其为本申请实施例中的一种分布式账号云存储系统的框架示意图，主要用于介绍业务层面的架构，该系统包括：业务层、平台管理层，能力层和数据支持层（又称数据支持层）。

其中，业务层用于对接不同的业务方，为各个平台提供有效的账号数据支撑以及作者生态管理。即业务层主要用于处理一些与用户对接的业务，包括对作者进行一些管理，对作者的信息进行统计，分析作者的数据，给写内容的作者做一些结算工作，分等级、分流量，做用户画像等。例如图6中所示的：作者引入、作者管理、作者信息查询、消息通知、作者线索、作者结算等级、作者流量等级、作者画像等。

其中，消息通知是指系统内部管理的一个功能，比如用户修改了账号或头像等时，会触发一个消息并通知给相关的管理人员，例如运营。

另外，如图6所示，本申请实施例中的业务方可以是图6所示的应用1，应用2，应用3，运营，应用4等，这些属于本申请实施例中的账号以及内容信息的来源渠道，本申请实施例中的指定业务方可以是图6所列举的这些应用或运营，账号主要是指作者在这些应用中注册、登录的账号，或运营人员的账号，内容信息主要是指作者通过登录账号在应用发布、上传的内容。其中，运营作为业务方时，相当于运营管理平台，表示运营人员可以直接上传图片、上传内容。

在本申请实施例中，这些业务方相关的账号数据，包括账号基础数据，账号流量数据，账号特征数据等，通过图6所示的统一读/写接入层，即可与业务层、平台管理层、能力层，或是数据支持层进行通信、数据读写等。

本申请实施例中的平台管理层主要用于对作者生态以及账号内容提供统一的管理平台，参阅图6所示，平台管理层分为两部分，一部分用于对作者进行管理，另一部分用于对内容（即账号的一些信息）进行管理。

其中，用于对作者进行管理的这一部分即图6所示的平台管理层-作者管理部分，包括运营平台和事件管理中心。运营人员可以通过运营平台进行一些管理操作，而作者修改了一些内容时，会触发一些事件，即可通过事件管理中心进行事件管理。

图6所示的内容引擎部分即用于对内容进行管理的这一部分，包括账号画像标记、账号等级、账号封禁。在本申请实施例中，内容管理是指对账号进行特征标记，字段标记等等，这些信息不是作者自己更改的，而是一些特征处理环节所产生的数据，包括画像数据，账号等级，是否封禁等。

在本申请实施例中，管理平台做一些操作时需要调用接口，需要底层的一些服务来支持，能力层则是用于实现这些功能的。如图6所示，能力层主要分为两部分，基础能力和特征工程。

1）基础能力：对用户的一些基础信息进行增删改查的操作，主要是针对作者开户、账号基础信息修改、以及事件通知提供相应的能力，如图6所示包括：高性能读接口，开户/修改，事件池，事件分离，事件分发，定时任务这几部分。

在本申请实施例中，用户在修改一些信息时会触发一些事件，这些事件会存储到事件池中做一些分离、分发的工作，进而给到不同的订阅方。

2）特征工程：对内容、账号等做一些算法分析，通过算法模型对每一个账号打一些特征标记，比如某一账号主要是用于写地域文章的，是女性账号等等。另外，通过结合账号低质、优质程度，发文活跃情况等反向推导账号的生态，分析账号是不是广告营销账号，是不是经常发布含有标题党的文章等等。通过算法模型检测优质账号、低质账号、账号品类，对接内容链路，将各类账号特征提供给推荐侧使用，针对不同等级账号分发不同内容，例如，降低低质账号的降低优先级，不优先推荐该账号所发表的文章。

参阅图6所示，特征工程部分具体包括：优质账号，用户行为，热点账号，潜力账号，发文活跃程度，号主粉丝互动，相似账号，地域账号，女性账号，账号向量工具，信安审核，低质账号，搬运账号，标题党账号，广告营销号，无用账号，变异优质账号等的分析和处理。

在本申请实施例中，数据支持层，用于存储整个作者生态体系各个账号对应的所有元数据，作为整个系统的底层数据支持，元数据包括账号基础数据、账号特征数据、账号流水数据、业务事件等，其中业务事件是通过对基于账号流水信息生成的数据变更消息进行映射而得到的，存储于事件池中。对应的数据库有分布式数据库、CTV、Clickhouse、Hbase、弹性搜索（Elastic search，ES）数据库。

其中，分布式数据库具备强一致高可用、全球部署架构、分布式水平扩展、高性能、企业级安全等特性。Hbase是一个分布式的、面向列的开源数据库。Clickhouse是一个用于联机分析处理的列式数据库管理系统。ES是一个基于全文搜索引擎（Lucene）的搜索服务器。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。

另外，本申请实施例中的分布式账号云存储系统还包括监控部分，用于监控操作流水以及一些异常的打点的数量，如果有异常的情况发生的话，可以及时告警通知。如图6所示，监控包括：ES流水，记录每一条操作的一些详细信息，比如更改了某个字段，相当于操作流水；Monitor，主要用于记录打点信息，比如读字段每天大概请求多少次，相当于数量的统计；007，和Monitor性质相似的监控平台。

需要说明的是，本申请实施例通过收拢账号读写入口，迁移底层数据，合并DB存储，特征数据存储分离等方式，最终的效果数据如下：迁移修复有效账号数据：1600w+；修复绑定关系：6w+；解决搜索问题账号：1k+；发文映射问题：1w+；基础账号信息DB量：由相关技术中的3个变更为1个；特征数据平均读写耗时：由相关技术中的6-8ms变更为1-2ms。很显然，提高了数据处理效率。

下面结合图7所示的又一分布式账号云存储系统的架构示意图，该架构主要体现的是在图6所示的能力层和数据支持层中所做的一些优化策略。

业务层：内容标签系统，内容开放平台，聊天软件入库应用程序编程接口（Application Programming Interface，API），视频软件、浏览器、直播软件，内容开放平台流水同步。

其中，图7所示的业务层内左边的矩形框中介绍的是账号和数据的来源和渠道（对应图6），包括内容标签系统，内容开放平台、聊天软件入库API，视频软件、浏览器、直播软件，内容开放平台流水同步，右边的矩形框介绍的是客户端侧（简称C侧）的数据来源和渠道，包括作者信息查询，其他业务接口。接入层（对应对6中的同一读/写接入层和平台管理层）包括高性能读接口，开户/修改，账号等级，账号搜索，账号审核，消息通知，特征工程等。

图7所示的系统为各个业务方提供了统一读写服务，帮助业务方快速接入不同类型的账号，统一进行权限检查和频率控制，同时也便于统一维护管理。

具体的，在读取数据时，可基于权限检查器（appid+skey）进行鉴权，进而在基于频率控制器进行频率控制。之后，基于逻辑执行器从相应的数据库中读取数据，另外还可通过元数据合并器合并元数据。

同理，在写入数据时，过程同读取过程类似，其中的逻辑执行器用于计算流水日志的modID，进而，通过存储管理器，基于事物写操作写入账号基础数据和账号流水数据。通过特征数据存储管理服务，将账号特征数据写入账号特征数据Hbase。

其中的账号流水数据DB即本申请实施例中的第一数据库，账号基础数据DB即本申请实施例中的第二数据库，账号特征数据Hbase即本申请实施例中的第三数据库。

另外，底层数据统一DB存储，并且存储流水记录，写基础数据和流水数据时采用事物写的方式，确保数据的可回溯。除此之外，图7所示的架构图中也包含了离线的监控对账模块，具体处理过程同上述实施例，重复之处不再赘述。在本申请实施例中，通过每天将DB中数据同步到分布式数据仓库中，定时分析数据，及时发现问题。

在本申请实施例中，考虑到内容中心会针对用户画像进行各种特征提取，特征工程分析模型会处理、加工、更新许多用户特征元数据，推荐侧以及其他业务方需要及时感知字段变更，并且业务方众多，需要在不同时机订阅账号变更各种事件，并且针对解除业务模块的耦合，所以引入了事件中心机制，对于流量进行频率控制，具体的实现方案见图8所示。

参阅图8所示，其为本申请实施例中的一种事件中心机制的具体流程示意图，主要分为以下几步：事件收集、事件推送kafka、配置获取、事件分离、事件分发、事件proxy获取。具体过程如下：

1、新建流水日志，更新账号基础数据与记录数据变更消息在一个事务中完成，所有的流水日志存储在账号流水数据DB（即第一数据库）中。如图8所示，账号流水数据包括：ID，版本（version），标签（label），modID。

2、事件收集服务轮询流水日志的数据，定时从第一数据库中批量获取数据，根据唯一的modID进行分区，同一个modID的内容会进入到同一个分区，可保障局部有序，将数据写入到多个队列中，然后通过多任务写入到Ckafka中，并写入成功后，回写DB状态位，以避免重复写入。

3、基于消息中间件Ckafka来实现消息的推送，Ckafka中会开启partitioner的配置，使用hase选项，通过puin进行分区。

4、然后事件分离分发服务使用多个消费者会消费kafka中消息，同时获取事件映射配置信息，将字段变更映射为业务事件，获取订阅映射配置信息，将业务事件分发到不同的订阅方，然后写入到事件池中。事件池使用分布式MySQL数据库，底层自动分区。

具体的，事件分离/分发服务具体是从远程配置中心中获取事件映射配置信息和订阅映射配置信息。

5、订阅方传入事件获取偏移量，通过事件获取proxy来获取事件。

6、事件清理策略：按天清理，proxy存储当前消息获取方消费记录，用以进行告警和事件清理。

在本申请实施例中，通过引入事件中心机制，最终的效果数据如下：1、30+业务事件分离；2、每天生产事件数据：1千万+；3、事件生效时间近实时；4、可维护性大大提高，业务解耦。

另外还需要说明的是，在本申请实施例中，整个事件中心容错处理情况有以下几种：

情况一、当更新数据和记录消息处理出错，进行事务回滚，相当于什么都没有发生。

情况二、当消息push到kafka出错时，由于消息保存在消息表中，可以重新发送到消息队列（Message Queue，MQ）进行重试。

情况三、如果消息获取订阅方消费处理出错，且是业务上的失败，业务方自行重试。

其中，事件分发给订阅方之前会存到事件池中，针对每一个订阅方，相关的业务事件都会存到对应的DB中。如果订阅方需要消费事件时，是由订阅方主动从事件池DB中拉取的，如过服务失败或者网络不通等情况下，就会造成数据拉取失败，但是实际上数据没有丢失，可以继续从DB中拉取。

通过上述实施方式可知，本申请实施例中的事件中心容错率较高，实现过程更加简单。

综上，本申请实施例中的整个基于事件中心机制的分布式账号云存储系统，由事件驱动，改变了开发模式，由最开始的同步调用变成了消息推送，将业务模块解耦，支持监听多种字段变更事件，如第一次写入、更新、变更为预期值等，基于事件中心机制统一账号事件管理，有效提高了数据存储的安全性和数据处理效率。

参阅图9所示，其为本申请实施例中的一种账号数据处理的完整方法流程图。该方法的具体实施流程如下：

步骤S901：服务器通过预设读写模块为指定业务方接入不同类型的账号；

步骤S902：服务器获取指定业务方在预置时间段内相关的各个账号对应的账号流水数据，通过事物写操作将账号流水数据写入第一数据库；

步骤S903：服务器获取指定业务方在预置时间段内相关的各个账号对应的账号基础数据，并通过事物写的方式将账号基础数据写入第二数据库；

步骤S904：服务器获取指定业务方在预置时间段内相关的各个账号对应的账号特征数据，并将账号特征数据写入文档型的第三数据库；

步骤S905：服务器基于账号特征数据对各个账号进行等级划分，并将划分结果发送给推荐系统，以使推荐系统针对不同等级账号分发不同内容；

步骤S906：服务器通过事件收集模块从第一数据库中批量获取账号流水数据，第一数据库中存储有与指定业务方相关的各个账号对应的账号流水数据；

步骤S907：服务器将获得的账号流水数据写入消息队列，并通过消息队列向事件分发模块推送基于账号流水数据生成的数据变更消息；

步骤S908：服务器通过事件分发模块将数据变更消息映射为业务事件，并存储至事件池中；

步骤S909：服务器接收到消息获取方发送的事件获取请求时，基于事件获取请求中的索引信息，从事件池中获取与索引信息对应的业务事件并发送至消息获取方；

步骤S910：服务器通过代理服务器存储消息获取方对应的事件获取记录；

步骤S911：服务器基于事件获取记录以及预设事件清理策略，清理事件池中的业务事件。

需要说明的是，本申请实施例结合业务的特点，在图1所示的内容中心账号体系内容开放平台的基础上提出了数据存储优化，引入了事件中心机制，最终实现了一种基于事件中心机制的分布式账号云存储系统。

基于相同的发明构思，本申请实施例还提供一种数据处理装置。如图10所示，其为数据处理装置1000的结构示意图，可以包括：

收集单元1001，用于通过事件收集模块从第一数据库中批量获取采样数据，第一数据库中存储有与指定业务方相关的各个对象对应的采样数据；

消息单元1002，用于将获得的采样数据写入消息队列，并通过消息队列向事件分发模块推送基于采样数据生成的数据变更消息；

映射单元1003，用于通过事件分发模块将数据变更消息映射为业务事件，并存储至事件池中；

订阅单元1004，用于接收到消息获取方发送的事件获取请求时，基于事件获取请求中的索引信息，从事件池中获取与索引信息对应的业务事件并发送至消息获取方。

可选的，映射单元1003具体用于：

通过事件分发模块获取预设的事件映射配置信息，基于事件映射配置信息，确定数据变更消息中的变更字段对应的业务事件类型后，将数据变更消息映射为业务事件类型对应的业务事件，其中，事件映射配置信息用于表征字段与业务事件类型之间的映射关系；

通过事件分发模块获取预设的订阅映射配置信息，基于订阅映射配置信息，确定各个业务事件对应的消息获取方，其中，订阅映射配置信息用于表征业务事件与消息获取方之间的映射关系；

根据各个业务事件对应的消息获取方，将各个业务事件写入到事件池中对应的事件数据库，其中，不同消息获取方在事件池中对应不同的事件数据库。

可选的，数据变更消息包含多个对应同一业务事件类型的变更字段；映射单元1003具体用于：

分别将数据变更消息中的各个变更字段映射为业务事件类型对应的业务事件；

在将数据变更消息映射为业务事件类型对应的业务事件之后，还包括：

将基于多个对应同一业务事件类型的变更字段映射得到的多个业务事件，进行事件合并。

可选的，消息单元1002具体用于：

根据采样数据对应的模块标识对采样数据进行分区处理，其中，具有相同模块标识的采样数据划分为同一分区，采样数据对应的模块标识是通过对采样数据的对象标识进行取模得到的；

将分区后的采样数据并行写入消息队列。

可选的，装置还包括：

第一读写单元1005，用于在收集单元1001通过事件收集模块从第一数据库中批量获取采样数据之前，获取指定业务方在预置时间段内相关的各个对象对应的采样数据；

通过事物写操作将采样数据写入第一数据库。

可选的，装置还包括：

第二读写单元1006，用于在收集单元1001通过事件收集模块从第一数据库中批量获取采样数据之前，获取指定业务方在预置时间段内相关的各个对象对应的基础数据，并通过事物写的方式将基础数据写入第二数据库；以及

获取指定业务方在预置时间段内相关的各个对象对应的特征数据，并将特征数据写入文档型的第三数据库。

可选的，装置还包括：

特征处理单元1007，用于基于特征数据对各个对象进行等级划分，并将划分结果发送给推荐系统，以使推荐系统针对不同等级对象分发不同内容。

可选的，装置还包括：

业务单元1008，用于在收集单元1001通过事件收集模块从第一数据库中批量获取采样数据之前，还包括：

通过预设读写模块为指定业务方接入不同类型的对象，并对各个对象统一进行权限检查和频率控制。

可选的，索引信息为事件获取偏移量；订阅单元1004具体用于：

根据事件获取请求中的事件获取偏移量，确定待获取的业务事件的地址信息；

根据地址信息从事件池中获取对应的业务事件，并发送至消息获取方。

可选的，装置还包括：

清理单元1009，用于在订阅单元1004从事件池中获取与索引信息对应的业务事件并发送至消息获取方之后，通过代理服务器存储消息获取方对应的事件获取记录；

基于事件获取记录以及预设事件清理策略，清理事件池中的业务事件。

在上述实施方式中，解除了业务模块的耦合，引入了事件中心机制，基于事件中心机制统一对象事件管理，实现了消息实时通知和消息数据的可靠性，消息数据独立存储，不占用业务系统资源，降低业务系统与消息系统之间的耦合，尽量与业务隔离，防止消息系统异常影响基本存储访问。针对不同的业务产品，给用户提供安全、高可靠的对象数据存储，并且基于事件中心机制统一对象事件管理，提高数据存储的安全性和数据处理效率。

为了描述的方便，以上各部分按照功能划分为各模块（或单元）分别描述。当然，在实施本申请时可以把各模块（或单元）的功能在同一个或多个软件或硬件中实现。

在介绍了本申请示例性实施方式的数据处理方法和装置之后，接下来，介绍根据本申请的另一示例性实施方式的电子设备。

所属技术领域的技术人员能够理解，本申请的各个方面可以实现为系统、方法或程序产品。因此，本申请的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式（包括固件、微代码等），或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。

与上述方法实施例基于同一发明构思，本申请实施例中还提供了一种电子设备。在一种实施例中，该电子设备可以是服务器，如图2所示的服务器110。在该实施例中，电子设备的结构可以如图11所示，包括存储器1101，通讯模块1103以及一个或多个处理器1102。

存储器1101，用于存储处理器1102执行的计算机程序。存储器1101可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统，以及运行即时通讯功能所需的程序等；存储数据区可存储各种即时通讯信息和操作指令集等。

存储器1101可以是易失性存储器（volatile memory），例如随机存取存储器（random-access memory，RAM）；存储器1101也可以是非易失性存储器（non-volatilememory），例如ROM，快闪存储器（flash memory），硬盘（hard disk drive，HDD）或固态硬盘（solid-state drive，SSD）；或者存储器1101是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器1101可以是上述存储器的组合。

处理器1102，可以包括一个或多个中央处理单元（central processing unit，CPU）或者为数字处理单元等等。处理器1102，用于调用存储器1101中存储的计算机程序时实现上述任意一种数据处理方法。

通讯模块1103用于与终端设备和其他服务器进行通信。

本申请实施例中不限定上述存储器1101、通讯模块1103和处理器1102之间的具体连接介质。本申请实施例在图11中以存储器1101和处理器1102之间通过总线1104连接，总线1104在图11中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。总线1104可以分为地址总线、数据总线、控制总线等。为便于表示，图11中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器1101中存储有计算机存储介质，计算机存储介质中存储有计算机可执行指令，计算机可执行指令用于实现本申请实施例的数据处理方法。处理器1102用于执行上述的数据处理方法，如图3所示。

在一些可能的实施方式中，本申请提供的数据处理方法的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当程序产品在计算机设备上运行时，程序代码用于使计算机设备执行本说明书上述描述的根据本申请各种示例性实施方式的数据处理方法中的步骤，例如，计算机设备可以执行如图3中所示的步骤。

程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子（非穷举的列表）包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器（RAM）、只读存储器（ROM）、可擦式可编程只读存储器（EPROM或闪存）、光纤、便携式紧凑盘只读存储器（CD-ROM）、光存储器件、磁存储器件、或者上述的任意合适的组合。

本申请的实施方式的程序产品可以采用便携式紧凑盘只读存储器（CD-ROM）并包括程序代码，并可以在计算装置上运行。然而，本申请的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被命令执行系统、装置或者器件使用或者与其结合使用。

可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由命令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本申请操作的程序代码，程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算装置上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算装置上部分在远程计算装置上执行、或者完全在远程计算装置或服务器上执行。在涉及远程计算装置的情形中，远程计算装置可以通过任意种类的网络包括局域网（LAN）或广域网（WAN）连接到用户计算装置，或者，可以连接到外部计算装置（例如利用因特网服务提供商来通过因特网连接）。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (15)

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

通过事件收集模块从第一数据库中批量获取采样数据，所述第一数据库中存储有与指定业务方相关的各个对象对应的采样数据；

将获得的采样数据写入消息队列，并通过所述消息队列向事件分发模块推送基于所述采样数据生成的数据变更消息；

通过所述事件分发模块将所述数据变更消息映射为业务事件，并存储至事件池中；

接收到消息获取方发送的事件获取请求时，基于所述事件获取请求中的索引信息，从所述事件池中获取与所述索引信息对应的业务事件并发送至所述消息获取方。

2.如权利要求1所述的方法，其特征在于，所述通过所述事件分发模块将所述数据变更消息映射为业务事件，并存储至事件池中，包括：

通过所述事件分发模块获取预设的事件映射配置信息，基于所述事件映射配置信息，确定所述数据变更消息中的变更字段对应的业务事件类型后，将所述数据变更消息映射为所述业务事件类型对应的业务事件，其中，所述事件映射配置信息用于表征字段与业务事件类型之间的映射关系；

通过所述事件分发模块获取预设的订阅映射配置信息，基于所述订阅映射配置信息，确定各个业务事件对应的消息获取方，其中，所述订阅映射配置信息用于表征业务事件与消息获取方之间的映射关系；

根据各个业务事件对应的消息获取方，将所述各个业务事件写入到所述事件池中对应的事件数据库，其中，不同消息获取方在所述事件池中对应不同的事件数据库。

3.如权利要求2所述的方法，其特征在于，所述数据变更消息包含多个对应同一业务事件类型的变更字段；所述将所述数据变更消息映射为所述业务事件类型对应的业务事件，包括：

分别将所述数据变更消息中的各个变更字段映射为所述业务事件类型对应的业务事件；

在所述将所述数据变更消息映射为所述业务事件类型对应的业务事件之后，还包括：

将基于所述多个对应同一业务事件类型的变更字段映射得到的多个业务事件，进行事件合并。

4.如权利要求1所述的方法，其特征在于，所述将获得的采样数据写入消息队列，包括：

根据所述采样数据对应的模块标识对所述采样数据进行分区处理，其中，具有相同模块标识的采样数据划分为同一分区，所述采样数据对应的模块标识是通过对所述采样数据的对象标识进行取模得到的；

将分区后的采样数据并行写入所述消息队列。

5.如权利要求1所述的方法，其特征在于，在所述通过事件收集模块从第一数据库中批量获取采样数据之前，还包括：

获取所述指定业务方在预置时间段内相关的各个对象对应的采样数据；

通过事物写操作将所述采样数据写入所述第一数据库。

6.如权利要求1所述的方法，其特征在于，在所述通过事件收集模块从第一数据库中批量获取采样数据之前，还包括：

获取所述指定业务方在预置时间段内相关的各个对象对应的基础数据，并通过事物写的方式将所述基础数据写入第二数据库；以及

获取所述指定业务方在预置时间段内相关的各个对象对应的特征数据，并将所述特征数据写入文档型的第三数据库。

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

基于所述特征数据对各个对象进行等级划分，并将划分结果发送给推荐系统，以使所述推荐系统针对不同等级对象分发不同内容。

8.如权利要求1所述的方法，其特征在于，在所述通过事件收集模块从第一数据库中批量获取采样数据之前，还包括：

通过预设读写模块为所述指定业务方接入不同类型的对象，并对所述各个对象统一进行权限检查和频率控制。

9.如权利要求1~8任一项所述的方法，其特征在于，所述索引信息为事件获取偏移量；所述基于所述事件获取请求中的索引信息，从所述事件池中获取与所述索引信息对应的业务事件并发送至所述消息获取方，包括：

根据所述事件获取请求中的事件获取偏移量，确定待获取的业务事件的地址信息；

根据所述地址信息从所述事件池中获取对应的业务事件，并发送至所述消息获取方。

10.如权利要求1~8任一项所述的方法，其特征在于，在所述从所述事件池中获取与所述索引信息对应的业务事件并发送至所述消息获取方之后，还包括：

通过代理服务器存储所述消息获取方对应的事件获取记录；

基于所述事件获取记录以及预设事件清理策略，清理所述事件池中的业务事件。

11.一种数据处理装置，其特征在于，包括：

收集单元，用于通过事件收集模块从第一数据库中批量获取采样数据，所述第一数据库中存储有与指定业务方相关的各个对象对应的采样数据；

消息单元，用于将获得的采样数据写入消息队列，并通过所述消息队列向事件分发模块推送基于所述采样数据生成的数据变更消息；

映射单元，用于通过所述事件分发模块将所述数据变更消息映射为业务事件，并存储至事件池中；

订阅单元，用于接收到消息获取方发送的事件获取请求时，基于所述事件获取请求中的索引信息，从所述事件池中获取与所述索引信息对应的业务事件并发送至所述消息获取方。

12.如权利要求11所述的装置，其特征在于，所述映射单元具体用于：

通过所述事件分发模块获取预设的事件映射配置信息，基于所述事件映射配置信息，确定所述数据变更消息中的变更字段对应的业务事件类型后，将所述数据变更消息映射为所述业务事件类型对应的业务事件，其中，所述事件映射配置信息用于表征字段与业务事件类型之间的映射关系；

通过所述事件分发模块获取预设的订阅映射配置信息，基于所述订阅映射配置信息，确定各个业务事件对应的消息获取方，其中，所述订阅映射配置信息用于表征业务事件与消息获取方之间的映射关系；

根据各个业务事件对应的消息获取方，将所述各个业务事件写入到所述事件池中对应的事件数据库，其中，不同消息获取方在所述事件池中对应不同的事件数据库。

13.如权利要求12所述的装置，其特征在于，所述数据变更消息包含多个对应同一业务事件类型的变更字段；所述映射单元具体用于：

分别将所述数据变更消息中的各个变更字段映射为所述业务事件类型对应的业务事件；

在所述将所述数据变更消息映射为所述业务事件类型对应的业务事件之后，还包括：

将基于所述多个对应同一业务事件类型的变更字段映射得到的多个业务事件，进行事件合并。

14.一种电子设备，其特征在于，其包括处理器和存储器，其中，所述存储器存储有程序代码，当所述程序代码被所述处理器执行时，使得所述处理器执行权利要求1~10中任一所述方法的步骤。

15.一种计算机可读存储介质，其特征在于，其包括程序代码，当程序产品在电子设备上运行时，所述程序代码用于使所述电子设备执行权利要求1~ 10中任一所述方法的步骤。

Images