洞见｜AI 时代下我们需要怎样的数据基础软件？

小编导读：

AIGC 时代数据量和数据种类的需求飞速上涨，企业不仅需要将历史上各种数据基础设施中的数据进行分析使用，同样需要通过数据湖来建设新的 Single Source of Truth。本文阐述了数据湖的发展、构建、生态玩家并分析了 AI 是如何影响以湖仓为核心的数据基础设施建设。本篇文章是由 InfraNative Partners 安淳榆所带来的行业观察，旨在从宏观视角剖析湖仓在当代数据架构中的重要性。

湖仓架构与概念在北美大火，多家科技巨头纷纷跟进

今年众多的 AI 交易中，有如下两笔交易：

6月4日，Databricks 宣布收购最火的数据湖表格式 Apache Iceberg 背后的商业机构 Tabular，Databricks 表示最终的交易价格将在 10 亿美元以上。

6月21日，OpenAI 宣布收购搜索和数据库分析初创公司 Rockset，以增强其企业产品的基础设施。此次交易通过股票交易完成，估值数亿美元，成为 OpenAI 最大的收购之一。

AI 在应用层的战斗如火如荼的当今，多家科技巨头纷纷在数据湖与湖仓一体的建设上加大投入，这些公司在数据基础设施上的军备竞赛随着 Tabular 的收购也渐渐浮出水面。6月4日，Databricks 宣布收购最火的数据湖表格式 Apache Iceberg 背后的商业机构 Tabular，Databricks 表示最终的交易价格将在 10 亿美元以上。Snowflake 最终因为 Databricks 产品生态更加开放而输掉了这笔交易，对于 Databricks 而言，这也不单纯是一笔保护性收购，它对于 Databricks 的商业版图也十分有意义。

从市场空间来说，Marketresearch.biz 给出了对于湖仓市场空间的测算和预测，在 2023 年达到近 90 亿美元，并且有 22.9% 的 CAGR。

湖仓一体的概念大火之后，以 Snowflake 为首的传统数仓纷纷开始了支持湖仓架构的路，而湖仓技术继承自在数仓产品上打磨的丰富的分析型数据负载的优化经验于用户体验，Snowflake 也在年收入 20 亿美元之后仍然以 120% 以上的 NDR 保持高速增长 。据 Snowflake 自己在 2023 年的预测，Snowflake 在 AI 到来之后，市场空间可达到千亿美金以上。

此前，数据基础设施在企业内部的建设更像是烟囱型建设，有专门用于数据分析的数仓与 ETL，有专门用于机器学习的文件存储系统等等，执行特定的任务，数据与存储都在某一个或某一套封闭的基础设施，使用专用的存储与计算执行专门的任务。而系统内的数据需要被其他设施调用通常会有抽取、迁移等等或繁琐或高风险的操作。企业都希望进行更彻底的解耦，让各种数据源能被各种计算引擎灵活调用。

根据这个标准，Iceberg 无疑是数据湖表格式产品中最好的。Iceberg 是在设计上把写、读、存储的解耦都做的很好，所以更加灵活且兼容性更好，于此同时还具有不错的性能。在之前的采访中，Databricks 也直言不讳地承认了 Iceberg 与自家的 Delta lake 更加优秀，也初显了收购意图：

https://inpractise.com/articles/databricks-melting-the-snow

坐拥 Spark 的 Databricks 若想在这个趋势下仍然具备竞争力，那么它必须能够兼容足够多样的数据源，而同样的，它自己的数据也能被灵活调用。Databricks 通过这笔收购，几乎坐拥了表格式的半壁江山，而由于湖仓一体的概念在当前 Data Infra 的建设中已成为流行趋势，经过充分验证之后，一定会选择合适的供应商来共建湖仓范式下的新一代数据基础设施：

• Iceberg 开源社区带来潜在的湖仓线索，大量的北美公司在建设新一代数据基础设施体系时，均选择了 Iceberg 作为数据湖表格式，以苹果为例，苹果有 5 位成员（来源）在 Apache Iceberg 担任 PMC 席位（Project Management Committee，项目管理委员会，共同讨论项目发展的战略、未来规划等），足见其对于 Iceberg 的重视

