Day38-18｜19.6.2 Lambda 架构在某网广告平台的应用与演进：从实时投放到数据闭环

对应教材目录：第 19 章 大数据架构设计理论与实践 → 19.6 大数据架构设计案例分析 → 19.6.2 Lambda 架构在某网广告平台的应用与演进

学习目标：理解广告平台中曝光、点击、转化、预算和计费数据的处理特点；掌握 Lambda 架构如何支撑实时投放、频次控制、效果分析和历史核算；能够分析广告平台从单体统计、批处理到实时大数据平台的演进过程及其架构权衡。

一、广告平台的业务特点

广告系统同时服务广告主、媒体、用户、运营和财务，数据链路长、事件量大、实时性要求高且直接涉及费用结算。一次广告展示可能经历请求、竞价、曝光、点击、落地页访问、注册、下单和支付等多个事件。

广告请求 -> 竞价 -> 曝光 -> 点击 -> 到达 -> 转化 -> 计费/归因
   |          |       |      |       |       |        |
实时投放   实时预算  频控   风控   推荐   归因分析   财务核算

广告平台需要同时解决：实时竞价和投放、预算控制、频次控制、反作弊、实时看板、效果归因、模型训练和准确计费。实时结果用于决策，批量结果用于修正、分析和结算，Lambda 架构因此具有典型应用价值。

二、核心数据和主体

1. 广告主和活动

包括广告账户、活动、计划、创意、预算、出价、定向和投放时间。配置变化应版本化并审计，不能让实时系统读取到部分更新的活动配置。

2. 用户与设备

包括用户标识、设备标识、地域、兴趣、行为和隐私授权。数据必须分级、脱敏和最小化，设备标识不能被无限期或跨用途使用。

3. 广告事件

曝光、点击、转化、取消、无效流量和计费事件应有唯一 ID、事件时间、接入时间、广告、媒体、用户或设备、来源和版本。

4. 预算与财务

预算消耗、出价、扣费、退款和结算属于高价值数据，要求幂等、可审计、可对账和最终确认。实时预算可以是近似值，但不能直接绕过确认流程生成最终账单。

三、广告平台的主要挑战

1. 极高吞吐和低延迟

广告请求需要在很短时间内完成候选过滤、竞价、频控和返回，事件吞吐却可能远高于普通交易系统。实时链路必须靠内存状态、缓存、分区、并行和预计算支撑。

2. 事件重复、丢失和作弊

网络重试会导致重复曝光或点击，客户端可能伪造事件，机器人会制造大量无效流量。系统需要事件去重、设备和行为特征、来源校验、风控模型和批量反作弊。

3. 归因复杂

一次转化可能对应多个触点、设备和渠道，归因窗口、模型和迟到事件会影响效果报告和结算。实时归因与最终归因可能不同，必须保留版本和修正记录。

4. 多方指标不一致

媒体、广告主、投放平台和财务可能使用不同过滤、时区、去重和归因口径。平台需要定义指标契约和数据版本，不能让每个报表自行解释事件。

四、广告 Lambda 架构

广告请求/媒体/客户端/转化系统
             |
      接入、鉴权、反作弊预检
             |
       事件日志/消息队列
          /          \
         /            \
速度层：投放、频控、预算、告警   原始事件归档
         |                         |
实时特征/实时指标             批处理层：去重、归因、反作弊、核算
         \                         /
          \                       /
              服务层：投放 API、看板、报表、账单

速度层的目标是快速作出投放和预算决策，批处理层的目标是完整、准确和可重算，服务层根据使用者提供实时估算或最终确认结果。

五、速度层：实时投放和预算控制

1. 实时特征

速度层计算用户和设备的近期行为、广告频次、预算消耗、媒体质量、实时转化率和风险分数。特征服务要提供低延迟读取，状态更新必须幂等并带版本。

2. 频次控制

系统要限制同一用户、设备或家庭在时间窗口内看到同一广告的次数。分布式计数需要处理并发、过期、跨节点一致性和设备标识变化。短时间内可以允许近似，但对高价值活动应设置更严格的校验。

3. 预算控制

实时预算消耗可以按媒体、活动和地域分区聚合，设置安全余量和限额。预算扣减不能只依赖异步估算，关键扣费需要通过幂等交易和最终对账确认。

4. 实时竞价

竞价服务使用缓存的活动配置、出价、定向和风险特征。配置发布采用版本化和原子切换，避免部分节点读取旧配置、部分节点读取新配置导致竞价不一致。

六、批处理层：去重、归因、反作弊和核算

1. 事件清洗和去重

批处理读取完整事件，根据曝光 ID、点击 ID、转化 ID、设备和时间窗口去重，并识别迟到和异常事件。去重规则要版本化，因为业务和反作弊策略会变化。

2. 归因计算

批处理根据归因窗口、触点序列、渠道和模型计算最终转化归属。归因结果应保存模型版本、输入事件范围和计算时间，支持广告主复核。

3. 反作弊

离线分析可以识别设备群、异常 IP、点击时间模式、转化异常、批量注册和流量来源变化。被判定为无效的事件应标记状态或生成修正事件，不能直接删除原始证据。

4. 计费与结算

最终账单以确认事件、无效流量规则、合同和计费模型为依据。账单生成前要进行金额、事件量、广告主、媒体和渠道对账；账单版本和人工调整必须可审计。

七、服务层和不同结果口径

广告平台至少需要提供三类结果：

  1. 实时结果：用于投放、预算和运营监控，追求新鲜度。
  2. 预估结果：用于广告主实时看板，可能包含暂未完成归因的数据。
  3. 最终结果：用于结算、合同和正式报表，强调确认和可追溯。

