行业先锋畅聊 Flink 未来 —— FFA 2021 圆桌会议（北京）

摘要：1 月 8 日，Flink Forward Asia 2021 邀请到了几位国内外顶尖科技公司实时计算方向的负责人，举办了两场圆桌分享。本文为大家带来北京场题为《行业先锋畅聊 Flink 未来》的圆桌分享的精彩内容。本场圆桌主要讨论了三个话题：

1. 如何看待 Flink 与实时计算的未来？

2. 如何看待 Flink 与其他开源项目的关系？

3. 如何看待企业与开源社区之间的关系？

FFA 2021 直播回放 & 演讲 PDF 下载

一、如何看待 Flink 与实时计算的未来

是否可以认为 Flink 在实时计算方面已经趋于成熟？各位嘉宾眼中实时计算的未来是什么样的？距离实现这样的未来，Flink 还需要探索哪些领域、解决哪些问题？

王加胜：功能趋于成熟，应用领域有待扩展

我个人认为，成熟有两个比较重要的标志：功能趋于完善、在核心场景下得到大规模的应用。我认为 Flink 现在在功能层面已经趋于成熟，包括对实时计算和流批一体的支持。但在应用方面，Flink 还需要推广更多的业务。期待 Flink 在更多的领域发挥更大的作用。

董亭亭：流式计算趋于成熟，流批一体仍有较大探索空间

流式计算领域，Flink 已经是业界事实标准，是各公司流式计算选型的首选，在稳定性和易用性方面也越来越成熟。作为流批一体引擎，Flink 在批处理方面仍有较大探索空间，例如动态资源调度、推测执行等能力，以及湖仓一体、OLAP 等应用场景。在这方面，社区和各公司也在积极推动、探索，还不能说是成熟的。

鞠大升：Flink 是一种趋势，未来前景会更光明

从数据处理领域来看，Flink 现阶段已经达成了一种趋势，但还不是成熟。衡量是否成熟要看两个方面：从在业务应用场景的实际使用情况来看，目前 Flink 在流式处理的趋势已经达成，批式处理仍以 Spark 为主，数据湖、增量生产才刚刚起步，所以从应用角度来说，Flink 的使命任重而道远；从技术能力来说，Flink 在批处理、大状态作业执行、容灾恢复等方面还有进步空间。期望 Flink 在数据处理领域发挥更大的作用、增长出更多的能力和场景。

张光辉：流式计算场景相对成熟，技术层面进一步提升

Flink 在流式计算的场景已经相对成熟，在实时数仓、实时 ETL、实时机器学习都已经有大规模落地，随着 Hybrid Source、CDC connector、实时入湖入仓等技术的开源，对业务场景的覆盖面已经比较广了。但在技术层面上，还有一些需要未来进一步探索的地方，比如状态和计算的存算分离、弹性计算应对突发流量的能力、更优秀的容错能力等。

王峰：流计算要走向极致，实时计算不只是流计算

大数据的整体趋势是向实时化演进，Flink 在其中充当了先锋的作用。Flink 在流处理技术方面已经走向成熟，但还没有达到极致。比如，Flink 在云原生的挑战下如何动态的适配弹性扩缩容，如何实现彻底的存算分离架构，如何提升容错能力做到 zero downtime。我觉得在流计算方面，Flink 接下来应该朝着极致方向去演进。

实时计算这个大的概念并不等于流计算。当数据发生变化时，第一时间感知变化、按预定逻辑进行处理，这是流计算所做的事情；同时，实时计算还有其他的形态，比如要对一批数据进行毫秒级、秒级的分析，这依然是实时计算的范畴。Flink 在对存量数据进行高时效分析方面还有很大发展空间，依赖其流批一体的能力、高效的计算引擎可以实现更大场景数据的实时化。

二、如何看待 Flink 与其他开源项目的关系

目前行业内有很多 Flink 与其他生态项目相结合的成功案例，同时 Flink 在许多方面也面临着与其他开源项目的竞争。各位嘉宾如何看待 Flink 与这些生态项目之间的关系？Flink 在整个开源大数据生态中应该如何定位、如何保持差异化？

王峰：保持开放，创新发展、良性竞争

Flink 需要保持开放性，这是开源系统的基本理念。我们需要和其他的开源项目很好地协同，形成生态系统。Flink 目前已经和上下游系统有了很好的对接，通过 connector 可以连接不同的数据库、数据仓库，部署方面也兼容了 Hadoop、Kubernetes 的生态。未来我们需要继续坚持。

