- 博客(412)
- 资源 (14)
- 问答 (1)
- 收藏
- 关注
RSS订阅原创 记录一次排查Flink一直重启的问题
Flink程序陷入重启死循环问题分析及解决过程。最初表现为任务持续重启失败，日志显示卡在RocksDB关闭操作。尝试调整pekko超时参数无效，怀疑与RocksDB相关但未果。临时解决方案是禁用checkpoint并添加重启策略。最终通过异常页面发现每天0点定时报错，与生产环境数据缺失时间吻合。反思指出两个关键失误：未准确记录事故时间点，以及未用Five Whys方法深挖重启根源。问题实际由0点的参数异常引起，修复后恢复正常。该案例凸显了现象记录和根本原因分析的重要性。
2026-02-07 10:37:09
326
原创 Flink 使用 RocksDB 作为状态后端存储的原因详解
RocksDB 作为 Flink 的状态后端，凭借其大容量支持、增量检查点、堆外存储、高性能 I/O等优势，成为生产环境中处理大状态流作业的首选方案。尽管其访问延迟略高于纯内存方案，但在状态规模、容错能力和资源效率方面具有不可替代的优势。合理配置 RocksDB（内存、磁盘、增量检查点）可显著提升 Flink 作业的稳定性与性能。
2025-10-23 22:41:01
1127
原创 Flink 水印（Watermark）最佳实践指南
Watermark= 当前已处理数据最大事件时间 - 允许的延迟时间作用：告诉Flink "从这个时间点之后的数据都已到达，可以安全触发窗口计算"核心公式"分流先行，水印后置"text源数据↓ 无水印分流（filter）↓ 独立水印窗口计算。
2025-10-23 21:36:41
776
原创 如何正确理解flink 消费kafka时的watermark
摘要：文章分析了Flink中watermark生成的三种场景：1）在source层全量数据生成watermark会导致不同业务流互相污染（如order和click事件）；2）通过先filter分流再独立生成watermark可解决污染问题；3）rebalance操作会破坏per-partition watermark的单调递增性，导致watermark不准确。核心结论：watermark生成应尽量靠近数据源且保持分区特性，针对不同业务流需独立处理。（149字）
2025-10-22 22:53:41
432
原创 大数据计算里的Broadcast Hash Join/Shuffle Hash Join/Sort Merge Join
大数据计算里三种JOIN实现
2024-10-31 23:33:51
418
1
原创 一文理解mysql 联合索引和各种SQL语句分析
联合索引有两个rule要记一下，1.左到右，中间不能有skip,2.中间是range,后面不能用索引了联合索引的顺序非常重要，即使上面走了索引，也可能效果不好，正确的顺序是根据业务场景把最能区分的列放在前面，按照这样的顺序从左到右。
2024-09-28 22:18:47
505
原创 一图快速看懂flink source的设计实现
整体来说多个处理流程是解偶的，这样可以在面对多数据源情况下，能更加的灵活。下面只展示了，主要的一些流程。
2024-09-21 21:50:35
355
原创 一文速通calcite结合flink理解SQL从文本变成执行计划详细过程
一文速通calcite结合flink理解SQL从文本变成执行计划详细过程
2024-09-15 22:17:33
985
1
原创 flink 实战理解watermark，maxOutOfOrderness，allowedLateness
【代码】flink 实战理解watermark，maxOutOfOrderness，allowedLateness。
2024-08-29 22:33:29
642
javax.mail.jar
2016-06-25
commons-email-1.3.jar_mail.jar_activation.jar
2016-06-22
hadoop中找不到jobtracker的源码
2017-06-13
TA创建的收藏夹 TA关注的收藏夹
TA关注的人