蒋步星：自助报表难自助，敏捷BI欠敏捷

Posted 2020-09-04

       这里有点标题党，为了对仗把题目写成这样。其实自助报表和敏捷BI深究起来是一回事，都是希望业务人员自己能完成数据分析和呈现，叫得通俗些是自助报表，洋气一些就是敏捷BI了。

　　经营分析软件中大都会提供丰富的固定报表，能够处理较复杂的计算需求，但毕竟死板。业务经营中常常会有临时性的数据分析需求，传统手段一般提交给技术部门去实现，这样显然周期长效率低，有时获得结果时已经失去意义了。如果能让业务人员自己做分析和呈现，那无疑会极大地提高决策效率，这就是敏捷BI产品主打的目标。

问题是，这个目标能达到吗？

       如果用于分析的基础数据事先已经准备好，然后使用这些数据制作交互式的报表或图形并组合出管理看板（Dashboard），目前许多敏捷BI产品的功能都还不错，界面也比较友好，业务人员一般都能够操作起来，这也是敏捷BI在演示阶段能吸引住用户的主要原因。不过，在已经获取了相关数据时，敏捷BI能做的许多事用Excel也能做得很好（美观程度要差一些），在很多场合下再专门上一套敏捷BI系统的必要性并不大，或者说Excel就是足够好用的敏捷BI产品了。

　　而且，大多数时候，数据并没有准备好，获取数据本身就是灵活分析中最关键的步骤。它是后续动作的基础，也是几乎所有敏捷BI产品（如果Excel也算的话也可包括在内）都不够“敏捷”的环节。

       关系数据库是当前数据存储的事实标准，特别是有分析需求的带业务含义的结构化数据。从数据库取获取数据要用SQL语句，实际上发明SQL的初衷就是想让业务人员能用来查询数据，所以它很象英语。确实，对于单个表的常规查询（过滤、计算列、分组汇总）问题并不大，业务人员即使不会写，也容易做个可视化的界面辅助“编辑”出来。

　　但是，有意义的查询经常是多表关联的，比如取出存储余额10万以上的本地储户，获得北京打到上海的电话记录，按月统计合同额、回款额、发票额，....。关系代数对数据表关联的处理方式是业务人员很难理解的，表间关系是个网状结构，要指定关联字段，还可能涉及到自关联递归关联等复杂情况。关联表较多或层级较深时连技术人员都很难掌握，三五个关联表的数据关系就足以使业务人晕掉，这时候界面再炫丽操作再流畅都无济于事了。

　　怎么办？只能由技术人员事先准备数据，把关联表做成逻辑或物理的单表，这就是所谓的“数据建模”。一旦有新的关联需求，就需要技术人员重新建模。这种搞法，“自助”和“敏捷”就无从谈起了。

　　糟糕的是，这个问题还是理论上的，只要数据库的数据组织和关联描述方式不变，或者说只要仍在关系代数的体系下，这件事就无解！敏捷BI产品在界面环节无论如何努力都是徒劳。

　　敏捷BI虽然是个新词，但涉及的内容并不新鲜，以前的OLAP产品也是瞄这个目标去的，可以说敏捷BI就是OLAP换个马甲后再加强了呈现能力。应用OLAP产品时也一样碰到这个问题，也一样无法解决，也只能是事先准备好死板的CUBE，有新关联需求时再重建新CUBE。有个别公司产品能根据数据类型做一些自动关联，但碰到同维关联（很常见）或自关联时仍然没有办法。国内BI界当时有个词叫shelfware，就是用来形容这种中看不中用的OLAP产品。厂家人员开玩笑说卖的不是software，而是买来就被扔进柜子不再动的shelfware。在演示阶段让用户产生极大的期望以为真能让业务人员自己分析，实际用起来完全不是那回事，结果都会沦为报表工具在用（报表工具对“沦”字表示不爽）。这是购买OLAP或现在敏捷BI产品的一个大坑！

行业化，敏捷BI产品的合理出路

       不过，也不是完全没有办法。虽然无法在当前数据库理论体系下通用地解决这个问题，我们却可以在工程方面通过行业化的手段来缓解，这也是敏捷BI产品的合理出路。用事先获得的行业知识可以把数据项之间的关联关系固化到程序界面中，业务用户在选择某些数据项时，程序已经知道这些数据项之间的最常见关系，就会大概率地建立出正确的关联。比如我们知道通信业务中一般都用电话号码把其它信息串起来，也知道手机号中已包含有一些业务信息。利用这些知识可以简化关联路径的寻找，有了行业知识后的敏捷BI产品就可能真地“敏捷”地应对业务人员的关联需求了。

　　类似地，现代敏捷BI产品一般都还有业务人员制作管理看板（dashboard）的功能。显然，用户要的不会只是在一个界面上摆上几个固定不变且毫无关系的图表，而会要求这些图表之间可以联动，并且有统一的参数来控制。这又是另一种关联：图表之间的关系，图表与参数的关联。让业务人员去理解这种抽象的关系是不现实的，实现一个通用的看板制作功能恐怕也只能给程序员去用了。而如果有行业知识，就可以事先知道行业内常用的图表间关联以及参数，直接做死，业务用户不必关心抽象问题，只负责摆放即可。

　　但是，这需要了解每个行业甚至每个用户的数据特征和术语习惯，而这些知识换个行业甚至用户就很大可能性不再适用了。这样，敏捷BI不再是一个通用产品，而是一个服务型的解决方案。

       所以，实施BI项目，国内厂商比国外厂商的实际效果要好，因为能提供定制化服务；而对BI技术不是特别熟悉的行业集成商能做得更好，因为他们有深刻的行业和用户知识。国外品牌看着是很炫，但厂商没能力提供本地化服务，又因为集成性差也难以让第三方代劳，结果实施效果大都很差，也就是再进一步诠释shelfware而已。

本文出自 “12691508” 博客，谢绝转载！