敏捷BI的那些麻烦事(一)

发布时间:2018-04-04 分类:产品文章 Tag:

BI1

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

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

bi-1

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

bi-2

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

bi-3

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

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