Storage on NoneBack

LevelDB MVCC

Sat, 08 Feb 2025 14:06:39 +0800

LevelDB通过 MVCC 实现了 sstable 读写并发以及 Snapshot Read 的功能，让我们来看看它是怎么做到的。

Sequence Number

LevelDB通过Sequence Number作为逻辑时钟，维护了单个 KV 写操作的全序关系。在 InternalKey 的编码里，将Sequence Number 编码到 InternalKey 的最后几个字节里。在写内存时，也确保了数据的有序性。

Versioning

LevelDB每次sstable文件集合变化，都会从一个Version升级成另外一个Version。Version表示DB在某个时刻的状态，每个Version中记录了某个时刻sstable以及compaction 有关的元信息。VersionEdit 描述了版本的变化。

text

Version1 ---VersionEdit--> Version2

VersionSet 被描述为一组有序的 Version 链表，代表了数据库当前以及历史的运行状态。其中LastSeq 和 Version 链表最为关键。

Version链表描述了存储的所有Version以及变化，Version 本身使用 RC 的方式做 GC。Version Chain 描述了不同时间sstable 集合写操作的全序关系。

WAL + Manifest 确保了LastSeq变更的原子性。

Manifest文件作为VersionChange的WAL保证版本变更的Crush Safety, 和 Version Commit操作一起保证了VersionSet最新版本变更的原子性。

plain

Write Done ---> VersionEdit ---> Manifest ---> VersionSet

在整个 Version迁移过程中，写操作导致状态变更由 VersionEdit 记录在内存中，然后写入到 Manifest里，最后再将 VersionSet 指向此 Version，这样的操作保证了 Version 变更的一致性，即Compaction导致的版本变更不会影响到正在进行的读操作。读操作也不会读取到中间状态的 sstable 文件。

cpp


class VersionEdit {
 /** other code */
 typedef std::set<std::pair<int, uint64_t>> DeletedFileSet;

 std::string comparator_;
 uint64_t log_number_;
 uint64_t prev_log_number_;
 uint64_t next_file_number_;
 SequenceNumber last_sequence_;
 bool has_comparator_;
 bool has_log_number_;
 bool has_prev_log_number_;
 bool has_next_file_number_;
 bool has_last_sequence_;

 std::vector<std::pair<int, InternalKey>> compact_pointers_;
 DeletedFileSet deleted_files_;
 std::vector<std::pair<int, FileMetaData>> new_files_;
};

class Version {
 VersionSet* vset_; // VersionSet to which this Version belongs
 Version* next_; // Next version in linked list
 Version* prev_; // Previous version in linked list
 int refs_; // Number of live refs to this version

 // List of files and meta per level
 std::vector<FileMetaData*> files_[config::kNumLevels];

 // Next file to compact based on seek stats. （allowed_seek耗尽导致的compact）
 FileMetaData* file_to_compact_;
 int file_to_compact_level_;

 // Level that should be compacted next and its compaction score.
 // Score < 1 means compaction is not strictly needed. These fields
 // are initialized by Finalize().
 double compaction_score_; // score表示数据不均衡的程度，score越大表示该level数据越不均衡，需要有限compact
 int compaction_level_;
}

class VersionSet {
 Env* const env_;
 const std::string dbname_;
 const Options* const options_;
 TableCache* const table_cache_;
 const InternalKeyComparator icmp_;
 uint64_t next_file_number_;
 uint64_t manifest_file_number_;
 uint64_t last_sequence_;
 uint64_t log_number_;
 uint64_t prev_log_number_; // 0 or backing store for memtable being compacted

 // Opened lazily
 WritableFile* descriptor_file_; // descriptor_ is for manifest file
 log::Writer* descriptor_log_; // descriptor_ is for manifest file
 Version dummy_versions_; // Head of circular doubly-linked list of versions. 正在使用的version的链表
 Version* current_; // == dummy_versions_.prev_

 // Per-level key at which the next compaction at that level should start.
 // Either an empty string, or a valid InternalKey.
 std::string compact_pointer_[config::kNumLevels];
}

MVCC & Snapshot Read

对于memtable的并发读写操作，依赖 skiplist，本身是有锁来处理读写冲突的。对于sstable的并发读写（compaction 和 read ）则依赖 Version 和 Sequence Number 解决。

每次对 sstable 的写操作（minor/major compaction）必然产生新的 sstable 文件，带来 sstable 集合的变化，进而产生新的 Version。而每条KV记录也一定会携带 Sequence Number信息。

每次读操作(Version.Get)会附带上 Sequence Number 以及 Version 信息，Sequence Number 确保了后续的写入对读不可见，关联Version确保了Version关联的sstable在读操作结束前不会被GC。进而确保了读取所用到的sstable文件不会丢失或者更新,同时也能实现 Snapshot Read。

如果 Read 和 Write 在同一个 Version 进行，则必须是Compaction 先完成后，否则 Version 不会变化。此时触发读取操作，此时sstable不会有变化，所以读写并不冲突。如果不是，则只能是先读后写，写对读不可见，更不会有冲突。

Reference

https://leveldb-handbook.readthedocs.io/zh/latest/index.html https://noneback.github.io/zh/blog/zh/leveldb-write/

Prometheus--TSDB

Tue, 31 Dec 2024 01:10:28 +0800

最近晋升，顺便总结一些以前的工作。工作里大规模数据库可观测系统占了很大一部分，不过这个和云原生监控系统Prometheus还是很不一样的。现在来学习一下开源监控的标准系统。

文章主要涉及 Prometheus 自带的单机时序存储。简单写写里面的TSDB设计，不涉及源码分析。

这种项目的源码分析性价比有点低,除非我是专门搞tsdb的，不然分析之后也容易忘，再说了也不是什么很好的代码。

数据+查询模型

一个监控指标被描述为一组与时间有关的数据结构，timeseries。

$$ {timeseries} = \quad\lbrace \quad metric(attached\ with\ a\ set\ of\ labels) \Rightarrow (t_0,\ v_0),\ (t_1,\ v_1),\ (t_2,\ v_2),\ \ldots,\ (t_n, v_n) \quad\rbrace $$

查询使用 ${identifier(metric\ +\ sets\ of\ selected\ labels\ value)}$ 查询得到对应的timeseries

text

series
^
│ . . . . . . . . . . . . . . . . . . . . . . {__name__="request_total", method="GET"}
│ . . . . . . . . . . . . . . . . . . . . . . {__name__="request_total", method="POST"}
│ . . . . . . .
│ . . . . . . . . . . . . . . . . . . . ...
│ . . . . . . . . . . . . . . . . . . . . .
│ . . . . . . . . . . . . . . . . . . . . . {__name__="errors_total", method="POST"}
│ . . . . . . . . . . . . . . . . . {__name__="errors_total", method="GET"}
│ . . . . . . . . . . . . . .
│ . . . . . . . . . . . . . . . . . . . ...
│ . . . . . . . . . . . . . . . . . . . .
v
<-------------------- time --------------------->

identifier 的定义很重要。否则 ts 数据容易膨胀，比如容器重建的场景，如果 label 用的不好很容易膨胀。

数据组织方式

对云原生的场景，监控数据有哪些特点？

数据的生命周期短。因为单个容器本身的生命周期就很短（比如扩缩容场景，大量临时任务等场景），timeseries 很容易在一定时间维度上膨胀。
垂直写入，水平查询

带着这些问题看看数据文件的组织方法，如何解决或者避免这些问题。

那么首先看看逻辑的结构

整个 db 由 blocks + HEAD 组成，block 又可以进一步被拆分成 chunks，HEAD 基本上就是内存数据+wal 保障的读写 buffer 区域。chunks 包含多种 timeseries。

对于单个 Block 的磁盘目录结构如下：

text

├── 01BKGV7JC0RY8A6MACW02A2PJD // block 的 ULID
│ ├── chunks
│ │ └── 000001
│ ├── tombstones
│ ├── index
│ └── meta.json
├── chunks_head
│ └── 000001
└── wal
├── 000000002
└── checkpoint.00000001
└── 00000000

block，一个时间段内（默认 2 小时）的所有数据，只读，用 ULID 命名。每一个 block 内主要包括：
- chunks 固定大小（最大 128M）的 chunks 文件
- index 索引文件，主要包含倒排索引的信息
- meta.json 元信息，主要包括 block 的 minTime/maxTime，用于在查询的时候data skip。
chunks_head，当前在写入的 block 对应的 chunks 文件，只读，最多 120 个数据点，时间跨度最大 2 小时。
wal：数据完整性保证

从图上可以知道很多信息，比如wal保障数据完整性；Head 类似 tsdb 的 buffer pool，只不过用 mmap 托管，实现内存数据批量刷盘。Head 到达一定条件（比如时间阈值，数据大小阈值）之后变成 immutable 的结构（block）刷盘。

整体在数据组织上有很多概念和lsm 类存储结构类似。LSM结构也确实很适合 tsdb。

不难看出 Prometheus 的设计思路：

通过数据按时间分片的方式来解决数据生命周期短的问题
通过内存攒批的方式来对应只写最新数据的场景

抛开与 leveldb 类似的地方不谈，我们来看看有什么不一样的地方。

首先，使用的模型上不一样。leveldb 是 kv ，tsdb 是 timeseries，与时间强关联，而时间是单调递增的。很少会去写入过去时间端的数据。其次，查询的模型也不一样。tsdb 会有更多样话的查询方式，比如对label 的各种集合操作对 timeseries 进行过滤，所以会有更多的元信息来标注 timeseries，以便高效的查询。

