Hi
你好，一般你看到 deprecated 的注释，同时会在 Java doc 中看到类似 "Use XX instead"
的语句，也就是建议使用后面的 XX
关于为什么会被 deprecated 可以查看下引入这个修改的 PR 或者相关的 JIRA
Best,
Congxian
guanyq 于2020年4月4日周六 上午10:30写道：
>
>
>
> 辛苦了！
>
>
> flink的一些方法或者类都被@deprecated修饰
> 1.如何找到相对应建议使用的方法或者类，来替换@deprecated修饰的类或方法？
>
辛苦了！
flink的一些方法或者类都被@deprecated修饰
1.如何找到相对应建议使用的方法或者类，来替换@deprecated修饰的类或方法？
2.如何知道为什么这些@deprecated修饰的类或方法被弃用呢？
Hi
Savepoint 你可以理解为 OperatorId -> State 的一个映射[1]，如果你不指定 OperatorId
则会随机生成一个，所以一般会需要用户指定一个 OperatorId。
另外你使用 SQL，可能 SQL 代码发生变更后，导致最终的作业 DAG 图已经变掉了，也就无法恢复了，首先，你可以看一下你两次执行的作业最终的
DAG 图是否完全一样，另外，可以看一下是否指定了 OperatorId
[1]
Hi
1 不参加 compaction 的不会被删除
2 TTL state 暂时无法做到一到时间就清除（我理解你这里担心不删除会有磁盘打满的风险），实际上现在会周期性的清理 state
的。另外如果你真的希望严格控制 state 的过期时间，或者你可以尝试下 ProcessFunction[1] 自己使用 Timer 相关的来控制
State 的生命周期
[1]
https://ci.apache.org/projects/flink/flink-docs-release-1.10/dev/stream/operators/process_function.html
Best,
集群模式下server ip不能直接拿，比如在哪个taskmanager上执行。 如果实在想实现的话可以自己实现个SourceFunction.
在 2020/3/19 下午8:23，“512348363”<512348...@qq.com> 写入:
例如这个对应的
DataStream
HDFS 上的路径和本地不一样，如果你要看 HDFS 路径的话，可能需要看 Checkjpoint Meta 的相关信息，这个比较麻烦，可以参考
CheckpointMetadataLoadingTest 的相关测试。
我再看了一下你给的 TM Log，看上去是 148 行的 outputStream.close() 出错了（有个比较奇怪的现象是，这里的
outputStream 是本地的文件，但是从错误栈看是 HadoopFileSystem）。你这个是稳定复现的问题吗？如果是的话，能否贴一下打开
debug log，贴一下 JM/TM log，另外能给一个可复现的 作业更好
你好，这个是预期中的。在新的类型系统下，我们将使用 LocalDateTime 作为 TIMESTAMP 类型的默认对象。
同时我们还禁用了 long 和 TIMESTAMP 对象的直接互转。
具体的原因和细节可以看：
https://cwiki.apache.org/confluence/display/FLINK/FLIP-37%3A+Rework+of+the+Table+API+Type+System
Best,
Kurt
On Fri, Apr 3, 2020 at 4:58 PM 1193216154 <1193216...@qq.com> wrote:
>
>
??blinkplanner??proctime??TimeStampLocalDateTime??
org.apache.flink.table.dataformat.DataFormatConverters??TimestampConverter ??
Hi 大家好,
非常感谢大家的反馈！我想与大家分享下调查问卷的结果。我在中英文邮件列表分别发了中英文的调查问卷，调查结果差异较大，很有意思。
*英文问卷*
- Top3 CDC tools: Debezium (66.7%), Oracle GoldenGate (15.6%), Maxwell
(13.3%)
- Top3 databases: PostgresSQL(52.3%), MySQL (50%), MS SQL Server (34.1%)
*中文问卷*
- Top3 CDC tools: Canal (70.7%), Debezium (26.8%), Maxwell
hi all??flink sqlwindow join
hi all??flink sqlwindow join
1.未keyby的话，user1 user2
user3的顺序取决于分区策略，比如forward他们还是会在一个subtask上，顺序还是有序的，如果被打散的话就不确定了
2.keyby的话，可以保证同一个key的后续数据保持有序，不同的key不能保证一定有序
| |
Sun.Zhu
|
|
邮箱：17626017...@163.com
|
Signature is customized by Netease Mail Master
在2020年03月31日 15:39，tingli ke 写道：
HI，再次补充一下我的场景，如下图所示：
1、kafka
Hi
只是配置state.backend.rocksdb.ttl.compaction.filter.enabled 还需要相关的state
descriptor也配置上state ttl config，不确定这里所谓的“不理想”的效果是没有及时删除，还是彻底没有删除？
目前RocksDB的后台清理确实需要依赖于compaction的执行，换言之，如果有部分数据一直没有进入compaction，确实存在理论上的可能性一直不会因为过期而删除，但是这个可能性很低不应该对你的使用体验带来很大的影响。
现在的这两种策略是更新时间戳的策略，只要不再访问，到时间都会因为TTL而自动后台清除的。
13 matches
Mail list logo
