数据如何为业务赋能 一点资讯数据仓库实践

1 .20 18 中 国 大 数 一点资讯 数据与用户增长中心 黄雅斌 据 技 术 大 会 （ BD TC ） 

2 .Intro ） 个人简介 TC BD （ 2014-现在 会 数据仓库：数据治理，数据流水线，实时计算等 大 术 技 2012-2014 据 浏览器Push，推荐系统后端，垂搜索引 数 大 国 中 18 20 

3 .Intro ） 一点资讯业务概览 TC BD • 目前的访问量 （ • 日活7000万，人均每日阅读文章数26篇，视频日 会 均播放量7亿 大 术 • 流量生态 技 • 独立主应用，小米浏览器，oppo浏览器，开放 据 平台等等 数 • 内容生态 大 国 • 除了自媒体，还已接入知乎，汽车之家，快手， 中 优酷等内容源 18 20 

4 .Intro ） 大数据下数据仓库的挑战 TC BD • 数据量大 （ 会 • 业务逻辑复杂易变 大 术 技 • 数难取（如何快速开发？） 据 数 • 出数慢（如何提高流水线处理速度？） 大 • 算错数（如何保证自洽性和正确性？） 国 中 • 发现并解释数据异动 18 20 

5 .Intro ） 我们的一些实践 TC BD • 日志埋点管理：数据质量从源头抓起 （ • 数据表建设 会 大 • 专题表的建设 术 • UDF 的使用 技 • 指标计算框架化：快而准的方案 据 • 指标监控：化繁为简划重点 数 大 国 中 18 20 

6 .日志埋点管理 ） 原始日志：业务迅速发展时，如何保证数据质量？ TC BD （ 会 大 术 技 据 数 大 国 中 18 首页 视频 小视频 20 

7 .日志埋点管理 ） 阶段1：采用强schema日志 TC BD { message Event { （ "user_id": 1234, CLICK = 0; "event" : "click" VIEW = 1; 会 } } 大 message SampleLog { { optional uint64 userId = 1; 术 "userid": 1234, optional Event event = 2; "event" : "Click" } 技 } { 据 SampleLog.Builder log = SampleLog.newBuilder(); 数 "user": { log.setUserId(1234); "id": 1234 log.setEvent(Event.CLICK); 大 }, return log.build(); "action": "click" 国 } 中 18 弱schema：如 JSON 强schema：如 protobuf 20 

8 .日志埋点管理 ） 阶段2：采用SDK TC BD SampleLog.Builder log = SampleLog.newBuilder(); log.setUserId(1234); （ log.setEvent(Event.CLICK); log.setImei(imei); 会 log.setAndroidId(aid); 大 log.setClientIp(ip); log.setDocId(docId); 术 log.setTheme(Theme.MICRO_VIDEO); log.setRefreshId(rid); 核心思想： 技 log.setPosition(pos); LogService.send(log.build()); 据 • 把业务复杂性留给数据团队 未使用SDK的埋点 • 设备信息获取标准化 数 大 挑战： 国 LogAgent.clickMicroVideo(rid, pos, docID); • 数据团队需要懂客户端开发 中 使用SDK的埋点 18 20 

9 .数据表建设 ） 典型数据仓库结构 TC BD 原始日志 原始日志 原始日志 （ 数据库 数据库 数据库 会 ETL ETL 大 术 技 专题ETL 专题ETL 专题ETL 据 数 维度表 明细事实 明细事实 维度表 明细事实 维度表 大 国 汇总事实 汇总事实 汇总事实 中 18 20 

10 .数据表建设：专题ETL ） 专题ETL TC BD 原始日志 原始日志 原始日志 （ 数据库 数据库 数据库 会 ETL ETL 大 术 技 专题ETL 专题ETL 专题ETL 据 数 维度表 明细事实 明细事实 维度表 明细事实 维度表 大 国 汇总事实 汇总事实 汇总事实 中 18 20 

11 .数据表建设：专题ETL ） ETL与专题ETL：分工 TC BD ETL 专题ETL （ 上游 原始日志 ETL后的日志 会 职责 数据清洗，去重，反作弊等 提取与专题相关的内容 大 特点 大而全 schema简明扼要 术 用户 数仓工程师为主 数据分析师 技 开发效率 高（原有流水线加字段） 较低（可能需建立新流水线） 据 数 大 国 中 18 20 

12 .数据表建设：UDF ） UDF：适用于未稳定/存储开销大的对应关系 TC BD （ UDF 会 大 术 日志 Hive接口 Java接口 技 据 数 日志值域 数据流水线 大 国 中 对应关系详表 BI系统 18 20 

13 .数据表建设：指标计算框架化 ） 数据集市的噩梦：自洽性 TC BD （ 会 数据库A ETL 数据库B 大 术 技 维度表A 明细事实 维度表B 维度表C 据 数 大 汇总事实A 国 汇总事实B 中 汇总事实C 18 20 

