三石

Hudi按照我的理解，我们一般所说的 MOR 与 Hudi 中的 MOR 不同，我们强调的是 query，而 Hudi 中指的是 table type。Hudi 中真正对应的我们的是视图（query type） 中的近实时视图（Snapshot Queries）：在此视图上的查询将查看某个增量提交操作中数据集的最新快照。该视图通过动态合并最新的基本文件(例如parquet)和增量文件(例如avro)来提供近实时数据集（几分钟的延迟）。当前支持 Hudi 近实时视图的查询引擎如下图Hudi 实时

引言本次分享的出发点是为了理清楚 iceberg 是如何实现 MOR 的，以此作为解决 arctic MOR 相关问题的参考，问题：delta 增量数据文件的格式是否与 base 保持一致 delta 增量数据文件是否需要拆分为 insert 和 delete 两部分 delete 文件的格式规范如何设计，兼顾数据摄取的吞吐量和查询效率 实现 MOR 后，minor compaction 和 major compaction 是如何设计的在Iceberg 中 MOR 相关的功能是在 Ic..

本文说讨论的IncrementalPuller是指 Hadoop 数据的增量查询，有两种场景，batch 模式下查询是指一次性返回所有或者有变化的数据，steaming 模式下查询是指连续返回所有数据并接着只返回有变化的数据，或者只返回有变化的数据，这取决于用户如何指定 increment scan 的 snapshot。IncrementalPuller 配合数据的 Row Level Delete（即数据的update、delete）即可以实现Incremental processing on...

最近阅读了 Iceberg 项目中 FlinkSource 和 FlinkSink 的实现，上一篇文章[1]其实都有带过一笔，今天就总结下 Iceberg 如何做 plan 的，无论是数据读取或者小文件合并，都需要对底层文件进行 Scan 和 Plan，生成最后可供计算(如Flink、Spark)引擎或者查询(AP，如SparkSQL、Presto)引擎执行的 SubTasks，或者叫做 Splits，以此进行分布式并发计算。Iceberg 对比 Hudi 经常拿来说道的就是其 API 抽象更优雅，这里就介

问题一、Apache Iceberg 0.11 版本的源码编译后对 Spark Test 进行运行的时候报错：Error:scalac: Output path /Users/wulei/IdeaProjects/iceberg/spark2/out/test/classes is shared between: Module 'iceberg.iceberg-spark2.jmh' tests, Module 'iceberg.iceberg-spark2.test' tests Please conf

背景我司开发了一个非常牛的基础设施，产品的定位可以参考 Apache Hudi，也有一点 Apache Iceberg 的影子。我这边负责的实现主要是 Flink 的写入和 Spark 的读取，开发后就是最有意义的性能调优了～优化除去最基本的通过打印日志排查到底是哪个步骤执行时间较长不谈，着重讲一讲如何通过内存和CPU情况来定位性能问题。内存优化在数据写入阶段，观察 Flink 的 TM 进程，发现其有频繁的 FGC，使用 MAT 工具 dump 后发现并不存在大对象问题。操作步骤如下：// 查