实时数据处理和分析指南

版权信息

书名：实时数据处理和分析指南

ISBN：978-7-115-52486

本书由人民邮电出版社发行数字版。版权所有，侵权必究。

您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。

我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。

如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。

版       权

著　　　　［印度］希尔皮·萨克塞纳（Shilpi Saxena）

　　　　　［印度］沙鲁巴·古普塔（Saurabh Gupta）

译　　　　吴志国　曾凤姝

责任编辑　吴晋瑜

人民邮电出版社出版发行　　北京市丰台区成寿寺路11号

邮编　100164 　电子邮件　315@ptpress.com.cn

网址　http://www.ptpress.com.cn

读者服务热线：(010)81055410

反盗版热线：(010)81055315

版权声明

Copyright ©Packt Publishing 2018. First published in the English language under the title

Practical Real-time Data Processing and Analytics (9781787281202).

All rights reserved.

本书由英国Packt Publishing公司授权人民邮电出版社有限公司出版。未经出版者书面许可，对本书的任何部分不得以任何方式或任何手段复制和传播。

版权所有，侵权必究。

内容提要

本书主要介绍实时大数据计算领域的相关技巧和经验，包括Flink、Spark和Storm等流处理框架技术。全书从搭建开发环境开始，逐步实现流处理，循序渐进地引导读者学习如何利用Rabbit MQ、Kafka和NiFi以及Storm、Spark、Flink和Beam等组件协同应用来解决实际问题。

本书内容分为6个部分，分别是“导言——熟悉实时分析”“搭建基础设施”“Storm实时计算”“使用Spark实现实时计算”“使用Flink实现实时分析”以及“综合应用”。

在阅读本书之前，读者应具备基本的Java和Scala编程基础，还应熟悉Maven、Java和Eclipse的安装和配置流程。

作者简介

希尔皮·萨克塞纳（Shilpi Saxena）是IT从业者，也是一位技术布道者。她是一名工程师，曾涉足多个领域（机器对机器空间、医疗保健、电信、人才招聘和制造业）。在企业解决方案的构思和执行的所有方面，她都有着丰富的经验。过去3年来，她一直在大数据领域从事设计、管理和提供解决方案的工作。她还负责管理一个分布在世界各地的精英工程师团队。

希尔皮在软件行业的产品和服务方面有超过12年（大数据领域3年）的开发和执行企业解决方案的经验。她曾担任过开发者、技术负责人、产品负责人、技术经理等职位，可以说在这个行业阅历颇丰。她通过AWS的自动扩展，设计并完成了一些在大数据领域中基于Storm和Impala的前沿的产品实现。

希尔皮参与编写了Real-time Analytics with Storm and Cassandra一书（Packt 出版社出版）。

沙鲁巴·古普塔（Saurabh Gupta）是一名软件工程师，已有数十年的IT行业从业经验，在大数据领域有超过3年的工作经验，目前从事处理和设计在生产中运行的实时和批处理项目的相关工作，主要包括Impala、Storm、NiFi、Kafka等技术以及在AWS上部署Docker，他还参与了各种物联网项目，涉及电信、医疗保健、智能城市、智能汽车等领域。

前        言

本书给出了实时大数据计算领域的许多技巧和经验，介绍了Flink、Spark和Storm等流处理框架技术。本书还归纳了一些实用的技术，以帮助读者像使用Hadoop批处理一样的方式实时处理无界流数据。读者可以从如何搭建开发环境开始，逐步实现流处理，然后学会如何利用Rabbit MQ、Kafka和NiFi以及Storm、Spark、Flink和Beam等组件协同应用来解决实际问题。通过学习本书的内容，读者可以对NRT的基本原理及应用有透彻的理解，并能掌握如何将这些基础知识应用到任何适用的实际问题当中。

本书采用“菜谱”（Cookbook）式的写作风格，辅以丰富的实际案例，包括注释清楚的代码示例、相应的图表等。

本书内容概述

第一部分　导言——熟悉实时分析　本部分主要带领读者熟悉实时分析领域，了解它的基础组件和基于此构建的系统，包括如下几章：

• 第1章　实时分析简介
• 第2章　实时应用的基本组件

第二部分　搭建基础设施　本部分主要讲解如何由基础组件搭建基础设施，包括如下几章：

• 第3章　了解和跟踪数据流
• 第4章　安装和配置Strom
• 第5章　配置Apache Spark和Flink

第三部分　Storm实时计算　本部分主要关注Strom的计算能力和它的各种特性，包括如下几章：

• 第6章　集成Storm与数据源
• 第7章　从Storm到Sink
• 第8章　Storm Trident

第四部分　使用Spark实现实时计算　本部分主要关注Spark的计算能力和它的相关特性，包括如下几章：

• 第9章　运用Spark引擎
• 第10章　运用Spark操作
• 第11章　Spark Streaming

第五部分　使用Flink实现实时分析　本部分主要关注Flink的计算能力和它的相关特性，包括如下一章：

• 第12章　运用Apache Flink

第六部分　综合应用　本部分包括如下一章：

• 第13章　用例研究

阅读基础

本书旨在引导读者逐步掌握实时流处理技术。在阅读本书之前，读者应具备基本的Java和Scala编程基础，还应熟悉Maven、Java和Eclipse的安装和配置流程，以便运行示例程序。

读者对象

如果读者是Java开发人员，想要安装相关软件并设计一个端到端的实时数据流的实用解决方案，那么本书非常适合作为参考书。掌握实时处理的基本知识是很有帮助的，了解Maven、Shell和Eclipse的基本原理也对读者大有裨益。

本书约定

在本书中，读者会发现许多文本样式，可以据此区分不同种类的信息。下面给出了这些样式的一些例子，并对它们的含义进行了解释。文本中的代码、数据库表名、文件夹名、文件扩展名、路径名、虚拟URL、用户输入和Twitter句柄表示为：“下载kafka_2.11-0.10.1.1.tgz文件后，提取文件。”

代码块设置如下：

cp kafka_2.11-0.10.1.1.tgz/home/ubuntu/demo/kafka
cd/home/ubuntu/demo/kafka
tar-xvf kafka_2.11-0.10.1.1.tgz

新术语和重要单词以粗体显示。读者在截屏图中看到的单词（例如，在菜单或对话框中）在文本中表示为：“为了下载新模块，我们将转到Files | Settings | Project Name | Project Interpreter。”

警告或重要注释的形式如下。

警告内容。

提示和窍门的形式如下。

提示内容。

审稿人简介

