网易严选数据产品实践

背景

本文内容来自我在 2020 产品经理大会上《网易严选数据产品实践与方法论》分享的文字总结，由于篇幅原因，只包含了实践部分。数据产品是个新兴的产品分类，每个人眼里都有一个自己的数据产品，尽管在绝大部分人的概念中都是一堆报表。在过去的 3 年里，我们在用户需求的推动下一步步构建了网易严选数据产品体系，在构建过程中也有一些自己的思考。

网易严选数据产品实践主要分为以下 4 个阶段：“业务有数可看”、“数据质量保障”、“CXO 有处看数”、“场景化数据产品”。这 4 个阶段其实并没有明显的阶段之分，各阶段高度重叠，很多时候都同时在推进。接下来，我会从每个阶段面临的需求（问题），以及我们采用的产品解决方案来详述我们的实践之路。

一、业务有数可看

    2017 年，我刚来严选的时候，是严选数据产品起步的阶段，我们主要面临事多、人少、工具差的三大问题（应该也是各个数据部门长期面临的问题）。

“事多”主要是因为业务方多且当时业务数据需求有一波激增。现代商业（特别是在线业务）数据重要性不言而喻，业务需要通过数据来了解业务现状，发现业务的机会点和风险点。网易严选作为品牌电商，业务链路特别长，相较于纯互联网业务主要有产品运营部门，品牌电商还有很重的供应链、商品、客服等部门，记得当时光二级部门就有 30+，每个部门都有数据需求。当时还不断有电商互联网大厂的管理层加入严选，基于他们在原来公司比较先进的数据监控体系，提了大量数据需求，带来一波业务数据需求的激增。“人少”是部门初建的常规问题，当时我们数据开发 10 个不到（还有 2 个实习生数据产品经理），跟我们合作的数据分析师应该也就 10 个左右。当时使用的报表工具有 BIEE、Excel、自己开发的数据产品（报表集合），数据开发主要写 MR 加工数据，网易猛犸 + 网易有数尽管也已经引入，但是没有用正确的姿势大规模的使用起来。

面对“业务有数可看”的需求，我们通过构建数据仓库 + 严选有数（敏捷 BI 平台）的方案来解决。数据开发工程师在网易猛犸大数据开发平台使用 SQL 高效地进行数据开发构建数据仓库，数据分析师基于数据仓库在网易猛犸上使用 SQL 高效地进行分析集市的开发，再使用网易有数通过拖拽和配置的方式快速进行报表开发。经过数据分析师和数据开发工程师的辛勤工作，严选有数目前有 8w 的图表（加上其他数据产品一共 10w+），工作日 PV 6K+，周 UV 900+，对于一个事业部级别的 BI 平台，报表量和访问量应该算是非常不错了。那我们是如何做到这样的规模呢？首先应该感谢数据分析师和数据开发工程师的辛勤开发，开发了大量的报表和数据模型。因为本文主题是数据产品，接下来我主要从数据产品（严选有数）的角度展开讲下我们方案的优势。

严选有数是网易有数在严选的一个私有部署版本，在网易有数的版本上结合数仓做了性能优化，在开放协同上也做了一些功能扩展。

严选有数继承了网易有数简单易用的特性，只需要简单拖拽即可进行可视化分析，支持分析师快速制作数据报表。PPT 式的操作，让分析师能够快速进行报表布局、图层管理、图表样式优化，制作出业务人员友好的报表。

由于严选有数承载的报表数量大、大数据查询引擎的并发性能差、业务人员集中在开始上班时间（9 点多）并发查看报表，性能问题一直是影响业务人员高效阅览报表的主要问题。在性能方面，我们优化查询引擎（Imapla）的同时，通过数据产出驱动的缓存极大的提升了性能，支持业务人员快速阅览报表。最早，严选有数采用常规的被动缓存，图表首次访问落库查询（并缓存），后续访问查询缓存。业务人员上班后（9 点多）集中访问报表，大量图表首次访问进行落库查询，查询引擎瞬间就崩了。那时候几乎每天早上都被严选有数群里用户对 BI 平台崩了的抱怨，搞得焦头烂额，尽管暂时通过限流排队，解决崩的问题，但还是大量用户排队访问不了报表。我们的第一次改进，是把被动缓存改成定时主动缓存，因为报表数据绝大部分是 T+1 的，当日数据产出后不会变化，所以在每天 7 点数仓（及分析集市）产出后，集中进行主动缓存。改进后 70% 以上的图表访问都能命中缓存，秒级影响，极大地提升了用户的阅览体验。随着图表数量的快速增加，7 点 - 9 点多之间缓存的占比越来越低，平台的平均性能越来越差，用户图表平均访问时间也不断增长，每天早上严选有数群里各种用户抱怨又开始出现。我们再次改进了我们的缓存方案，把定时主动缓存改成了数据产出驱动的缓存。通过监听数仓表（及分析集市表）产出的消息，每次有表产出时遍历依赖该表的所有图表，如果相应的图表依赖的表都已经产出就开始进行缓存。这样我们就不用等到 7 点开始进行主动缓存，而是从 0 点开始只要图表依赖的表已经产出就开始进行主动缓存，这样从 0 到 9 点多，我们就能预先缓存大量图表。我们的图表缓存命中率达到 80% 以上（最近缺乏人力持续优化下跌到 70% 左右），命中缓存的图表都秒级响应。

