在利用基于MCU的传感器和移动设备构建新的连接互联网的云时，很少有人会考虑如何管理这些传感器云。在本文中，RTI公司的Sumeet Shendrikar介绍了如何通过具有态势感知功能的分布式数据管理来做到这一点。在Michael Lewis的《点球成金（Moneyball）》一书中，他记录了使用Sabermetrics指导管理棒球队的策略。虽然重点在于组建棒球队的分析方面，但其基本理念是利用历史信息（先前的统计数据）改变当前的策略（上场击球、防御态势或阵容决定）。
《点球成金》讨论的重点是由统计分析得出的意外决策，经常有悖于长期棒球专家的“第六感”。但这本书也表明，成功地使用Sabermetrics有3点要求：（1）了解过去发生了什么；（2）认识当前态势；（3）应用历史知识驱动当前策略。
这种统计趋势可以在许多其它领域见到。例如，经济贸易应用所依据的模型需要使用历史数据进行校准。很像棒球世界那样，模型的成功取决于能够多快地根据当前市场活动发掘机会。如果实时市场数据由于任何理由被推迟了，那么机会将减少，甚至丢失。
最近在斯坦福大学商学院举行的Big Data会议上，与会者讨论了所有产业中Big Data的增长趋势，包括工业、汽车、消费、医疗，不仅只是棒球或经济产业。或者更准确地讲，Big Data已经是下一件世界大事，商业伙伴分析他们的系统中产生的庞大信息是明智的。
然而，经常被人忽略的是如何真实地收集这些庞大的数据，或更准确地说，如何将数据从产生地移动到需要它的其它不同地方。
这种关联实时数据与历史数据实现态势感知，并将原始数据转换成信息的能力正在快速变成许多大规模分布式系统的必备能力。
Big Data的兴起表明，传统的RDBMS数据库已经无法跟上这些大型分布式系统所展现的数据速率，也不足以应对获得重要信息所需的各种咨询。最近虚拟化技术和基于云的数据管理系统的爆发式增长使得我们能够以创新的方式解决这些问题。
本文余下部分将简要介绍如何使用所谓的NoSQL数据库方法将联网设备与系统组成的分布式网络连接到基于云的数据管理工具，从而实现态势感知。同时使用了多个领域的不同例子说明如何通过整合实时数据与历史数据给分析师提供完整的新生态势描述以及后事件分析。
保留实时数据
无论何时将永久数据管理增加到实时分布式系统，主要考虑因素都是保持运营技术（OT）的关键性能特征。面向物理设备的技术是由工程部门实现和支持的，一般有许多设备与嵌入式系统设计。
在任何大型企业中，OT一般独立于涉及数据管理的信息技术（IT）部门完成，包括在生产线上或已部署系统中的嵌入式设备产生的数据，OT和IT之间很少有实时交互。
在这种分布式系统中，永久存储器性能低于易失性存储器，虽然有迹象表明这两种存储器可能会统一（也就是固态硬盘）。
实时数据管理由多个同时进行的活动组成：
1. 存储（写入）
2. 查询、关联和获取
3. 发布
OT（实时）数据管理与传统IT领域的区别在于，所有这些活动都是同时发生的。数据的产生、存储、关联、获取和重新发布是根据实时要求进行的。
在实时系统中，数据以各种速率产生，并以不同的优先级发布。因此，数据管理系统最好也能划分数据优先级，并能够灵活处理任意存储负荷。
来自传感器的信息就是在典型实时分布式系统中一个非常好的数据产生例子。传感器数据一般是以一致并且已知的速率产生的。虽然通常以低优先级发布，但同一数据能够很快变成最高优先级——数据紧急性是动态的。
比如考虑汽车发动机中的温度传感器。大多数时候温度在正常工作范围内，这个信息可以设置为低优先级。但当温度达到规定阈值时，立即向系统报警就非常重要。
存储性能可以分成截然不同的两大类——完整的和部分的。如果数据管理系统能够以分布式系统的峰值吞吐速率存储数据，那就能实现完整存储。对于部分存储而言，系统设计师有两种选择：
1. 减慢数据发生速率
2. 有选择的丢弃数据
值得注意的是，简单的缓冲处理是不够的，因为任何缓冲器容量都是有限的。缓冲只是简单地推迟了不可避免的问题，在实时系统中是不合适的。
由于是分布式实现，NoSQL数据库写入性能会受复制策略以及基础硬件的影响。对系统设计师来说，理解数据库实现方法并选择一种最适合应用的方法很重要。举例来说，Apache Cassandra的主要强项之一是良好的写入性能，这种性能得益于非常高效的复制策略。
存档服务
存档服务可以给实时数据保证适当的服务质量（QoS），因此可以提供最好的数据存储。在基本实现中，存档服务使用NoSQL数据库API向云中的任意节点发出写命令。NoSQL数据库实现从那里保留和复制数据。根据一致性配置，在达到设定的一致性时，数据库将通知存档服务。
更加先进的存档服务实现能以负载均衡的方式写入云的不同段，从而实现最佳写入吞吐量。存档服务在不能提供完整数据存储时可以检测出来，并相应调整云资源。
在不破坏实时系统条件下的签约能力是存档服务的基本特征。OT系统对时间特别敏感。数据发送的任何延时都可能导致系统故障。虽然订阅数据看起来价值不高，而且是非侵入式的，但传统公司IT系统经常是牺牲反应时间来确保接收到所有数据。
这种平衡措施是将运营技术与存储及其它常用IT系统集成在一起时的常见挑战。为了确保非侵入式订阅，数据的发布必须激活被动观察，并且不能降低数据产生器或任何其它数据传输的速度。
数据库架构
NoSQL数据库的基本属性是模式自由，因此特别适合OT系统。大型实时分布式系统都有数据模式，而且非常复杂，还是动态的。
这个产业很大程度上在远离固定的单数据模型概念（如CORBA），原因有很多，而集成度和前向兼容性是其中最重要的两个。在现代OT系统中，数据模式必须实时动态的发现，并且必须是可扩展和/或容易改变。
这些模式不仅必须被数据管理系统捕获，而且还可能被检查以供分析使用。换句话说，元数据和数据对态势感知来说同样重要。
数据关联、查询和获取
实现态势感知（SA）要求关联实时数据与历史数据。从技术角度讲，这意味着当数据流写入NoSQL数据库时，必须对这些数据流进行连续的预编译和动态查询。
所有态势感知查询都是由某些实时事件的发生进行触发，例如安全性的价格变化。一旦实时事件发生，查询数据需要关联历史数据，并确定采取哪种措施（如果有的话）。
内容发布
NoSQL数据库已经征服了按需内容发布世界。Netflix使用Apache Cassandra实现流服务这个事实也许是最生动的例证。
查询结果分成两类：警告和内容获取。警告发布在大多数情况下都不是很重要，只是一个高优先级的消息。在数据获取情况下，发布成为一个重要因素。来自查询的数据结构需要及时地被取回、排序并发布给消费者。
使用案例：发电
全球范围内建好的风力发电厂已有数百个。假如风力发电厂建构为分层的分布式系统。
在层次化结构的最底层，每个风机本身就是一个分布式系统：它有一个巨大的传感器阵列，用于产生有关当前发电的信息以及结构数据和环境数据，这些数据用来使风机安全高效地运行。
这些数据也自动与电厂控制中心共享。控制中心负责保持与其它电厂的联系，并链接到两个重要的外部系统：电网和气象系统。
以风机检测到突发和意外的强大阵风为例，根据过去几周的精确测量结果以及过去几年更全面的测量结果，风机会判断这阵风不正常。
由于具有潜在的危害性，风机将转换到故障防护模式。然后向命令中心发送警告，然后根据每个风机的当前状态使用连续实时控制方法仔细地调整其它涡轮的性能。命令中心也可以警告下游电厂，以便他们可以能够及时调整性能。
另外一种场景涉及到来自能源贸易的实时报价更新。电网和能源交换可以提供有关负荷、需求和电量报价方面的信息。
如果需求和价格低于当前输出电能，电厂能够自动将产生的电能重定向到存储或停止发电。如果需求和价格高于当前所产电能，电厂能够转向峰值产能，并销售存储的电能。就像安全交易一样，有可能设计出算法来检测发电和配电的有益模式。气象系统也能采取算法统计分析方法，并从与风力发电厂的双向通信中受益。一方面，电厂成为气象数据的重要实时传感器站；另一方面，电厂依靠气象系统的天气预报进行仔细调整性能来实现最优输出。
发电和气象系统中使用的算法都需要及时地访问实时事件和历史趋势。如果由于某种原因延迟了数据，造成的结果可能从不足输出导致收入减少，到灾难性的故障和基础设施损毁（甚至可能危及人类生命安全）。
前瞻性维护
前瞻性维护和资产管理是先进的OT/IT集成可能直接影响收入的例子。就像预防性维护一样，这种方法能够降低成本，因为工作只在需要时开展。前瞻性维护是通过连续的实时监视在线设备预测何时要求维护来实现的。
但只是监视设备状态是不够的。就像风力发电厂例子一样，其自身实时数据不能提供足够信息来判断设备是否工作在正常范围内。传感器指示高温有可能是由于设备故障引起的，也可能是由于电厂输出提高造成的。
为了进行确认，必须根据历史信息分析监视数据来判断是否需要采取进一步措施。用于解决维护问题的相同技术和算法也可以用于提供长期商业智能。除了防止意外的设备故障外，认清设备使用方面的长期趋势也可以提高可用性，并延长设备寿命。
干草堆中的细针
许多公司已经成功展示使用Big Data技术筛选IT系统产生的庞大信息的价值。这种技术被证明非常适合用来寻找谚语式的干草堆细针。与此同时，有关部门刚开始认识到OT系统产生的数据商业价值。
合并OT和IT数据是下一个合理的步骤，但这种整合面临许多技术挑战。OT系统会产生甚至更多的数据用于分析（更多的“干草”来隐藏细针），而IT系统必须以不影响OT实时数据流的时间敏感性这种方式进行集成。
通过选择正确的技术整合方法可以解决数据管理问题，OT和IT的能量可以同时释放出来捕获转瞬即逝的机会。也就是说，在细针落入干草堆之前就发现细针。
在利用基于MCU的传感器和移动设备构建新的连接互联网的云时，很少有人会考虑如何管理这些传感器云。在本文中，RTI公司的Sumeet Shendrikar介绍了如何通过具有态势感知功能的分布式数据管理来做到这一点。在Michael Lewis的《点球成金（Moneyball）》一书中，他记录了使用Sabermetrics指导管理棒球队的策略。虽然重点在于组建棒球队的分析方面，但其基本理念是利用历史信息（先前的统计数据）改变当前的策略（上场击球、防御态势或阵容决定）。
《点球成金》讨论的重点是由统计分析得出的意外决策，经常有悖于长期棒球专家的“第六感”。但这本书也表明，成功地使用Sabermetrics有3点要求：（1）了解过去发生了什么；（2）认识当前态势；（3）应用历史知识驱动当前策略。
这种统计趋势可以在许多其它领域见到。例如，经济贸易应用所依据的模型需要使用历史数据进行校准。很像棒球世界那样，模型的成功取决于能够多快地根据当前市场活动发掘机会。如果实时市场数据由于任何理由被推迟了，那么机会将减少，甚至丢失。
最近在斯坦福大学商学院举行的Big Data会议上，与会者讨论了所有产业中Big Data的增长趋势，包括工业、汽车、消费、医疗，不仅只是棒球或经济产业。或者更准确地讲，Big Data已经是下一件世界大事，商业伙伴分析他们的系统中产生的庞大信息是明智的。
然而，经常被人忽略的是如何真实地收集这些庞大的数据，或更准确地说，如何将数据从产生地移动到需要它的其它不同地方。
这种关联实时数据与历史数据实现态势感知，并将原始数据转换成信息的能力正在快速变成许多大规模分布式系统的必备能力。
Big Data的兴起表明，传统的RDBMS数据库已经无法跟上这些大型分布式系统所展现的数据速率，也不足以应对获得重要信息所需的各种咨询。最近虚拟化技术和基于云的数据管理系统的爆发式增长使得我们能够以创新的方式解决这些问题。
本文余下部分将简要介绍如何使用所谓的NoSQL数据库方法将联网设备与系统组成的分布式网络连接到基于云的数据管理工具，从而实现态势感知。同时使用了多个领域的不同例子说明如何通过整合实时数据与历史数据给分析师提供完整的新生态势描述以及后事件分析。
保留实时数据
无论何时将永久数据管理增加到实时分布式系统，主要考虑因素都是保持运营技术（OT）的关键性能特征。面向物理设备的技术是由工程部门实现和支持的，一般有许多设备与嵌入式系统设计。
在任何大型企业中，OT一般独立于涉及数据管理的信息技术（IT）部门完成，包括在生产线上或已部署系统中的嵌入式设备产生的数据，OT和IT之间很少有实时交互。
在这种分布式系统中，永久存储器性能低于易失性存储器，虽然有迹象表明这两种存储器可能会统一（也就是固态硬盘）。
实时数据管理由多个同时进行的活动组成：
1. 存储（写入）
2. 查询、关联和获取
3. 发布
OT（实时）数据管理与传统IT领域的区别在于，所有这些活动都是同时发生的。数据的产生、存储、关联、获取和重新发布是根据实时要求进行的。
在实时系统中，数据以各种速率产生，并以不同的优先级发布。因此，数据管理系统最好也能划分数据优先级，并能够灵活处理任意存储负荷。
来自传感器的信息就是在典型实时分布式系统中一个非常好的数据产生例子。传感器数据一般是以一致并且已知的速率产生的。虽然通常以低优先级发布，但同一数据能够很快变成最高优先级——数据紧急性是动态的。
比如考虑汽车发动机中的温度传感器。大多数时候温度在正常工作范围内，这个信息可以设置为低优先级。但当温度达到规定阈值时，立即向系统报警就非常重要。
存储性能可以分成截然不同的两大类——完整的和部分的。如果数据管理系统能够以分布式系统的峰值吞吐速率存储数据，那就能实现完整存储。对于部分存储而言，系统设计师有两种选择：
1. 减慢数据发生速率
2. 有选择的丢弃数据
值得注意的是，简单的缓冲处理是不够的，因为任何缓冲器容量都是有限的。缓冲只是简单地推迟了不可避免的问题，在实时系统中是不合适的。
由于是分布式实现，NoSQL数据库写入性能会受复制策略以及基础硬件的影响。对系统设计师来说，理解数据库实现方法并选择一种最适合应用的方法很重要。举例来说，Apache Cassandra的主要强项之一是良好的写入性能，这种性能得益于非常高效的复制策略。
存档服务
存档服务可以给实时数据保证适当的服务质量（QoS），因此可以提供最好的数据存储。在基本实现中，存档服务使用NoSQL数据库API向云中的任意节点发出写命令。NoSQL数据库实现从那里保留和复制数据。根据一致性配置，在达到设定的一致性时，数据库将通知存档服务。
更加先进的存档服务实现能以负载均衡的方式写入云的不同段，从而实现最佳写入吞吐量。存档服务在不能提供完整数据存储时可以检测出来，并相应调整云资源。
在不破坏实时系统条件下的签约能力是存档服务的基本特征。OT系统对时间特别敏感。数据发送的任何延时都可能导致系统故障。虽然订阅数据看起来价值不高，而且是非侵入式的，但传统公司IT系统经常是牺牲反应时间来确保接收到所有数据。
这种平衡措施是将运营技术与存储及其它常用IT系统集成在一起时的常见挑战。为了确保非侵入式订阅，数据的发布必须激活被动观察，并且不能降低数据产生器或任何其它数据传输的速度。
数据库架构
NoSQL数据库的基本属性是模式自由，因此特别适合OT系统。大型实时分布式系统都有数据模式，而且非常复杂，还是动态的。
这个产业很大程度上在远离固定的单数据模型概念（如CORBA），原因有很多，而集成度和前向兼容性是其中最重要的两个。在现代OT系统中，数据模式必须实时动态的发现，并且必须是可扩展和/或容易改变。
这些模式不仅必须被数据管理系统捕获，而且还可能被检查以供分析使用。换句话说，元数据和数据对态势感知来说同样重要。
数据关联、查询和获取
实现态势感知（SA）要求关联实时数据与历史数据。从技术角度讲，这意味着当数据流写入NoSQL数据库时，必须对这些数据流进行连续的预编译和动态查询。
所有态势感知查询都是由某些实时事件的发生进行触发，例如安全性的价格变化。一旦实时事件发生，查询数据需要关联历史数据，并确定采取哪种措施（如果有的话）。
内容发布
NoSQL数据库已经征服了按需内容发布世界。Netflix使用Apache Cassandra实现流服务这个事实也许是最生动的例证。
查询结果分成两类：警告和内容获取。警告发布在大多数情况下都不是很重要，只是一个高优先级的消息。在数据获取情况下，发布成为一个重要因素。来自查询的数据结构需要及时地被取回、排序并发布给消费者。
使用案例：发电
全球范围内建好的风力发电厂已有数百个。假如风力发电厂建构为分层的分布式系统。
在层次化结构的最底层，每个风机本身就是一个分布式系统：它有一个巨大的传感器阵列，用于产生有关当前发电的信息以及结构数据和环境数据，这些数据用来使风机安全高效地运行。
这些数据也自动与电厂控制中心共享。控制中心负责保持与其它电厂的联系，并链接到两个重要的外部系统：电网和气象系统。
以风机检测到突发和意外的强大阵风为例，根据过去几周的精确测量结果以及过去几年更全面的测量结果，风机会判断这阵风不正常。
由于具有潜在的危害性，风机将转换到故障防护模式。然后向命令中心发送警告，然后根据每个风机的当前状态使用连续实时控制方法仔细地调整其它涡轮的性能。命令中心也可以警告下游电厂，以便他们可以能够及时调整性能。
另外一种场景涉及到来自能源贸易的实时报价更新。电网和能源交换可以提供有关负荷、需求和电量报价方面的信息。
如果需求和价格低于当前输出电能，电厂能够自动将产生的电能重定向到存储或停止发电。如果需求和价格高于当前所产电能，电厂能够转向峰值产能，并销售存储的电能。就像安全交易一样，有可能设计出算法来检测发电和配电的有益模式。气象系统也能采取算法统计分析方法，并从与风力发电厂的双向通信中受益。一方面，电厂成为气象数据的重要实时传感器站；另一方面，电厂依靠气象系统的天气预报进行仔细调整性能来实现最优输出。
发电和气象系统中使用的算法都需要及时地访问实时事件和历史趋势。如果由于某种原因延迟了数据，造成的结果可能从不足输出导致收入减少，到灾难性的故障和基础设施损毁（甚至可能危及人类生命安全）。
前瞻性维护
前瞻性维护和资产管理是先进的OT/IT集成可能直接影响收入的例子。就像预防性维护一样，这种方法能够降低成本，因为工作只在需要时开展。前瞻性维护是通过连续的实时监视在线设备预测何时要求维护来实现的。
但只是监视设备状态是不够的。就像风力发电厂例子一样，其自身实时数据不能提供足够信息来判断设备是否工作在正常范围内。传感器指示高温有可能是由于设备故障引起的，也可能是由于电厂输出提高造成的。
为了进行确认，必须根据历史信息分析监视数据来判断是否需要采取进一步措施。用于解决维护问题的相同技术和算法也可以用于提供长期商业智能。除了防止意外的设备故障外，认清设备使用方面的长期趋势也可以提高可用性，并延长设备寿命。
干草堆中的细针
许多公司已经成功展示使用Big Data技术筛选IT系统产生的庞大信息的价值。这种技术被证明非常适合用来寻找谚语式的干草堆细针。与此同时，有关部门刚开始认识到OT系统产生的数据商业价值。
合并OT和IT数据是下一个合理的步骤，但这种整合面临许多技术挑战。OT系统会产生甚至更多的数据用于分析（更多的“干草”来隐藏细针），而IT系统必须以不影响OT实时数据流的时间敏感性这种方式进行集成。
通过选择正确的技术整合方法可以解决数据管理问题，OT和IT的能量可以同时释放出来捕获转瞬即逝的机会。也就是说，在细针落入干草堆之前就发现细针。
举报
举报
