腾讯营销数据平台.pptx

1、腾讯广告数据系统关于我关于我11年加入腾讯关注分布式存储和计算系统现负责腾讯广告数据系统腾讯广告简介腾讯广告简介国内国内 流量最大流量最大（日均约（日均约500亿亿PV，百亿展现），百亿展现）场景最丰富场景最丰富（微信（微信, QQ, 视频视频, 新闻等几十种产品）新闻等几十种产品）覆盖人群最广泛覆盖人群最广泛（超过（超过10亿受众）亿受众）的互联网广告平台的互联网广告平台腾讯新闻、腾讯新闻、快报广告快报广告微信广告微信广告QQ广告广告腾讯视频广告腾讯视频广告联盟广告联盟广告应用宝广告应用宝广告国内移动国内移动咨海量优质APP月活跃用户5亿广告，也可以广告，也可以是生活的一部是生活的一部分分最

2、懂年轻人最懂年轻人的营销平台的营销平台国内移动视国内移动视频第一入口频第一入口用户覆盖率第用户覆盖率第一的安卓应用一的安卓应用商店商店询top入口入口广告系统架构用户画像API 投放端实验系统初选广告索引定向特征播放系统精选质量预估广告服务审核数据带来价值： 模型训练 策略机制收益管理 广告排序用户体验 流量规则PCTRPCVRLITECTRLITECVR投放系统业务库 报表和BI分析 DMP数据管理统计信息预算控制广告主一方数据DMPTDC数效果归因统计框架特征工程据系统出价调节数据安全请求 触发日志关联用户画像报表曝光 点击广告系统日志广告画像1. 数据分析2. 特征工程3. 数据安全1.

3、 数据分析2. 特征工程3. 数据安全数据分析任务的分类分类预先聚合计算在线实时计算OLAP优点查询速度快 灵活性高灵活性不够 查询时计算量大缺点DMPBI应用场景报表Pushmail统计特征预算控制出价调节多维透视分析SEAGULL基于spark的聚合计算平台(1)原始数据原始数据原始数据中间表原始数据Hive/pig统计结果SparkStorm mapreduce实时计算 离线计算streaming实时+准确统一配置统计结果统一配置统计结果统计结果 业务特点 实现方案 一份输入，多份输出 数据量大，每天100多T 实时性，准确性 统一数据流 配置化计算逻辑 一套代码解决按key的聚合问题S

4、EAGULL基于spark的聚合计算平台(2)日志切分1分钟聚合HDFS.计算入库.1小时聚合1天聚合.HDFS.N天回归HBase 优化： 准确： spark内存做cache，命中率96% 输入输出都是hdfs 先计算diff再写hbase，写入量减少93% 分钟级调度，时间维度上资源均匀消耗 目录结构做checkpoint 实时： 不采用spark window，避免输出任务batch之间 在spark中执行分钟级别的mapreduce 常驻进程，分层调度依赖，在集群抖动时快速恢复 利用hbase version，避免新数据被老数据覆盖调度优化(1) 推测执行，避免struggle 会有很

5、多的推测备份任务被杀掉调度优化(2) 优化思路 利用streaming周期任务的特点，动态评估每个executor 的吞吐量 能力强的节点分配大任务，能力弱的节点分配小任务 实现 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)12

6、34选择最适合executor 3执行的任务Executor2(1MB/s)Task(128M)Task(128M)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)调度优化(3) 性能提升 a) 推测任务减少 86.57%b) 计算延迟降低 20.96% c) 少用 1/1

