尧图网站建设 
system-design-notes第21章设计广告点击事件聚合系统完整指南【免费下载链接】system-design-notesNotes of the book System Desgin Interview - An Insiders Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notessystem-design-notes是《System Design Interview - An Insiders Guide》的开源学习笔记第21章带你从零开始设计一套广告点击事件聚合系统Ad Click Event Aggregation如何把每天 10 亿条广告点击事件实时汇总成可计费、可查询的统计结果本章围绕消息队列、MapReduce 聚合、Kappa 架构、水位线Watermark、Exactly-Once 语义等核心问题给出 Facebook/Google 规模下的完整设计方案是学习大数据系统设计面试的精华章节。本章原始笔记21. Ad Click Event Aggregation/README.md一、为什么需要广告点击事件聚合系统数字广告是 Facebook、YouTube、TikTok 等平台的核心收入来源。其中有一个关键环节叫实时竞价RTB广告位在一秒内被买卖因此系统既要快又要数据绝对准确——聚合结果直接决定广告主付多少钱。广告主基于点击聚合数据做出调整定向人群、优化关键词等决策。系统需要支持的核心查询查询类型说明点击计数广告 X 在最近 Y 分钟内的点击次数Top N 广告最近 1 分钟点击最多的 Top 100 广告参数可配置维度过滤按ip、user_id、country等维度过滤容量估算Back-of-the-envelope10 亿 DAU × 每人每天 1 次点击 10 亿次点击/天平均 QPS 约 1 万峰值 QPS 约 5 万日存储约 100GB、月存储约 3TB。二、API 设计与数据模型先想清楚契约API 是客户端数据分析师、广告主与服务器之间的契约本章设计了两个接口查询点击聚合数GET /v1/ads/{ad_id}/aggregated_count支持from、to、filter查询参数查询热门广告GET /v1/ads/popular_ads支持countTop N、window窗口大小、filter参数数据模型上同时保留两类数据数据类型结构用途原始数据ad_id / click_timestamp / user / ip / country调试、重算兜底存冷存储聚合数据ad_id / click_minute / filter_id / count仪表盘快速查询Top N 结果window_size / update_time / most_clicked_ads快速返回每分钟 Top N原始数据 聚合数据双轨并存是本章的关键权衡聚合数据查询快但有损无法回查细节原始数据体积大但支持重新计算。选库时原始数据写入密集平均 10k / 峰值 50k QPS聚合数据读写都重本章最终都选用Cassandra。三、高层架构消息队列解耦 MapReduce 聚合系统整体是一条无界数据流用 Kafka 消息队列解耦生产者与消费者避免某个消费者崩溃拖垮整个链路数据链路分为两条队列第一条队列存原始点击事件Database Writer将其落盘到原始数据数据库第二条队列存聚合结果每分钟的广告计数、Top N 广告由Database Writer写入聚合数据库查询服务Dashboard直接读取这种设计的收益是实现了端到端 Exactly-Once 原子提交语义聚合结果先入队、再由消费者写库链路各段都能独立重试而不产生重复计数。聚合服务内部Map-Reduce DAG聚合服务采用 MapReduce 范式把大数据用并行分布式计算压缩成常规规模的结果Map 节点读取数据源过滤并转换数据按ad_id把数据分发到不同聚合节点。为什么不直接让聚合节点订阅 Kafka 分区因为 Map 节点能统一做数据清洗且不依赖上游的分区策略同一ad_id的事件可能散落在不同分区Aggregate 节点每分钟在内存中按ad_id计数Reduce 节点汇总各 Aggregate 节点的结果产出最终计数Top N 场景下每个节点维护一个堆结构快速取出点击最多的 N 个广告三个典型用例按分钟聚合点击数广告按ad_id % 3分区各 Aggregate 节点独立计数后由 Reduce 汇总Top N 热门广告每个节点维护堆Reduce 合并出全局 Top N维度过滤预定义过滤条件并预聚合如按country分桶这是数据仓库中经典的**星型模型Star Schema**思路——过滤字段即维度优点是查询快、可复用代价是桶和记录数变多四、流式 vs 批式Kappa 架构是更好的选择本章的高层架构本质上是一个流处理系统。三种系统形态对比维度在线服务批处理离线流处理近实时输入用户请求有界大数据集无界数据流输出客户端响应物化视图、聚合指标物化视图、聚合指标度量可用性、延迟吞吐吞吐、延迟如果同时用批 流两条链路就是Lambda 架构缺点是两套代码库要维护Kappa 架构只用一条流处理链路历史数据重算也走同一个聚合服务本章方案正是 Kappa 风格当聚合逻辑出现 Bug 时从原始存储取出历史数据 → 送入独立的专用聚合服务不影响实时链路→ 结果写入第二条消息队列 → 更新聚合数据库完成无损重算。五、时间戳、水位线与聚合窗口聚合必须有时间戳两种选择各有取舍方案优点缺点事件时间点击发生时刻结果更准确客户端时间可能不准、可能被恶意伪造处理时间服务器处理时刻服务端时间可靠事件迟到时结果不准因为数据准确性直接关系计费本章选择事件时间并用**水位线Watermark**技术处理迟到事件刻意把聚合窗口向后延长一段这段延展区就是 watermark。水位线短 → 延迟低但漏事件概率高水位线长 → 漏事件概率低但延迟增加无论水位线多长都可能漏事件因此不追求 100% 完美而是靠**日终对账Reconciliation**兜底修正。聚合窗口共四类滚动Tumbling、跳变Hopping、滑动Sliding、会话Session。本章点击计数用1 分钟滚动窗口而最近 M 分钟 Top N 广告用滑动窗口窗口随时间连续移动。六、Exactly-Once 投递与数据去重数据用于计费所以投递语义必须是Exactly-OnceAt-Least-Once 产生的少量重复在这个量级上可能意味着数百万美元的差异。重复数据的常见来源客户端重发同一事件发多次恶意重复交给风控引擎处理确认丢失聚合节点宕机在上游收到 ACK 之前事件被重发——若只在 S3/HDFS 存最后处理的 offset又可能让结果永远到不了下游正确做法是把 offset 存储与下游交互原子化即实现分布式事务或者更简单——让下游对聚合结果幂等处理就没有必要上分布式事务了。七、水平扩展队列、聚合服务与热点广告三大组件消息队列、聚合服务、数据库相互解耦可独立扩容消息队列生产者不限流天然易扩消费者加入消费组即可水平扩展前提是分区要提前创建充足重平衡耗时较长建议在业务低峰执行还可按地域拆分为topic_na、topic_eu等聚合服务MapReduce 节点直接加节点扩容吞吐可用多线程提升生产上更推荐 Apache YARN 这类资源调度器做多进程调度数据库Cassandra 基于一致性哈希原生支持水平扩展新节点加入后数据自动再平衡无需手动分片⚠️热点问题是隐藏陷阱某条广告突然爆红流量集中打到单个聚合节点上怎么办本章方案热点聚合节点向资源管理器申请额外资源 → 事件被拆成 3 组由 3 个临时 Aggregate 节点各处理 100 条 → 结果写回原节点再进入 Reduce。更高级的做法还有 Global-Local Aggregation 与 Split Distinct Aggregation。八、容错与数据正确性监控聚合节点在内存中处理数据宕机会丢中间状态。恢复手段利用 Kafka 的消费者 offset从断点继续对进行中的 Top N 聚合状态做分钟级快照新节点读取最新 offset 最新快照即可无缝接管监控方面要盯住三个指标端到端延迟、队列积压Kafka 场景下看 records-lag 指标积压突增就该加聚合节点、聚合节点资源CPU、磁盘、JVM。最后正确性靠日终对账批处理兜底从原始数据重新计算聚合结果与聚合数据库中的实际值比对发现不一致就告警修正九、替代方案直接用成熟大数据组件面试中不要求你精通所有大数据工具内部实现讲清思路与权衡更重要。若想直接用现成组件可以原始点击数据存入Hive上面架一层ElasticSearch加速查询聚合交给ClickHouse / Druid这类 OLAP 数据库分别服务商家侧分析与数据科学家查询两类场景。十、本章总结一张图看完整链路 设计要点本章方案架构模式Kappa 架构单条流处理链路 原始数据兜底重算聚合引擎Map-Reduce DAGMap 分发 / Aggregate 计数 / Reduce 汇总时间语义事件时间 水位线容忍迟到事件窗口滚动窗口点击计数 滑动窗口Top N投递语义Exactly-Once靠分布式事务或下游幂等实现扩展性三组件独立扩容 资源管理器缓解热点正确性监控 日终对账双保险本章覆盖的设计要点可回溯到笔记目录Readme.md 中列出的其他章节如 19. Distributed Message Queue 讲 Kafka 细节、02. Back Of the Envelope Estimation 讲容量估算能帮你在面试中把广告点击聚合这类大数据系统设计讲得更扎实。【免费下载链接】system-design-notesNotes of the book System Desgin Interview - An Insiders Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 system-design-notes第21章：设计广告点击事件聚合系统完整指南
system-design-notes第21章设计广告点击事件聚合系统完整指南【免费下载链接】system-design-notesNotes of the book System Desgin Interview - An Insiders Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notessystem-design-notes是《System Design Interview - An Insiders Guide》的开源学习笔记第21章带你从零开始设计一套广告点击事件聚合系统Ad Click Event Aggregation如何把每天 10 亿条广告点击事件实时汇总成可计费、可查询的统计结果本章围绕消息队列、MapReduce 聚合、Kappa 架构、水位线Watermark、Exactly-Once 语义等核心问题给出 Facebook/Google 规模下的完整设计方案是学习大数据系统设计面试的精华章节。本章原始笔记21. Ad Click Event Aggregation/README.md一、为什么需要广告点击事件聚合系统数字广告是 Facebook、YouTube、TikTok 等平台的核心收入来源。其中有一个关键环节叫实时竞价RTB广告位在一秒内被买卖因此系统既要快又要数据绝对准确——聚合结果直接决定广告主付多少钱。广告主基于点击聚合数据做出调整定向人群、优化关键词等决策。系统需要支持的核心查询查询类型说明点击计数广告 X 在最近 Y 分钟内的点击次数Top N 广告最近 1 分钟点击最多的 Top 100 广告参数可配置维度过滤按ip、user_id、country等维度过滤容量估算Back-of-the-envelope10 亿 DAU × 每人每天 1 次点击 10 亿次点击/天平均 QPS 约 1 万峰值 QPS 约 5 万日存储约 100GB、月存储约 3TB。二、API 设计与数据模型先想清楚契约API 是客户端数据分析师、广告主与服务器之间的契约本章设计了两个接口查询点击聚合数GET /v1/ads/{ad_id}/aggregated_count支持from、to、filter查询参数查询热门广告GET /v1/ads/popular_ads支持countTop N、window窗口大小、filter参数数据模型上同时保留两类数据数据类型结构用途原始数据ad_id / click_timestamp / user / ip / country调试、重算兜底存冷存储聚合数据ad_id / click_minute / filter_id / count仪表盘快速查询Top N 结果window_size / update_time / most_clicked_ads快速返回每分钟 Top N原始数据 聚合数据双轨并存是本章的关键权衡聚合数据查询快但有损无法回查细节原始数据体积大但支持重新计算。选库时原始数据写入密集平均 10k / 峰值 50k QPS聚合数据读写都重本章最终都选用Cassandra。三、高层架构消息队列解耦 MapReduce 聚合系统整体是一条无界数据流用 Kafka 消息队列解耦生产者与消费者避免某个消费者崩溃拖垮整个链路数据链路分为两条队列第一条队列存原始点击事件Database Writer将其落盘到原始数据数据库第二条队列存聚合结果每分钟的广告计数、Top N 广告由Database Writer写入聚合数据库查询服务Dashboard直接读取这种设计的收益是实现了端到端 Exactly-Once 原子提交语义聚合结果先入队、再由消费者写库链路各段都能独立重试而不产生重复计数。聚合服务内部Map-Reduce DAG聚合服务采用 MapReduce 范式把大数据用并行分布式计算压缩成常规规模的结果Map 节点读取数据源过滤并转换数据按ad_id把数据分发到不同聚合节点。为什么不直接让聚合节点订阅 Kafka 分区因为 Map 节点能统一做数据清洗且不依赖上游的分区策略同一ad_id的事件可能散落在不同分区Aggregate 节点每分钟在内存中按ad_id计数Reduce 节点汇总各 Aggregate 节点的结果产出最终计数Top N 场景下每个节点维护一个堆结构快速取出点击最多的 N 个广告三个典型用例按分钟聚合点击数广告按ad_id % 3分区各 Aggregate 节点独立计数后由 Reduce 汇总Top N 热门广告每个节点维护堆Reduce 合并出全局 Top N维度过滤预定义过滤条件并预聚合如按country分桶这是数据仓库中经典的**星型模型Star Schema**思路——过滤字段即维度优点是查询快、可复用代价是桶和记录数变多四、流式 vs 批式Kappa 架构是更好的选择本章的高层架构本质上是一个流处理系统。三种系统形态对比维度在线服务批处理离线流处理近实时输入用户请求有界大数据集无界数据流输出客户端响应物化视图、聚合指标物化视图、聚合指标度量可用性、延迟吞吐吞吐、延迟如果同时用批 流两条链路就是Lambda 架构缺点是两套代码库要维护Kappa 架构只用一条流处理链路历史数据重算也走同一个聚合服务本章方案正是 Kappa 风格当聚合逻辑出现 Bug 时从原始存储取出历史数据 → 送入独立的专用聚合服务不影响实时链路→ 结果写入第二条消息队列 → 更新聚合数据库完成无损重算。五、时间戳、水位线与聚合窗口聚合必须有时间戳两种选择各有取舍方案优点缺点事件时间点击发生时刻结果更准确客户端时间可能不准、可能被恶意伪造处理时间服务器处理时刻服务端时间可靠事件迟到时结果不准因为数据准确性直接关系计费本章选择事件时间并用**水位线Watermark**技术处理迟到事件刻意把聚合窗口向后延长一段这段延展区就是 watermark。水位线短 → 延迟低但漏事件概率高水位线长 → 漏事件概率低但延迟增加无论水位线多长都可能漏事件因此不追求 100% 完美而是靠**日终对账Reconciliation**兜底修正。聚合窗口共四类滚动Tumbling、跳变Hopping、滑动Sliding、会话Session。本章点击计数用1 分钟滚动窗口而最近 M 分钟 Top N 广告用滑动窗口窗口随时间连续移动。六、Exactly-Once 投递与数据去重数据用于计费所以投递语义必须是Exactly-OnceAt-Least-Once 产生的少量重复在这个量级上可能意味着数百万美元的差异。重复数据的常见来源客户端重发同一事件发多次恶意重复交给风控引擎处理确认丢失聚合节点宕机在上游收到 ACK 之前事件被重发——若只在 S3/HDFS 存最后处理的 offset又可能让结果永远到不了下游正确做法是把 offset 存储与下游交互原子化即实现分布式事务或者更简单——让下游对聚合结果幂等处理就没有必要上分布式事务了。七、水平扩展队列、聚合服务与热点广告三大组件消息队列、聚合服务、数据库相互解耦可独立扩容消息队列生产者不限流天然易扩消费者加入消费组即可水平扩展前提是分区要提前创建充足重平衡耗时较长建议在业务低峰执行还可按地域拆分为topic_na、topic_eu等聚合服务MapReduce 节点直接加节点扩容吞吐可用多线程提升生产上更推荐 Apache YARN 这类资源调度器做多进程调度数据库Cassandra 基于一致性哈希原生支持水平扩展新节点加入后数据自动再平衡无需手动分片⚠️热点问题是隐藏陷阱某条广告突然爆红流量集中打到单个聚合节点上怎么办本章方案热点聚合节点向资源管理器申请额外资源 → 事件被拆成 3 组由 3 个临时 Aggregate 节点各处理 100 条 → 结果写回原节点再进入 Reduce。更高级的做法还有 Global-Local Aggregation 与 Split Distinct Aggregation。八、容错与数据正确性监控聚合节点在内存中处理数据宕机会丢中间状态。恢复手段利用 Kafka 的消费者 offset从断点继续对进行中的 Top N 聚合状态做分钟级快照新节点读取最新 offset 最新快照即可无缝接管监控方面要盯住三个指标端到端延迟、队列积压Kafka 场景下看 records-lag 指标积压突增就该加聚合节点、聚合节点资源CPU、磁盘、JVM。最后正确性靠日终对账批处理兜底从原始数据重新计算聚合结果与聚合数据库中的实际值比对发现不一致就告警修正九、替代方案直接用成熟大数据组件面试中不要求你精通所有大数据工具内部实现讲清思路与权衡更重要。若想直接用现成组件可以原始点击数据存入Hive上面架一层ElasticSearch加速查询聚合交给ClickHouse / Druid这类 OLAP 数据库分别服务商家侧分析与数据科学家查询两类场景。十、本章总结一张图看完整链路 设计要点本章方案架构模式Kappa 架构单条流处理链路 原始数据兜底重算聚合引擎Map-Reduce DAGMap 分发 / Aggregate 计数 / Reduce 汇总时间语义事件时间 水位线容忍迟到事件窗口滚动窗口点击计数 滑动窗口Top N投递语义Exactly-Once靠分布式事务或下游幂等实现扩展性三组件独立扩容 资源管理器缓解热点正确性监控 日终对账双保险本章覆盖的设计要点可回溯到笔记目录Readme.md 中列出的其他章节如 19. Distributed Message Queue 讲 Kafka 细节、02. Back Of the Envelope Estimation 讲容量估算能帮你在面试中把广告点击聚合这类大数据系统设计讲得更扎实。【免费下载链接】system-design-notesNotes of the book System Desgin Interview - An Insiders Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考