FLINK WEEKLY 2019/40

[Zili Chen]

FLINK WEEKLY 2019/40 用户问题

Dynamic stream handling


FLINK 暂不支持流图的动态更新，但这是 FLINK 计划中支持的功能

[SURVEY] What is the most subtle/hard to catch bug that people have seen?


Konstantinos Kallas 发起了一个有趣的调查，关于 FLINK 用户遇到过的最微妙棘手的问题。他和他的团队正准备搭建一个 FLINK
的测试框架，希望能够收集已有的问题的样本

Broadcast state


关于在作业中 Broadcast state 的复用问题

Finding the Maximum Value Received so far in a Stream


场景实现，查找流中当前的最大值

POJO serialization vs immutability


关于 FLINK 中 POJO 实现的细节，由于 POJO 的域是可变的，所以在默认的 hashCode 实现下不能用作键值对的键
已知缺陷

FLINK-14315 NPE with JobMaster.disconnectTaskManager


JobMaster 的竞态条件使得运行中可能抛出空指针异常，已定位到问题，将在 1.10.0/1.9.1/1.8.3 中修复
开发讨论

[SURVEY] Dropping non Credit-based Flow Control


Piotr Nowojski 发起了废除非 Credit-based 的流量控制机制的讨论。在 FLINK 1.5 中引入了 Credit-based
的流量控制机制，目前 FLINK 的网络栈正在活跃发展，废除这部分代码将有利于开发的进行

[jira] [Created] (FLINK-14320) [FLIP-66] Support Time Attribute in SQL DDL


Jark Wu 的 FLIP-66 已经通过投票，开始开发。FLIP-66 旨在提供 SQL DDL 中对时间属性的支持

[DISCUSS] Improve Flink logging with contextual information


Gyula Fóra 发起了关于丰富 FLINK 日志内容的讨论，主要是提供关于 TaskManager/Container/JobId 等信息

[DISCUSS] FLIP-65: New type inference for Table API UDFs


Timo Walther 的 FLIP-65 旨在为 Table API 的用户定义函数提供新的类型接口，这也是新一轮 Table API
开发中的一部分

[DISCUSS] FLIP-76: Unaligned checkpoints


Arvid Heise 的 FLIP-76 引入了 Unaligned checkpoints，旨在优化背压情况下的 checkpoint 性能

[VOTE] FLIP-73: Introducing Executors for job submission

[VOTE]
FLIP-74: Flink JobClient API


Client API 改进的两个 FLIP 进入投票阶段
社区发展

[VOTE] Release 1.9.1, release candidate #1


Jark Wu 作为 1.9.1 的 release manager 拉出了第一个 release candidate

Real-time experiment analytics at Pinterest using Apache Flink


来自 Pinterest Engineering 的开发者分享了他们使用 FLINK 做实时计算的经验

Turning messy data into a gold mine using Spark, Flink, and ScyllaDB


来自 DynamicYield 的 Oran Hirsch 分享了他们基于 Spark Flink ScyllaDB 的数据分析栈

Flink 1.8 版本如何进行 TaskManager 的资源控制

[龙逸尘]

Dear community,
我搭建了一个实时计算平台，由于历史遗留问题，目前使用的 Flink 版本是社区版1.5.0，hadoop版本是2.7.3，采用flink on
yarn ha部署，直接部署在物理机上没有使用 K8S，服务启动采用 flink run 脚本提交 yarn per-job 任务。
目前想将 Flink 版本升级到 1.8 以上的版本，但是遇到了资源控制的问题，情况具体描述如下：
1.5 版本：
任务采用 Legacy 运行模式，一个 TaskManager 对应一个 slot，通过在命令行中设置 -yn 参数来控制 TM
的数量，设置 -ytm 参数来控制 TM 的内存，设置 -s 参数来控制任务的总 cpu 数(slot 数*taskmanager 数)，脚本示例如下：

flink run -m yarn-cluster -d -yjm 2048 -ys 1 -yn 2 -ytm 4096
WordCount.jar

1.8 版本：
任务已经废除 Legacy 运行模式，并将 -yn 参数置为 deprecated，log 如下：
The argument yn is deprecated in will be ignored
追踪源码发现，slot 数仅仅与任务的并行度有关，所以无法通过命令行进行限制总内存与 CPU 数目

我的问题：
1.由于用户代码是直接提交到平台上的，无法知道程序的并行度，是否有机制可以预先限制YARN per-job 模式下 Flink
任务的总内存与 CPU 数目？
2.各位公司搭建的实时计算平台，一般是如何进行运算资源的限制的？

期待解答，祝好!