今天给大家分享的是“蝶变-Smartbi2018大数据分析峰会”广州站，Smartbi首席售前咨询顾问杜健航先生的主题演讲。
所以，传统BI就会有以下问题：
1、需要数据仓库支撑。数据仓库的建设周期很长，而且很依赖于技术人员，有任何小的需求都必须找IT人员，业务人员发言权很小;
2、传统BI主要是数据报表的功能，没有数据挖掘、人工智能这些更深层次的应用;
3、传统BI处理的数据量有几百万就很不错了，现在动不动就上亿。
刚才还有客户问我：针对上亿的数据，我们的处理速度是多少?
正因为以前有这些问题，敏捷BI应运而生。敏捷BI让业务人员参与度变高;更有利于类似于手机、大屏等传播渠道;让项目的运作周期缩短，以前半年至一年的项目，现在只要两三个月就可以完成;数据格式更加丰富、数据量更大。
但是，这些都是敏捷BI的表现形式，敏捷BI的本质是将由技术部门主导的事情变成由业务部门主导，这才是敏捷BI的核心。
Smartbi认为，敏捷BI产品应该包含以下几个方面：
1、强大的数据处理能力;
2、高标准产品支撑性能;
3、严格的权限管理标准(适用于集团级别);
4、必备的易用性;
5、运营支撑能力。
我们具体来看一下Smartbi在这些方面所作的努力。
在数据处理部分，以前传统BI里建指标、建维度这些由技术人员处理的工作，在敏捷BI里，必须让业务人员能自己完成。可以自己拖拉拽，可以自己定义数据关系，维度和指标，例如：时间维度，年月日这样的层次结构，完全不用敲代码，利用鼠标轻点即可实现;如果要算交易总额，也是滑动鼠标就可以完成。正是能真正帮助业务人员解决这些问题，满足数据处理自主化，才称得上敏捷BI。
企业接触到的数据源越来越多，跨库能力也是关键。Smartbi产品完全支持跨库数据源，比如：Oracle、MySQL、Hadoop等，只要动动鼠标就可以进行关联和运算。此外，还支持动态宽表的概念。动态宽表偏技术，我们可以稍作解释：最原始做项目是直接把业务系统的数据表拖在一起，直接用原始数据表做分析，如果数据量大，这种方式完全行不通;数据量大以后，技术人员会建立CUBE(数据立方体)和大宽表，业务人员基于此进行数据分析，虽然这种方式能满足一定需求，但场景就固化了，无法支撑变化的需求;而最根本的解决方式是，支持动态宽表，即由业务人员构建模型和宽表，要做到这点，从产品层面，必须支撑整个仓库的建模或语义层建模，也就是把整个数据仓库上所有的字段按业务涵义建立。
在权限管理方面，是很多国外敏捷BI所缺乏考虑的。在国外，这类产品通常用户体量小，可能由一两位分配权限就可以了;但在国内，比如银行系统，会有几百，上千人来使用自助分析平台，不可能由一两个人授权完成。因此，敏捷BI产品必须具备分级授权的策略，还是用银行举例，总行级别的管理员授权给二级(分行)管理员，二级(分行)管理员再继续往下授权。功能层面还需要具备权限继承机制，这主要是解决部门人员流动、需重复授权的问题。
在运营方面，以前的敏捷BI很少涉及到运营。对于集团化的客户来说，它需要的不仅仅只是购买或安装一款敏捷BI的产品，更重视的是运营这块的需求。Smartbi重视以人为本的一体化运营，因为企业在上项目时，自助的工具只是提高工作的效率，必须要由激励人的手段来获得想要的结果。回到技术层面，谈到数据运营，必须有配套的数据搜索的配套手段，从产品或工具层面而言，必须让搜索变得容易快捷，否则对于报表制作的数据来源就会模糊不清。此外，还需要有数据答疑功能，业务人员自己做报表如果有问题或难点，可以通过问答系统来答疑解惑;资源发布-避免不同部门做重复的工作，通过类似苹果的应用商店来实现。
总结来说，Smartbi重新定义敏捷BI并不是要推翻过去对敏捷BI的定义。过去三四年，敏捷BI在国内的推广很成功，很多企业都接受了这个概念。做敏捷BI从本质上是适用企业数据化运营的趋势，Smartbi的理念是要做一个更完整、更完善、更优化的敏捷BI，而现在Smartbi的产品不论是从产品思维、功能实现、实践经验上都具备了做好一款敏捷BI的要求。
好的，我的演讲就到这里，谢谢大家!
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至253000106@qq.com举报，一经查实，本站将立刻删除。
发布者：SEO优化专员，转转请注明出处：https://www.chuangxiangniao.com/p/969958.html