鲁本·奥利瓦·拉莫斯（Ruben Oliva Ramos） 是莱昂技术学院的计算机系统工程师，他毕业于墨西哥瓜纳华托州莱昂市的Salle Bajio大学，拥有该校计算机和电子系统工程、远程信息学和网络专业的硕士学位。他在开发Web应用程序方面有5年以上的经验，擅长用Web框架和云服务来控制和监控与Arduino和Raspberry Pi连接的设备，进而构建物联网应用程序。

鲁本·奥利瓦·拉莫斯在墨西哥的Salle Bajio大学的机电一体化系任教，是机电一体化系统设计和工程硕士生导师。他还在墨西哥瓜纳华托州莱昂市的一家机构（Centro de Bachillerato Tecnologico Industrial 225）工作，负责教电子、机器人和控制、自动化和微控制器等课程。他也是一些监控系统和数据记录仪项目的顾问和开发人员——用编程技术（如Android、iOS、Windows Phone、HTML5、PHP、CSS、AJAX、JavaScript、Augular和ASP.NET）、数据库（如SQlite、MongoDB和MySQL）、Web服务器（如Node.js和IIS）以及硬件编程（如Arduino、Raspberry Pi、Ethernet Shield、GPS和GSM/GPRS、ESP8266）来实现数据采集和编程的控制和监控系统。

他撰写了Internet of Things Programming with JavaScript一书，该书由Packt出版社出版，并参与了用Arduino和Visual Basic .NET为Alfaomega监控、控制和获取数据的项目。

感谢在参与这个项目的过程中给予我帮助和理解的人们，他们是：我亲爱的妻子Mayte、我两个可爱的儿子Ruben和Dario、我亲爱的父亲Ruben和母亲Rosalia、我的弟弟Juan Tomas和妹妹Rosalia。在我审阅这本书的过程中，他们给了我很多的支持，让我能够追求自己的梦想，并容忍我在忙碌的一天工作后不能陪伴他们。

胡安·汤玛斯·奥利瓦·拉莫斯（Juan Tomás Oliva Ramos）是一名环境工程师，毕业于墨西哥瓜纳华托 大学，获得了工程和质量管理的硕士学位。他在专利管理和开发、技术创新项目以及通过控制过程的统计来开发技术解决方案领域有超过5年的经验。自2011年以来，他一直担任统计、创业和项目技术开发的教师。他还是企业家导师，并在Instituto Tecnologico Superior de Purisima del Rincon开设了一个新的技术管理和创业系。

胡安是Alfaomega的审稿人，曾参与了Wearable designs for Smart watches, Smart TVs and Android mobile devices一书的工作。他还通过编程和自动化技术开发了用于改进操作的原型（这些原型已经注册了专利）。

感谢Packt让我有机会审校这本令人惊叹的书，并能有幸与一群敢于担当的人合作。

还要感谢我美丽的妻子Brenda、我的两个女儿Regina和Renata以及我们家的新成员Angel Tadeo——感谢你们给了我力量，让我幸福和快乐地度过人生中的每一天。谢谢你们成为我的家人。

普拉蒂克·巴蒂（Prateek Bhati）毕业于印度最为知名的私立大学——阿米提大学。他目前居住在新德里，就职于Accenture公司，已有4年的实时数据处理经验。

资源与支持

本书由异步社区出品，社区（https://www.epubit.com/）为您提供相关资源和后续服务。

配套资源

本书为读者提供示例源代码。读者可登录异步社区本书页面进行下载。

提交勘误

作者和编辑尽最大努力来确保书中内容的准确性，但难免会存在疏漏。欢迎读者将发现的问题反馈给我们，帮助我们提升图书的质量。

读者如果发现错误，请登录异步社区，按书名搜索，进入本书页面，单击“提交勘误”，输入勘误信息，单击“提交”按钮即可。本书的作者和编辑就读者提出的勘误进行审核，确认并接受后，将赠予读者异步社区的100积分（积分可用于在异步社区兑换优惠券、样书或奖品）。

与我们联系

我们的联系邮箱是contact@epubit.com.cn。

如果读者对本书有任何疑问或建议，请发邮件给我们，并在邮件标题中注明本书书名，以便我们更高效地做出反馈。

如果读者有兴趣出版图书、录制教学视频，或者参与图书翻译、技术审校等工作，可以发邮件给我们；有意出版图书的作者也可以到异步社区在线提交投稿（直接访问www.epubit.com/selfpublish/submission即可）。

如果读者来自学校、培训机构或企业，想批量购买本书或异步社区出版的其他图书，也可以发邮件给我们。

如果读者在网上发现有针对异步社区出品图书的各种形式的盗版行为，包括对图书全部或部分内容的非授权传播，请将怀疑有侵权行为的链接发邮件给我们。这既是对作者权益的保护，也是我们提供高品质内容的动力之源。

关于异步社区和异步图书

“异步社区”是人民邮电出版社旗下IT专业图书社区，致力于出版精品IT技术图书和相关学习产品，为作译者提供优质出版服务。异步社区创办于2015年8月，提供大量精品IT技术图书和电子书，以及高品质技术文章和视频课程。更多详情请访问异步社区官网https://www.epubit.com。

“异步图书”是由异步社区编辑团队策划出版的精品IT专业图书的品牌，依托于人民邮电出版社近30年的计算机图书出版积累和专业编辑团队，相关图书在封面上印有异步图书的Logo。异步图书的出版领域包括软件开发、大数据、AI、测试、前端、网络技术等。

异步社区

微信服务号

第一部分　导言——熟悉实时分析

• 第1章 实时分析简介
• 第2章 实时应用的基本组件

第1章　实时分析简介

本章为读者展现了大数据技术的全貌，尤其是大数据实时分析的概况。本章先给出了概念性的大纲，旨在起到抛砖引玉的作用，以激励读者继续阅读本书后续章节的内容。

本章主要包括以下内容

• 大数据的定义
• 大数据的基础设施
• 实时分析——神话与现实
• 近实时解决方案——可用的架构
• 分析学——过多的可能性
• 物联网——想法与可能性
• 云——考虑NRT和物联网

1.1　大数据的定义

简单来说，大数据有助于处理“3V”问题——体量、速度和多样性。最近，又增加了“2V”——真实性与价值，这就构成了一个五维的范式。

体量：数据的数量。环顾四周，每时每刻都有大量的数据产生，比如电子邮件、推特（Twitter）、脸书（Facebook）或者其他社交媒体中的信息，又如视频、图片、短信、电话记录以及各种设备和传感器产生的数据。数据的计量单位从TB级到ZB级，甚至到YB级这样趋近天文数字的量级。在Facebook上，每天大约产生100亿条消息，点赞50亿次，上传4亿张照片。统计结果令人惊讶，2008年前产生的所有数据量与今天一天生成的数据量相当，相信在不远的将来，这个时间很快就会缩短为一小时。仅从数据体量这一维度来看，传统数据库已经无法在合理的时间范围内存储和处理大规模数据，于是大数据栈脱颖而出，它以低成本、分布式且可靠有效的方式处理这些惊人的海量数据。

