阿里云DLF数据湖：AI时代数据基础设施演进

在数据与 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 的权限管理、后台元仓服务，以及最重要的——智能存储优化。

热点追踪提示词 一键复制

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：阿里云DLF数据湖：AI时代数据基础设施演进要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题