启动物联网项目所需的一切：第 3 章
原文作者：William Vorhies
原文地址：https://dzone.com/articles/everything-you-need-to-start-your-iot-project-part-1
在第 3 章中，我们将继续对物联网或流处理系统的一些技术问题建立完整的基础和多方面的理解，以便读者在规划物联网系统时能够做出明智的决策或是有根据地提出问题。
接上第 2 章，我们的意图是帮助开始考虑流处理和物联网的人们建立多方面的基础。在本章节里，我们将解释 Spark 和 Storm 处理数据流的不同方式、讨论实时分析的实际意义、为流处理提供一些除了开源框架之外的解决方案，并给出在这个快速发展的领域中应该注意的一些趋势。
三种数据处理范例：SPARK 与 Storm
在用户对比 SPARK 和 Storm 的时候，关注点通常集中在它们对传入数据流的处理方式的差异上。
- Storm 一次处理传入数据的一个事件 —— 也就是原子级处理（Atomic processing）。
- SPARK 以非常小的批次处理传入数据 —— 也就是微量批处理（Micro Batch）。根据传感器传递数据的频率，SPARK 的微批次通常在半秒到 10 秒之间。这个值也可以由你来定义。
- 第三种方法是窗口化（Windowing），它能使用更长的时间窗口，并且可以用于某些文本或情感分析的应用，或信号只会在相对较长的时间内变化的系统。
原子级处理：（也就是一次处理一个元组）将每个传入数据事件作为一个单独的元素处理。这是最简单明了的，但也是计算量最高的设计。它能用于确保以最少的延迟将事件传送给用户，以此来达成对个别事件的最快处理。这一处理模式也会经常查看用户输入的事务，以便在对事件块的某些元素的处理失败的时候，不用把整个块删掉，将其移至一个错误记录文件中，以后再去处理即可。Apache Storm 用的就是这种模式。
微量批处理：尽管存在着对它实际上把数据按批处理而不去实现原子级的流处理的非议，但其实这里的批次是极其微小的，只会包含用几秒就能弄完的操作。你还可以通过调整时间窗口来让这一过程变得更加高效。SPARK 的流处理就用了这种模式。
窗口化：这是上述两种方法的一种结合。窗口化方法会维护每个数据项的原子处理，同时还会创建伪批次（窗口）来使处理更加高效。这一方法也有很多更加复杂的具体实现，比如滑动窗口（例如，在最后 X 个时间段内发生的所有事件）。
所有这三种方法都可以保证每个数据元素至少被处理一次。只有原子级处理这一方式才能保证每个数据元素只处理一次。
考虑这个例子
你的传感器跟 FitBits 一样每 10 秒会采集一遍数据。每当传感器将其数据转储到 Wi-Fi 流时，它们就会把数据全都传输出去。有个用户可能会在一天里把数据流的输出看上好几遍，而且当前的网络延迟很低，使得他的传感器经常通过 Wi-Fi 上传数据。另一个用户可能不在 Wi-Fi 热点附近，或者可能根本不想花好几天去下载数据。除此之外，还有第三个用户可能会遇到网络连接或硬件本身的问题，使得传感器会传输不完整或者丢失的数据包（数据包在一段时间后在数据流里重新出现，或者就这样在数据流里消失）。
在这种情况下，在同一时间发出的传感器数据可能会以各种各样的延迟到达流处理器，并且一些受影响的数据包可能还会被反复传输或根本没传输过。
在进行流处理器选型的时候，你应该仔细地考虑一下是应该选择 “只有一次” 方式的处理，还是应该选择能比这种方式的原子级处理稍微快一些的响应时间。
流处理和实时分析
在物联网领域中找到 “实时分析”（real time analytics） 或 “流分析”（in stream analytics） 的参照范例并不难，不过这些术语可能会产生误导。实时分析并不是指在进行流处理的时候实时地发现数据中的什么你没有见过的全新模式。这意味着的是已开发的部署到流处理器中的预测模型可以对数据流里面的数据进行评分，并实时地判定某个特定的信号有没有出现。
要记住这一重点。在复杂的流处理器背后的数据科学原理是在经典的两步数据科学过程中开发的。首先，数据科学家会基于已知结果的历史数据（也就是基于监督式学习）开发一种使用输入数据来预测目标事件的可能性的算法。然后，将模型，也就是算法的代数公式（由如 C、Python、Java，和 R 这些语言的代码来代表）导出到流处理器里面的程序中，并开始评估传入的数据来检查信号有没有出现。如果信号出现了，某种形式的警报就会被发送给某些人或机器，或作为视觉信号发送到某个仪表板上。
最近的一些迹象表明，有些新型的信号检查过程已经可以实时进行，不过这种过程并不多见。请参阅这篇文章。
超越开源方案的流处理方式
你为何会想为你的物联网系统找一个比开源方案更好的解决方案呢？很大程度上应该是因为虽然开源工具和软件包几乎都是免费的，但这与 “免费的午餐” 没什么两样。
没错，之前提到过的软件包都可以从 Apache 免费下载，但最合理的下载来源应该还是三个主流分销商 —— Hortonworks，Cloudera 和 MapR（他们都会确保代码与最新版同步，并添加某些功能使其更容易维护）。不过即使是在把这些分销商加入考量的时候，你的总投资也应该低于五位数。这当然不包括实施，咨询或配置支持的成本，这些额外的支持可以来自分销商，也可以来自其他顾问，更可以来自在你公司里面能胜任这工作的员工。
使用开源方案也会带来更多的系统复杂度。作者 Jim Scott 撰写的关于 SPARK 的文章对此总结得非常好：“ SPARK 就像是一架要你自己来造的战斗机。在你造完之后，你就有一架战斗机了。这很好，但有个问题，你开过战斗机吗？你有想象过你坐在里面摆弄那么多操纵杆的情景吗？“
按照 IT 的说法，在 SPARK 或其他开源流处理平台中创建的配置和初始程序将非常没有弹性。这也就意味着每当业务规则发生变化时，用 Scala 编写（虽然也能用 Python 来写）的 SPARK 代码就必须要改。
同样，一个 SPARK 或 Hadoop 存储集群的存在还会带来编程还有数据库管理（DBA）的开销。你大概也不希望产生这种开销，或者至少是能把这种开销最小化。用上一家主流云服务提供商和 / 或添加像 Qubole 这样的 SaaS 服务就能以很小的增量成本来大大减少你的人力成本。
一些有专利的流处理器也是如此，其中许多流处理器都是由主流公司提供的，并且它们都经过了良好的测试，并且受到了很好的技术支持。其中许多都带有可拖曳的可视化界面，无需手动编程，因此任何对此足够投入的程序员或分析师都可以根据业务变化来对内部逻辑进行配置和维护。（NiFi 请了解一下，这个新兴的开源平台也声称可以用拖曳式的界面来操作）。
需要考虑的竞争对手
Forrester 公布了在 “大数据流分析平台” 方面的若干竞争者的定期评级与排名。截至 2016 年，这一排名列出了 15 个值得考虑的在这方面的竞争者。
以下是 Forrester 给出的业界七大领袖（Leaders）的排行榜：
- IBM
- Software AG
- SAP
- TIBCO Software
- Oracle
- DataTorrent
- SQLstream
另外还有业界八大强者（译者注：Strong Performers，档次上比 Leaders 低一级，详见下方排名图表）的排行榜：
- Impetus Technologies
- SAS
- Striim
- Informatica
- WSO2
- Cisco Systems
- data Artisans
- EsperTech
注意，以上排名不包括那些只提供云服务的供应商，尽管它们也应该会在像这样的排行榜中出现。比如：
- Amazon 网络服务里面的 Elastic MapReduce
- Google 云数据流
- Microsoft Azure 的流分析
这是排名图表：
你可以从上面提到的其中一个竞争者那里获得一份完整报告的副本。其中的细节应该得到注意。就比如这里有一些从数值计分表观察到的有趣现象。
数据流处理能力（Stream Handling）：在这个假定的核心能力中，SoftwareAG 在这方面得到了一个完美的分数，而 Impetus 和 WSO2 的得分明显低于平均水平。
数据流操作（程序）种类（Stream Operators）：另一个假定的核心能力。IBM Streams 在这方面获得了满分。大多数其他竞争对手的得分接近 4.0（5.0分），而 data Artisan 得分明显偏低。
为具体实现提供技术支持（Implementation Support）：data Artisans 和 EsperTech 明显弱于其他竞争对手。
总而言之，你需要仔细检查 12 个得分项。
这 15 个业界典范和 3 个云产品的共同之处在于，它们极大地简化了编程和配置，并隐藏了实现细节。这是一个值得考虑的因素。
值得注意的趋势
物联网及流处理是一个日新月异的领域。在去年，SPARK 就一跃成为了最流行的开源解决方案。所有这些发展都反映出了对能够应对在数据流处理应用（data-in-motion applications）方面不断膨胀的市场的工具和平台的日益增加的市场需求。
这一切都意味着你应该在设计还有技术选型阶段跟这方面的最新成果保持同步。不过，技术的日新月异也不应该成为阻碍你开始行动的理由。
- 其中一个发展的方向会是将 SPARK 进一步完善为一个能够支持全部四个架构元素（数据采集，流处理，存储还有查询）的单一平台。
- 我们预计许多有专利的解决方案也会朝着这一方向发展。
- 当这种发展的成果变得可靠的时候，Lambda 架构所需要的分离组件就没有用处了。
- 我们预计 SPARK 将朝着简化设置和维护过程的方向发展，有不少有专利的解决方案也像这样声明了它们的发展方向。留意 NiFi 可能会被集成到 SPARK 里面，至少也可能通过集成可拖曳的界面元素来构建更亲切的用户界面。
Bill Vorhies 是 Data Science Central 的编辑总监，自 2001 年起担任数据科学家和商业预测建模师。本文首次出现在 Data Science Central。