速度：数据产生的速度。如今的时代，各种各样的数据都在激增。正是因为数据产生的速度足够快，才积累了如此海量的数据。社交媒体上的事件通常在数秒内就开始流传，接着就开始病毒式地传播。股票交易员在短短数毫秒内就能从社交媒体的热门事件中分析出一些有用信息，并由此触发大量的买入/卖出操作。大数据赋予人们以惊人的速度分析数据的能力：在零售业柜台的终端设备上，短短数秒内信用卡刷卡、欺诈交易的辨别、支付、记账和确认回执等一系列操作就都完成了。

多样性：该维度呈现这样一个事实——大数据很可能是非结构化的。在传统数据库时代甚至更早以前，大部分人习惯于处理类似于表格这样非常结构化的数据。如今超过80%的数据是非结构化的，如照片、短视频、社交媒体更新、传感器采集的数据和通话录音等。大数据技术让你以结构化方式存储和处理非结构化数据，实际上这在一定程度上消除了多样性。

真实性：该维度关乎数据的有效性和准确性。应该如何判断数据是否准确和有效呢？海量的数据记录并非都是经过修正的、准确的且可作为参考的。真实性的内涵在于数据的可信度和质量是怎么样的。数据真实性的例子包括Facebook和Twitter上的帖子使用了不标准的缩写且有拼写错误。大数据已将对数据进行分析的功能用于数据表中。决定数据量究竟有多大的主要因素就是真实性。

价值：顾名思义，就是数据实际拥有的价值。毫无疑问，这是大数据中最重要的维度。从超大型数据集中获取一些有价值的信息或许是人们处理它们的唯一动机，因为所有这些都关乎成本和效益。

当前，几乎所有企业都十分关注大数据技术。众多行业都深信它的实用价值，但实现如上目标的关键主要是面向应用程序，而不是面向基础设施。下一节会详细介绍这部分内容。

1.2　大数据的基础设施

在深入探究大数据基础设施之前，我们先带领读者一览大数据的全貌。表1-1从高层次视角对大数据细分领域进行了划分。

表1-1

表1-1描述了大数据技术的细分领域。最底层是最关键的，支持可扩展和分布式存储。

• 核心技术：核心底层软件如Hadoop、MapReduce、Mahout、HBase和Cassandra等。再往上一层是基础设施层，开发者依据用例和解决方案可以选择合适的基础设施。
• 数据分析基础设施：EMC、Netezza、Vertica、Cloudera和Hortonworks。
• 可运维基础设施：Couchbase、Teradata和Informatica等。
• 基础设施即服务（IaaS）：AWS和Google云等。
• 结构化数据库：Oracle、SQLServer、MySQL和Sybase等。往上一层是特定需求的数据即服务（DaaS）：Kaggle、Azure和Factual等。
• 商业智能（BI）：Qlikview、Cognos和SAP BO等。
• 分析和可视化：Pentaho、Tableau和Tibco等。

可以看到，如今传统的关系型数据库仍然在为数据存储及处理实现高效和低成本的效果而努力挣扎。传统的关系型数据库处理大数据的成本非常高，通过扩展的方式很难满足低延迟的要求。正是由于以上现状，才促进了具有低成本、低时延、高扩展性、开源等需求的新技术的涌现。黄色的大象——Hadoop成为救星，它出其不意地占领了数据存储和计算的竞技场。Hadoop作为分布式数据存储和计算框架，在设计上具有非常高的可靠性和可扩展性。Hadoop计算方法的核心是将数据分块存储在集群的所有节点上，然后在所有节点上并行地处理数据。

相信到了这里，读者已经对大数据的基础知识和全貌有了一些认识，能够以Hadoop框架为例来深入研究大数据的概念。接下来继续研究实现Hadoop集群的体系结构和方法，这与高层基础设施和大型数据集群的典型存储需求非常相似。本书将深入研究的另一个关键话题是大数据环境下的信息安全。图1-1主要指出大数据基础设施中的几个关键因素。

图1-1

集群设计：这是基础设施规划中最重要且最有决定性的一个因素。基础设施的集群设计策略基本上是解决方案的主要考虑因素，包括应用程序用例和要求、工作负载、资源计算（取决于是内存密集型还是计算密集型）以及安全性。除了计算、内存和网络利用率，另一个重要因素是存储，它将基于云或本地。云的选择有公共云、私有云或混合云，这取决于应用场景和企业的需求。

硬件架构：存储成本主要取决于存储数据的体量、存档策略以及数据生存期限。决定性因素有两点。第一点是实现的算力需求（商用化组件是否丰富，或者是否需要高性能GPU）。第二点，内存需求是什么？是低等、中等，还是高等？这取决于应用程序实现内存算力需求。

网络架构：这听起来可能不是很重要，但它是大数据应用的一个重要驱动力。原因在于大数据的关键是分布式计算，而且网络利用率比单服务器单片集成实现的情况高得多。在分布式计算中，数据负载和中间计算结果在网络上传输。因此，网络带宽成为总体解决方案的节流代理，并且取决于基础设施策略的主要方面的选择。糟糕的设计方法有时会导致网络阻塞，其中数据在处理上花费的时间更少，而在通过网络或等待传输以供下一步执行所花费的时间更多。

安全架构：安全对于任何应用程序来说都是非常重要的。在大数据应用场景下，由于它的体量和多样性，以及计算需要通过网络获取数据，因此安全就变得更加重要。安全对大数据基础设施具有关键性和战略性意义，云计算和存储选型这两方面进一步增加了未来对其需求的复杂性。

1.3　实时分析——神话与现实

实时分析的最大真相是实际上没有什么东西是真正实时的，这仅仅是一个神话。实际上，只能说它接近于实时。通过分析可以得到这样的结论：只有提高解决方案的性能和减少操作延时，分析才能接近于实时。由于实际中计算、操作和网络的延迟，实际上不可能消除实时和近实时之间的差距。

在进一步讨论之前，我们带领读者快速了解一下这些所谓的实时分析解决方案的高层次需求。图1-2展现了满足高层次需求的一个系统，该系统可以使用各种结构化和非结构化数据集处理数百万个事务。首先，程序引擎应该超快，并能够处理非常复杂的连接操作和多样化的业务逻辑；其次，可以准确产生令人叹为观止的报告，在一瞬间恢复即席查询（AdHoc查询），并在没有延迟的情况下渲染可视化的仪表面板。

图1-2

