数据平台的历史进程

我们正处于数据的黄金时代。对于我们这些身处用户端的人来说，它的感觉并不明显。但是这项技术的每一走过的每一步都值得更深入的分析。

我们一直在追赶续期的迭代。在过去十年中，我们看到了数据处理技术突破性技术进步后的突破性进展，并且在2015年我们已经到了Spark的时代。

让我们来看看将我们带到今天的需求演进过程。

2006年之前：ETL，数据仓库和OLAP多维数据集

数据平台最常用的方法是使用 ETL 进程将传入数据转换为现成的块，这些块将被批量加载到数据仓库中。

对于对于低延迟查询，数据仓库由OLAP多维数据集补充。但是整体上缺乏灵活性，大多数数据平台都是按日计划进行的。只要需简单地更改了业务逻辑，就算不是几个月的联调的技术工作，也会导致数周甚至数月。

OLAP多维数据集是一个多维数据库，针对数据仓库和联机分析处理（OLAP）应用程序进行了优化。

对于商业供应商而言，这是一个黄金时代，但对于企业管理即使是少量数企业需要更快地采取行动，而这些庞大的流程正在减缓业务发展。企业的特殊问题超出了预算报告的范围，这是变革的主要催化剂。

2006-2009：MPP救场

从2006年到2009年，多并行处理器（MPP）数据库为数据仓库带来了可扩展性和荒谬的速度，并使OLAP多维数据集过时，从而实现了堆栈的整合。Greenplum，Netezza和Vertica等MPP供应商占据主导地位，前行业领导者用他们自己的解决方案回应，例如Oracle的Exadata; Teradata已经在这个空间里玩了。即使在刚开始MPP发生的那些日子里，人们仍在发生变化：业务需求在不断变化，半结构化数据的丑陋野兽正在崛起。

随着MongoDB等NoSQL数据库的兴起以及分析RESTful和SOAP API日志和响应数据的需求增加，半结构化数据开始充斥数据平台。开发人员从严格模式中解放出来直接与关系数据库的基础相冲突。

公司希望分析这些新数据源，并将按照半结构化和非结构化数据按压到严格模式的压力给ETL流程带来巨大压力。

除此之外，还有另一个根本问题：公司正在积累和收集他们无法融入关系数据模型的数据，因为他们还不知道他们将如何使用它。先验地需要数据模型的限制意味着真正的探索性分析解锁数据中的隐藏价值仍然是新生的。

2010-2012：房间里的大象（Hadoop的logo是大象）

Hadoop走到了现场，为企业提供了一个可以转储任何类型数据的地方，并允许原始数据科学家在其上捅棍子，从而减轻MPP对每个人的压力。

2009年，Cloudera发布了他们的Hadoop发行版的第一个版本，到2010年，Hadoop开始成为主流企业的家喻户晓的名字。这种转变中的输家很快变成了ETL工具，这些工具由Hadoop成群结队地流离失所，这也可以完成所有这些繁重的工作。

最佳实践架构迅速成为Hadoop + MPP，Hadoop成为事实上的ETL平台，将数据转换为加载到MPP数据库。在Hadoop中分析了无法将其推入MPP数据库的任何内容 - 尽管通过Hive和Pig等工具的速度要慢得多。

这是一个很好的稳定点，但业务需求再次发生变化：数据量增加给MPP带来巨大压力，需要快速加载数据，并且提取价值最高的数据从结构化数据转变为半结构化数据那是坐在Hadoop。这意味着直接在Hadoop上执行分析变得至关重要。

MPP供应商推出了“Hadoop连接器”，可以将数据从Hadoop提取到MPP进行处理 - 但这会对性能产生非常不利的影响，因为计算需要接近存储。还有另一个同步转变 - 需要近乎实时地分析数据流。

2012-2014：Lambda的崛起

解决方案开始变得清晰：世界需要一个能够接收大量数据并执行批处理和流操作而不会退缩的系统。Nathan Marz 基于他在Twitter上的工作创建了Lambda架构的概念。

在Lambda中，Hadoop中有一个“批处理层”，可以安全，可靠地处理数据，还有一个“速度层”，可以进行实时流处理，并且不需要超级可靠。传统上，Lambda堆栈使用Kafka + Storm作为速度层，Hadoop作为批处理层。

堆栈将在两个层中处理相同的数据，速度层在创建数据后立即作出反应，批处理层随后进行更可靠，更强化的处理。Lambda架构的主要问题来自其复杂性。Jay Kreps在他的博客文章中做了很好的探索。

数据工程师需要在两个地方实现业务逻辑，包括两个框架，管理两个基础架构，以及从两个源组成单个数据视图。市场和社区对这些缺点做出了反应 - Summingbird为速度和批处理层提供了一个通用的API; 然后Hortonworks将Storm纳入他们的Hadoop发行版，在某种程度上统一了基础设施和管理。

Lambda今天非常重要，并且拥有许多优秀的属性，但是许多数据工程师都把目光锁定在视野上，寻找技术上的变化，这将使堆栈不像火箭科学。

2015年：Apache Spark

如今，Spark在数据工程社区中占据了主导地位。即使作为一种新兴技术，Spark也解决了前面几节中讨论的许多问题：

• Spark＆Spark Streaming的统一API和基础架构。Lambda风格的架构更加平易近人。
• 数据工程师友好的API。Spark以易用性着手到达现场，Hadoop DSL最终通过Scalding等框架进化而来。
• 分层存储。Spark可以将数据缓存在内存，本地磁盘或HDFS中。这允许开发人员进一步优化他们的应用程序。
• Apache Tez值得一提，因为它是一个与Spark重叠的框架，能够构建一个直接的非循环图（DAG），可以跨分层存储分发和执行处理。Tez的开发是为了插入现有的框架，这些框架具有数据工程师友好的API，如Pig，Hive和Cascading。

它并不意味着数据工程师直接使用，因为它的API太低了。因此，它在社区中没有得到同样的关注，但Hortonworks正在响应Spark-on-Tez项目，这应该令人兴奋。

最后但同样重要的是，尽管Spark可以在Hadoop之外生存，但两者交织在一起，因为大部分数据Spark都将在HDFS中处理生命。HDFS的重力是巨大的，因为它构建了一个“数据结构”，构建了分析应用程序，并且不可忽略。Spark需要继续构建并改进其Hadoop生态系统支持。

词汇说明：

• Impala承诺通过提供超低延迟查询来扩展“纯Hadoop”堆栈。
• Amazon Redshift只是简单易用，延长了MPP架构的使用寿命。
• OLAP多维数据集在Hadoop生态系统中卷土重来，创建了推入HBase的聚合，以及像Kylin和Platfora等商业产品的项目。