因为这类的需求，这里引入了一些新结构和功能：倒排索引，checkpoint，tombstone，retention，以及和 lsm kv模型不一样的 compaction 设计。这些让我们和对应的文件 format 一起分析。

文件组织格式

让我们来看看有哪些成分，具体的组织方式不是本文重点。

meta.json

block 的一些信息，关键看 compaction 和 minT,maxT。

minT,maxT 记录block 的时间访问，查询的时候可以用来做 data skip。

companction：记录了block的历史信息，比如经历了几次 compaction(level), 由哪些 block 派生出来(source)。暂时不知道有啥用。可能可以compaction 或者 retention 的时候用到，比如清理重复的 source 里面的 block。

text

{
"ulid": "01EM6Q6A1YPX4G9TEB20J22B2R", #
"minTime": 1602237600000,
"maxTime": 1602244800000,
"stats": {
"numSamples": 553673232,
"numSeries": 1346066,
"numChunks": 4440437
},
"compaction": {
"level": 1,
"sources": [
"01EM65SHSX4VARXBBHBF0M0FDS",
"01EM6GAJSYWSQQRDY782EA5ZPN"
]
},
"version": 1
}

chunks

普通的数据文件，它的索引都在 index 文件里。需要注意的是一个chunk 只能属于一个 timeseries，一个 timeseries 由多个 chunks组成。

text

┌──────────────────────────────┐
│ magic(0x85BD40DD) <4 byte> │
├──────────────────────────────┤
│ version(1) <1 byte> │
├──────────────────────────────┤
│ padding(0) <3 byte> │
├──────────────────────────────┤
│ ┌──────────────────────────┐ │
│ │ Chunk 1 │ │
│ ├──────────────────────────┤ │
│ │ ... │ │
│ ├──────────────────────────┤ │
│ │ Chunk N │ │
│ └──────────────────────────┘ │
└──────────────────────────────┘
Every Chunk:
┌───────────────┬───────────────────┬──────────────┬────────────────┐
│ len <uvarint> │ encoding <1 byte> │ data <bytes> │ CRC32 <4 byte> │
└───────────────┴───────────────────┴──────────────┴────────────────┘

tombstone

标记删除，tsdb 有时候会有一些删除操作。比如，短时 Job、容器销毁之后，业务上可能希望删除。标记删除主要是为了用追加写代替原地修改。后续可以通过 Compaction 回收这部分磁盘。

当然不删除也没事，会有 TTL 到期删除磁盘过期数据。

text

┌────────────────────────────┬─────────────────────┐
│ magic(0x0130BA30) <4b> │ version(1) <1 byte> │
├────────────────────────────┴─────────────────────┤
│ ┌──────────────────────────────────────────────┐ │
│ │ Tombstone 1 │ │
│ ├──────────────────────────────────────────────┤ │
│ │ ... │ │
│ ├──────────────────────────────────────────────┤ │
│ │ Tombstone N │ │
│ ├──────────────────────────────────────────────┤ │
│ │ CRC<4b> │ │
│ └──────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────┘
Every Tombstone:
┌────────────────────────┬─────────────────┬─────────────────┐
│ series ref <uvarint64> │ mint <varint64> │ maxt <varint64> │
└────────────────────────┴─────────────────┴─────────────────┘

index 文件

包含了读取用到的所有信息。比如倒排索引，timeseries 和 chunks 的映射关系。

里面值得注意的是 Series 和 Postings 两类。

Series 里面记录了Blocks里所有 series 对应 chunks的信息。

Posting Offset Table记录了各个倒排索引的位置。倒排索引具体的内容被放在了 Postings里。

对倒排索引的集合操作，可以快速过滤出来符合条件的 timeseries

text

┌────────────────────────────┬─────────────────────┐
│ magic(0xBAAAD700) <4b> │ version(1) <1 byte> │
├────────────────────────────┴─────────────────────┤
│ ┌──────────────────────────────────────────────┐ │
│ │ Symbol Table │ │
│ ├──────────────────────────────────────────────┤ │
│ │ Series │ │
│ ├──────────────────────────────────────────────┤ │
│ │ Label Index 1 │ │
│ ├──────────────────────────────────────────────┤ │
│ │ ... │ │
│ ├──────────────────────────────────────────────┤ │
│ │ Label Index N │ │
│ ├──────────────────────────────────────────────┤ │
│ │ Postings 1 │ │
│ ├──────────────────────────────────────────────┤ │
│ │ ... │ │
│ ├──────────────────────────────────────────────┤ │
│ │ Postings N │ │
│ ├──────────────────────────────────────────────┤ │
│ │ Label Offset Table │ │
│ ├──────────────────────────────────────────────┤ │
│ │ Postings Offset Table │ │
│ ├──────────────────────────────────────────────┤ │
│ │ TOC │ │
│ └──────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────┘
A Series:
┌──────────────────────────────────────────────────────┐
│ len <uvarint> │
├──────────────────────────────────────────────────────┤
│ ┌──────────────────────────────────────────────────┐ │
│ │ labels count <uvarint64> │ │
│ ├──────────────────────────────────────────────────┤ │
│ │ ┌────────────────────────────────────────────┐ │ │
│ │ │ ref(l_i.name) <uvarint32> │ │ │
│ │ ├────────────────────────────────────────────┤ │ │
│ │ │ ref(l_i.value) <uvarint32> │ │ │
│ │ └────────────────────────────────────────────┘ │ │
│ │ ... │ │
│ ├──────────────────────────────────────────────────┤ │
│ │ chunks count <uvarint64> │ │
│ ├──────────────────────────────────────────────────┤ │
│ │ ┌────────────────────────────────────────────┐ │ │
│ │ │ c_0.mint <varint64> │ │ │
│ │ ├────────────────────────────────────────────┤ │ │
│ │ │ c_0.maxt - c_0.mint <uvarint64> │ │ │
│ │ ├────────────────────────────────────────────┤ │ │
│ │ │ ref(c_0.data) <uvarint64> │ │ │
│ │ └────────────────────────────────────────────┘ │ │
│ │ ┌────────────────────────────────────────────┐ │ │
│ │ │ c_i.mint - c_i-1.maxt <uvarint64> │ │ │
│ │ ├────────────────────────────────────────────┤ │ │
│ │ │ c_i.maxt - c_i.mint <uvarint64> │ │ │
│ │ ├────────────────────────────────────────────┤ │ │
│ │ │ ref(c_i.data) - ref(c_i-1.data) <varint64> │ │ │
│ │ └────────────────────────────────────────────┘ │ │
│ │ ... │ │
│ └──────────────────────────────────────────────────┘ │
├──────────────────────────────────────────────────────┤
│ CRC32 <4b> │
└──────────────────────────────────────────────────────┘
A Postings:
┌────────────────────┬────────────────────┐
│ len <4b> │ #entries <4b> │
├────────────────────┴────────────────────┤
│ ┌─────────────────────────────────────┐ │
│ │ ref(series_1) <4b> │ │
│ ├─────────────────────────────────────┤ │
│ │ ... │ │
│ ├─────────────────────────────────────┤ │
│ │ ref(series_n) <4b> │ │
│ └─────────────────────────────────────┘ │
├─────────────────────────────────────────┤
│ CRC32 <4b> │
└─────────────────────────────────────────┘

加速磁盘查询

这里重点讲述一次查询是如何找到符合条件的数据的：

首先在 Posting Offset Table 中，找到对应 label 的 Postings 位置
根据 Postings 中的 series 信息，找到对应的 chunk 位置，即上文中的 series ref
根据timeseries 找到对应的 chunks

Compaction

类似 leveldb，也有 major compaction和 minor compaction。在这里叫 Compaction 和 Head Compaction。

Head Compaction类似把 Head部分持久化成 Chunk 的过程，在这个过程中，mark delete 的tombstone 会被真的删除（毕竟要读到内存里，顺手删了）。

Compaction 就是把 Block 合并的一个过程。这个动作可以回收：

标记删除占用的磁盘资源。
重复的部分信息。比如散落在多个 block 里面的重复 chunk，倒排索引这类的磁盘记录
加速一些查询的处理。比如数据在多个数据块之间overlapping（没处理的话，读出来之后要在内存里处理，不如顺便在 compaction 的时候处理掉，合并之后读取也方便了）

什么时候会 compaction？

官方博客里没咋说清楚，只提到了data overlapping 的时候会触发。不过其他策略也挺多的。比如定时触发，每次 minor 触发的时候判断，基于 tombstone 的大小判断，手动触发这类。可以参考一些 leveldb 的策略。

Retention

没啥说的，就是 Time or Size Based TTL，感觉放到 Compaction 里面做也不是不行。

Snapshot

感觉就是把内存数据 dump 一份到磁盘上而已……。可能是为了平衡大量指标数据磁盘写入以及数据完整性。不然有了 wal 还要它干啥。

Reference

https://web.archive.org/web/20210803115658/https://fabxc.org/tsdb/

https://liujiacai.net/blog/2021/04/11/prometheus-storage-engine/

https://tech.qimao.com/prometheus-tsdb-de-she-ji-yu-shi-xian-2/

https://ganeshvernekar.com/blog/prometheus-tsdb-persistent-block-and-its-index/

https://ganeshvernekar.com/blog/prometheus-tsdb-compaction-and-retention/#compaction

Dynamo: Amazon’s Highly Available Key-value Store

Tue, 01 Aug 2023 16:15:29 +0800

