PostNL 如何使用 Amazon 管理服务处理数十亿 IoT 事件

关键要点

PostNL 是荷兰指定的全球邮政服务提供商，处理大量 IoT 设备的实时数据。为了应对旧有 streaming 处理解决方案的局限性，PostNL 迁移至 Amazon 管理服务，以利用 Apache Flink 的强大能力。Apache Flink 的许多功能，特别是事件时间语义和可扩展性，帮助 PostNL 实现了高效、可拓展的流处理解决方案。迁移过程中的学习经验强调了理解事件时间语义和 API 的重要性，并警示开发者在使用时需要谨慎。

在这篇文章中，我们介绍了 PostNL 的传统流处理解决方案及其面临的挑战，以及 PostNL 如何选择 Amazon 管理服务 以现代化其物联网IoT数据流处理平台。我们提供了参考架构，描述了迁移至 Apache Flink 的步骤，以及在此过程中获得的经验教训。

通过这次迁移，PostNL 能够建立一个可扩展、强大且可扩展的流处理解决方案，适用于其 IoT 平台。Apache Flink 非常适合 IoT 领域，通过横向扩展，能够处理由 IoT 设备生成的海量数据。借助事件时间语义，即使来自偶尔断开连接的设备也能正确处理生成事件的顺序。

PostNL 对 Apache Flink 的潜力感到兴奋，并计划将其用于其他流应用场景，同时将更多业务逻辑向上转移到 Apache Flink 中。

Apache Flink 和其管理服务

Apache Flink 是一个分布式计算框架，允许进行有状态的实时数据处理。它提供了一组单一的 API，用于构建批处理和流处理作业，使开发人员能够轻松处理有界和无界数据。管理服务允许开发者轻松托管 Apache Flink 应用程序，而无需深入专研构建、配置和维护 Apache Flink 集群。

挑战：实时 IoT 数据的大规模处理

如今，PostNL 的 IoT 平台 Roller Cages 解决方案 正在实时追踪超过 380000 资产，利用蓝牙低功耗BLE技术进行监控。该平台旨在通过利用来自蓝牙设备的 GPS 点和加速计传感器数据，提供每个资产的可用性、地理围栏和底层状态事件。这些事件被不同的内部用户用来简化操作规划，提高效率和可持续性。

IoT 工作流组件

以下是从边缘到下游系统的整体流向的示意图：

工作流程由以下组件组成：

边缘架构：包括作为遥测数据源的 IoT BLE 设备和将这些设备连接至 IoT 平台的网关设备。输入层：包含 AWS 服务，如 AWS IoT Core 和 Amazon API Gateway，以通过 MQTTS 或 HTTPS 收集 IoT 检测，并使用 Amazon Kinesis Data Streams 将数据传送到源数据流。聚合应用：过滤 IoT 检测数据，在固定的时间窗口内进行汇总，并将聚合结果传输出去。事件生产者：由不同状态服务组合而成，生成 IoT 事件如地理围栏、可用性、底层状态和在途状态。输出层：包括 Amazon EventBridge、Amazon Data Firehose 和 Kinesis Data Streams 等服务，将生成的事件交付给消费者。消费者：内部团队根据 IoT 事件构建商务逻辑。

该架构的核心组件是聚合应用程序，最初使用传统的流处理技术实现。PostNL 决定在这个关键组件上进行升级，迁移至管理服务的过程将是本文的重点。

迁移至管理服务的决策

随着连接设备数量的增加，处理和聚合海量 IoT 数据的平台需求也日益增强。经过深入分析，PostNL 决定迁移至管理服务，这与不断发展的业务需求相一致：

增强的数据聚合：利用 Apache Flink 在实时数据处理中的强大功能，可以有效聚合来自多个来源的原始 IoT 数据。能够扩展聚合逻辑的能力，可以解锁更复杂的分析和更知情的决策过程。可扩展性：管理服务允许横向扩展应用程序，帮助 PostNL 轻松处理不断增加的数据量。专注于核心业务：采用管理服务后，团队可以专注于实现业务逻辑，开发新用例，而不必分散精力于大规模运营 Apache Flink 的学习曲线。成本效益：管理服务采用按需收费的模式，方便与运营预算相适应。

处理迟到事件的挑战

流处理常见用例需要基于生成事件的时间进行聚合，这称为事件时间语义。在实现这类逻辑时，可能会面临迟到事件的问题。

迟到事件在 IoT 中常见，是由于设备可能会因网络延迟、设备故障或临时断开连接等原因导致。由于 IoT 设备通常在无线网络上通信，数据包的传输可能存在延迟，致使数据的处理顺序无法保证。这意味着一些事件可能在其他事件生成后的几分钟被处理，造成事件顺序混乱。