Flink 和一些生态项目之间可能会有一些 overlap，这种竞争在我看来是偏良性的。用户需要的其实是完整、方便的体验，可能很难分清楚各个引擎组件的边界。目前看到的趋势，各个生态项目都在扩展自己的边界，基于自己的核心优势向前迈一步，让用户使用更方便，这是一种良性竞争。Flink 也是一样，基于纯流式执行引擎的核心优势，可以构建流批一体的分析能力，兼容离线的一些场景；基于 Flink SQL，可以做短查询、OLAP 分析，做有限数据集的分析、查询加速；Flink 接下来在流批一体的存储数据格式上也会有自己的创新，实现流批一体计算和流批一体存储的结合，实现流式数仓理念，实现一站式大数据分析体验。

所以，我觉得各大生态之间既要保持开放性、能够相互集成和对接，又要有各自的创新发展，给用户更好的体验。

张光辉：合作实现一加一大于等于二

从现状来看，Flink 和其他生态项目之间更多的是合作关系。比如构建实时数仓，上游需要 Kafka，中间使用 Flink，把计算结果导入 Doris 去做实时分析。我认为 Flink 和其他生态项目的合作，能够实现一加一大于等于二的状态。

鞠大升：正确看待竞合关系，发挥优势创造价值

合作与竞争是开源社区经常会遇到的话题。我们应该正确看待合作与竞争的关系，分析自己的优势和劣势，更好地发挥自己的优势，为用户提供更多的能力，这是非常重要的。具体到这个问题，我认为目前在业界有三块：一是 MQ 上的轻量化事件处理能力；二是类似 Kafka、Hudi 数据湖等。这些我认为是偏合作的关系，通过实时更新能力，让数仓更多地达到增量生产的能力，而不单单是批式或者流式处理的数仓；第三是 OLAP 场景，在这方面我认为确实是竞合关系。所谓竞争，是在生产和应用这两个项目时，当其中一个的能力很强时，一定会侵占另一个的市场，这是不可避免的。而这二者无论哪个做的越来越好，都一定会给用户提供更多的价值，这是从合作的角度。比如我们提出实时数仓，采用 Flink + Doris，他们之间是合作的关系，但在某种程度上也是竞争的关系。

关于如何保持差异化的竞争，我觉得 Flink 可以看到自己弱势的地方并加以改进。比如 Flink 的状态对用户是偏透明的，终端用户无法触达状态数据，无法分析，在这一点上可以做的更好。

董亭亭：保持生态融合，提升自身竞争力

关于合作，Flink 是流批一体的计算引擎。如果要实现全链路的流批一体，除了计算引擎的流批一体，还要依赖存储引擎的流批一体。所以，Flink 可以和 Prevaga、Hudi 等存储引擎保持很好的合作关系，和整个生态更加融合，让用户有更多的选择，也能够很好地与其他引擎配合，从而实现真正的全链路流批一体、湖仓一体建设。

关于竞争，在计算引擎领域，各社区确实存在一些竞争关系。Flink 需要提升自己的竞争力，比如在 Batch 引擎能力方面是否能和 Spark 拉齐、是否能够具有可替代性等。

王加胜：专注计算，与存储系统保持合作关系

大数据领域技术发展，存储计算分离更加符合未来的趋势。一方面，存储层和计算层各自迭代，速率更快，更有优势；另一方面，无论存储层还是计算层，单一引擎长时间内都很难支持所有场景，依然需要通过多个引擎来覆盖业务场景，分离的状态可以更多地满足各种场景的需求。因此，Flink 应该专注计算层面，需要和存储层面的相关项目有很好的合作关系，一起为业务提供比较好的使用体验。

Clickhouse、Doris 等项目也在做流式计算的探索，这些项目最大优势在于查询效率等方面，他们做流式计算的探索的优势是降低了用户使用的复杂性。这些项目相对于 Flink 偏弱的是，Flink 在实时计算方面领先比较多，对于实时计算领域的支持更加好。如果 Flink 在使用体验、接入门槛等方面进一步改进的话，加上其强大的功能，依然可以保持非常强的竞争力，能够覆盖更多的应用场景、连接更多系统、支持更多业务场景，在存储计算分离的生态中，在计算层面占据重要地位并保持优势长期发展下去。

