孙晗：BI系统建设的误区与要义

数据，已经植入我们的血脉。在互联网行业更甚。聚光灯下，除了财务数据就是运营数据。然而，这些数据仅能称的上是对企业或者团队现状的测度。距离指导运营，改善工作还存在着显著的差异。为了弥补这样的差异，同时能让团队成员在无任何技术背景的运用数据，通过成型的BI系统来展示数据成为了主流的手段。并非很幸运的是，一些BI（biz intelligence） 系统的建设却离前述目标越来越远，非但没有成为数据化运营、管理的驱动力，反而成为了负担。

一个合理、高效的BI体系要达成的目的是：

1. 让团队向数据人员提需求的频率极大降低，有更重要的事情等待DBA和数据分析团队；（今天不题这部分）

2. 团队每一位同学都能可以自助的完成数据的查询与质疑，便于时间序列上的对比，控制组的对比，不同维度下不同水平等的各种对比；所需查询的数据与维度要精简，易于操作；

3. 基于数据的“知识”共享。数据重要，但在没有转化成知识之前是没有价值的。诚如明天天气40度，如果不告诉你单位，或者没有这个测度下知识时，数据毫无价值，但若能将其转化成“天气很热”这样的知识，则有重大作用。进一步分享，则善之善也。

现状却是，很多BI系统偏离了这样的目标，遁入了一些看似有道理，但却如泥潭般，越陷越深的误区：

1. 重视报表，而不重视数据基础架构和ETL过程：以领导或客户的需求为导向，数据从体系变成了孤零零的数据。依旧以天气预报为例：如果BI中所展示的数据，是跟现在的天气预报以每天为粒度，不同地区的天气呈现，所有的数据以报表呈现，而不同对地区数据进行钻取，更不能选中一个地区，做出时间序列上的判断。这样，或许满足了一些人看一下现状的需求，但这种需求距离目的有多远？

2. 需求导向，而不是目标导向： 需求的提出方永远有无数的需求提出，而这些需求真的有用吗？不假判断，只会让BI系统中的数据越来越多，噪声也会愈演愈烈。久而久之，用户（大抵上就是需求提出的同学）会觉得用起来简直是受罪。如此有害无利的事情，始作俑者竟然是需求提出后，不做评审，做剖析目标而一味地满足需求。

3. 数据贪心心理，数据越多越好：数据在转化成知识前，一文不值。BI中充满了各种数据，各种报表。即便所有的数据都通过了评审，确定了价值，但大量的数据也会让查询过程成为杯具。不要说知识，恐怕连查询效率都不能满足。数据绝非越多越好，KPI也好，KDI也罢，那个K是关键的意思，不宜超过3个。BI中的数据就应该是比基尼，多了反而不好。

4. 无知识，仅数据：苍白的数据是不会撒谎，但你也不知道它在说什么，即使知道了，其他人呢？知识比数据有价值，智慧比知识有价值。别让BI成为最基础，也是最没用的工具。

窃以为，BI系统的要义在于：

1. 基础建设最重要，ETL过程、数据仓库、统计库缺一不可：

千里之行，始于足下。若想提高数据质量，让数据更加接近于知识，数据基础建设必不可少。通常情况下，BI系统宜基于一个轻量级的应用数据库（可以称之为统计库），该库是日志通过ETL后，存储入数据仓库进行计算的结果。用户通过BI系统查询提供数据同时，也可以根据自己的需求来对统计库进行临时SQL查询。可以说，数据仓库是基础，而ETL过程则是数据仓库维持质量的根本。只有完善了数据仓库的建设，才能高效的计算出统计库，进一步通过展示和临时查询。 三者缺一不可，万不可想当然的觉得直接日志计算就能得到结果，而忽视ETL过程，且不存入数据仓库，直接将结果存入统计库。如是的话，BI系统的质量将无法保障，日后的维护将非常可怕。

2. 产品经理去评审、控制需求，BI系统只提供最核心的数据：

80：20原理用在BI上并不适用，窃以为应该是95：5.即5%的数据代表了95%的价值。将需求控制好，只提供最核心的数据信息查询即可。越多的数据，越难以查询，越难以理解，更加难以维护。所以说，产品经理非常必要，需要他们来保障BI系统在使用时是顺畅的，而不是一场噩梦。

3. 人人完善的交互知识体系：

数据了解过去，预知未来。数据推翻或者验证假设。如是种种基于数据转化而成的知识才是BI系统应该带给团队的。诚如上面天气预报的例子，下不下雨和一堆卫星云图参数，谁更有价值？不言而喻。而在企业内部BI系统中，建立基于权限控制的人人可参与交互的知识分享机制是非常有必要的。比如数据的波动原因，这样的知识可能需要了解该业务的同学来分享。BI最终带给用户的一定是精炼的、基于数据的知识，而非一坨数据。

4. 数据可视化：

基于数据分享知识是重要的手段。数据可视化也是将数据转化成知识的重要方案。所谓一图胜千图，诚哉斯言～常用的视图也非常简单，无非是折线图、散点图和地理信息图。不要弄的复杂，但要谨记，视图比报表有用的多。