正确的处理快数据：五步法

最初由Scott Jarr撰写

最后一篇文章定义了未来的企业数据架构将是什么样子，以及“快”和“大”将如何协同工作。本文将深入探讨如何正确的处理快数据。

很多解决方案从一些有实力的科技公司涌现出来，以此表明一个巨大的问题即将到来。不幸的是，这些解决方案使您失去了快数据中很大一部分价值。如果你继续沿着这些道路走下去，你会比你预想中更早地重新开发你的系统。

我确信快数据是一个新的领域。当我们开始深入地将分析整合到组织的数据管理架构中时，这是一个不可避免的步骤。

这是我的理解：应用程序以前是使用可操作数据库组件编写的。应用程序开发人员只编写应用程序很少考虑如何进行分析，因为这不是他们的工作。

数据已经成为新的黄金，应用程序开发人员已经意识到需要把应用程序产生的快数据流和分析结合起来，这样才可以更好的利用这些数据。这就是快数据的起源以及我说这是不可避免的原因。有关数据增长趋势的相关问题，请参阅EMC Digital Universe（EMC数字宇宙）报告，其中包括IDC的研究和分析; 以及Mary Meeker发表的“2013年互联网趋势报告”。

如果您打算在数据流上构建一个数据驱动应用程序，您该怎么做呢？在与应用程序的开发人员合作完成这项工作时，至少要达到这五个要求。当然，您和您的伙伴也可以选择放弃其中的一些。但是，您的决定应该由应用程序的需求驱动，而不是受限于您选择的数据管理技术。

快数据应用程序的五个要求如下所示：

1.和实时数据反馈互动

广泛的来源和更高的数据频率使得组织中很多有趣的数据获取速度变得更快。这些数据源通常是任何正在构建的数据管道的核心。然而，仅仅获得这些数据是不够的。请记住，一个应用程序面对数据流的同时，另一端的'东西'通常是寻找某种形式的交互。

例如：VoltDB为许多智能电网应用提供动力，其中包括英国计划推出的5300万米（连接到英国电网）。当这些仪表每秒输出大量传感器读数时，您将面临严重的读取数据的挑战。除此之外，您只有查看每个传感器读数，才能确定传感器的状态以及是否需要操作它。

2.决定数据反馈中的每个事件

您需要通过使用其他数据块来决定如何才能满足上述交互的需求 - 它为您提供了必要的决策环境。做出这些决策需要一定数量的存储数据。如果一个事件仅仅获得其表面价值，那么就会缺少事件发生的背景。您就不能通过加深对程序的理解来做出的更好的决策了。

例如：当我可以比较一米内连接到同一个变压器的另外10个仪表的读数，而不是通过家中的单个仪表来确定变压器是否有问题时，我们的传感器读数才能变得更加丰富和有价值。

这里有一个可能更接近生活的例子。一位女士正在商店购买香蕉，如果我们向她推荐其他购物者购买的香蕉时，该建议将是及时的，但不一定有用; 也就是说，我们不知道她买香蕉是为了制作香蕉面包，还是只是为了搭配麦片。因此，如果我们根据汇总过得购买数据向她提供建议，那么这些建议对她来说将是有用的，但可能不是个性化的。我们的建议需要相关情境，需要及时有用，并且需要根据购物者的需求进行个性化。要全部完成这三项工作 - 无需多虑，我们需要利用当前环境针对事件采取行动，例如存储的数据。

3.通过实时分析提供快速流动数据的可视性

我将通过讲故事来阐明我的观点。我记得我在2011年第一次参加JasperWorld大会。我向某人介绍了如何使用VoltDB来查看快速移动数据的聚合信息和仪表盘。他说了一些简单又深奥的话：“当然，要不然你怎么能理解数据移动得如此之快呢？”

但是，理解快速移动数据的能力不仅仅在于看着仪表板的人。把实时分析用在决策过程是快数据应用和传统OLTP（on-line transaction processing，联机事务处理）的区别。通过在快数据引擎中运行这些分析，就可以通过分析得到决策。在做出决策时，如果拥有多个事件的情境，就可以让决策更加明智。在大数据中，就像在生活中一样，情境就是一切。

