现在都说，是大数据时代，可是百度了，也不能给我一个通俗易懂的答案：到底什么是大数据，为什么会出现这种情况，怎么处理呢？

起初，数据量很少的时代，通过表格工具、mysql等关系型数据库（二维表数据库，数据逐行插入）就能够解决数据存储的问题。

但是，随着互联网的飞速发展，产品以及用户的激增，产生了海量的数据。

考虑到长足发展，公司会对产品、用户相关的原生数据、埋点数据等进行分析，传统的关系型数据库就无法满足需要，只能通过行式、分布式等数据库来存储这些数据（HBASE、hive等，能够实现集群化，及分配到多台主机上同时计算）。

当数据量大了，光秃秃的数字就难免让人产生困意，所以就出现了由数据向图表的转变，也就是我们说的数据可视化。

认识数据可视化

有了数据之后，对数据分析就是成了最关键的环节，我公司的分析师就曾对我说过一句话：数据分析主要对整体分析，而不执着于特殊的个体数据，这样才能够给产品提供宏观、有效的参考价值。

海量的数据让用户通过逐条查看是不可行的，图像化才是有效的解决途径。少量的数据可以通过表格工具生成图表、透视表的方式进行分析，但是大数据的分析就需要借助专门的可视化工具了，常见的可视化工具包括：Tableau、FineBI等。

大部分商用数据可视化工具的计算、图表展示虽然比较强大，但是却无法做到实时数据快速生成，数据也多为push（固定的范围）的方式，有时候数据还需要二次加工满足可视化产品的规则（商用产品多考虑通用性，无法适用于所有企业的数据规范）。

除此之外，现在很多图表插件的开源化（如：Echart、GoogleChart），以及行业内对数据安全性等的考虑，越来越多的公司也开始进行数据可视化的私有化部署。

数据可视化的类型

1、探索性可视化

探索性可视化需求一般集中在数据分析场景中的数据探索场景。在分析数据的时候需要对数据进行探索，最后才能得出结论。

但是为啥我们需要使用可视化的方式去探索数据呢？使用统计学的方式不就能得出结论了吗？其实并不是，最典型的案例就是安斯库姆四重奏。四组数据的平均数、方差以及相关系数都一样，你可能会觉得这些数据的分布应该也会很像。

但，当你使用数据可视化的方式去看这些数据时，你会发现他们的分布都不一样：

从流程来看，探索性可视化是这样的：

2、解释性可视化

解释性可视化需求一般集中在完成了数据探索，并且形成一定数据洞察后的 story-telling 场景。大家在网上看到的一些「一张图搞懂 XXX 」、「一张图了解 XXX」就属于解释性可视化。所以解释性可视化的流程是这样的：

国内的可视化步骤一般是这样的：

用户导入数据到产品，然后进行一些可视化的探索，或者直接将数据进行可视化的表达。

但是，基于我对目前的用户样本量的理解，我发现这种偏业务型的产品框架，并不太适合国内市场。因为这类产品面向的用户基本上是专业用户（数据分析师），而忽略了一个事实——大部分中国企业并没有设立专门的数据分析岗位。

有能力配备数据分析师的企业一般都是中大型企业以及互联网企业，他们付费能力可能比较强，但是也意味着用户量会较少。用户样本集中在以下两大块：

专业用户对应的是数据分析师，而半专业用户则对应的是类似财务、销售、HR 等，在业务上专业但数据分析上不专业的用户。在企业里面，其实半专业用户远大于专业用户。而这类用户的日常工作又一般集中在解释性可视化上面，比如年终总结、年度规划、每月汇报中都需要利用到数据可视化。所以这类用户的流程是这样的：

用户导入数据，无需太复杂的操作，即可直接生成图表。（为什么少了数据化探索呢？其实是因为在半专业用户中，又以中小型企业的用户为主，他们的业务相对单一，且交易、财务数据都不会太大。当然了还有一些是靠 erp 数据分析的，这里就不展开细谈了。）

然后根据图表，补充自己的洞见，就可以制成报告给到老板。

数据可视化的实现

数据可视化产品（系统）的结构框架主要分为三层：数据存储层、数据计算层、数据展示层。

1. 数据存储层

数据存储层在开头已经和大家说过了，在数据可视化产品（系统）中，既支持常规数据（MySQL、CSV等）可视化，也支持大数据（hive、HBASE等）的可视化，满足日常分析人员定性、定量的分析。

在考虑到数据安全的因素，数据存储还会与权限管理相结合，实现不同角色的人只能访问指定的数据。

2. 数据计算层

这里的计算不是平时所说的聚合、排序、分组等计算，解释之前我们先了解一下数据分析的工作流程吧：

• 产品/运营人员提出数据需求，如“APP一周留存 ”；
• 分析师确认需求后需要明确本次分析需要的字段及分析方式；
• 数仓人员提供整理后的表格（数据模型，多张表join后合成的中间表）；
• 分析师基于数据模型进行可视化分析。

数仓提供的数据模型主要分为增量、全量数据，不能直接对某个较长范围的数据进行分析，举个例子1月1日、1月2日两天都产生了数据，增量、全量的数据存储方式效果如下：

3. 数据展示层

可以给很多人看，数据分析师，业务人员，IT人员，还有管理层。

总结

我想未来的 BI 的产品不能将自己定位为「工具」，而是应该定位为「服务」。

这里的「服务」不是说从原来的买断式收费，转变为按年收服务费，这只是商业模式的转变。我理解的转变是要从产品理念上做文章，BI 产品不能只是一个工具，而应该是一个服务平台，连接企业内外部数据之外，并且更重要的是，需要连接企业内外部的业务。比如连接供应链的数据，连接财务数据，连接审批数据等等。

比如，对于一家生产鱼丸的企业，当系统发现制作鱼丸的原材料库存不足，但是又快到销售的旺季，是不是能提前预警，并且快速将此信息发到供应商那，直接订货。再比如，当一家企业的现金流并不是非常健康时，系统能否能推荐企业一些「财务顾问」服务，甚至「现金贷款」服务？

我相信总归是有办法的。