一篇AWS的老文章，Dynamo到现在已经售卖了很久了，架构应该也早已不像论文中描述的这样。但文章入选了某年的sigmod best paper，依旧是有很多值得学习的地方。

设计

Dynamo是一种NoSQL产品，对外提供KV存储语义。在产品定义上强调Highly Available而非Consistency，所以在架构设计以及技术选型上和其他的产品还是有很多不同之处。

技术

在技术上，Dynamo其实有很多有问题的地方，比如NWR算法本身的一些。但考虑到Dynamo已经经过了很长时间的验证，也许这些问题已经被很好的解决了，只不过论文中语焉不详。所以暂且放下这些，挑一些来说一说。其中我认为值得拿出来说的主要有这几块：

数据的分区

一致性hash算法。传统的一致性hash算法使用hash ring来解决增减节点rehash范围大的问题，但比如数据倾斜，以及异构机器导致的性能倾斜这类问题是无法避免的。 Dynamo实践上，在原有hash ring上引入了虚拟节点，比较优雅的解决了这两个问题。

数据写入问题

一般存储系统会在写的同时保证一定的数据一致性，换取较低的读操作复杂度，代价上写性能降低（延迟等）。但Dynamo选择了另一条路线。 Dynamo的设计目标是提供一个高可用的KV Store，保证always writable，同时只保证最终的一致性。这样的目标使得Dynamo把解决数据冲突之类的操作放到了读操作中，以保证写永远不会被拒绝。总的来说，问题有两个。一个是数据更新冲突问题，显然多client并发的读写同一个Key很容易遇到这样的问题，因为Dynamo只能提供最终一致性，Dynamo Ring 上多个节点的数据不一定一致。二是节点数据空洞的问题。因为Dynamo使用的是NMR这类的gossip算法，这类理论上会出现所有节点上都不包含完整数据集的情况，需要同步副本之间的数据。前者使用版本时钟来标记数据版本，后续在读操作的时候进行读修复合并数据版本；后者有熵逆过程来处理，使用MerkleTree来快速检测副本之间的不一致性，以及最小化转移的数据量。 论文中的这个表格可以清楚的看出Dynamo设计开发需要考虑的方面以及在技术上的选择。剩下这些论文中感觉语焉不详，可以参考原文。

参考

Dynamo 的实现技术和去中心化

Dynamo一个缺陷的架构设计(译) – 后端技术 by Tim Yang

Dynamo: A flawed architecture | Hacker News

Flink-Iceberg-Connector写入流程

Mon, 10 Oct 2022 10:43:38 +0800

Iceberg社区提供了Flink Connector的官方实现，本章源码阅读正是基于此。

写入提交流程总览

Flink 通过 RowData -> distributeStream -> WriterStream -> CommitterStream，在写入数据提交之前，数据以中间文件形式存在，提交之后对系统可见（写入manifest + snapshot + metadata，数据文件对外部可见）

java


 private <T> DataStreamSink<T> chainIcebergOperators() {
 Preconditions.checkArgument(inputCreator != null,
 "Please use forRowData() or forMapperOutputType() to initialize the input DataStream.");
 Preconditions.checkNotNull(tableLoader, "Table loader shouldn't be null");

 DataStream<RowData> rowDataInput = inputCreator.apply(uidPrefix);

 if (table == null) {
 tableLoader.open();
 try (TableLoader loader = tableLoader) {
 this.table = loader.loadTable();
 } catch (IOException e) {
 throw new UncheckedIOException("Failed to load iceberg table from table loader: " + tableLoader, e);
 }
 }

 // Find out the equality field id list based on the user-provided equality field column names.
 List<Integer> equalityFieldIds = checkAndGetEqualityFieldIds();

 // Convert the requested flink table schema to flink row type.
 RowType flinkRowType = toFlinkRowType(table.schema(), tableSchema);

 // Distribute the records from input data stream based on the write.distribution-mode and equality fields.
 DataStream<RowData> distributeStream = distributeDataStream(
 rowDataInput, table.properties(), equalityFieldIds, table.spec(), table.schema(), flinkRowType);

 // Add parallel writers that append rows to files
 SingleOutputStreamOperator<WriteResult> writerStream = appendWriter(distributeStream, flinkRowType,
 equalityFieldIds);

 // Add single-parallelism committer that commits files
 // after successful checkpoint or end of input
 SingleOutputStreamOperator<Void> committerStream = appendCommitter(writerStream);

 // Add dummy discard sink
 return appendDummySink(committerStream);
 }

写入流程源码分析

WriteStream

java


 private SingleOutputStreamOperator<WriteResult> appendWriter(DataStream<RowData> input, RowType flinkRowType,
 List<Integer> equalityFieldIds) {

 // Fallback to use upsert mode parsed from table properties if don't specify in job level.
 boolean upsertMode = upsert || PropertyUtil.propertyAsBoolean(table.properties(),
 UPSERT_ENABLED, UPSERT_ENABLED_DEFAULT);

 // Validate the equality fields and partition fields if we enable the upsert mode.
 if (upsertMode) {
 Preconditions.checkState(!overwrite,
 "OVERWRITE mode shouldn't be enable when configuring to use UPSERT data stream.");
 Preconditions.checkState(!equalityFieldIds.isEmpty(),
 "Equality field columns shouldn't be empty when configuring to use UPSERT data stream.");
 if (!table.spec().isUnpartitioned()) {
 for (PartitionField partitionField : table.spec().fields()) {
 Preconditions.checkState(equalityFieldIds.contains(partitionField.sourceId()),
 "In UPSERT mode, partition field '%s' should be included in equality fields: '%s'",
 partitionField, equalityFieldColumns);
 }
 }
 }

 IcebergStreamWriter<RowData> streamWriter = createStreamWriter(table, flinkRowType, equalityFieldIds, upsertMode);

 int parallelism = writeParallelism == null ? input.getParallelism() : writeParallelism;
 SingleOutputStreamOperator<WriteResult> writerStream = input
 .transform(operatorName(ICEBERG_STREAM_WRITER_NAME), TypeInformation.of(WriteResult.class), streamWriter)
 .setParallelism(parallelism);
 if (uidPrefix != null) {
 writerStream = writerStream.uid(uidPrefix + "-writer");
 }
 return writerStream;
 }

WriterStream流算子由distriteStream转换而来，以RowData作为输入，WriteResult作为输出，其中转换的逻辑封装在IcebergStreamWriter对象中，处理逻辑见processElement。

java


 private transient TaskWriter<T> writer;
 @Override
 public void processElement(StreamRecord<T> element) throws Exception {
 writer.write(element.getValue());
 }

IcebergStreamWriter将数据的写入委托给TaskWriterFactory（RowDataTaskWriterFactory）创建的TaskWriter（如PartitionedDeltaWriter，UnpartitionedWriter）执行。

java


 public TaskWriter<RowData> create() {
 Preconditions.checkNotNull(outputFileFactory,
 "The outputFileFactory shouldn't be null if we have invoked the initialize().");

 if (equalityFieldIds == null || equalityFieldIds.isEmpty()) {
 // Initialize a task writer to write INSERT only.
 if (spec.isUnpartitioned()) {
 return new UnpartitionedWriter<>(spec, format, appenderFactory, outputFileFactory, io, targetFileSizeBytes);
 } else {
 return new RowDataPartitionedFanoutWriter(spec, format, appenderFactory, outputFileFactory,
 io, targetFileSizeBytes, schema, flinkSchema);
 }
 } else {
 // Initialize a task writer to write both INSERT and equality DELETE.
 if (spec.isUnpartitioned()) {
 return new UnpartitionedDeltaWriter(spec, format, appenderFactory, outputFileFactory, io,
 targetFileSizeBytes, schema, flinkSchema, equalityFieldIds, upsert);
 } else {
 return new PartitionedDeltaWriter(spec, format, appenderFactory, outputFileFactory, io,
 targetFileSizeBytes, schema, flinkSchema, equalityFieldIds, upsert);
 }
 }
 }TaskWriterFactory

TaskWriter又将写入交给RollingWriter（BaseRollingWriter）执行。

java


 public void write(T row) throws IOException {
 PartitionKey partitionKey = partition(row);

 RollingFileWriter writer = writers.get(partitionKey);
 if (writer == null) {
 // NOTICE: we need to copy a new partition key here, in case of messing up the keys in writers.
 PartitionKey copiedKey = partitionKey.copy();
 writer = new RollingFileWriter(copiedKey);
 writers.put(copiedKey, writer);
 }

 writer.write(row);
 }

RollingWriter会持有一个OutputFileFactory生成的OutputFile作为写入文件，并根据一些策略自动切换的新的OutputFile文件.

java


 public void write(T record) throws IOException {
 write(currentWriter, record);
 this.currentRows++;

 if (shouldRollToNewFile()) {
 closeCurrent();
 openCurrent();
 }
 }

java


 private void openCurrent() {
 if (partitionKey == null) {
 // unpartitioned
 this.currentFile = fileFactory.newOutputFile();
 } else {
 // partitioned
 this.currentFile = fileFactory.newOutputFile(partitionKey);
 }
 this.currentWriter = newWriter(currentFile, partitionKey);
 this.currentRows = 0;
 }

OutputFile的命名规则是

LocationProvider.newLocation(partitionId+taskId+operationId+fileCountID+ext)

RollingWriter会把写入交个AppenderFactory构造的DataWriter，对于Flink，默认的DataWriter是ParquetDataWriter。ParquetDataWriter根据不同的数据类型委托给不同的ParquertValueWriter

