Re: The question about the FLIP-45

Hi LakeShen, Sorry for the late response. For the first question, literally, the stop command should be used if one means to stop the job instead of canceling it. For the second one, since FLIP-45 is still under discussion [1] [2] (although a little bit stalled due to priority), we still don't s

flink cpu 随机性飙高排查

https://issues.apache.org/jira/browse/FLINK-16721 各位大佬，在jira上面提了个issue，就是我的flink tm进程不时有内存飙高的现象 使用busy thread抓线程，java线程并没有发现明显的飙高现象。 查看stackoverflow说这类问题可能是iowait引起的。 想问下有碰到过类似情况，或者有排查思路的吗？ 先谢谢了

Re: Flink1.10执行sql超出内存限制被yarn杀掉

Hi Faaron, 内存超用被杀说明是 native memory 用的比实际配置多，常见有以下几种可能： - JVM Overhead 配置大小不够。这个默认大小是 TM 大小的 10%，但是不会超过 1G。你的情况是 TM 的总内存比较大，可以尝试调大一点。相关配置项：taskmanager.memory.jvm-overhead.[min|max|fraction] - UDF 中使用了 native memory，可能是用户代码，也可能是依赖的第三方库。这种属于 task off-heap 内存，默认大小是 0，相关配置项：taskmanager.mem

flink 1.9.2 容器ha部署是jobid 一直是00000000000000000000000000000000

大家好，我在用flink 1.9.2 部署到容器的时候如果不启动ha的情况下jobid是正常的，但是启动了就变成了 这样的话，checkpoint的地址和ha的文件地址都一样了，导致checkpoint总是失败。 不知道这是什么原因呢？

Re: Flink1.10执行sql超出内存限制被yarn杀掉

Hi, 建议使用 Profiling 工具查看下堆内内存的使用情况，或者使用 MAT 等内存泄漏分析工具，找出具体的瓶颈所在（有可能是用户自定义的数据结构导致的问题）。如果发现堆内占用不大，则可能是堆外内存（native 部分）导致的，那么也可以用 jemalloc 和 jeprof 等工具来辅助定位。 On Mon, Mar 23, 2020 at 10:12 PM faaron zheng wrote: > > 大家好，我在用flink1.10执行sql时，当数据比较大的时候，3T左右，100多亿条数据，在执行hash和sort的时候经常超出内存限制，被yarn杀掉，我的tm给了

Re: Flink1.10执行sql超出内存限制被yarn杀掉

Hi farron , 能否在详细描述一下你的 SQL 的逻辑 faaron zheng 于2020年3月23日周一 下午10:12写道： > > 大家好，我在用flink1.10执行sql时，当数据比较大的时候，3T左右，100多亿条数据，在执行hash和sort的时候经常超出内存限制，被yarn杀掉，我的tm给了40g内存，每个有10个slot，每个slot3g内存。我也试过给更大的内存，但是没什么效果。不知道这是什么原因？ > > > >

关于 SQL DATE_FORMAT 的时区设置的构想

Hi, 近期发现 Flink 的 Blink Planner 在 DATE_FORMAT 对 CURRENT_TIMESTAMP 做时间格式化为字符串时，默认以 UTC+0 为准。 长期以来，TableConfig 类里面有一个 setLocalTimeZone 方法；将其设置为东八区以后，发现格式化后的字符串仍然是 UTC+0 的。而深入来看，Flink 的时间格式化时的代码生成逻辑（time.scala）并未考虑时区的设置。 由于大多数用户的时区均不是 UTC+0（GMT、UTC），如果时间格式化、显示等都可以考虑到 TableConfig 中的时区设置，那么 Flink 是否会更

Flink1.10执行sql超出内存限制被yarn杀掉

大家好，我在用flink1.10执行sql时，当数据比较大的时候，3T左右，100多亿条数据，在执行hash和sort的时候经常超出内存限制，被yarn杀掉，我的tm给了40g内存，每个有10个slot，每个slot3g内存。我也试过给更大的内存，但是没什么效果。不知道这是什么原因？

Re: FLINK SQL中时间戳怎么处理处理

I created to track this issue: https://issues.apache.org/jira/browse/FLINK-16725 Best, Jark On Mon, 23 Mar 2020 at 18:23, Zhenghua Gao wrote: > 你定义的Kafka source使用JsonRowDeserializationSchema 解析json字符串并将其转换为Flink types > [1]。 > 目前JsonRowDeserializationSchema 仅支持 RFC 3339兼容的时间字符串 [2]。 > > [1] > >

Re: 使用blink planner读取mysql数据

Hi, DDL 是定义了元数据，首先你需要先在 Flink SQL 中用 DDL 定义你在 mysql 中的 student 表。比如 CREATE TABLE student ( id BIGINT, score INT ) WITH ( 'connector.type' = 'jdbc', 'connector.url' = 'jdbc:mysql://localhost:3306/flink-test', 'connector.table' = 'student', ... ) 然后，如果你想要查询数据，可以通过 Flink SQL query 来查询，如

??????????flink????????????

??es??flinkhdfssetBatchSiz ??hive

Re: FLINK SQL中时间戳怎么处理处理

你定义的Kafka source使用JsonRowDeserializationSchema 解析json字符串并将其转换为Flink types [1]。 目前JsonRowDeserializationSchema 仅支持 RFC 3339兼容的时间字符串 [2]。 [1] https://github.com/apache/flink/blob/master/flink-formats/flink-json/src/main/java/org/apache/flink/formats/json/JsonRowDeserializationSchema.java#L446 [2] ht

