【Hudi】 更新怎么定位 — File Group + Index
一条更新来了,Hudi 怎么知道要改哪个文件?这就是 File Group 和 Index 要解决的事。 为什么不能扫全表 最简单的更新方案是:找出所有分区里所有 Parquet 文件,逐个读出来,找到要改的行,写回去。这就是全量重写的逻辑。 - 一张 100GB 的表,改一行也要扫 100GB -
一条更新来了,Hudi 怎么知道要改哪个文件?这就是 File Group 和 Index 要解决的事。 为什么不能扫全表 最简单的更新方案是:找出所有分区里所有 Parquet 文件,逐个读出来,找到要改的行,写回去。这就是全量重写的逻辑。 - 一张 100GB 的表,改一行也要扫 100GB -
Hudi 表目录下有个 .hoodie/ 文件夹,里面放的不是数据,是元数据。这套元数据叫 Timeline,是 Hudi 读写一致性的核心。 为什么需要 Timeline Parquet 文件本身是死的——它不会告诉你"我现在是最新版本"还是"已经被更新替代了",也不会告诉你"写我的那个作业成功提
两个写入作业同时往一张表写数据,会不会把对方的数据覆盖掉? 数据模型 先讲 Hudi 的数据模型,因为并发控制的前提是知道每条记录长什么样。 不是所有 Hudi 表都要有主键和分区。 COW 表可以不指定 recordKey,只能做批量追加,每次写入都是新文件。MOR 表必须指定 recordKey
篇 6: Flink → Hudi 实时入湖实战 Hudi 的存储、索引、Timeline、并发控制,每个组件单独看都不复杂。这篇把它们串起来,看一条真实链路:用 Flink 把数据写进 Hudi,在一个场景里把各个概念都过一遍。 场景:订单流水实时入湖 假设有一条 Kafka 流,主题是 orde
写代码几十年了,没有哪个语言能统一所有场景。C/C++ 统治系统编程,Java 统治企业后端,Python 统治数据科学。每种语言都有它擅长的生态,也有它够不着的角落。 FFI(Foreign Function Interface)的存在,本质上是为了两件事: 借用性能。 Python 写数据管道很
FFI 的底层逻辑很简单:两个语言之间要互相调用,总得有个共同的"语言"做桥梁。这个桥梁不是 C 语言本身,而是 C 的调用约定——C ABI。 为什么是 C ABI,不是别的 操作系统内核用什么语言写的不重要。Linux 是纯 C,macOS 的 XNU 混了大量 C++,Windows 内核也是
Python 是数据科学最顺手的语言,但纯 Python 跑计算密集型任务慢得离谱。一个斐波那契递归,纯 Python 算 fib(40) 要几十秒。Rust 算同样的东西,毫秒级。问题是怎么让 Python 用上 Rust 的速度?FFI 提供了三条路。 一个例子看清三道门 先用 PyO3 写个最
Java 从 JDK 1.1 就能调 C,但这条路走了二十多年,一直在"方便"和"快"之间做取舍。四个方案串起来看,就是 Java FFI 的演化史。 JNI:最底层,也最麻烦 JNI(Java Native Interface)是 Java 调 C 的标准姿势。Java 侧写 native 方法,
跨语言调用的核心矛盾只有三个:数据类型怎么传、函数怎么调、内存怎么管。前两个靠 ABI 和绑定工具解决,第三个是最难的——GC 语言和手动管理语言各有自己的内存世界观,边界上谁说了算? 两个世界,一个边界 Rust 说:每个值有且仅有一个 owner,owner 离开作用域就 drop。Python
数据中台场景下,不同技术栈的系统怎么用 FFI 共享同一套数据基础设施——为什么微服务不是答案,以及 FFI 桥接方案的实战经验。