阿里云DLF数据湖：AI时代数据基础设施演进_AI热点日报

阿里云DLF作为OpenLake存储底座，通过智能存储优化、统一元数据管理与多模态数据湖能力，深度支持Paimon等湖格式，构建大数据与AI深度融合的湖仓一体架构，提升企业数据治理与分析效率。

# 面向 AI 时代的数据基础设施演进：阿里云 DLF 与 OpenLake 完整教程

在数据与 AI 深度融合的当下，数据基础设施正经历从传统数据湖仓向统一、智能、多模态平台的深刻变革。本教程将带您全面了解阿里云 OpenLake 与 DLF（Data Lake Formation）如何引领这场革新，并为您详细解析数据湖格式的演进、元数据管理的升级以及面向 AI 的多模态数据湖能力。

导读与分享嘉宾

本次分享题目为 OpenLake 面向 AI 时代的数据基础设施演进，由阿里云高级技术专家李劲松主讲。主要介绍以下四个核心部分：

背景介绍：当前数据趋势与 OpenLake 的定位
数据湖基础设施的演进：从 Hive 到现代湖格式的飞跃
DLF 数据湖平台：OpenLake 的存储底座
DLF 数据湖平台：多模态数据湖

小提示：本教程以技术演进为主线，如果您对特定湖格式（如 Paimon、Iceberg）或智能优化功能特别感兴趣，可以直接跳转到对应章节阅读。

01 背景介绍：为何需要新的数据基础设施？

当今主要数据趋势，是从传统的数据湖和数据仓库，融合到一种新的架构——湖仓一体。这一架构由四层组成：计算引擎、元仓、统一的湖格式存储以及统一对象存储 OSS。

目前，业界的发展方向已经不仅仅是数据湖仓，而是更进一步，将 AI 数据、搜索数据等，都统一在一个更大的数据湖仓中。这意味着要实现：

表和文件的统一管理
统一的元数据体系
统一的存储体系

阿里云 OpenLake 解决方案定位为大数据、搜索、AI 一体化的开发平台。它集成了众多引擎，包括阿里云自研的 Hologres、MaxCompute，以及开源的 Flink、Spark、StarRocks 等。

OpenLake 致力于打造一个基于统一元数据、统一存储的计算引擎平权的联合计算架构。其主要的湖格式是 Paimon 和 Iceberg，并基于此实现了对图像、视频、文本、机器学习模型等内容的管理。

02 数据湖基础设施的演进

数据湖技术的核心演进，围绕着两个核心维度展开：文件格式（Lake Format） 和 元数据管理。下面我们逐一深入解析。

2.1 Hive 格式：松散的共享文件管理

传统 Hive 格式，本质上是 Shared File Storage for Batch Processing。它的核心不是对数据的具体文件进行管理，而是对文件夹进行管理。比如：

分区对应一个文件夹
表对应一个文件夹
文件夹里包含 ORC、Parquet、CSV、JSON 等格式的文件

Hive 通过 List 文件夹的方式来读取表中内容。这种松散的管理方式导致：

架构与处理逻辑非常简单
数据处理能力严重缺失，只能完成非常基础的操作（如 Insert Overwrite）
无法通过 Insert Into 来增加部分文件
一致性保障非常差

2.2 从 Hive 到湖格式：核心解决批更新问题

针对 Hive 不管理文件的问题，Iceberg、Delta Lake、Paimon 等现代湖格式应运而生。它们对文件进行细粒度管理，带来了革命性的优势：

支持 ACID Transaction：每一次 Commit 都是原子操作，能清楚地知道增减了多少文件。
冲突检测：多个作业同时 Commit 时，能检测并处理冲突。
细粒度操作：支持 Delete、Update，可以针对性地 Rewrite 受影响的文件，而不是重写整个表。

具体场景对比：批更新

在数据库场景中，最大的诉求是数据带有主键。例如，需要将每天产生的增量数据（Staging table）Merge 到目标表中。

Hive 方式：使用 Insert Overwrite，需要将 Staging 表和 Target 表的两个分区进行 Join，读写所有数据，新增完整副本，造成计算和存储的大量浪费。
湖格式方式：使用 Merge Into 语法，自动检测影响哪些文件，只更新需要的文件，效率更高，还能通过时间旅行查询历史数据。

⚠️ 重要提示：湖格式的负担
湖格式也并非无脑替换 Hive 表，它带来了两个需要管理的负担：
1. 小文件管理：细粒度更新可能产生大量小文件，对 HDFS Name Node 和 OSS 造成压力。
2. 版本管理：表的版本会不断增多，需要做好版本淘汰，否则空间会越来越大。

2.3 从 Iceberg 到 Paimon：核心解决流更新问题

如果说 Hive 到 Iceberg 解决的是批更新（天级或小时级），那么 Iceberg 到 Paimon 解决的则是实时流更新。

Paimon（前身为 Flink 社区的 Flink Table Store）在 Iceberg 基础上核心增强了 Streaming Processing 能力：

支持从 Kafka 或 Flink CDC 实时同步到下游 Paimon 表
支持 Schema Evolution：上游增加列，下游自动增加列
支持一个 Job 整库同步，维护成本极低

流更新的新挑战：

bucket（桶数）定义难：数据量大、吞吐高时需要多桶，但桶数过多资源消耗大、合并效率低；桶数过少则造成反压和数据延迟。
后台 Compaction 影响写入：类似 HBase 的 LSM，Compaction 发生在写入过程中可能影响写入性能和资源消耗。

2.4 OpenLake 上的湖格式性能测试

以下是在 OpenLake 上进行的性能测试结果：

流测试：Paimon 在流更新方面大幅领先 Hudi 和 Iceberg。
批测试（TPC-DS Benchmark）：Paimon 同样大幅领先 Hudi 和 Iceberg。

所以，在 OpenLake 上，推荐大家使用 Paimon 湖格式。

2.5 数据湖时代元数据管理的演进

除了文件格式，元数据管理也是一个亟待解决的大问题。传统的事实标准是 Hive MetaStore（HMS），但它存在诸多局限：

针对 Hive 设计，无法理解 Iceberg、Paimon 等湖表概念
权限模型与 Ranger 绑定，难以统一审计和管理
难以扩展和集成 AI 相关能力

业界已经出现多种新方案，如 Snowflake 的 Polaris Catalog、社区的 Gra vitino Catalog、Databricks 的 Unity Catalog。而 Paimon 也在 1.1 版本中推出了自己的 Paimon REST API 和 Catalog。那么，专门为 Paimon 打造的元数据系统在哪里？答案就在下一章的 DLF 中。

03 DLF 数据湖平台：OpenLake 的存储底座

DLF（Data Lake Formation） 是 OpenLake 的存储底座，它如何解决前面提到的小文件、版本管理、元数据管理等问题？我们逐一来看。

3.1 Data Lake Formation 数据湖仓管理平台概览

DLF 的整体架构自下而上为：

底层存储：OpenLake OSS
Lake Format 层：Apache Paimon，支持 Parquet、ORC、A vro，并正在集成 Lance File Format（面向多模态）
实体层：Catalog、Database、Table、View、Function、Volume
开放接口：DLF 实现了 Paimon REST API，围绕开源开放的接口设计
引擎支持：对接自研引擎（Hologres、MaxCompute）、开源引擎（Flink、Spark、StarRocks）、AI 引擎（Python、PyArrow、Ray、DuckDB）

在体系上，DLF 核心加强了元数据管理（Metadata Management），提供一体化界面、基于 OpenLake Run Role 的权限管理、后台元仓服务，以及最重要的——智能存储优化。