在 Apache Flink 中开发和部署作业
Developing and deploy jobs in Apache Flink
我们开始用 Flink 开发一些工作。我们当前的开发/部署过程如下所示：
1.在本地IDE开发代码并编译
2.上传jar文件到服务器（通过UI）
3.注册新工作
然而事实证明，生成的 jar 文件约为 70MB，上传过程需要几分钟。加速开发的最佳方法是什么（例如使用服务器上的 ide？）
一种解决方案是使用版本控制系统，在提交并推送更改后，您可以在服务器本身上构建 jar。您可以为此编写一个简单的脚本。
另一个需要时间和精力的解决方案是设置一个 CI CD 管道，这将使整个过程自动化，并且可以最大程度地减少手动工作.
此外，如果您必须将 jar scp 到集群，请尝试不要使用 fat jar 以最小化 jar 大小。
首先，现在上传 70 MB 应该不需要几分钟。您可能需要检查您的网络配置。当然，如果你的网络不好，那也没办法。
一般来说，我会尽量避免集群测试 运行。它很慢而且很难调试。它应该只用于性能测试或发布到生产之前。
所有逻辑都应该进行单元测试。完整的工作应该进行集成测试，理想情况下您还需要进行端到端测试。我建议对外部系统使用基于 docker 的方法，并对 Kafka 使用 test containers 之类的方法，这样您就可以 运行 来自 IDE 的所有测试。
那么进入测试集群应该是一件难得的事情。如果你发现你的自动化测试没有覆盖到的问题，你需要添加一个新的测试用例并在本地解决，这样大概率会在测试集群上解决。
编辑（处理评论）：
如果您编写 Flink 作业来生成数据更容易，那么这听起来是一个可行的选择。我只是担心你还需要测试那份工作...
这听起来像是你想要一个端到端的设置，你可以在其中连续 运行 多个 Flink 作业并比较最终结果。这是由多个 Flink 作业组成的复杂管道的常见设置。但是，如果它涉及多个团队的组件，则维护起来相当困难，并且可能所有权状态不明确。我宁愿通过大量指标（产生了多少记录，在每个管道中过滤了多少无效记录......）并进行了特定的验证工作来解决它，这些工作只评估（中间）输出的质量（可能涉及人类） ).
所以根据我的经验，要么你可以在一些本地作业设置中测试逻辑，要么它太大以至于你花在设置和维护测试设置上的时间比实际编写生产代码要多得多。在后一种情况下，我宁愿相信并投资于您无论如何都需要的（预）生产的监控和质量保证能力。
如果你真的只是想用另一个 Flink 作业来测试，你也可以 运行 testcontainers 中的 Flink 作业，所以从技术上讲，它不是一个替代方案，而是一个补充。
我们开始用 Flink 开发一些工作。我们当前的开发/部署过程如下所示： 1.在本地IDE开发代码并编译 2.上传jar文件到服务器（通过UI） 3.注册新工作
然而事实证明，生成的 jar 文件约为 70MB，上传过程需要几分钟。加速开发的最佳方法是什么（例如使用服务器上的 ide？）
一种解决方案是使用版本控制系统，在提交并推送更改后，您可以在服务器本身上构建 jar。您可以为此编写一个简单的脚本。
另一个需要时间和精力的解决方案是设置一个 CI CD 管道，这将使整个过程自动化，并且可以最大程度地减少手动工作.
此外，如果您必须将 jar scp 到集群，请尝试不要使用 fat jar 以最小化 jar 大小。
首先，现在上传 70 MB 应该不需要几分钟。您可能需要检查您的网络配置。当然，如果你的网络不好，那也没办法。
一般来说，我会尽量避免集群测试 运行。它很慢而且很难调试。它应该只用于性能测试或发布到生产之前。
所有逻辑都应该进行单元测试。完整的工作应该进行集成测试，理想情况下您还需要进行端到端测试。我建议对外部系统使用基于 docker 的方法，并对 Kafka 使用 test containers 之类的方法，这样您就可以 运行 来自 IDE 的所有测试。
那么进入测试集群应该是一件难得的事情。如果你发现你的自动化测试没有覆盖到的问题，你需要添加一个新的测试用例并在本地解决，这样大概率会在测试集群上解决。
编辑（处理评论）：
如果您编写 Flink 作业来生成数据更容易，那么这听起来是一个可行的选择。我只是担心你还需要测试那份工作...
这听起来像是你想要一个端到端的设置，你可以在其中连续 运行 多个 Flink 作业并比较最终结果。这是由多个 Flink 作业组成的复杂管道的常见设置。但是，如果它涉及多个团队的组件，则维护起来相当困难，并且可能所有权状态不明确。我宁愿通过大量指标（产生了多少记录，在每个管道中过滤了多少无效记录......）并进行了特定的验证工作来解决它，这些工作只评估（中间）输出的质量（可能涉及人类） ).
所以根据我的经验，要么你可以在一些本地作业设置中测试逻辑，要么它太大以至于你花在设置和维护测试设置上的时间比实际编写生产代码要多得多。在后一种情况下，我宁愿相信并投资于您无论如何都需要的（预）生产的监控和质量保证能力。
如果你真的只是想用另一个 Flink 作业来测试，你也可以 运行 testcontainers 中的 Flink 作业，所以从技术上讲，它不是一个替代方案，而是一个补充。