CN111221831B - 一种对广告效果数据实时处理的计算系统 - Google Patents

Abstract

本发明公开了一种对广告效果数据实时处理的计算系统，包括数据收集服务器集群、数据传输服务器、数据实时处理服务器集群、数据存储服务器集群；本发明系统基于Kafka‑Stream模块开发了实时计算框架SW‑Kafka‑Stream，完全原生兼容Kafka的设计模式，提供简单高效的流式计算功能，同时采用Pikamgr为数据存储服务提供平台化的运维管理、性能监视、配置自动更新等功能；因此，本发明系统可以快速对大流量场景下的业务需求提供数据支持，且一条采集数据从接收落地到实时计算完成的全流程时延在亚秒级以内，同时提供低成本但可靠高效的存储集群和便捷的集群管理平台。

Description

一种对广告效果数据实时处理的计算系统

技术领域

本发明属于大数据实时计算存储技术领域，具体涉及一种对广告效果数据实时处理的计算系统。

背景技术

随着公司广告业务的不断发展，业务量逐渐上升，原有的实时数据处理方案已经越来越不能满足业务需求，越来越多的问题显现出来：采集数据容易丢失；无标准的实时数据处理流程，存在隐患；数据存储集群无法平台化管理，运维效率低，出错概率大。

为了解决这些问题，调研了目前流行的技术方案如下：

(1)数据收集服务

目前业界的数据收集服务大多都根据自身业务数据采集的需求进行定制，并且在数据收集到之后即把数据按照规则逐一写入文件，不涉及到其他处理。这也是比较统一的做法，因此我们的数据收集服务也会基于这一收集流程以及广告业务数据采集的需求来定制广告业务数据收集服务，这样做的好处有：完全符合自身数据采集的需要，无需做各种妥协处理；数据直接写入文件，尽可能确保了数据的安全性和完整性，为后续的数据处理提供保障。

(2)数据传输服务

目前业界流行以下三组方案：

Logstash，由Elastic公司开源，基于JRuby开发的数据传输工具，支持的功能包括：从多种数据源读取数据(kafka、file、redis等等)、对数据进行过滤和简单的解析、将数据导入多种数据存储组件(elasticsearch、kafka、redis、influxdb等等)，功能支持十分强大，同时也支持自定义的插件来扩展功能，但是在我们的场景下存在以下问题：①Logstash基于JRuby开发，部署运维复杂，并且运行效率也不太高；②Logstash跑起来之后，占用资源也比较大，cpu和内存使用量都较大；③虽然Logstash支持的功能很丰富，但是在我们的场景下基本用不到复杂的过滤、解析功能；④再就是团队技术栈的问题，目前Ruby对于我们来说还太小众，后期运维过程中的问题排查和维护的难度都不小。

Flume，apache基金会的顶级项目，最早由cloudera公司使用Java开发，整个程序架构比较清晰，由source、channel、sink三部分组成，我们在使用Flume的过程中，发现Flume存在以下问题：①运行起来之后，资源暂用比较多；②对于同一目录下的多文件并行处理的能力有限。

Filebeat，由Elastic公司开源，基于Golang开发的数据传输工具，非常轻量级，因而支持的功能相对较弱，代码结构清晰，模块之间耦合度很低，可以很容易的扩展个性化的功能。

(3)数据实时处理服务

实时计算的产生即来源于对于数据加工时效性的严苛需求，数据的业务价值随着时间的流失而迅速降低，因此在数据发生后必须尽快对其进行计算和处理；像我们的广告业务，在广告投放流程中的实时控量就是对数据加工时效性的最有力证明。

目前在数据实时处理这块，业界都会使用流式处理框架来解决数据处理的实时性和交付保障，常见的方案有以下三种：

Storm，纯实时的流式处理框架，应用也很广泛，但是最大的不足是仅能保证“AtMost Once”(最多一次)和“At Least Once”(最少一次)的消息投递语义，即可能存在重复发送的情况。在对数据的精确性要求比较高的业务场景中无法很好地满足“Exactly Once”(精确一次)的语义，像广告系统中的实时控量、结算等都是对数据准确度具有较高的要求，因此很难满足我们的业务场景。

