关于数据湖:读Paimon源码聊设计引子
最近我司开始摸索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 OffServing、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的弱小与不足之处。 目前该我的项目还处于孵化中，后续我会始终关注其实现细节，敬请期待。