导读：开源以丰富的项目画布引领着处理实时事件的方向。
https://linux.cn/article-13891-1.html
译者：unigeorge
在“永不下线”的未来，入 设备规模可能会达到数十亿。存储原始数据，日后再进行分析的方案将不再能满足需求，因为用户需要实时且准确的响应。要对故障等对环境敏感的状况进行预测，实时处理数据也必不可少 —— 数据到达数据库后再处理肯定是来不及的。
有人可能会说，“云可扩展性”能够满足实时处理流数据的需求，但一些简单的例子就能表明它永远无法满足对无界数据流进行实时响应的需求。从移动设备到物联 ，都需要一种新的范式来满足需求。尽管云计算依赖于对大数据“先存储后分析”的方案，但也迫切需要一种能够处理持续、杂乱和海量数据流的软件框架，并在数据流到达时立即对其进行处理，以保证实时的响应、预测和对数据的洞悉。
例如，在加利福尼亚州的帕洛阿尔托市，每天从基础交通设施产生的流数据比 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
? 流处理器必须能够根据数据速率进行扩展，甚至要能够跨越服务器和云，并且还可以跨实例实现负载均衡，以确保弹性和其他应用层的需求。
解决数据扩展问题
需要注意的是，即使是 Samza 也不能完全减轻开发人员的数据处理需求。扩展数据规模意味着处理事件的任务需要跨多个实例进行负载均衡，而使用数据库是实例间共享结果应用层状态的唯一方法。然而，当应用程序任务之间的状态协调转移到数据库时，对性能会产生不可避免的连锁反应。此外，数据库的选择也至关重要。随着系统的扩展，数据库的集群管理会成为下一个潜在的瓶颈。
这些解决方案允许大量的代理（真实数据源的数字类比）分布，甚至还有在应用层使代理互连的分布式图，从而简化了应用架构。这是因为代理之间互连的本质，是映射到解决方案的当前运行时执行实例和代理本身的 URL。通过这种方式，应用程序可以跨实例无缝扩展，而无需担心 DevOps 问题。代理消费数据并维护状态，还会计算自己和其他代理的状态。由于代理是有状态的，因此不需要数据库，并且数据洞察是以内存速度计算的。
使用开源阅读数据世界
via:https://opensource.com/article/20/2/real-time-data-processing
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！