在路线图上不断发展的TTL? [英] Evolving TTL On The Roadmap?

问题描述

Flink版本1.8引入了对不断发展的状态架构的支持.我的问题是Flink将介绍对生存时间(TTL)的演变的支持.目前，您无法将TTL添加到未配置TTL的现有状态，并且希望能够恢复状态.我很好奇Flink是否打算在将来打开这种可能性?我现在看到的唯一解决方法可能是在所有状态下都启用TTL，然后设置到期时间，以至于令人难以置信的高设置，这使我可以灵活地在以后使用TTL功能(如果我仍然对此感兴趣).当然，到期是基于有意义的业务逻辑而不仅仅是一些极高的数字.

Flink version 1.8 introduced the support for evolving state schema. My question is will Flink introduce support of evolving time to live (TTL) to state. Right now you can't add TTL to an existing state not configured with TTL and expect to be able to restore state. I'm curious if Flink intends to open this possibility up in the future? The only work around I see might now is to enable TTL on all my state and then just set the expiration so something unbelievable high which gives me the flexibility to use the TTL features later down the line if I am still interested in it. Of course with a expiration that is based on meaningful business logic and not just some extremely high number.

生存时间来源:不断发展的状态架构来源: https://ci.apache.org/projects/flink/flink-docs-stable/dev/stream/state/schema_evolution.html

Evolving State Schema Source: https://ci.apache.org/projects/flink/flink-docs-stable/dev/stream/state/schema_evolution.html

推荐答案

我无法在邮件列表上回忆起对此的任何讨论，也找不到关于此主题的任何JIRA票证.

I can't recall any discussion of this on the mailing lists, nor can I find any JIRA tickets on this topic.

您提出的解决方法并不理想，因为您将为状态TTL(包括计时器的空间和检查过期状态的处理工作)付出代价，而收效甚微.

The workaround you've proposed isn't ideal, because you will pay the cost for state TTL (both the space for the timers and the processing effort of checking for expired state), with little benefit.

您可能要做的是使用

What you might do instead is to use the State Processor API to migrate your data to new state descriptors. You would use the existing state descriptor to read the data from a state snapshot (savepoint or checkpoint), and then use an updated state descriptor to write the state out to a new savepoint.

这篇关于在路线图上不断发展的TTL?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！