java


 DataWriter<T> newWriter(EncryptedOutputFile file, StructLike partitionKey) {
 return appenderFactory.newDataWriter(file, format, partitionKey);
 }

java


@Override
public DataWriter<RowData> newDataWriter(EncryptedOutputFile file, FileFormat format, StructLike partition) {
return new DataWriter<>(
 newAppender(file.encryptingOutputFile(), format), format,
 file.encryptingOutputFile().location(), spec, partition, file.keyMetadata());
}

@Override
 public FileAppender<RowData> newAppender(OutputFile outputFile, FileFormat format) {
 MetricsConfig metricsConfig = MetricsConfig.fromProperties(props);
 try {
 switch (format) {
 case AVRO:
 return Avro.writer...
 case ORC:
 return ORC.writer...
 case PARQUET:
 return Parquet.writer...
 default:
 throw new UnsupportedOperationException("Cannot write unknown file format: " + format);
 }
 } catch (IOException e) {
 throw new UncheckedIOException(e);
 }
 }

CommitterStream

CommitterStream 接受 WriteResult 作为输入，无结果输出。WriteResult包含了WriteStream中产生的数据文件。

java


public class WriteResult implements Serializable {
 private DataFile[] dataFiles;
 private DeleteFile[] deleteFiles;
 private CharSequence[] referencedDataFiles;
 ...
}

处理数据文件提交的核心逻辑封装在IcebergFilesCommitter.IcebergFlieCommitter用一个List（writeResultsOfCurrentCkpt）维护正在处理的Ckpt的需要提交的文件集合，用一个SortedMap（dataFilesPerCheckpoint）维护了系统当前Snapshot中所有Ckpt中提交的文件信息，用List of SortedMap 维护了系统所有的Snapshot的文件提交信息。

java


class IcebergFilesCommitter extends AbstractStreamOperator<Void>
 implements OneInputStreamOperator<WriteResult, Void>, BoundedOneInput {
 ...

 // A sorted map to maintain the completed data files for each pending checkpointId (which have not been committed
 // to iceberg table). We need a sorted map here because there's possible that few checkpoints snapshot failed, for
 // example: the 1st checkpoint have 2 data files <1, <file0, file1>>, the 2st checkpoint have 1 data files
 // <2, <file3>>. Snapshot for checkpoint#1 interrupted because of network/disk failure etc, while we don't expect
 // any data loss in iceberg table. So we keep the finished files <1, <file0, file1>> in memory and retry to commit
 // iceberg table when the next checkpoint happen.
 private final NavigableMap<Long, byte[]> dataFilesPerCheckpoint = Maps.newTreeMap();

 // The completed files cache for current checkpoint. Once the snapshot barrier received, it will be flushed to the
 // 'dataFilesPerCheckpoint'.
 private final List<WriteResult> writeResultsOfCurrentCkpt = Lists.newArrayList();

 private transient ListState<SortedMap<Long, byte[]>> checkpointsState;
 ...
 }

java


 @Override
 public void processElement(StreamRecord<WriteResult> element) {
 this.writeResultsOfCurrentCkpt.add(element.getValue());
 }

上游的当前checkpoint的WriteResult一个writeResultsOfCurrentCkpt中。在SnapshotState的时候writeResultsOfCurrentCkpt -> dataFilesPerCheckpoint -> checkpointsState提交。之后通过notifyCheckpointComplete通知Ckpt完成，并将其提交。

java


public void snapshotState(StateSnapshotContext context) throws Exception {
 super.snapshotState(context);
 long checkpointId = context.getCheckpointId();
 LOG.info("Start to flush snapshot state to state backend, table: {}, checkpointId: {}", table, checkpointId);

 // Update the checkpoint state.
 dataFilesPerCheckpoint.put(checkpointId, writeToManifest(checkpointId));
 // Reset the snapshot state to the latest state.
 checkpointsState.clear();
 checkpointsState.add(dataFilesPerCheckpoint);

 jobIdState.clear();
 jobIdState.add(flinkJobId);

 // Clear the local buffer for current checkpoint.
 writeResultsOfCurrentCkpt.clear();
 }

 @Override
 public void notifyCheckpointComplete(long checkpointId) throws Exception {
 super.notifyCheckpointComplete(checkpointId);
 // It's possible that we have the following events:
 // 1. snapshotState(ckpId);
 // 2. snapshotState(ckpId+1);
 // 3. notifyCheckpointComplete(ckpId+1);
 // 4. notifyCheckpointComplete(ckpId);
 // For step#4, we don't need to commit iceberg table again because in step#3 we've committed all the files,
 // Besides, we need to maintain the max-committed-checkpoint-id to be increasing.
 if (checkpointId > maxCommittedCheckpointId) {
 commitUpToCheckpoint(dataFilesPerCheckpoint, flinkJobId, checkpointId);
 this.maxCommittedCheckpointId = checkpointId;
 }
 }

提交逻辑在commitUpToCheckpoint函数中。Iceberg抽象除了SnapshotUpdate接口处理Snapshot的变更。Iceberg使用乐观策略处理提交时的Snapshot并发冲突。当发生并发提交冲突时，会重试commit操作。每次commit都会基于当前最新的metadata产生一个新的Snapshot 对象，将其添加到新的Metadata中，最后尝试通过TableOperation.commit进行提交。

java


 public void commit() {
 // this is always set to the latest commit attempt's snapshot id.
 AtomicLong newSnapshotId = new AtomicLong(-1L);
 try {
 Tasks.foreach(ops)
 .retry(base.propertyAsInt(COMMIT_NUM_RETRIES, COMMIT_NUM_RETRIES_DEFAULT))
 .exponentialBackoff(
 base.propertyAsInt(COMMIT_MIN_RETRY_WAIT_MS, COMMIT_MIN_RETRY_WAIT_MS_DEFAULT),
 base.propertyAsInt(COMMIT_MAX_RETRY_WAIT_MS, COMMIT_MAX_RETRY_WAIT_MS_DEFAULT),
 base.propertyAsInt(COMMIT_TOTAL_RETRY_TIME_MS, COMMIT_TOTAL_RETRY_TIME_MS_DEFAULT),
 2.0 /* exponential */)
 .onlyRetryOn(CommitFailedException.class)
 .run(taskOps -> {
 Snapshot newSnapshot = apply(); // generate a new snapshot based on new added data file and manifest,manifest list
 newSnapshotId.set(newSnapshot.snapshotId());
 TableMetadata.Builder update = TableMetadata.buildFrom(base);
 if (base.snapshot(newSnapshot.snapshotId()) != null) {
 // this is a rollback operation
 update.setBranchSnapshot(newSnapshot.snapshotId(), SnapshotRef.MAIN_BRANCH);
 } else if (stageOnly) {
 update.addSnapshot(newSnapshot);
 } else {
 update.setBranchSnapshot(newSnapshot, SnapshotRef.MAIN_BRANCH);
 }

 TableMetadata updated = update.build();
 if (updated.changes().isEmpty()) {
 // do not commit if the metadata has not changed. for example, this may happen when setting the current
 // snapshot to an ID that is already current. note that this check uses identity.
 return;
 }

 // if the table UUID is missing, add it here. the UUID will be re-created each time this operation retries
 // to ensure that if a concurrent operation assigns the UUID, this operation will not fail.
 taskOps.commit(base, updated.withUUID()); // commit table metadata, may cause commit failure
 });

 } catch (CommitStateUnknownException commitStateUnknownException) {
 throw commitStateUnknownException;
 } catch (RuntimeException e) {
 Exceptions.suppressAndThrow(e, this::cleanAll);
 }

 try {
 LOG.info("Committed snapshot {} ({})", newSnapshotId.get(), getClass().getSimpleName());

 // at this point, the commit must have succeeded. after a refresh, the snapshot is loaded by
 // id in case another commit was added between this commit and the refresh.
 Snapshot saved = ops.refresh().snapshot(newSnapshotId.get());
 if (saved != null) {
 cleanUncommitted(Sets.newHashSet(saved.allManifests(ops.io())));
 // also clean up unused manifest lists created by multiple attempts
 for (String manifestList : manifestLists) {
 if (!saved.manifestListLocation().equals(manifestList)) {
 deleteFile(manifestList);
 }
 }
 } else {
 // saved may not be present if the latest metadata couldn't be loaded due to eventual
 // consistency problems in refresh. in that case, don't clean up.
 LOG.warn("Failed to load committed snapshot, skipping manifest clean-up");
 }

 } catch (Throwable e) {
 LOG.warn("Failed to load committed table metadata or during cleanup, skipping further cleanup", e);
 }

 try {
 notifyListeners();
 } catch (Throwable e) {
 LOG.warn("Failed to notify event listeners", e);
 }
 }

java


