启动物联网项目所需的一切：关于流处理

欢迎大家前往腾讯云+社区，获取更多腾讯海量技术实践干货哦~

在本文中，我们将围绕物联网或流处理系统的一些技术问题建立完整的基础和多方面的理解，以便读者在规划物联网系统时能够做出明智的决策或是有根据地提出问题。我们的意图是为开始考虑流处理和物联网的人们建立多方面的基础，不管你是否真的需要一个流处理器，我们都将深入到流处理（物联网的核心）里面，然后讨论 Lambda 架构，并给出一些对传感器可以做什么的大致上的思考。

流处理的开源框架

事件流处理平台就像把瑞士军刀，你可以让在数据流里运动的数据（data-in-motion）做几乎任何你想做的事情。
了解 ESP 体系结构的最简单的方法是将其视为三个层面或三个功能 —— 输入，处理和输出。

输入层会接受几乎所有类型的基于时间的流数据，并经常有存在多个输入流的情况。在主 ESP 处理器中会发生各种会被称为程序或操作的动作。这些程序的结果会传递给订阅者的一些接口，后者可以通过人机界面发送警报或创建机器来进行自动操作，并将数据传递给像 Fast 和 Forever 这样的数据存储服务里。

流处理平台确实可以直接接收数据流，但要注意他们并不善于保存一些会意外丢失的数据，因此你仍然会需要像 Kafka 这样的一个能够回退并重放丢失的数据的数据采集端。在不久的将来，很多流处理器可能会解决这个问题，然后你就需要重新考虑 Kafka 端的必要性了。

流处理的要求

对流处理器常会有这些要求：

• 高速：视具体具体业务需求而定，通常每秒要能采集并处理数百万个事件。
• 易扩展：全部东西都要在分布式集群上运行。
• 容错：这与保证不丢失数据不同。
• 确定处理：这有两种做法：每个事件至少处理一次，和每个事件正好处理一次。不过 “正好处理一次”
  的标准很难保证。这是我们将放在稍后讨论的一个深入的主题。
• 能执行你的应用程序运行的必需程序

ESP 程序能做什么？

在采集端进行数据清理的能力（类似于一种迷你 MDM）是其功能强大的真正体现。在数据清理之后会多次复制数据流，以便每个相同的数据流可以同时用于不同的分析程序中，而不用让这些程序程序排队等待前面的分析程序完成分析。下面是一个医疗业务示例的图表，该示例描述了一种在上一章提到过的工作方式，说明了多个数据流会由静态数据来扩大，并会由不同类型的逻辑同时处理。每个块都表示了在 ESP 中需要由你来编写的单独程序。

有很多不同类型的逻辑可以通过这些 ESP 程序来得到应用，包括：

• 计算
• 复制，建立多个处理路径 —— 每个处理路径具有不同的保留时间，例如 5 - 15 分钟。
• 统计
• 计数
• 过滤，它让你能只从数据流中保留有用的数据，并放弃其余数据，从而大大减少存储空间。
• 函数（用于变换）
• 合并多个流为一个
• 通知性质的电子邮件，文字或多媒体形式
• 模式（特定关注事件的 EOI，用于检测）
• 流程（用于应用高级的预测模型）
• 文本内容，用于检测例如受关注的推特模式这样的信息。
• 文本情感，用于监控社交媒体流中的积极或消极的情绪。
• 开源的和专有的软件包在能做的工作上都有着一些区别，因此你应该根据你所需要完成的东西来核对这些软件包的内容。

流处理的开源选项

主要的开源框架选项（全是 Apache 的）如下：
Samza： 一个分布式的流处理框架。它使用 Kafka 来进行消息传递，由 YARN 来提供容错性、处理器隔离、安全性，以及资源管理。
NiFi：这是一个相当新兴的开源项目，仍处于完善之中。它与其他项目的区别在于它有用户友好的拖曳式的图形界面，以及我们可以轻松地根据特定需求来对它进行定制。
Storm：一款经过充分测试的基于事件的流处理器。它最初由推特开发。
SPARK Streaming： SPARK Streaming 是 SPARK 的四个组成部分之一，它是第一个能在单一企业级平台上整合批量处理和流处理的组件。

SPARK 流媒体和 Storm：最常见的开源软件包

SPARK 已被推出好几年了，但在去年它的使用率有了惊人的增长，现已在大多数新项目中取代了 Hadoop / MapReduce 的地位，并且许多既有的 Hadoop / MapReduce 系统也都迁移到了 SPARK。SPARK 的开发工作正在朝着成为物联网应用所需的唯一技术栈发展。

SPARK 由五个组件组成，所有这些组件都支持 Scala，Java，Python 还有 R 语言。

1. SPARK：作为一个在系统中处于核心地位的应用程序，它是一个与 HDFS 和其他 NoSQL DB 兼容的批处理引擎。它能比Hadoop / MapReduce 快 10 倍到 100 倍，因此它十分流行。
2. ML.lib：一个自带的功能强大的数据科学以及机器学习算法库。
3. SPARK SQL：用于直接支持 SQL 查询。
4. SPARK Streaming：SPARK 集成的流处理引擎。
5. GraphX：强大的图形数据库引擎，可用于流式应用程序之外。

