为什么发展Paimon，Paimon是为什么而诞生的，以及现在Paimon使用的主要场景。Paimon的格式区别于Iceberg、Hudi的独特之处是什么。分为四个部分。第一个部分是数据架构的存储演进，第二部分是Paimon实时数据湖，做Paimon实时数据湖原因以及Paimon的发展，第三部分是数据湖，也是Paimon数据湖，它的实时流式处理相关的一个应用，它为什么能称为实时数据湖，到底加速什么，第四个部分是数据湖上的Paimon的非结构化数据的思考，以及AI相关的集成。

一、数据架构的存储演进

Data LakeHouse是Lake到Warehouse的完美结合。一般企业都有Data Warehouse，它是一个非常强大的内部的分析系统，它能存储数据、分析数据，但是它是相对封闭的，其中公司包括Hive、hadoop、HDFS，甚至基于阿里云上的OSS开源体系，Build是更偏向于Data Lake 的东西，它的基本含义是一个文件或者对象存储，可以存储任何你想要的任何东西。包括结构化数据、非结构化数据，json，其中非结构化数据包括图片、视频、音频之类的数据，Data Lake是一个非常通用的、非常粗糙的、非常底层的底层存储。

Data LakeHouse包括湖格式，希望在Data Lake上build出结构化的适合企业安全，包括企业更结构化的SQL的一套处理的架构，希望结合Data LakeHouse的高性能处理，安全包括权限系统，也结合Data LakeHouse灵活的处理的开放的体系，第一点是Data LakeHouse如何让Lake上的数据变得更像House，目前主流的存储格式是Hive，Hive对表的目录的管理，没有管理目录的内容，它只定义目录是属于这张表的，分区的目录是属于分区的，而对里面的文件没有任何的管理，用Hive是比较粗糙的类似于Data Lake 的使用方式，对它的写入只能是inser Overright，对它的读、写入完全没有任何的保障，提供的是一个比较粗糙的读写，不符合Data LakeHouse的更进一步的发展，近几年诞生湖格式的东西，包括Iceberg、Hudi、Delta湖格式的东西，它通过文件的重新定义，把文件管理起来，管理的就不仅是一个目录，它管目录下每一个文件，它通过slap sort、manifest file的机制把每个文件的引用管理起来，这张表就具有版本的效果，也具有更细粒度控制的效果。

举例说明，把文件管起来之后ACID的能力，可以避免类似的目录，也可以有一些基于文件的data skipping的，也可以支撑delete update merge into细粒度的操作。最后也可以支持时间旅行包括回滚、Branch， Tag的能力。

整体上，Data LakeHouse的House通过存储格式把Data LakeHouse上的数据变得更像House，更易管理起来。这里有一个问题，如果只是这样的核心目标，需要把Hive非常简单的文件格式迁移到一个比较复杂的湖格式上，而湖格式比较复杂，包括Iceberg、Hudi，Delta都有几十万行代码。如果仅仅是这些好处，从Hive迁移过来，面临可能有一些未知的bug。

Data LakeHouse不仅是右边的好处，它带来对业务的核心收益更多，让业务变得更加的实时，业务的时效性更好，Late flink Stream的技术能让数据时效性从天级到分钟级，甚至到秒级，第一个大的好处是streaming实时，第二个好处数据湖拿到非结构化数据 半结构化数据的处理，发现湖格式是结构化的东西，其实和hive的结构化完全一模一样，数据湖只能分析结构化的数据，所以数据湖也需要非结构化的管理和机器学习的更进一步的结合。首先介绍Paimon，其次在实时化方面介绍一部分，最后在非结化机器学习方面介绍一部分。

二、Paimon实时数据湖

Paimon实时数据湖的出发点是Streaming加实时。数据湖格式上做Streaming的处理，Hive公开的每个引擎都能进行读写格式，它是一个非常open的格式，这里把它叫做shared database storage for batch processing。在批处理上一个被所有计算引擎share的格式，Iceberg 包括Hudi ，Delta在Hive的基础上演化出来的更进一步的ACID的处理，这里把Iceberg叫做shared databasestorage for batch processing，像数据仓库更像数据库的存储，有更进一步的能力。

Paimon出发点是在Iceberg基础上这些东西还不够，最大能给业务带来效果的是streaming，是实时化，是时效性。所以Paimon不仅是batch processing包括batch processing， streaming procession，olap processing，所以它是结合湖格式加LSM技术，把时效性带到数据湖。

