腾讯广告的数据分析系统.pptx
- 【下载声明】
1. 本站全部试题类文档,若标题没写含答案,则无答案;标题注明含答案的文档,主观题也可能无答案。请谨慎下单,一旦售出,不予退换。
2. 本站全部PPT文档均不含视频和音频,PPT中出现的音频或视频标识(或文字)仅表示流程,实际无音频或视频文件。请谨慎下单,一旦售出,不予退换。
3. 本页资料《腾讯广告的数据分析系统.pptx》由用户(无敌的果实)主动上传,其收益全归该用户。163文库仅提供信息存储空间,仅对该用户上传内容的表现方式做保护处理,对上传内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知163文库(点击联系客服),我们立即给予删除!
4. 请根据预览情况,自愿下载本文。本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
5. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007及以上版本和PDF阅读器,压缩文件请下载最新的WinRAR软件解压。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 腾讯 广告 数据 分析 系统
- 资源描述:
-
1、腾讯广告的数据分析系统腾讯社交广告 丰富的广告资源 精准的定向能力数据分析 查询时聚合 预先将数据处理成易 预先聚合 实时+离线于查询的格式 灵活性高 灵活性不够 查询速度快 查询时计算量大预先聚合的计算系统LAMDA架构实时离线接入消息队列yarnTDWstormHdfsTimerspoutspout spout spout spout计算存储MapReduceHdfsBoltBoltBoltHBase实时性 + 可靠性统一计算框架 问题:任务越来越多,计算资源消耗越来越大 合并原始数据聚合的工作,减少重复IO和数据解析的开销 多个pig, hive, mapreduce - 一个mapre
2、duce生成多个聚合结果 一份代码,易于性能优化 时间均匀分布,提高集群利用率任务解耦 流式计算111222333444日志1日志2日志3理想数据及时到达时间11223344计算任务日志1日志2日志31234现实总是有数据晚到如何减少MTBF?12 3 4时间123456计算任务平均故障次数= 每个日志源的故障次数 + 计算系统故障次数任务解耦:只计算已经就绪的数据。某个日志源故障不会影响其他数据。避免故障时机群空闲,恢复后机群压力过大。向流式计算系统演进一代系统:lambda架构快Storm纯内存计算,实时,不准确MapReduce离线计算,准确,慢实时离线两套系统,代码实现和环境部署都是两
3、套准二代系统:流式计算Spark Streaming同时做到准确实时Spark worker常驻进程,避免进程启停开销Spark分层调度,减少中央调度器的压力快+准Mapreduce - spark streamingSpark Streaming的优势常驻进程,避免任务分发的延迟和消耗分层调度,降低调度器负载内存加速计算MapReduce任务里面,yarn既要管理工作流各任务的依赖,又要管理每个任务在不同时间的实例。Spark Streaming里面,每个任务在不同时间的实例是在sparkdriver里面管理的计算流程日志切分:数据按最细时间粒度落地到hdfs计算:分粒度聚合,输入输出都在h
4、dfs,相当于用spark调度更小的mapreduce作业将hdfs目录当做checkpoint,不依赖spark的状态输出到hbase 需要保证操作幂等 采用put而不是increase 每次输出的时候,累加过去N个周期的计算结果 与上次周期的输出数据计算diff,减少对hbase压力 不采用spark window,避免输出任务batch之间依赖,在集群抖动时快速恢复 利用hbase version,避免新数据被老数据覆盖调度优化 推测执行,避免struggle 会有很多的推测备份任务被杀掉调度优化 优化思路 利用 streaming周期任务的特点,动态评估每个 executor 的吞吐量
5、 能力强的节点分配大任务,能力弱的节点分配小任务 实现 a) RDD 及 NewHadoopRDD:获取每个 task 对应的 HDFS 文件的 大小并上报 b) 在每个 batch 结束时,分析 executor 处理任务的情况,动态更新到 driver 端的记录里 c) 按照 executor 的 吞吐量排序在任务列表里选择合适的任务Executor1(4MB/s)Task(32M)Task(32M)Executor1(8MB/s)Task1(128M)Task2(120M)1234选择最适合executor 3执行的任务Executor2(1MB/s)Task(128M)Task(128
6、M)Executor2(4MB/s)Task3(110M)Task4(96M)Executor3(2MB/s)Task5(80M)Task6(78M)Executor1(4MB/s)Task(128M)Task(32M) * 5 = 3Executor2(1MB/s)Task(32M)Task(128M)Executor4(1MB/s)Task7(75M)Task8(70M)调度优化 性能提升 a) 推测任务减少 86.57%b) 计算延迟降低 20.96% c) 少用 1/10 资源 预先聚合的计算系统 统一计算框架 Lamda架构-spark streaming查询时聚合的计算系统要解决的
7、问题 - SQL举例 从万亿条数据中选择符合条件的数据,计算聚合结果 查询用户年龄性别的分布SELECT age, gender, COUNT(*) FROM log WHERE advertiser_id=123 group by age, gender; 查询不同曝光次数的用户的占比、点击率、消耗等SELECT exposure_num, COUNT(*) as user_num,SUM(sum_click) / SUM(exposure_num) as click_rate, SUM(sum_cost) AS total_costFROM(SELECT user_id, COUNT(*)
8、 AS exposure_num,SUM(click_count) AS sum_click, SUM(cost) AS sum_costFROM logGROUP BY user_id) temp_tableGROUP BY exposure_num;流程描述分组Groupby聚合Sum|Count|原始数据集过滤Where流程描述:结果 从万亿条数据中选择符合条件的数据,计算聚合结果 为了提高查询速度,就需要预先将数据整理成适合查询的格式两种数据模型1. 平铺结构:宽表,其中每个cell可以是term list,可以有正排,倒排2. 嵌套结构:proto buffer,正排存储类似于dre
9、mel/parquet,没法倒排Message pageview optional UserProfile user;repeated Position pos repeated Impression imps optional Advertisement ad;repeated Click clicks optional BillInfo bill;嵌套结构的列存储格式 dragon 同列数据连续存储,压缩效率高 读取数据只需读取需要的列,节省磁盘IO 读取数据省去了反序列化整个PB的过程 定义repetition level和definition level 只存储叶子节点的值和rleve
10、l,dlevelDragon vs parquet文件大小(单位:MB)写入时间(单位:秒)80060040020007005004003002001000383289Dragonparquetrecordio254Dragonparquet266271211161138153请求日志曝光日志请求日志曝光日志数据读取耗时(单位:秒)864206.76.73.40.56.74.5DragonParquetRecordio2.10.11.6读一列 读三列 读十列数据特点Message pageview 空节点很多optional UserProfile user;Pageview:3000+叶子节
展开阅读全文