Spark streaming，应用较广泛的流式处理框架，社区非常强大，支持非常多的输入源(Kafka、Flume、HDFS等)，可独立部署也可以与Hadoop结合取代MapReduce，完全在内存中进行计算，最多只会在输入输出时与存储层交互。Spark streaming是Spark框架的流处理模式，属于准实时处理(微批处理的方式)，相比于真正的流处理框架性能存在不足，不适合对延时有较高需要的业务场景，比如我们的广告投放流程中的实时控量的业务场景。

Flink，最近两年非常流行的纯实时流式计算框架，支持流式计算的很多高级功能(如Event Time Processing、Watermarksd等)，支持“Exactly Once”(精确一次)的语义，低延时高吞吐量；但是对于我们小团队来说，维护Flink的成本有点高，而且Flink有很多功能我们也用不上，跟维护成本和资源投入相比就很不划算。

(4)数据存储服务

我们广告投放流程中的标签匹配、实时控量，并发查询量非常大，并且对查询的延时要求很苛刻，而且数据量相对较大，针对大数据量、高并发、低延时场景下的数据存储，业界常见的方案有以下三种：

Redis集群，使用Redis-Cluster或者Codis/Twemproxy+Redis的集群方式搭建Redis集群，由于Redis数据都存储在内存中，因此支持的并发查询量很高，而且查询延时很低，但是也正是因为数据存储在内存中导致存储成本非常高，而且由于服务器资源始终是有限的，因此当数据量达到一定规模后，存储容量将是很大的挑战。另外，由于数据存储在内存中，如果Redis实例挂掉，那么内存中原有的数据将丢失，虽然Redis有持久化的方案(RDB/AOF)，但是在数据量非常大的情况下，Redis的持久化方案对于Redis实例挂掉重启后的数据恢复来说效率很低。

Memcached集群，使用Twemproxy+Memcached的集群方式来搭建Memcached集群；和Redis一样，Memcached也是把数据存储在内存中，而且Memcached没有持久化方案，那么也会遇到Redis相同的重启数据恢复的问题。

360-Pika集群，360-Pika是360公司开源的存储组件，数据存储在硬盘上，底层的存储引擎是Rocksdb，兼容Redis协议(支持绝大多数Redis命令)；360-Pika单实例在合理的配置下支持的并发查询量跟单实例的内存型存储组件(Redis/Memcached)相差不大(仅限KV格式的数据)，查询延时TP99较单实例的内存型存储组件高3～5ms，这些指标完全符合我们的业务场景，而且数据存储在磁盘，并且会对数据进行压缩，很大程度上可以降低存储成本。

由于我们的数据种类比较多，为了减小对业务服务的入侵，我们需要在存储层对不同类型的数据做隔离，因此就需要搭建一套集群来管理多种类型的数据。使用360-PikaMaster-Slave或者Codis+360-Pika的集群方式来搭建360-Pika集群，这两种集群方式在使用过程中存在如下问题：

360-Pika Master-Slave集群方式，由于多种类型的数据，需要多组Master-Slave，单纯的Master-Slave集群方式不带有集群自组织管理的功能，因此多组Master-Slave的管理会非常困难。Codis+360-Pika的集群方式，结合Master-Slave模式，可以很好的解决多组Master-Slave管理困难的问题，但是在实际的使用过程中存在如下问题：

①虽然360-Pika兼容Redis协议，可以使用Codis+360-Pika的方式搭建集群，但是360-Pika毕竟跟Redis还是有很多不同的地方，比如存储方式、线程模型、Info信息、事务块命令等，正因为如此，在使用Codis+360-Pika组合方案时，总是有很多别扭的地方，并且如果想做到不同业务数据的隔离，需要从Codis-Proxy层就开始进行隔离，导致网络拓扑较为复杂。

②在对Codis+360-pika组合方案进行压测的时候，总有2～3％的请求时延在40-50ms以上，并且无论对Codis-Proxy、360-Pika的配置如何优化、或者增加Codis-Proxy节点，都依旧存在这个问题；毕竟360-Pika和Redis的数据存储方式不同，pika的数据存储在磁盘，存取效率要比Redis差一些，再加上一些大K/V的影响、Codis-Proxy环节的性能消耗，最终导致某些问题无法避免。