以前对实时解决方案的要求是不够的，如果把它们推广到生产环境中，即在当今的数据生成和零停机时代，最基本的要求是，系统应该能够以最小的代价实现自我管理或被管理，并且以容错和自动恢复的方式来构建，以处理大多数情况（即便不是所有情况）。它还应该能够提供类似于基本SQL的接口。

尽管前面对实时分析的要求听起来有些极端可笑，但是它们都是当今大数据解决方案最正常和最基本的要求。然而，回到实时分析这个主题，既然已经简要地谈到了数据、处理和输出方面的系统级要求，这些正在设计和已被设计的系统用于处理数以万计的事务并动态应用复杂的数据科学和机器学习算法，以尽可能接近实时地计算结果。图1-3描述了计算时间、上下文的概念以及最终见解的重要意义。

图1-3

如图1-3所示，在有限时间背景下，存在以下问题。

• 对泽字节（ZB）数据的即席查询占用了小时级的时间，因此这通常被称为批处理。图1-3中圆的大小比喻的是以图形式处理的数据的大小。
• 广告展示次数/标签广告趋势/确定性工作流程/推文：这些大多被称为在线时间和计算时间的用例通常为500ms/1s。虽然与以前的用例相比，计算时间大大减少了，但是处理的数据量也显著减少了。它可以非常迅速处理几吉字节大小（GB）的数据流。
• 财务跟踪/关键任务应用程序：典型特点是数据量很低，数据率非常高，处理非常快，并且在几毫秒的时间窗口中产生低延迟计算结果。

除了计算时间，批处理、实时处理以及解决方案设计之间还有一些显著的差异，见表1-2。

表1-2

在本节，我们想强调的是近实时（NRT）解决方案是接近真正实时的，因为它实际上是可能实现的。所以，如上所述，RT实际上是一个神话（或假设），而NRT是一个现实。每天处理和查看的NRT应用程序，包括车联网、预测和推荐引擎、医疗保健和可穿戴设备。

有一些关键的环节实际上会引入延迟到总周转时间，或者称之为TAT。实际上，事件发生与产生可行的措施之间的时间间隔是由它产生的。

数据/事件通常通过有线（互联网/电信信道）从不同的地理位置传输到处理中心。这项活动已经过了一段时间。其处理如下。

• 数据着陆：由于安全方面的原因，数据通常落在边缘节点上，然后被提取到集群中。
• 数据清理：需要满足数据准确性方面的要求，在处理之前消除错误/不正确的数据。
• 数据修改和丰富：使用维度数据来绑定和丰富交易数据。
• 实际处理。
• 存储结果。这里，所有以前的处理过程都会产生：CPU周期、磁盘I/O、网络I/O、数据序列化方面的主动编组和解组。

既然已经了解了实时分析的实际情况，接下来我们将更深入地了解这些解决方案的架构。

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

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

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

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

图1-4

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

1.4.1　NRT的Storm解决方案

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

图1-5

1.4.2　NRT的Spark解决方案

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

图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架构能同时满足数据量和速度的要求，这是早期架构的优势，可以满足更广泛的用例集。

1.5　Lambda架构——分析可能性

前文已经介绍了这种神奇的架构，那么本节就仔细研究一下该架构模式。

在底层上，Hadoop提供了大量存储，并且有HDFS和MapReduce这种形式的非常强大的处理引擎，既可以处理大量数据又可以执行种种计算。但是，它有很长的周转时间（TAT），而且是一个批处理系统，从而可以帮助解决大数据的体量问题。如果对处理速度有要求，需要寻找一种低延迟的解决方案，则必须求助于实时处理引擎，它可以快速处理最新或最近的数据，并且可在有效的时间范围内快速生成一些见解。但是除了速度和快速的TAT，还需要将更新的数据逐步集成到批处理系统中，以便对整个数据集执行深度批处理分析。因此，从本质上讲，所处的环境既需要批处理系统，也需要实时系统，这种模式的最佳体系结构组合称为Lambda架构（）。图1-7描述了这种模式的高层次设计逻辑。

图1-7

解决方案既与技术无关，又与语言无关；它可以抽象为以下3层：批处理层、速度层和服务层。

输入数据被输送到批处理层和速度层，其中批处理层用于创建整个不可变主数据的预计算视图。该层主要有不可变的数据存储，具有一次写入和大量读取的功能。

速度层处理最近的数据，仅维护最近一组数据的增量视图。该层在数据可访问性方面具有随机读取和写入的功能。

问题的症结在于服务层的智能。在服务层中，来自批处理层和速度层的数据被合并，并满足查询需求，因此，可以无缝地从这两者中得到最好的结果。近实时请求是速度层的增量视图（它们具有低保留策略）中的数据来处理的，而引用旧数据的查询是由批处理层中生成的主数据视图来处理的。该层仅适用于随机读取而不能随机写入，但它确以查询、连接以及批量写入的形式来处理批量计算。

但是，Lambda架构并非是针对所有混合用例的一站式解决方案。有一些关键方面需要注意：总是认为分布式；面向故障的设计和规划；经验法则为数据是不可变的；面向故障设计。

既然已经熟悉了实时分析中流行的架构模式，那么来谈谈这一部分可能存在的用例。图1-8展示了可能应用到的高级领域和各种关键用例。

图1-8

1.6　物联网——想法与可能性

Kevin Ashton于1999年创造了“物联网”这个术语，并由此成为近10年来最有影响力的开拓者之一。虽然有M2M形式的物联网前驱和工业自动化仪表控制，但物联网和连接智能设备的时代已经到来，这是前所未有的事情。图1-9从俯瞰视角帮助读者了解物联网应用的广泛性和多样性。

图1-9

智能互联设备已经进入千家万户，它们具备感知、处理和传输的功能，甚至能够根据处理结果采取行动。几年前科幻小说中的机器时代已经走入现实。如果车主拿着钥匙走进或者远离联网的车，就可以方便地对车进行解锁/锁定。超市里有近距离感应信标，它能感应到顾客和货架的距离，并把报价传送并显示到顾客的手机上。智能办公室通过在空荡荡的会议室里关掉电灯和交流电源来节约电力。这样的例子数不胜数，而且时刻都在增加。

物联网的核心是由联网设备组成的生态系统，这些设备能够在互联网上进行通信。在这里，设备可以是任何东西，像传感器设备、拥有可穿戴设备的人、一个地方、一棵植物、一只动物或一台机器。时至今日，几乎任何我们在这个星球上能想到的实体都可以连接起来。任何物联网平台都主要有7层，如图1-10所示。

图1-10

以下是对物联网所有7个应用程序层的概述。

