数据可视化服务的系统能力与确定性

数据可视化服务的系统能力与确定性

编辑导读：当你说你要做一个产品，你需要的是建设一套系统能力。产品上线后，要持续地提供用户可以依赖的确定性，才能让人留恋和依赖。本文作者以数据可视化产品为例，分析其系统能力与确定性，一起来看看吧。

接着梁宁系列课程的思考，这节课讲的是产品的系统能力，在课后她留的作业是：

• 挑选一个你最熟悉的产品，说说它应该给用户提供怎样的确定性满足？这个产品做到了吗？如果没有，你觉得问题在哪？
• 持续的满足就会依赖，不确定的感觉就是伤害。你可以说说，你有没有确定性被伤害的时候？

在写作业之前，我们先学习一下梁宁在这节课的名词解释：

• 当你说你要做一个产品，你需要的是建设一套系统能力；
• 确定性很重要。人生如此不确定，所以当你看到有一个东西非常确定的时候，是让人留恋与依赖的。持续地提供用户可以依赖的确定性，这个是关键；

今天我们围绕着梁宁布置的作业，那就从“系统能力”、“确定性”两个方面来探讨一下数据可视化产品（更确切的说是“数据可视化服务”）。

一、如何进行数据服务？数据可视化产品的系统能力

其实在《数据可视化如何实现？》一文中就介绍过数据产品的系统，主要分为：数据存储层、数据计算层、数据展示层（如下图所示）。当时仅对系统的各个层级进行了名词解释，但作为一个整体的系统各个层级之间又是怎么工作来进行数据服务呢？

作为业务人员，数据可视化产品对他们最直观的服务就是数据的图表化展示，我们单从字面的意思来看，整个系统由两部分组成：用于业务场景的数据+将数据图表化的能力。

1. 用于业务场景的数据

在企业实际的工作场景中，数据分散在不同的存储中，比如日志数据、埋点数据、服务端数据等。但这些数据如果不经过加工，几乎不可能满足业务的需要，所以这里就要提到数据仓库。在BI工具中，可视化的数据来源于数据集（你可以理解为一张满足业务方一处分析需求，涵盖其所有指标、维度的数据表），而数据集就是直接引用或聚合计算数据仓库内的数据表。

再说一说数据仓库内的数据表，或许你也听过ods、dwd、dws、adm这些数仓层级结构，其实除了这些技术性的内容，数据仓库还有一点需要了解：其需要数据仓库工程师按照业务结构创建。而在企业的实际工作场景下，工程师创建数据仓库则依赖于数据产品整理的数据映射表（又称datamapping，即将某业务中指标[含指标定义]、维度[指标按照该字段聚合查看]关联的表格）通过系统已有的数据整理并建模（数据映射表里的指标可能需要通过多张表的字段，通过复杂的数学计算得到），完成一张或多张满足分析需求的数据表存储在数据仓库里。

2. 将数据图表化的能力

这里我们数据可视化产品来制作仪表盘的实现方式为例，这里能力有两部分：一部分是后端能力，另一部分是前端能力。体验过 Tableau 或者相似产品的朋友应该清楚创建仪表盘的整个过程：

通过该过程就可以明显的看出“数据连接”、“生成数据集”就是后端能力的一部分，数据连接，即通过 JDBC 等接口将数据库（含数据仓库）与我们的数据可视化产品连接起来，这是生成数据集的前提条件。生成数据集，即为了满足后面的可视化需要，通过数据查询语言（一般是 sql 语言）将连接的数据库内的一张或多张数据表聚合生成一张大宽表（里面包含分析需要的指标、维度，与数据产品之前整理的数据映射表字段一致，或者是其子集）。既然需要创建仪表盘，一定是业务经常需要的查看的，所以这里的数据一定要保证能够随着时间而进行周期性的更新，这里就得提到调度模块了。所谓调度，就是通过任务执行的定时设置，来实现数据集的定时更新。

“创建图表和仪表盘”就是前端能力了，即将后端传来的数据在图标上展示出来。一些大公司或者专业的可视化系统企业会自己开发自己的图表组件，如 Tableau 。而国内的百度（Echart）、阿里（AntV）也开源了自己的图表组件，前端同学可以此二次开发实现可视化展示。

二、如何更好的数据服务？数据可视化产品的确定性

1. 加载速率

数据产品与那些诸如 C 端、系统后台产品等在数据侧的最大不同点就是数据量的多少，有时候一张数据看板需要查询的数据就可能有上亿条数据。用户愿意等多久才不会躁动？数据查询执行时间是否超出公司系统的限制？这时候数据加载的时长就要受到用户、甚至系统的限制了。

为了提升加载速率，第一步通常是跟业务侧的同学沟通，把没有的分析砍掉来减少初始的数据量，如按日方式的细粒度查询方式能否改成按周/月的高汇总度的查询，来减少数据存储（不过，通过这种方式成功的可能性也不高）。第二步就得从数据侧入手了，如果非点查询而是汇总查询（举个例子，有10w用户，我需要随机展示单个用户的标签信息，这就是点查询。如果我只看这10w用户整体的标签信息分布，这就是汇总查询），那我们可以把数据存储在 clickhouse 里，在汇总查询下速率会更快。那如果是点查询，可以将 Spark 替换 MR 来操作数据集，这样查询效率更快但是内存消耗也越大，所以财大气粗的公司可以多买一些计算资源。第三步就要从看板设计侧入手了，比如在时间筛选器中限制日期的跨度选择，也可以将一张仪表盘的图表数量减少，来降低单张看板查询的时间（后面有机会再单独介绍一下单张看板的设计）。

2. 数据准确性

经常看一些数据报告的朋友应该清楚，比结论更重要的就是数据准确定，如果数据都不准确那得到的结论就一点价值都没了，数据可视化产品亦要遵守此规则。这里的数据准确性并非仅狭义里指的数据是否错误，还包括数据是否正常执行（如果因为数据无法生产，我昨日的数据对的不是昨日，而是前天的数据，那这也是一种错误）、数据是否出现异常（如出现空值等）、数据是否存在二义性（也可以称为数据孤岛，就是相同的指标在不同的业务部门数据源是否一致？规则是否一致？如果这些都不能保证，那不同的业务部门就被不能很好的交流了）。

数据错误、数据异常、数据执行中断可以通过调度系统里的监控模块进行监控，数据产品经理也可以给大数据开发工程师提供一些方案，如出现空数据、空值，或者相关指标与前一次执行的数据结果差异变化超过某个阈值，就会提醒相应的数仓同学来确认一下问题。针对一些画像标签数据，还可以采用数据注入的方式来验证一下画像标签是否准确。

数据二义性就需要数据仓库工程师统一管理公司所有业务线的数据，保证相同的指标其数据源、口径都是一致的。另一方面，这样做也可以有助于一些指标在公司范围内进行推广。

今天就说到这里，如果内容对你有帮助的话，欢迎分享或收藏。如果你有其他的观点欢迎在下方留言讨论~

#专栏作家#

兮兮，微信公众号：孤身旅人（ID：gushenlvren），人人都是产品经理专栏作家。关注人工智能、toB产品、大文娱等领域。

本文原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议