大流量广告业务场景具有如下特点：1.广告曝光量很大，单次广告曝光到广告投放控制再到广告展示的全流程都需要采集并实时处理分析，因此需要计算的数据量非常大；2.广告业务相关数据的采集端多种多样，如PC软件、网站、移动App等；3.分析后的结果数据需要实时提供给广告投放服务用作广告消耗控制、广告打分等功能，数据处理的实时性要求很高；4.广告的投放周期不固定，因此分析后的结果数据需要保留的期限也不固定，但某条广告投放周期内必须保证其相关数据正常且不丢失；5.广告业务系统也是交易系统的一种，对整个系统以及周边辅助系统的准确性和稳定性要求很高。

发明内容

鉴于上述且针对大流量广告业务场景，本发明提供了一种对广告效果数据实时处理的计算系统，能够在数据采集、数据传输、数据实时处理、数据存储整个流程的各个环节提供轻量、低维护成本、低运维成本的技术方案。

一种对广告效果数据实时处理的计算系统，包括数据收集服务器集群、数据传输服务器、数据实时处理服务器集群、数据存储服务器集群，其中：

所述数据收集服务器集群用于为多样的数据采集端提供统一的数据收集入口，并按照制定的数据采集规范将收集到的数据写入文件，同时集群中的每台数据收集服务器均为无状态服务，在性能不足时可以很方便的进行扩展；

所述数据传输服务器依托于数据采集规范将写入文件的数据实时传输到MQ(消息中间件)，即保障了数据持久性又降低了数据实时处理服务与数据收集服务之间的耦合度，并且支持断点续传功能；

所述数据实时处理服务器集群用于从MQ中实时读取数据并按照对应数据分析及存储需求进行拆分、计算并将处理结果数据写入数据存储服务器集群，保证了数据处理的及时性；另外即便是集群有一定比例的服务实例挂掉，依然可以继续正常对MQ中的数据进行处理；

所述数据存储服务器集群用于提供数据备份、快速错误恢复的功能，数据存储在磁盘，这大大降低了存储成本并且允许存储较大的数据量，并且同时保证了数据存取的性能；另外数据存储服务器集群还提供了相应的管理平台，最大程度减少运维复杂度和集群日常维护的工作量。

进一步地，所述数据收集服务器集群根据自身业务场景编写数据采集服务，支持多样的采集端，支持使用HTTP/HTTPS/TCP协议进行数据上报，制定了包括采集文件的状态、采集数据的组织格式在内的数据采集规范，并根据该规范把采集数据逐条写入文件，同时支持动态新增、修改、删除收集任务，对正在进行的收集任务不会有任何影响，支持查看收集任务的实时状态。

进一步地，所述数据传输服务器基于elastic公司开源的filebeat-v6.4进行了功能扩充，支持数据采集规范中定义的采集文件状态转换功能以及数据输出格式，支持timezone时区的配置，支持将文件中的数据实时传输至MQ，随时跟进Filebeat的最新功能，MQ使用Kafka-2.0。

进一步地，所述数据实时处理服务器集群基于Kafka-2.0提供的Kafka-Stream库搭建轻量级的流式计算框架SW-Kafka-Stream，完全原生兼容Kafka的设计模式，提供简单高效的流式计算功能。

进一步地，所述流式计算框架SW-Kafka-Stream对于需要实时处理任务提供弹性支持，业务对采集数据的处理需求变更无需修改代码，并提供以下功能以保证计算的灵活性；

(1)支持实时数据的格式配置，业务数据本身的格式可通过配置来说明，且支持两种格式：JSON格式的数据以及分隔符分隔的数据；

(2)支持实时数据处理规则的配置，业务对采集数据的处理需求完全可以通过配置规则来进行自动计算；

(3)支持将计算结果输出到多种数据存储组件，可通过配置来指定。

进一步地，所述数据存储服务器集群采用开源组件360-Pika，支持数据备份、快速错误恢复，提供较低的存储成本(数据存储在磁盘)的同时保证了存取性能，同时使用了LVS+Keepalived+HAProxy结合的高可用方案，360-Pika的实时监控方案使用Pika-Exporter并结合Prometheus和Grafana进行实时监控指标数据的展示和告警。

