专注思考的时候，时间仿佛也静下来了

Apache Kyuubi [1] 是一个分布式多租户的 SQL 网关，主要功能为接受用户的通过 JDBC/REST 等协议提交的 SQL 并根据多租户隔离策略路由给其管理的 SQL 引擎执行。在最新的 Kyuubi 1.8 版本，Kyuubi Flink Engine 迁移到 Flink SQL Gateway（下简称 FSG） API 之上并支持 Flink Application 模式，这让我们能借助 Kyuubi 快速部署生产可用的分布式 Flink SQL 网关。

在分布式计算中，Shuffle 是非常关键但常常容易被忽视的一环。比如著名的 MapReduce 的命名跳过 Shuffle ，只包含其前后的 Map 跟 Reduce。背后原因一方面是 Shuffle 是底层框架在做的事情，用户基本不会感知到其存在，另一方面是 Shuffle 听起来似乎是比较边缘的基础服务。然而，笔者认为大数据计算与在线服务最基础的区别之一正在于 Shuffle。

前不久笔者在 Flink 社区讨论 Flink SQL 中 Savepoint 的 SQL 语法时（见 FLIP-222 [3]），曾提议过参考数据库的 Savepoint 语法。虽然最终未能获得 Flink 社区的大多数赞成，但也引发了笔者的好奇心: Flink Savepoint 和传统的数据库 Savepoint 究竟有何异同？于是经过笔者一番调研与思考，便有了这篇文章。

谈起 Immutability (不可变性)，相信大多数读者先想起的是编程语言中的 final、const 之类的常量关键词或 ImmutableMap 之类的数据结构。不可否认，它们是日常开发中的实用工具，但这仅是 Immutability 的最基础应用，而在更深入的领域，比如编程范式、数据库、服务架构设计，同样无不处处体现着 Immutability 的理念。Immutability 通常意味着用直接赋值以外的方式来表达更新，本文就来谈谈这些方式提供何种特性及其如何让我们的程序设计受益。

众所周知，流场景和批场景最为根本的区别在于 Data Boundness（数据集有界性）。Data Boundness 将数据分为 Bounded 和 Un-Bounded。在业界过去多年的实践中，两者分别绑定对应领域的存储系统和计算引擎，然而在流批一体的趋势下，领域的边界在逐渐弱化。例如，消息队列通常用作流场景，但 Pravega 的 StreamCut 支持将指定队列中某一段消息作为批处理的输入[1]。在混合使用流批的场景下，不少原本大家习以为常的设定都需要重新去审视，其中的一项便是数据集内部的边界。

流计算（Stream Processing）和服务网格（Service Mesh）本分别属于大数据和在线服务两个不同的领域，放在一起比较并不常见，但从本质而言两者都是分布式的运行时系统（Runtime）或基础设施，并提供专用的编程 API 或 SDK 供用户在其上运行任意代码。若不论效率，流计算提供的海量数据流式处理功能改为使用服务网格同样可以实现，反之某些服务网格提供的在线服务通过一定改造也可以运行在流计算引擎之上。当然，实现中大概没有人会将它们的使用场景搞混，但随着实时数据服务与在线服务的边界逐渐模糊，在某些数据密集型系统里，流计算和以服务网络为代表的微服务的确都可以作为技术选型的选项，比如事件驱动（Event Driven）应用。

随着近年来流式 SQL 理论逐渐完善，在实时流计算场景中的提供与离线批计算类似的 SQL 开发体验成为可能，GCP Dataflow、Apache Flink、Apache Kafka、Apache Pulsar 都纷纷推出 SQL 支持。在开源领域中，Flink SQL 毫无疑问是流式 SQL 领域最为流行的框架之一，但由于 Flink SQL 缺乏类似 Hive Server2 的服务端组件，各大厂对 Flink SQL 平台化的实现方案各不相同，而本文将介绍在网易游戏在 Flink SQL 平台化上的探索和实践。

相信身处于大数据领域的读者多少都能感受到，大数据技术的应用场景正在发生影响深远的变化: 随着实时计算、Kubernetes 的崛起和 HTAP、流批一体的大趋势，之前相对独立的大数据技术正逐渐和传统的在线业务融合。关于该话题，笔者早已如鲠在喉，但因拖延症又犯迟迟没有动笔，最终借最近参加多项会议收获不少感悟的契机才能克服懒惰写下这片文章。

在生产环境中，Flink 通常会部署在 YARN 或 k8s 等资源管理系统之上，进程会以容器化（YARN 容器或 docker 等容器）的方式运行，其资源会受到资源管理系统的严格限制。另一方面，Flink 运行在 JVM 之上，而 JVM 与容器化环境并不是特别适配，尤其 JVM 复杂且可控性较弱的内存模型，容易导致进程因使用资源超标而被 kill 掉，造成 Flink 应用的不稳定甚至不可用。

文本由笔者在 Flink Forward Asia 2020 上的分享《网易游戏基于 Flink 的流式 ETL 建设》整理而成。