• Databricks 几乎可以主导湖仓生态接下来的发展，帮助自己在激烈的湖仓竞争中赢得优势

到底什么是湖仓？看下面的内容就够了

湖仓是在各大公司建设完数据湖之后提出的新概念，因此要了解湖仓，我们先来了解一下数据湖是怎么样的基础设施。

1

数据湖不是某一种技术，或某一套基础设施，而是一套解决方案

数据湖的概念最早在 2010 年被提出，强调企业应该有一个这样的基础设施，用来以最原始的格式存储海量的文件。基于这个概念，后来有了各种各样的实现。

比较通俗地来讲，数据湖主要分为下面几个部分：

存储层仅仅保证数据能够被完整保存下来，单单存储数据对于企业来说，其意义和价值十分有限，而数据湖存在的意义是让保存下来的数据更好地发挥其价值，因此工程师在“如何用好数据湖中的数据”这个点上，积累了大量的工作。

数据湖的存储层

早期的数据湖基本选择 HDFS 作为底层存储

HDFS (Hadoop Distributed File System) 是 Apache Hadoop 的核心组件之一，是一种专为大规模数据存储和处理而设计的分布式文件系统。由于 Hadoop 的大数据组件及其生态的繁荣，很长一段时间内，因为易于部署且易于使用，且确实没有更好的分布式存储的替代方案，所以数据湖的存储角色由 HDFS 来承担。企业只要准备好服务器，用网线连接起来，进行网络配置之后安装 HDFS 软件，就有了一个巨大的存储空间。

就像每次在格式化磁盘时候让你选择的“格式”一样，Windows 的用户常用 NTFS，苹果用户常用 APFS，这个 FS（File System）描述的是计算机和存储沟通的方式，也就是说，使用 HDFS 之后，把这些服务器上的磁盘，抽象成了一大块让你可以像使用本地计算机一样，随意把文件丢进去的空间。因此早期数据湖都采用 HDFS 作为底层存储，更多地也是为了在存+算的大数据生态上进行全盘考虑。

对象存储因为云计算的崛起和成本优势，对 HDFS 形成替代趋势

说起对象存储，基本上都认为是云计算的显著特点之一，因为它足够便宜，便于扩展，且接口简单，深受大家的欢迎。在此之前，块存储是大家用得最多的存储，因为知名数据库，如 Oracle 等都是基于块存储构建的。和块存储相比，对象存储具有更低的价格，因为块存储具有“独占性”。指定的存储挂载到某个系统中时，其他的用户便不能访问、读取、写入这些存储，即便是当前存储上没有任何负载。而对象存储可以由多个用户进行统一访问和读写，提高了存储和网络的利用率，因此对象存储具有充分的成本优势和价格优势。

使用对象存储，可以以文件的形式存储所有的结构化、半结构化与非结构化数据，换句话说，只要是一个“文件”，所有数据一视同仁，都可以存储。当然它也有缺点：

• 没有针对系统级的读写优化，性能比块存储差

• 相比于块存储的支持在存储上的增删改，对象存储只能进行上传/下载的操作，无法修改，要想修改也是下载到本地修改后上传覆盖，使用方式类似于百度网盘

但是因为对象存储的价格实在是有太大的优势，所以现在云原生的产品技术栈都围绕着如何针对这些缺点尽可能地优化对象存储展开。

随着企业数据的爆炸式增长，各种各样的数据储量和复杂度都几何增长，数据不光要求能很好的保存，也要求云原生的基础设施能够充分利用，而作为低成本的，不挑存储格式的云原生的存储基础设施，恰好非常适合承担数据湖的落盘和存储介质。而 HDFS 的劣势相比之下也渐渐突出，因为其过度依赖 Hadoop 生态，并且成本高昂。

因此，虽然世面上现存的数据湖方案中，大都是基于对象存储或 HDFS 构建。但是随着对象存储的大量使用，渐渐形成了脱离 HDFS 转而使用对象存储构建数据湖方案的趋势。

数据湖的元数据层

元数据（metadata）的概念在很多分布式系统里面都有所涉及，它一般描述的是数据自有的信息，在不同的系统中，元数据有着不一样的定义，因此很难对元数据下一个清晰、明确且通用的定义。好比一家公司里面有不同的员工，员工在公司工作，跟公司里面的业务产生交互。元数据更像是在描述这些员工本身的性别、职位、部门归属等，虽然不直接影响业务，但是组成业务和协作关系都离不开这些信息。元数据帮助体系运转，方便高效管理，但是不直接影响业务。元数据层一般包括但不限于以下的概念：