进一步地，所述数据存储服务器集群采用Pikamgr管理平台对集群进行管理，Pikamgr管理平台支持Pika实例的运维管理、性能监视、HAProxy和LVS的自动化配置更新，在保证存储效率和尽可能提高稳定性的同时也大大降低了运维复杂度和日常维护的工作量。

进一步地，所述Pikamgr管理平台包括Pika-Dashboard和Pika-FE两个服务，其中Pika-FE为前端页面提供API接口服务，Pika-Dashboard为集群管理功能提供支撑，使得Pikamgr管理平台具备以下功能：

(1)360-Pika实例的多集群、多分组管理；

(2)360-Pika的性能监视包括QPS、CPU、Connection等；

(3)LVS、Haproxy集群的管理，HAProxy和LVS的配置自动化更新；

(4)使用Redis-Sentinel作为360-Pika的Master-Slave关系的维护，自动下发360-Pika的分组信息至Redis-Sentinel；

(5)360-Pika实例、LVS、HAPrroxy、Redis-Sentinel异常状态显示；

(6)360-Pika的紧急问题修复操作。

基于上述技术方案，本发明系统基于Kafka-Stream模块开发了实时计算框架SW-Kafka-Stream，完全原生兼容Kafka的设计模式，提供简单高效的流式计算功能，同时采用Pikamgr为数据存储服务提供平台化的运维管理、性能监视、配置自动更新等功能；因此，本发明系统可以快速对大流量场景下的业务需求提供数据支持，且一条采集数据从接收落地到实时计算完成的全流程时延在亚秒级以内，同时提供低成本但可靠高效的存储集群和便捷的集群管理平台。

附图说明

图1为本发明系统的数据流程示意图。

图2为本发明系统的整体架构示意图。

图3为本发明数据存储管理平台Pikamgr的整体架构示意图。

具体实施方式

为了更为具体地描述本发明，下面结合附图以及具体实施方式对本发明的技术方案进行详细说明。

本发明对广告效果数据实时处理的计算系统，包括数据收集服务集群、数据传输服务、数据实时处理服务集群、数据存储集群；其中：

数据收集服务集群为多样的数据采集端提供统一的数据收集入口，并按照制定的数据采集规范将收集到的数据写入文件，同时数据收集服务集群中的每个数据收集服务均为无状态服务，在性能不足时可以很方便的进行扩展。

本实施方式中数据采集服务根据自身业务场景编写数据采集服务，可以选择支持HTTP/HTTPS/TCP上报，按照制定的数据采集规范(包括：采集文件的状态、采集数据的组织格式)把采集数据逐条写入文件，如我们自研的SWLogger。

数据传输服务依托于数据采集规范将写入文件的数据实时的传输到MQ，即保障了数据持久性又降低了数据实时处理服务与数据收集服务之间的耦合度，并且支持断点续传功能。本实施方式中数据传输服务在不影响Filebeat原始代码的基础上对Filebeat的功能进行扩充，支持自定义的数据采集规范以及数据输出格式，可以随时跟进Filebeat的最新功能，MQ使用Kafka-2.0。

数据实时处理服务集群从MQ中实时读取数据并按照对应数据分析及存储需求进行拆分、计算并写入目标存储，保证了数据处理的及时性，另外，即便是数据实时处理服务集群有一定比例的服务实例挂掉，依然可以继续正常对MQ中的数据进行处理。

本实施方式中数据实时计算服务集群使用Kafka-Stream库搭建轻量级的流式计算框架SW-Kafka-Stream，Kafka-Stream原生支持Kafka的数据消费模式，提供简单高效的流式计算功能；SW-Kafka-Stream对于需要实时处理任务提供弹性支持，业务对采集数据的处理需求变更无需修改代码，通过以下功能提供计算的灵活性：

①实时数据的格式配置，业务数据本身的格式为何可通过配置来说明，目前支持两种格式：JSON格式的数据、分隔符分隔的数据；

