腾讯大数据平台与推荐应用架构


腾讯大数据平台与推荐应用架构 Zeus(蒋杰)Zeus(蒋杰) 2014.08 1 提纲  腾讯大数据发展概况  大数据平台之基础架构  大数据应用之实时精准推荐 2 月活跃用户8.3亿,最高同时在线2.1亿; 在线人际关系链超X000亿; 月活跃4.4亿; 日均消息量超X0亿; 腾讯数据现状 月活跃用户数6.5亿; 日均相册上传超过X亿,日写操作总数过X0亿; 腾讯游戏月活跃用户超X亿; 手机游戏月活跃用户超X亿; 日均pv超X亿,手机侧近超X亿; 日均uv超X千万,手机侧超X千万; 部分数据来自腾讯2014第二季度综合业绩报告 3 4 平台服务 数据服务 开发者平台 对外服务 推荐服务 IDEA FACE 画像计算 通用推荐 广告推荐 TDBANK 数据产品 黄金眼应用 产品 服务 接入 大数据平台整体规划 TDBANK GAIA 洛子 运 维 监 控 测 试 HIVE HADOOP SPARK STORM PG HERMES HDFS TDE实时数据存储 TRE实时算法预测 TMT实时模型训练分析统计任务 PIG 接入 计算 存储 调度 HBASE 5 数据平台体系化是应用基础 数据应用商业化是价值导向数据应用商业化是价值导向 6 • 数据接入 数据处理 • 查询分析 平台体系化的基本思路 • 数据接入 • 数据存储 数据积累 • 离线计算 • 实时计算 • 查询分析 • 数据挖掘 数据应用 7 GaiaGaia 资源管理与调度 8 Gaia 打造大数据云操作系统 配置管理、单点容灾+性能,扩缩容,资源利用率…,统统不用操心! 资源调度和管理 Gaia 将一组机器映射成一台逻辑上的大机器 为上层提供简单、统一的资源界面 9 Gaia 核心特性 支持多种并行计算 框架 可扩展性好可扩展性好 资源隔离彻底 资源利用率高 10  强扩展性:支持单cluster万台规模 (8800节点,20w+核,1500个pool)  高调度吞吐:毫秒级的下发效率(App并发3.5k,Container匹配时间0.2ms)  弹性内存管理:hardlimit+softlimit相结合充分利用整机资源 Gaia 技术特点  弹性内存管理:hardlimit+softlimit相结合充分利用整机资源  多维度资源管理:新增Network IO、Disk IO等资源管理维度,提升了隔离性  丰富的用户api:为业务提供更便捷的容灾、扩容、缩容和升级等方式  建立“on Gaia”生态圈:支持storm、spark、MR等各种应用 11 (一)Gaia vs Yarn – 提升可扩展性 在规模为1万节点,1万作业,1200队列时, Yarn原生fair调度器平均每秒只能调度20个container。 一天只能调度170万个container。 而我们的现网集群, 平均每天调度的container数量为7000万+。 12 Gaia-资源调度器优化 – Yarn调度器 RM Scheduler NodePoolAppPool 2. Select an app 3. Launch container Match Resource Manager NodeManager Container Container 1. Heartbeat NodeManager Container Container NodeManager Container Container 13 Gaia-资源调度器优化 – sfair调度器 RM Scheduler NodePoolAppPool 3. Launch container ScheduleThread 2. Select an app Resource Manager Match NodeManager Container Container 1. Heartbeat NodeManager Container Container NodeManager Container Container • 心跳处理与调度解耦和:单集群规模扩展至1w个节点 • 控制多线程间的同步:优化线程间锁,将调度线程持锁时间减少70% • 优化队列和作业排序:取消全排序,采用堆排序,减少了调度器80%的CPU时间 • 降低调度开销:对无资源需求的app/queue,禁止其参与调度 14 Gaia-资源调度器优化–效果 经过优化,在大规模环境下,调度器的平均吞吐率从20提高到1000, 提高50倍。 优化前 优化后 优化前 上图优化前后的测试环境完全相同。均为1万节点,1万作业,1200队列。 15 网络出带宽管理 资源维度 Yarn Gaia Memory  Cpu  Disk space  Network IO  (二)Gaia vs Yarn-增加资源管理维度 网络出带宽管理  结合linux Cgroups和HTB  采用borrow机制,充分利用共享带宽资源 网络入带宽管理  自主知识产权,通过修改Linux内核实现,实现精准而弹性,高效率低损耗的入带宽隔离。 • 专利2013107167896 基于令牌桶的数据传输流量调度方法及其系统 • 专利201310743471.7 通过接收端主机标记ECN进行网络入流量限速的方法 • 专利2013107175144 根据令牌桶的水位调整TCP通告窗口的网络入流量主动限速方法 多磁盘管理  统一工作目录,为job提供更大磁盘空间  充分利用多磁盘IO并发 16 (三)Gaia-优化资源管理策略 • CPU管理 • 资源超发:提高资源使用率 • 基于优先级调度的cpu.share • 高优先级作业的服务质量得以保证 • 内存管理 • 引入EMC(Elastic Memory Control) • 采用hardlimit+softlimit结合的方式 • Hardlimit保证安全,不超机器总容量 • Softlimit保证充分利用整机资源 17 TDBankTDBank 实时数据接入平台 18 200TB 日接入数据量 10000个 10000亿 最高日接入消息条数 15,000亿 10000个 并发分拣业务接口 1-2s 采集平均时延 99.999% 可用度 19 从业务数据源端实时采集数据,进行预处理和分布式消息缓存后,按照 消息订阅的方式,分发给后端的离线和在线处理系统。 数据源 接入 TDBank 实时数据接入平台 数据缓存 预处理 数据 深加工 20 接入层 文件数据源 AgentFile DB DBSync TDBus TDBus 数据打包 / 接入层设计  全实时的数据传输过程  支持多种数据类型 带宽成本优化DB DBSync TDBus TDBus业务进程 / 压缩 / 加密 数据协议适配 数据去重公网/内网切换  带宽成本优化  接入全流程自助配置 21 Consumer Consumer Producer Producer Broker Broker Broker Broker Broker cluster 存储层设计-Tube系统架构  实现发布/订阅(P/S)模型  支持非持久化和持久化订阅  服务端集群部署,线性扩容 Consumer Consumer Master (active) Producer Producer Master (standby) Zookeeper Producer group Consumer group Master HA  生产者、消费者自动负载均衡  消息持久化,支持顺序消息  无单点设计,Master HA  毫秒级数据消费延迟 22 Topic Broker-0 Broker-1 存储层设计-Tube层次结构 Partition-0 Partition-1 Partition-n Segment Files Tube File-0 Tube File-1 23 Message 34477849968 Message 34477850175 Message 35551590806 Message 3555159179235551591793-36625333616 36625333617-37699075440 34477849968-35551591792 Segment Files topic/34477849968.tube Deletes Consistent views Active Segment List 存储层设计-Tube持久化模型 36625333617-37699075440 80648749159-81722490982 81722490983-82796232806 ... 82796232807-83869974630 Message 81477849968 Message 81477850175 Message 83868926054 Message 83869974630 Appends Consistent views Reads topic/ 81477849968.tube 24 分拣层 消息存储 Tube 数据分拣 Sort TDW HBase 分拣层设计  负责业务数据分发  支持分发到不同数据存储平台Tube Sort tPGStorm ...  支持分发到不同数据存储平台  支持十万级别接口数据并行处理  不同数据协议插件化管理 25  灵活:支持DB/文件/消息等多种接入方式  低成本:支持公网传输以及数据打包压缩  高可靠:支撑安全协议,数据可达零误差 TDBank 技术特点总结  高可靠:支撑安全协议,数据可达零误差  低时延:流式数据处理,毫秒级消息分发  可复用: 7天数据缓存,消息可重复订阅  快捷:与离线/实时数据计算平台无缝对接 26 1天 2秒 Linux HDFS TDW TDW集群 分布式 消息队 列 订阅 分发 挑战: T+1,实时性不足 忙时,入库压力大 流程,复杂维护难 质量,无法保证 消息队 列 TRC 优点: 主动实时采集 公网传输(已部署上万台Agent) 可用度提升至99.999% 消息缓存 27 TDWTDW 分布式数据仓库 28 单集群 8800台 CPU 140,000核 内存 560 TB 每天Job数 1,000,000+ 每天扫描数据量 10PB 存储利用率 85%内存 560 TB 磁盘 105,600块 存储容量 180 PB+ 存储利用率 85% CPU利用率 90%+ 网络利用率 90%+ 29 Hive / Pig Lhotse任务统一调度集成开发环境 IDE 腾讯自主研发,支持百PB级的数据存储和计算,提供海量、高效、稳 定的大数据平台支撑和决策支持。 TDW分布式数据仓库 Hive / Pig 查询处理引擎 计算 引擎 MapReduce 存储 引擎 HDFS HADOOP 集群 TDBank数据采集 Postgre 小数据 处理 HBase 实时 查询 资源管理和调度 Gaia Spark 内存 计算 30 HermesHermes 实时多维分析平台 31 在单表亿万级数据、万级维度的量级下,用户可以在该平台上进行任意 维度组合、任意层级下钻等分析作业,但结果响应只需要在数秒以内。 Hermes实时多维分析平台 自定义数据 包实时数据 离线数据 数 据 源 用户包服务用户包服务Open-APIOpen-API 接 口 层 功能 扩展 层 嵌套列存储文件嵌套列存储文件 存 储 层 位图文件位图文件 Hermes计算引擎 计 算 层 数据调度服务数据调度服务 服 务 层 查询服务查询服务 配置管理 Hermes管理层 容灾管理 负载调度 运维工具 32 Hermes存储结构设计 33 Hermes数据实时加载 Ram A Ram B Ram C Ram D Ram E 10:00:00-10:15:00 10:15:00-10:30:00 10:30:00-10:45:00 10:45:00-11:00:00 …… Merg 实时数据计算集群 实时数据 实时数据 实时数据 +  在接入实时数据的同时对外提供检索服务  实时数据存于内存,到达一定周期后将merge并flush到磁盘 历史数据计算集群 Merg e Disk A …… Disk B 9:00:00-10:00:00 Disk C 10:00:00-11:00:00 周期性数据 周期性数据 周期性数据 + 请求查询 34 Hermes应用之:用户画像分析 35  多维分析场景  5000亿数据记录、8000个维度指标、约500TB存储量  查询分析秒级响应,无cache情况下80%左右查询3秒内返回  1亿数据量Count耗时50ms Hermes运营数据 1亿数据量Count耗时50ms  1亿数据量sum,group by,join耗时1~3s  全文检索场景  20万广告查询获取结果7万并导出耗时0.7ms  2000亿数据检索并导出结果10万耗时3s 36 SparkSpark 基于内存计算的大数据处理框架 37 Cluster Manager Worker Node Executor Cache Task Task Worker Node Client (Driver) Spark,更高效的分布式计算系统 Worker Node Executor Cache Task Task 内存Cache:支持反复迭代计算或者多次数据共享,减少IO开销 DAG并行计算:减少多次计算之间中间结果读写HDFS开销 多线程池:减少task启动开销 38 Spark,当前存在的主要不足 stage1 stage2 stage3 Master application1 job application2 job1 job2 job… worker executor executor worker executor executor worker executor 构建DAG并调度 stage FIFO Task Task Task job… executor executor executor worker executor DAGScheduler TaskScheduler 调度 task 集群规模小:FIFO调度策略初级,资源隔离能力低下 执行参数需人工设置:job申请资源、map和reduce数目设定不合理导致资源浪费 使用门槛高:Scala语言学习成本,Shark/SQL稳定性和语法功能不足 39 (一)Spark on Gaia Resource Manager 2. 启动 AppMaster 3. 申请 Executor资 源 4. 分配 Container Spark Gaia Client HDFS 0. 上传Spark和 Driver Jar到 HDFS 1. 提交请求 Application Master DAGScheduler SparkGaiaClusterScheduler 源 Executor Node Manager Node Manager Executor Node Manager 40 (一)Spark on Gaia—AM容灾 Resource Manager Node Node XNode 新启动一个 AppMaster  Executor所在的Container不停止  新启动一个AM,从HDFS上读取状态信息,恢复状态 HDFS Application Master DAGScheduler SparkGaiaClusterScheduler Executor Node Manager Node ManagerXApplication Master DAGScheduler SparkGaiaClusterScheduler Node Manager 从HDFS上读 取状态做恢复 41  通过配置参数设置资源数  固定,不可伸缩  内存计算、流式实时计算: Executor服务常驻、资源需要客 户端评估,服务端不做自动设置  批处理:Executor服务有生命周 Resource ManagerSpark Gaia Client AppMaster Executor1 Node Manager Executor2 Node Manager Executor3 Node Manager (二)Executor资源数的自动设置 stage1 stage2 stage3 取各个Stage的 tasks最大值 3 tasks 2 tasks 1 tasks s1:t1 s2:t1 s1:t2 s2:t2 s1:t3 s1:t3执行完 s1、s2执行完 s3:t1 s3执行完  批处理:Executor服务有生命周 期,资源评估不需要客户端参与 ,服务端做自动设置 Executor1 Executor2 Executor3 Executor1 Executor2 Executor3 Executor1 Executor2 Executor3 Executor1 Executor2 Executor1 42 Stage1 Map r1-file r2-file r3-file (二)Reduce数的自动设置 • 根据map端的输入数据确定 map数以及预设reduce数 Map r1-file r2-file r3-file Stage2 Reduce 1 Reduce 2 r1-file r2-file r3-file Reduce 3 • 根据上一阶段输入数据量来 动态重新确定reduce数 r1-file r2-file r3-file 43 TDW Hive Shark Spark Sql TDW Hive metastor e Sql parser SerDes, UDFs Command-line shell Thrift / JDBC Driver Query Optimiz er Physical Plan Execution (三)TDW Hive on Spark MapReduce Spark Execution MapReduce Spark Shark、Spark Sql稳定性和成熟度不足 Shark、Spark Sql在语法和功能上不及TDW Hive丰富(分区功能(List、Range等)、 和PG结合、类似于Oracle的语法) 对TDW老用户保持良好体验,自适应切换 44 (四)其他 – 修复30+bug Shark Groupby、Join、Order by OOM Spark的Stage重跑时,以前的task没有被杀掉,还在运行,以前的task和新的重 跑的task并发执行,在创建HDFS文件时会出现脏数据出错 多个SparkContext共存 本地磁盘坏、目录不存在或者目录不可写,spark的Job执行会失败 Spark AppMaster向GAIA发起资源申请成功申请到资源之后没有及时清除请求, 造成GAIA记录这个请求越来越多,下发多余的资源 45 Spark Streaming,大规模流式处理 • Vision:one stack to rule them all • 三种情景的输入输出数据无缝共享,无需进行格式转换 • 同一款开源软件,降低开发和维护团队成本 • Spark Streaming 继承Spark容错设计 46 Spark Streaming,主要优化方向 AppMaster Driver ReceiverExecutor Executor 流式数据生成RDD • Batch生成:只能按照系统时间生成RDD,不能以数据时间的维度生成RDD • 使用门槛高:开发Spark Streaming应用成本较高 • 容灾:Driver与Receiver暂不支持容灾 47 Executor Driver (一)支持Data Time recei ver ReceiverTra cker AddBlo ck JobGenerat or JobSetJobScheduDAGSchedu [DTime, blockId] [DTime, updateTime] [DTime,Queue[BlockId]] 实现逻辑  Receiver接收数据并为Block增加数据时间字段,一段时间产生的Block数由一个 变为多个,不同DTime的记录属于不同Block。  ReceiverTracker接收Block后,根据数据时间分组。  JobGenerator每秒轮询接收到的块信息,把一段时间未更新的Block创建RDD并 启动一个SparkJob处理。 JobSetJobSchedu ler DAGSchedu ler 48  对用户脚本进行语法/语义分析,生成语法树  将语法树编译生成逻辑执行计划  生成SparkStreaming物理执行计划 语法/语义分析 逻辑计划 用户SQL脚本 TDBank 输入表 输出表 (二)SQL on Spark Streaming  生成SparkStreaming物理执行计划  支持TDBank表,KV表,DB表作为输入输出  支持JOIN,Group BY,去重统计等功能  支持按照数据时间进行统计 SparkStreaming- DAG 物理计划 逻辑计划 Spark-Yarn Gaia TDBank (流水表) KV/DB (关联表) TDBank KV/DB 49 (三)关键节点容灾-Receiver容灾 1 Reciever接受数据 2 缓存数据 3 处理数据 4 删除数据 5 提交Tube的当前位置偏移量 当一批数据完整执行完成之后 记录一个checkpoint,如果 Receiver出现挂掉,会从上一个 checkpoint点开始读取 Tube Buffer RDD Compute 删除数据 提交偏移量 50 RDD Map ……. 业务接口层 通用算子层 Hive SQL Streaming MLlib Graphx filter union Group by join count 下半年目标,逐步建设Spark生态圈,单集群1000台 DAGScheduler Executor Cache Executor ………. . AppMaster/Driver Node 1 Node N task task RDD 计算引擎层 通用算子层 资源管理层 Gaia-资源调度 Cache TaskScheduler CachManager BroadManager JobListener/UI 51 数据平台体系化是应用基础 数据应用商业化是价值导向数据应用商业化是价值导向 52 实时精准推荐生命周期极简图 53 实时精准推荐核心模块 数据上报通道 实时请求通道 腾讯精准推荐平台 TDBank实时接入 HDFS TRC实时计算平台 TRE推荐引擎 效果广告、视频、新闻、购物、本地化生活等个性化精准推荐 TDBank实时接入 TDP流式计算 TDE分布式KV存储 Spark实时模型训练 实时 统计 实时算法 CB AR MF 用户画像 广告信息 LR DNN 实时 采集 压缩 加密 分拣 过滤 HDFS 点击、曝光、转化日志 实时 画像 Centrum 模型加载 CF MF 其他 点击预 估模型 转化预 估模型 ROI预 估模型 混合 模型 其他 推荐预测 filterin g scoring sortin g rerankin g 54 用户画像为核心基础 以效果广告为代表的精准营销 以视频推荐为代表的相关推荐 以电商推荐为代表的效果推荐 实时精准推荐应用现状 以电商推荐为代表的效果推荐 QQ好友,微博等关系链推荐 QQ秀,APP应用类推荐 Tips定向推荐 … 55 50ms PC端 单次推荐请求控制时间50ms以内 10ms 移动端 单次推荐请求控制时间10ms以 1 ‰~1% 用户-物品的评价/行为矩阵过于稀疏,密度百分位~千分位低 挑战-实时精准推荐 I 40% VS 1 单推荐位 40%的用户,一天内,曝光 = 1 80% VS 3 单推荐位 80%的用户,一天内,曝光< 3 3-9 以效果广告为例,大部分推荐素材对应的的生命周期仅有3-9天 10,000 + 通常单个推荐位可投物品在数十万级别以上 10 bn+ 日均推荐请求量可达100亿次+ 56 VS0.20% 1.70% 挑战-实时精准推荐 II 1.1% VS 0.21% 57 推荐关键点  数据  算法 用户  算法  系统 推荐引擎 物品上下文 58 人口属性 (年龄,性 别,学历…) 其他 (搜索、付费、 设备imei…) 用户画像 社交属性 (QQ,qzone、 朋友关系链…) 海量数据-大数据之腾讯  数据 • 8亿 月活跃用户数8亿 • 40亿 日均用户行为40亿次以上 • 100亿+ 单产品日均请求百亿量级 • 1000亿+ 用户关系链累积千亿量级用户画像 内容偏好 (腾讯网, 视频,微博) 电商兴趣 (网购、拍拍、 易迅…) 游戏爱好 (游戏时长、 付费…) • 1000亿+ 用户关系链累积千亿量级 • 15000亿 日均支撑多维度交叉计算量 • …  格式多样 • 结构化数据 文本 图像 音频 视频 … 59 用户画像 - 基础属性校准 Nick 注册年龄 25岁 ?北大博士?  好友年龄分布  不同平台的注册 年龄 校验 高富帅? 70后!  微博上follow的名人 粉丝群年龄分布  加入的班级群 &行业群分布  CNKI&SCI&EI&Citeseer检索分布  … 40岁高中毕 业 大叔是也! … 交叉 校验 分布 迭代 60 算法-谱系  用户实时行为 • 关联,重定向  老用户-老物品 • 经典模型效果好  老用户-新物品 规则算法 (重定向, 关联规则,热度,…) 基于内容的算法  老用户-新物品 • 借助物品相关的标签,类目,以及提 取的图像特征等  新用户-老物品 • 借助用户分群,转移学习等  新用户-新物品 • 寻找相关信息量 协同过滤算法 (基于邻域,各种矩阵分解,…) 图算法 (最近邻,各类图挖掘,…) 分类算法 (LR,RDT,GBDT,NN,…) 混合算法 61  都是女装美图,结果不同 1.1 % CTR 智能算法–如何有效提取新特征? 0.21% CTR 62 智能算法-基于深度学习的推荐 特征提取:CNN+DNN整体训练 X2:用户特征 物品特征 CNN DNN Y2: Click ratio 抽取的图像特征 与LR融合:两种方式  Ensemble方式  加特征方式,解决性能问题 • 抽取其中CNN层输出的图像特征,加入LR X1图片像素 物品特征 X2:图像亮度、对比度等 63 63 大规模并行机器学习基础算法研发 分布式并行高维Logistic回归算法 支持百亿+训练样本,Online分片训练 支持十亿/百亿 连续+离散值特征的模型在线更新 图像领域Deep Learning模型研发 提取推荐图片关键特征,解决Cold Start精度问题 海量特征 算法演进 - 精准推荐算法演进规划 实时用户分群Online反馈优化算法 支持8亿用户多分类模型,协作推荐模型 支持实时模型更新,支持流式框架 腾讯分布式实时混合算法模型 Tencent Distributed Real-Time Hybrid Model 支持混合多类预测模型的增强学习算法 实时训练 混合预测 64 64 系统-实时推荐平台  TDBank • 日接入消息10000+亿 • 平均采集延迟1-2秒  TDProcess • 日计算量26000+亿 • 秒级延迟 精准推荐投放系统 TDBank 系统 TDProcess 流计算 实时推荐 引擎 • 秒级延迟  TDE • 存储量3T • 毫秒级延迟  实时推荐引擎 • 日请求200+亿 • 日推荐10000+亿 • 推荐延迟50ms以内 • 模型推送延迟分钟级 系统 TDEngine 分布式存储引擎 TDW 离线算法模型 Spark 在线实时模型 65 数据流式处理 模型实时更新 数据实时化实时推荐 10%+ 系统-全流程实时推荐价值 66 交流经验,共同进步! 67
还剩66页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 10 金币 [ 分享pdf获得金币 ] 1 人已下载

下载pdf

pdf贡献者

bluedesire

贡献于2017-04-11

下载需要 10 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf