2013-03-20 00:00:00
来 源
中存储
大数据
面对大数据OLAP分析的一些问题 发布时间:2012.05.16 09:25来源:赛迪网作者:OLAP分析需要进行大量的数据分组和表间关联,而这些显然不是NoSQL和传统数据库的强项,往往必须使用特定的针对BI优化的数据库。比如绝大多数针对BI优化的数据库采用
面对大数据OLAP分析的一些问题 发布时间:2012.05.16 09:25      来源:赛迪网     作者:

OLAP分析需要进行大量的数据分组和表间关联,而这些显然不是NoSQL和传统数据库的强项,往往必须使用特定的针对BI优化的数据库。比如绝大多数针对BI优化的数据库采用了列存储或混合存储、压缩、延迟加载、对存储数据块的预统计、分片索引等技术。

Hadoop平台上的OLAP分析,同样存在这个问题,Facebook针对Hive开发的RCFile数据格式,就是采用了上述的一些优化技术,从而达到了较好的数据分析性能。如图2所示。

然而,对于Hadoop平台来说,单单通过使用Hive模仿出SQL,对于数据分析来说远远不够,首先Hive虽然将HiveQL翻译MapReduce的时候进行了优化,但依然效率低下。多维分析时依然要做事实表和维度表的关联,维度一多性能必然大幅下降。其次,RCFile的行列混合存储模式,事实上限制死了数据格式,也就是说数据格式是针对特定分析预先设计好的,一旦分析的业务模型有所改动,海量数据转换格式的代价是极其巨大的。最后,HiveQL对OLAP业务分析人员依然是非常不友善的,维度和度量才是直接针对业务人员的分析语言。

而且目前OLAP存在的最大问题是:业务灵活多变,必然导致业务模型随之经常发生变化,而业务维度和度量一旦发生变化,技术人员需要把整个Cube(多维立方体)重新定义并重新生成,业务人员只能在此Cube上进行多维分析,这样就限制了业务人员快速改变问题分析的角度,从而使所谓的BI系统成为死板的日常报表系统。

使用Hadoop进行多维分析,首先能解决上述维度难以改变的问题,利用Hadoop中数据非结构化的特征,采集来的数据本身就是包含大量冗余信息的。同时也可以将大量冗余的维度信息整合到事实表中,这样可以在冗余维度下灵活地改变问题分析的角度。其次利用Hadoop MapReduce强大的并行化处理能力,无论OLAP分析中的维度增加多少,开销并不显著增长。换言之,Hadoop可以支持一个巨大无比的Cube,包含了无数你想到或者想不到的维度,而且每次多维分析,都可以支持成千上百个维度,并不会显著影响分析性能。

因此,我们的大数据分析架构在这个巨大Cube的支持下,直接把维度和度量的生成交给业务人员,由业务人员自己定义好维度和度量之后,将业务的维度和度量直接翻译成MapReduce运行,并最终生成报表。可以简单理解为用户快速自定义的“MDX”(多维表达式,或者多维立方体查询)语言→MapReduce的转换工具。同时OLAP分析和报表结果的展示,依然兼容传统的BI和报表产品。

在年收入上,用户可以自己定义子维度。另外,用户也可以在列上自定义维度,比如将性别和学历合并为一个维度。由于Hadoop数据的非结构化特征,维度可以根据业务需求任意地划分和重组。

声明: 此文观点不代表本站立场;转载须要保留原文链接;版权疑问请联系我们。