1、Intro一点资讯业务概览 目前的访问量 日活7000万，人均每日阅读文章数26篇，视频日均播放量7亿 流量生态 独立主应用，小米浏览器，oppo浏览器，开放平台等等 内容生态 除了自媒体，还已接入知乎，汽车之家，快手，优酷等内容源Intro大数据下数据仓库的挑战 数据量大 业务逻辑复杂易变 数难取（如何快速开发？） 出数慢（如何提高流水线处理速度？） 算错数（如何保证自洽性和正确性？） 发现并解释数据异动Intro我们的一些实践 日志埋点管理：数据质量从源头抓起 数据表建设 专题表的建设 UDF 的使用 指标计算框架化：快而准的方案 指标监控：化繁为简划重点日志埋点管理原始日志：业务迅速发展
2、时，如何保证数据质量？首页视频小视频日志埋点管理阶段1：采用强schema日志message Event CLICK = 0;VIEW = 1;user_id: 1234,event : clickmessage SampleLog optional uint64 userId = 1;optional Event event = 2;userid: 1234,event : ClickSampleLog.Builder log = SampleLog.newBuilder();log.setUserId(1234);log.setEvent(Event.CLICK);return log.b
3、uild();user: id: 1234,action: click弱schema：如 JSON强schema：如 protobuf日志埋点管理阶段2：采用SDKSampleLog.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.setRefres
4、hId(rid);log.setPosition(pos);核心思想：LogService.send(log.build(); 把业务复杂性留给数据团队未使用SDK的埋点设备信息获取标准化挑战：LogAgent.clickMicroVideo(rid, pos, docID); 数据团队需要懂客户端开发使用SDK的埋点数据表建设典型数据仓库结构原始日志原始日志原始日志数据库维度表数据库数据库ETLETL专题ETL专题ETL专题ETL维度表明细事实明细事实维度表明细事实汇总事实汇总事实汇总事实数据表建设：专题ETL专题ETL原始日志原始日志原始日志数据库维度表数据库数据库ETLETL专题ETL专
5、题ETL专题ETL维度表明细事实明细事实维度表明细事实汇总事实汇总事实汇总事实数据表建设：专题ETLETL与专题ETL：分工ETL专题ETLETL后的日志上游职责原始日志数据清洗，去重，反作弊等大而全提取与专题相关的内容schema简明扼要数据分析师特点用户数仓工程师为主开发效率高（原有流水线加字段）较低（可能需建立新流水线）数据表建设：UDFUDF：适用于未稳定/存储开销大的对应关系UDF日志Hive接口Java接口数据流水线日志值域对应关系详表BI系统数据表建设：指标计算框架化数据集市的噩梦：自洽性数据库A数据库BETL维度表A明细事实维度表B维度表C汇总事实A汇总事实B汇总事实C数据表建
6、设：指标计算框架化数据集市的噩梦：自洽性数据库A数据库BETL维度表A明细事实维度表B维度表C汇总事实A汇总事实B汇总事实C出错几率大！测试成本高！数据表建设：指标计算框架化解决方案：用计算框架代替裸写SQL自定义维度表（用户提供）明细事实表（管理员维护）常用维度表（管理员维护） 采用高级语言编写配置文件（用户提供）计算框架规范化维度表和明细事实表join 的过程 计算框架根据维度表和配置文件确定事实表schema 用户无须做数据表 join 操作汇总事实数据表建设：指标计算框架化计算框架：应用select app_id, channel, client_version,count(*) as
7、 dau, sum(open_app) as open_app, sum(duration) as duration,sum(click_doc) as click_doc, sum(refresh) as refreshfrom(select app_id, user_id, channel, client_versionfrom dim_user_define_tablewhere day = 2018-12-06) user_defineinner join(select app_id, user_id, open_app, duration, click_doc, refreshfro
8、m fact_user_core_stats_detailwhere day = 2018-12-06) detailon user_define.app_id = detail.app_id and user_define.user_id = detail.user_idgroup by app_id, channel, client_version;传统裸写SQL的开发数据表建设：指标计算框架化计算框架：应用list.db=userlist.table=dim_user_define_tabletarget.db=usertaget.table=fact_user_define_stats
9、_dayperiod=dailyuser.properties 代码量大幅减少配置文件和执行脚本基本可重用export SPARK=/etc/spark/bin/spark-submitexport JAR_LOCATION=lazy-stats.jar$SPARK -class com.yidian.data.CoreRunner $JAR_LOCATION -action run -date 2018-12-06 -conf user.propertiesrun.sh采用计算框架的开发数据表建设：指标计算框架化提升流水线迭代速度：复杂指标的计算list.db=userlist.table=
10、dim_user_define_tabletarget.db=usertaget.table=fact_user_define_retentionretention.day=1,2,3,4,5,6,7,14,30user.retention.properties 即使面对较复杂的指标，代码依然很简洁export SPARK=/etc/spark/bin/spark-submitexport JAR_LOCATION=lazy-stats.jar 复杂指标还包括session分析$SPARK 转化漏斗分析等-class com.yidian.data.RetentionRunner $JAR_L
11、OCATION -action run -begin-date 2018-11-07 -end-date 2018-12-06 -last-version-date 2018-11-06 -conf user.retention.propertiesrun.retention.sh采用计算框架计算留存率指标监控：化繁为简划重点指标监控：必要性 指标越来越多 多维度多指标，单靠人力看不过来 以某内部分析系统为例，已经有20+个维度，20+个指标 解决方案 在业务系统中，重点指标加入报警指标监控：化繁为简划重点指标监控：多层监控 指标异动：原因？ 数仓研发迅速排查问题原始日志数据库维度表ETL 解决方案 每层都得有监控（实时日志，落盘原始日志，ETL，数据库等）专题ETL明细事实汇总事实指标监控：化繁为简划重点指标监控：异动归因 指标异动：原因？DAU 用户想要知道为何异动，如果不是流水线 bug 的话相关指标1 解决方案 整合过往追查的知识 关联指标有哪些？ 关联线上事件有哪些？总结一些感想 代码是规范流程的工具 人是靠不住的：能用代码生成的就避免手工开发 及时抽象通用的知识 注重数据/需求间的联系 及时重构迭代：需求的汇总总结 数仓架构师必须有大局意识 数据驱动：从被动出数到主动提供洞察谢谢！
