Home

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

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

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

上一篇笔记看到 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...

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

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

flink 提供多种消费 Kafka 数据的方式，由于不同层级接口支持的功能范围、粒度不同，同时 flink 版本迭代频繁，接口也在不断发生变化，因此使用起来容易混淆。 当我们定义了一个 Kafka 的 DDL，例如： CREATE TABLE MyUserTable ( ... ) WITH ( 'connector.type' = 'kafka', 'connector.version' = '0.11' ... ) 在 DDL 背后都做了什么，使得我们能够通过 SQL 读写这张表？flink 如何组织其代码结构，如何复用 streaming 相关代码的？接口从 API 到 SQL，方式更加简洁的同时，又有哪些功能被忽略掉了？ 这些疑问，在刚...