• 数据目录：记录了数据湖中存在哪些数据资产,包括数据的位置、格式、模式等信息,方便数据的发现和访问。

• 数据血缘：跟踪数据的来源和变更历史,包括数据从哪里来、经过了哪些处理等,有助于数据的审计和溯源。

• 数据质量：记录和管理数据的质量指标,如完整性、准确性、一致性等,确保数据质量满足要求。

• 数据安全和权限：管理数据的访问权限和安全策略,确保数据的安全性和合规性。

• 数据分类和标签：对数据进行分类和标注,方便数据的组织和管理。

元数据层通常由专门的元数据管理工具(如 Apache Atlas、AWS Glue 等)来实现，为数据湖提供统一的元数据服务,支持元数据的创建、更新、查询等操作。拥有完善的元数据层有助于提高数据湖的可管理性和可用性。在实践中，元数据是为了更好地管理数据湖中的数据从而提高使用效率，因此也有企业选择自研或改造第三方的管理方案，或者自己选用更加适合的数据标签体系等等。因此，这些工具之间很多时候并非直接替换的关系，互相搭配使用或相互集成也很常见。

Databricks 开源了 Unity Catalog，Snowflake 宣布 9 月之前推出 Polaris Catalog，这些都是代表着提供数据存储的厂商为自己的客户打造的数据访问与管理的最佳实践。Polaris Catalog 尚未推出，而 Unity Catalog 被诟病并不能被很好地使用。也有一些开源的方案，如 Apache Gravitino 解决类似的问题。

数据湖的格式层

这层即是 Iceberg 等组件存在的层，与之对应的 Hudi、Deltalake 都是一类产品。这类产品为结构化数据与半结构化数据提供了可被查询能力。目前 Iceberg 是口碑最好的表格式产品。Hudi 和 Iceberg 支持写时复制，和读时合并，而 Delta Lake 只支持写时复制。

• 写时复制(copy on write):

  仅使用列式文件(parquet)存储数据。在写入/更新数据时，直接同步合并原文件，生成新版本的基文件(需要重写整个列数据文件，即使只有一个字节的新数据被提交)。此存储类型下，写入数据非常昂贵，而读取的成本没有增加，所以适合频繁读的工作负载，因为数据集的最新版本在列式文件中始终可用，以进行高效的查询。

• 读时合并(merge on read):

  使用列式(parquet)与行式(avro)文件组合，进行数据存储。在更新记录时，更新到增量文件中(avro)，然后进行异步(或同步)的 compaction，创建列式文件(parquet)的新版本。此存储类型适合频繁写的工作负载，因为新记录是以 appending 的模式写入增量文件中。但是在读取数据集时，需要将增量文件与旧文件进行合并，生成列式文件

Hudi、Iceberg、Delta Lake 的区别与对比

• Iceberg 的设计初衷更倾向于定义一个标准、开放且通用的数据组织格式，同时屏蔽底层数据存储格式上的差异，向上提供统一的操作 API，使得不同的引擎可以通过其提供的 API 接入，三个数据湖里只有 Iceberg 的表 Schema 是可以自定义的，写入不依赖 Spark，很多 SQL 引擎都可以直接写，且支持并发写

• Hudi 的设计初衷更像是 Uber 为了解决大数据系统的数据增量更新的问题而研发，Hudi 的 Schema 支持是三者里最差的，只有删除列、添加可选列，且写入必须是 Spark 的 Schema，不支持并发写

• Delta Lake 作为 Databricks 开源的项目，更侧重于在 Spark 层面上解决 Parquet、ORC 等存储格式的固有问题，并带来更多的能力提升，底层源码实现高度依赖 Spark，且写入必须是 Spark 的 Schema

下面以 Iceberg 为例，看看结构化数据是如何被存储的

Iceberg 的存储是以目录组织的，目录结构如下：

• 20211212/20211213 是分区目录

• Parquet 文件里面是真实的数据，例如，每次运行 INSERT DDL（每次插入数据），就有一个 Parquet 文件生成，每次操作都有一个