例如，假设您要聚合生成的事件，如何确保在忽略迟到事件的情况下获得准确结果？可能的解决方案是在等待几秒后丢弃延迟到达的事件，但这可能影响重要信息的完整性和及时性。

Apache Flink 提供了默认的事件时间语义，并通过多种选项处理迟到事件。

强大的流处理 API

Apache Flink 提供了多种常用数据处理任务如窗口、连接、过滤和转换的操作符和库。它还包括超过 40 个连接器，支持多种数据源和接收器。

对于 PostNL 来说，最重要的功能是其 API 提供了不同级别的抽象。您可以选择使用更高层次的抽象如 SQL 或 Table API，从而更易于理解和学习。在您的逻辑变得复杂后，可以转到更低层次的抽象，即 DataStream API，以更接近 Apache Flink 内部处理的方式表达流。

选择 API 抽象级别并不是不可逆转的架构决定，在同一应用程序中可以混合不同 API，以满足特定步骤所需的控制级别。

水平扩展

要处理数十亿个原始事件并随着业务发展而扩展，扩展能力成为 PostNL 的一项基本要求。Apache Flink 设计为能够水平扩展，将处理和应用状态分布到多个处理节点上。

对于 PostNL 而言，聚合原始事件的庞大量级并根据相似特征处理这些事件非常关键，能够使数据流可控，供后续系统使用。这种聚合不仅仅是处理单个事件的简单转换，而是需要能够进行有状态流处理的框架，这正是 Apache Flink 的强项。

先进的事件时间语义

Apache Flink 强调事件时间处理，以根据发生的时间准确和一致地处理数据。借助内置支持的事件时间语义，Flink 能够优雅地处理无序事件和迟到数据。

弹性与保障

PostNL 必须确保即使在应用程序失败或重启的情况下，也不会丢失从设备发送的数据。Apache Flink 提供强大的容错保证，通过分布式快照检查点机制，即使发生故障，也能恢复计算的状态，确保结果的“恰好一次”语义。

选择合适的 Apache Flink API 的旅程

迁移的一个关键要求是完全重现遗留聚合应用的行为，以满足无法修改的下游系统。在窗口语义和处理迟到事件方面，这带来了额外的挑战。

Apache Flink 提供了两种高层次概念来实现事件时间语义，以及处理无序事件的能力：水印和允许的延迟。鉴于 PostNL 必须精确复制现有应用的行为，他们决定在实现中使用 ProcessFunction API，借此获得对应用状态的最精细控制。

部署与优化

在迁移过程中，PostNL IoT 平台团队了解到如何根据数据量、处理速度和有效的迟到事件处理来微调 Flink 应用的性能。团队最终决定将新 Flink 应用以“影子模式”运行，与遗留应用并行，确保正常运作并比较输出结果。

关键收获

在采用管理服务后，PostNL 学会了如何充分利用 Apache Flink 的强大 API，实施复杂的业务逻辑。以下是他们在这段旅程中获得的几条重要经验：

理解事件时间语义：对事件时间语义的深入理解对准确实现与时间相关的数据操作至关重要。使用强大的 Apache Flink API：Apache Flink 的 API 可以创建复杂的有状态流应用程序，这超越了基本的聚合和窗口功能。责任随权力而来：Apache Flink 的高级功能带来了显著的责任，开发者必须确保应用程序的有效性以及在编码和系统设计中的最佳实践。避免混合事件时间和处理时间逻辑：将二者结合可能会造成独特挑战，对保持准确性提出更高要求，需要全面的测试确保性能的良好。

结论

在采用 Apache Flink 的旅程中，PostNL 团队了解到，强大的 API 能够帮助实现多样的业务需求。团队计划将其应用扩展到更多流处理用例，并将业务价值放在优先位置。

欲了解有关管理服务的更多信息，以及选择合适的服务选项和 API 的建议，请访问 Amazon Managed Service for Apache Flink。

关于作者

ar akr 是 PostNL IoT 平台的首席软件工程师。他擅长设计和实施大规模实时数据处理解决方案。

zge Kavalc 是 PostNL IoT 平台的高级解决方案工程师，对于开发兼具创新和高可扩展性的解决方案充满热情。

Amit Singh 是AWS的高级解决方案架构师，与企业客户深入探讨AWS的价值及成功部署设计。

小熊加速器bear458

Lorenzo Nicora 为 AWS 高级流解决方案架构师，广泛帮助客户构建基于云的数据密集型系统。

标签 Apache Flink IoT