摘要：1 月 8 日，Flink Forward Asia 2021 邀请到了几位国内外顶尖科技公司实时计算方向的负责人，举办了两场圆桌分享。本文为大家带来北京场题为《行业先锋畅聊 Flink 将来》的圆桌分享的精彩内容。本场圆桌次要探讨了三个话题：
- 如何对待 Flink 与实时计算的将来？
- 如何对待 Flink 与其余开源我的项目的关系？
- 如何对待企业与开源社区之间的关系？
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 相干技术问题，可扫码退出社区钉钉交换群
第一工夫获取最新技术文章和社区动静，请关注公众号～