广告业务系统 之 数据桥梁 —— “日志中心-曝光数据流转结算”

广告业务系统 之 数据桥梁 —— “日志中心-曝光数据流转结算”

曝光数据流转结算

曝光数据,是 ADX 额外关注的部分,其数据流转 是沟通结算,涉及营收的重要桥梁。
曝光数据从生产位置分,可分为 接口曝光、真实曝光、Client 加载曝光…等等多种类型。不同类型曝光对应着广告合约中不同的曝光结算形式。除曝光外还有转化、点击等其他结算形式

接口曝光处于生产最高的位置,为 Server 服务下发的广告位最终候选;依次是 Client 加载,Client 加载到的 Server 下发候选;最后是真实曝光,即出现在用户视野中的广告候选;且曝光规模按此次序成递减关系。

注:此文章主体曝光数据,为接口曝光。

管道式架构助力高可用

据上文中介绍可知,曝光数据的粒度为 pv 为最佳,也就是 一个请求数据中包含了多个广告位的曝光信息。数据规模与流量入口呈正相关趋势,且随之波动。当然也可以是广告位粒度,不过数据规模会翻几翻,且与 pv 藕合分析需额外的映射/聚合逻辑,不同场景视情况而定

我们要考量 数据流转服务的 **承载能力、及可扩展能力,确保服务的高可用、高性能。**这里我们引入一个架构模式,叫做 “管道式架构”,适用于承担这种场景下的数据流转功能。

管道式架构模式图

在这里插入图片描述
该模式中,数据流始于 中间件,终于 中间件,流转服务被夹至中间。

中间件 高效的应对 流量规模及流量动态/差异化增跌问题,有效的隔离/消除 流转及下游的承载压力。
数据流转服务于 上下游服务完美解藕,在轻量化的同时使业务功能高度专一。在数据无损前提下,支持服务灵活弹性部署/功能变更,且具备强悍的可扩展能力。

在数据流式业务中,该模式被极广应用于此类场景。

流式链路中特殊的缓存设计

注意力回到数据流转服务,曝光数据会被重整/拆分/分层,将数据抽象重组成 “公共字段-用户字段-广告位字段-扩展字段…“ 样式,且于 pvId/uuid 形成 k-v 格式。

K-v 格式中,k 将会作为曝光数据唯一标识,用于后续结算和数据标签等流程。

除此之外,由于曝光数据流转的流量为 ADX 全数据,故这里将会进行数据缓存,为下篇中的 “监测上报” 服务提供数据支撑。

一、二级缓存

这里将缓存分为两级,一级缓存为 Redis,二级缓存为 HBase。[也可多层,视场景而定]熟悉缓存系统的同学,尤其是业务涉及票务、电商。会比较了解,缓存分层的意义。

在这里插入图片描述
这里结合当前场景简单赘述:

  • 性能刚需
    • 在缓存出现的地方,无不牵涉到提升数据读性能。尤其是在高并发/规模流量下,这时的传统 DB ,Mysql/SqlServer 等组件的承载能力、读写特征性能、数据存储规模 都将显的格格不入。
  • 冷热数据
    • 在某些场景中,存在读写频次极其高的数据集,形成了热数据;相对的数据,即为冷数据。针对数据的这个特征,往往将热数据放置一级缓存层,冷数据置二层。因为一层往往是处于内存空间[暂不涉及内核高速缓冲区],高速的处理速度使这有限的空间变得寸土寸金。

基于上面的一些因素,这里将依据时间段,做冷热数据的分离。热数据存放至 Redis,冷数据则置于 HBase 中,数据格式皆为 k-v 形式。

Nosql 数据型缓存组件

到这里,来解答一个疑问,关于 缓存组件的选取问题。

二级缓存,往往是 Mysql 等传统的组件,这里使用的却是 HBase,有何区别

产生这个疑问的同学,可能接触的业务比较常规,大都基于 结构性数据,对存储和数据结构之间的选型,了解不够深,不足为奇。

ADX 系统 核心数据流 都是基于流式处理方式,保障失效性的同时,准确性、可靠性都需要兼顾。与常规业务数据流处理方式有较大的不同。
另外一点是,此场景中,缓存系统中的数据是 k-v 格式,属于 No-sql 类型,关系型数据库无法作为数据载体。

HBase 是一个开源的、分布式的、数据多版本的,列式存储的 nosql 数据库。[ HBase 详细介绍可关注后续博文/公众号,暂不做重点]

  • 强有力的压缩比
    • 列式存储,可具备较高的压缩比,有限的空间存储无限的数据。其它列式存储也都具备,levelDB、Prometheus 等等
  • 客观的吞吐量
    • HBase 依托 Hadoop 的分布式文件系统 HDFS 作为底层存储,能够为数十亿行数百万列的海量数据表提供随机、实时的读写访问。

最终,曝光数据以 其中的结算类型字段进行分流,流向不同的结算服务,进行计数处理。

良好的架构设计和适配的技术组件选型 为 业务/团队 能够快速持续交付价值,起着决定性的作用!

s2s 监测上报

s2s 监测上报,是 ADX 将广告的曝光、互动[点击/播放/下载/关闭…]、Win 数据以 接口形式进行回转给 DSP[广告主]。广告主依据此数据,进行数据归因及结算,是阐述/同步广告投放效果的核心通道…


见后续文章!

推荐阅读:
暨 广告、推荐、搜索 三大顶级复杂业务之 “广告业务系统详叙”
广告业务系统 之 承前启后 —— “消息中心”
广告业务系统 之 数据中转站 —— “日志中心-实时服务监控”
广告业务系统 之 数据桥梁 —— “日志中心-曝光数据流转结算”
广告业务系统 之 核心通道 —— “日志中心-s2s监测上报”
广告业务系统 之 辅助决策 —— “ AB 实验平台”
广告业务系统 之 框架沉淀 —— “数据消费型服务框架”
广告业务系统 之 智能保险丝 —— “智能流控”
广告业务系统 之 敏捷交付 —— “基于 Docker 容器同机部署”
广告业务系统 之 业务串联 —— “ PDB - 广告投放【保量保价】”


三行代码搞定 —— 反转链表…
Kafka 高吞吐、高性能核心技术及最佳应用场景…
HTTPS 如何保证数据传输安全 —— TLS 协议…
五分钟搭建基于 Prometheus + Grafana 实时监控系统…

猜你喜欢

转载自blog.csdn.net/qq_34417408/article/details/128643326
今日推荐