INP 洞见，AI 时代 Data Infra 的必争之地——湖仓架构

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

今年众多的 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 几乎可以主导湖仓生态接下来的发展，帮助自己在激烈的湖仓竞争中赢得优势

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

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

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

数据湖的概念最早在 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 支持写时复制，和读时合并，而 Deltalake 只支持写时复制。

写时复制(copy on write):

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

使用列式(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，因此它们存储在外部。因此，数据库本身仅包含对外部文件实际存储位置的引用。

下面列举一些实现：

把文件的路径等元数据以表格形式存储下来，使用 SQL 作为索引
使用 Catalog 等产品的产品功能进行文件的管理和索引，文件通过系统统一存储/读取
直接以 blob 的数据格式写入数据湖表格式，如几百万张小于1m的图像
将图像、视频等经过机器学习模型处理过的特征写入数据湖中，采用 SQL 进行索引

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

数据湖的计算层

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

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

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

没有针对系统级的读写优化，性能比块存储差
相比于块存储的支持在存储上的增删改，对象存储只能进行上传/下载的操作，无法修改，要想修改也是下载到本地修改后上传覆盖，使用方式类似于百度网盘

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

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

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

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 年正式推出的。

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

能在几秒内就能完成几十亿行，几 PB 数据的计算
是算是可以被规模化的，即采用更多的计算节点，性能也可以获得线性的提升

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

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

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

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

产品	Iceberg 查询	Deltalake 查询	Hudi 查询
Apache Druid	支持	支持	不支持
Snowflake	支持	支持	极其糟糕的兼容方案
Databricks	支持	支持	支持
StarRocks	支持	支持	支持
ClickHouse	支持	支持	支持
Apache Doris	支持	不支持	支持
DuckDB	支持	支持	通过 Unity Catolog 可以支持，原生不支持
PuppyGraph	支持	支持	支持
PrestoDB	支持	支持	支持
Trino/Starburst	支持	支持	支持
Dremio	支持	支持	非直接支持，原生不支持
Redshift	支持	支持	支持
BigQuery	支持	支持	支持
SingleStore	支持	不支持	不支持
Impala	支持	不支持	支持（实验）
Firebolt	不支持	不支持	不支持

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

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

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

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

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

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

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

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

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

小结

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

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

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

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

AIGC 背景下的数据湖相关的基础设施建设

众多厂商押注湖仓一体的概念也绝非偶然，AIGC 的风靡也是冥冥之中数据基础设施的变迁的推手之一。

从对 LLM 的需求来看企业对于 AI 建设的需求大致分为三类

需要自建 LLM 来提升产品与业务效率的
需要使用 LLM 的能力但是综合成本和效用考虑不会自建的
AI 在主营业务上并没有太多的应用场景，更多使用集成了 AI 能力的产品

第一类——自建 LLM

这类的企业基本以现有的巨头为主，需要使用 LLM 构造产品，并有着海量客户。

例如，微软需要 LLM 生产更好用的桌面操作系统和桌面软件，苹果需要 AI 生产更好用的移动设备。和之前的 AI 相比，在中长周期内，已经很难会对模型的结构有新的迭代，更多的都是喂更多的数据。

第二类——使用接口

以中小型企业为主，使用接口，结合 RAG、Agent 等开发 AIGC 应用，可能供内部使用，也可能封装为产品对外服务，调用量可能很高，但一般少于第一类。

第三类——使用现成的产品

以传统企业为主，可能涉及将相关的信息、资料、数据托管在企业服务软件平台上。

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

其中 Data For AI 指的是，大量的用户数据和企业数据将用于模型的训练流程。

AI For Data 指的是，用 AI 能力把企业现有的数据资产以更加高效和充分的方式利用起来，一般场景以推理为主。

对于第一类企业而言，需要模型训练和模型推理两种场景，对应的数据应用方式两类都有涉及。而后两类以 AI For Data 为主。

Data For AI

以 MOSS 大模型的数据集为例，一个基本的数据文件的形式为：

很显然，这是一个非常标准的 JSON 格式文件，在大模型的训练过程中，这样的文件可能存在上亿个。对于企业而言，无论是 Fine-Tune 还是 Train from Scratch 都需要海量的类似的 JSON 文件。

挑战一，如何准备训练 LLM 所需的数据集。

训练的原始数据可能有多种来源：

公开数据集和公网上可被轻易下载和触达的开源的预训练数据
数据科学团队根据模型训练的需要在特定来源使用爬虫技术获取
企业自有数据，可能存在于各个部门不同的基础设施里，比如结构化数据库里存的客户对于商品的评价；半结构化数据库里存的客服与客户的对话；交易相关的以非结构化文本方式保存的日志；商品图、模特图等等非结构化的图片等等

那么对于一个自有的多模态大模型而言，对应这第一个挑战，相关工作可能有：

企业需要把以前的知识整理成类似的格式，构造海量的 Instruction-output 对
企业需要从外界爬取需要的数据，并整理成类似的格式
涉及到多模态的训练需要额外的图片的访问做 Instruction-output 匹配

挑战二，如何成体系地更新并管理 LLM 训练或 Fine-Tune 需要的数据以保证模型的迭代同时满足合规要求

和之前的 AI 相比，在中长周期内，已经很难会对模型的结构有新的迭代，更多的都是喂更多的数据，或者让模型能够更多地使用企业知识。因此，在现在模型训练的大量挑战会变成面向数据管理和使用的挑战。

如图中的语料数据，在这个问答对中，是一个显著的数学题问答。这样的回答有可能出现在教辅材料上，也有可能发生在老师学生的对话中，对话里面还包含了 Latex 公式。那么假如我们对语料文件使用文件夹分类的时候，到底把它归到哪一类呢？显然单纯的文件夹的管理并不能直接满足要求，因为非结构化数据本身的特性和标签足够复杂。对于数据的索引依赖一套有效的元数据管理体系，要求有分类、有来源、有权限等等。

显然这个问题一直是围绕 AI 持续存在的痛点，目前也并没有很好的解决方案。因此在 Lakehouse 的架构之间存在 Catalog 类的产品，随着 Snowflake 宣布开源 Polaris 和 DataBricks 开源了 Unity 这类 Catalog 的产品，也能说明，从需求侧来说，企业有越来越多的多源数据接入、管理、分析的需求。

挑战三，如何更加经济、成本可控地存储各种数据

随着企业数字化业务的增多，对应的数据信息也呈爆炸增长。数据文件体积和过去相比大了很多倍，过去的数据一般存放在专用的 NAS 服务器的文件存储中，或由专门的集群所搭建的 HDFS 存储中。在上一代数据湖中 HDFS 应用得尤其广泛。现代数据湖更多地会直接采用云服务商所提供的对象存储作为存储底座，因为它面向文件、海量、统一访问、安全、并且便宜，是最适合数据湖需求的存储类型。在对象存储基础上，有数据湖相应的软件，Hudi/Delta Lake/IceBerg 也都支持对象存储。

挑战四，如何运维复杂的数据流转的管道

在个人电脑上操作数据的时候相信都经历过类似的场景，把手机里的照片拷贝到电脑上进行处理。每次拷贝四五百张尚可，但是每次复制粘贴的操作面向四五千张照片的时候，大概率会卡死，然后你想挑出重点照片再拷贝，发现读取照片、预览照片都很慢几乎也不可操作。

于是你为了避免下次再碰见这个问题有了几个方案：

以后养成习惯，每多 100 张照片的时候就往电脑上同步一份
以后建立了一组文件夹/相册，把照片分门别类放起来，让每次的处理和使用范围能够快速有效地缩小
在手机上购买了一个很好用的照片处理软件，避免使用电脑处理照片

在数据基础设施的处理上，方案其实是类似的：

在传统数据分析中，数据仓库来承载经过 ETL 计算之后的结果，成为新的存储，在这个过程中，也少不了 Kafka、Flink 的参与，数据技术设施需要维护多套，并且存储成倍提升。传统数据分析使用的是方案 1，分批、按次、或实时完成数据的清洗和搬运，把大计算拆成小计算，大搬运拆成小搬运，利用业务闲时完成；
在传统机器学习过程中，有 Feature Store 来解决这个问题，将训练使用的字段经过合成、计算、聚合成为新的特征，占用部分存储，管理训练数据。Feature Store 的方案更像是混合了方案 1 和方案 2。
生成式 AI 产生的数据量太大，成本冲击也比较大，于是 DataBricks 提出了类似方案 3 的概念。手机就好比是数据湖，建一个能直接处理湖中数据的计算引擎。在数据量指数级增长的今天，数据基础设施的演进也基本向避免数据的搬运，减少二次加工进行。因此，这个计算引擎的价值在今天也随着数据量的增多而加大。

挑战五，如何在用基础设施越来越复杂的时候仍然保证用户的易用性

从数据的流向来看，对于用户使用的场景可以分为两类，一类是数据的流入，一类是数据的流出。企业为了应对更多的数据使用挑战，不仅要用更大量的数据，也要使用更多类型、格式的数据，因此都会选择数据湖作为数据存储的基础设施，而在数据湖的存储选型上，一般都会选择对象存储，也就是 MinIO 或 AWS S3 等作为数据湖的存储底座。然而在数据入湖的过程中并不是通过对象存储的通用接口上传就完成了，数据工程师仍然要额外考虑很多：

旧的已经在对象存储的数据如何管理？
跨云的数据如何管理？跨数据中心的数据如何管理？
对象存储的数据只能增删，无法修改，当数据流入很大的时候，如何做增量更新？
数据的目录、血缘信息如何存？用什么存？

当数据被提取/计算的时候，数据分析师和数据科学家仍然面临许多问题：

数据科学家无法使用对象存储的借口，如何能让他们用 SQL、一两行之内的 Python 就能便捷使用？
数据使用需要鉴权，如何能无感地使用数据并且合理鉴权
部分数据需要加密、脱敏，如何使用 SQL、Python 方便地配置加密、脱敏并按照权限让用户便捷使用

AI For Data

在数据驱动决策的流程上，虽然目前没有最佳实践，但是目前业界普遍在进行很多的研究和尝试。目前在这个环节中，仍然有很多需要人工参与的流程：

业务人员根据经营状况和企业的战略决定目前最需要关心的经营数据指标
数据开发把这些数据指标翻译成 SQL
SQL 执行之后都是一些原始的表格，有的表格被可视化为图形
一些决策者通过可视化图表产生业务指导和决策
一些决策者需要通过二次整理的经营报告来产生业务指导和决策

在上述的业务闭环中，如果让 AI 来参与，最理想的情况是通过 AI 让业务流程自发运转，人只需要在关键点进行观测，来保证系统运行不出故障。然而因为当前 AI 能力的限制，目前还无法用一套基础设施来完成这个流程。

AI 尚无法替代的环节

指标 SQL 化

对于结构化数据这种强逻辑和要求较为精准的计算场景，基于概率学的 AI 很难能够生成需要的复杂 SQL。目前市面上完全基于 LLM 进行 SQL 转义的产品基本没有能够满足客户要求的，反而是融合了一定业务知识和业务对应 SQL 的先验知识的产品目前都能取得较为靠谱的结果，但是离大规模的生产应用仍然有距离。

数据库查询 AI 化

分析型数据库和查询引擎是通过数据的相互关系执行的正向计算，保证白盒的同时能人为地评估、改进计算效率。对比 AI 的黑盒，用结果倒推规律再套用到其他结果的逆向计算来说，计算代价和效率具有天然的优势。随着业务场景的丰富，计算需要越来越快，占用的资源越来越少，因此计算速度和代价的要求越来越苛刻，因此 AI 难以胜任此类任务。

数据驱动决策的根本价值

其实根本价值在于两条：

适应企业所有的变化
产生有意义的经营决策

企业的策略随着每天的经营情况或在微观，或者宏观基本都需要调整，而通过数据形成知识，通过知识再变成决策的流程离开数字化将变得非常长，在过去常以月、季度为单位进行决策调整。企业经营者都希望进行更加细颗粒的决策支持以保证企业始终在正确的发展道路上。

因此 AI 的价值可以协助缩短生产正确决策的过程，企业可以更加敏捷地进行策略调整来改善经营，攫取更多利润。

从这个角度来说，真正的价值来源于加速决策到数据，数据再反哺决策的流程，因此使用 AI 优化任意一个单点，价值只有省去人力成本，但是不一定能够达到“增效”的程度。

当前的 AI For Data 进行了初步的探索

RAG 的诞生

使得数据可以进入大模型的分析流程

RAG 的原理很简单，把用户的输入向量化之后和数据库中的信息做匹配和查询，查询所得的信息通过大模型进行整合反馈给用户。当然在实践中，为了让查询和索引更高效，可能引入分层、分块等等复杂的策略。

在企业使用 LLM 的时候 RAG 的好处有两个：

避免大模型的幻觉，所有需要的信息都有精准的对应
能够利用企业现有的知识（无法进行数值计算）

RAG 目前能做什么事情

目前来看，通过观察可视化结果来生成经营报告，以及初步的通过业务进展来决定跟踪哪些指标，通过大模型结合企业现有的知识是能够负担一些的。

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

Data For AI

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

上述的五个挑战，归纳来看可以总结为三个点：

数据的管理与使用
计算的效率
对应的成本

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

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

AI For Data

短期尚无最佳实践

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

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

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

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

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

posted on 2025-03-19 19:57 ExplorerMan 阅读(320) 评论(0) 收藏举报

刷新页面返回顶部

ExplorerMan

INP 洞见，AI 时代 Data Infra 的必争之地——湖仓架构

导航

公告