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

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

A computing system for real-time processing of advertising effect data

【技术实现步骤摘要】
一种对广告效果数据实时处理的计算系统
本专利技术属于大数据实时计算存储
，具体涉及一种对广告效果数据实时处理的计算系统。
技术介绍
随着公司广告业务的不断发展，业务量逐渐上升，原有的实时数据处理方案已经越来越不能满足业务需求，越来越多的问题显现出来：采集数据容易丢失；无标准的实时数据处理流程，存在隐患；数据存储集群无法平台化管理，运维效率低，出错概率大。为了解决这些问题，调研了目前流行的技术方案如下：(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，纯实时的流式处理框架，应用也很广泛，但是最大的不足是仅能保证“AtMostOnce”(最多一次)和“AtLeastOnce”(最少一次)的消息投递语义，即可能存在重复发送的情况。在对数据的精确性要求比较高的业务场景中无法很好地满足“ExactlyOnce”(精确一次)的语义，像广告系统中的实时控量、结算等都是对数据准确度具有较高的要求，因此很难满足我们的业务场景。Sparkstreaming，应用较广泛的流式处理框架，社区非常强大，支持非常多的输入源(Kafka、Flume、HDFS等)，可独立部署也可以与Hadoop结合取代MapReduce，完全在内存中进行计算，最多只会在输入输出时与存储层交互。Sparkstreaming是Spark框架的流处理模式，属于准实时处理(微批处理的方式)，相比于真正的流处理框架性能存在不足，不适合对延时有较高需要的业务场景，比如我们的广告投放流程中的实时控量的业务场景。Flink，最近两年非常流行的纯实时流式计算框架，支持流式计算的很多高级功能(如EventTimeProcessing、Watermarksd等)，支持“ExactlyOnce”(精确一次)的语义，低延时高吞吐量；但是对于我们小团队来说，维护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-PikaMaster-Slave集群方式，由于多种类型的数据，需要多组Master-Slave，单纯的Master-Slave集群方式不带有集群自组织管理的功能，因此多组Master-Slave的管理会非常困难。Codis+360-Pika的集群方式，结合Master-Slave模式，可以很好的解决多组Master-Slave管理困难的问题，但是在实际的使用过程中存在如下问题：①虽然360-Pika兼容Redis协议，可以使用Codis+360-本文档来自技高网...

【技术保护点】
1.一种对广告效果数据实时处理的计算系统，包括数据收集服务器集群、数据传输服务器、数据实时处理服务器集群、数据存储服务器集群，其特征在于：/n所述数据收集服务器集群用于为多样的数据采集端提供统一的数据收集入口，并按照制定的数据采集规范将收集到的数据写入文件，同时集群中的每台数据收集服务器均为无状态服务，在性能不足时可以很方便的进行扩展；/n所述数据传输服务器依托于数据采集规范将写入文件的数据实时传输到MQ，即保障了数据持久性又降低了数据实时处理服务与数据收集服务之间的耦合度，并且支持断点续传功能；/n所述数据实时处理服务器集群用于从MQ中实时读取数据并按照对应数据分析及存储需求进行拆分、计算并将处理结果数据写入数据存储服务器集群，保证了数据处理的及时性；另外即便是集群有一定比例的服务实例挂掉，依然可以继续正常对MQ中的数据进行处理；/n所述数据存储服务器集群用于提供数据备份、快速错误恢复的功能，数据存储在磁盘，这大大降低了存储成本并且允许存储较大的数据量，并且同时保证了数据存取的性能；另外数据存储服务器集群还提供了相应的管理平台，最大程度减少运维复杂度和集群日常维护的工作量。/n

【技术特征摘要】
1.一种对广告效果数据实时处理的计算系统，包括数据收集服务器集群、数据传输服务器、数据实时处理服务器集群、数据存储服务器集群，其特征在于：
所述数据收集服务器集群用于为多样的数据采集端提供统一的数据收集入口，并按照制定的数据采集规范将收集到的数据写入文件，同时集群中的每台数据收集服务器均为无状态服务，在性能不足时可以很方便的进行扩展；
所述数据传输服务器依托于数据采集规范将写入文件的数据实时传输到MQ，即保障了数据持久性又降低了数据实时处理服务与数据收集服务之间的耦合度，并且支持断点续传功能；
所述数据实时处理服务器集群用于从MQ中实时读取数据并按照对应数据分析及存储需求进行拆分、计算并将处理结果数据写入数据存储服务器集群，保证了数据处理的及时性；另外即便是集群有一定比例的服务实例挂掉，依然可以继续正常对MQ中的数据进行处理；
所述数据存储服务器集群用于提供数据备份、快速错误恢复的功能，数据存储在磁盘，这大大降低了存储成本并且允许存储较大的数据量，并且同时保证了数据存取的性能；另外数据存储服务器集群还提供了相应的管理平台，最大程度减少运维复杂度和集群日常维护的工作量。


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


3.根据权利要求1所述的计算系统，其特征在于：所述数据传输服务器基于elastic公司开源的filebeat-v6.4进行了功能扩充，支持数据采集规范中定义的采集文件状态转换功能以及数据输出格式，支持timezone时区的配置，支持将文件中的数据实时传输至MQ，随时跟进Filebeat的最新功能，MQ使用Kafka-2.0。


4.根据权利要求1所述的计算系统，其特征在于：所述数据实时处理服务器集群基于Kafka-2.0提供的Kafka-Stream库搭建轻量级的流式计算框架SW-Kafka-Stream，完全原生兼容Kafka的设计模式，提供简单高效的流式计算功能。


5.根...

【专利技术属性】
技术研发人员：丁善富，林剑炜，魏新杰，
申请(专利权)人：杭州顺网科技股份有限公司，
类型：发明
国别省市：浙江;33