本文共 1868 字,大约阅读时间需要 6 分钟。
作者:蒋步星
来源:数据蒋堂
本文共1100字,建议阅读8分钟。
关注BI系统数据源有关的后台功能点。用户在选购BI解决方案的时候,常常会更关注界面环节的功能指标,比如美观性、操作的流畅性、移动端支持等等。毕竟,BI是要给业务人员使用的,这些看得见的内容一般不容易被遗漏。
然而,有些与数据源有关的后台功能点就可能被忽略掉。如果在项目实施时才发现就会非常麻烦,可能造成上线延迟,或者有些功能只能绕路而行。在选购BI系统时反而要特别注意这些功能点。
对大清单报表的支持
OLAP分析时钻取到明细数据是个基本功能,而明细数据很可能非常大,常常需要分页显示。我们在前面文章中讨论过这个分页功能的实现手段。需要提请注意的是,绝大多数BI解决方案都在使用该文中所说的数据库的分页取数机制,而没有实现文中建议的双线程方案。这些内容我们在那篇文章中已经详细解释,这里就不再赘述了。
对更换数据库的支持
BI涉及的源数据大多在关系数据库中,需要用SQL来取数。而OLAP分析涉及的SQL语法形式非常简单,都是标准SQL的内容。这样,理论上讲,BI系统更换后台数据库应当是很容易的事。
但并没有这么简单,取数用的SQL主体确实是通用的,但总会涉及到一些用于条件和计算的函数,特别是与日期相关的运算 ,各家数据库相差很大。而且,上面说的分页语法也是标准SQL之外的东西,也和使用的数据库相关。这样,在更换后台数据库时,这些语法要根据使用的数据库来做调整。
那么问题来了,这些调整是可以简单配置就好的?还是需要有厂家程序员再编码实现的?作为用户,我想肯定会想当然地认为都叫BI产品了,这些应当能配置一下就好了吧。然而,并不是!很有一些BI厂商需要现场再开发代码才能实现数据库的切换。只不过,许多用户常常只有一种数据库,在厂商部署系统时就已经准备好,也就感觉不到更换数据库竟然还会是个问题。
对存储过程的支持
单纯的多维分析一般不会直接用到存储过程,特别是直接基于数据库的ROLAP,本身运算也是由数据库完成的,要拼SQL实现,不可能使用存储过程作为数据源。不过,BI系统常常也都有自己的分析运算能力,可以针对任意一个给定的数据集做分析,这时候就可能接入存储过程(以及其它外部程序数据源)来实现一些复杂或高效的数据准备工作。
存储过程的访问有业界标准,JDBC/ODBC接口都对此有明确的规定,按说支持起来应当不是太难的事情。然而,再一次的并不是!有些厂商不支持或只能有限地支持存储过程,不能通用地支持符合JDBC/ODBC标准的调用接口,这包括某个国际大牌厂商(这里就不点名了)。存储过程参数和返回值都比较复杂,也没有元数据信息来获取数据结构,要全面支持确实也有点麻烦。
专栏作者简介
润乾软件创始人、首席科学家
清华大学计算机硕士,中国大数据产业生态联盟专家委员,著有《非线性报表模型原理》等,1989年,中国首个国际奥林匹克数学竞赛团体冠军成员,个人金牌;2000年,创立润乾公司;2004年,首次在润乾报表中提出非线性报表模型,完美解决了中国式复杂报表制表难题,目前该模型已经成为报表行业的标准;2014年,经过7年开发,润乾软件发布不依赖关系代数模型的计算引擎——集算器,有效地提高了复杂结构化大数据计算的开发和运算效率;2015年,润乾软件被福布斯中文网站评为“2015福布斯中国非上市潜力企业100强”;2016、2017年,荣获中国电子信息产业发展研究院评选的“中国软件和信息服务业十大领军人物”;2017年度中国数据大工匠、数据领域专业技术讲堂《数据蒋堂》创办者。
数据蒋堂
《数据蒋堂》的作者蒋步星,从事信息系统建设和数据处理长达20多年的时间。他丰富的工程经验与深厚的理论功底相互融合、创新思想与传统观念的相互碰撞,虚拟与现实的相互交织,产生出了一篇篇的沥血之作。此连载的内容涉及从数据呈现、采集到加工计算再到存储以及挖掘等各个方面。大可观数据世界之远景、小可看技术疑难之细节。针对数据领域一些技术难点,站在研发人员的角度从浅入深,进行全方位、360度无死角深度剖析;对于一些业内观点,站在技术人员角度阐述自己的思考和理解。蒋步星还会对大数据的发展,站在业内专家角度给予预测和推断。静下心来认真研读你会发现,《数据蒋堂》的文章,有的会让用户避免重复前人走过的弯路,有的会让攻城狮面对扎心的难题茅塞顿开,有的会为初入行业的读者提供一把开启数据世界的钥匙,有的甚至会让业内专家大跌眼镜,产生思想交锋。
数据蒋堂第二年往期回顾:
编辑:黄继彦
转载地址:http://bmuqi.baihongyu.com/