• 第1层：设备、传感器、控制器等。
• 第2层：通信信道、网络协议和网络要素、通信、路由硬件-电信、Wi-Fi和卫星。
• 第3层：基础设施——可以是内部的，也可以是云端的（公共的、私有的或混合的）。
• 第4层：这里是大数据提取层。这是一个平台，收集来自实体/设备的数据，为下一步做准备。
• 第5层：使用复杂处理、机器学习、人工智能等对数据进行清理、解析，消息生成和分析的处理引擎，以报告、警报和通知的形式生成见解。
• 第6层：自定义应用程序、可插拔的二级接口（如可视化仪表板、下游应用程序等）构成这一层的一部分。
• 第7层：这一层中的人员和流程实际上是根据以下系统的建议进行操作的。

在图1-11中，如果从自下而上开始，最底层是设备层，它们是传感器或由RaspberryPi、Ardunio等计算单元驱动的传感器。此时，通信和数据传输通常由轻量级选项控制，如消息队列遥测传输（MQTT）和约束应用程序协议（CoAP），它们正在快速取代HTTP等传统选项。该层实际上与聚合或总线层结合在一起，本质上它是一个Mosquitto代理，该层从数据源构建了事件传输层，即为从设备到处理集线器之间的部分。一旦到达处理集线器，就可以将计算引擎上的所有数据准备好进行操作，分析和处理数据以生成有用的可操作的命令。这些命令进一步集成到网络服务API可消耗层，以用于下游应用程序。除了这些水平层，还有交叉层，它们用于处理设备配置、设备管理、身份和访问管理层。

图1-11

现在读者了解了标准物联网应用程序的高级架构和层次，下一步是了解物联网解决方案受到限制的关键方面以及对整体解决方案的影响。

安全性：这是整个数据驱动解决方案领域中关键部分之一，连接到互联网的大数据和设备的理念使整个系统更容易受到黑客攻击且安全性方面更敏感，因此在为静态数据和动态数据设计所有层的解决方案时，要将其作为一个战略关注领域来处理。

功耗/电池寿命：由于是在为设备而不是人类设计解决方案，因此，应该具有非常低的功耗，且不会消耗电池寿命。

连通性和通信：与人类不同，这些设备总是相互连接，而且非常“健谈”。同样，我们在整体通信方面需要轻量级协议来实现低延迟数据传输。

从故障中恢复：这些解决方案处理数十亿的数据并且维持7×24小时的工作模式。该解决方案应该能够诊断故障、应用背压，然后从最小的数据丢失情况中进行自我恢复。如今，物联网解决方案旨在通过检测延迟/瓶颈并具有弹性自动扩展和缩小的能力来处理突然出现的数据峰值。

可扩展性：这个解决方案需要设计为线性可扩展模式，而无须重新构建基础框架或设计，这是因为该域正在使用前所未有且不可预测的设备数量进行扩张，这些设备与全部未来等待发生的用例相连。

接下来是物联网应用框架中先前约束的含义，其表面形式为通信信道、通信协议和处理适配器。

在通信信道供应商方面，物联网生态系统正在从电信信道和LTE演变为以下选项。它们分别是：直接以太网/Wi-Fi/3G、LoRA、蓝牙低能量（BLE）、RFID/近场通信（NFC）、中程无线网状网络（如Zigbee）。

对于通信协议，事实上的机载标准是MQTT，其广泛使用的原因是显而易见的。

• 非常轻。
• 就网络利用率而言，占用的空间很小，因此通信速度非常快，负担也更少。
• 提供了一个有保证的传输机制，从而最终能够传输数据，即使是在脆弱的网络上也是如此。
• 功耗低。
• 对网络上的数据包流进行优化，以实现低延迟和较小的使用空间。
• 是一种双向协议，因此既适合从设备上传输数据，也适合将数据传输到设备。
• 更适合这样一种情况，即必须通过网络传输大量的短消息。

边缘分析

后进化、物联网革命和边缘分析是改变游戏规则的重要组成部分。如果要查看物联网应用程序，则需对来自传感器和设备上的数据进行整理，并将其传输到分布式处理单元中，该单元要么位于办公场所，要么位于云上。数据提升和转移导致了大量的网络开销，这使得整个解决方案存在潜在的传输延迟。这些因素催生了一种新的解决方案，并开拓了物联网计算的新领域——边缘分析。顾名思义，它将处理推向边缘，以便数据在其源处被处理。如图1-12所示，物联网分为边缘分析和核心分析。可以看到，物联网的计算现分为以下几个部分。

图1-12

• 设备传感器边缘分析：其中处理的数据和一些洞见是在设备级得到的。
• 边缘分析：这些是已处理数据的分析，并在网关级别获得洞见。
• 核心分析：要求所有数据到达一个公共计算引擎（分布式存储和分布式计算），然后进行高复杂度的处理，以生成可行的洞见，服务于人或机器决策。

传感器/边缘分析的一些典型用例如下。

• 工业物联网（IIoT）：传感器被嵌入在各种设备、机器，有时甚至是车间里。传感器产生数据，设备本身具有处理数据和产生警报/建议以提高性能或产量的能力。
• 医疗领域的物联网：智能设备可以参与边缘处理，有助于发现早期预警信号，并对适当的医疗情况提出警报。
• 在可穿戴设备的世界里，边缘处理可以使跟踪和安全变得很容易。

如今，环顾四周，你会发现联网设备在生活、工作中无所不在，如智能交流、智能冰箱和智能电视。这些智能设备都把数据发往中央集线器或者手机上（在那里它们易于控制）。实际上，物联网正在变得越来越智能，正在从互联发展到足以执行计算、处理和预测的智能化程度，例如，咖啡机智能到可以连接到主人的汽车、办公室，能推测主人的日程和到达时间，并随时准备新鲜的热咖啡。

1.7　云——考虑NRT和物联网

“云”不过是一个术语，用来识别互联网上可以获得的计算能力。大部分人都熟悉物理机器、服务器和数据中心。云的出现把我们带到了一个虚拟化的世界，在那里我们正在向虚拟节点、虚拟化集群甚至虚拟数据中心转移。现在，使用硬件虚拟化手段在几台物理机上就可以搭建一个虚拟机集群。这就像是让软件运行在硬件上一样。下一步是实现云服务，我们在其上托管了所有虚拟主机上的计算资源，并且可以通过互联网获取。

云服务包括基础设施即服务（Infrastructure as a Service，IaaS）、平台即服务（Platform as a Service，PaaS）和软件即服务（Software as a Service，SaaS）这3种类型。

