当前位置:首页 > 业界动态 > 正文

广告大数据实时计算系统实践

广告涉及商家、用户、平台三方关系。 上一篇文章介绍了广告的驱动历程,涉及到商家投放的广告、算法、引擎以及用户侧的系统架构。 主要关注用户侧的数据调用过程; 本文主要涉及平台和商家。 商家和平台最关心的是什么? 数据、数据、数据,无论是平台还是业务都需要基于数据进行决策和运营,这肯定会涉及到离线和实时的数据系统。

本文重点介绍广告技术实时流媒体系统的构建和解决方案:高效的数据输出,同时为商家和运营商提供高实时、高质量、多维度的数据,同时支持运营商定制数据报表改善基于数据的运营。 能力。

商户侧

操作端

数据系统的四件事:数据采集、数据清洗/分层、数据处理、数据服务。 接下来我们将从这几个方面入手:

1. 数据收集

广告主要涉及交易行为、用户行为、商家行为(投放、观看广告效果、操作)等数据,而这些数据是由不同的系统产生的:每个系统的存储不同,结构也不同。 系统如何整合各类数据? 数据是为系统服务的,也是为商家和平台服务的?

广告系统涉及平台的收入。 如果系统不稳定,将会影响收入、商家投放、用户体验。 如何根据数据监控系统的稳定性,及时发现问题,定位问题模块?

数据方面,我们主要收集四个方面:

系统数据:收集各种业务系统变更数据、商户行为数据等。

指标数据:收集指标数据、点击量、曝光度、用户行为等。

监控数据:全站根据场景数据统一上报。

性能数据:系统内第三方调用的性能数据统一采集。

2.数据清洗/分层

在数据采集阶段,结合业务,我们依赖大量外部系统产生的大量数据。 数据结构不同。 完整性约束是否满足业务的需求,数据结构是否满足业务对数据的处理,数据存储在系统中的各个处理中,如何保证处理系统中各个字段的语义一致性。

当时的两个主要问题是:

在广告投放初期,各业务系统直接根据自身业务需求对来自源数据层的数据进行处理、解析和结构化。 但随着业务的深入,业务方对数据也有了更深层次的需求。 例如:本来,我可能只需要知道搜索场景的曝光PV。 稍后你需要知道搜索某个词的实时PV。 如果粒度发生变化,就需要改变聚合逻辑和原有的数据解析逻辑。 在大多数情况下,两个系统是耦合的。 ,数据复用性较差。

最初我们只需要知道产品的曝光、点击、订单等数据。 后来我们需要知道广告、商品购买、点赞、收藏等交易环节; 我们发现原来基于原始日志处理的系统已经不能满足要求,数据维度发生了变化;

似乎可以这样做:

提供对原有系统的支持。 如果原来的系统比较大,修改的风险就更大,数据处理流程也不同。 对不起...;

打开一个新的应用程序,再次拉取数据进行处理,并根据需要再次解析。 那么相同的数据将被多个应用程序处理。 在处理过程中,多个应用程序会调用同一个服务来完成额外的数据。 对外部服务的调用也加倍。 同时,每个应用程序的完整性约束是否相同,异常的处理是否相同? 如何保证数据性能的一致性?

最终计划:

参考公司离线数据分层仓库的数据建模层面,对实时流数据进行分层。 在原始数据层的基础上,通过统一的数据清洗层(ETL)进行统一处理和处理,然后产生DWD层(数据建模)。 :根据业务需求,对原始数据进行统一处理,保证下游数据处理的一致性,同时去掉原始数据的一些不必要的字段),对于下游处理数据的同学来说更加友好简洁。

3. 数据处理

数据处理熟悉的三驾马车:storm、flink、kylin。

本节重点:在不贴代码的情况下,从时间和业务角度来解释为什么我们要选择这些框架来处理数据; 如何让小组内的学生基于这些框架高效发展; 我们在什么阶段选择了哪个框架?

第一阶段:

蘑菇街的广告系统仍处于早期阶段。 业务形式主要有CPC和CPS。 很多数据显示采用T+1(HIVE)方式。 CPC广告订单和点击数据使用计划任务进行更新。 还使用一些其他流媒体程序。 普通单机版java程序。 我们面临的问题是: 1、机器偶尔无故重启怎么办? 2、程序OOM怎么办? 3. 程序卡住怎么办? 4、如何快速重启程序? 5、如何拓展? ETC;