• Manifest 清单文件，每次生成一个 Parquet 文件的时候同样也会生成一个清单 AVRO 文件，包括这次的插入的数据属于什么表，什么分区，什么列、列统计信息等等，对于实际数据的描述

• Snapshot 快照文件，第二次的查询中，会包含第一次和第二次合起来的 Manifest 文件，这样一个查询过程其实是通过快照来定位清单，通过清单来定位真实数据，也就是说 Snapshot 等价于包含时间顺序的清单索引

• 元数据信息 JSON，每次操作都会生成一个，里边存储的每次修改对应的表情况，例如有哪些列，哪些快照，上次哪些快照、这次哪些快照等等，实现 time travel

每当进行一次对表格的增量更新，metadata 文件夹里面多一个 JSON 文件，表格的真实的元数据情况也指向最新的 metadata 的 JSON 文件，里面包含格式版本、位置、最后更新时间、分区规范等等。旧的 JSON 文件用于时间旅行等功能，回溯数据表以前的版本和状态。对应的每个数据版本，也就是每个 JSON 文件，都有一个 Manifest 文件列表，用于指向该版本的数据里面包含了哪些更新的实质信息，也就是包含哪些实质的清单文件，将清单文件的所有更新信息叠加起来就是当前版本数据的状态，通过这些清单文件索引到真实的数据落盘文件，也就是 Parquet 文件，就是一次表格的更新过程，而快照文件可以加速查询的过程。

存储和更新流程可用下图来表示：

https://thedatafreak.medium.com/apache-iceberg-a-primer-75a63470bfa2

值得一提的是，在表格式中，我们再次提及了“元数据”这个概念，但是显然这里的元数据是相对于 Iceberg 表格式系统而言的，而非对于整个数据湖系统而言。另外我们提到了 Time Travel，这也是数据管理里面一个很重要的特性，可以允许数据的回溯，不同的分析结果可能对应不同时期的数据版本，通过这个特性可以很好管理数据分析流程。

结构化数据与半结构化数据直接用表格，那么非结构化数据怎么办呢？

非结构化数据并不会被直接写进表格，虽然 Iceberg 的 Slack 中很多用户呼吁能够直接把图片、音乐、视频直接写进 Iceberg 表中，在实践中，应对非结构化的数据我们仍然需要考虑两个问题：存储和索引。

其中存储又分为两种方式：blob 存储和文件存储。文件存储很好理解，就是把原始文件码放在指定的存储中，不更改其本身的编码方式、文件格式等等。另一种存储方式是 Blob 存储，Blob 指的是 Binary Large Objects，是一种常见于数据库系统的概念，不同的数据库系统以不同的方式存储 Blob。由于数据库结构通常不适合直接存储 Blob，因此它们存储在外部。因此，数据库本身仅包含对外部文件实际存储位置的引用。

下面列举一些实现：

1. 把文件的路径等元数据以表格形式存储下来，使用 SQL 作为索引

2. 使用 Catalog 等产品的产品功能进行文件的管理和索引，文件通过系统统一存储/读取

3. 直接以 blob 的数据格式写入数据湖表格式，如几百万张小于1m的图像

4. 将图像、视频等经过机器学习模型处理过的特征写入数据湖中，采用 SQL 进行索引

同样，这些实现可以进行组合搭配，例如 Iceberg 的 Slack 中，有用户分享了他们在 AI 流程中的管理方式：使用 Catalog + 对象存储管理和存储最原始的视频文件，然后采用 AI 模型进行特征提取，存放在数据湖中，使用这些特征进行模型的调优，产生了不同的模型，之后使用表格来定位和存储这些模型文件的元数据。

数据湖的计算层

数据湖中的数据要进行分析和挖掘，最后一公里即是计算与处理。最早的时候有 MapReduce 系统进行海量数据的计算，后来 Spark 以高计算效率著称，占据了数据湖计算层的半壁江山。对于结构化与半结构化数据而言，计算引擎基本都是基于 SQL，相比于传统的数据库系统而言，一个完整的分析型数据库有自己的存储、数据结构、计算引擎。而对于数据湖中的结构化数据与半结构化数据而言，有了 Iceberg 等表结构的帮助，SQL 的引擎直接在数据湖中的表上查询结构化的数据表格，非结构化数据也可以被解析为表格进行 SQL 查询。而对于非结构化数据而言，Catalog 系统也能提供良好的访问 API。数据都在湖中，计算是单独的基础设施，进行了存算分离解耦。如今，越来越多的分析型数据库和数据仓库供应商开始进行产品改造，让自家产品的 SQL 查询引擎层能够直接运行在数据湖中。

