FLINK WEEKLY 2019/33

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

FLINK WEEKLY 2019/33

tison
近日 FLINK 社区的每周社区速报又重新开始发布了[1],鉴于 FLINK 中文社区已经发展到开设了一个专门的 user-zh
邮件列表,我打算试着编纂中文版的 FLINK 社区每周速报。

本次首发在这里[0],根据和社区讨论的结果,以后会同步发布在邮件列表上,同时针对邮件列表的阅读形式做格式上的调整。
英文版的 WEEKLY 主要关注在开发(develop)和社区新闻事件(event)上,而我发现中文社区的用户对大多在海外的 event
兴趣不大,反而对一些 FLINK 常见的问题的解答需求量较大。因此我会在第一个部分先选出 FLINK 社区 user 列表和 user-zh
列表上一些有意义的 QA 邮件。因为我主要 focus 在 runtime 的部分,所以对其他模块尤其是 SQL
的部分不甚了解,暂时不予摘录。如果有同学想要一起合作写 WEEKLY 也欢迎私信联系。
本次 WEEKLY 的结构为 USER 用户问题的解答,DEV 社区开发和提议的进展,NEWS 社区新闻,以及最后作为第一次 WEEKLY 附录的
FLINK 邮件列表的加入方法。
USER
Flink 1.8 run 参数不一样
<https://lists.apache.org/thread.html/061d8e48b091b27e797975880c193838f2c37894c2a90aa6a6e83d36@%3Cuser-zh.flink.apache.org%3E>
涉及到 FLINK 1.8.1 之后将 pre-bundle 的 Hadoop 包分开 release 的问题,需要单独下载或者指定已有的
Hadoop 路径。
[DISCUSS] Flink Docker Playgrounds
<https://lists.apache.org/thread.html/4f54c0b4162e3db8626afdca5c354050282282d3cc229d01f2d8ca3e@%3Cdev.flink.apache.org%3E>
Fabian Hueske 表示社区发布了一个 Flink Docker 的样例镜像,可以为想在 Docker 上部署 Flink
的用户提供一个方便尝试的方式。
Why available task slots are not leveraged for pipeline?
<https://lists.apache.org/thread.html/2d391d03302cc83670b0198c682225e0f44d38b20353978cd73dae3c@%3Cuser.flink.apache.org%3E>
FLINK 调度时 slot 使用与并行度的关系,涉及到 operator chain 的作用。
flink on yarn,提交方式是per job的话,如何保证高可用?
<https://lists.apache.org/thread.html/463f57821ace24b58bc046daa96c37efed1b4bb84d141cd0bfa2bbe7@%3Cuser-zh.flink.apache.org%3E>
回答介绍了 FLINK 高可用机制的实现。
What should the "Data Source" be translated into Chinese
<https://lists.apache.org/thread.html/8a041adc57c36b2228cdc7394a0442db61a39e82c382e598f8842805@%3Cuser-zh.flink.apache.org%3E>
FLINK 文档中文翻译中关于 Data Source 一词翻译的讨论。FLINK 文档中文翻译由 Jark Wu 主导,Umbrella Issue
为 FLINK-11529[2],是中文社区用户参与到社区贡献的一个好起点。
How many task managers can Flink efficiently scale to?
<https://lists.apache.org/thread.html/40392ecd9e39a0c45cf56cf3e35a07f44598adaa58a2c89633215498@%3Cuser.flink.apache.org%3E>
FLINK 能够处理多大规模的集群?阿里巴巴的开发者分享了内部实践经验,并介绍了一些常见的瓶颈。
Launching Flink server from IntelliJ
<https://lists.apache.org/thread.html/db84e43036b26f990b8cc99f011669474f2b7993e03def815c15c1b6@%3Cdev.flink.apache.org%3E>
如何在 IntelliJ IDEA 中运行 FLINK 程序?
DEV
过去两周 FLINK 社区一共有 6 个 FLIP(FLINK Improvement Proposals
<https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals>)被提出,可以看到
FLINK 社区在 1.9.0 顺利进入 release 阶段后关于下一阶段的开发的讨论热度持续上升中。
[DISCUSS] FLIP-49: Unified Memory Configuration for TaskExecutors
<https://lists.apache.org/x/thread.html/3609c0fdf05c642d7a569fd60c860e6eef85690d6bb3d962d8ef487c@%3Cdev.flink.apache.org%3E>
Xintong Song 的 FLIP-49 主要是为了解决流和批不同的存储配置和 RocksDB 难以配置的问题。通过重构
MemoryManager/TaskManager 和 Configuration 自身来支持统一的配置接口和提高配置项的可读性。这个 FLIP
还在讨论的早期阶段。
[DISCUSS] FLIP-50: Spill-able Heap Keyed State Backend
<https://lists.apache.org/x/thread.html/a10cae910f92936783e59505d7b9fe71c5f66ceea4c1c287c87164ae@%3Cdev.flink.apache.org%3E>
Yu Li 的 FLIP-50 旨在实现一个新的 State Backend,Spill-able Heap Keyed State
Backend,它将能够有效的减少作业执行中出现 OOM 的几率。这个 FLIP 已经进入到了 VOTE 的阶段。
[DISCUSS] FLIP-51: Rework of the Expression Design
<https://lists.apache.org/x/thread.html/cebf8a8f3915234392837717c89fdc53ece276a9284e414693bbe5fb@%3Cdev.flink.apache.org%3E>
JingsongLee 的 FLIP-51 由 FLINK 社区整合 BLINK planner 的过程提出,是 FLINK SQL
功能优化一部分。FLINK 的 SQL 功能高度依赖 Calcite,这一 FLIP 将减少 FLINK Expression 和 Calcite
RexNode 之间转换的复杂性,同时使得 TableAPI 和 Calcite 的 definitions 更一致。目前这个 FLIP 已经进入到了
VOTE 的阶段。
[DISCUSS] FLIP-52: Remove legacy Program interface.
<https://lists.apache.org/thread.html/0dbd0a4adf9ad00d6ad869dffc8820f6ce4c1969e1ea4aafb1dd0aa4@%3Cdev.flink.apache.org%3E>
Kostas Kloudas 的 FLIP-52 基于我此前提出的讨论[3]和调查[4],主要是从 codebase 中去掉 Program
接口和相关的代码路径。这个接口早期作为 FLINK 的前身 Stratosphere 提供给用户提交任务的接口,在 FLINK
的发展过程中已经无人问津了。Program 的废弃和移除也作为正在讨论的 Client API 重构的一部分。这个 FLIP
已经被社区接受并进入实现阶段。
[DISCUSS] FLIP-53: Fine Grained Resource Management
<https://lists.apache.org/x/thread.html/5ca4e34e8f0291efa78e577f131dd2e253dc0797f19a2757af4fae4f@%3Cdev.flink.apache.org%3E>
Xintong Song 的 FLIP-53 旨在重构 FLINK 的资源管理模块,真正激活 FLINK 中 ResourceProfile
类及其相关逻辑。目前 FLINK 的资源管理是比较粗粒度的,基于 slot 来分配资源,并且具体资源难以配置。FLIP-53
试图提出一个在批和流上统一的资源管理视图,并提供细化的配置资源和动态的更改资源配置的能力。这个 FLIP 还在讨论的早期阶段。
[DISCUSS] FLIP-54: Evolve ConfigOption and Configuration
<https://lists.apache.org/x/thread.html/a56c6b52e5f828d4a737602b031e36b5dd6eaa97557306696a8063a9@%3Cdev.flink.apache.org%3E>
Timo Walther 的 FLIP-54 的出发点是在开发 TableAPI 相关功能时发现 FLINK 的 ExecutionConfig 和
TableConfig 不容易配置,进而提出了一个更一般的问题,FLINK
的用户配置在内部应该提供一个一致的视图,应该支持方便的演进,即加入新的配置项。这个 FLIP 还在讨论的早期阶段。
Rework threading model of CheckpointCoordinator
<https://issues.apache.org/jira/browse/FLINK-13698>
Piotr Nowojski 和 Biao Liu 合作的 FLINK-13698 主要是为了统一 CheckpointCoordinator
的线程模型。FLINK 的各个组件设计之初都有一个类似于 actor
模型的单个主线程模型的设计,但是随着代码的演进线程模型越来越混乱,许多难以排查的阴魂不散的 BUG
都由此而起。梳理和重构组件的线程模型有助于减少由于不必要的或者没有良好管理的并发带来的稳定性和性能问题。
[DISCUSS] Best practice to run flink on kubernetes
<https://lists.apache.org/thread.html/cb38999f67885d9cf2de180b503fa140332167f33946ca85c4ee6dc4@%3Cdev.flink.apache.org%3E>
Yang Wang 提出的关于 FLINK on k8s 的讨论继续了 FLINK-9953 的工作,目的是基于 FLINK 的架构实现 k8s 的
ResourceManager 以原生的支持 FLINK 在 k8s 上的部署执行。
Checkpointing under backpressure
<https://lists.apache.org/x/thread.html/fd5b6cceb4bffb635e26e7ec0787a8db454ddd64aadb40a0d08a90a8@%3Cdev.flink.apache.org%3E>
来自 Apache Beam 社区的 Thomas Weise 发起了在 back pressure 严重的场景下 checkpoint
机制运行的讨论。结合 FLINK 网络栈的实现尝试整理出 FLINK 在这种情境下会遇到的问题,已知的解决方法和未来相关代码的演进方向。
[DISCUSS] Flink Python User-Defined Function for Table API
<https://lists.apache.org/thread.html/77e660458cfd8b9a8585b13a8c5ac806eaee6c4ebccf9569c46add86@%3Cdev.flink.apache.org%3E>
jincheng sun 发起了 FLINK Python Table API 增强的讨论,旨在增强 Flink Python 对用户定义的
Table API 函数的支持。
[DISCUSS] Flink client api enhancement for downstream project
<https://lists.apache.org/x/thread.html/ce99cba4a10b9dc40eb729d39910f315ae41d80ec74f09a356c73938@%3Cdev.flink.apache.org%3E>
Aljoscha Krettek 的加入再次激活了 Client API 重构的讨论,这个讨论最早由 Jeff Zhang
提出,我在中途加入到讨论和设计之中。Client API 的重构目的是统一 FLINK
在不同类型的集群上部署不同类型的任务的视图,为用户提供一个一致的部署集群提交任务的接口。同时,提供面向用户的 FLINK
部署提交的编程接口,在目前基于命令行工具和 REST 接口的交互方式之外,支持更加自定义的、更细粒度的交互支持。一个典型的例子就是上层生态的
FLINK 任务管理项目软件能够依赖公开稳定的接口来提供封装后更丰富的集群部署和作业提交功能。
NEWS
[ANNOUNCE] Andrey Zagrebin becomes a Flink committer
<https://lists.apache.org/x/thread.html/fb61b397e25461956e4f94fa0aca69f9f3b98093aea8fbe4b4dbfbbe@%3Cdev.flink.apache.org%3E>
Andrey Zagrebin 当选为 FLINK 新的 Committer,他主要为 State TTL 和 Shuffle Service
方面的功能贡献了核心代码,同时也是 user 列表上活跃的问题回答者。
[VOTE] Apache Flink Release 1.9.0, release candidate #2
<https://lists.apache.org/x/thread.html/c0605ec027777815fe3a8618a6c26f7d5d443fabcdfd18789bb81028@%3Cdev.flink.apache.org%3E>
FLINK 1.9.0 正式的第一个 RC 发布,Tzu-Li (Gordon) Tai 作为本次的 Release Manager
管理发布过程,FLINK 的用户也可以在自己的环境下下载或编译 1.9.0-rc2 帮助社区测试新版本的稳定性和性能。

