寒蝉 Hancic
【Hudi】 Hudi 是什么,解决什么问题
Parquet、HDFS / 对象存储上的文件,写完就不能改。但业务总是要改 — 用户改了收货地址、订单从"待支付"变成"已发货"、某笔交易被风控标黑。 这些"改一行"的事情落到 Parquet 层,就变成了"重写整个文件"。 传统做法:Hive/Spark OVERWRITE 最直接的思路是 IN
标签：大数据
【Hudi】 数据怎么存 — Parquet + Avro + 两种表类型
Hudi 没有发明新存储格式，它站在 Parquet 和 Avro 之上。这不是"技术选型"，而是刻意为之。 为什么用两种格式 Parquet 是列式文件，读的时候只扫需要的列，跳过滤掉的不读。一张 100 列的表查 3 个字段，Parquet 只读 3% 的数据。 Avro 是行式文件，一行一行写
【Hudi】 更新怎么定位 — File Group + Index
一条更新来了，Hudi 怎么知道要改哪个文件？这就是 File Group 和 Index 要解决的事。 为什么不能扫全表 最简单的更新方案是：找出所有分区里所有 Parquet 文件，逐个读出来，找到要改的行，写回去。这就是全量重写的逻辑。 - 一张 100GB 的表，改一行也要扫 100GB -
【Hudi】 Timeline — Hudi 的事务日志
Hudi 表目录下有个 .hoodie/ 文件夹，里面放的不是数据，是元数据。这套元数据叫 Timeline，是 Hudi 读写一致性的核心。 为什么需要 Timeline Parquet 文件本身是死的——它不会告诉你"我现在是最新版本"还是"已经被更新替代了"，也不会告诉你"写我的那个作业成功提
【Hudi】 并发控制 — 多个作业同时写怎么办
两个写入作业同时往一张表写数据，会不会把对方的数据覆盖掉？ 数据模型 先讲 Hudi 的数据模型，因为并发控制的前提是知道每条记录长什么样。 不是所有 Hudi 表都要有主键和分区。 COW 表可以不指定 recordKey，只能做批量追加，每次写入都是新文件。MOR 表必须指定 recordKey
【Hudi】 Flink → Hudi 实时入湖实战
篇 6: Flink → Hudi 实时入湖实战 Hudi 的存储、索引、Timeline、并发控制，每个组件单独看都不复杂。这篇把它们串起来，看一条真实链路：用 Flink 把数据写进 Hudi，在一个场景里把各个概念都过一遍。 场景：订单流水实时入湖 假设有一条 Kafka 流，主题是 orde
实时数据湖技术选型：Hudi、Iceberg、Delta Lake、Paimon 怎么选
实时数据湖技术选型：Hudi、Iceberg、Delta Lake、Paimon 怎么选 为什么需要数据湖格式？ 传统数仓的痛点很明显：数据先入 Kafka 或 MySQL，再通过离线 ETL 写入 HDFS/Hive。这个链路里，更新和删除是老大难问题——Hive 不支持行级 UPDATE，只能全
使用大数据处理的思维提升繁杂事务处理的效率
无论工作还是生活中，我们时常不得不面对大量繁杂事务的处理，仔细思考下，其实这种场景与IT领域中的大数据处理非常相似，其目标都是一样的，输入大量的任务信息，经过一系列的思考、规划和执行，输出为指定的任务结果。那么，在大数据处理场景中，我们对于提升执行效率和压缩执行时间的很多思路，也就可以同样带入到真实
Spark高频面试问题
基础概念 Spark有哪些核心组件 集群级别 Master：管理集群资源，接收任务提交，分配任务到worker。 Worker：接收master指令，启停executor，向master发送心跳。 应用级别 Driver：解析任务代码，转成执行计划，申请资源，分发任务给executor。 Execu
