流数据本身不足以最大限度地发挥实时数据的价值。为此，您需要流处理。
译自 Stream Processing 101: What’s Right for You? 。
在过去的十年中，Apache Kafka 的日益普及让数据流式传输(即连续传输数据流)成为主流。
如果要实时运行运营和分析用例，您不想处理会坐着变臭的孤立数据包。您想要连续的数据流，可以在生成和摄取时立即处理和应用。这就是为什么如此多的公司转向了数据流式传输，但现实是，数据流式传输本身不足以最大限度地发挥实时数据的价值。为此，您需要流处理。
流处理意味着在接收数据后立即对其执行操作。在数据到达时立即处理数据可以提取其价值，而不是等待数据收集后再进行批处理。
默认情况下，大多数系统都是设计有高延迟的。批处理作业被串在一起定期将数据从一个地方移动到另一个地方，就像 Rube Goldberg 机器一样。但情况不必如此。当组织为更快的处理进行架构时，特别是在旨在改进组织反应能力的用例中，它们会获得优势。
许多人使用的电视流媒体应用程序就是流处理可以如何改进前端体验和后端流程的很好例子。遥控器上按的每个按钮都提供有关查看行为的信息，这可以告知内容的分类，从而改进用户体验。
与此同时，该应用程序可以设计为通过监控重新缓冲事件和区域故障的数据流来确保查看质量。将其与只能以预定的间隔提供中断数据的系统或应用程序进行比较，间隔以分钟、小时甚至天为单位。这就是使用基于批处理与基于流式传输的数据流水线捕获运行业务所需数据之间的区别。一旦一个组织转向数据流式传输，在他们构建的新流水线中结合流处理是唯一合理的选择。
采用数据流式传输而不利用流处理的组织最终会面临比必要的更高的延迟和更高的成本。如果您不打算实时处理和转换实时捕获的数据，采用实时数据收集又有什么意义呢?
尽管并非您构建的每个应用程序都需要在传输中处理数据，但诸如欺诈检测、网络安全和位置跟踪等大多数有价值的用例需要实时处理才能有效工作。
当流式数据未实时处理时，它必须存储在传统文件系统或云数据仓库中，直到应用程序或服务请求该数据。这意味着每次您想要加入、聚合或丰富数据以使其为下游系统和应用程序做好准备时，都需要从头执行查询。
相比之下，流处理允许您“查看”数据一次，而不必一遍又一遍地对其应用相同的操作。这减少了存储和计算成本，尤其是随着您的数据流式传输用例随时间扩展。
一旦您构建了流处理流水线，就可以将它们连接到您的数据所在的所有地方——从本地关系数据库到越来越受欢迎的云数据仓库和数据湖。或者，您可以使用这些流水线直接连接到实时应用程序。
流处理的好处的一个很好的例子是实时电子商务。流处理允许电子商务平台在有新信息可用时立即更新下游系统。对于产品定价和库存等数据点，可能有多个运营和面向客户的用例需要该信息。
如果这些平台必须以批处理方式处理数据，这会导致客户想要的信息(新销售和促销、装运更新或退款)与他们实际收到的通知之间的滞后时间更长。这是企业如果想要具有竞争力就需要避免的糟糕客户体验，这在每个行业都适用。
但是在公司及其开发人员开始之前，他们需要选择正确的数据流处理技术。这个选择不一定很直接。
在过去的七八年中，几种开源技术主导了流处理的世界。这少数几种技术正试图解决更快地将数据投入使用的问题，而不损害数据质量或一致性，即使下面的技术、架构和操作细节不同。
让我们看看三种常用的流处理器。
- Apache Flink 是一个设计用于处理大规模数据流的数据处理框架。 Flink 支持事件驱动式处理和批处理，以及交互式分析。
- Kafka Streams 是 Apache Kafka 生态系统的一部分，是一种基于微服务的客户端库，允许开发人员构建实时流处理应用程序和可扩展的高吞吐量流水线。
- Apache Spark 是一个使用微型批处理构建的分布式引擎，类似于使用 Flink 和 Kafka Streams 实现的实时处理。
这些技术都有其优势，在某些用例中，结合使用这些技术也是有意义的。无论是考虑这三种技术还是更广泛的生态系统中的许多其他技术，组织都需要考虑这个决定将如何推进其长期数据战略，并允许他们追求保持竞争力的用例，因为随着数据流式传输的普及。
今天采用流处理的组织通常会根据开发人员和运维团队现有的技能组进行此决定。这就是为什么您经常看到拥有大量 Kafka 社区实践经验的企业转向 Kafka Streams 的原因，例如。
如果您计划在不久的将来构建流式应用程序，那么开发人员体验是生产力的一个重要预测指标。例如，使用 SQL 引擎(Flink SQL、ksqlDB 或 Spark SQL)来处理数据流可能是使组织中的业务分析师可以访问实时数据的正确选择。相反，对于习惯使用 Java 的开发人员来说， Kafka Streams 的易用性和熟悉度可能更符合他们的技能。
虽然这种推理在短期内不阻碍创新的方式确实有意义，但它并不总是最具战略性的决定，并且可能会限制您可以发挥流处理用例的程度。
从实践者的角度开始流处理看起来与从组织角度不同。虽然组织需要考虑业务需求，但从业人员可以专注于帮助他们快速启动和学习的技术。
首先，查看您要使用的流技术的横向比较。虽然公司可能会同时评估几种技术，但我建议开发人员不要这样做 - 您不希望对五种不同的技术进行概念验证(POC)。相反，将您的列表缩减为两个符合要求的选项，然后为每一个构建 POC。
最简单的方法是找到一个与您的用例紧密匹配的教程并深入研究。一个很好的学习起点是构建从物联网(IoT)设备或公共数据集(如 Wikipedia 更新)中提取和处理数据的流水线。以下是一些入门的地方：
- Stream Processing Simplified 介绍了针对 Kafka 用户的 Flink。
- Learn Flink: Hands-On Training 介绍了如何使用 Flink 的 API 来管理时间和状态。
- Get started with Flink in Java 是上手练习。
- Apache Flink 101 讨论了 Flink 的核心概念和架构。
- Build a real-time fraud detection pipeline 通过 kafka 流。
- Build a real-time stream-processing pipeline 通过 Spark 和 Kafka。
开发流式应用程序和服务具有挑战性，因为它们需要不同于传统同步编程的方法。从业人员不仅需要熟悉技术，还需要了解如何通过响应事件和数据流来解决问题，而不是对静态数据应用条件和操作。
虽然您今天选择的技术可能不是您明天使用的技术，但您正在获得的解决问题和流处理技能不会浪费。