Re: flink 1.10.0中内存分配问题和超时问题

Hi, Requested resource profile (ResourceProfile{UNKNOWN}) is unfulfillable 这个应该是 jobmanager 日志里面的报错，有没有看过 taskmanager 日志，心跳超时的原因是什么？ 另外，你提到你的作业是流处理，是否用了 state，statebackend 的类型是什么？在同等大小情况下，Flink 1.10 默认配置相比 Flink 1.9，会分配更多的堆外空间，而 JVM 堆空间的会变小。对于无状态或者使用 HeapStateBackend 的作业，建议是把 taskmanager.memory.

????blink planner????mysql????

hi??Allblink planner??batch modemysqlJDBC Connector CREATE TABLE MyUserTable ( ... ) WITH ( 'connector.type' = 'jdbc', -- required: specify this table type is jdbc 'connector.url' = 'jdbc:mysql://localhost:3306/flink-test', -- required: JDBC DB ur

回复： Flink 1.10 的 JDBCUpsertOutputFormat flush方法的重试机制无法生效

好的，我会调整下JIRA描述并提交代码，感谢大家回复～ -- 原始邮件 -- 发件人: "Jingsong Li"https://issues.apache.org/jira/browse/FLINK-16281 > > Best, > Jingsong Lee > > On Mon, Mar 23, 2020 at 2:34 PM lucas.wu http://shipilev.net/blog/2016/arrays-wisdom-ancients/ > >

FLINK SQL????????????????????

?? kafkajson?? {"id":5,"price":40,"timestamp":1584942626828,"type":"math"} {"id":2,"price":70,"timestamp":1584942629638,"type":"math"} {"id":2,"price":70,"timestamp":1584942634951,"type":"math"} timestamp??13SQL??   -

回复: 回复：Flink 1.10 的 JDBCUpsertOutputFormat flush方法的重试机制无法生效

Hi, 如果每用一次都 open close 的话，吞吐量会下降很多的。建议还是遇到问题时再重连好一些。 Best, Weike -邮件原件- 发件人: 出发 <573693...@qq.com> 发送时间: 2020年3月23日 下午 2:37 收件人: user-zh 主题: 回复：Flink 1.10 的 JDBCUpsertOutputFormat flush方法的重试机制无法生效 可以建议在计算层那里，获取连接，用完之后手动close，open只是负责初始化连接池。 -- 原始邮件 

回复：Flink 1.10 的 JDBCUpsertOutputFormat flush方法的重试机制无法生效

可以建议在计算层那里，获取连接，用完之后手动close，open只是负责初始化连接池。 -- 原始邮件 -- 发件人: "lucas.wu"http://shipilev.net/blog/2016/arrays-wisdom-ancients/ Query[] queries = batchStatements.toArray(new Query[0]); ParameterList[] parameterLists = batchParameters.toArray(new ParameterList[0]);

Re: Flink 1.10 的 JDBCUpsertOutputFormat flush方法的重试机制无法生效

Hi, > 加上判断，如果connection被关闭，则进行重新尝试连接 👍，完全可以，合理的需求，可以考虑改下JIRA的描述。(可以贡献那就更好了) Best, Jingsong Lee On Mon, Mar 23, 2020 at 3:46 PM shangwen <583767...@qq.com> wrote: > > hi，我简单的看了下你提供的issue，这个应该可以解决如果connection被关闭，第二次执行被误认为正常的问题，另外还有一个问题是，假设我们的connection被关闭了，即使你重试三次，好像也是不能正常的执行，这里的重试如果加上判断，如果conn

回复： Flink 1.10 的 JDBCUpsertOutputFormat flush方法的重试机制无法生效

hi，我简单的看了下你提供的issue，这个应该可以解决如果connection被关闭，第二次执行被误认为正常的问题，另外还有一个问题是，假设我们的connection被关闭了，即使你重试三次，好像也是不能正常的执行，这里的重试如果加上判断，如果connection被关闭，则进行重新尝试连接，直到三次都异常才退出，这样会不会更好点。 -- 原始邮件 -- 发件人: "Jingsong Li"https://issues.apache.org/jira/browse/FLINK-16281 Best, Jingsong

Re:flink 1.10.0中内存分配问题和超时问题

有没有配置TaskManager的MaxMetaspaceSize呢？1.10默认的MaxMetaspaceSize比较小，UserCodeClassLoader加载class之后容易出现Metaspace区溢出，导致TM挂掉。可以在flink-conf.yaml文件里面进行配置 env.java.opts.taskmanager: "-XX:MaxMetaspaceSize=1024m" 在 2020-03-23 14:44:42，"site" 写道： >你好，我在1.9.0升级到1.10.0的过程中，通过官网的升级说明文档了解到1.10版本在内存上有较

Re: Flink 1.10 的 JDBCUpsertOutputFormat flush方法的重试机制无法生效

Hi, 是否[1]能解决你的问题呢？还是说需要单独判断不同的exceptions？ [1] https://issues.apache.org/jira/browse/FLINK-16281 Best, Jingsong Lee On Mon, Mar 23, 2020 at 2:34 PM lucas.wu wrote: > hi ,我们之前写mysql遇到过这种问题，因为任务的open函数是任务启动的时候调用的，是只调用一次的。而open函数里面会对jdbc > connection进行初始化，当jdbc > conection因为各种原因断开的时候，例如空闲时间超过max_