Paimon的生态体系结构已经非常的广，底下基于HDVS，OSS或者stream的存储介质。在上面基于文件的格式ORC，包括阿里的ORC，parquet在上面build一个非常丰富的生态体系，可以看到是左边是CDCingest各种数据源入湖到Paimon中，并且社区提供非常方便的入湖工具，右边是它支持各种各样的sacred query的computer engine，包括Flink流的，Flink包括批的Spark StarRocks，包括一系列的社区的计算引擎，最新的版本也提出Paimon Python API，通过Paimon Python API解锁机器学习，来自包括rag，Python一系列的生态，包括通过error格式的转换。支撑包括pandas之类的计算框架。

简单介绍Paimon的发展历程。Paimon是做湖上的实时化处理，所以它从Flink社区诞生的。它最开始的名字叫Flink Table store，去年的三月份正式从Flink当中剥离出来，单独发展，成为单独的项目进入Apache的孵化器孵化，到今年三月份正式毕业，成为独立的顶级项目。这也标志Paimon不仅是一个Flink存储，它是一个通用，公开，被共享的湖格式。对接的包括Flink流计算Spark StarRocks等一系列的引擎，预计在11月份发布1.0版本，预计Paimon在批，在流，在Olap已经达到非常完善的程度，在1.0当中会引入来自AI相关的集成，让Paimon成为真正能处理非结构化数据的数据湖格式。

今年是Paimon诞生以来发展最快的一年。2022年诞生到23年，24年的孵化到24年在阿里巴巴集团内大规模应用，包括来自中国各大公司的应用非常迅速的发展，最新Paimon发布0.9版本是一个功能非常完善的一个版本，补充完善有缺陷的futures，并且核心增强了包括victor ，组件化letive的查询对接来自StarRocks的C++的查询，也兼容Spark生态，可以通过Spark生态查询Paimon的数据，最后优化对象存储的文件，包括文件缓存 文件格式。经过几个版本的迭代，Paimon在阿里云上的性能表现非常具有竞争力，本页PPT包括流更新，流上的处理，批上的处理，可以看出Paimon在目前阿里云支持的格式当中具有非常领先的性能，具有非常竞争力的性能表现。三个格式在阿里云上经过一定的优化，Paimon在阿里云上投入是最大的，也是优化的最多。

三、数据湖实时流式处理

第三部分是数据湖的实时流式处理，也介绍Paimon相关的streaming应用。实时流式处理让业务的时效性加强，从天级的时效性降低到分钟级。基于Paimon数据湖的VP的处理，成本不会增加特别多。成本可控的情况下，时效性增加，时延降低，整体呈现出一套批流完全一体的存储计算架构。以前用Kafka中间来做流处理，因为Kafka不可查，所以anyway最后需要可以查询的引擎，比如需要把数据写到StarRocks上，StarRocks才可查。但Paimon这套架构完全不一样。Paimon作为一个湖格式，它是可以批写批读，也可以流写流读，它把整条streaming链路建立起来，每一层都实时可查。架构能做到完全的流批一体，整套架构在阿里巴巴内部淘天集团非常迅猛的一个推进当中，已经迁移很多业务到这套架构上，发现整体的实时的成本降低，然后流批完全一体，业务开发效率得到非常大的提升，不是流批割裂的两套架构。

Paimon的能力有三个，第一个是它可以支持更新的数据入湖。第二个特性是能流读流写。流读流写不是简单的把数据流读流写，可以给Paimon声明一张图组件表，组件表就可以表现的像MYSQL，也可以实时的流式的更新数据，组件表也能实时的产生Change log给下游的消费，能做到非常准确的类似number架构，CPA架构。因为它是基于存储来产生Change log，它能做到最正确的计算，所以在很多场景当中，它能做到流一份数据沉淀下来，不用批写批读，做批的刷新。最后一个场景是每一层都是可以被包括StarRocks包括Spark引擎实时查询。Paimon针对这些引擎做非常多的优化，能保证查询性能不弱于正常的批查询。

