第9讲大数据架构设计理论与实践大数据架构设计案例分析二.pptx

第十九章大数据架构设计理论与实践大数据架构设计案例分析Lambda架构在某网广告平台的应用与演进应用系统架构设计师第二版

综合知识精讲培训课讲师：邵宗其

考点分析本章主要学习大数据方向软件架构的发展和工作中的实践。根据考试大纲，本小时知识点会涉及案例分析题和论文题（各占25分）。本小时内容侧重于理解性记忆，按照以往的出题规律，部分基础知识点来源于教材，部分考查内容需要灵活运用相关知识点。知识架构如图所示。大数据架构设计理论与实践

Lambda架构在某网广告平台的应用与演进系统建设背景某网广告平台依托于某网微商城，帮助商家投放广告。通过某网广告平台，商家可以在腾讯广点通、云堆、小博无线等流量渠道投放广告。对于某网广告平台，除了提供基础的广告编辑、投放、素材管理等功能，最重要的就是广告的投放效果的展示、分析功能。某网广告平台的数据分析模块提供了不同的时间维度(天、小时),不同的实体维度(广告计划、广告、性别、年龄、地域)下的不同类型指标(曝光、点击、花费、转化下单、增粉数)的分析。所有这些数据都是秒级到10min级别的准实时数据，为了做到将实时数据和离线数据方便的结合，引入了大数据系统的Lambda架构，并在这样的Lambda架构的基础下演进了几个版本

数据需求与场景大数据处理技术需要解决数据的可伸缩性与复杂性。首先要很好地处理分区与复制，不会导致错误分区引起查询失败。当需要扩展系统时，可以非常方便地增加节点，系统也能够针对新节点进行rebalance。其次是要让数据成为不可变的。原始数据永远都不能被修改，这样即使犯了错误，写了错误数据，原来好的数据并不会受到破坏。某网广告平台展示的数据指标包含两类：曝光类(包括曝光数、点击数、点击单价、花费),转化类(包括转化下单数、转化下单金额、转化付款数、转化付款金额)。前一类的数据主要由流量方以接口的方式提供(比如对接的腾讯广点通平台),后一类则是某网特有的数据，通过买家的浏览、下单、付款日志算出来。Lambda架构在某网广告平台的应用与演进

系统架构第一版采用了典型的Lambda架构形式，架构图如19-14所示。批处理层每天凌晨将Kafka中的浏览、下单消息同步到HDFS中，再将HDFS中的日志数据解析成Hive表，用HiveSql/SparkSql计算出分区的统计结果Hive表，最终将Hive表导出到MySQL中供服务层读取。另一方面，曝光、点击、花费等外部数据指标则是通过定时任务，调用第三方的API,每天定时写入另一张MySQL表中。实时处理层则是用SparkStreaming程序监听Kafka中的下单、付款消息，计算出每个追踪链接维度的转化数据，存储在redis中。服务层则是一个Java服务，向外提供http接口。Java服务读取两张MySQL表和一个Redis库的数据。第一版Lambda架构在某网广告平台的应用与演进

系统架构第一版的数据处理层比较简单，性能的瓶颈在Java服务层。Java服务层收到一条数据查询请求之后，需要查询两张MySQL表，按照聚合的维度把曝光类数据与转化类数据合并起来，得到全量离线数据。同时还需要查询业务MySQL,找到一条广告对应的所有rediskey,再将redis中这些key的统计数据聚合，得到当日实时的数据。最后把离线数据和实时数据相加，返回给调用方。这个复杂的业务逻辑导致了Java服务层的代码很复杂，数据量大了之后性能也跟不上系统要求。另一方面，实时数据只对接了内部的Kafka消息，没有实时的获取第三方的曝光、点击、浏览数据。因此，第一版虽然满足了历史广告效果分析的功能，却不能满足广告操盘手实时根据广告效果调整价格、定向的需求。第一版Lambda架构在某网广告平台的应用与演进

系统架构针对第一版的两个问题，在第二版对数据流的结构做了一些修改。在实时处理层做了一个常驻后台的Python脚本，不断调用第三方API的小时报表，更新当日的曝光数据表。这里有一个小技巧：由于第三方提供的API有每日调用次数上限的限制，将每天的时间段分为两档：1:00—8:00为不活跃时间段，8:00至第二天1:00为活跃时间段，不活跃时间段的同步频率为30min一次，活跃时间段为10min一次。每次同步完数据之后会根据当天消耗的API调用次数和当天过去的时间来计算出在不超过当天调用次数前提下，下一次调用需要间隔的时间。同步脚本会在满足不超过当天限额的前提下尽可能多的调用同步API。从而避免了太快消耗掉当日的调用限额，出现在当天晚上由于达到调用限额而导致数据无法更新的情况。在批处理层，把转化数据表和曝光数据表导入到Hive中，用HiveS