大数据下的数据分析-Hadoop架构解析(2)

数据分析的算法复杂度

根据不同的业务需求，数据分析的算法也差异巨大，而数据分析的算法复杂度和架构是紧密关联的。举个例子，Redis是一个性能非常高的内存Key-Value NoSQL，它支持List和Set、SortedSet等简单集合，如果你的数据分析需求简单地通过排序，链表就可以解决，同时总的数据量不大于内存 (准确地说是内存加上虚拟内存再除以2)，那么无疑使用Redis会达到非常惊人的分析性能。

还有很多易并行问题(Embarrassingly Parallel)，计算可以分解成完全独立的部分，或者很简单地就能改造出分布式算法，比如大规模脸部识别、图形渲染等，这样的问题自然是使用并行处理集群比较适合。

而大多数统计分析，机器学习问题可以用MapReduce算法改写。MapReduce目前最擅长的计算领域有流量统计、推荐引擎、趋势分析、用户行为分析、数据挖掘分类器、分布式索引等。

面对大数据OLAP分析的一些问题

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

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





图2 RCFile的行列混合存

然而，对于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和报表产品。如图3所示。





图3 MDX→MapReduce简略示意图

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