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

news2024/11/20 0:49:45

曝光数据，是 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 形式。