2

对象存储的大规模应用推动了数据湖脱离 Hadoop 生态

Hadoop 系统里，HDFS 引领了分布式文件存储的风潮，风靡一时。因此早期数据湖都采用 HDFS 作为底层存储，更多地也是为了在存+算的大数据生态上进行全盘考虑。而说起对象存储，基本上都认为是云计算的显著特点之一，因为它足够便宜，便于扩展，且接口简单，深受大家的欢迎。在此之前，块存储是大家用得最多的存储，因为知名数据库，如 Oracle 等都是基于块存储构建的。和块存储相比，对象存储具有更低的价格，因为块存储具有“独占性”。指定的存储挂载到某个系统中时，其他的用户便不能访问、读取、写入这些存储，即便是当前存储上没有任何负载。而对象存储可以由多个用户进行统一访问和读写，提高了存储和网络的利用率，因此对象存储具有充分的成本优势和价格优势。

使用对象存储，可以以文件的形式存储所有的结构化、半结构化与非结构化数据，换句话说，只要是一个“文件”，所有数据一视同仁，都可以存储。当然它也有缺点：

• 没有针对系统级的读写优化，性能比块存储差

• 相比于块存储的支持在存储上的增删改，对象存储只能进行上传/下载的操作，无法修改，要想修改也是下载到本地修改后上传覆盖，使用方式类似于百度网盘

但是因为对象存储的价格实在是有太大的优势，所以现在云原生的产品技术栈都围绕着如何针对这些缺点尽可能地优化对象存储展开。

随着企业数据的爆炸式增长，各种各样的数据储量和复杂度都几何增长，数据不光要求能很好的保存，也要求云原生的基础设施能够充分利用，而作为低成本的，不挑存储格式的云原生的存储基础设施，恰好非常适合承担数据湖的落盘和存储介质。随着对象存储的大量使用，渐渐形成了脱离 HDFS 构建数据湖方案的趋势。

3

更加开放和标准的生态与越来越强的计算引擎催生了湖仓的概念

Databricks 于 2020 年首次提出了湖仓一体 (Data Lakehouse) 的概念，概念强调，在数仓中进行数据分析需要进行大量 ETL，而在过去数据湖进行了超量的数据存储，是否有办法增强数据湖的数据分析和处理能力，也就是前文提到的计算层的能力，使得数据分析的负载直接在数据湖中进行计算，省去大量的批处理。但是彼时，Databricks 的计算引擎继承自 Spark 的能力，提出了概念，但是仍未真正意义上在数据湖上获得和数据仓库中一样的数据分析能力和体验。因此，湖仓一体可以被看作是数据湖的一个增强版特性，它的真正实现离不开下面这些要素：

生态的开放

在大数据时代的上半场，所有的产品技术栈几乎被 Hadoop 生态垄断，曾经一度大家以为 Hadoop 生态就是最优解，直到后来 Clickhouse、Snowflake 的出现，颠覆了人们的认识，原来脱离了以 Java 立足的计算生态，我们仍然能把海量数据的分析和处理做得这么好，并且 Data infra 的设计能和云组件契合得这么好，从而做到真正面向云原生来设计数据基础设施。大数据也正式宣布进入下半场，企业开始拥抱 Iceberg、对象存储这样足够标准并且没有生态倾向的产品来构建自己的数据基础设施，数据在不同地区、不同的云、不同的存储产品中存储，用更开放的表格式和 Catalog 产品进行统一管理，不被某一项技术和生态绑定，迎来了新的技术繁荣。湖仓一体强调一个足够强悍的计算引擎，只有在开放生态下得以采用全新的设计而不依赖 Hadoop 生态的设计规范，才能设计出全新的产品。

数据库技术的进步