• 基础设施即服务：它基本上是基于物理计算机的云变体。实际上它通过在网络上运行的虚拟化层取代了实际机器、服务器和硬件存储以及网络。IaaS允许读者构建整个虚拟基础设施，其实质是模拟实际硬件的软件。
• 平台即服务：一旦解决了硬件虚拟化部分，下一个显而易见的步骤是考虑在原始计算机硬件上操作的下一层。这是一个将程序和组件绑定在一起的组件，如数据库、服务器、文件存储等。例如，在这里，如果数据库作为PaaS公开，那么程序员可以将其用作服务，而不必担心存储容量、数据保护、加密、复制等较低级的细节。PaaS的著名例子是Google App引擎和Heroku。
• 软件即服务：这一层是云计算栈中的最上层，实际上是提供解决方案作为服务的层。这些服务是按每个用户或每月来收费的，这种模式确保最终用户可以灵活地注册和使用服务，而无须支付任何许可证费用或锁定时间。一些广为人知的典型例子是Salesforce Customer 360平台和Google App。

现在我们已经了解并熟悉了云，接下来需要理解的是云计算究竟意味着什么，为什么说“云的出现正在拉下传统数据中心时代的帷幕”。再来了解一下云计算的一些关键优点——这实际上使这个平台成为NRT和物联网应用程序的核心。

云服务是按需的。用户可以根据需要和负载提供计算组件/资源。在未来的若干年里，我们没有必要在基础设施上进行巨额投资，也没有必要进行规模化投资，而是可以提供一个足以满足当前需求的集群，然后在需要时通过请求更多的随需应变实例来扩展集群。因此，人作为用户所得到的保证是，在需要一个实例时，会得到一个相同的实例。

云服务允许构建真正有弹性的应用程序。这意味着根据负载和需求，部署可以扩容和降容。这是一个巨大的优势，而且基于云的方式有着很高的成本效益。如果用户有一个应用程序在每个月的第一天流量出现偶发性激增，那么，在云环境下，用户就不需要在30天内都提供满足第一天流量激增需求所要配备的硬件。相反，用户可以提供平均一天所需的资源，并构建一种机制来扩展自己的集群，以满足第一天的激增，然后在每月的第二天自动缩至平均大小。

这就是回报。这是云最有趣的特点，它击败了传统硬件供应系统——建立一个数据中心时，必须预先规划金额巨大的投资。在云数据中心环境下，用户不需要这样的成本，只为正在运行的实例付费就够了，而这种付费通常是按小时计算的。

1.8　小结

在本章，我们主要概述了大数据技术的整体面貌，以及大数据作为基础设施和大数据分析的前提意义。我们向读者介绍了在设计和决定大数据基础设施时需要考虑的各种因素和注意事项，还揭开了实时分析和NRT架构的真实面纱，并给出了一些可以利用物联网和NRT解决问题的案例。在本章的最后，我们简要介绍了物联网的边缘计算和云基础设施的概念。

在第2章，我们将带领读者更深入地了解实时分析应用程序、概念与架构，讨论NRT应用程序的基本构建模块、所需的技术栈以及开发时可能遇到的挑战。

第2章　实时应用的基本组件

本章将带领读者熟悉近实时系统的基本构建模块，向读者介绍这些应用的高级逻辑、物理原理和技术视图，并将涉及系统中每个构建模块的技术选型。

本章主要包括以下内容

• NRT系统及其构建模块
• 数据采集
• 流处理
• 分析层—服务终端用户
• NRT的高级系统视图
• NRT的技术视图

2.1　NRT系统及其构建模块

本章读者遇到的首要问题可能是“什么时候应该将应用程序称为NRT应用程序？”简单来讲，一个能够非常接近实时地进行消费、处理和生成结果的应用程序可以称为NRT应用程序，也就是说，从事件发生到结果产生的时间间隔非常小，量级从几纳秒到最多几秒。

传统的单体应用无法满足NRT应用系统的需求，原因主要有以下几个关键点。

• 后端数据库：单点单体数据访问。
• 摄入流：管道复杂，容易导致端到端流的延迟。
• 故障与恢复：系统容易发生故障，恢复方法困难、复杂。
• 同步和状态捕获：捕获和维护系统中的事务状态非常困难。多样化的分布式系统和实时系统故障的出现使得这类系统的设计和维护变得更加复杂。

解决上述问题的方案之一是以流式传输为架构，从而基于源源不断的实时数据流使终端用户能够实时看到一些实用的结论。设计流处理系统需要考虑几个挑战，并在以下几点中加以说明。

• 大规模高速系统的局部状态和系统的一致性。
• 数据不会按相同时间间隔到达，它不断流入，并且一直在流式传输。
• 后端数据库没有单一的事实状态，而是应用程序订阅或利用事实数据流。

在进一步深入研究之前，我们有必要先来了解一下时间表示法，如图2-1所示。

图2-1

图2-1已经非常清楚地将SLA与每种实现类型（批处理、近实时和实时）以及每个实现所满足的用例类型关联起来。例如，批处理实现的SLA范围从几小时到几天不等，这些解决方案主要用于封闭/预生成报告和趋势预测。实时解决方案具有几秒到几小时的SLA量级，可满足需要AdHoc查询、中等分辨率的聚合器等场景。在SLA方面，实时应用程序是最关键的任务，分辨率是每个事件的计数，其结果必须在事件发生后的毫秒到秒量级延迟后返回。

了解了NRT、实时和批处理系统的时间维度和SLA后，接下来我们讨论了解NRT系统的构建模块。

本质上，它由消息传输管道、流处理组件、低延迟数据存储以及可视化和分析工具这4个主要组件/层组成，如图2-2所示。

图2-2

先从源中收集数据并将其提供给数据管道，实际上这是一个逻辑管道，它从不同的生产者收集连续事件或流数据并将其提供给消费者的流处理应用程序；然后这些应用程序对这些实时流数据进行转换、整理、关联、聚合和执行各种其他操作，再将结果存储到低延迟数据存储中；最后各种分析、商业智能、可视化工具和仪表板从数据存储中读取这些数据，并将其呈现给商业用户。

2.1.1　数据采集

这是所有数据处理过程的开始。无论是批处理还是实时处理，最主要的挑战是将数据从源处获取到系统中以进行处理。读者可以将处理单元视为一个黑盒和一个数据源，并将消费者视为发布者和订阅者。数据采集的整个过程如图2-3所示。

图2-3

在大数据和实时应用的背景下，衡量数据收集工具的关键指标有：性能和低延迟、可扩展性以及处理结构化和非结构化数据的能力。

除此之外，任何数据收集工具都应该能够接收各种来源的数据，示例如下。

（1）来自传统跨国系统的数据：在考虑软件应用时，了解到业内长期以来一直应用传统数据库收集和整理数据。这些数据可能是磁带、Oracle、Teradata、Netezza等上的顺序文件。因此，从实时应用程序及其相关数据收集开始，系统架构有如下3个选项。

• 复制这些传统系统中的ETL过程并从源处获取数据。
• 从这些ETL系统中提取数据。
• 第三种更好的方法是使用虚拟数据池体系结构复制数据。