private void commitUpToCheckpoint(NavigableMap<Long, byte[]> deltaManifestsMap,
 String newFlinkJobId,
 long checkpointId) throws IOException {
 NavigableMap<Long, byte[]> pendingMap = deltaManifestsMap.headMap(checkpointId, true);
 List<ManifestFile> manifests = Lists.newArrayList();
 NavigableMap<Long, WriteResult> pendingResults = Maps.newTreeMap();
 for (Map.Entry<Long, byte[]> e : pendingMap.entrySet()) {
 if (Arrays.equals(EMPTY_MANIFEST_DATA, e.getValue())) {
 // Skip the empty flink manifest.
 continue;
 }

 DeltaManifests deltaManifests = SimpleVersionedSerialization
 .readVersionAndDeSerialize(DeltaManifestsSerializer.INSTANCE, e.getValue());
 pendingResults.put(e.getKey(), FlinkManifestUtil.readCompletedFiles(deltaManifests, table.io()));
 manifests.addAll(deltaManifests.manifests());
 }

 int totalFiles = pendingResults.values().stream()
 .mapToInt(r -> r.dataFiles().length + r.deleteFiles().length).sum();
 continuousEmptyCheckpoints = totalFiles == 0 ? continuousEmptyCheckpoints + 1 : 0;
 if (totalFiles != 0 || continuousEmptyCheckpoints % maxContinuousEmptyCommits == 0) {
 if (replacePartitions) {
 replacePartitions(pendingResults, newFlinkJobId, checkpointId);
 } else {
 commitDeltaTxn(pendingResults, newFlinkJobId, checkpointId);
 }
 continuousEmptyCheckpoints = 0;
 }
 pendingMap.clear();

 // Delete the committed manifests.
 for (ManifestFile manifest : manifests) {
 try {
 table.io().deleteFile(manifest.path());
 } catch (Exception e) {
 // The flink manifests cleaning failure shouldn't abort the completed checkpoint.
 String details = MoreObjects.toStringHelper(this)
 .add("flinkJobId", newFlinkJobId)
 .add("checkpointId", checkpointId)
 .add("manifestPath", manifest.path())
 .toString();
 LOG.warn("The iceberg transaction has been committed, but we failed to clean the temporary flink manifests: {}",
 details, e);
 }
 }
 }

java


public void commit(TableMetadata base, TableMetadata metadata) {
 // if the metadata is already out of date, reject it
 if (base != current()) {
 if (base != null) {
 throw new CommitFailedException("Cannot commit: stale table metadata");
 } else {
 // when current is non-null, the table exists. but when base is null, the commit is trying to create the table
 throw new AlreadyExistsException("Table already exists: %s", tableName());
 }
 }
 // if the metadata is not changed, return early
 if (base == metadata) {
 LOG.info("Nothing to commit.");
 return;
 }

 long start = System.currentTimeMillis();
 doCommit(base, metadata);
 deleteRemovedMetadataFiles(base, metadata);
 requestRefresh();

 LOG.info("Successfully committed to table {} in {} ms",
 tableName(),
 System.currentTimeMillis() - start);
 }

写入问题

就以上写入以及提交流程，最大的问题有两个：

Lots of Small File

对于流式写入，每次都会生成新的文件。这就会产生大量的小文件。小文件在对象存储其实支持比较好。但是大量的小文件可能会带来Iceberg 元数据读取和更新的额外开销，因为这些数据文件的信息都需要靠iceberg元数据文件中维护，大量的小文件可能导致元数据文件的膨胀，导致读取元数据文件时的处理时间增加。如何解决？

Iceberg Rewrite Action：支持Rewrite Data 和 Metadata 需要Flink / Spark Action 触发
snapshot 过期删除, 支持配置

java


import org.apache.iceberg.flink.actions.Actions;

TableLoader tableLoader = TableLoader.fromHadoopTable("hdfs://nn:8020/warehouse/path");
Table table = tableLoader.loadTable();
RewriteDataFilesActionResult result = Actions.forTable(table)
 .rewriteDataFiles()
 .execute();

https://iceberg.apache.org/docs/latest/flink/https://iceberg.apache.org/docs/latest/maintenance/

高并发写入时的性能问题

Iceberg的写入会导致产生新的snapshot，并使用乐观并法策略处理并法冲突，冲突的提交将被重试。高并发写入场景下，并发冲突会导致很多提交snapshot的请求被重试，会有性能损失。

在准备提交snapshot前，iceberg会读取以前的快照然后创建新的快照，这个过程十分耗时，并且耗时会随着元数据增加而增加。

如何解决？

Batch Commit : 引入缓存层或者一个额外的服务，批量提交到数据湖，降低提交操作并发度。同时缓存层也许可以对多次的数据文件进行compact

https://zhuanlan.zhihu.com/p/472617094 https://www.infoq.cn/article/hfft7c7ahoomgayjsouz

Flink Iceberg Connector不支持隐藏分区，也不支持分区字段预处理。

Apache-ORC调研

Wed, 05 Oct 2022 19:56:01 +0800

iceberg支持ORC和Parquat两种列存格式。相比于Parquat，ORC在查询性能以及ACID支持方面具有一定的优势。于是考虑到后续湖仓查询性能以及数据湖的ACID需求，现对ORC进行调研，以支持后续Flink+iceberg+orc的demo测试。

调研重点：ORC文件的编码以及文件组织方式，索引支持。

File Layout

一个ORC文件总体上可以分为三大部分：

Header：标识文件的类型
Body：包含Row Data和Indexes，如下图
Tail：包含文件级别的信息

ORC Specification v1

File Tail

由于现在的分布式存储一般只提供AppendOnly语义，ORC 文件在文件的尾部有一块区域，用于维护文件级别（Top Level）的信息。 source code

The sections of the file tail are (and their protobuf message type):

encrypted stripe statistics: list of ColumnarStripeStatistics

stripe statistics: Metadata

footer: Footer

postscript: PostScript

psLen: byte

postscript

不允许被压缩，包含了解析文件尾部所需要的信息，比如：Footer和Metadata区域的长度，压缩方法等

protobuf


message PostScript {
 // the length of the footer section in bytes
 optional uint64 footerLength = 1;
 // the kind of generic compression used
 optional CompressionKind compression = 2;
 // the maximum size of each compression chunk
 optional uint64 compressionBlockSize = 3;
 // the version of the writer
 repeated uint32 version = 4 [packed = true];
 // the length of the metadata section in bytes
 optional uint64 metadataLength = 5;
 // the fixed string "ORC"
 optional string magic = 8000;
}

...

enum CompressionKind {
 NONE = 0;
 ZLIB = 1;
 SNAPPY = 2;
 LZO = 3;
 LZ4 = 4;
 ZSTD = 5;
}

Footer包含了文件的schema信息，文件的行数，列级别的统计信息

protobuf


message Footer {
 // the length of the file header in bytes (always 3)
 optional uint64 headerLength = 1;
 // the length of the file header and body in bytes
 optional uint64 contentLength = 2;
 // the information about the stripes
 repeated StripeInformation stripes = 3;
 // the schema information
 repeated Type types = 4;
 // the user metadata that was added
 repeated UserMetadataItem metadata = 5;
 // the total number of rows in the file
 optional uint64 numberOfRows = 6;
 // the statistics of each column across the file
 repeated ColumnStatistics statistics = 7;
 // the maximum number of rows in each index entry
 optional uint32 rowIndexStride = 8;
 // Each implementation that writes ORC files should register for a code
 // 0 = ORC Java
 // 1 = ORC C++
 // 2 = Presto
 // 3 = Scritchley Go from https://github.com/scritchley/orc
 // 4 = Trino
 optional uint32 writer = 9;
 // information about the encryption in this file
 optional Encryption encryption = 10;
 // the number of bytes in the encrypted stripe statistics
 optional uint64 stripeStatisticsLength = 11;
}

Stripe Information Body中的数据会被分为多个Stripe，行数据不允许跨Stripe存储。Stripe包含：**indexes of rows、row data、stripe footer。**indexes和data在stripe中按列存储。

protobuf


message StripeInformation {
 // the start of the stripe within the file
 optional uint64 offset = 1;
 // the length of the indexes in bytes
 optional uint64 indexLength = 2;
 // the length of the data in bytes
 optional uint64 dataLength = 3;
 // the length of the footer in bytes
 optional uint64 footerLength = 4;
 // the number of rows in the stripe
 optional uint64 numberOfRows = 5;
 // If this is present, the reader should use this value for the encryption
 // stripe id for setting the encryption IV. Otherwise, the reader should
 // use one larger than the previous stripe's encryptStripeId.
 // For unmerged ORC files, the first stripe will use 1 and the rest of the
 // stripes won't have it set. For merged files, the stripe information
 // will be copied from their original files and thus the first stripe of
 // each of the input files will reset it to 1.
 // Note that 1 was choosen, because protobuf v3 doesn't serialize
 // primitive types that are the default (eg. 0).
 optional uint64 encryptStripeId = 6;
 // For each encryption variant, the new encrypted local key to use until we
 // find a replacement.
 repeated bytes encryptedLocalKeys = 7;
}

Type Infomation

ORC文件的type schema必须保持一致。嵌套数据类型使用树形结构组织。 Case in Hive DDL：

sql


create table Foobar (
 myInt int,
 myMap map<string,
 struct<myString : string,
 myDouble: double>>,
 myTime timestamp
);

支持的类型：

protobuf


message Type {
 enum Kind {
 BOOLEAN = 0;
 BYTE = 1;
 SHORT = 2;
 INT = 3;
 LONG = 4;
 FLOAT = 5;
 DOUBLE = 6;
 STRING = 7;
 BINARY = 8;
 TIMESTAMP = 9;
 LIST = 10;
 MAP = 11;
 STRUCT = 12;
 UNION = 13;
 DECIMAL = 14;
 DATE = 15;
 VARCHAR = 16;
 CHAR = 17;
 TIMESTAMP_INSTANT = 18;
 }
 // the kind of this type
 required Kind kind = 1;
 // the type ids of any subcolumns for list, map, struct, or union
 repeated uint32 subtypes = 2 [packed=true];
 // the list of field names for struct
 repeated string fieldNames = 3;
 // the maximum length of the type for varchar or char in UTF-8 characters
 optional uint32 maximumLength = 4;
 // the precision and scale for decimal
 optional uint32 precision = 5;
 optional uint32 scale = 6;
}