Facebook 在2012 年开始设计和开发了 Presto，目的是为了解决其内部数据分析师在 PB 级 HDFS 表上进行数据分析和查询的需求。起初，主要依赖 Apache Hive，Hive 基于 MapReduce 模型，速度较慢，无法很好地满足交互式查询的需求，因此 Facebook 开发了 Presto，性能比 Hive快 10 倍左右，在 PB 级别数据上可以进行秒级到分钟级的计算。Presto 于 2012 年秋季在Facebook内部启动开发，并在2013年冬季正式开源，开源后，Presto 迅速获得业界关注。2014年，Netflix 透露他们使用 Presto 查询 Amazon S3 中的 10 PB 数据。这是比较早的湖仓一体的雏形，而湖仓一体的概念是从 2020 年正式推出的。

从数据湖的角度来看，计算需要满足以下两点：

1. 能在几秒内就能完成几十亿行，几 PB 数据的计算

2. 计算是可以被规模化的，即采用更多的计算节点，性能也可以获得线性的提升

从而使得“在湖中直接计算”获得和在“数据仓库中计算”一样的体验。对于 Databricks 来说，虽然它提出了湖仓一体的概念，但 Databricks 对于 Spark 进行了更深的优化，并且补足了 SQL 查询引擎的能力，由 Databricks 托管的闭源版 Spark 性能比开源版足足高了五倍。

分析型数据库在发展中，渐渐能够支持存算分离的设计，并且查询足够快，能够兼容表格式，针对对象存储做兼容和优化，这些进步都奠定了湖仓生态的繁荣的基础。

越来越多的数据库供应商开始拥抱湖仓方案

下面进行了一些知名分析型数据库对于湖仓方案的支持情况，以下情况包含文档或第三方技术文章，部分产品对于湖仓的兼容并不好，有“文档欺诈”的嫌疑，在 Twitter、Slack 等社区中工程师可能发表不同的看法。里面不少供应商是最近才开始支持的，如 Impala。目前在湖仓的方案中，Trino、StarRocks 是兼容和优化都比较成熟的产品。

4

湖仓，也就是计算层的价值是全数据湖的产品中最大的

再一次说起老生常谈的一百多年前，美国淘金热的时候在旧金山的故事。最终金矿只有让少数淘金的人挣到钱，但是卖铲人多数却发了财。对于企业的数字化转型也是同样的道理，数据驱动的数字化转型取决于对于数据价值的挖掘程度是否充分。正如同 HDFS 刚开始风靡那样，企业把各种各样的数据先放进 HDFS 来构建数据湖，但是因为缺乏系统性的管理和挖掘的能力，数据湖在很多企业的实践中成为了“数据沼泽”，正是因为缺乏管理，以及缺乏让已有数据资产变现的能力，即好用的、高性能的计算层。

这些计算层的基础设施好比让数据湖中已积累大量资产变现的最后一公里，但是这件事情本身的难度又极大。做一个好的分析计算引擎需要从 CPU 指令集的层面开始考虑并设计相应的算子，还要考虑到对象存储的特性、表结构的特性等等，难度不亚于设计一个数据库系统。因此，计算层基础设施的建设属于极难但必须要做的事情。

对于存储层，因为 S3 等云上的对象存储服务几乎是开箱即用，并且在过去的十年中，存储已经足够成熟，并且全球的企业几乎都完成了数据积累，只是数据质量参差不齐，数据治理水平参差不齐，放在现在来看，似乎也没有必要为了数据湖专门打造存储，甚至有的已经被积累下来的数据其实并没有什么价值，这些数据存储的必要性也存疑，因此存储层被归在难度小，必要性一般的位置。

而表格式与元数据层中，表格式的设计比元数据的设计本身稍复杂一些，因为需要兼顾生态和写入/读取的性能，而元数据层更多反映的是数据治理与管理水平，这些设计比起技术能力的考验，更偏向于 CIO 的经验。但是正如前面分析，它也是挖掘数据资产这个金矿的“铲子”之一，关乎到数据资产变现

如果将难度和必要性看成一个直角坐标，那么这些基础设施的排布类似于这样：

5

湖仓概念下，各个技术与生态在数据湖版图上位置

6

湖仓的流行带动了整个软件生态的变化