7、0 资源预先聚合计算在线实时计算要解决的问题 - 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(SELE

8、CT user_id, COUNT(*) 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. 嵌套结构：pro

9、to buffer，正排存储类似于dremel/parquet，没法倒排Message pageview optional UserProfile user;repeated Position pos repeated Impression imps optional Advertisement ad;repeated Click clicks optional BillInfo bill;索引文件设计(1)索引数据结构：检索查询流程：全局信息列值字典倒排数据正排数据列值ID对应的文档ID列式存储的压缩数据每一列(Column)的值编码为列值(Term ) ID列表查询条 Where age=

10、20 and age=20 and age30GROUP BY gender;件命中列 找到age满足条件的列值ID值倒排拉 拉出列值对应的倒排拉链链集合运 根据逻辑对结果进行集合运算算索引文件设计(2) 倒排 正排 文档ID在文件内编码，减少值域范围 稀疏数据保存array，稠密数据保存bitmap 采用roaring bitmap进行自适配 实现高效的bitmap与array之间交并差的计算减少磁盘IO访问-列存储最大程度节省磁盘空间-编码压缩通过采样进行比较，自动确定最优编码方案对于不同 定长类型编码：定长数组编码、列值个数索引编码、定长列表编码、变长列表编码、run length en

11、cording的数据特String类型编码：单string长度索引编码、多string长度索引编码、单string列表编码、多string列表编码征，适用简单字典编码：适用列值重复较多的string类型于不同的 Huffman字典编码：列值分布不均匀情况下对简单字典编码的优化编码算法二进制String编码：较特殊的二进制数据类型嵌套结构列式存储格式dragon(1) Pivot需要支持直接查原始日志proto buffer格式 嵌套结构，无法建倒排 针对稀疏的proto buffer数据进行优化 谷歌 dremel vs 开源parquet vs 自研 dragon文件大小（单位：MB）写入时

12、间（单位：秒）数据读取耗时（单位：秒）80060040020007005004003002001000383864206.76.76.7Dragonparquetrecordio2892544.52662712111613.41531382.11.60.5读三列0.1请求日志 曝光日志请求日志曝光日志读一列读十列嵌套结构列式存储格式dragon(2) 存储：同列数据连续存储，压缩效率高 存储：不保存空节点的rlevel和dlevel 写：暂时为空的节点cache rlevel dlevel 写：Flush cache的时候只flush到下层节点 读：读取数据只需读取需要的列，节省磁盘IO 读：

13、热点hash map优化为查表 读：重复计算前置 读：自适应分级缓存，栈上小内存分配PIVOT-实时多维透视分析引擎元数据管理hbase新数据捡测索引构建数据拉取数据清理配置表版本表在线检索离线计算 任务管理路由表Tdbank检索节点检索节点检索节点聚合节点Sparkstreaming增量索引全量索引增量文件全量文件聚合节点聚合节点mapreduce 业务特点 建索引 列存储 万亿条数据 秒级响应 利用SSD进行检索，而不是内存 利用HADOOP集群构建索引遍历正排数据实现分组 Group by age, gender, city 如果直接排序： 每次比较age_gender_city，而前缀

14、基本一致，浪费计算量 Map太大，log(N)的插入操作也很耗时 按照列的顺序分层计算 先group by age，然后在每个age里面group by gender，以此类推 每次查找和插入都只操作一个很小的map基于倒排数据实现分组 基于正排数据，计算量跟命中的doc数量成正比 基于倒排的roaring bitmap，进行集合求交计算量有上限，在命中doc很多时会更快 仅适用于group分组数量比较小的情况，否则需要求交的次数太多倒排分层Group By集合求交1. 数据分析2. 特征工程3. 数据安全广告业务多模型优化用户 + Context百万级广告百级广告个级广告初选精选广告展示广告

15、库其他候选广告列表广告特征初选模型: 相似人群扩展，自动定向，动态创意，商品推荐，litectr, litecvr, 精选模型: pctr, pcvr, 负反馈,模型优化不仅仅只是模型训练Data ValidationMonitoringConfigurationData CollectionMLCodeAnalysis ToolsServingInfrastructureProcess ManagementToolsMachine ResourceManagementFeature Extraction需求1: 从业务角度如何提升特征工作迭代效率？ 模型方特征工作迭代内容模型方特征工作迭代内

16、容 已经有哪些特征？ (有哪些用户特征、统计特征、广告特征等等) 特征数据质量如何？ (数据分布是否符合预期？是否存在脏数据？） 有没有其他模型尝试过？（离线调研和在线调研效果如何） 快速地尝试新的特征（走通特征生产、调研和在线应用流程） 模型方如何看待特征工作？模型方如何看待特征工作？ 只关注如何使用特征，即简单配置要什么特征就可以完成特征调研、上线等工作 不关注特征数据如何流通、存储、访问计算 计算逻辑（如特征Join)能否尽量少写代码，简单配置复用公共组件特征生产特征存储特征调研特征上线需求2: 从系统角度如何提高特征工作资源利用率？ 多模型优化在特征工作上高度重叠多模型优化在特征工作上

17、高度重叠 都需要进行特征生产、存储、特征补录并进行离线调研、离线特征抽取生成训练样本集、在线特征抽取生成待预测样本 存储和计算资源上能否共享使用并优化，提升资源利用率？特征补录生成补录训练样本集特征抽取生成训练样本集特征抽取生成待预测样本模型模型1特征生产特征存储特征调研模型训练模型预测特征补录生成补录训练样本集特征抽取生成训练样本集特征抽取生成待预测样本模型模型M特征生产特征存储特征调研模型训练模型预测需求3：如何避免训练和预测的偏差 训练和预测的偏差 指的是训练阶段和预测阶段的效果差异（如线下AUC和在线AUC相差很大) 引起训练和预测的偏差的可能原因 训练和预测数据处理逻辑（如特征抽取等