Column Statistics

有关列的一些简单的statistics，可用于粗粒度过滤以及cbo

protobuf


message ColumnStatistics {
 // the number of values
 optional uint64 numberOfValues = 1;
 // At most one of these has a value for any column
 optional IntegerStatistics intStatistics = 2;
 optional DoubleStatistics doubleStatistics = 3;
 optional StringStatistics stringStatistics = 4;
 optional BucketStatistics bucketStatistics = 5;
 optional DecimalStatistics decimalStatistics = 6;
 optional DateStatistics dateStatistics = 7;
 optional BinaryStatistics binaryStatistics = 8;
 optional TimestampStatistics timestampStatistics = 9;
 optional bool hasNull = 10;
}

...

message IntegerStatistics {
 optional sint64 minimum = 1;
 optional sint64 maximum = 2;
 optional sint64 sum = 3;
}

User Metadata：用户自定的KV信息

protobuf


message UserMetadataItem {
 // the user defined key
 required string name = 1;
 // the user defined binary value
 required bytes value = 2;
}

File Metadata

protobuf


message Metadata {
 repeated StripeStatistics stripeStats = 1;
}

...

message StripeStatistics {
 repeated ColumnStatistics colStats = 1;
}

Stripe

Body部分的数据可以被拆分成Stripes，Stripes are large (typically ~200MB)。包含三个部分：Index Data、Row Data、Stripe Footer

在Stripe中，列数据分别以一组Stream的形式相邻于文件，如：

integer column：由两种数据流构成，PRESENT（代表是否为空） + DATA（具体数值）
string column：PRESENT + DATA + LENGTH

包含列的编码信息，以及流的相关信息

protobuf


message StripeFooter {
 // the location of each stream
 repeated Stream streams = 1;
 // the encoding of each column
 repeated ColumnEncoding columns = 2;
 optional string writerTimezone = 3;
 // one for each column encryption variant
 repeated StripeEncryptionVariant encryption = 4;
}

stream

表示文件中的一段二进制流，每一个stream的数据会根据该列的类型使用特定的压缩算法保存。

protobuf


message Stream {
 enum Kind {
 // boolean stream of whether the next value is non-null
 PRESENT = 0;
 // the primary data stream
 DATA = 1;
 // the length of each value for variable length data
 LENGTH = 2;
 // the dictionary blob
 DICTIONARY_DATA = 3;
 // deprecated prior to Hive 0.11
 // It was used to store the number of instances of each value in the
 // dictionary
 DICTIONARY_COUNT = 4;
 // a secondary data stream
 SECONDARY = 5;
 // the index for seeking to particular row groups
 ROW_INDEX = 6;
 // original bloom filters used before ORC-101
 BLOOM_FILTER = 7;
 // bloom filters that consistently use utf8
 BLOOM_FILTER_UTF8 = 8;

 // Virtual stream kinds to allocate space for encrypted index and data.
 ENCRYPTED_INDEX = 9;
 ENCRYPTED_DATA = 10;

 // stripe statistics streams
 STRIPE_STATISTICS = 100;
 // A virtual stream kind that is used for setting the encryption IV.
 FILE_STATISTICS = 101;
 }
 required Kind kind = 1;
 // the column id
 optional uint32 column = 2;
 // the number of bytes in the file
 optional uint64 length = 3;
}

message ColumnEncoding {
 enum Kind {
 // the encoding is mapped directly to the stream using RLE v1
 DIRECT = 0;
 // the encoding uses a dictionary of unique values using RLE v1
 DICTIONARY = 1;
 // the encoding is direct using RLE v2
 DIRECT_V2 = 2;
 // the encoding is dictionary-based using RLE v2
 DICTIONARY_V2 = 3;
 }
 required Kind kind = 1;
 // for dictionary encodings, record the size of the dictionary
 optional uint32 dictionarySize = 2;
}

索引支持

ORC支持三种级别的索引：

level	位于ORC的哪块	数据内容
file level	file footer	整个文件的列级别的统计
stripe level	file footer	每个stripe的列级别的统计
row level	stripe的最开始部分	每个RowGroup的列级别的统计和每个RowGroup的起始位置

Row Level

行级的索引主要有Row Group Index 和 Bloom Fliter Index

Row Group Index

索引由多个原始类型列的ROW_INDEX stream组成，每个Row Group拥有一个RowIndexEntry。

默认10000行的数据组成一个RowGroup

protobuf


message RowIndex {
 repeated RowIndexEntry entry = 1;
}

message RowIndexEntry {
 repeated uint64 positions = 1 [packed=true];
 optional ColumnStatistics statistics = 2;
}

Bloom Fliter Index

由多个列的BLOOM_FILTER stream组成。每个列拥有一个BloomFilter

protobuf


message BloomFilter {
 optional uint32 numHashFunctions = 1;
 repeated fixed64 bitset = 2;
 optional bytes utf8bitset = 3;
}

message BloomFilterIndex {
 repeated BloomFilter bloomFilter = 1;
}

Bloom filter streams are interlaced with row group indexes.

数据访问路径

Postscript -> Footer -> 获取对于的StripeInfomation -> Stripe Footer -> Stripe Index -> Stripe Row Group -> Column

参考

Apache-Iceberg调研

Wed, 05 Oct 2022 19:55:54 +0800

一种用于大规模分析数据集的表格式。
一种对数据文件和元数据文件的组织规范。
一种介于存储和计算中间的schema语义抽象。
netflix开发开源，旨在提升拓展性、可靠性、以及易用性。

背景

HIVE 上云遇到的一系列问题：

依赖List和Rename语义，无法使用更廉价的OSS代替HDFS。
可拓展性问题。Hive中的Schema信息集中存储于metastore中，可能会成为性能瓶颈
不安全操作、cbo不友好、etc

特性

支持安全高效的schema，partition变更和演进，self-define schema，hidden partition

抽象了自己的schema，不绑定任何计算引擎层面的schema；schema层面维护partition。partition和sort order 提供transformer函数，如 date(timestamp)

支持对象存储，对fs语义依赖少
ACID语义支持，读写并行，写操作串行化: 读写快照分离；乐观处理写并行冲突，重试保证写入
snapshot，支持数据回滚以及时间回溯，支持snapshot过期删除（默认不删除数据文件，但可以定制删除行为(related api doc))。通过对比snapshot差异可以实现增量读取。
查询优化友好，predict pushdown， data file statistics,目前好像不支持compaction, 可以在snapshot过期删除的删除无效文件(deleteWith)
抽象程度高，方便改造优化拓展。catalog，读写路径，文件格式，存储依赖插件化。Iceberg的设计初衷是定义于一个标准、开发且通用的数据组织格式，同时屏蔽底层数据存储格式上的差异，向上提供统一的操作API，使得不同的引擎可以通过其提供的API接入。
其他：文件级别加密解密

生态