（2）来自物联网/传感器/设备或CDR的结构化数据：这是以非常高的速度和固定格式传输的数据，数据来自各种传感器和电信设备。数据收集/接收的主要复杂性或挑战是数据的多样性和到达速度。收集工具应该能够处理多样性和速度方面的问题，但是对于上游处理来说，这种数据的一个优点是格式非常标准和固定。

（3）来自媒体文件、文本数据、社交媒体等的非结构化数据：这是所有传入数据中最复杂的一种，其复杂性是由体量、速度、多样性和结构等方面决定的。数据格式可能差异很大，可能是非文本格式，如音频/视频等。数据收集工具应该能够收集这些数据并将其同化以进行处理。

2.1.2　流处理

流处理组件本身包含如下3个子组件。

• 代理程序：从数据收集代理上收集和保存事件或数据流。
• 处理引擎：实际转换、关联、聚合数据并执行其他必要操作。
• 分布式缓存：实际上是在处理引擎的所有分布式组件中维护公共数据集的机制。

流处理组件的相似点被放大，如图2-4所示。

流处理组件应该满足几个关键属性。分布式组件可以提供故障恢复能力；可扩展性可以满足不断增长的应用程序需求或突发的流量激增；处理此类应用程序预期的总体SLA的低延迟；易于操作的用例可以支持不断发展的用例；为故障而构建，系统能够从不可避免的故障中恢复，而不会造成任何事件损失，并且能够从故障点处重新开始处理；易于集成堆外/分布式缓存或数据存储；各种各样的操作、扩展和功能可以满足用例的商业需求。

图2-4

在为流处理应用程序/框架选型时，基本上可以参考以上这些属性。

2.1.3　分析层—服务终端用户

分析层是NRT应用程序所有组件中最有创意，也是最为有趣的一部分。截止目前，我们所讨论的都是后端处理环节，但是本节所要介绍的组件将以可视化以及易操作的形式向终端用户展示输出/见解。

作为解决方案的一部分，数据可视化技术选型中最关键的一点是，如何以一种使预期目标受众容易理解并基于此做出某种行动的方式来呈现信息。仅仅对数据进行智能处理并获得可行的见解是不够的，必须接触到参与者，无论他们是人类还是一些流程。

在深入研究商业智能的本质和可视化组件的细节之前，不妨先了解一下大数据和高速NRT/RT应用程序给问题混合带来的挑战。

这些可视化系统能够应对的一些挑战如下。

• 对速度的需求：世界在不断发展和合理化，现在越来越多的公司倾向于实时分析，以在竞争中获得优势。因此，可视化工具应该能补充其所属应用程序的速度，以便能够快速地以有意义的形式描述和呈现关键参与者的准确事实，从而做出明智的决策。
• 理解数据并在正确的背景下呈现：有时，相同的结果需要进行不同的调整和呈现，这取决于所迎合的受众。因此，该工具应该提供这种灵活性，并能够以最有意义的形式围绕可操作见解设计一个可视化解决方案。例如，如果读者正在绘制城市中的车辆位置，那么可能需要使用热力图，其中颜色差异表示车辆的浓度/数量，而不是在图上绘制每辆车辆。当读者呈现出特定航班/船舶的行程时，可能不希望合并任何数据点，并将它们都绘制在图表上。
• 处理离群值：图形数据表可以轻松地表示趋势和离群值，从而使终端用户能够发现问题或找出需要注意的点。一般来说，离群值是数据的1%～5%，但在处理大量数据时，5%的总数据是巨大的，可能会导致绘图问题。

图2-5描述了整个应用程序的流程和一些流行的可视化方法，包括Twitter热力图。

图2-5

该图描述了从事件生产者到收集代理的信息流，紧接着是代理和处理引擎（转换、聚合等），然后是长期存储。可视化工具从存储单元中获取分析结果，并以图形、警报、图表、Excel表、仪表板或地图的形式将其呈现给商业所有者，这些所有者可以分析信息并根据信息采取一些行动。

2.2　NRT的高级系统视图

在本章前面，我们特意给读者讲解了NRT应用程序的基本构建模块及其逻辑概述。下一步是理解NRT框架的功能和系统视图。图2-6清楚地概述了各种体系的构建模块和贯穿各领域的问题。

图2-6

从图2-6中可以看到由左到右的横向流程，整个过程从使用低延迟组件数据提取和转换开始，它是近实时的，转换后的数据被传递到下一个逻辑单元，该逻辑单元实际上对数据执行了高度优化和并行操作—该单元实际上是近实时处理引擎。一旦数据被聚合和关联，并且得到了可行的分析结果，那么它就被传递到表现层。与实时仪表板和可视化工具组合在一起，表现层可能有一个持久性组件，以用于长期深入分析保留数据。

如图2-6所示，NRT框架所有组成部分中贯穿各领域的问题包括安全、系统管理以及数据完整性和管理。

接下来，我们将带领读者了解4种基本的流处理模式，帮助读者了解流处理用例构成的常见风格及最佳解决方案（见本章后续内容）。

• 流提取：在这里，我们所要做的就是将事件持久化到稳定的存储中，如HDFS、HBase、Solr等。所以需要的只是低延迟的流收集、转换和持久性组件。
• 近实时（NRT）处理：此应用程序设计允许有外部上下文，并处理异常或欺诈检测等复杂用例。它需要根据特定的复杂业务逻辑对事件进行过滤、警报、重复数据消除和转换。所有这些操作都需要在极低的延迟下执行。
• NRT事件分区处理：这与NRT处理非常接近，但是有一个变化可以帮助它从分区数据中获得好处，从而引用一些实例，这就像在内存中存储相关的外部信息。这种模式也应在极低的延迟下运行。
• NRT和复杂模型/机器学习：它主要要求我们在流事件集的滑动时间窗口上执行非常复杂的模型/操作。它们是高度复杂的操作，需要对数据进行微批，并且要求操作延迟非常低。

2.3　NRT的技术视图

在本节中，我们将向读者介绍NRT组件的各种技术选型及其在特定情形下的优缺点。随着本书的进展，之后我们将更详细地介绍这些内容，以帮助读者理解为什么某些工具和技术栈更适合解决某些用例。

在此之前，我们有必要了解一些关键的相关工具和技术。这里提到的工具和技术对于软件来说是通用的，我们稍后将继续讨论NRT工具的细节。

• 性能：基本上它是在给定负载和给定硬件环境下测量软件组件的性能。
• 容量：这一点非常关键，因为它决定了任何应用程序的断点。
• 管理：组件的管理烦琐吗？是否需要专业工程师来维护？
• 可扩展性：组件是否可扩展，以适应不断增加的流量和新的用例？能在同一个体系上演进吗？
• 总拥有成本（TCO）：端到端解决方案所需的总成本。