接下来展开讲三个场景，第一个场景就数据库CDC入湖，可以通过Flink CDC，各种connector包括mysql CDC包括mongo DB的CDC包括OCEANBASE一系列的CDC的能力。用Paimon包括社区Paimon提供的Paimon CDC的入湖方式，可以用最新的一个Flink CDC 3.1基于young的入湖方式定义数据集成的数据传输的脚本链路。包括商业化也做来自Kafka数据CDC的入湖。可以通过Kafka的入湖享受到整个流式入湖全自动，schema evolution ，schema跟着变来自源头的数据schema变，下面的Paimon表的schema也跟着变，也可以用类似整库同步的能力进一步节省资源，降低运维难度。第二个是湖上的全链路流式ETL，定义Paimon的merge engine，可以定义partial-update，也可以定义Aggregation的merge engine。基于把计算存入到存储的技术，目前在最新的版本当中已经逐渐成熟，也可以通过Paimon取代类似join的部分列更新，也可以基于Paimon定义聚合表，整体写入Paimon后定义Paimon merge engine，之后也可以定义Change log producer让Paimon表实时的产生Change log，但是产生的Change log是需要不小的代价。

整体湖格式的流读已经非常成熟，在商业化包括内部沉淀大量的case。流写流读基于Paimon做计算的替代，在后面的版本当中，会进一步来降低文件的cost，包括Change log合并 生命周期等，最后是湖上的Olap的加速，分为两个部分，第一个部分是实时数据的Olap。可以定义一个组件表，它接受上游数据的实时更新。实时更新的过程当中，可以通过StarRocks类似的引擎实时的查询，所以在社区推出一个组件表的deletion victor模式，基于deletion victor模式，它可以让存储本身和c++向量化更好的集成，可以让查询性能得到数倍的提升，在社区也有很多离线数据的Olap。离线数据直接Olap，可能会扫描全表的数据，Paimon也支持对离线数据做z-order排序。做z-order排序之后，在查询的时候就可以基于排序的range过滤大量的文件，Paimon在社区有文件索引。通用文件索引支持Bloom Filter，也支持最新的Bitmap进一步过滤不需要的文件。加强Olap的性能。

四、数据湖非结构化处理

最后是数据湖的非结构化处理，接触到数据湖格式之后，会发现数据湖是一个结构化的处理，它是一个表，需要定义字段，不是结构化处理，很难把视频 图片 大文件塞进去，所以Paimon在最新的版本当中也会推出Paimon object Table，希望通过Object Table管理非简化的数据，包括在OOS或者HDFS上的图片，视频，文件，音频之类的文件。做到管理就不能把这些数据都重新读一遍放到Paimon当中，Object Table方式通过一个视图，不操作这些文件，相当于是在后台建立文件的索引。把这些文件的原数据写到数据湖当中，通过这样的结构化视图就可以查询到Object Table，对一个目录或者多个目录的原数据的映射。拿到这些原数据之后就可以通过包括pySpark ，Flink SQL ，Spark SQL 等，通过这种结构化的处理，读表知道有哪些文件，这些文件的文件大小可以做一些过滤，也可以把这些文件读出来做一些处理，所以通过这样的方式把非结构化和结构化的SQL的处理，或者结构化的计算引擎的处理结合到一起，让整个结构化的处理更简单。Lopython也可以做到，但享受不到计算引擎的Spark，Flink分布式计算引擎的好处。通过这套结构化管理，可以把这些非结构化的数据通过结构化的方式管理起来，包括权限管理对接到正常的数仓的权限管理当中。刚才是Spark的图片处理，在Flink当中，在SQL当中也支持Model的一些处理，包括Model的预测，案例是假如根据training数据训练出Model，可以在Flink SQL中定义Model，然后也可以在SQL中定义Object Table映射到目录中的文件，通过纯SQL的调用，通过Model预测针对object数据做预测，通过纯SQL的方式产出一个模型预测数据处理的效果。这套链路只能通过包括python ，ray相关的计算引擎才能达到的效果。通过Paimon的object table的方式可以把这套体系融入到SQL的处理当中，融入到传统的大数据计算的分布式处理当中，是案例的简单的SQL处理，可以create Model，create object table，通过predict模型预测的函数，做模型的预测处理。

Paimon可以管Model，包括非结构化数据。SQL的结构化处理模型预测也可以得到结果，整个非结构化数据得到数据版本和管理，从而可以得到学员的依赖管理。也可以把结果数据和其他结构化数据进行join，以及进行联合的计算。