启动物联网项目所需的一切：第 1 章
原文作者：William Vorhies
原文地址：https://dzone.com/articles/iot-101-everything-you-need-to-know-to-start-your
简介： 这是本系列教程中的第一篇，旨在帮助读者围绕物联网或流处理系统的技术问题建立完整的基础和多方面的理解，以便读者在规划物联网系统时能够做出明智的决策或是有根据地提出问题。
在和刚开始着手物联网数据流处理项目的客户和潜在客户进行交谈的时候，我了解到他们的知识都显然存在着很多误解以及分歧。现在有关物联网的文章随便找都能找到好几百篇，但它们都不可避免地局限于物联网这一整体的某个细分领域，而没什么文章来介绍一个具有普遍意义的知识背景或者基础。这是可以理解的，毕竟光就物联网这一话题的范围就非常广泛，以至难以总结，更不用说这一领域的瞬息万变了。
所以我们的意图就是帮助开始考虑流处理和物联网的人们建立多方面的基础。我们将从基础知识入手，并介绍一些更高级的主题，希望能够为读者提供足够的信息，让读者能够开始设计项目细节，或者至少能提出好的问题。
由于这是一个很宽泛的话题，所以我们会把它分为几个章节来讲，旨在立足于基础，然后在逻辑上为每块内容逐渐添加细节。
是叫物联网，还是叫流处理？
我们需要为初学者厘清的第一件事是术语。现在 “物联网（IoT，Internet of Things）” 和 “流处理（Streaming）” 这两个术语不仅能用来表示不同的事物，还能用来表示同一事物的部分内容。而我们界定物联网的范围的核心差异在于：如果系统的输入信号来自于传感器，那就属于物联网的范畴。信号并非来自传感器的情况有很多，不过处理非传感器信号的方法本质上也和处理传感器信号的方法一样。网络日志、点击事件流、来自社交媒体的文本流还有股票价格数据流都是非传感器数据流的例子，而它们都不属于物联网的范畴。
不过，不管信号是不是来自传感器，所有的数据其实都是在数据流中运动的数据（data-in-motion）。流处理是这两者在事实上共有的核心概念，我们也可以简单地将它设想为 “事件流处理”。不过除了流处理之外，此前设想的场景的整个架构里面还有一些其他的核心要素，比如数据的采集、存储，以及查询。
就架构而言，流处理这一部分只是我们在此讨论的四个核心要素之一。稍后我们还会讨论这样一个事实：尽管数据可以用流处理的方式来处理，但在一些情况下你其实不需要用到流处理，而这取决于你定义 "实时" 的方式。这一点咋一看让人一头雾水，不过我们会在后面详细说明这点。
无论数据源是不是特定的传感器，所有类型的流数据的处理过程所需的架构基本上是相同的，我们将把这种架构称为 “物联网体系结构（IoT Architecture）”。从这里开始，本文的讨论将会把重心放在架构上。如果你仍然不清楚流处理的基本概念，那么不妨从这些概述开始了解一下：
物联网体系结构的基础知识：开源方案
大数据领域的开源方案已经成为创新的巨大推动力。正因为这点，在网上的八成左右的可用资料都会涉及一些开源的用来处理数据的元素或包的使用。远近闻名的 Apache 基金会更是几乎成了开源的代名词。因此，要想了解物联网体系结构的基础知识，首先就应该关注开源的工具和软件包。
如果你想要完全熟悉物联网，那么有关 SPARK 和 Storm 这两个 Apache 的主流开源流处理项目的内容的学习是绕不开的，而这些还仅仅只是整体架构的一部分。此外，在本系列文章后面的部分，我们会把注意力转向一些新兴的、享有专利的非开源选项，还会讨论一下在什么情况下你会需要考虑它们。
本文讨论的物联网架构将由四个部分组成：数据采集，流处理，存储和查询。在一些你可能会选择的特定架构方案里面，其中一些过程可能会合并在一起，但在接下来讨论开源方案的时候，我们会假设它们是分开的。
数据采集
不妨将数据采集组件看作针对所有传入数据源（传感器、网络资源流、文本、图片，还有社交媒体）的一件捕手手套。数据采集应用程序会需要做到：
- 能够尽可能快地采集来自所有数据源的数据。拿数字广告来说，每秒百万级别的事件量是很常见的。某些应用的事件发生的频率会更高。虽然大家自己写的应用本身不太可能会达到这个水平，但是若能想象一下接入一百万个每秒传一遍数据的传感器的场景，那也差不多能体会到了。
- 绝不能丢掉事件。传感器会传来尤其多不能用的 “脏数据“。这可能是由于故障、老化、信号漂移、连接问题，或由于各种别的网络、软件，和硬件问题而引起的。根据你的使用场景，你可能会就此丢掉一些数据，但我们的假设是你不想丢掉任何数据。
- 易于扩展。你的数据采集应用要能跟得上数据量的增长。这意味着它将是一个在集群上运行的分布式应用程序。接下来讨论的物联网体系结构的其他组件其实也是如此。
在流里面处理的数据是一段基于时间的序列，因此这种数据至少会含有三种信息：记载其生成时刻的时间戳、传感器或别的类型的数据源的 ID，以及在相应时间的读数。
在稍后你会见到把在数据流里的数据和静态数据（比如应用的用户数据）结合起来的工作方式，不过这就是另外一个组件的事了。
为什么会需要一个数据采集器？
包括 SPARK 和 Storm 在内的许多流处理应用都可以直接接收数据，而无需一个单独的数据采集器作为直接接收数据的前端。但是，如果分布式集群里面的某个节点出现了故障，那么相应的数据能不能恢复就没办法保障了。由于我们做了你的业务需要保存所有传入数据的假设，因此为了设计一个安全的架构，就需要一个数据采集器作为直接接收数据的前端，以便在故障发生前能临时保存数据，并且在故障发生时能把数据重新发送一遍。
数据采集器的开源选项
你能从很多开源方案里面挑一个来用。这里有一部分比较著名的数据采集器：
- FluentD —— 通用多源数据收集器。
- Flume —— 大规模日志聚合框架。Hadoop 生态系统的一部分。
- MQ（比如 RabbitMQ）—— 从 IBM 的 MQTT（消息队列遥测传输，缩写为 MQ）里面派生出来的轻量级消息代理。
- AWS Kinesis —— 其他一些主流的云服务也提供了开源的数据收集器。
- Kafka —— 分布式队列发布 - 订阅系统，能用于应对大量流处理数据。
Kafka 是目前最流行的选项
Kafka 并非唯一的选择，但它是当今最流行的选择。LinkedIn，Netflix，Spotify，Uber 还有 Airbnb 等公司都在用。
Kafka 是一种分布式消息传递系统，旨在增强对硬件、软件以及网络故障的承受能力，并使得部分处理失败的数据能基本上得到找回并且重发，从而为系统提供其所必需的安全性。Kafka 最初在 2011 年由 LinkedIn 推出，以其能处理非常高的吞吐量，以及其易于扩展的特点而闻名。
如果你的数据流不需要做其他处理，那么它可以直接通过 Kafka 传递到数据存储端。
存储
这有一个能简单快速地评估你所需的存储空间的方法。比如可以按这样来算：
传感器数量： 1 百万
信号频率：每 60 秒 1 次
数据包大小： 1 Kb
每个传感器一天产生的事件数： 1,440
日总事件产生数： 14.4 亿
秒事件数： 16,667
日数据量：每天 1.44 TB
你的系统会用到两种类型的存储器：“永久” 存储和 “快速” 存储。
快速存储的意义在于在数据流经流处理平台之后，或者还在流处理平台的时候能够实时找到这一数据。你可能需要能在数毫秒内在 “快速存储” 中找到你想要的数据，以便能将这一数据或者它的内容加入到你的流处理平台里面的其他数据流里，比如在最近 24 小时内（或最近一月内）传感器 X 的最小（最大，抑或是平均）的读数。数据能在快速存储里面存多久就取决于具体的业务需求了。
永久存储的意义并非一定是永远保存数据，你的数据要保留多长时间需要由你来进行准确的评估。数据的存储时限可以是永久的，也可能只有几个月或几年。永久存储会为你所实现的、能在流处理平台中检测信号的高级分析和预测模型提供支持，也会为特殊的批量查找提供支持。
囿于速度，成本和规模方面的限制，RDBMS（关系型数据库管理系统）无法满足这些需求，而有些版本的 NoSQL（非关系型数据库）就实现了这两种存储功能。
考虑成本
在选择存储平台时，想必你会担心其可扩展性和可靠性，同时也会担心它们的成本。不妨了解一下 Hortonworks 提出的这个对比：
对于内部存储，Hadoop 集群将是一个具有低成本以及最佳可扩展性 / 可靠性的选项。现在在谷歌，亚马逊和微软这些云服务供应商那里，基于 Hadoop 的云存储每 GB 每月只卖 1 美分。
存储系统的开源方案选项
我们得再停下来解释一下 “Hadoop” 这个东西。很多时候，在你读过的提到 “Hadoop” 的大部分内容里面，作者所指的都是由能在 Hadoop 上运行的软件包所组成的整个生态系统。
从严格的意义上来说，Hadoop 本身由三个元素构成。这三个元素是它作为数据库运行的最低要求。它们是 HDFS（Hadoop 文件系统，决定数据的存储方式）、YARN（调度程序）还有 Map / Reduce（查询系统）。“Hadoop”（此指三个组件合为一体的数据库）适用于批量查询，不过在最近基于运行在 HDFS 的 SPARK 的新项目已经大大地超越了基于 Hadoop 的项目，其中前者具有速度更快的查询方法。
HDFS 方面的基础真的应该关注一下。尽管对 HDFS 还有一些开源的替代方案，比如 S3 还有 Mongo 都是可行的选择，但是在这方面的存储方案的实现几乎全都是基于 HDFS 的 NoSQL 数据库系统。比如：
- Hbase
- Cassandra
- Accumulo
- SPARK
- 还不止这些
我们之前提到过，RDBMS 因为各种原因而在这一方面并无竞争优势，其中最重要的原因在于它要求在写入数据时定义模式（schema-on-write），而 NoSQL 能在读取数据时定义模式（schema-on-read，或 late schema），比前者更加灵活。不过如果你非要用 RDBMS 不可，那就应该尝试一下 NewSQL 方面的新项目，而这些项目便是具有 NoSQL 大多数优点的 RDBMS。如果你不熟悉这些东西，不妨看看这些文章：这篇，这篇，还有这篇。
查询
物联网流处理系统的目标一般是实时发现对其用户 / 客户有价值的特定事件。在任何特定时刻，你的系统都将包含两种类型的数据：
- 在数据流中的数据（data-in-motion），因为它们会流经你的流处理平台。
- 在存储系统里面的静态数据（data-at-rest），其中有些存在于快速存储里，有些会存在于永久存储中。
有两种类型的活动会需要你去查询平台里面的数据：
实时输出：如果你的目标是向人或机器发送操作消息，或者是将数据发送到需要实时更新的仪表板上，则可能需要查询存储信息来改善流数据的表现形式。这一活动的一种常见类型是引入静态的用户信息。例如，在数据流流经流处理器时向数据流添加静态的用户数据就可以增强预测信号的能力。这一活动还有一种类型，那就是扩展信号种类。就比如若你的传感器发来了某个机器的读数，你可能需要将其与同类传感器的一些统计量进行比较，比如在最后一分钟或最后一个月时间内的平均值、最小值、最大值。
需要实时输出的数据将会存储在快速存储里面，其查询要在几毫秒内完成。
分析型查询：物联网系统一般很可能会包含一些用于对数据进行评分，以预测人或机器的行为的复杂的预测模型。在物联网领域里面，预测分析模型的开发遵循着传统的两步数据科学过程：首先分析并建模已知数据以创建预测模型，然后将该模型的代码（或 API）导出到流处理系统中，让这一预测模型能对输入到其中的数据进行评分。永久存储的数据会是让这些预测分析模型得以开发的基础。你可以使用对响应时间要求较低的批量查询来提取这部分数据来进行分析。
查询系统的开源方案
在 HDFS Apache 生态系统中，有三个查询系统的开源方案选项。
- Map / Reduce：这一方案是 Hadoop 数据库的三大支柱之一，并且也是存在时间最长的一大支柱。不过即便在最近有些 Apache 项目（如 Pig 和 Hive）在试图改善这点的前提下，用它来编写程序也还是会很复杂。在批量查询的模式下，就对响应时间要求不高的的分析型查询而言，传统 Hadoop 集群上的 Map / Reduce 就能做得很好，并且可以在几分钟到几小时内返回大规模查询的结果。
- SPARK：Hadoop Map / Reduce 的地位正在被基于 HDFS 的 SPARK 所取代 ，因为后者的查询速度比前者提高了 10 倍到 100 倍（取决于数据是在硬盘还是内存上）。如果你在你的流处理平台上使用了 SPARK，那么把它用于平台内的实时查询也是很有意义的。使用 SPARK 可以实现毫秒级别的延迟，具体会取决于存储器以及其他硬件方面的因素。
- SQL：在传统意义上，NoSQL 这一名字来源于像 Hadoop 这样不能用 SQL 来查询的数据库设计。不过，很多人用起 SQL 来都很舒畅，但用起那些相对含糊的 Map / Reduce 查询就很不舒畅了。也因为这样，很多人一直都希望这样的数据库能开发使用 SQL 查询的功能。现在，SQL 查询在这些 HDFS 数据库上已经成了常见的标配，以至于连 NoSQL 这一形容这一事物的名词也变得不那么严谨了。然而，所有这些 SQL 查询的实现都需要某种转换器作为中介者，而中介者的引入让 SQL 通常都不适合用于实现毫秒级的查询。不过，它们确实可以让你的没用传统模式存储的数据可以开放给任何具有 SQL 技能的分析师和数据科学家。
接下来请关注第 2 还有第 3 章。
Bill Vorhies 是 Data Science Central 的编辑总监，自 2001 年起担任数据科学家和商业预测建模师。本文首次出现在 Data Science Central。