既然有了经验法则，那么让我们看看NRT应用程序框架的技术视图，了解相关的技术选型，如图2-7所示。

图2-7展示了NRT框架在设计解决方案时的各种关键技术，下面我们进一步了解每个技术环节及其候选的技术选择。

图2-7

2.3.1　事件生产者

事件生产者是事件发生的源头。这些单独的事件或元组以连续永不结束的流串接，形成数据流，这些数据流作为任何NRT应用程序系统的输入源。事件可以是以下任意一个或多个事件，并且可以实时触发。

• 应用程序、电信日志或者CDR。
• Facebook、Twitter或者其他社交媒体。
• 传感器或者卫星产生的数据。
• 闭路电视或者安全摄像头的视频。
• 图像、自由文本、结构化、半结构化、非文本（音频、视频）、JSON、XML等格式的数据。

2.3.2　数据收集

既然已经确定了数据的来源及其特征和到达频率，接下来考虑将实时数据导入应用程序中的各种收集工具。各种数据收集工具的比较见表2-1。

表2-1

（1）Apache Flume：Flume是一种分布式、高可靠和高可用的服务，用于高效地收集、聚合和移动大量日志数据。它有一个简单且灵活的基于数据流的体系结构，具有鲁棒性和容错性、可维护性、可靠性机制以及故障转移和恢复机制。它使用一个简单的可扩展数据模型，允许在线分析应用程序。Flume的主要特点如下。

• 简单地读取流数据，具有内置故障恢复功能。通过内存和磁盘信道处理激增或峰值数据，而不会影响下游处理系统。
• 消息传递有保障：它有一个内置的信道机制，可以在确认上工作，从而确保传递消息。
• 可扩展性：与所有其他Hadoop组件一样，Flume很容易水平扩展。

（2）FluentD：FluentD是一个开源数据采集器，统一数据收集和消费，以便更好地使用和理解数据。FluentD的显著特点如下。

• 可靠性：此组件同时具有基于内存和文件的信道配置，可以根据所需用例的可靠性需求进行配置。
• 基础架构采用底层语言编写：组件用Ruby和C编写，内存和CPU消耗非常少。
• 可插拔架构：该组件为社区的不断发展做出了贡献。
• 使用JSON：它将数据尽可能地统一为JSON，从而使统一、转换和筛选变得更容易。

（3）Logstash：Logstash是一个开源的服务器端数据处理管道，它同时从多个源接收、转换数据。它的显著特点如下。

• 多样性：支持各种各样的流数据输入源，包括从度量到应用程序日志、实时传感器数据、社交媒体数据，等等。
• 过滤输入数据：Logstash具备超低延迟的分析、过滤和转换数据的能力。在某些情况下，我们可能希望在登录到代理或存储之前，对来自各种源的数据进行筛选，并按照预先定义的通用格式进行解析。这使得整体开发过程分离，并且由于它收敛到通用格式而易于使用。它能够格式化和解析非常复杂的数据，并且整个处理时间与源、格式、复杂性或模式无关。
• 可以将转换后的输出统一收集到各种存储、处理或下游应用系统（如Spark、Storm、HDFS、ES等）中。
• 良好的鲁棒性、功能强大且可扩展：开发者可以选择使用各种各样的可用插件或编写自定义插件。插件可以使用名为插件生成器的Logstash工具开发。
• 监控API：开发人员能够利用Logstash集群并监控数据管道的整体运行状况。
• 安全性：有提供动态加密数据的能力，以确保数据安全。

（4）用于数据收集的云API：这是另一种数据收集方法，大多数云平台都提供各种数据收集API，例如，亚马逊Kinesis Firehose、Google StackDriver监控API、数据收集API和IBM Bluemix数据连接API。

2.3.3　代理

组件分离是一个基本的架构原则。代理恰恰是NRT体系结构中的一个组件，它不仅将数据采集组件和处理单元分离开，还提供了在流量突然激增时将数据保留在队列中的弹性。

在本节中，我们介绍的各种工具和技术主要如下。

（1）Apache Kafka：Kafka用于构建实时数据管道和流式应用程序。它具有水平可扩展性、容错性和非常快的速度，并已在数千家公司的生产中运行。这个代理组件的显著特性如下。

• 高可扩展。
• 故障安全。
• 提供容错性和高可用性。
• 开放源代码和可扩展。
• 它是基于磁盘的，可以存储大量数据（这是Kafka的一个USP，实际上可以满足任何数量的数据）；允许数据的复制和分区。

（2）ActiveMQ：Apache ActiveMQ速度快，支持多种跨语言客户端和协议，具有易于使用的企业集成模式和许多高级功能，同时完全支持JMS 1.1和J2EE 1.4。Apache ActiveMQ根据Apache 2.0许可证发布。该协议的主要特点如下。

• 支持多种客户端和协议。
• 支持JMS 1.1和J2EE 1.4。
• 高性能。
• 支持持久性。
• 公开了与技术无关的Web服务层。

（3）RabbitMQ：这是一个具有持久性、低延迟的位于内存中的分布式队列系统，具有以下显著功能。

• 鲁棒性。
• 易于使用。
• 支持所有主要操作系统。
• 既有开源版本，也有商业版本。

其中RabbitMQ和Apache Kafka的对比，即两种消息队列组件的对比见表2-2。

表2-2

2.3.4　转换和处理

转换和处理是NRT框架的核心，所有处理实际上都在这里执行，从数据转换到复杂的聚合和其他操作。

可供选择的组件有Apache Storm、Apache Flink和Apache Spark。在接下来的章节中，我们将对它们进行详细的探讨。这些具备可扩展、分布式且高可用的NRT核心框架的特性对比见表2-3。

表2-3

2.3.5　存储

首先，我们需要将中间或最终结果和警报写入稳定的存储空间。存储是NRT应用程序中非常重要的组件，因为我们需要将最终结果进行持久化存储。其次，它是下游应用程序的集成点，这些应用程序从这些低延迟存储中提取数据，并对它们进行进一步的洞察或深入的学习。

图2-8清楚地表示了各种数据存储及其与NRT应用程序的时间SLA的一致性。

虽然现在跳过了大量可用于存储和可视化的选择方案，但我们将在本书的后面具体介绍这些选择方案。

图2-8

2.4　小结

在本章，我们介绍了NRT体系结构框架的各种组件和技术选型。读者了解了实时处理的挑战、要考虑的关键方面以及堆栈中每种技术可用的USP。这里的目的是让读者从概念上熟悉可用工具和技术栈选择，以便根据功能性和非功能性需求，选择最适合用例的解决方案。