最近我司开始摸索 Paimon 在局部场景下的应用，因而我这边须要做一些技术储备，缓缓关注起来 Paimon 的一些实现细节。
简略介绍一下前辈 Iceberg
个别的数据湖都会设计成凋谢通用的，即不和特定的存储、计算引擎（比方 Spark 和 Flink）绑定。所以数据湖的定位是在计算引擎之下，又在存储之上，将其称之为 table format。须要强调的是数据湖个别是面向 OLAP 场景的，所以个别存储会抉择分布式文件系统。当初 OLAP 底层存储反对对象存储根本算是快成业界共识了，这玩意儿挺划算的。
数据湖的前辈根本就是 Hive 了。过后大家用 Hive 碰到的问题就是 Hive 耦合 HDFS 很厉害，最次要体现在：
- Hive 上的计算执行首先依赖于 list 操作。在对象存储上做 list 是个很慢的操作。
- Hive 的写数据依赖于 rename。但同样这个操作在对象存储上做特地的慢。
这两个问题间接导致无奈降本。从这点上来说，Iceberg 是本人保护了一套元数据，这块网上十分的全，就不再赘述了，google 上搜 iceberg file layout 一大把。
Hive 还有其余的问题，如：
- metastore 的瓶颈问题。
- 没有 ACID 保障。
- parition 字段必须显示的在 query 里。
- 下推能力无限。Hive 只能通过 partition 和 bucket 对须要扫描哪些文件进行过滤，无奈更加粗疏。只管 parquet 文件里保留了 max 和 min 值能够用于进一步的过滤，但没软用。
Iceberg 把这些都解了。基于快照实现事务、数据的更新，快照的数据也容许跳版本读取来做工夫回溯。同时收集的统计信息也更加细粒度，不仅仅是文件 parition 级别的，还会记录文件级的内容（比方一个文件中的 min、max 值）和实现文件内容级的信息——一个文件中的 min、max 等等。
听起来所有都还很美妙。惟一美中不足的就是 Iceberg 对于实时场景反对得不好：
- Flink 写入 Iceberg 会引发小文件的问题。
- Iceberg 不反对 CDC（OLAP 反对 CDC 确实有点离谱，然而确实有需要呀）。
- Iceberg 主键表不反对局部字段更新。这在实时数仓的场景中有点离谱。
Paimon 能够解决什么问题
目前看来 Paimon 基于 Iceberg 的场景上，去反对流读流写（这块后续会做源码剖析），甚至还反对了点查和预聚合。实质是分布式文件系统上套了一个 LSM，这样数据都是有序写入——将屡次写入优化成一次程序写入，对存储系统上比拟敌对的。同时 LSM 能够作为一个简略的缓存，且有序写入为前面查问也能够缩小代价，这都能够为查问缩小代价。
从场景上来说它能够解决一些准实时业务的场景。因为基于对象存储来做底层存储，尤其还是列式存储。无论如何都不好做到实时场景：
- Paimon 的 CDC 依据不同的模式，会有不同的新鲜度。收回残缺 CDC 的模式要抉择 Lookup。个别是 Checkpoint 的距离 +10s 多新鲜度，这是比拟好的性能考量下。具体还要看数据量、分桶数、小文件数量的影响。
- 实时场景要求是毫秒级点查响应。Paimon 反对的是秒级点查。
但事实中真正须要实时类场景的业务有多少呢？因为数据的新鲜度往往和业务决策周期有关系。这么来看，数据新鲜度的要求从高到低，对于业务场景的总数来说，肯定是一个金字塔形态的。
咱们后面提到过数据湖个别不会和任何计算引擎绑定。因而业界还有一种玩法叫湖上建仓，计算能力用的是 OLAP，数据来自数据湖。这样就很有想象力了，因而当初一些实时 + 离线的场景会用不同的存储引擎，那么数据就会拷贝好几份。如果数据都放在同一个数据引擎中，这样能够缩小不少的存储老本。（对于通用型设计 这块后续会做源码剖析）
具体实现还是看对于性能的要求的：
- 要求低就做一些简略的优化间接捞数据。
- 再高点就缓存到 OLAP 里。
- 再高点就不仅仅是缓存到 OLAP 里，还会做物化视图。
Trade Off
Serving、Trascantion、Analytics
依据业界常识，咱们会发现：
- 面向在线利用，高并发、疾速、简略，如：HBase、Redis
- 面向剖析的，大规模数据扫描、过滤、汇总，如：Hive、Presto
- 面向事务、随机读写的，如：MySQL，PostgreSQL
数据湖是典型的 OLAP 产物。但联合上文，它确实具备肯定的随机读写能力。
Buffer、Mutable、Ordered
存储构造有三个常见变量：是否应用缓冲、应用不可变的还是可变的文件，以及是否按顺序存储值（有序性）。
因为 TiDB 底层的 RocksDB 用了 LSM。因而应用了缓冲、不可变性以及程序性。
RUM
有一种风行的存储构造开销模型思考了如下三个因素：读取（Read）、更新（Update）和内存（Memory）开销。它被称为 RUM 猜测。
RUM 猜测指出，缩小其中两项开销将不可避免地导致第三项开销的好转，并且优化只能以就义三个参数中的一个为代价。咱们能够依据这三个参数对不同的存储引擎进行比拟，以理解它们针对哪些参数进行了优化，以及其中隐含着哪些可能的衡量。
一个现实的解决方案是领有最小的读取开销，同时放弃较低的内存与写入开销。但在事实中，这是无奈实现的，因而咱们须要进行取舍。
Paimon 容许在配置中自在设置 LSM 的高度，以便获取读与写之前的衡量。
底细鸟瞰
后面说到过，计算局部是依赖于计算引擎实现的，自身 Paimon 没有提供计算能力。存储则是基于局部是文件系统做了薄薄的一层 LSM。
从文件布局来看，Partition 相当于是一级索引，和 Hive 一样。Bucket 为二级索引，每个 Bucket 下都会有 Data file 和 Change log file。这意味着如果命中了 Parition 和 Bucket 条件，有一些额定的条件查问也不会太慢——个别都会收集文件级的统计信息，并对文件的 Reader 做一些过滤优化。
整体的布局还是和 Iceberg 挺像的，这边不再过多赘述。
小结
在这篇文章中我简略的介绍了一下 Paimon 要解决的问题，以及它的前辈 Iceberg 的弱小与不足之处。
目前该我的项目还处于孵化中，后续我会始终关注其实现细节，敬请期待。