Home

浅谈 Flink - Why Checkpoint

上篇笔记介绍了 Checkpoint 相关的代码, 关于源码的分析网上文章很多,通过断点调试也能大概了解 Checkpoint 的实现。 Checkpoint 的原理,在 Lightweight Asynchronous Snapshots for Distributed Dataflows 里有系统的描述,思路来源于最开始的这篇文章:Chandy-Lamport algorithm,没错,就是发明 Paxos 算法的那位。 这篇笔记希望以简单易懂的方式介绍下我理解的 why checkpoint 以及解决思路。 1. Why 存储系统里的 snapshot,记录的是某个时间点存储的状态,存储可以恢复到这个时间点,用户也可以指定读取这个时间点时的存储内容。不同的 snapsh...

Read more

2021年个人总结

转眼21年已经过去了,无论是互联网还是所在的教育行业,这一年变化都挺大的。一年没有更新博客,主要是工作太忙,以及甩不掉的惰性。 1. 工作 1.1. 大数据实时计算 这两年在作业帮负责大数据实时计算,互联网正在经历很大的变化,包括在线教育。身处其中自然也会有一些特别的体验,我个人觉得这是一个很好的审视的机会。 工作内容上从业务架构转到大数据,虽然设计原则、衡量标准是通用的,但是实际执行起来不同路径差别很大。特别是对于中小公司,短期收益与长期收益同等重要,因此需要在经验较少的情况下摸索一条适合的路出来。这部分完成还算可以,既做架构又做平台再换位用户角度思考,同时抓平台功能、研发质量、稳定性,再加上人手较少,一年下来发际线有点后移。 今年关于工作有两个比较大的感悟: 找到适...

Read more

如何《掌控习惯》

这本书在书架上已经有一段时间,一直没有什么动力翻开来读。我曾经惯性的以为这类书籍,都是心理暗示,不断的重复一个理论,直到你共鸣、相信、并且开始行动。读完之后,我把这本书作为今年目前为止最好的一本书,去年乃至更早是《万历十五年》、《心理罪》、《中国近代史》这些,想不到有一天会这么推崇一本自我管理的书籍。 与之前看过的精力管理的书籍不同,这本书里有众多的论据以及情景设定: 你有没有特别想去跑个步,但是懒得换运动服或者觉得健身房需要绕路太麻烦了,所以没有开始第一次的健身? 你有没有因为某段时间工作太累,回家上床后就是刷手机看视频,从此养成了凌晨一点才入睡的习惯,从此很难改正,而之前你都保持了12点前入睡。 你会疯狂的追剧,会不断的拿起手机查看,直到你的时间被切成任意个碎片,明明过了一...

Read more

浅谈 Flink - State 之 Checkpoint 流程

上篇笔记介绍了从用户视角看如何正确的应用 state,不过要想进一步确认一些猜测,例如对于 kafka-source,是如何确保snapshotState与emitRecord互相阻塞执行的,发送 CheckpointBarrier 时怎么保证 barrier 与普通数据的顺序性?这篇笔记比较简单,我们直接撸一下代码。 1. StackTrace 把上篇笔记例子里的getStackTrace的日志打开,当 source sink 位于不同的 vertex 时,source 的调用是从 SourceStreamTask -> StreamTask -> AbstractUdfStreamOperator: java.lang.Thread.getStackTrace(T...

Read more

浅谈 Flink - State 之 Kafka 写入 HBase

前面介绍了读取 state,这篇笔记介绍下 state 是如何触发写入的。 1. Why 考虑订阅 Kafka 写 HBase 的场景: 写入 HBase 时,为了获取最大的写入性能,可能会先缓存到内存然后批量写入 消费 Kafka 时,需要记录当前的 offsets,方便重启时继续消费。 因此,就需要有数据同步的机制,在上传 kafka 的 offsets 前,确保 hbase 收到了全部数据并且将内存的数据持久化,这就是 flink 里 checkpoint 的作用。 2. How Fault Tolerance via State Snapshots 里这张图从理论上解释的非常清楚: 简单来讲,相比 spark 物理上微批处理的方式,flink 在逻辑...

Read more

浅谈 Flink - JobGraph 之 JobVertexID

上一篇笔记看到 restore state 时找不到 operator id 的问题: Cannot map checkpoint/savepoint state for operator 77fec41789154996bfa76055dea29472 to the new program 这些数字的变化乍看非常奇怪,这篇笔记尝试分析下这些数字是如何生成的并且修复上个例子。 1. 唯一OperatorID OperatorID 对应的就是 StreamGraph 里的节点 id,不过在 Transformation->StreamGraph 阶段,都还是自增的 id。在生成 JobGraph 时,会首先为每个 StreamNode 生成 hashID,代码入口在cre...

Read more

浅谈 Flink - State 之读取 Kafka Offsets

上篇学习笔记通过 Kafka Offsets 以及用户 Count 函数分别介绍了 OperatorState 以及 KeyedState,但当我们使用 flink-SQL 时无法Assigning Operator IDs ,而实际场景中总免不了要查看 state 的需求。 这篇笔记从这个实际需求出发,实现一个 demo 的解决方案,进而相比文档更深入的了解下 flink state 的设计。 1. Mock FlinkKafkaConsumerBase 在不想深入了解 flink state 实现细节的情况下,一个比较自然的想法是:既然Flinkkafkaconsumerbase可以从 state 恢复 offsets,那么我们不妨直接利用该类或者Mock该类去尝试读取 st...

Read more

浅谈 Flink - State 之 Kafka Offsets

1. 概念 Flink 支持有状态的计算。状态即历史数据,例如计算过程中的 pv uv,此外还有数据源例如 Kafka Connector 的 offsets,数据存储比如接收后缓存未持久化的数据。 计算 uv,就需要存储键为 u,值为 count/明细的数据,可以使用外部存储,也可以在计算引擎中存储。在计算引擎中存储的好处是可以做到对用户无感知,例如SELECT user, count(distinct url) GROUP BY user,如果我们只需要写出这样的逻辑,而不用关注distinct url是如何存储的,会是一件很美好的事情。当然同样需要解决接口上的易用性、数据不丢不重的可靠性这类基础问题。 Flink 支持这类需求的机制就是 State. 网上介绍 state...

Read more