18、）是否存在不同 由于训练和预测时间存在差异，数据上是否有变化特征工程平台1.数据分析2.特征工程3.数据安全特征数据仓库特征计算平台Rocksflow数据校验用户画像特征拼接特征提取、过滤、清洗 模型多 数据量大 节省机器成本 提升特征调研效率 共享特征数据 避免训练和预测的偏差元数据管理广告画像任务管理任务补录日志数据一方数据统计特征样本标记结果缓存列式存储版本管理在线数据服务广告检索模型服务离线训练训练样本DataHub一致性校验前文统计特征生产框架-CF2 CF2 Context Feature Computation Framework 支持按照配置的进行统计的通用系统框架 使用者只需

19、要配置如下参数即可完成统计1. 源数据输入，如HDFS路径2. Interval和Window配置信息3. 聚合逻辑，类似于Spark UDAF函数4. 统计数据输出，如HDFS路径特征举例特征举例 (用户为主体用户为主体)( )特征举例特征举例 非用户为主体非用户为主体每小时统计最近3小时、每天统计最近14天的曝光量、点击量每天统计用户在App激活场景下最近14天的点击量、转化量每天统计用户在H5下单场景下最近14天的点击量、转化量每小时统计用户最近7天的历史转化广告ID列表、商品ID列表每天统计每个商品ID最近7天或者14天的曝光数和点击数每小时统计每个广告ID最近14天的曝光量、点击量C

20、F2存储HBase 表结构设计interval_table_1_MINcf:dcf:fT60mrowkeyk1T1mT30mT60m.W30mW60mT1mT30m.W30mW60minterval_table_1_HOURcf:dcf:f.rowkeyk1T1hT2hT24h.W6hW24hW72hT1h T2hT24hW6hW24hW72hinterval_table_1_DAYcf:dcf:frowkeyk1T1dT2d.W14dT1dT2d.W14dCF2计算之读取输入数据 读取输入数据读取输入数据 将数据按最细时间粒度写入对应的Interval Tableinterval_table

21、_1_MINcf:dT60mcf:fT60mrowkeyT1mT30m.W30mW60mT1mT30m.W30mW60mk1k2k3HDFST1mHDFSTHDFST30mHDFSTHDFST60mCF2计算之Interval统计聚合interval_table_1_MINcf:dcf:frowkeyT1mT60mT120m.W60mT1mT60mT120m.W60mW72hW14dk1interval_table_1_HOURcf:d.cf:f.rowkeyk1T1hT2hT24hW6hW24hW72hT1h T2hT24hW6hW24hinterval_table_1_DAYcf:dcf:

22、frowkeyk1T1dT2d.W14dT1dT2d.CF2计算之Window统计聚合 滑动窗口进行计算滑动窗口进行计算 = + 1interval_table_1_MINcf:dcf:frowkeyk1T30mT60mT90mW30mW60mT30mT60mT90mW30mT90mW60mT90m统计结果输出广告特征生产框架-TerraStore 广告、创意素材广告、创意素材 广告数据分层级，Advertiser - Campaign - AdGroup - Ad - AdCreative AdGroup层级里存储有扣费类型、计费类型、优化目标类型、定向等数据 AdCreative层级有广告

23、标题、描述、落地页、图片素材等数据 特征应用: 从广告标题描述提取分类信息、爬取落地页提取核心关键词、从图片素材上提取美感特征等等 广告特征生产目标 存储所有广告（包括当前在线和非在线的广告）的特征数据 广告、创意素材变更，快速地在模型上生效 记录版本变更，避免Training-Serving Skew问题TerraStore系统实现 实现原理实现原理Creative_Multiversion表的一个Region 使用HBase Observer Coprocessor和MVCC生成流水表，确保数据和流IDCreativeID1ValueFA2, A2FC2, C2FC3, C3水数据一致性b