示例：根据我们的智能电表示例，我被告知变压器在出故障之前会呈现特定的趋势，并且这种类型的电气元件的故障可能相当严重。因此，如果可能的话，我们希望可以提前知道即将发生的故障。这是把实时分析应用到决策过程中的一个经典的例子。如果变压器在30分钟中的历史数据中呈现出这样的趋势，那么就关闭它并重新布线。

4.将快数据系统无缝集成到存储大数据的系统中

我们已经清楚地表明，我们相信在21世纪的数据库技术方面，一种规模并不适合。因此，快速操作数据库是管理快数据的正确工具，而其他工具则针对大数据的存储和深层分析处理进行优化（有关详细信息，请参阅我以前的文章）。在这些系统之间移动数据是必要的。

但是，这不仅仅是数据移动。除了数据的单纯移动外，大数据和快数据之间的整合需要考虑到：

• 解决大系统导入能力和快数据获得速率不匹配的问题;
• 系统之间的安全传输，包括持久和缓冲，以及
• 对数据进行预处理，以便它在到达Data Lake（数据湖）时即可使用（聚合，清理，充实）。

示例：快数据来自整个国家智能电表快速的累积。这一历史数据在显示季节性趋势方面比电网效率等方面具有更明显的价值。将这些数据移至Data Lake（数据湖）中是极其重要的。但是，数据验证、安全检查和数据清理可以在数据到达Data Lake之前完成。集成在数据管理产品中的应用越多，应用架构师需要弄清楚的代码就会越少（“如果一个系统出现故障，我怎么保存数据？”“如果我的Data Lake无法持续获取数据怎么办？“）。

5.能够将来自大数据系统的分析结果和知识快速提供给用户和应用程序，从而关闭数据循环

BI报告和数据科学家的深度分析需要变成可实施的。可以通过两种方式实现：

• 使BI报告可以让更多被分析系统支持的人员或设备消费，以及
• 从分析中获取情报并将其转移到运营系统中。

第一个很容易描述。报告系统（例如数据仓库和Hadoop）可以很好地生成和计算出报告。但是它们不能以毫秒级向数以千计的并发用户提供这些报告。为了满足这种需求，许多客户将这些分析存储的结果转移到内存中的可操作组件，以便其能够在这些快数据频率/速度中提供结果。坦率地说，我猜想为了达到这个目的未来我们会看到这些分析存储位置将会在内存加速中。

第二项功能要强大得多。我们从大数据处理中获得的所有知识应该为决策提供信息。将这些知识转移到运营仓库、通过深入分析理解让进入系统的每一个事件中都能够操作。

示例：如果我们的系统按照这个想法进行工作，我们正在对智能电表和基于网格的读数进行操作决策。我们正在使用当月的数据来查看零件趋势，确定帐单并提供网格管理。我们将这些数据导出回大数据系统，科学家们可以通过收集相关事件数据来了解季节变化趋势。

假设这些探索性分析已经实现，根据当前的电网规模，如果在夏末出现10度的热浪，那么电力就需要从其他供应商转移或增加。这些知识可以应用在我们的系统中，因此，如果我们发现10度的热浪时，网格将根据当前数据动态调整并根据历史记录进行通知。我们已经关闭了电网内数据情报的循环。

最后，实际部署中，我们已经看到了这些需求。不过，并不是每一个客户都想同时解决这五个问题。但是几乎在我每一次谈话的过程中，大多数的需求都包含在最终需求文档中。掩饰这些需求是有风险的; 我警告人们不要对快数据组件做出战术决定，因为他们认为“我现在只需要担心获取数据”。这是重构架构的必然路径，并且比其他情况要快得多。

在下一篇文章中，我将表达解决快数据技术挑战的想法，并具体地分析一下为什么流处理类型解决方案无法解决90％快数据使用中的问题。