BI产品的核心功能是数据可视化，借助数据可视化挖掘分析数据背后的价值，从而起到辅助研究或决策的作用。
近期调研了很多BI产品，包括付费的与开源的，需要根据需求决定是购买还是基于开源的扩展还是自己开发。
产品很杂，需求又总要考虑到扩展，如果每个产品都试用一遍，分析分析利弊，测试一下user story，需要的成本比较高，因此就重点看了两个比较体验与上手的BI产品（FineBI和豌豆BI），抽象出了BI模型，然后根据模型再结合需求分析分析可扩展性，以及BI产品在自己开发时的难点。
BI模型
BI产品的设计思路可以抽象为下图的模型。
倒着推理，想要可视化数据，其实依赖的是x和y，也就是说，想要生成图表，传给图表的数据必须是x和y（可能有z）。最简单的场景就是我们要可视化的是一张数据表，且这张表直接包含要设置的x值与y值，那么直接绘图就可以；再想要灵活一些，可能想要展示的数据不在表里，需要动态计算得出，那么要支持动态计算列，算出来后就将问题转变为上一个场景的问题，可以直接绘图；再灵活一些，可能数据都不是一张表，分散在n张表，需要从n张表做连接等运算，才能得到可展示的表，转化为上两个场景的问题。
所以，BI解决的核心问题就可以抽象为「如何从n张表到x和y」的问题。这个过程就是「数据建模」，从n张表到x和y，可以涵盖BI面临的所有场景，需求再怎么扩展，也不过就到n张表。
结合上述三个场景，「数据建模」又可以拆分为「表生成」与「动态列生成」两步，「表生成」做的是把n张表变成1张表，是场景三到场景二的抽象，「动态列生成」是场景二到场景一的抽象。
BI产品可能的扩展点
根据BI模型可以发现，BI产品的可扩展点有三个部分，即「数据获取」、「数据建模」、「数据可视化」。
数据获取的扩展点
数据获取的扩展点主要在于数据来源的多样性。数据可能来自各种种类的数据库，也可能来自文件，如果写死任何一个来源，在扩展时都会变得很难受，这个问题就抽象成了「如何屏蔽某个方向的变化，使其不影响后续步骤」，这就自然联想到“接口”的概念。为了让可视化依赖的图表与数据源不耦合，可以专门抽象出一层表，作为可视化依赖的表，如下图所示，所有数据源的内容都需要先转成这个中间依赖，这样无论数据源怎样变，只需要配置上层，不需要修改其他内容。事实上，看一些优秀的开源BI产品（比如superset）就会发现，他们都会有自己的数据库引擎，支持多种数据源，然后把数据源的数据转化成数据库引擎的数据，设计理由就是如上所述。
数据建模的扩展点
数据建模的扩展点其实在分析数据建模场景的时候已经分析过了。如果你的需求比较简单，那么BI支持到动态列生成就足够，如果你的需求可能变更，并且希望变更后不需要再进行改动，那么BI就要支持表生成，这样未来不论需求如何扩展变更，开发人员都不需要再另做开发。
这里值得一提的是关于「动态列生成」存在的扩展点。
可以看到，动态列生成分为三个场景，对于第三个场景，想要计算A类与B类的精确率，得出x和y确实是依赖这两列，但又不是简单地「列1 / 列2」就能算出来的，对于这类场景，其实可以转化为「重组中间表」的问题，其实期望的是根据这些数据，重新得到一个「类别 ｜ 精确率」的中间表，然后展示出来。
所以动态列生成的问题可以抽象为下图所示问题
可视化的扩展点
可视化的扩展很容易想到，无非是多种类型的图表，然后就是交互上降低用户的成本，支持一些分享保存的常用功能，锦上添花。
BI设计难点（产品关注点）
从模型抽象以及可扩展点来看，BI产品解决方案需要考虑的首先是「如何灵活地数据重组」，可以想到的有两种方式：
- 用SQL之类可以实现多种逻辑的语言;
- 用Excel，有强大的公式算符做基础；
调研就会发现，微软的power BI就是基于Excel的，有Excel支撑，重组表和计算公式不是问题，开源的BI通常都是用SQL，也有一些小众的用plainless等语言，总之就是这些语言可以实现重组表和运算的逻辑，并且学习成本比较低。只要支持了数据重组，BI就完成了一大半。
除此之外，还需要考虑的问题是「如何使图表能够动态刷新」，由于产生了一系列的中间表，因此当原数据发生变更后，这些中间表如何随之变更，以及刷新的性能问题，是BI实现时需要考虑的重点。
总结
从模型上能得出BI的设计思路，以及重要关注点，这些关注点也是考察一款产品时需要注意的点，如果一个产品是基于SQL的，那么你看一下他能否creat table以及create view，能否自定义sql，如果能，那么他可以满足所有核心需求了，如果不能生成表，那么限制就比较大，有了模型抽象，产出各项产品的对比方案就会比较容易。
很多问题看起来五花八门，其实越往向上抽象越会发现他们的相似性，越能联想到一些已有的解决方案，一步步推出问题的解，大概就是格物致知吧。
