腾讯广告的数据分析系统

下载 5

大佬陈

发布于

2670

人观看

#信息技术

腾讯广告的数据分析系统

展开查看详情

1 .20 18 中国大数据技术大会（ BD TC ）李锐腾讯广告的数据分析系统

2 . ） TC BD 关于我（会大术 11年加入腾讯技据关注分布式存储和计算系统数现负责腾讯广告数据系统大国中 18 20

3 .腾讯社交广告） TC • 丰富的广告资源 BD （会大术技据 • 精准的定向能力数大国中 18 20

4 .数据分析） TC • 预先聚合 • 查询时聚合 BD （ • 实时+离线 • 预先将数据处理成易会大于查询的格式术技 • 灵活性不够据 • 灵活性高数 • 查询速度快大 • 查询时计算量大国中 18 20

5 .20 18 中国大数据技术大会（ BD 预先聚合的计算系统 TC ）

6 .LAMDA架构） TC BD 实时离线（接入消息队列会 yarn TDW 大 storm 术 Timer Hdfs 技 spout spout spout spout spout 据计算数 MapReduce 大 Bolt Bolt Bolt 国中 HBase Hdfs 18 存储 20 实时性 + 可靠性

7 .统一计算框架） TC • 问题：任务越来越多，计算资源消耗越来越大 BD （会 • 合并原始数据聚合的工作，减少重复IO和数据解析的开销大 • 多个pig, hive, mapreduce -> 一个mapreduce生成多个聚合结果术 • 技一份代码，易于性能优化据 • 时间均匀分布，提高集群利用率数大国中 18 20

8 .任务解耦 – 流式计算） TC 日志1 1 2 3 4 BD 理想日志2 1 2 3 4 （日志3 1 2 3 4 数据及时到达时间会大计算任务 1 2 3 4 术技日志1 1 2 3 4 据日志2 1 2 3 4 现实数日志3 1 2 3 4 总是有数据晚到大时间国如何减少MTBF？计算任务 1 2 3 4 5 6 中 18 平均故障次数= ∑ 每个日志源的故障次数 + 计算系统故障次数 20 任务解耦：只计算已经就绪的数据。某个日志源故障不会影响其他数据。避免故障时机群空闲，恢复后机群压力过大。

9 .向流式计算系统演进） TC BD 一代系统:lambda架构快（ •Storm纯内存计算，实时，不准确会 •MapReduce离线计算，大准确，慢术 •实时离线两套系统，代准技码实现和环境部署都是两套据数大二代系统:流式计算国 •Spark Streaming同时做到中准确实时 •Spark worker常驻进程， 18 避免进程启停开销快+准 20 •Spark分层调度，减少中央调度器的压力

10 .Mapreduce -> spark streaming ） TC •Spark Streaming的优势 BD •常驻进程，避免任务分发的延迟和消耗 •分层调度，降低调度器负载 •MapReduce任务里面，yarn既要（ •内存加速计算管理工作流各任务的依赖，又要会管理每个任务在不同时间的实例。大 •Spark Streaming里面，每个任务术在不同时间的实例是在spark 技 driver里面管理的据数大国中 18 20

11 .计算流程） TC BD （会大术技据数大 日志切分：数据按最细时间粒度落地到hdfs 国 计算：分粒度聚合，输入输出都在hdfs，相当于用spark调度更小中的mapreduce作业 18 将hdfs目录当做checkpoint，不依赖spark的状态 20

12 .输出到hbase ） TC • 需要保证操作幂等 BD （ • 采用put而不是increase 会 • 每次输出的时候，累加过去N个周期的计算结果大术 • 与上次周期的输出数据计算diff，减少对hbase压力技据 • 不采用spark window，避免输出任务batch之间依赖，在集群抖动时数快速恢复大国 • 利用hbase version，避免新数据被老数据覆盖中 18 20

13 .调度优化） TC • 推测执行，避免struggle BD （ • 会有很多的推测备份任务被杀掉会大术技据数大国中 18 20

14 .调度优化） TC • 优化思路 BD • 利用 streaming周期任务的特点，动态评估每个 executor 的吞吐量（ • 能力强的节点分配大任务，能力弱的节点分配小任务会 • 实现大术 • a) RDD 及 NewHadoopRDD：获取每个 task 对应的 HDFS 文件的大小并上报技 • b) 在每个 batch 结束时，分析 executor 处理任务的情况，动态更新到 driver 端的记录里据 • c) 按照 executor 的吞吐量排序在任务列表里选择合适的任务数 Executor1 (4MB/s) Task (32M) 大 Task (32M) 1 Executor1 (8MB/s) 选择最适合 Task1 (128M) Task2 (120M) 国 executor 3 Executor2 Task Task Executor2 Task3 Task4 执行的任务中 (1MB/s) (128M) (128M) 2 (4MB/s) (110M) (96M) 18 Executor1 Task Task Executor3 Task5 Task6 3 (4MB/s) (128M) (32M) (2MB/s) ⌊¾ * 5⌋ = 3 (80M) (78M) 20 Executor2 Task Task Executor4 Task7 Task8 4 (1MB/s) (32M) (128M) (1MB/s) (75M) (70M)

15 . 调度优化） TC • 性能提升 BD • a) 推测任务减少 86.57% b) 计算延迟降低 20.96% （会大术技据 • c) 少用 1/10 资源数大国中 18 20