②实时数据处理规则的配置，业务对采集数据的处理需求完全可以通过配置规则来进行自动计算；

③支持将计算结果输出到多种数据存储组件，可通过配置来指定。

数据存储服务集群提供数据备份、快速错误恢复等功能，数据存储在磁盘，这大大降低了存储成本并且允许存储较大的数据量，并且同时保证了数据存取的性能。另外还提供了数据存储服务群管理平台，最大程度减少运维复杂度和存储集群日常维护的工作量。

本实施方式中数据存储服务集群的存储组件选择360-Pika，使用自研的Pikamgr对360-Pika的集群进行管理，Pikamgr管理平台包括Pika-Dashboard和Pika-FE两个服务，其中Pika-FE为前端页面提供API接口服务，Pika-Dashboard为集群管理功能提供支撑，Pikamgr管理平台所包含的功能：

①360-Pika实例的多集群、多分组管理；

②360-Pika的性能监视：QPS、CPU、Connection等；

③LVS、Haproxy集群的管理，HAProxy和LVS的配置自动化更新；

④使用Redis-Sentinel作为360-Pika的Master-Slave关系的维护，自动下发360-Pika的分组信息至Redis-Sentinel；

⑤360-Pika实例、LVS、HAPrroxy、Redis-Sentinel异常状态显示；

⑥360-Pika的紧急问题修复操作。

如图1所示，本实例中数据从数据采集服务(SWLogger)到逐条存入文件，再由数据传输服务(SWFilebeat)实时将文件中的数据逐条发送到Kafka，接着由基于Kafka-Stream库开发的SW-Kafka-Stream实时计算框架实时从Kafka拖取数据根据所配置的实时数据格式以及实时数据的处理规则将计算后的数据按照所配置存储组件的地址写入存储组件，计算结果通过LVS+Haproxy写入360-Pika。

如图2所示，本实例系统整体架构主要包含以下几个部分：

数据采集服务-SWLogger，负责接收上报的数据，属于无状态服务，可按需部署多个SWLogger实例；

数据传输服务-SWFilebeat，负责实时传输采集文件中的数据到Kafka，负责维护采集文件的状态(log、freeze、complete)；

MQ-Kafka，此组件完全使用开源的Kafka组件，可参照Kafka的官方文档，负责采集数据的临时存储以及将数据发往数据的多个消费方；

Zookeeper，此组件完全使用开源的Zookeeper组件，负责Kafka集群状态数据的存储；

SW-Kafka-Stream，基于Kafka-Stream开发的实时计算框架，负责按照实时处理任务相关的配置从Kafka拖取数据进行计算，并将计算结果按照输出配置写入存储组件，可部署多个计算组分别按照各自的计算任务对数据进行处理；

Storage Cluster，Pikamgr管理平台所管理的数据存储集群，负责存储SW-Kafka-Stream的计算结果。

如图3所示，本实例Pikamgr管理平台整体架构主要包含以下几个部分：

LVS+HAProxy，这两个组件完全是开源的，在Linux2.4.23之后的版本内核中已经内置了LVS，再结合Keepalived、HAProxy对360-Pika提供高可用支持；

Confd，完全开源的配置更新组件，负责监听配置内容的变动以及更新LVS、HAProxy的配置；

360-Pika，完全开源的数据存储组件，负责存储SW-Kafka-Stream发送过来的计算结果数据；

Pika-FE，Pikamgr管理平台的服务之一，负责为管理平台的前端页面提供API接口；

Pika-Dashboard，Pikamgr管理平台的服务之一，负责集群管理功能的具体执行；

Pika-Exporter，360-Pika的监控指标数据实时采集组件，负责实时采集360-Pika的运行信息并组织成Prometheus所需要的数据格式；

Prometheus，完全开源的实时监控和告警系统，负责定时从Pika-Exporter拉取指标数据进行存储以及及时告警；

Grafana，完全开源的数据可视化组件，负责实时展示Prometheus中的指标数据。

上述对实施例的描述是为便于本技术领域的普通技术人员能理解和应用本发明。熟悉本领域技术的人员显然可以容易地对上述实施例做出各种修改，并把在此说明的一般原理应用到其他实施例中而不必经过创造性的劳动。因此，本发明不限于上述实施例，本领域技术人员根据本发明的揭示，对于本发明做出的改进和修改都应该在本发明的保护范围之内。