因为湖上的计算引擎能力的增强，数据湖逐渐成为企业数据分析的 Single Source of Truth，我们观察到大部分的数据基础设施已经开始跟随这一范式发生变化，这个趋势虽然仍在进行，但是可以预见的是未来 5 年内的 Data Infra 都需要向这个生态靠拢。比如，可观测性的日志数据、时序数据可能会直接入湖，业务数据经过 Streaming 的 Pipeline 直接入湖，从而 ETL 和 Batch Computing 的增量将会减少等等。

小结

• 数据湖并不像数据库、数据仓库指的是某个确定的基础设施，而是一套技术标准或技术方案

• 湖仓一体并不是一套独立的基础设施，是一个理念，而对应这个理念是湖上的计算引擎具有超强的计算能力

• 因为数据湖生态越来越开放，数据的价值才能被很好挖掘，因此 Snowflake 和 Databricks 均放弃建设封闭烟囱

• 湖仓虽然热，但是很新，各个供应商目前有要支持新架构的共识，但是支持进度仍然具有差距

AIGC 时代湖仓生态下的 Data and AI

现在数据对于 AI 在企业中的应用可以分为两类：Data For AI 与 AI For Data。

• Data For AI：大量数据用于模型训练，如MOSS大模型训练所需的JSON格式数据集。

• AI For Data：利用AI提升现有数据资产的利用效率，主要涉及推理应用。

Data For AI

中长期来看，湖仓架构是未来

Data For AI 面临的许多挑战，归纳来看可以总结为三个点：

1. 数据的管理与使用

2. 计算的效率

3. 对应的成本

在湖仓中，数据湖通过一套通用存储基础设施，作为企业的 Single Source of Truth 最大程度避免存储的重复建设从而降低成本。通过 Catalog、表格式、结构化索引、标签、框架等等手段解决数据的管理与使用问题，通过 Lakehouse 基础设施拔升计算效率。

举一个通俗的例子，数据的管理与使用好比好比用料清单和菜谱，对象存储和数据就是冰箱，而 Lakehouse 引擎是厨师，AI 是食客。食客的胃口随着 AI 技术的演进会越来越大，Lakehouse 就需要足够强大来满足食客的胃口。食客胃口膨胀，市场空间从千亿增长到万亿美金，对应的 Lakehouse 空间也会从几十亿增长到几百亿。

AI For Data

短期尚无最佳实践

目前 Databricks 在其宣传材料中给了一套解决方案

通过在数据湖中存储向量，并且使用查询引擎去做匹配。但是目前尚不是业界共识，也没有进行大规模的生产级应用。生产级应用的向量匹配依然依赖类似于 ETL 的流程，从湖中抽取数据进入向量数据库完成匹配，并且仍然面临扩容、管道维护等等问题。

中长期来看湖仓一体价值不可替代

中长期来看 AI For Data 会更加聚焦，而非使用 RAG 解决某个单点问题。在数据驱动决策的闭环流程中，显著可以分为“查询前”和“查询后”，随着 AI 发展，可能使用一套智能系统整合了全部的数据驱动决策流程，也可能分为中间的某些系统模块，成为一个带有 AI 能力的系统工程。

但是无论其能力如何整合演变，查询和数值计算本身是无法被替代的。可能在未来的某一时刻，我们扩展了计算的定义，使用结构化查询语言或者其他的 DSL 能够做更多的事情，甚至操纵一个带有智能的分析引擎对数据进行深度挖掘，但是 Lakehouse 本身的生态位置和数值计算能力是难以被替代的。

结语

综上，我们有如下观点和结论：

1. 湖仓架构是 AI 对于多元化应用企业数据需求下的必然产物

2. 湖仓的计算引擎层是高价值且重要的生态位，也是百亿美金级的黄金赛道，多家公司随着市场一起高速增长

3. 数据湖与湖仓架构均不代指某个特定的软件或云基础设施，而是一套解决方案或者某一套最佳实践

4. 虽然存量的建设有可能不会推倒重来，但是增量的数据基础设施一定都会 follow 湖仓趋势

5. 以 SQL 为核心的结构化、半结构化的索引与非结构化的数据管理仍然是高效的，AI 并不会颠覆 SQL。相反，高效的数据索引与管理可以帮助企业加速 AI 的进程