开放源码以丰富的项目画笔助推着处置动态该事件的方向。
在“终将推向市场”的未来，破网电子设备规模可能会达到数千万。储存原始统计数据，日后再展开预测的计划将不再能满足用户市场需求，因为用户须要动态且准确的积极响应。要对机械故障等对环境敏感的状况展开预估，动态处置统计数据也不可或缺 —— 统计数据抵达统计资料库后再处置肯定是顾不上的。
有人可能会说，“云扩展性”能满足用户动态处置流统计数据的市场需求，但一些单纯的范例就能表明它永远无法满足用户对景丰纯统计报文展开动态积极响应的市场需求。从终端电子设备到物联网，都须要一类捷伊本体论来满足用户市场需求。尽管云计算倚赖对大统计数据“先储存后预测”的计划，但也迫切须要一类能处置持续、凌乱和海量统计报文的应用软件架构，并在统计报文抵达时立即对其展开处置，以保证动态的积极响应、预估和对统计数据的看透。
比如，在加州的尔湾市，每天从基础公共设施造成的流统计数据比 Twitter Firehose 还要多。这是很大的统计信息量。为 Uber、Lyft 和 FedEx 等顾客预估公共交通须要动态的预测、学习和预估。云处置无可避免地导致每个该事件大约会有四分钟的延后。
我们须要两个单纯而强大的程式设计本体论，让插件在类似下面的情形时能动态处置景丰纯统计报文：
统计信息量巨大，或原始统计数据的终端成本很高。统计数据由广泛分布的资产（比如终端电子设备）生成。统计数据具有此时此刻的价值，即刻预测刻不容缓。须要始终看透最新统计数据情形，外推法没错。正式发布和订户
该设计模式控制系统领域中有两个关键构架商业模式：正式发布/订户publish/subscribe 输入输出商业模式。这是一类触发器通信方法，其中最新消息会从 正式公共信息（统计数据造成方）传递到订户者（处置统计数据的插件）。正式发布/订户商业模式可以将最新消息转交者与顾客分离开去。
在正式发布/订户商业模式中，最新消息源会 正式发布特别针对某一 主轴topic 的 该事件event 至 服务器端broker，后者按转交顺序储存它。插件可以订户两个或多个主轴，然后服务器端会转贴相匹配的该事件。 Apache Kafka 和 Pulsar 以及 CNCF NATS 是正式发布/订户控制系统。 正式发布/订户的云服务包括 Google Pub/Sub、AWS Kinesis、Azure Service Bus、Confluent Cloud 等。（LCTT 评注：本段部分名词中文名称更为通用型，特别针对这些名词，采用了中文标示。）
正式发布/订户控制系统不会 运行订户者插件，它只是传递统计数据给相应主轴的订户者。
流统计数据通常包含插件或基础构架状态更捷伊该事件。在选择构架来处置统计数据时，正式发布/订户架构等统计数据分发控制系统的作用是有限的。顾客插件的“处置方式”超出了正式发布/订户控制系统的范围。这让开发人员的管理变得极具复杂性。所谓的流处置器是一类特殊的订户者，可以动态预测统计数据并将结果返回给同两个服务器端。
Apache Spark
Apache Spark是用于大规模统计数据处置的统一预测引擎。通常将 Apache Spark Streaming 用作流处置器，比如给机器学习模型提供新统计数据。Spark Streaming 将统计数据分成小批量，每个小批量都由 Spark 模型或其他控制系统独立预测。该事件流可以被分组成小批量以展开预测，但流处理器本身必须具有弹性：
可能相差很大。这意味着它必须是有状态的，或者将状态储存在统计资料库中。当使用 Spark Streaming 作为流处置器时，通常会使用后一类方法，这种方法在须要超低延后积极响应时可能会存在性能问题。相关项目 Apache Samza也提供了一类处置动态该事件流的方法，并使用Hadoop Yarn或Apache Mesos来管理计算资源，以便展开弹性扩展。
解决统计数据扩展问题
须要注意的是，即使是 Samza 也不能完全减轻开发人员的统计数据处置市场需求。扩展统计数据规模意味着处置该事件的任务须要跨多个实例展开负载均衡，而使用统计资料库是实例间共享结果应用层状态的唯一方法。然而，当插件任务之间的状态协调转移到统计资料库时，对性能会造成无可避免的连锁反应。此外，统计资料库的选择也至关重要。随着控制系统的扩展，统计资料库的集群管理会成为下两个潜在的瓶颈。
这个问题可以通过有状态、有弹性的替代计划来解决，并且这样的解决计划可以用来代替流处置器的真实关系（如包含和临近）,代理实现互连以共享状态。代理也因此形成了两个并发服务图，可以预测它自己的状态和链接到的代理的状态。统计数据源将原始统计数据转换为状态，并根据自身及其链接子图的变化展开预测、学习和预估，每个代理都为单个这样的统计数据源提供微服务。
这些解决计划允许大量的代理（真实统计数据源的数字类比）分布，甚至还有在应用层使代理互连的分布式图，从而简化了应用构架。这是因为代理之间互连的本质，是映射到解决计划的当前运行时执行实例和代理本身的 URL。通过这种方式，插件可以跨实例无缝扩展，而无需担心 DevOps 问题。代理消费统计数据并维护状态，还会计算自己和其他代理的状态。由于代理是有状态的，因此不须要统计资料库，并且统计数据洞察是以内存速度计算的。
使用开放源码阅读统计数据世界
我们查看统计数据的方式正在发生翻天覆地的变化：不再将统计资料库用作记录控制系统，取而代之的是现实世界，现实世界事物的数字类比可以不断地传输它的状态。幸运的是，开放源码社区在处置动态该事件的项目丰富度方面处于领先地位。从正式发布/订户商业模式（其中最活跃的社区是 Apache Kafka、Pulsar 和 CNCF NATS）到持续处置流统计数据的预测架构，包括 Apache Spark、Flink、Beam、Samza，以及 Apache 许可的SwimOS和Hazelcast，对开发人员来说，可选择项目非常之多。可以说，没有什么地方比开放源码社区的专有应用软件架构更多了。试看应用软件的未来，必是开放源码的天下。
via: https://opensource.com/article/20/2/real-time-data-processing
作者：Simon Crosby选题：lujun9972译者：unigeorge校对：wxy
本文由 LCTT原创编译，Linux中国荣誉推出