Claims (2)

1.一种对广告效果数据实时处理的计算系统，包括数据收集服务器集群、数据传输服务器、数据实时处理服务器集群、数据存储服务器集群，其特征在于：

所述数据收集服务器集群用于为多样的数据采集端提供统一的数据收集入口，并按照制定的数据采集规范将收集到的数据写入文件，同时集群中的每台数据收集服务器均为无状态服务，在性能不足时方便进行扩展；

所述数据传输服务器依托于数据采集规范将写入文件的数据实时传输到MQ，即保障了数据持久性又降低了数据实时处理服务与数据收集服务之间的耦合度，并且支持断点续传功能；

所述数据实时处理服务器集群用于从MQ中实时读取数据并按照对应数据分析及存储需求进行拆分、计算并将处理结果数据写入数据存储服务器集群，保证了数据处理的及时性；即使集群有一定比例的服务实例挂掉，依然继续正常对MQ中的数据进行处理；

所述数据存储服务器集群用于提供数据备份、快速错误恢复的功能，数据存储在磁盘，并且同时保证了数据存取的性能；另外数据存储服务器集群还提供了相应的管理平台；

所述数据收集服务器集群根据自身业务场景编写数据采集服务，支持多样的采集端，支持使用HTTP/HTTPS/TCP协议进行数据上报，制定了包括采集文件的状态、采集数据的组织格式在内的数据采集规范，并根据该规范把采集数据逐条写入文件，同时支持动态新增、修改、删除收集任务，对正在进行的收集任务不会有任何影响，支持查看收集任务的实时状态；

所述数据传输服务器基于elastic公司开源的filebeat-v6.4进行了功能扩充，支持数据采集规范中定义的采集文件状态转换功能以及数据输出格式，支持timezone时区的配置，支持将文件中的数据实时传输至MQ，随时跟进Filebeat的最新功能，MQ使用Kafka-2.0；

所述数据实时处理服务器集群基于Kafka-2.0提供的Kafka-Stream库搭建轻量级的流式计算框架SW-Kafka-Stream，完全原生兼容Kafka的设计模式，提供简单高效的流式计算功能；

所述流式计算框架SW-Kafka-Stream对于需要实时处理任务提供弹性支持，业务对采集数据的处理需求变更无需修改代码，并提供以下功能以保证计算的灵活性；

(1)支持实时数据的格式配置，业务数据本身的格式通过配置来说明，且支持两种格式：JSON格式的数据以及分隔符分隔的数据；

(2)支持实时数据处理规则的配置，业务对采集数据的处理需求通过配置规则来进行自动计算；

(3)支持将计算结果输出到多种数据存储组件，通过配置来指定；

所述数据存储服务器集群采用开源组件360-Pika，支持数据备份、快速错误恢复，同时使用了LVS+Keepalived+HAProxy结合的高可用方案，360-Pika的实时监控方案使用Pika-Exporter并结合Prometheus和Grafana进行实时监控指标数据的展示和告警；

所述数据存储服务器集群采用Pikamgr管理平台对集群进行管理，Pikamgr管理平台支持Pika实例的运维管理、性能监视、HAProxy和LVS的自动化配置更新。

2.根据权利要求1所述的计算系统，其特征在于：所述Pikamgr管理平台包括Pika-Dashboard和Pika-FE两个服务，其中Pika-FE为前端页面提供API接口服务，Pika-Dashboard为集群管理功能提供支撑，使得Pikamgr管理平台具备以下功能：

(1)360-Pika实例的多集群、多分组管理；

(2)360-Pika的性能监视包括QPS、CPU、Connection；

(3)LVS、Haproxy集群的管理，HAProxy和LVS的配置自动化更新；

(4)使用Redis-Sentinel作为360-Pika的Master-Slave关系的维护，自动下发360-Pika的分组信息至Redis-Sentinel；

(5)360-Pika实例、LVS、HAPrroxy、Redis-Sentinel异常状态显示；

(6)360-Pika的紧急问题修复操作。