关于大数据

选择RisingWave是因为我本身对Flink有些了解，再加上RW的代码本身写得还不错，比较易读，因此以它来做为生产级Rust代码的学习对象。 本文基于RW v2.2.0。

上期Fluss的内容还算受欢迎，这期加更，讲讲Fluss RoadMap里提到的Zero Disks是怎么个事儿。 所谓Zero Disks就是把所有的存储放在S3这种远程，容量无限的存储上。

上期讲Flink Forward Aisa的视频比较受欢迎，这期加更讲Fluss。 为了方便新观众了解Fluss。简单介绍一下Fluss，这玩意儿主要是为实时分析而生的流存储。 所以它会有和Kafka

11月29号和30号，Flink Forward Asia 在上海举行。这篇文章给大家搞个省流版，聊聊有什么值得关注的点。

在Dataflow相关的论文发表前，大家都往往认为需要两套API来实现流计算和批计算，典型的实现便是Lambda架构。

前阵子在生产上碰到了一个诡异现象：全量作业无法正常进行，日志中充斥着timeout的报错。场景为Oracle全量抽取至Hive，数据会流过Kafka，数据量为T级别，根据时间字段每天做一个分区。

将Flink应用至生产已有一段时间，刚上生产的时候有幸排查过因数据倾斜引起的Checkpoint超时问题——当时简单的了解了相关机制，最近正好在读Flink源码，不如趁这个机会搞清楚。

前阵子组里的小伙伴问我“为什么Flink从我们的代码到真正可执行的状态，要经过这么多个graph转换？这样做有什么好处嘛？”我早期看到这里的设计时的确有过相同的疑惑，当时由于手里还在看别的东西...

在最初接触到Flink时，是来自于业界里一些头部玩家的分享——大家会用其来处理海量数据。在这种场景下，`如何避免JVM GC带来StopTheWorld带来的副作用`这样的问题一直盘绕在我心头。

前阵子笔者涉及了些许监控相关的开发工作，在开发过程中也碰到过些许问题，便翻读了FLink相关部分的代码，在读代码的过程中发现了一些好的设计，因此也是写成文章整理上来。