在网易有数的基础上，我们还增加了一些开放协同的功能点。我们根据业务人员所属业务域，开放了尽量多的数据权限（能看到更多数据，才能产生更多分析的想法）。我们开发了维度/指标级搜索功能，让业务人员通过搜索维度/指标名称，快速从众多的报表中找到他想要的报表。我们在报表右上角提供了联系作者的快速入口，当业务人员阅览报表时，如有疑问可以快速唤起 popo 联系报表作者。通过一系列开放协同的产品功能，让业务人员可以看到更多的数据，可以更快速的找到想要的数据报表，可以便捷的联系报表作者（分析师），形成业务人员看更多数据 -> 产生更多数据需求 -> 联系分析师提进一步分析需求 -> 分析师开发更多分析报表的分析闭环。

二、数据质量保障

由于数据源多、数据链路长、数据指标口径复杂等原因，数据质量问题多、保障难度大。从用户的角度看数据质量主要存在晚、错、不一致的问题。

“晚”是指报表产出晚，实时数据延迟。由于报表数量大，对应的数据处理任务（数仓、数据集市）也很多，任务的出错和运行超时都可能导致数据产出晚。18 年时，严选有数用户群里，用户反映报表晚产出是常态。实时数据延迟主要会在大促时候出现，实时 UV、在线人数常常会延时。“错”主要指数据指标错误和用户标签错误。数据源里一条记录的丢失、一个字段的错误，数据处理任务链路上一个处理逻辑的错误、任务的延迟都可能导致数据指标、用户标签的错误。“不一致”主要指同一指标在不同的报表不一致，指标口径业务理解不一致。因为同一个指标会出现在不同的有数报表以及不同的数据产品中，经常会出现业务在不同的报表里看到指标不一致的情况。同一个指标名称在不同的上下文可能有多种口径，光毛利相关的口径就有 5+ 个，业务人员对同一个指标的口径理解可能会不一致。

数据质量保障是一个复杂而系统化的工程，展开讲可以写一本书，本文的主题是数据产品，下面主要从数据产品的角度讲下我们的数据质量保障的解决方案。针对数据质量保障需求，我们设计开发了一系列中台数据产品来保障数据的完整性、准确性和稳定性。

在刚开始构建数仓的时候，我们就形成了默认的规则，所有的业务数据库、业务日志都接入数仓，保障了在线化数据的完整性。尽管我们严选产技团队，几年来加班加点地不断研发系统，但是严选依然有很多业务没有线上化，进而数据不能通过业务系统、日志进入数仓。一方面是因为作为品牌电商，业务链路长，对应的业务线上化的需求也多，另一方面业务不断更精细化运营、不断探索新的业务方向（这样才互联网），进而不断产生新的业务线上化需求。针对尚未线上化的业务过程，我们开发了数据填报系统，业务通过 Excel 就可以快速把数据导入数仓。

数据产品经理结合业务需求通过指标管理系统先定义指标（口径、描述等），数据开发同学通过数仓设计系统根据指标定义进行数仓模型的设计，网易猛犸大数据开发平台根据数仓设计系统的模型设计来新建表。通过需求 -> 设计 -> 开发的在线化协同，来保证指标开发的一致性。指标地图，提供所有核心指标的定义，业务人员可以在指标地图查看指标定义，来解决指标口径理解问题。从数据源的角度看，业务 DB 的数据一方面有数据库 scheme 的校验，另一方面应用层也会进行校验（业务 DB 的数据是通过应用层代码写入的），出问题的概率很低。数据填报系统 Excel 导入的数据，因为在 Excel 里直接操作数据且操作非常灵活（约束少），很容易出现导入的数据有问题。我们首先控制数据填报系统的建表权限（只有数据开发可以建表），同时在系统里提供了大量的校验规则。业务人员需要导入数据到数仓时，先联系对应的数据开发提数据导入需求，数据开发根据需求设计表的结构，并配置对应的表级/字段级的校验规则。业务人员导入 Excel 的时候，相应的校验规则就能提前发现不符合规则的数据，并要求业务人员修改后重新导入。埋点由于端多、涉及的开发人员多、没有强 scheme 约束，也是数据源问题重灾区。埋点管理系统提供了埋点的定义，埋点流程管理和埋点测试。埋点开发人员使用埋点管理系统的单元测试能力，在埋点开发完成后就能进行单元测试，检查埋点数据是否符合埋点定义。测试人员可以使用埋点管理系统的回归测试能力，对核心埋点进行回归测试。通过埋点测试，可以保障埋点数据源的准确性。

