Flink 1.15 指日可待，众多改进中包括一个 Scala free的类路径。用户现在可以玩转任何 Scala 版本的 Java API，包括 Scala 3！
本博客将讨论历史上支持多个 Scala 版本如此复杂的原因、我们如何实现这一里程碑，以及 Scala 在 Apache Flink 中的未来。
TLDR：所有 Scala 依赖项现在都与flink-scalajar 隔离。要从用户代码类路径中删除 Scala，请从 Flink 发行版的 lib 目录中删除此 jar。
$ rm flink-dist/lib/flink-scala*类路径和 Scala
如果您使用过基于 JVM 的应用程序，您可能听说过术语类路径。类路径定义了当需要加载给定类文件时 JVM 将在哪里搜索它。每个类路径上可能只有一个类文件的实例，这迫使 Flink 将任何依赖项暴露给用户。这就是为什么 Flink 社区努力保持我们的类路径“干净”——或者没有不必要的依赖。我们通过组合shadow依赖、子类加载和可选组件的插件抽象来实现这一点。
Apache Flink 运行时主要是用 Java 编写的，但包含强制 Scala 使用默认类路径的关键组件。而且由于 Scala 不保持跨次要版本的二进制兼容性，这在历史上需要为所有版本的 Scala 交叉构建组件。但是由于许多原因——编译器的重大变化、新的标准库和重新设计的宏系统——说起来容易做起来难。
隐藏Scala
如上所述，Flink 在几个关键组件中使用了 Scala；Mesos 集成、序列化堆栈、RPC 和表规划器。社区没有删除这些依赖项或寻找交叉构建它们的方法，而是隐藏了 Scala。它仍然存在于代码库中，但不再泄漏到用户代码类加载器中。
在 1.14 中，我们迈出了向用户隐藏 Scala 的第一步。我们放弃了对部分在 Scala 中实现的 Apache Mesos 的支持，Kubernetes 在采用方面远远超过了它。接下来，我们将 RPC 系统隔离到一个专用的类加载器中，包括 Akka。通过这些更改，运行时本身不再依赖于 Scala（这就是为什么 flink-runtime 失去了它的 Scala 后缀），但 Scala 仍然始终存在于 API 层中。
这些变化，以及我们实施它们的容易程度，开始让人们想知道还有什么可能。毕竟，我们在不到一个月的时间里就隔离了 Akka，一个积压多年的任务，被认为太耗时了。
下一个合乎逻辑的步骤是将 DataStream / DataSet Java API 与 Scala 分离。这主要需要对一些测试 类进行少量清理，还需要识别仅与 Scala API 相关的代码路径。然后将这些路径迁移到 Scala API 模块中，并且仅在需要时使用。
例如，我们一直扩展以支持某些 Scala 类型的Kryo 序列化程序现在仅在应用程序使用 Scala API 时才包含它们。
最后，是时候处理 Table API，特别是 table planner，在撰写本文时它包含 378,655 行 Scala 代码。表规划器将 SQL 和表 API 查询解析、规划和优化为高度优化的 Java 代码。它是 Flink 中最广泛的 Scala 代码库，不能轻易移植到 Java。利用我们从为 RPC 堆栈构建专用类加载器和为序列化器的条件类加载中学到的知识，我们将计划器隐藏在一个不暴露其任何内部结构的抽象背后，包括 Scala。
Apache Flink 中 Scala 的未来
虽然这些更改大部分发生在幕后，但它们导致了一个非常面向用户的更改：删除了许多 scala 后缀。
此外，对 Table API 的更改需要对打包和分发进行一些更改，一些依赖规划器内部的高级用户可能需要适应。
展望未来，Flink 将继续支持针对 Scala 2.12 编译的 DataStream 和 Table API 的 Scala 包，而 Java API 现在已解锁，用户可以利用任何 Scala 版本的组件。我们已经看到社区中出现了新的 Scala 3 包装器，我们很高兴看到用户如何在他们的流管道中利用这些工具4！
文章评论