服务接口应明确结果类型、统计时间、时区、口径、版本和是否可能修正。不能把实时估算直接命名为“最终点击数”或“最终费用”。

八、数据质量和对账体系

广告事件链路可以用漏斗校验：

请求数 >= 返回数 >= 曝光数 >= 点击数 >= 转化数
       |          |          |          |
     接入校验   展示校验   去重校验   归因/支付校验

实际业务中并非所有数量都严格单调，但可以通过比例、时间、媒体和活动维度发现异常。对账包括：

  • 采集系统与事件平台对账。
  • 媒体曝光与平台曝光对账。
  • 点击与落地页访问对账。
  • 转化与订单/支付对账。
  • 预算消耗与财务账对账。

差异应进入分类、补偿和人工复核流程。

九、架构演进过程

阶段一：单体统计和离线报表

早期系统可能把事件写入关系数据库，每天批量生成报表。优点是简单，缺点是无法支撑实时投放和高吞吐事件。

阶段二：读写分离和数据仓库

通过日志、ETL 和数仓降低在线库压力，增加历史分析能力，但实时特征和预算仍然存在延迟。

阶段三：消息平台和流处理

引入事件队列、实时计算、缓存和特征服务，支持频控、预算、实时看板和风控。批处理继续承担去重、归因、反作弊和核算。

阶段四：平台化和智能化

统一数据契约、数据湖/湖仓、模型平台、特征平台、实时服务、数据治理和多租户能力，形成广告数据闭环。实时和批量结果通过版本、水位和对账连接。

十、峰值和资源治理

广告流量在热点事件、节假日和大促期间突增。应采用：

  • 请求层限流、熔断和多级缓存。
  • 活动配置预热和读副本。
  • 消息分区扩展和优先级队列。
  • 实时计算资源预留和弹性扩容。
  • 非核心报表、模型训练和历史重算错峰。
  • 预算和风控链路高于普通统计的优先级。

如果实时链路不能及时更新预算，应采用安全余量或临时收紧投放，而不能继续无限消耗。

十一、安全和隐私设计

广告平台处理用户行为和设备信息，应遵循最小化、目的限制和授权。用户标识、设备标识和转化数据分级保护，访问按广告主、媒体、团队和用途授权。

广告主不能读取其他广告主数据，媒体不能读取全平台用户画像，算法人员访问训练数据应脱敏。模型、规则、出价和计费配置要版本化、审批和审计。日志、备份和消息副本也要保护敏感信息。

十二、案例分析：从离线广告系统演进到实时平台

某广告平台原来每天生成一次曝光和点击报表，后来要求实时预算控制、频次限制和异常流量拦截。

演进方案：

  1. 先建立统一事件模型和可靠接入，保留原有批报表作为基准。
  2. 引入消息日志和速度层，实时计算频控、预算和风险特征。
  3. 批处理继续做去重、归因、反作弊和最终账单。
  4. 服务层区分实时看板、确认报表和账单结果。
  5. 进行双跑，对比实时和离线指标、预算误差、延迟和成本。
  6. 逐步将投放、看板和风控迁移到实时服务，保留批处理作为校正和结算路径。
  7. 建立数据目录、指标契约、权限、审计和生命周期管理。

十三、案例题答题模板

广告平台案例可以按以下方式作答：

  1. 识别曝光、点击、转化、预算、出价和计费等核心事件。
  2. 设计统一事件、消息、原始归档和数据版本。
  3. 速度层实现投放、竞价、频控、预算、风控和实时指标。
  4. 批处理层实现去重、归因、反作弊、历史报表和账单核算。
  5. 服务层区分实时、预估和最终确认结果。
  6. 设计峰值弹性、缓存、限流、优先级和故障降级。
  7. 说明数据质量、漏斗校验、对账、安全、隐私和审计。
  8. 说明从离线到实时平台的分阶段演进和双跑验证。

十四、课后练习

练习 1

为什么广告平台不能只使用实时结果进行计费？

参考答案：实时事件可能重复、迟到、作弊或未完成归因，实时结果适合投放和监控；计费需要去重、反作弊、归因、合同规则和对账后的最终确认结果。

练习 2

广告平台 Lambda 的速度层主要承担哪些任务？

参考答案：实时竞价、频次控制、预算消耗、实时特征、风险判断、热点指标和投放决策。

练习 3

从离线广告系统迁移到实时平台为什么要双跑？

参考答案：双跑可以对比新旧口径、事件完整性、预算误差、延迟、资源和账单差异，确认实时链路不会破坏原有最终结果。

练习 4

论文题：论“广告平台大数据架构的设计与演进”。

参考答案要点：事件模型、消息、实时投放、预算频控、批量去重、归因、反作弊、计费、数据质量、对账、峰值弹性、隐私安全和分阶段迁移。

十五、今日复盘

  • 我能否说明广告曝光、点击、转化和计费的关系？
  • 我是否能区分实时投放结果、预估报表和最终账单？
  • 我能否设计批处理和速度层的职责？
  • 我是否考虑反作弊、对账、预算、峰值和隐私？
  • 我能否写出从离线系统向 Lambda 平台的演进路径？

广告平台案例的核心结论是：速度层负责及时投放、频控、预算和风控，批处理层负责去重、归因、反作弊和最终核算，服务层区分临时与确认结果；系统演进必须以统一事件、双跑对账、数据治理和分阶段迁移保证实时能力不会牺牲计费准确性。