三、如何看待企业与开源社区之间的关系

使用和贡献开源项目有哪些优势，过程中遇到过哪些挑战？如何看待企业内部实践创新与开源社区之间的关系？各位嘉宾所在团队都在做哪些有关 Flink 的探索，接下来有哪些规划，有哪些打算贡献社区的创新技术？

王加胜：积极拥抱开源，探索湖仓一体、流批一体

小米对于开源的态度是非常开明的，我们积极拥抱开源，认为开源有很大的优势。一方面，借助开源的力量，我们能通过较少的人力投入，支撑非常复杂的业务场景，满足各种业务的复杂需求；另一方面，通过参与开源，我们能够和业界非常优秀的工程师，共同进行技术交流，提高自己的技术能力。

我们目前在 Flink 方面的探索：一是结合 Flink + Iceberg 做湖仓一体的尝试，希望为业务提供近实时数仓的开发和使用体验；二是流批一体方面的尝试，通过 Flink 把公司内部实时集成和离线集成的技术栈做了统一。后续也会在其他方面进一步探索。我们遇到的挑战，主要来自项目的使用门槛和开发运维体验。开源项目赋予了我们强大的核心能力，在实际业务应用过程中，还是要解决复杂性问题、降低用户使用门槛，这是一个挑战。

关于内部实践与开源社区的关系，我认为每家公司根据自己的特殊场景和需求，基于开源的版本做一些内部特性的适配，是很有必要的。针对这些特性，整体原则是尽量不要侵蚀核心代码，避免和社区割裂导致运维困难。其他一些功能迭代开发方面，我们坚持先到社区参与讨论，吸收业界优秀工程师建议，保证我们的设计是合理的正确的，并争取合并到社区。

董亭亭：开源有很多优势，版本跟进是挑战

开源项目的优势有很多，比如我们可以跟社区做一些交流，遇到问题时可以吸收到很好的想法思路和设计建议，减少试错成本；我们还能够享受到社区代码带来的一些红利，借鉴社区成熟的解决方案，避免重复造轮子。

过去一段时间，快手在 Flink SQL 方面也和社区进行了一些合作，包括跟进、参与社区的一些功能、issue 的开发，也贡献了我们内部自研的像渐进式窗口这样的功能。在引擎方面，我们做了热更新模型、限流策略等在我们内部业务使用场景上反馈比较好的功能，也在和社区讨论准备把这些功能贡献给社区。

我们在跟进社区最新版本的过程中是有一些挑战的。比如一些内部自研功能，不是很通用，适配我们公司内部的一些场景需求。社区新发版本，我们需要把这些功能 Cherrypick 到社区的版本上，在 Cherrypick 代码、推进业务升级等方面会有额外的人力成本。所以我们基本上每隔一年跟进一次社区的最新版本，把内部功能合并到一起。

鞠大升：开源项目加速技术领域的发展应用

我认为开源项目能够很好地加速一个技术或者领域的发展和应用过程。具体来说，一家公司借助开源项目能够很快启动在这个领域的探索。另外，开源项目能够把相关领域的问题集中起来，让大家共同参与解决相关领域的问题，促进相关领域的问题快速迭代、快速解决，促进相关领域的发展。这些方面的优势是非常明显的。

美团在 Flink 方面的规划基本分为三个方面：实时数仓方面，期望通过 Flink + Doris 链路，构建实时数仓开发的场景；增量数仓方面，通过 Flink + Hudi，达到近实时数据产出效果；离线场景下，期望将引擎统一到 Flink。我们期望让业务方根据成本、时效性选择不同场景，保持语言和底层引擎的一致，给业务方提供这样的便利。

使用开源项目的过程中遇到的挑战有两个方面：一是我们发现开源项目普遍不太关注可运维性。可运维性更多需要结合公司内部的生态技术去做，开源社区不知道公司内部运维环境，在这方面关注比较少。这也是大部分公司在使用开源项目时第一个需要解决的困难。二是在开源项目上做的比较深入的时候，如果社区发展比较慢，公司可能是等不及的，需要做很多 Feature 甚至大版本的迭代。这是对公司的一个挑战，反过来也是对社区发展速度的一个挑战。

接下来，我们可能会在 Flink 实时更新的方面做流批一体的尝试，希望这些尝试的方案和想法能够跟社区分享。

