本系列的首篇文章中，我们介绍了这样一个概念，即企业数据架构正在成形，并且对快数据的处理与现在所说的大数据处理方法是不同的。在第二篇文章中我们看到了快速数据的例子以及应用程序与快速数据交互所需要的东西。在本文中，我会阐释我对企业架构是如何设想的，而此架构可以让企业实现对快速数据和大数据的整合。

下图展示了此架构大数据工作的基本原理。中间部分是Data Lake(数据湖)，或称之为数据池、数据储备库或是其他……。很明显，它是企业用来存放其所有数据的场所。此组件并不因为设计和功能上的原因而显得独特，但是它却因为要存储一切内容而成为一个有着巨大成本效益的系统。从本质上讲，它是一个在廉价商用机器上的分布式文件系统。

可能某项技术格外吸引眼球，比如说HDFS或是其他技术(对于Amazon就有可能会是S3)，但关键在于，这里汇集了所有数据。此平台将会：

1. 存储要发送给其他数据管理产品的数据

2. 支持可以对文件系统数据直接执行任务的框架

围绕在Data Lake周围的是一些补充技术，它们可以让人从那些存储在Data Lake中的数据获取认知和价值。从上到下依次是：

BI报表：数据仓库可以出色的执行报告任务，并且可以持续提供此功能。一些数据会导出至那些系统并在那里临时存储，同时会以混合方式从Data Lake直接访问其他数据。这些数据仓库系统是专门设计来执行复杂报告分析的，而且它们也做的非常好。

SQL on Hadoop：这里有着很多的创新。这些产品的目的是取代数据仓库。像Hawq和Impala这样的产品已经有所进步。但毫无疑问的是，对于这些系统要接近数据仓库的速度和效率还有很长的路要走，尤其那些有列式设计的系统。SQL-on-Hadoop系统的存在有两个重要原因：

1) SQL仍是在数据上所能取得的最佳方式

2) 进行处理并不需要移动大量的数据

挖掘分析：这是数据科学家的领域。这些工具为在数据中有所发现提供了某些功能：模式，模糊关系，统计规则等等。Mahout和R语言是此类中的流行工具。

MapReduce：通常Hadoop上所有要执行的任务和管理工作都是在MapReduce群组中进行的。如今很多的Hadoop用例都包括在使用上述分析工具之前进行预处理和数据清洗。这都是这些工具和接口所允许的情况。

企业应用程序的ETL：最后是ETL流程，它会协助从我们信任的企业应用程序将所有的遗留数据放入存储所有内容的数据池。这些应用程序会逐渐适时地迁移至成熟的快速+大数据应用程序，而这一点我会在将来的文章中进行讨论。在这里我要说的是：当我把传感器加到生产线上之后，我就会有一个快速+大数据的问题。

好的，我们现在有了这些分析……然后呢？

我们为何要先做分析呢？很简单，我们想要：

• 更好的决策
• 更好的个性化
• 更好的检测
• 更好的交互

应用程序要负责交互，并且这是在你可以准确并实时做这些交互时最具价值的改进。这就引出了此架构的第二部分，在这里我们可以更好的处理快速数据，加快实时应用程序，这些都如下图所示。

首先要注意的是，快速和大是紧耦合的，尽管它们是独立的系统。至少在规模上它们必是如此。数据库系统是设计来在每秒钟处理数以百万计的事件决策的，这与那些设计用来保存千万亿字节数据并生成扩展报告的系统是截然不同的。

快速数据的实质就是产生一定数量的关键需求以最有效地使用它。这些包括的功能有：

• 数据种子提取与交互
• 对种子中的每个事件做出决策
• 利用实时分析为快速移动的数据提供可视性
• 无缝集成到设计用来存储大数据的系统中去
• 从大数据系统为用户和应用程序快速提供分析结果和知识，同时关闭数据环路。

没有比可操作的数据库更好的满足这些需求的技术了。我们过去所面临的挑战是，没有一个可操作的数据库能够管理这种吞吐量。结果，就有一些人用权宜之计来试图满足他们的需求，通常是放弃某些功能并且总是增加了复杂性。

在下篇文章中，我会详细介绍一些功能，这些功能是我所看到的客户正在寻找的能支持他们的快速数据应用程序。然后我们会看一下尝试用一个流行的流处理解决方案所产生的结果。