14 .数据表建设：指标计算框架化 ） 数据集市的噩梦：自洽性 TC BD （ 会 数据库A ETL 数据库B 大 术 技 维度表A 明细事实 维度表B 维度表C 据 数 大 汇总事实A 国 汇总事实B 中 汇总事实C 18 20 出错几率大！测试成本高！ 

15 .数据表建设：指标计算框架化 ） 解决方案：用计算框架代替裸写SQL TC BD （ 自定义维度表 明细事实表 常用维度表 会 （用户提供） （管理员维护） （管理员维护） 大 术 • 采用高级语言编写 技 配置文件 计算框架 • 规范化维度表和明细事实表 （用户提供） 据 join 的过程 数 大 • 计算框架根据维度表和配置 汇总事实 国 文件确定事实表schema • 用户无须做数据表 join 操作 中 18 20 

16 .数据表建设：指标计算框架化 ） 计算框架：应用 TC BD select app_id, channel, client_version, （ count(*) as dau, sum(open_app) as open_app, sum(duration) as duration, sum(click_doc) as click_doc, sum(refresh) as refresh 会 from 大 (select app_id, user_id, channel, client_version from dim_user_define_table 术 where day = '2018-12-06') user_define 技 inner join 据 (select app_id, user_id, open_app, duration, click_doc, refresh from fact_user_core_stats_detail 数 where day = '2018-12-06') detail 大 on user_define.app_id = detail.app_id and user_define.user_id = detail.user_id group by app_id, channel, client_version 国 ; 中 18 传统裸写SQL的开发 20 

17 .数据表建设：指标计算框架化 ） 计算框架：应用 TC BD list.db=user （ list.table=dim_user_define_table target.db=user 会 taget.table=fact_user_define_stats_day period=daily 大 user.properties 术 • 代码量大幅减少 export SPARK=/etc/spark/bin/spark-submit • 配置文件和执行脚本基本可重用 技 export JAR_LOCATION=lazy-stats.jar ${SPARK} \ 据 --class com.yidian.data.CoreRunner \ 数 ${JAR_LOCATION} \ 大 --action run \ --date 2018-12-06 \ 国 --conf user.properties 中 run.sh 18 20 采用计算框架的开发 

18 .数据表建设：指标计算框架化 ） 提升流水线迭代速度：复杂指标的计算 TC BD list.db=user （ list.table=dim_user_define_table target.db=user 会 taget.table=fact_user_define_retention retention.day=1,2,3,4,5,6,7,14,30 大 user.retention.properties 术 • 即使面对较复杂的指标， export SPARK=/etc/spark/bin/spark-submit 代码依然很简洁 技 export JAR_LOCATION=lazy-stats.jar • 复杂指标还包括session分析 ${SPARK} \ 据 --class com.yidian.data.RetentionRunner \ 转化漏斗分析等 数 ${JAR_LOCATION} \ 大 --action run \ --begin-date 2018-11-07 \ 国 --end-date 2018-12-06 \ --last-version-date 2018-11-06 \ 中 --conf user.retention.properties run.retention.sh 18 20 采用计算框架计算留存率 

19 .指标监控：化繁为简划重点 ） 指标监控：必要性 TC BD • 指标越来越多 （ • 多维度多指标，单靠人力看不过来 会 • 以某内部分析系统为例，已经有 大 20+个维度，20+个指标 术 技 • 解决方案 据 • 在业务系统中，重点指标 数 加入报警 大 国 中 18 20 

20 .指标监控：化繁为简划重点 ） 指标监控：多层监控 TC BD • 指标异动：原因？ （ • 数仓研发迅速排查问题 原始日志 会 数据库 大 ETL 术 • 解决方案 技 • 每层都得有监控（实时 据 专题ETL 日志，落盘原始日志，ETL， 数 数据库等） 明细事实 维度表 大 国 汇总事实 中 18 20 

21 .指标监控：化繁为简划重点 ） 指标监控：异动归因 TC BD • 指标异动：原因？ （ DAU • 用户想要知道为何异动， 会 如果不是流水线 bug 的话 大 术 相关指标1 技 • 解决方案 • 整合过往追查的知识 据 数 • 关联指标有哪些？ 大 • 关联线上事件有哪些？ 国 中 18 20 

22 .总结 ） 一些感想 TC BD • 代码是规范流程的工具 （ • 人是靠不住的：能用代码生成的就避免手工开发 会 • 及时抽象通用的知识 大 术 • 注重数据/需求间的联系 技 • 及时重构迭代：需求的汇总总结 据 • 数仓架构师必须有大局意识 数 大 • 数据驱动：从被动出数到主动提供洞察 国 中 18 20 

23 .20 18 中 国 大 数 据 技 术 大 谢谢！ 会 （ BD TC ）