第一章Paimon数据湖介绍.pdfVIP

1.1

数据湖介绍

1.1.1

什么是数据湖

数据湖是一个集中式的存储库，允许你以任意规模存储多个来源、所有结构化和非结构化数据，

可以按照原样存储数据，无需对数据进行结构化处理，并运行不同类型的分析，对数据进行加

工，例如：大数据处理、实时分析、机器学习，以指导做出更好地决策。

1.1.2

为什么需要数据湖

当前基于Hive的离线数据仓库已经非常成熟，在传统的离线数据仓库中对记录级别的数据进行更

新是非常麻烦的，需要对待更新的数据所属的整个分区，甚至是整个表进行全面覆盖才行，由于

离线数仓多级逐层加工的架构设计，数据更新时也需要从贴源层开始逐层反应到后续的派生表中

去。

随着实时计算引擎的不断发展以及业务对于实时报表的产出需求不断膨胀，业界最近几年就一直

聚焦并探索于实时数仓建设。根据数仓架构演变过程，在Lambda架构中含有离线处理与实时处

理两条链路，其架构图如下：

正是由于两条链路处理数据导致数据不一致等一些列问题所以才有了Kappa架构，Kappa架构如

下：

Kappa架构可以称为真正的实时数仓，目前在业界最常用实现就是Flink

+

Kafka，然而基于

Kafka+Flink的实时数仓方案也有几个非常明显的缺陷，所以在目前很多企业中实时数仓构建中经

常使用混合架构，没有实现所有业务都采用Kappa架构中实时处理实现。Kappa架构缺陷如下：

1)

Kafka无法支持海量数据存储。对于海量数据量的业务线来说，Kafka一般只能存储非常短时间

的数据，比如最近一周，甚至最近一天。

2)

Kafka无法支持高效的OLAP查询，大多数业务都希望能在DWD\DWS层支持即席查询的，但

是Kafka无法非常友好地支持这样的需求。

3)

无法复用目前已经非常成熟的基于离线数仓的数据血缘、数据质量管理体系。需要重新实现一

套数据血缘、数据质量管理体系。

4)

Kafka不支持update/upsert，目前Kafka仅支持append。

为了解决Kappa架构的痛点问题，业界最主流是采用“批流一体”方式，这里批流一体可以理解

为批和流使用SQL同一处理，也可以理解为处理框架的统一，例如：Spark、Flink，但这里更重

要指的是存储层上的统一，只要存储层面上做到“批流一体”就可以解决以上Kappa遇到的各种

问题。

数据湖技术可以很好的实现存储层面上的“批流一体”，这就是为什么大数据中需要数据湖的原

因。

1.2

Paimon介绍

Apache

Paimon

是一种数据湖格式（lake

format），用于构建实时数据湖仓（Lakehouse）架

构，支持

Flink

和

Spark

的流处理和批处理操作。Paimon

采用

LSM（Log-structured

merge-

tree）

结构来支持高效的数据摄取、更新和查询，尤其适用于实时数据流处理和大规模批数据处

理了操作，可以实现更高效的实时更新和复杂的数据分析功能。

上图展示了

Paimon

在数据集成和数据分析中的使用，Paimon

采用

LSM

树

作为其存储引擎的

核心结构，通过这种数据结构高效地处理大规模数据的写入和更新操作，数据底层通过

分布式文

件系统（例如

HDFS、OSS

或

S3）进行持久化存储。

Paimon可以做如下数据集成操作：

从

MySQL

和

日志数据源

进行实时数据摄取（Real-time

Ingestion），将增量变化导入

Paimon。

整个数据库同步（Entire

Database

Sync），支持对整个数据库的同步，适合一次性导入数

据。

模式演化同步（Schema

Evolution

Sync），支持数据库模式的动态变化。

部分更新（Partial-Update），支持只更新部分字段而不影响其余数据。

批量覆盖（Batch

Overwrite），可以进行全量的批量覆盖操作，适用于需要重写数据的场

景。

基于Paimon可以实现如下数据查询和分析功能：

增量快照（Incremental

Snapshot），支持增量快照查询，可以高效地获取数据变化。

变更日志生成（Changelog

Producing），生成数据的变更日志，适合实时