UPDATE: 目前已经是 RC3 了
https://lists.apache.org/x/thread.html/913abfd050a5ab48ba839515f1f0bece51c444bb83af51800750af8d@%3Cdev.flink.apache.org%3E
帮助社区做新版本 RC 的测试也是重要的贡献 >_<

APPENDIX

(能收到这封邮件的同学应该也不用读这一段了2333)

订阅 FLINK user-zh 列表的方法是发送任意邮件到 [hidden email],注意这个
subscribe 后缀,收到一封确认订阅的邮件后回复那封确认订阅的邮件,订阅成功后就可以收到别人发送到
[hidden email] 的邮件。当自己有疑问或者想讨论的内容的时候,就可以把邮件发送到
[hidden email] 这个地址,这样其他订阅的用户也能看到。回复别人邮件的时候,记得回复的也是
[hidden email] 而不是发出邮件的用户的个人地址。只有发到 [hidden email]
的邮件才能被订阅的用户收到。
国内不少开发者对这种比较古老的邮件列表的交流方式不熟悉,容易发到 [hidden email]
订阅,这个是无效的,而且会造成用于讨论的 [hidden email] 列表出现无意义的订阅邮件。订阅邮件列表请发送任意邮件到
[hidden email] 这个地址。其他的邮件列表例如 user 和 dev 以此类推。
[0]
https://zhuanlan.zhihu.com/p/78753149
[1]
https://lists.apache.org/thread.html/f5972110283f7bf8c24eb7b2f4ad11cc01f7f359e4221452031e8679@%3Cuser.flink.apache.org%3E
[2] https://issues.apache.org/jira/browse/FLINK-11529
[3]
https://lists.apache.org/x/thread.html/7ffc9936a384b891dbcf0a481d26c6d13b2125607c200577780d1e18@%3Cdev.flink.apache.org%3E
[4]
https://lists.apache.org/thread.html/37445e43729cf7eaeb0aa09133d3980b62f891c5ee69d2c3c3e76ab5@%3Cuser.flink.apache.org%3E