选型QlikView建议关注的问题

bjourway

选型QlikView建议关注的问题

§1            QlikView是否包括DW（数据仓库）技术，包括数据转换ETL、元数据管理等功能。

数据仓库技术是BI技术的核心，严格的来说，没有数据仓库技术的BI产品，只能称之为一个报表工具。就好像没有生产制造模块的ERP不能称之为完整的ERP一样。数据仓库用于决策支持，面向分析型数据处理，不同于一般的数据库。面对复杂的数据源，最高效的方法就是将数据先整合到数据仓库中，而BI应用统一从数据仓库里取数。

数据仓库的构建本是一个复杂的过程，特别是ETL脚本管理、定时调度以及增量更新机制等。如果可以将一个复杂的过程实现起来变的简单而且易于管理，则可对开发维护人员的门槛大大降低，从某种程度上来讲，也就降低了实施的成本及风险。

QlikView明显是无此项关键技术的。

§2            QlikView是否包括OLAP（多维数据库）技术。

如果没有OLAP，在企业中运用最为频繁的父子维度根本无法快速实现，需要大量的代码。如物料（或客户）编码一般有多级，在OLAP中，只需要一个维度，即可自动实现多级展开，而如果没有OLAP，则物料分了几级，就需要有多少个维度，并且，如果编码并不规范，则更难实现。同时，多维分析技术彻底颠覆了传统报表，它相当于一个魔方，可以任意筛选、旋转、切片、钻取，一个多维数据库可以变换出数十张报表，且只需要操作者通过鼠标拖拽、勾选即可实现。有了OLAP，可轻松实现数据的钻取，能够有效地帮助管理者快速识别问题并追溯到明细的交易数据，找问题背后的原因。

QlikView与用友BQ一样，也只是一个前端展示工具，没有OLAP，复杂分析的建模非常困难。但QlikView也有明细钻取的功能，但如果想钻取到明细的交易数据，则需要大量的设计。

报表系统具有许多先天性的缺陷：

1、  报表仅能实现数据的查询，要真正实现分析，如要从多个维度去分析同一个数据，就得制作许多样式的报表。

2、  一个报表样式，通常就得开发一张报表，会导致开发及维护的工作量都非常大。

3、  报表基于SQL查询，需要临时计算，海量数据下，效率极低。

4、  同样因为基于SQL查询，在权限管理方面也存在许多困难。QlikView是通过内嵌数据向导来进行数据权限的控制，实现起来非常复杂。

§3            QlikView的运行效率。

BI就是在海量数据中快速找到所需要关键信息的技术，使用者感受到的效率是其成功与否的关键因素之一。

QlikView采用自己的数据格式（QVD）存储数据，号称是直接读取内存，速度也快，但基于SQL查询的报表，一定要临时计算，效率仍然无法与OLAP相比。同时，在数据量较大时，占用较大的内存资源，对服务器性能要求较高。且在大数据量情况下，会容易造成系统不稳定。所以，QlikView不适合大量数据分析及数据增量分析。

§4            QlikView的运行维护。

QlikView是美国Qlik tech公司的产品。其前端操作美观、紧凑、灵活，但其操作的习惯，源自西方人的思维习惯。但操作中，鼠标的点击会响应维度钻取，所以很容易因为误操作而变得很乱。且在应用中，会有许多实际的问题无法解决。QlikView仅仅是报表或者将KPI值展示出来，对企业做科学的决策分析并没有多大价值。因为管理者从报表中看不出任何真正对企业决策以及发展具有借鉴意义的数据。

举一个很简单的例子：在进行同比分析时，Qlikview会采取一个非常灵活的展示方式，比如左边会有不同的年度进行选择，然后右边会马上出来不同年度的数据。这样的效果乍一看很不错，但实际应用中会发现：你还需要人工来判断2个年度的数据到底有什么不同。

目前各地机构或代理商掌握这套系统的实施人员非常少，根本无法及时响应。当企业需要另外一种分析报表的样式时，需要专人来进行设计开发，所以，如果企业没有经过专门培训的IT人员，就无法持续优化好这套系统，真正发挥其价值。从这套系统仍然是英文的帮助就可以看出掌握其设计技巧是有较高难度的。被动式的服务会让成本无法控制。通常，价格与成本，永远是企业在信息化产品采购时考虑的重要因素。

YolandaW

非常好的资料，收藏了！QlikView的确存在这样的问题