廖嘉逸

作业出现异常，产生了重启或 failover 的情况，我们可能都已经习以为常，甚至对于绝大多数开发者来说，主动重启是遇到问题的第一反应。如果想深层次地定位问题，以及更深程度知道 Flink 的限制，那么了解 Failover 会非常重要。

复杂事件处理(CEP)，在企业内部实践中，又常被称作规则引擎。随着实时数仓的发展，CEP 会成为很多实时计算相关团队的另一个大的发展方向。

上一篇文章 数据湖系列(1) - Hudi 核心功能原理剖析 中讲解了关于 Hudi 的基本概念和功能原理，Hudi 利用主键索引的方法来实现了 Upsert 的语义。Apache Iceberg 也是一个广为应用的数据湖框架，虽然两个框架的设计初衷和思路不同，但如今随着需求逐步丰富，两者对于使用者来说，却是越来越趋于一致了。

随着互联网业务的逐步成熟，数仓和模型训练的基本盘逐步稳固，越来越多的工程师从业务开发需求转移到了工程的架构升级，而常用的 Hudi 和 Iceberg 往往会成为替代 Hive/Hdfs 等架构升级的选型。

Ray 1.8+ 版本中提出使用 Datasets 来解决模型训练的”最后一公里”问题。由于并未在 Ray 上做过多的实践，所以本文更多是将 Datasets 做了系统化的梳理。关于 Ray 的介绍可以参考 Ray - A Distributed Framework for Emerging AI Applications。

本文聊聊 Flink 中的容错机制及其存在的常见问题，以及在生产实践中遇到的弱一致性场景和解决方案。

本文以 Apache Flink 为例，聊聊为什么 RocksDB 不是流计算引擎中理想的状态存储。Flink 中使用 RocksDB 作为大状态的存储后端，但在实际线上大规模的生产应用中，我们发现 RocksDB 和流计算场景的组合，即使在参数调优及技术优化后，也始终达不到预期的理想状态。

原文：Hazelcast Jet: Low-latency Stream Processing at the 99.99th
Percentile，Hazelcast Jet 是一个流处理引擎，整篇论文通读下来，它的定位和当前广为应用的流计算引擎 Apache Flink 和 Spark Streaming 又有些不同，详见以下文章的解析。

自定义 Flink State 的序列化方式是一种高阶的使用技巧，在很多复杂场景下，通过自定义 Serializer 可以在兼容性、性能等方面获得一定的收益。

RocksDB 的内存管理在 Flink 1.10 版本之前是不受管控的，社区利用 RocksDB 已有的一些内存控制上的优化，在去年对 Flink 中 RocksDB 的使用做了一系列的改造（详见 FLINK-7289）。