发帖
雷达卡
qlikview操作简单吗？笔者从qlikview的优点和缺点两个方面讨论了一下。
众所周知，Qlikview绝对定位就是一个前端工具，跟数据仓库不仓库的没什么关系的。它的数据源，可以是已经建设好的数据仓库、或者小型的数据集市、或者直接从源系统加载到QVD再到QVW中，或者直接从源到QVW中，都是可以支持的。只是往往在产品宣传的时候，为了体现其“快速实施”的优势，而省去提及数据仓库建设方面的了。
Qlikview也称其具有ETL功能的，只是相对其他的ETL工具来说，哪怕是SSIS，都要弱上太多太多。没有图形化界面、没有好的脚本管理及版本控制方法、定时调度等待方面，确实是其缺陷。但是作为前端工具，附带的ETL功能再垃圾，也不算是重点。
元数据管理方面的缺失，也确实是存在的，这方面可以依据企业自身需要而选择，有些行业，尚未到此阶段。有些企业，定位Qlikview为桌面级别的分析工具，或是企业仪表盘的发布，那么对于元数据管理方面，自然要求也是有限。
这是个比较纠结的地方，Qlikview本身就是一个别出心裁的工具，算是不走寻常路吧，跟其他传统的BI前端工具都不太一样，因此很难拿其比对着传统工具的MOLAP、ROLAP、语义层等类似的概念来讨论。但是Qlikview中有“组”的概念，结合过滤的属性、交叉表组件等，可以部分实现的“上钻”、“下钻”、“切片”、“切块”、“旋转”等操作。通过如此这般操作内存中的数据集，也可以实现一个报表样式变换实现出若干张业务需求报表的需求。
提到这点就顺便说一下，由于与传统不一样，则有几点也会是特别一些的：
1. 处理同期、前期、年累计等，是与其他工具的计算方式有区别的，很难简单套用其他工具的概念；
2. 由于一个QVW就是一个大的数据集合，则同一QVW中所有页签的数据都会随着选择、过滤等操作而联动，既是好事，但对数据显示上来说也增加了控制的难度。
Qlikview运行效率问题，这个倒也真还是个问题，数据量的增大、计算复杂度的增加，确实对资源的消耗很大，在QV客户端上运行的本机，3.5G的内存（同时运行有其他程序）打开个二三十兆的QVW文件，会遇到点击响应要等待的问题。实际部署时，基于保守的心理，基本上给客户就会提内存32G、64G或更多这样的需求。
只是，拿QV和OLAP，尤其是MOLAP来比，是个不算太合适的比较，MOLAP牺牲空间换取时间，QV内存动态计算，不慢些才觉得奇怪了。
提到了Qlikview运行时的一个问题，美观，这个确实是个做仪表盘的不错的工具，客户的实际操作中，容易点着点着就混乱了参数，这种情况也确实有发生的，尤其是改变若干参数还切换页签。至于QV只善于展示KPI等，这个便是仁者见仁智者见智的事了，看制作应用的顾问水平了，当然，也跟客户的实际需要紧密关联。
除此之外，在选择Qlikview时，有几个点，确实是值得考虑的：
1.Qlikview开发出来的应用文件，是若干个QVW文件，QVW文件是存储了数据的，分析时是要加载至内存的，各个QVW文件数据的交叉使用情况，是较差的，估计也是极其不好实现的。这样，自然会给人一种这些QVW都是“孤立”的感觉。如需要改善这种情况，也可考虑QVW的数据从数据仓库/数据集市而来，在开发前端时，各种公式、口径一定要严格遵守规范，统一，避免出现同一指标出现不同口径算出不同值的情况。
2.权限控制，在这方面是比较弱的，在LOAD脚本中进行定义，依据字段去设置，有点偏“硬”，欠灵活。
3.与外部WEB平台的集成性、不支持FLASH地图(Google地图用起来不是太好看)等；
4.仅运行于WINDOWS平台，这也是一个有局限性的点。
5.总代来说，Qlikview还算是个偏小众的BI工具，资源少、交流少是一大困扰。
但是QV也有着其鲜明的特点，在此也简要列举几个核心点：1. 适应了QV的开发习惯后，系统原型开发周期确实可以提升不少，存在快速开发及部署的可能，这也为很多实施商所宣扬；
2. 从仪表盘开发展现角度来看，美观度都算挺不错的；
3. 简单，易用，入门较容易
4. 成本因素，这个也是终端客户一般都需要考虑的
总而言之，工具没有最好的，只有合适的，如果不寄希望于Qlikview作为企业级别的BI工具，而作为一个有特点的亮点或是补充、譬如个人级的分析平台、部门级别分析应用发布平台、仪表盘发布平台等，确实还是一个不错的选择。
提升卡
置顶卡
沉默卡
变色卡
抢沙发
千斤顶
显身卡
京公网安备 11010802022788号
