面对大数据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数据的非结构化特征,维度可以根据业务需求任意地划分和重组。