分类:科技

能跑:为什么简单优先是最高原则

28 阅读 0 3353 字 · 约 12 分钟

复杂度的代价不是「写的时候费劲」,是「改的时候绝望」。砍、硬、短——三个字讲透为什么在信息最少的阶段,简单不是偷懒,是降低意外概率。三个真实案例:Airflow过度设计、配置抽象过头、新产品验证把MVP做成平台。

架构不是设计出来的

30 阅读 0 2681 字 · 约 9 分钟

架构不是设计出来的,是在每个阶段做了正确的决策才长出来的。四阶段框架:能跑→跑得准→跑得稳→跑得快,每个阶段的核心矛盾不同,三条原则的权重随场景变化。

【Hudi】 Hudi 是什么,解决什么问题

33 阅读 0 707 字 · 约 3 分钟

Parquet、HDFS / 对象存储上的文件,写完就不能改。但业务总是要改 — 用户改了收货地址、订单从"待支付"变成"已发货"、某笔交易被风控标黑。 这些"改一行"的事情落到 Parquet 层,就变成了"重写整个文件"。 传统做法:Hive/Spark OVERWRITE 最直接的思路是 IN

【Hudi】 数据怎么存 — Parquet + Avro + 两种表类型

24 阅读 0 1143 字 · 约 4 分钟

Hudi 没有发明新存储格式,它站在 Parquet 和 Avro 之上。这不是"技术选型",而是刻意为之。 为什么用两种格式 Parquet 是列式文件,读的时候只扫需要的列,跳过滤掉的不读。一张 100 列的表查 3 个字段,Parquet 只读 3% 的数据。 Avro 是行式文件,一行一行写

【Hudi】 更新怎么定位 — File Group + Index

20 阅读 0 1290 字 · 约 5 分钟

一条更新来了,Hudi 怎么知道要改哪个文件?这就是 File Group 和 Index 要解决的事。 为什么不能扫全表 最简单的更新方案是:找出所有分区里所有 Parquet 文件,逐个读出来,找到要改的行,写回去。这就是全量重写的逻辑。 - 一张 100GB 的表,改一行也要扫 100GB -

【Hudi】 Timeline — Hudi 的事务日志

28 阅读 0 2709 字 · 约 10 分钟

Hudi 表目录下有个 .hoodie/ 文件夹,里面放的不是数据,是元数据。这套元数据叫 Timeline,是 Hudi 读写一致性的核心。 为什么需要 Timeline Parquet 文件本身是死的——它不会告诉你"我现在是最新版本"还是"已经被更新替代了",也不会告诉你"写我的那个作业成功提

【Hudi】 并发控制 — 多个作业同时写怎么办

23 阅读 0 1928 字 · 约 7 分钟

两个写入作业同时往一张表写数据,会不会把对方的数据覆盖掉? 数据模型 先讲 Hudi 的数据模型,因为并发控制的前提是知道每条记录长什么样。 不是所有 Hudi 表都要有主键和分区。 COW 表可以不指定 recordKey,只能做批量追加,每次写入都是新文件。MOR 表必须指定 recordKey

【Hudi】 Flink → Hudi 实时入湖实战

23 阅读 0 2188 字 · 约 8 分钟

篇 6: Flink → Hudi 实时入湖实战 Hudi 的存储、索引、Timeline、并发控制,每个组件单独看都不复杂。这篇把它们串起来,看一条真实链路:用 Flink 把数据写进 Hudi,在一个场景里把各个概念都过一遍。 场景:订单流水实时入湖 假设有一条 Kafka 流,主题是 orde

【FFI】 FFI 为什么存在——跨语言调用的根本问题

14 阅读 0 1027 字 · 约 4 分钟

写代码几十年了,没有哪个语言能统一所有场景。C/C++ 统治系统编程,Java 统治企业后端,Python 统治数据科学。每种语言都有它擅长的生态,也有它够不着的角落。 FFI(Foreign Function Interface)的存在,本质上是为了两件事: 借用性能。 Python 写数据管道很

【FFI】 C FFI 与 libffi——事实标准的工作原理

16 阅读 0 1382 字 · 约 5 分钟

FFI 的底层逻辑很简单:两个语言之间要互相调用,总得有个共同的"语言"做桥梁。这个桥梁不是 C 语言本身,而是 C 的调用约定——C ABI。 为什么是 C ABI,不是别的 操作系统内核用什么语言写的不重要。Linux 是纯 C,macOS 的 XNU 混了大量 C++,Windows 内核也是