社区对OSS & Flink & Spark & Presto均有一定支持
- flink(detail)：支持流式读写和增量读取(基于snapshot)，upsert write(0.13.0-release-notes)
- presto: Iceberg connector
- Aliyun oss: # pr 3689
其他组件对接
- 对接下层存储：只依赖三种语义In-place write，Seekable reads，Deletes，支持AliOSS(# pr 3689)
- 对接其他文件格式：抽象程度高，目前支持avro，parquet，orc
- Catalog：可定制化(Doc:Custom Catalog Implementation),目前支持JDBC，Hive metastore，hadoop等
- 对接计算层：提供原生 JAVA & Python API，抽象程度高，支持大多数计算引擎
社区开放中立，可以参与贡献，提高影响力

表规范

对数据文件和元数据文件的组织规范。

Case：Spark + IceBerg + Local FS

ice-berg 支持parquet，Avro，ORC 三种文件格式

json


# 存储组织
test2
├── data
│ ├── 00000-1-ccff6767-12cc-481c-93fc-db9f1a57438c-00001.parquet
│ └── 00001-2-6c1e5a0b-89fe-4e77-b90a-1773a7fbbcc8-00001.parquet
└── metadata
├── 2c1dc0e8-1843-4cb9-9c55-ae43f800bf3f-m0.avro // manifest file
├── snap-8512048775051875497-1-2c1dc0e8-1843-4cb9-9c55-ae43f800bf3f.avro // manifest list file
├── v1.metadata.json // metadata file
├── v2.metadata.json
 └── version-hint.text // catalog

DataFile

数据文件，列存，parquet，orc

有三种类型的Data File，data file，partition delete file，equality delete file（

Manifest File

索引数据文件，同时包含statistics, partition,

json


[
 {
 "status":1,
 "snapshot_id":{
 "long":1274364374047997583
 },
 "data_file":{
 "file_path":"/tmp/warehouse/db/test3/data/id=1/00000-31-401a9d2e-d501-434c-a38f-5df5f08ebbd7-00001.parquet",
 "file_format":"PARQUET",
 "partition":{
 "id":{
 "long":1
 }
 },
 "record_count":1,
 "file_size_in_bytes":643,
 "block_size_in_bytes":67108864,
 "column_sizes":{
 "array":[
 {
 "key":1,
 "value":46
 },
 {
 "key":2,
 "value":48
 }
 ]
 },
 "value_counts":{
 "array":[
 {
 "key":1,
 "value":1
 },
 {
 "key":2,
 "value":1
 }
 ]
 },
 "null_value_counts":{
 "array":[
 {
 "key":1,
 "value":0
 },
 {
 "key":2,
 "value":0
 }
 ]
 },
 "nan_value_counts":{
 "array":[

 ]
 },
 "lower_bounds":{
 "array":[
 {
 "key":1,
 "value":"\u0001\u0000\u0000\u0000\u0000\u0000\u0000\u0000"
 },
 {
 "key":2,
 "value":"a"
 }
 ]
 },
 "upper_bounds":{
 "array":[
 {
 "key":1,
 "value":"\u0001\u0000\u0000\u0000\u0000\u0000\u0000\u0000"
 },
 {
 "key":2,
 "value":"a"
 }
 ]
 },
 "key_metadata":null,
 "split_offsets":{
 "array":[
 4
 ]
 },
 "sort_order_id":{
 "int":0
 }
 }
 },
 {
 // another data file meta
 }
]

Snapshot

代表某个时刻Table的状态。通过Manifest List File保存。
每次对Table进行数据变更都会生成一个新的Snapshot。

Manifest List File

包含了一个Snapshot包含的所有Manifest文件的信息，以及Partition stats和Data File Count。
一个Snapshot对应一个Manifest List File，每次提交一个Snapshot会生成一个manifest list file。
乐观并发处理，并发提交snapshot冲突时，后提交的请求会重试保证提交。

Each manifest list stores metadata about manifests, including partition stats and data file counts.

json


[
 {
 "manifest_path":"/tmp/warehouse/db/test3/metadata/f22b748f-a7bc-4e4c-ad6c-3e335c1c0c2b-m0.avro",
 "manifest_length":6019,
 "partition_spec_id":0,
 "added_snapshot_id":{
 "long":1274364374047997583
 },
 "added_data_files_count":{
 "int":2
 },
 "existing_data_files_count":{
 "int":0
 },
 "deleted_data_files_count":{
 "int":0
 },
 "partitions":{
 "array":[
 {
 "contains_null":false,
 "contains_nan":{
 "boolean":false
 },
 "lower_bound":{
 "bytes":"\u0001\u0000\u0000\u0000\u0000\u0000\u0000\u0000"
 },
 "upper_bound":{
 "bytes":"\u0002\u0000\u0000\u0000\u0000\u0000\u0000\u0000"
 }
 }
 ]
 },
 "added_rows_count":{
 "long":2
 },
 "existing_rows_count":{
 "long":0
 },
 "deleted_rows_count":{
 "long":0
 }
 },
 {
 // another manifest file
 }
]

Metadata File

包含了表的所有状态。表状态变更的时候会生成一个新的metadata，并替换原有的metadata file，此过程保证原子性。

The table metadata file tracks the table schema, partitioning config, custom properties, and snapshots of the table contents

json


{
 "format-version":1,
 "table-uuid":"175d0b61-8507-40b2-9c19-3338b05f3d48",
 "location":"/tmp/warehouse/db/test3",
 "last-updated-ms":1653387947819,
 "last-column-id":2,
 "schema":{
 "type":"struct",
 "schema-id":0,
 "fields":[
 {
 "id":1,
 "name":"id",
 "required":false,
 "type":"long"
 },
 Object{...}
 ]
 },
 "current-schema-id":0,
 "schemas":[
 {
 "type":"struct",
 "schema-id":0,
 "fields":[
 {
 "id":1,
 "name":"id",
 "required":false,
 "type":"long"
 },
 Object{...}
 ]
 }
 ],
 "partition-spec":[
 {
 "name":"id",
 "transform":"identity",
 "source-id":1,
 "field-id":1000
 }
 ],
 "default-spec-id":0,
 "partition-specs":[
 {
 "spec-id":0,
 "fields":[
 {
 "name":"id",
 "transform":"identity",
 "source-id":1,
 "field-id":1000
 }
 ]
 }
 ],
 "last-partition-id":1000,
 "default-sort-order-id":0,
 "sort-orders":[
 {
 "order-id":0,
 "fields":[

 ]
 }
 ],
 "properties":{
 "owner":"chenlan"
 },
 "current-snapshot-id":1274364374047997700,
 "snapshots":[
 {
 "snapshot-id":1274364374047997700,
 "timestamp-ms":1653387947819,
 "summary":{
 "operation":"append",
 "spark.app.id":"local-1653381214613",
 "added-data-files":"2",
 "added-records":"2",
 "added-files-size":"1286",
 "changed-partition-count":"2",
 "total-records":"2",
 "total-files-size":"1286",
 "total-data-files":"2",
 "total-delete-files":"0",
 "total-position-deletes":"0",
 "total-equality-deletes":"0"
 },
 "manifest-list":"/tmp/warehouse/db/test3/metadata/snap-1274364374047997583-1-f22b748f-a7bc-4e4c-ad6c-3e335c1c0c2b.avro",
 "schema-id":0
 }
 ],
 "snapshot-log":[
 {
 "timestamp-ms":1653387947819,
 "snapshot-id":1274364374047997700
 }

 ],
 "metadata-log":[
 {
 "timestamp-ms":1653387937345,
 "metadata-file":"/tmp/warehouse/db/test3/metadata/v1.metadata.json"
 }
 ]
}

Catalog

记录最新的metadata file路径

特性

ACID语义保证：原子性的表状态变更 + 基于快照读写
分区管理灵活：hidden partition，无感分区变更
支持增量读取：可以根据snapshot来增量读取每一次修改的数据
数据多版本：利好数据回滚
无副作用、安全的schema、partition变更

数据类型

不同数据格式的数据文件，对不同的Type会有不同定义

Nested Types
- struct：a tuple of typed values
- list：a collection of values with some element type
- map：a collection of key-value pairs with a key type and a value type.
Primitive Type

Primitive type	Description	Requirements
`boolean`	True or false
`int`	32-bit signed integers	Can promote to `long`
`long`	64-bit signed integers
`float`	32-bit IEEE 754 floating point	Can promote to double
`double`	64-bit IEEE 754 floating point
`decimal(P,S)`	Fixed-point decimal; precision P, scale S	Scale is fixed [1], precision must be 38 or less
`date`	Calendar date without timezone or time
`time`	Time of day without date, timezone	Microsecond precision [2]
`timestamp`	Timestamp without timezone	Microsecond precision [2]
`timestamptz`	Timestamp with timezone	Stored as UTC [2]
`string`	Arbitrary-length character sequences	Encoded with UTF-8 [3]
`uuid`	Universally unique identifiers	Should use 16-byte fixed
`fixed(L)`	Fixed-length byte array of length L
`binary`	Arbitrary-length byte array

读取 & 写入路径

select：catalog -> manifest list file -> manifest file -> data file -> data group

insert：reverse（catalog -> manifest list file -> manifest file -> data file -> data group）

update：delete & insert， data file + partition delete file + equality delete file，

使用Patition delete file transaction 内同一行数据反复插入删除的语义问题

delete：row level delete

参考

ice-berg spec

Flink+Iceberg的数据湖建设

Flink + Iceberg 全场景实时数仓的建设实践 Flink 中文社区

ice-berg aliyun oss

ice-berg Flink支持

基于Flink+Iceberg构建企业级实时数据湖

Flink 如何实时分析 Iceberg 数据湖的 CDC 数据

iceberg github

alluxio POXIS API

深度对比delta、iceberg和hudi三大开源数据湖方案

LevelDB Write

Tue, 10 May 2022 17:14:14 +0800

LevelDB源码阅读笔记第二章，有关LevelDB的Write流程。本文并不是step by step的源码阅读教程，而是仅仅作为我的学习笔记，简单记录我的问题与思考。

主流程

LevelDB主要的写入逻辑其实比较简单。首先将写入操作封装到WriteBatch中，之后再执行写入。

cpp


Status DB::Put(const WriteOptions& opt, const Slice& key, const Slice& value) {
 WriteBatch batch;
 batch.Put(key, value);
 return Write(opt, &batch);
}

WriteBatch

WriteBatch是对一组更新操作的封装，这一组操作会原子性的应用到状态机上。使用一块内存将用户的更新操作保存。

InMemory Format: | seq_num: 8 bytes | count: 4 bytes | list of records{ type + key + value}

cpp


class WriteBatch {
 ...
 // See comment in write_batch.cc for the format of rep_;
// WriteBatch::rep_ :=
// sequence: fixed64
// count: fixed32
// data: record[count]
// record :=
// kTypeValue varstring varstring |
// kTypeDeletion varstring
// varstring :=
// len: varint32
// data: uint8[len]
 std::string rep_;
}
// some opt
void WriteBatch::Put(const Slice& key, const Slice& value) {
 WriteBatchInternal::SetCount(this, WriteBatchInternal::Count(this) + 1);
 rep_.push_back(static_cast<char>(kTypeValue));
 PutLengthPrefixedSlice(&rep_, key);
 PutLengthPrefixedSlice(&rep_, value);
}

写入流程

写入操作主要有四步：

初始化Writer

Writer实际上就是一次写入操作需要的全部信息。

cpp


// Information kept for every waiting writer
struct DBImpl::Writer {
 explicit Writer(port::Mutex* mu)
 : batch(nullptr), sync(false), done(false), cv(mu) {}

 Status status;
 WriteBatch* batch;
 bool sync;
 bool done;
 port::CondVar cv;
};

Writer调度

LevelDB的写入其实是一种多生产者单消费者的模式，多线程生产Writer，单线程消费Writer。每个Writer由一个线程产生，但可以被多个线程消费。在LevelDB内部维护了一个Writer队列，每个线程的写入删除等更新操作会先将Writer追加到队列末尾，并用锁保证队列的数据安全。Writer被放入队列之后会进入等待，直到出现在队列头部（被调度）或者已完成（被其他线程处理）才会被唤醒。

在消费Writer, 执行具体的更新操作时，LevelDB通过将同类型（根据sync类型）的Writer合并来优化写入任务。

Writers Batches 写入

首先MakeRoomForWrite确保memtable有足够的空间以及WAL保证写入成功。如果当前的memtable有空间则复用，如果空间不足，则新建memtable和WAL，并将原来的memtable转为immemtable，等待触发compaction（minor compaction 是串行的）。
除此之外，函数还会判断L0文件的数量，通过配置以及触发器判断是否需要对写入速率进行限制。其中主要包含两个配置：
- Slowdown Trigger。触发是会让写入线程Sleep，以减缓写入的速度，使得compaction任务得以处理；同时，以此限制Level 0 文件的数量，保证读效率。
- StopWritesTrigger。停止写入线程。
BuildBatchGroup则会将队列从头部开始同类型的Writer任务中需要写入的batches合并，只得到一个batch。
之后则是将合并之后的Batch先写WAL,再写memtable中。

WAL

WAL文件被拆分为Blocks, Blocks由Record组成。格式如下图：

WAL Record Encoding

| Header{ checksum(4 bytes) + len(2 bytes) + type(1 bytes)} | Data |

其中Record主要有五类：Zero，Full，First，Middle，Last。其中Zero是预留给预分配文件。由于有个KV可能长度过长，需要由若干个Chunk记录，于是有了其他四种类型。

写入的流程

memtable

memtable的核心设计有两个：跳表以及KV在跳表中的编码。跳表保证了插入数据的有序性，具体的实现思路可以参考我的另一篇博客。

memtable的Key的编码之后的Key称之为Internal Key,其编码为| Original Key(varstring) + seq num(7 by) + type(1 byte) |

SeqNum 是在每次更新操作时生成的一个递增的序号，作为逻辑时钟标记操作的新旧。基于SeqNum可以实现基于快照（版本号）的读取。

Reference

LevelDB handbook

LevelDB 启动

Sat, 09 Apr 2022 14:43:25 +0800

之前就听LevelDB是所有搞存储的人都会读的一个代码库。最近正好忙完了搞完了毕设的代码，稍微闲了一些，于是也打算看看LevelDB的源码。

这是LevelDB源码阅读笔记第一章，有关LevelDB的启动流程。本文并不是step by step的源码阅读教程，而是仅仅作为我的学习笔记，简单记录我的问题与思考。

带注释的代码库之后应该也会放在github上供大家学习参考。

预备知识

数据库文件

编码和命名等等等设计的相关的细节暂时不论（我也没看到那部分），先专注与文件的意义与作用

shell


├── 000005.ldb
├── 000008.ldb // sst or ldb 都是 sst文件
├── 000009.log // WAL
├── CURRENT // 记录了使用的manifest文件的名字也用于表示数据库存在
├── LOCK // 空文件，用于保证只有一个db实例操作数据库
├── LOG // level打印的日志
├── LOG.old
└── MANIFEST-000007 // descriptor_file, 元数据文件

值得深究的问题，之后也许会写相关博客，暂时先抛出：

LOCK怎么保证只有一个DB实例持有数据库

其实本质上是利用fcntl系统调用，在LOCK文件上设置写锁

各种文件的编码问题

之后会有相关博客说说leveldb的编码设计

DB State

Leveldb是一种嵌入式数据库，一般作为一些应用的组件存在（比如用于分布式存储系统中元数据节点的数据落盘）。这些应用可能会crush或者优雅退出，此时会有遗留的leveldb数据文件存在，所以我们一般需要在启动时恢复原先数据库的状态。故而我们需要明确一个db实例的状态信息，以便在使用时确保这些数据crush save，在启动时能及时回复数据状态机。

那么第一个问题是DB state应该包括什么？leveldb是一个LSM存储引擎，本质上是LSM Tree 数据结构 + 各种读写和存储优化，基于此，结合leveldb的文档，DB state包含的需要持久化信息至少有：

每层Level对应相关的sst文件，每个sst文件对应的key range

key range 主要是为了避免不必要的IO
全局逻辑时钟，last_seq_number

数据更新都有个seq_num 标记更新操作的新旧, 并与排序相关
compaction相关的参数 (file_to_compact, score, point)

compact 相关, 以便在crush之后出发compaction
cmp name

db初始化后，数据的排序逻辑就确定了，不允许被更改，用此名字作为凭证
log_number, next_file_number

wal的编号和下一个可用的file编号
deleted_files 和 add_files

compaction 或者 ref == 0 等原因导致的需要删除和添加的sst文件

具体实现上，每次leveldb的元数据变更行为（一般由Compact导致）都会被记录在VersionEdit这个数据结构之中，所以leveldb的DB State实际上是初始状态 + list of Applied VersionEdit。

版本控制

既然说到了VersionEdit, 那就顺带说一说启动流程里有关LevelDB的版本控制相关的设计，主要涉及Version, VersionEdit,VersionSet三种数据结构。

为什么需要版本控制？简单来说就是leveldb使用了MVCC机制来避免使用大锁来提高性能。

命令记录级别的快照读是通过sequence_number来实现的，所有操作都会附带当前的sequence_number，以此判断当前操作允许读取的数据，大于命令seq_number的记录对于操作将不可见。

sst文件级别的MVCC是通过Version链实现的，主要为了避免以下场景的冲突：正在读取某个文件时，而后台major compaction试图删除此文件。

Manifest Content

上文我们说到Manifest是leveldb的元数据文件，保存了数据库需要持久化的状态。leveldb在启动流程中，可能需要通过已有的数据文件回复原有db的状态。除此之外，但出现版本变更时，leveldb会生成VersionEdit, VersionEdit记录的元数据变动也需要及时持久化到manifest中，以此保证leveldb MVCC多版本状态的Crush Safe。所以Manifest的中编码布局十分重要。

在Manifest内部，元数据状态机编码成SnapshotSessionRecord +list of SessionRecords，本质上是初始状态 + list of Applied VersionEdit。

一个Manifest内部包含若干条Session Record，其中第一条Session Record记载了当时leveldb的全量版本信息，其余若干条Session Record仅记录每次更迭的变化情况。

一个Session Record可能包含以下字段：

Comparer的名称；

最新的WAL文件编号；

下一个可以使用的文件编号；

数据库已经持久化数据项中最大的sequence number；

新增的文件信息；

删除的文件信息；

compaction记录信息

Menifest写入版本变更

对于leveldb来说，增减某些sstable文件需要作为一个原子性操作，状态变更前后需要保持数据库的一致性。

原子性

原子性体现在：整个操作的完成标志为manifest文件中完整的写入了一条session record，在此之前，即便某些文件写入失败导致进程退出，数据库重启启动时，仍然能够恢复到崩溃之前正确的状态，而将这些无用的sstable文件删除，重新进行compaction动作。

一致性

一致性体现在：leveldb状态变更的操作都是以version更新为标记，而version更新是整个流程的最后一步，因此数据库必然都是从一个一致性的状态变更到另外一个一致性的状态。

从Manifest中恢复DB

随着leveldb运行时间的增长，一个manifest中包含的session record会越来越多，故leveldb在每次启动时都会重新创建一个manifest文件，并将第一条session record中记录当前version的快照状态。

其他过期的manifest文件会在下次启动的recover流程中进行删除。

leveldb通过这种方式，来控制manifest文件的大小，但是数据库本身没有重启，manifest还是会一直增长。

DB State恢复流程

检查上锁情况，创建数据目录
检查lockfile，判断是否有其他db实例
检查Current file是否存在
从manifest中恢复记录的元数据
从wal里回复last_seq_number和file_number

主体的Open流程

新建默认DB，VersionEdit实例
加锁
从manifest和wal中恢复元数据
如果新db实例没有memtable,新建memtable和wal file
将VersionEdit apply, 并落盘到manifest中
尝试删除无用文件
尝试进行compact

参考

Storage on NoneBack

LevelDB MVCC

Sequence Number

Versioning

MVCC & Snapshot Read

Reference

Prometheus--TSDB

数据+查询模型

数据组织方式

文件组织格式

meta.json

chunks

tombstone

index 文件

加速磁盘查询

Compaction

什么时候会 compaction？

Retention

Snapshot

Reference

Dynamo: Amazon’s Highly Available Key-value Store

设计

技术

数据的分区

数据写入问题

参考

Flink-Iceberg-Connector写入流程

写入提交流程总览

写入流程源码分析

WriteStream

CommitterStream

写入问题

Apache-ORC调研

File Layout

File Tail

postscript

Footer

Stripe

Stripe Footer

stream

索引支持

Row Level

Row Group Index

Bloom Fliter Index

数据访问路径

参考

Apache-Iceberg调研

背景

特性

生态

表规范

Case：Spark + IceBerg + Local FS

DataFile

Manifest File

Snapshot

Manifest List File

Metadata File

Catalog

特性

数据类型

读取 & 写入路径

参考

LevelDB Write

主流程

WriteBatch

写入流程

初始化Writer

Writer调度

Writers Batches 写入

WAL

WAL Record Encoding

写入的流程

memtable

Reference

LevelDB 启动

预备知识

数据库文件

DB State

版本控制

相关数据结构