16 . ） TC BD （  预先聚合的计算系统会大  统一计算框架术技  Lamda架构->spark streaming 据数大国中 18 20

17 .20 18 中国大数据技术大会（ BD 查询时聚合的计算系统 TC ）

18 .要解决的问题 - SQL举例） TC • 从万亿条数据中选择符合条件的数据，计算聚合结果 BD 查询用户年龄性别的分布（ • 会 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_cost 据 FROM 数 (SELECT user_id, COUNT(*) AS exposure_num, 大国 SUM(click_count) AS sum_click, SUM(cost) AS sum_cost 中 FROM log 18 GROUP BY user_id) temp_table 20 GROUP BY exposure_num;

19 .流程描述） TC BD （分组聚合会原始数过滤大流程描述： Group Sum|Cou 结果据集 Where 术 by nt|… 技据数 • 从万亿条数据中选择符合条件的数据，计算聚合结果大 • 为了提高查询速度，就需要预先将数据整理成适合查询的格式国中 18 20

20 .两种数据模型） TC BD 1. 平铺结构：宽表，其中每个cell可以是term list，可以有正排，倒排（ 2. 嵌套结构：proto buffer，正排存储类似于dremel/parquet，没法倒排会 Message pageview { 大 optional UserProfile user; 术 repeated Position pos { 技 repeated Impression imps { 据 optional Advertisement ad; 数大 repeated Click clicks { 国 optional BillInfo bill; 中 } 18 } 20 } }

21 .嵌套结构的列存储格式 dragon ） TC BD • 同列数据连续存储，压缩效率高（ • 读取数据只需读取需要的列，节省磁盘IO 会大术 • 读取数据省去了反序列化整个PB的过程技据 • 定义repetition level和definition level 数大 • 只存储叶子节点的值和rlevel，dlevel 国中 18 20

22 .Dragon vs parquet ） TC 文件大小（单位：MB）写入时间（单位：秒） BD 800 700 500 383 （ 600 400 Dragon 300 254 289 会 400 266 271 Dragon 211 parquet 200 138 大 200 153 161 parquet recordio 100 术 0 0 技请求日志曝光日志请求日志曝光日志据数数据读取耗时（单位：秒） 8 6.7 6.7 大 6.7 国 6 4.5 Dragon 中 4 3.4 2.1 Parquet 18 2 1.6 0.1 0.5 Recordio 20 0 读一列读三列读十列

23 .数据特点） TC Message pageview { • BD 空节点很多 optional UserProfile user; • Pageview：3000+叶子节点 repeated Position pos { （ • Pos : 3000+叶子节点 repeated Impression imps { 会 • Imps : 2000+ 叶子节点 • Click : 1000+ leaves optional Advertisement ad; 大 • Candidated_ads : 200+ 叶子节点 repeated Ad candidate_ads; 术 repeated Click clicks { 技 optional BillInfo bill; 据请求日志曝光日志 } 数 } Empty Columns 2926 大 2868 } } 国 Empty 855 831 中 Groups 18 20

24 .Dragon写性能优化：非递归实现） TC BD column io: col name, max d, max r, children fileld writer: traverse message in dfs message （会大 message 术 consumer 技据数大 column writer column writer 国中全空子节点的rlevel/dlevel是0,1,2…的序列， 18 编码后浪费大量空间不输出完全为空的叶子节点 20 column writer：<R,D,V>chunk writer 24

25 .Dragon写性能优化：空节点缓存） TC Proto 模板 Group : List<Pair<R,D>> BD message1 message2 （会大术技据 message3 message4 数大国中遇到空节点，先不用遍历子树，缓存 18 到有值或文件结束 20 再遍历到子节点 25

26 .Dragon写性能优化：Discard early ） TC BD • 最后一次刷空节点缓存非常的耗（时会 • Proto Tempate中每一个节点增大加一个字段，标记该节点及其所术技有孩子节点是不是完全为空（默据认为true）数 • 最后一次刷空节点缓存只刷写不为空的group 大国中 18 20

27 .Dragon写性能优化：lazy flush ） TC • 每次刷空节点缓存时，只刷到孩子节点，而不是叶子节点 BD （ Proto 会优化前优化后 template 大术技据数 Total 大 empty 国中 27 18 20

28 .索引文件设计） TC BD 索引数据结构：全局信息列值字典倒排数据正排数据（每一列(Column)的值列值ID对应的文档ID 列式存储的压缩数据会编码为列值(Term ) ID 列表大检索查询流程：术技查询条 • Where age>=20 and age<30 据件 SELECT gender, COUNT(*) 数 FROM log 命中列 • 找到age满足条件的列值ID WHERE age>=20 and age<30 值大 GROUP BY gender; 国倒排拉 • 拉出列值对应的倒排拉链中链 18 集合运 • 根据逻辑对结果进行集合运算 20 算

29 .列值字典String压缩） TC • 前缀压缩节省空间 BD • 例如词表：{“aa”, “abc”, “abcd”, “abd”, “abe”} （会 • 实现采用更高效的Vector前缀压缩大 • 词表排序之后，利用两两相邻的两个词的前缀压缩。仅保存后一术个词相对前一个词的后缀部分内容技 • 支持按词ID快速定位据数大国 struct Node { 中 uint32_t suffix_offset; // 后缀在suffix block中的偏移 18 uint8_t common_len; // 与前一个词的公共前缀长度 20 }

11点赞

3收藏

5下载