是时候讨论一下数据架构了!也许并行架构、NoSQL、NewSQL、Hadoop、SQL on Hadoop、列式关系型数据库管理系统扩展等等层出不穷的新架构已经让你眼花缭乱了。今天我们共同关注一下企业如何选择适合自己的数据架构，以及并行计算在新兴数据架构中地位。本文是两篇系列文章的第一篇，第二篇为《数据库市场冷观察：从SQL走向NoSQL》

Curt Monash

分析公司Monash Research总裁、资深数据库管理系统行业观察者

目前很多技术决策者都对实时分析很感兴趣，但这一技术很复杂，对应各种各样的数据架构。组织该采用什么架构，实现实时分析？

Curt Monash：谈到这个问题，我想，引用Ingres创始人Michael Stonebraker的一句话再合适不过了——没有一种尺寸能适合所有事物。

尺有所短寸有所长，我们需要做的只是物尽其用。比如对这种任务来说，理想的数据管理系统是这样的，对于那样的任务，理想的数据管理系统又是那样的。不过，技术人员还是要做出取舍，毕竟不能需要多少种，就运行多少种数据管理系统。

因此最佳的选择就是既要兼顾，又要避免走极端。看一下大型企业的架构，既不会只有一个数据库管理系统解决所有问题，也不会为每一项任务配备最合适的系统。

人们总是喜欢问，什么样的架构才是最好的架构。但每个人的需求不同，真的没有一个放诸四海皆准的架构。

当然，如果你是一个小公司，就不存在我刚才说的问题了。如果你的公司足够小的话，你完全可以把所有数据放到一个数据管理系统里，甚至不用区分数据仓库和OLTP（联机事务处理系统）。事实上，这类组织通常会采用SaaS服务，企业内部一到两个数据管理系统就完全足够了。

我们是否可以说，在新的、有竞争力的架构中，并行是它们共同的特征？我们知道并行在Hadoop和Hadoop 2重要组成部分Spark中都占有重要地位。

Curt Monash：并行计算通常有两种主要的需求——在同一节点上把负载分配到不同的处理器核心上;把负载分配到不同的节点上。大多数人关心的是后者，因为如果你能解决第二个问题，也就能解决第一个问题了。

基本上所有的数据和负载都需要扩展才能完成。从本质上来讲，是因为每个CPU所属的处理器核心，性能不会再增长。物理时间的增长也必须停止，因为它将耗费巨大的能量，产生大量热量。

你可以通过提升芯片的方法获得更多处理器核心，这样更划算。某种程度上来说，你最后会获得更多的节点，这往往是最划算的方式。

问题是有些任务特别容易并行处理，但有些却不能。对于容易并行的，我们称它为“理想并行”。你只需要在很多数据行中做相同的，简单的工作。

MapReduce并行范式非常适合处理“理想并行”任务，但不太适合一般的并行处理。

Hadoop 2正在努力解决这一问题。舆论一致认为，最好的下一代并行范式存在于Spark中。Spark在分配负载和数据的时候比MapReduce更灵活。Spark也更适合于迭代的机器学习，MapReduce则不然。同时，MapReduce不得不频繁地在磁盘上写中间结果，而Spark则没有这种局限性。至于流数据，很早以前就已经有方法表明Spark能够处理流数据。