Apache Hadoop准实时数据处理的架构模式

Ted Malaska 译：Robin robinlee@cmu.edu

原文地址：Architectural Patterns for Near Real-Time Data Processing with Apache Hadoop

本文由 董飞老师翻译并投稿至36大数据，转载必须获得原文作者、译者和本站的同意。拒绝任何不标明作者和出处的转载。

进入董飞先生 在36大数据的专栏>>>

评估好哪一种流架构模式最适合你的案例，是成功生产开发的先决条件。

Apache Hadoop 生态系统已成为企业实时地处理和挖掘大数据的首选。 Apache的Kafka， Flume， Spark， Storm， Samza等技术在不断地推进新的可能。人们很容易泛化大规模实时数据案例，但其实他们可以细分为几种架构模式，Apache系统里的不同组件适合于不同的案例。

这篇文章探讨四种主要的设计模式，案例来自于我们企业客户的数据中心的实例，并解释如何在Hadoop上实现这些架构模式。

流处理模式

四种流模式（经常串联使用）为：

流采集：低延迟将数据输入到HDFS，Apache HBase和Apache Solr。

基于外部环境的准实时事件处理： 对事件采取警报，标示，转化，过滤等动作。这些动作的触发可能取决于复杂的标准，例如异常监测模型。通常的使用案例，例如准实时的欺诈监测和推荐系统，需要达到100毫秒以内的延迟。

准实时事件分割处理：类似于准实时事件处理，但通过将数据分割获得一些好处—例如将更多相关外部信息存入内存。这个模式也要求延迟在100毫秒以内。

为整合或机器学习使用的复杂拓扑结构：流处理的精髓：实时地通过复杂而灵活的操作从数据中获取答案。这里，因为结果通常依赖于一段窗口内的计算，需要更多的活跃的数据， 于是重点从获得超低延迟转移到了功能性和准确性。

接下来，我们将介绍如何用可检测的，可被证明的和可维护的方式来实现这些设计模式。

流采集

传统上，Flume是最为推荐的流采集系统。它的大的源和池囊括了所有关于消费什么和写到哪里的基础（关于如何配置和管理flume，参考Using Flume，由O’Reilly 出版的Cloudera工程师/Flume 项目管理委员会成员Hari Shreedharan编写）。

Figure 1译者附：Flume架构

在过去的一年中，Kafka也变得非常受欢迎，因为playback和replication等特性。由于Flume和Kafka有重叠的目标，他们的关系常常令人困惑。他们如何配合？答案是简单的：Kafka的管道和Flume的通道类似，虽然是一个更好的管道，原因就是刚才所述的特性。一个通行的方法就是用Flume作为源(source)和池(sink)，而Kafka是他们中间的管道。

下图阐明kafka如何作为Flume的上游数据和下游目的，或Flume管道。

下图的设计是具有大规模拓展性，经过实战检验的架构设计，由Cloudera 管理者监控，容错，并且支持回放。

值得注意的一件事就是，这个设计多么优雅地处理故障。Flume 池从Kafka消费者群里取回。通过Apache zookeeper的帮助，Kafka 消费者群取回topic的位移。如果一个Flume池发生故障，Kafka消费者将把负载重新分发到其他的池中。当那个池恢复了，消费者池将重新分发。

基于外部环境的准实时事件处理

重申一下，这个模式的适用案例通常是观察事件流入然后采取立即动作，可以是转化数据或一些外部操作。决策的逻辑依赖于外部的档案或元数据。一个简单并且可拓展的实现方法是，在你的Kafka/Flume架构中添加源（Source）或池（Sink）Flume拦截器。只需简单配置，不难达到低毫秒级延迟。

Flume拦截器允许用户的代码对事件或批量事件进行修改或采取动作。用户代码可以与本地内存或外部Hbase交互，以获取决策需要的档案。Hbase通常可以4-25毫秒内给予我们信息，根据网络状况，模式概要，设计和配置而有所不同。你也可以将Hbase配置为永远不停止服务或被中断，即便在故障情况下。

这一设计的实现除了拦截器中应用的具体逻辑几乎不需要编程。Cloudera管理器提供直观的用户界面，可以部署这个逻辑，包括连结，配置，监测这一服务。

准实时基于外部环境的分割化的事件处理

下图的架构（未分割方案），你将需要频繁查询Hbase，因为针对某一事件的外部上下文环境在flume拦截器的本地内存中装不下。

但是，如果你定义一个键值来分割数据，你将可以把数据流匹配到相关上下文的一个子集。如果你将数据分割成十部分，那么你只需要将十分之一的档案放入内存里。 Hbase是快，但本地内存更快。Kafka允许你自定义分割器来分割数据。

注意，在这里，Flume并不是必须的；根本的方案只是一个Kafka消费者。所以，你可以只用一个YARN消费者或只有Mapper的MapReduce。

针对集成或机器学习的复杂拓扑

到此为止，我们探索了事件层面的操作。然而，有时你需要更复杂的操作，例如计数，求平均，会话流程，或基于流数据的机器学习建模。在这种情况，Spark流处理是最理想的的工具，因为：

和其他工具相比，Spark易于开发

Spark丰富简明的API让建设复杂拓扑变得容易

实时流处理和批处理的代码相似

只需很少的修改，实时小量流处理的代码就可以用于大规模离线的批处理。不仅减少了代码量，这个方法减少测试和整合需要的时间。

只需了解一个技术引擎

训练员工了解一个分布式处理引擎的机制和构件是有成本的。使用spark并标准化将会合并流处理和批处理的成本。

微批处理帮你更可靠地进行拓展规模

在批处理层面的应答将允许更多的吞吐量，允许无需顾忌双发的解决方案。微批处理也帮助在大规模下高效发送修改到HDFS或Hbase。

与Hadoop生态系统的集成

Spark与HDFS，Hbase和Kafka有很深的集成。

无丢失数据的风险

由于有了WAL和Kafka，Spark流处理避免了故障时丢失数据的风险

易于排错和运行

在本地的IDE中你就可以对你的spark流处理代码进行排错和逐步检查。而且，代码和普通函数式程序代码类似，对Java或Scala程序员来说，无需花很多时间就能熟悉。（Python也支持）

流处理是天然状态化的

Spark流处理中，状态是“第一公民”，意味着很容易写基于状态的流处理应用，对节点的故障可恢复。

作为实际的标准，Spark现在正在得到整个生态系统的长期投入

在写此文时，spark在30天内已有700次左右的提交—和其它框架相比，例如Storm，只有15次的提交。

你可以使用机器学习的库

Spark的MLlib库越来越受欢迎，它的功能只会越来越强大。

如果需要，你可使用SQL结构化查询语言

通过Spark SQL，你可以为你的流处理应用添加SQL逻辑，从而简化代码

结论

流处理和几种可能的模式有很强大的功能，但正如你在这篇文章所了解，你可以通过了解哪一种设计模式适合你的案例，从而最少量的代码做非常好的事情。

Ted Malaska是Cloudera解决方案架构师，Spark，Flume和Hbase的贡献者，O’Reilly书籍 《Hadoop 应用架构》的合作作者。

End.

生成海报

免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。