1.4 近实时解决方案——可用的架构

在本节，读者将学会如何构建可扩展、可持续且具有鲁棒性的实时系统解决方案，以及如何对可能的架构模式进行选型。

高级NRT解决方案看起来非常直观和简单，其具有数据收集漏斗、分布式处理引擎以及一些其他组件（如缓存、稳定存储和仪表板插件）。

如图1-4所示，在较高层面上，基本的分析过程可以分为3类：流数据的实时数据收集；分布式流数据的高性能计算；以可查询消耗层/仪表板的形式探索和可视化生成的见解。

市场上有两种存在竞争的流式计算技术，即Storm和Spark。下面我们将深入研究从这些堆栈中获得的高级NRT解决方案。

1.4.1 NRT的Storm解决方案

该解决方案实时捕获高级流数据并将其路由到某个队列/代理（Kafka或RabbitMQ）中，然后通过Storm拓扑处理分布式处理部分，一旦计算出见解，就可以将它们快速写入数据存储（如Cassandra）或其他队列（如Kafka），以进行进一步的实时下游处理。如图1-5所示，通过发送/提取收集代理（如Flume、Logstash、FluentD或Kafka适配器），可从不同数据源收集实时流数据。然后，数据被写入Kafka分区，Storm拓扑从Kafka中提取/读取流数据并在其拓扑中处理此数据，并将见解/结果写入Cassandra或其他一些实时仪表板。

1.4.2 NRT的Spark解决方案

在更高的层级上，Spark的数据流管道与图1-5所示的Storm架构非常相似，但是它最受诟病的一点是Spark利用HDFS作为分布式存储层。在进一步深入之前，我们先看看对整体流程及其细节的进一步剖析，如图1-6所示。

与典型的实时分析管道一样，流数据使用Flume或Logstash等抓取代理来提取数据。本节首先介绍Kafka，以确保数据源与抓取代理之间的系统解耦；然后介绍Spark Streaming组件——它将结果转储到稳定的存储单元、仪表板或Kafka队列之前，提供了一个用于处理数据的分布式计算平台。

前两种架构范式之间有一个本质区别：虽然Storm本质上是一个实时事务处理引擎，默认情况下，擅长按事件处理传入数据；但Spark基于微批的工作理念，本质上是一个伪实时计算引擎，通过减少微批的大小，可以满足接近实时的期望计算。Storm主要用于快速处理，所以所有转换都在内存中，因为任何磁盘操作都会产生延迟；对于Storm来说，这既是一个优点，又是一个缺点（因为如果事情中断，内存是不稳定的，一切都必须重新处理，中间结果会丢失）。此外，Spark基本上由HDFS支持，并且功能强大且容错性更强，因为中间结果在HDFS中有备份。

在过去的几年中，大数据应用程序按以下顺序进行了精彩的转换。

●仅批处理应用程序（早期的Hadoop实现）；

●仅流处理（早期的Storm实现）；

●可以是两者（前两者的定制组合）；

●前两者（Lambda架构）。

问题是：为什么发生了上面的演变？当人们熟悉了Hadoop的强大功能时，他们真的很喜欢构建几乎可以处理任何数据量的应用程序，并且可以将其以无缝、容错、无中断的方式扩展到任何级别。然后，随着Storm等分布式处理引擎的出现，逐步进入到了一个大数据处理成为强烈需求的时代。Storm可扩展性强，且具有轻量级快速处理能力。但是，有些情况发生了变化，大部分人意识到了Hadoop批处理系统和Storm实时系统的局限性和优势：前者满足了对数据量的需求，后者在速度方面非常出色。这些实时应用程序非常完美，它们在整个数据集的短时窗口上表现得很好，但在以后的某个时间没有任何修正数据/结果的机制。虽然Hadoop实现准确而强大，但需要花费很长时间才能获得确定性的结论。我们达到了这样的一个程度，即复制了完整/部分解决方案，以获得涉及批处理和实时实现相结合的解决方案。最近的NRT架构模式中的Lambda架构，是颇受欢迎的解决方案，结合了批处理和实时实现，无须复制和维护两个解决方案。Lambda架构能同时满足数据量和速度的要求，这是早期架构的优势，可以满足更广泛的用例集。