24、bbFB6+B6FB5+B5FB4+B423 Manager模块读取各个HBase Region里的流水数据发布上线FB6, B6 Manager将变更前后的数据有选择地发送给特征逻辑处理方 特征生产完写回多版本表，并通过多版本流水数据实时发布上线MFB6, B6数据流水FB6, B6b创意URL变更B6, B5b, B6创意变更数据流IDaCreativeA8ID1ValueA2, A1C2, C1C3, C2ManagerbcB62B6, B5B6, B5Worker1URLC53Worker2Worker3URLKB6, B5Image数据流水Creative表的一个Region特征仓库

25、存储系统表T版本V8的数据F1V8V8F2V8V8F3V8V8FMV8V8U1U2HBase存储，多版本(N个)用在实时的训练样本集生成UKV8V8V8V8Dragon列式存储，多版本用在特征补录和数据质量验证分析F1F2F3FMV6F1V1F2V1F3V1FMV1U1U2V6V6V6U1F1F2F3FM版本V1版本V2在线kv存储，最新版本用在在线预测UUU1V2V2V2V2UKF1V8V8F2V8V8F3V8V8FMF1V8V8F2V8V8F3V8V8FMV8V8U1U2V8V8U1U2UU1V8V8V8V8版本V8UKV8V8V8V8UKV8V8V8V8UKV8V8V8V8特征仓库存储系

26、统之多版本说明 解决特征数据解决特征数据Serving阶段和阶段和Training阶段的一致率，避免阶段的一致率，避免Training-Serving Skew 表记录批量更新，Serving阶段记录SeqNo，Training阶段检索对应版本 时间序列数据更新，Serving阶段记录start_time, end_time，Training阶段检索指定时间区间的数据SeqNo=2SeqNo=3SeqNo=1T1: V5T2: V3T3: V8T2: V4T4: V2TableT1: V6SeqNoTableVersionVersionTableT1VersionT1T2V5V3T1V5V6T

27、2T3T4V4V8V2T2T3T4V4V8V2start_time, end_timeTimestampstart_time, end_time特征计算之调研环境下特征补录 特征补录特征补录 新加了一个特征集，验证下模型加入这个新特征的效果 每个生产环境下跑的模型都会存储之前的训练样本集 将之前的训练样本集新的特征集，再生成新的训练样本集。需要保证不要出现时间泄漏问题timestampIDF1F2FmtimestampIDFrFsFzV1V1V22V1V1V2V2258556训练样本集待补录特征集timestampIDF1F2FmFrFzV1V1V2255补录后样本集特征补录优化 主要优化措施

28、主要优化措施 训练数据集和特征数据集，都使用列式存储，减少读取数据流(如待补录特征集里只使用Fr和Fs两列） 训练数据集只需要读取两列，进行broadcast join提升补录效率 将待补录的样本集单独生成列式文件，之前的训练样本集不变。读取的时候使用MultiInputFormat从两个列式文件里同时读取timestampID2F1F2FmtimestampID2FrFsFzV1V1V2V1V1V2V25855训练样本集6待补录特征集timestampID2FrFsV1V25补录后样本集1. 数据分析2. 特征工程3. 数据安全数据安全管理安全传输协议脱敏发布鉴权隐私集合求交数据水印系统提供

29、的安全机制认证授权审计差分隐私权限最小化原则 敏感数据生命周期管理 数据分级管理数据脱敏 加密存储 密钥管理服务 机器访问控制系统自身安全敏感端口访问控制内网隔离策略内部认证管理备份与恢复IP白名单审计与合规隐私集合求交 问题：在双方数据保密的情况下计算部分结果 解决方案：利用两个可交换的加密函数 f(g(x)=g(f(x) 应用场景： 曝光归因 第三方监测曝光人群 购买人群 广告效果衡量差分隐私 提供聚合查询结果时，客户可能通过构造相差很小的数据集，通过差分的方式获取单条数据 给结果附加少量扰动，防止差分攻击 限制访问的数据集，限制访问频率，控制差分预算1. 数据分析2. 特征工程3. 数据安全谢谢！