敏捷BI的那些麻烦事（一）

敏捷BI这个词这两年比较流行，其实深究起来就是自主报表，是希望业务人员自己能完成数据分析和呈现。业务人员经常面对临时性的数据分析需求，比如某区域的电商想搞个促销活动，经常需要一批有针对性的用户数据来分析一下，传统手段一般提交给技术部门去实现，这样显然周期长、效率低，有时获得结果时已经失去促销窗口期了。如果能有一套前端工具让业务人员自己做分析和呈现，那无疑会极大地提高决策效率，敏捷BI中说的敏捷多半指的是前端自主的敏捷。另外，当下敏捷BI的厂商，在产品交互体验上做的都还比较流畅，所以还是有相当的客户愿意卖单。

但这种在前端体验上的“自主敏捷”和“流畅敏捷”，其实都严重依赖事先的数据准备工作，一旦分析需求超出事先的准备，都很难再敏捷起来了。而数据准备一般都比较复杂，经常要做脱敏处理或多表关联，只能由技术人员来完成，是最费时费力的环节。根据经验总结，主要有两类运算，过程计算和关联查询。

先来说说过程计算，如图，过程计算是指数据S不能直接使用，需经过一个处理过程（比如，脱敏或增加计算列）计算成S'，相当于一定程度的ETL工作,这类需求经常用传统的SQL或存储过程去处理。SQL难以处理过程计算，只能用多个SQL分步加中间临时表的方式，存储过程倒是专门用来解决SQL过程化缺失的手段，但其与数据库高度耦合，需要较高权限编译后再次执行，调试繁琐，安全和管理都比较麻烦，并非理想的计算工具。在数据准备需求比较少，数据源比较单一时，用SQL或存储过程，可以勉强对付，随着各类业务人员需求的增多，库内数据准备的任务也越来越多，如果接入的各业务数据库再有不同，数据准备工作也越来越不一致，耦合在各业务数据库的处理过程越来越难管理。

为了提高性能和技术一致性，直接用Java做数据处理也经常被使用，算法外置可以帮助解耦，库外计算帮助数据库减负，但Java缺失结构化类库，总需要硬编码，做个分组汇总都需要上百行代码，非脚本语言，先编译后调试不如SQL便捷，用其它脚本语言的集成性又较差，难以和主流的工程语言相结合。

集算器是构建在Java基础上的脚本语言，将SQL的便捷、存储过程的分步和Java的可移植性统一起来，用它为BI提供数据准备，开发过程简单一致。集算器提供了SQL函数翻译功能，BI换数据库，如果是基于集算器简单SQL实现的，随便换什么数据库都不用改代码，配置切换就可以了，而非像某些BI厂商换一种数据库就要发回研发部门去改代码，为用户定制一个版出来。

敏捷BI就好比是自助餐，可选择性看似多样化了，但其实还是要仰赖厨师手艺，敏捷的手艺要凭借敏捷的工具，否则还真不一定能吃上几样心仪的菜。