张光辉：企业与社区相辅相成、相互促进

字节内部针对 Flink 做了非常多的技术探索。在 SQL 方面更多的是功能方面的探索，比如延迟 join、增加聚合指标、能从 checkpoint 恢复、以及内部的各种 connector。在 state checkpoint 方面我们更多的是性能方面的探索，比如小文件聚合、state 用户可查、通过 cache 减少 RocksDB State Backend 序列化、反序列化的性能损耗。在 runtime 侧，我们更多的是提升稳定性，比如黑名单机制、单点故障恢复能力等。

我认为使用开源项目的优势是，我们能以更少的人力投入、更短的时间，把一套更优秀的技术在内部的业务场景落地。我们遇到的最大挑战是版本升级。社区版本的升级迭代还是比较快的，我们内部积累了非常多的 feature 来不及贡献社区，每次版本升级、业务迁移的成本是非常大的。

我认为内部实践和开源社区，整体上是一个相辅相成、互相促进的关系。具体来说，字节有一些上万并发的超大作业，每次重启需要花费十分钟左右，这是我们业务无法容忍的。我们跟社区沟通了这些问题，社区同学也跟我们积极对接，很快就达成了一系列的解决方案，在后续版本中解决了这些问题，将作业的重启速度提升了 2-3 倍。

未来规划：在实时计算场景，我们会在提升弹性计算的能力、状态的存储计算分离、提高容错性这些方面做一些探索。在流批一体方面，我们会推更多的业务，把 Flink 的优势释放出来，解放和提升业务的生产力。另外我们在短查询方面有一些探索和落地，后续会把这方面做的一些调度性能、SQL 性能的优化回馈到社区。

王峰：推崇开源技术体系与企业业务及人才培养相结合的模式

“开源” 是一个非常有热度的话题。国家规划已经提出，中国在基础的核心技术上要自主可控、开源开放，希望国内各企业能够通过开源形成协同力量、提升国家的软件基础设施。阿里巴巴这些年对开源的拥抱是越来越积极的，也成立了开源委员会。Apache Flink 这个项目也是一个典型代表，相信业界的公司都能感受到阿里巴巴在 Flink 开源项目上的支持和投入。我现在所在的团队，有几十位工程师、核心技术人员是全职投入到 Flink 开源项目。

刚刚董亭亭、张光辉也提到了，快手和字节所在的流媒体行业实施业务量非常大，遇到了很多技术挑战，也希望把在这种极致挑战中解决的问题贡献给社区，可能受限于社区版本发布太快，无法更好的融合。在这一点上我们的经验和建议是，希望国内头部的互联网公司可以更多地投入到开源社区的建设，让公司的工程师有更多的时间投入到开源社区建设里。有越多的人投入，就有越多的机会产生 Committer、PMC Member，在社区就有更多机会发言、有更多机会把自己的东西推入社区，对社区的影响力也就越大，形成良性循环。也希望 Apache Flink 社区能够吸纳到更多公司的 Contributor 参与并成为 Committer，这样刚才很多问题都可以自然地在开源社区中解决。

企业内部技术实践和开源社区是非常密切的关系。我们相信开源社区的贡献者、核心开发者，都在一家技术驱动的公司工作。开源社区中很多的想法和需求，其实是来自于各家企业、各个行业。因此，内部业务的技术实践是开源社区的源泉。此外，开源社区发布的版本，需要到各个企业、行业去实践，这也是开源项目很大的一个优势。开源项目是免费的，大家都愿意去使用，用非常低的成本去拓展市场。这么多用户、行业、公司、场景使用后，会给社区提供丰富的反馈。开源社区基于这些反馈可以快速地迭代，然后再到各个公司去实践。这是开源项目能够快速发展并得到大家认可的一个很好的机制。这里面也包括了技术创新，开源社区是一个纽带，在这里大家能够看到各个公司是怎么使用这个项目的、各个公司的问题是什么，你的创新想法也可以被别的公司使用，形成一个很好的孕育技术创新的环境。企业参与到开源社区里，基于开源开放的技术体系，与自己的业务、人才培养结合起来，我觉得这是一个非常好的模式。

FFA 2021 直播回放 & 演讲 PDF 下载

更多 Flink 相关技术问题，可扫码加入社区钉钉交流群第一时间获取最新技术文章和社区动态，请关注公众号～