由于数据任务量大（1W+ 任务节点）、大数据平台本身稳定性相对较差，任务稳定性保障一直是个难题。我们跟杭研共建任务运维中心，提供任务治理、智能监控报警、任务影响分析等功能保障数据稳定产出。通过任务运维中心，发现高耗时、耗资源风险任务，及时进行任务优化。智能监控报警，在任务出错、预测基线有破线风险时及时报警给数据开发值班人员，数据开发值班人员自己或组织对应的开发人员，及时进行问题的处理，保障任务的稳定（准时）产出。

三、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 也不另外，是我们最成功的数据产品。

四、场景化数据产品

在日常接到的用户数据需求中，我们发现的一些数据需求场景，相对于作为整个严选业务数据监控体系的一部分，作为一个垂直场景的数据解决方案会是一种更好的表达，比如大促、市场投放、用户体验等数据需求场景。大促是电商最重要的节日，要渲染大促氛围，要实时追踪大促的爆发效果，以进行运营动作的及时调整。市场投放要及时追踪市场拉新 KPI，及时评估渠道 ROI 来决策放量/停投，要测试/挑选拉新的新品等。互联网产品都是以用户为中心，网易更是极度重视用户体验，如何量化评估用户体验，如何从用户视角改进业务。

针对电商大促场景化数据需求，我们设计开发了电商数据大屏和客服数据大屏。在 17 年双 11 之前，我们开发了第一版严选电商双 11 数据大屏。跟业界双 11 数据大屏类似，数据大屏通过主动的实时数据呈现，让业务实时追踪大促爆发。通过炫酷的视觉样式和动画来渲染大促氛围。在电商双 11 大屏上线后，我们客服部门负责人找到我们，希望帮他们在下一次大促前做个客服数据大屏。由于没找到 mock 数据的客服数据大屏（下图的大促数据大屏数据是 mock 的），且客服数据大屏上数据太多打码难度太大，大家根据大促数据大屏自行脑补下 UI 吧。客服数据大屏包含实时的会话、排队、坐席数据，还有满意度、CPD、满意度报警、超 30 分钟会话等排行榜。我们发现电商数据大屏只在双 11、周年庆等极少数电商大促节日的正点时段使用，但是客服数据大屏在我们两地的客服部门长期放了好几块。这种现象让我想到在房产中介看到的月度榜单墙，客服大屏是一种更实时的可视化的劳动竞赛榜。

针对用户体验场景化需求，我们设计开发了谛听-舆情洞察中心。用户体验的难点在于难以定量的衡量和分析。除了复购、退货量这些间接的量化指标外，我们能收集到的用户直接的声音是用户评论、客服咨询等非结构化、定性的数据。用户在严选的消费链路（访问 -> 浏览 -> 咨询 -> ...）的每个节点，在严选内部都有对应的业务部门/业务环节为用户提供服务。我们根据业务环节建立舆情的分类体系，通过算法+规则将舆情分到对应分类中。将归属到具体分类的舆情数量求和，就完成了舆情从定性到定量的过程，舆情类别就是舆情分析的维度。因为我们建立了用户舆情 -> 舆情分类 -> 业务环节（部门）的映射关系，就可以通过分析对应业务部门所属分类的数据来评估对应部门的用户体验，进而可以将对应的负面舆情分发到对应的部门进行改进。质量相关的舆情我们早已完成线上评估 -> 分类 -> 分发 -> 改进的线上化闭环，当前我们也正在推进其他分类的线上化闭环。

针对市场拉新的场景化需求，我们设计开发了刑天 - 推广渠道管理系统。整体的思路和逻辑类似，这里就不展开叙述了。

总结 &后记

3 年多的不断建设，经过以上 4 个阶段，我们基本完成了严选数据产品体系，并伴随业务的精细化与创新进行相应的开发与迭代。从用户（严选业务人员）角度看，自上而下是场景化数据产品、敏捷 BI 平台和数据管理数据产品（又可以叫中台数据产品），分别应对业务场景化数据需求（CXO 看数也可以理解为一种场景化数据需求）、大规模的看数需求和高效高质量的数据管理需求。

在写文章的过程中，我发现文章信息密度还是很大，包含了很多数据产品和解决方案，难以在一篇文章中全部展开来讲。如果大家对数据产品感兴趣，想了解具体的产品或解决方案，请在评论区留言，我们会根据反馈发表对应的解决方案或数据产品的文章。当然我也会视本文的热度，决定后续是不是把方法论部分再写一篇文章发表出来。

作者简介

魏文庆，现任网易严选数据技术及产品部总监。2007 年浙江大学计算机硕士毕业后入职网易杭州研究院，从事前端开发，后历任技术主管、技术经理、技术总监。曾负责网易摄影、网易企业邮箱、易信公众号等产品开发，以及网易前端微专业课程开发。2015 年开始内部创业，孵化敏捷 BI 平台-网易有数，任网易有数总经理，负责产品研发和商业化。2017 年开始负责网易严选数据技术及产品部，从 0 到 1 搭建网易严选数据中台和数据产品体系。

头图：Unsplash

原文：网易严选数据产品实践

来源：严选技术产品团队 - 微信公众号

转载：著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。