第二阶段:

我们添加了APP监控代理来检测一系列程序状态和其他操作。 部署了多个应用程序。 当时访问的数据量不大,总体还算可以管理;

第三阶段:

为了满足不同商家、不同需求,增加了不同的广告形式。 同时,很多场景也与商业逻辑进行了融合。 广告依赖的数据越来越多,广告需要分析的数据也越来越多。 直观的表现就是我们有很多类似流处理的应用,但是它们还是独立的。 每个应用程序都实现一些灾难恢复逻辑。 为了避免上述问题,容灾逻辑有所不同。 这时候我们就开始考虑普通的Java应用+代理。 方法是否可以替代也需要很多人认为从一开始就直接上游处理系统会更好。 看起来是对的,但其实也是错的:本来外部数据少、场景少,编写普通的Java程序就能很快满足业务的需求。 随着你写的需求越来越多,你会封装一些更容易使用的组件,这些组件逐渐成为改变的负担,但又总是需要改变。

第四阶段:

第 1 部分:选择流处理系统。 最早有spark和storm这两个框架,所以我们选择了storm(原因很多,我觉得没必要说,就不说了。主要是看了jstorm源码,感觉很简单,Control也能满足现在的需求,本来为了在普通Java程序中实现at-least-once语义,大家也参考了Storm来实现相应的组件);

Part 2.后来还有更多的需求需要分析。 无论是运营还是技术,我们都需要看到更多维度的数据。 在Storm中写代码效率太低了。 在某些情况下,我们不得不同时处理批处理相关的数据。 处理上需要Exactly-once,流需要有状态,硬编码效率太低。 需要在流处理中添加SQL。 这时候重点关注的是Flink(SQL、Exactly-once、流批集成等)。 网上有很多文章); 我花了两个周末看源代码。 Flink 是一个很棒的开源数据处理引擎,无论从代码风格、系统设计的初衷和思想,还是与大数据框架的融合,都是一个不错的选择。 。

当然,光有选择总是不够的。 原来的应用程序需要迁移。 如何在Storm和Flink上高效开发? 开发完成后,还需要对程序报警进行统一监控。 安吉拉系统诞生了。 Angela项目基于Storm和Flink作为基础环境构建了一个快速支持数据输出的解决方案:

第五阶段:

有时候写Flink SQL很麻烦。 例如:

比如有时会出现实时定位的问题。 产品曝光PV下降。 我想看看是什么原因:我计算了总PV。 全站场景、平台众多(各种小程序、APP、PC),如何实时场景分析? 这种需要并不是每天都需要,但总会发生几次。 是不是有实时数据可以直接查? 然后就可以修改原来的flink程序的代码并发布了。 ,让它产生相应的数据……(会崩溃)……,也可以明天跑一下Hive,好像也可以,然后明天写一堆一次性的SQL;

我们开始尝试Kylin,搭建一个数据立方体来满足数据下载和上卷的需求。 我们实现了一个准实时的自定义查询平台,可以满足各种维度查询的随机组合,秒级返回数据。 基于Kylin的数据处理现阶段主要用在技术和运营方面,因为Kylin构建一个Cube至少需要8分钟,并且会存在数据延迟。 商户端大部分数据处理仍然基于Strom+Flink(秒级延迟)。 现阶段我们开始基于 Kylin 构建一个用于广告的实时 Olap 平台。 在该平台中,整合各个维度的广告相关数据,形成基本的广告数据模型,然后输入Kylin进行预计算,以满足业务近实时的数据查询。

4、数据服务

目前的数据流转系统以及产生的数据已经服务于各个广告系统以及上下游,旨在产生准确、实时的数据,帮助商家和各方做出更好的决策。 数据处理系统确保:

总结

由于篇幅限制,本文主要介绍一些基于业务白话的实时流媒体框架选型和系统架构。 比如前面提到的Exactly-once我们是怎么做到的? 如何保证数据准确性? 使用Kylin时如何在进程存储和效率之间进行选择,以及如何剪枝? 目前还没有介绍,请耐心等待。 我会通过一些篇幅来介绍一下系统流程的一些细节以及当时的注意事项。

0
收藏0

最新文章

随机文章

取消
扫码支持支付码