相比之下，Storm 就是一个纯粹的事件流处理器。Storm 和 SPARK Streaming 之间的差异不大，不过它们为传入数据分区的方式便截然不同了。这是后面讨论的一个进一步的话题。

如果你已经熟悉了关于数据分区的知识并且确定这不会对你的应用造成损害，那么开源的 SPARK / SPARK Streaming 便是最好的选择。

Lambda 架构：速度加上安全

IoT 流处理应用的标准参考体系结构被称为Lambda 体系结构，该体系结构包含一个加速层（Speed Layer）和一个安全层（Safety Layer）。

传入数据流会由数据采集应用（Kafka）复制，并朝两个方向发送，一个是安全层，另一个是流处理平台（SPARK Streaming 或 Storm）。这可以确保丢失的数据都得以找回，以确保所有数据都至少得到了一次处理。

对流处理端的查询可能是提取静态数据来加到流处理器中的数据流，或者可能用于通过任意数量的媒体（包括电子邮件，SMS，客户的应用程序，还有仪表板）向下游的事件消费者发送消息、警报或数据。警报也是在流处理器中的本地环境生成的。

对安全层的存储的查询将被批量用于创建进一步的分析过程并嵌入到流处理器中，或者用于响应特殊查询，例如开发新的预测模型。

你真的需要一个流处理器吗？

你应该在设计物联网平台时考虑到引入流处理器的必要性。对某些只需要很少数量或很少种类的传感器的情况，省掉流处理器自身会带来的系统复杂度可能会更好。

如果 “实时“ 这段时间很长

当实时交互的时间相当长的时候，例如在通知终端用户任何新的发现只能每天发生一次或甚至更少时，对传感器的数据进行批量处理在一些情况下是完全合理的。

从架构的立场来看，传感器数据将到达数据采集应用（Kafka）并直接发送到存储器里面。若使用常规的批处理程序，今天的数据会在夜里被分析，并且需要发送给用户的任何重要信号会放到第二天才发送。

当 “实时” 会是 24 小时或更长的时间，在某些情况下至多缩短至 12 小时左右时，批处理会是一个可行的选择。如果实时交互的时间需求比这更短，流处理会是一个更具吸引力的选择。

其实配置流处理来评估任何时间段（包括数天，数周甚至数月）的数据也是可以的，但在某些时候简化系统的价值会超过引入流处理的价值。

传感器数据的四种应用

传感器数据有四种范围很广的应用。这也可以为你决定是否引入流处理提供参考。以下举一些例子。

直接使用：例如，直接从传感器读取 GPS 坐标，然后把坐标放到地图上，就能轻松创建出一个 “手机去哪里” 的小应用。这一应用可能还需要引入与用户有关的静态数据（比如，需要知道用户的居住地址来限制显示地图的比例），而这可以通过标准表连接（standard table join）来在流处理器外部完成，也可以在流处理器里面完成。

专家规则：不用数据科学，编写能为传入数据流赋予意义的规则也是可行的。例如，可以设计了一个专家规则来与患者的静态数据相结合，让这一规则在患者体温达到 103° 的时候呼叫医护帮助。

预测分析：接下来的两个应用程序都属于数据科学领域。数据科学家会使用预测分析技术来在数据中找到有意义的信息。

无监督学习： 在预测分析中，无监督学习意味着应用像聚类（clustering）和细分（segementation）这样的技术，而这些技术不需要指示了特定的结果的历史数据。例如，FitBit 里的加速度计可以很容易地了解到你现在的活动比最近活跃还是不活跃，或者你比其他一些你拿来比较的 FitBit 用户相对活跃还是不活跃。给阅读这一过程赋予一些内容就可能需要引入用户的静态数据。

无监督学习的优势在于，它在放置传感器之后几乎就可以立即部署起来，毕竟它不需要花大量时间用训练数据来建立模型。给定发送警报的阈值会需要一些无监督建模方法的帮助。例如一个符合标准的消息的更改周期可以设为应该超出每天 20％ 或一个相似用户组的标准差。这些算法会由数据科学家根据批量处理数据进行完善并导出到流处理器中，作为公式应用于数据流。

监督学习：使用训练数据来开发预测模型，而在训练数据中结果是已知的。这又需要部分检测到了行为和当前状态的样例，还有一部分状态未知的样例。

例如，我们可以记录电机的温度，振动和功耗，以及测量后 12 小时内电机是否发生故障。如果有足够多的训练数据，我们就可以开发出一个预测模型，提前 12 小时预测可能发生的障碍。然后将以代数公式（几行 C，Java，Python 或 R 代码）形式表示的模型导出到流处理器，以便在处理数据流时对数据进行评分，当分数显示即将发生故障时自动发送警报。

在流处理中使用复杂的预测模型很有好处。不过如果想要预测的事件很罕见，比如这一事件占所有测量数据的比例很小，或者这一事件需要很长时间才可能发生一次（收集足够的训练数据要等上很长时间），那么收集足够的训练数据就会是个问题。

问答
基于云计算的物联网应用场景有哪些？
相关阅读
启动物联网项目所需的一切：第 1 章
启动物联网项目所需的一切：第 3 章

此文已由作者授权腾讯云+社区发布，原文链接：https://cloud.tencent.com/dev...