广告业务系统 之 数据桥梁 —— “日志中心-曝光数据流转结算”
Posted 魏小言
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了广告业务系统 之 数据桥梁 —— “日志中心-曝光数据流转结算”相关的知识，希望对你有一定的参考价值。
文章目录
广告业务系统 之 数据桥梁 —— “日志中心-曝光数据流转结算”
曝光数据流转结算
曝光数据，是 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[广告主]。广告主依据此数据，进行数据归因及结算，是阐述/同步广告投放效果的核心通道…
见后续文章！
欢迎关注文末公众号
推荐阅读：
暨 广告、推荐、搜索 三大顶级复杂业务之 “广告业务系统详叙”
广告业务系统 之 承前启后 —— “消息中心”
广告业务系统 之 数据中转站 —— “日志中心-实时服务监控”
三行代码搞定 —— 反转链表…
Kafka 高吞吐、高性能核心技术及最佳应用场景…
HTTPS 如何保证数据传输安全 —— TLS 协议…
五分钟搭建基于 Prometheus + Grafana 实时监控系统…
以上是关于广告业务系统 之 数据桥梁 —— “日志中心-曝光数据流转结算”的主要内容，如果未能解决你的问题，请参考以下文章