以下是我的理由：过去应用程序通常是用一个操作数据库组建来编写的。应用程序开发人员很少担心分析是如何进行的——过去，这由其他人负责。他们只编写操作应用程序。

       但是数据已经变成了新型财富，而且应用程序开发人员也已经意识到如今应用程序需要与快速数据流和分析进行交互充分利用可用数据。这就是高速数据的来 源以及为什么我说这是不可避免的。这些从EMC Digital Universe的报告和Mary Meeker在2013年的Internet Trends报告中都能体现出来。

       因此，如果你正在建立类似这些运行在数据流之上的数据驱动应用程序，你会需要什么呢？在与人们协作建立这些应用程序中，一般可以归结出五项需求并使之正确。当然，你可以给出一些，然后人们来做。但是还是要让应用程序需求来驱动决策，而非受制于你所选择的数据管理技术。

Fast Data应用程序的五项需求：

获取数据与交互

       如今很多有价值的数据的运行速度正在加快，它们以更多的来源和更快的频率进入。这些数据源通常是任何正在建立的数据管道的核心。但是，仅仅是调查这些数据是不够的。记住，应用程序面对的是数据流，而且在另一端的事物通常在寻找的是某些交互的形式。

比如：VoltDB正推动大量的智能电网应用程序，包括一项在UK部署5300万个仪表的计划（接入UK电网）。当你拥有如此大量的仪表且每秒有多个传感器读数的时候，你就会面临严峻的数据获取挑战。此外，每个读数需要检查确定传感器的状态以及是否需要交互。

对每个事件作出决策

       使用其他数据来决定如何回应以上交互所描述的提升——它提供了你做决策所急需的语境。需要用一定数量的存储数据来做出这些决策。如果一个事件的发生仅限于其表面意义，那你就会错失事件发生的语境。要有能力来做出更好的决策，因为你对整个应用程序可能了解的东西会是迷失的。

比如：当我能够将一个仪表的读数与其他十个连接相同变压器的仪表读数进行对比来确定变压器问题，而不是仅仅是从一个位于家中的仪表进行判断的时候，我们的传感器读数会变得信息更加丰富且有价值。

这里有另外一个例子可能会更为贴切。一位女士在商店购买香蕉。如果我们给出其他顾客在购买了香蕉的同时还购买了些什么的建议，这可能会是及时的建 议，但并不一定相关;即，我们并不知道她购买香蕉是否是用来制作香蕉面包，或仅仅是作为水果。因此，如果我们是基于购买聚合数据给她提供的建议，那么这些 建议会是相关的，但是可能并不具备个性化。我们的建议需要语境才能具有相关性，他们需要及时且有用，并且还需要满足顾客的个性需求。要满足这三点——不加 权衡的做这些——我们需要在语境条件下在每个事件上加以行动，例如，存储数据。获取数据种子或是与其进行交互的能力意味着我们能够准确知道顾客想要什么， 在确切的时刻了解他/她的需求。

用实时分析为高速数据提供可视性

        可以给大家讲一个故事。记得在2011年首届JasperWorld会议上。讲述如何利用VoltDB来查看高速数据的集合和仪表盘。观众问：“当然，你让数据移动的那么快，那么你打算怎样做来搞清楚它呢？”

但是要能够理解高速数据超出了一个人查看仪表盘的范围。有一样东西让高速数据应用程序与老派的OLTP比起来显得与众不同，就是在决策流程中引入了 实时分析。通过在高速数据引擎内运行这些分析，会给操作决策提供信息。在进行决策的时候，此功能不仅仅是将单一事件纳入语境，它让决策信息更加充分。在大 数据中，甚至在生活中，语境就是一切。

比如：继续拿我们的智能仪表举例，我听说变压器在故障前会显示一个特定的趋势。而且那种电子元器件类型的故障会非常明显。因此，如果可能的话，我们 想在真的发生之前确认这些即将到来的故障。这就是实时分析注入决策流程的经典案例。如果一个变压器30分钟的历史数据显示了这样的趋势，那么就关闭它并重 定电力。

将高速数据系统无缝集成到大数据存储系统

        我们已经明确地确信在涉及到21世纪的数据库技术时，某一种方法并非万灵丹。因此，当某个快速操作数据库正好适于用来胜任高速数据的工作，那么其他工具则最好是优化用户存储和深入分析大数据处理。在这些系统间迁移数据是必要的需求。

       然而，这不仅仅是数据的迁移。除了纯粹的数据迁移，还需要考虑大数据和高速数据的集成：

处理大系统导入能力和高速数据到达率之间的阻抗失配;

      系统间的可靠传输，包括持久性和缓冲，以及数据预处理，因此当它到达数据湖就准备好了被使用（集成，清洗，丰富）。

比如：来自于遍布整个国家的智能仪表的高速数据会迅速积累。这一历史数据在展示季节性趋势，还有诸如同比电网效率上有着明显的价值。将这些数据迁移 至数据湖是至关重要的。但是，在数据到达数据湖之前会做有效性和安全性检查并对数据进行清洗。越是将此更多的集成进数据管理产品，应用程序所需要解决的问 题就会越少（“如果系统故障，我要如何保存数据？”“如果我的数据湖无法继续获取，我要从哪里溢出数据呢？”…）。

关闭数据循环，从大数据系统为用户和应用程序快速提供分析结果和知识

       由BI报告生成并由数据专家分析的具有深刻洞察力的分析需要可操作化。这可以通过两种方式来实现：

       通过分析系统所能支持的更多的人或设备来让BI报告更具消费性，采用从分析中获得的情报并将其迁移进操作系统。

第一条很容易描述。报告系统（如数据仓库和Hadoop）在生成和计算报告方面做了不错的工作。它们并不是设计用来在毫秒级延迟下提供这些报告给数 以千计的并发用户的。要满足此需求，很多客户正在将这些分析结果迁移存储至一个内存操作组件，这样就可以以高速数据的频率和速度提供结果了。坦率的讲，我 认为我们会在将来看到仅以此为目的的将这些分析存储的内存加速。

第二条则更为强大。我们从所有大数据处理中所获得的知识应该用于为决策提供信息。将这些知识迁移至可操作存储便会有助于这些决策，由深入分析理解加以驱动，并为每个进入系统的事件可操作化。

比如：如果我们的系统到目前为止如所描述的工作，我们正在基于智能仪表和基于电网的读数来进行可操作决策。我们正在使用来自当前月的数据以访问组件 趋势，确定计费并提供电网管理。我们将数据导出至大数据系统，在那里专家会探究季节性趋势，并通过所收集的某些事件的数据来获取信息。

我们说这些探索性分析已经有所发现，鉴于目前的电网规模，如果在夏末出现一个+10度的热浪，电力就需要转换或是从其他供应商那里进行补充。这些知 识如今也可以用于我们的操作系统，即如果我们遇到了+10度的热浪，电网会根据当前数据及历史信息进行动态调整。我们已经在电网内部关闭了数据情报循环。

       最后，我已经在实际部署中见到了这些需求。不，并不是每个客户都希望马上解决所有五个方面。但是通过我经历的几乎每个谈话过程，大多数观点都包括在 最终需求文档中。掩盖这些需求是有风险的;我要警告人们不要因为想当然的认为“我只是现在必须担心获取”而在高速数据组件上做出战术性的决策。这是一个确 定的五步路径来反应这一架构，并且可能要比实际情况要快得多。