数据产品是个新兴的产品分类，每一个人眼里都有一个本身的数据产品，尽管在绝大部分人的概念中都是一堆报表。在过去的3年里，咱们在用户需求的推进下一步步构建了网易严选数据产品体系，下文分享咱们在构建过程当中本身的一些思考和总结。
前端
背景web
本文内容来自我在2020产品经理大会上《网易严选数据产品实践与方法论》分享的文字总结，因为篇幅缘由，只包含了实践部分。数据产品是个新兴的产品分类，每一个人眼里都有一个本身的数据产品，尽管在绝大部分人的概念中都是一堆报表。在过去的3年里，咱们在用户需求的推进下一步步构建了网易严选数据产品体系，在构建过程当中也有一些本身的思考。算法
网易严选数据产品实践主要分为如下4个阶段：“业务有数可看”、“数据质量保障”、“CXO有处看数”、“场景化数据产品”。这4个阶段其实并无明显的阶段之分，各阶段高度重叠，不少时候都同时在推动。接下来，我会从每一个阶段面临的需求(问题)，以及咱们采用的产品解决方案来详述咱们的实践之路。数据库
1、业务有数可看缓存
2017年，我刚来严选的时候，是严选数据产品起步的阶段，咱们主要面临事多、人少、工具差的三大问题(应该也是各个数据部门长期面临的问题)。安全
“事多”主要是由于业务方多且当时业务数据需求有一波激增。现代商业(特别是在线业务)数据重要性不言而喻，业务须要经过数据来了解业务现状，发现业务的机会点和风险点。网易严选做为品牌电商，业务链路特别长，相较于纯互联网业务主要有产品运营部门，品牌电商还有很重的供应链、商品、客服等部门，记得当时光二级部门就有30+，每一个部门都有数据需求。当时还不断有电商互联网大厂的管理层加入严选，基于他们在原来公司比较先进的数据监控体系，提了大量数据需求，带来一波业务数据需求的激增。“人少”是部门初建的常规问题，当时咱们数据开发10个不到(还有2个实习生数据产品经理)，跟咱们合做的数据分析师应该也就10个左右。当时使用的报表工具备BIEE、excel、本身开发的数据产品(报表集合)，数据开发主要写MR加工数据，网易猛犸+网易有数尽管也已经引入，可是没有用正确的姿式大规模的使用起来。性能优化
面对“业务有数可看”的需求，咱们经过构建数据仓库+严选有数(敏捷BI平台)的方案来解决。数据开发工程师在网易猛犸大数据开发平台使用SQL高效地进行数据开发构建数据仓库，数据分析师基于数据仓库在网易猛犸上使用SQL高效地进行分析集市的开发，再使用网易有数经过拖拽和配置的方式快速进行报表开发。通过数据分析师和数据开发工程师的辛勤工做，严选有数目前有8w的图表(加上其余数据产品一共10w+)，工做日PV 6K+，周UV900+，对于一个事业部级别的BI平台，报表量和访问量应该算是很是不错了。那咱们是如何作到这样的规模呢？首先应该感谢数据分析师和数据开发工程师的辛勤开发，开发了大量的报表和数据模型。由于本文主题是数据产品，接下来我主要从数据产品(严选有数)的角度展开讲下咱们方案的优点。微信
严选有数是网易有数在严选的一个私有部署版本，在网易有数的版本上结合数仓作了性能优化，在开放协同上也作了一些功能扩展。并发
严选有数继承了网易有数简单易用的特性，只须要简单拖拽便可进行可视化分析，支持分析师快速制做数据报表。PPT式的操做，让分析师可以快速进行报表布局、图层管理、图表样式优化，制做出业务人员友好的报表。app
因为严选有数承载的报表数量大、大数据查询引擎的并发性能差、业务人员集中在开始上班时间(9点多)并发查看报表，性能问题一直是影响业务人员高效阅览报表的主要问题。在性能方面，咱们优化查询引擎(Imapla)的同时，经过数据产出驱动的缓存极大的提高了性能，支持业务人员快速阅览报表。最先，严选有数采用常规的被动缓存，图表首次访问落库查询(并缓存)，后续访问查询缓存。业务人员上班后(9点多)集中访问报表，大量图表首次访问进行落库查询，查询引擎瞬间就崩了。那时候几乎天天早上都被严选有数群里用户对BI平台崩了的抱怨，搞得焦头烂额，尽管暂时经过限流排队，解决崩的问题，但仍是大量用户排队访问不了报表。咱们的第一次改进，是把被动缓存改为定时主动缓存，由于报表数据绝大部分是T+1的，当日数据产出后不会变化，因此在天天7点数仓(及分析集市)产出后，集中进行主动缓存。改进后70%以上的图表访问都能命中缓存，秒级影响，极大地提高了用户的阅览体验。随着图表数量的快速增长，7点-9点多之间缓存的占比愈来愈低，平台的平均性能愈来愈差，用户图表平均访问时间也不断增加，天天早上严选有数群里各类用户抱怨又开始出现。咱们再次改进了咱们的缓存方案，把定时主动缓存改为了数据产出驱动的缓存。经过监听数仓表(及分析集市表)产出的消息，每次有表产出时遍历依赖该表的全部图表，若是相应的图表依赖的表都已经产出就开始进行缓存。这样咱们就不用等到7点开始进行主动缓存，而是从0点开始只要图表依赖的表已经产出就开始进行主动缓存，这样从0到9点多，咱们就能预先缓存大量图表。咱们的图表缓存命中率达到80%以上(最近缺少人力持续优化下跌到70%左右)，命中缓存的图表都秒级响应。
在网易有数的基础上，咱们还增长了一些开放协同的功能点。咱们根据业务人员所属业务域，开放了尽可能多的数据权限(能看到更多数据，才能产生更多分析的想法)。咱们开发了维度/指标级搜索功能，让业务人员经过搜索维度/指标名称，快速从众多的报表中找到他想要的报表。咱们在报表右上角提供了联系做者的快速入口，当业务人员阅览报表时，若有疑问能够快速唤起popo联系报表做者。经过一系列开放协同的产品功能，让业务人员能够看到更多的数据，能够更快速的找到想要的数据报表，能够便捷的联系报表做者(分析师)，造成业务人员看更多数据->产生更多数据需求->联系分析师提进一步分析需求->分析师开发更多分析报表的分析闭环。
2、数据质量保障
因为数据源多、数据链路长、数据指标口径复杂等缘由，数据质量问题多、保障难度大。从用户的角度看数据质量主要存在晚、错、不一致的问题。
“晚”是指报表产出晚，实时数据延迟。因为报表数量大，对应的数据处理任务(数仓、数据集市)也不少，任务的出错和运行超时均可能致使数据产出晚。18年时，严选有数用户群里，用户反映报表晚产出是常态。实时数据延迟主要会在大促时候出现，实时UV、在线人数经常会延时。“错”主要指数据指标错误和用户标签错误。数据源里一条记录的丢失、一个字段的错误，数据处理任务链路上一个处理逻辑的错误、任务的延迟均可能致使数据指标、用户标签的错误。“不一致”主要指同一指标在不一样的报表不一致，指标口径业务理解不一致。由于同一个指标会出如今不一样的有数报表以及不一样的数据产品中，常常会出现业务在不一样的报表里看到指标不一致的状况。同一个指标名称在不一样的上下文可能有多种口径，光毛利相关的口径就有5+个，业务人员对同一个指标的口径理解可能会不一致。
数据质量保障是一个复杂而系统化的工程，展开讲能够写一本书，本文的主题是数据产品，下面主要从数据产品的角度讲下咱们的数据质量保障的解决方案。针对数据质量保障需求，咱们设计开发了一系列中台数据产品来保障数据的完整性、准确性和稳定性。
在刚开始构建数仓的时候，咱们就造成了默认的规则，全部的业务数据库、业务日志都接入数仓，保障了在线化数据的完整性。尽管咱们严选产技团队，几年来加班加点地不断研发系统，可是严选依然有不少业务没有线上化，进而数据不能经过业务系统、日志进入数仓。一方面是由于做为品牌电商，业务链路长，对应的业务线上化的需求也多，另外一方面业务不断更精细化运营、不断探索新的业务方向(这样才互联网)，进而不断产生新的业务线上化需求。针对还没有线上化的业务过程，咱们开发了数据填报系统，业务经过excel就能够快速把数据导入数仓。
数据产品经理结合业务需求经过指标管理系统先定义指标(口径、描述等)，数据开发同窗经过数仓设计系统根据指标定义进行数仓模型的设计，网易猛犸大数据开发平台根据数仓设计系统的模型设计来新建表。经过需求->设计->开发的在线化协同，来保证指标开发的一致性。指标地图，提供全部核心指标的定义，业务人员能够在指标地图查看指标定义，来解决指标口径理解问题。从数据源的角度看，业务DB的数据一方面有数据库scheme的校验，另外一方面应用层也会进行校验(业务DB的数据是经过应用层代码写入的)，出问题的几率很低。数据填报系统excel导入的数据，由于在excel里直接操做数据且操做很是灵活(约束少)，很容易出现导入的数据有问题。咱们首先控制数据填报系统的建表权限(只有数据开发能够建表)，同时在系统里提供了大量的校验规则。业务人员须要导入数据到数仓时，先联系对应的数据开发提数据导入需求，数据开发根据需求设计表的结构，并配置对应的表级/字段级的校验规则。业务人员导入excel的时候，相应的校验规则就能提早发现不符合规则的数据，并要求业务人员修改后从新导入。埋点因为端多、涉及的开发人员多、没有强scheme约束，也是数据源问题重灾区。埋点管理系统提供了埋点的定义，埋点流程管理和埋点测试。埋点开发人员使用埋点管理系统的单元测试能力，在埋点开发完成后就能进行单元测试，检查埋点数据是否符合埋点定义。测试人员可使用埋点管理系统的回归测试能力，对核心埋点进行回归测试。经过埋点测试，能够保障埋点数据源的准确性。
因为数据任务量大(1W+任务节点)、大数据平台自己稳定性相对较差，任务稳定性保障一直是个难题。咱们跟杭研共建任务运维中心，提供任务治理、智能监控报警、任务影响分析等功能保障数据稳定产出。经过任务运维中心，发现高耗时、耗资源风险任务，及时进行任务优化。智能监控报警，在任务出错、预测基线有破线风险时及时报警给数据开发值班人员，数据开发值班人员本身或组织对应的开发人员，及时进行问题的处理，保障任务的稳定(准时)产出。
3、CXO无处看数
看到“CXO无处看数”，你们可能以为很奇怪。上文不是说了，在有数上已经制做了大量报表，怎么CXO会无处看数。由于CXO有不同的场景，进而产生不同的需求。尽管BI平台（严选有数）上有大量报表，CXO依然面临“难找”、“不能随时看”的问题。CXO有整个BI平台的权限，进入平台后面对海量的报表，难以快速找到想看的数据(CXO的时间又不多)。CXO工做特性须要随时随地查看数据。CXO事情特别多，电商CXO尤甚，品牌电商CXO更甚，CXO不是在开会/出差，就是在开会/出差的路上(连我本身如今也差很少)。
针对CXO的看数场景和需求(痛点)，咱们设计开发了VIPApp-移动数据工做台。VIPApp为CXO提供了随时随地监控KPI以及所见既所得商品、类目、流量数据。下图中是VIPApp很早期版本的一些UI，由于数据安全的缘由数据部分打了码。早期VIPApp主要为CXO及少数中高层服务，如今已经逐渐发展成面向严选全员的移动数据工做台了，承载了整个严选KPI体系监控及各业务运营的数据监控体系。VIPApp从技术角度看是以严选app为容器，内嵌了一个wap(数据产品)网站；从用户角度看依托严选app提供了所见既所得的交互入口。用户能够长按类目唤起类目数据页，长按商品唤起商品数据页，长按流量位置唤起流量数据页。移动化让用户随时随地能够查看数据，所见既所得的入口让用户能够快速找到对应的数据模块。好的用户体验必定会带来高频访问的回报(每一个产品人都应该信仰)，VIPApp也不另外，是咱们最成功的数据产品。
4、场景化数据产品
在平常接到的用户数据需求中，咱们发现的一些数据需求场景，相对于做为整个严选业务数据监控体系的一部分，做为一个垂直场景的数据解决方案会是一种更好的表达，好比大促、市场投放、用户体验等数据需求场景。大促是电商最重要的节日，要渲染大促氛围，要实时追踪大促的爆发效果，以进行运营动做的及时调整。市场投放要及时追踪市场拉新KPI，及时评估渠道ROI来决策放量/停投，要测试/挑选拉新的新品等。互联网产品都是以用户为中心，网易更是极度重视用户体验，如何量化评估用户体验，如何从用户视角改进业务。
针对电商大促场景化数据需求，咱们设计开发了电商数据大屏和客服数据大屏。在17年双11以前，咱们开发了初版严选电商双11数据大屏。跟业界双11数据大屏相似，数据大屏经过主动的实时数据呈现，让业务实时追踪大促爆发。经过炫酷的视觉样式和动画来渲染大促氛围。在电商双11大屏上线后，咱们客服部门负责人找到咱们，但愿帮他们在下一次大促前作个客服数据大屏。因为没找到mock数据的客服数据大屏(下图的大促数据大屏数据是mock的)，且客服数据大屏上数据太多打码难度太大，你们根据大促数据大屏自行脑补下UI吧。客服数据大屏包含实时的会话、排队、坐席数据，还有满意度、CPD、满意度报警、超30分钟会话等排行榜。咱们发现电商数据大屏只在双十一、周年庆等极少数电商大促节日的正点时段使用，可是客服数据大屏在咱们两地的客服部门长期放了好几块。这种现象让我想到在房产中介看到的月度榜单墙，客服大屏是一种更实时的可视化的劳动竞赛榜。
针对用户体验场景化需求，咱们设计开发了谛听-舆情洞察中心。用户体验的难点在于难以定量的衡量和分析。除了复购、退货量这些间接的量化指标外，咱们能收集到的用户直接的声音是用户评论、客服咨询等非结构化、定性的数据。用户在严选的消费链路(访问->浏览->咨询->...)的每一个节点，在严选内部都有对应的业务部门/业务环节为用户提供服务。咱们根据业务环节创建舆情的分类体系，经过算法+规则将舆情分到对应分类中。将归属到具体分类的舆情数量求和，就完成了舆情从定性到定量的过程，舆情类别就是舆情分析的维度。由于咱们创建了用户舆情->舆情分类->业务环节(部门)的映射关系，就能够经过分析对应业务部门所属分类的数据来评估对应部门的用户体验，进而能够将对应的负面舆情分发到对应的部门进行改进。质量相关的舆情咱们早已完成线上评估->分类->分发->改进的线上化闭环，当前咱们也正在推动其余分类的线上化闭环。
针对市场拉新的场景化需求，咱们设计开发了刑天-推广渠道管理系统。总体的思路和逻辑相似，这里就不展开叙述了。
总结&后记
3年多的不断建设，通过以上4个阶段，咱们基本完成了严选数据产品体系，并伴随业务的精细化与创新进行相应的开发与迭代。从用户(严选业务人员)角度看，自上而下是场景化数据产品、敏捷BI平台和数据管理数据产品(又能够叫中台数据产品)，分别应对业务场景化数据需求(CXO看数也能够理解为一种场景化数据需求)、大规模的看数需求和高效高质量的数据管理需求。
在写文章的过程当中，我发现文章信息密度仍是很大，包含了不少数据产品和解决方案，难以在一篇文章中所有展开来说。若是你们对数据产品感兴趣，想了解具体的产品或解决方案，请在评论区留言，咱们会根据反馈发表对应的解决方案或数据产品的文章。固然我也会视本文的热度，决定后续是否是把方法论部分再写一篇文章发表出来。
做者简介
魏文庆，现任网易严选数据技术及产品部总监。2007年浙江大学计算机硕士毕业后入职网易杭州研究院，从事前端开发，后历任技术主管、技术经理、技术总监。曾负责网易摄影、网易企业邮箱、易信公众号等产品开发，以及网易前端微专业课程开发。2015年开始内部创业，孵化敏捷BI平台-网易有数，任网易有数总经理，负责产品研发和商业化。2017年开始负责网易严选数据技术及产品部，从0到1搭建网易严选数据中台和数据产品体系。
本文由做者受权严选技术团队发布
本文分享自微信公众号 - 严选技术产品团队（YanxuanTechProd）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。