小编导读：
AIGC 时代数据量和数据种类的需求飞速上涨，企业不仅需要将历史上各种数据基础设施中的数据进行分析使用，同样需要通过数据湖来建设新的 Single Source of Truth。本文阐述了数据湖的发展、构建、生态玩家并分析了 AI 是如何影响以湖仓为核心的数据基础设施建设。本篇文章是由 InfraNative Partners 安淳榆所带来的行业观察，旨在从宏观视角剖析湖仓在当代数据架构中的重要性。
湖仓架构与概念在北美大火，多家科技巨头纷纷跟进
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，有专门用于机器学习的文件存储系统等等，执行特定的任务，数据与存储都在某一个或某一套封闭的基础设施，使用专用的存储与计算执行专门的任务。而系统内的数据需要被其他设施调用通常会有抽取、迁移等等或繁琐或高风险的操作。企业都希望进行更彻底的解耦，让各种数据源能被各种计算引擎灵活调用。
https://inpractise.com/articles/databricks-melting-the-snow
坐拥 Spark 的 Databricks 若想在这个趋势下仍然具备竞争力，那么它必须能够兼容足够多样的数据源，而同样的，它自己的数据也能被灵活调用。Databricks 通过这笔收购，几乎坐拥了表格式的半壁江山，而由于湖仓一体的概念在当前 Data Infra 的建设中已成为流行趋势，经过充分验证之后，一定会选择合适的供应商来共建湖仓范式下的新一代数据基础设施：
Iceberg 开源社区带来潜在的湖仓线索，大量的北美公司在建设新一代数据基础设施体系时，均选择了 Iceberg 作为数据湖表格式，以苹果为例，苹果有 5 位成员（来源）在 Apache Iceberg 担任 PMC 席位（Project Management Committee，项目管理委员会，共同讨论项目发展的战略、未来规划等），足见其对于 Iceberg 的重视 Databricks 几乎可以主导湖仓生态接下来的发展，帮助自己在激烈的湖仓竞争中赢得优势
到底什么是湖仓？看下面的内容就够了
数据湖不是某一种技术，或某一套基础设施，而是一套解决方案
数据湖不是某一种技术，或某一套基础设施，而是一套解决方案
比较通俗地来讲，数据湖主要分为下面几个部分：
存储层仅仅保证数据能够被完整保存下来，单单存储数据对于企业来说，其意义和价值十分有限，而数据湖存在的意义是让保存下来的数据更好地发挥其价值，因此工程师在“如何用好数据湖中的数据”这个点上，积累了大量的工作。
数据湖的存储层
早期的数据湖基本选择 HDFS 作为底层存储
就像每次在格式化磁盘时候让你选择的“格式”一样，Windows 的用户常用 NTFS，苹果用户常用 APFS，这个 FS（File System）描述的是计算机和存储沟通的方式，也就是说，使用 HDFS 之后，把这些服务器上的磁盘，抽象成了一大块让你可以像使用本地计算机一样，随意把文件丢进去的空间。因此早期数据湖都采用 HDFS 作为底层存储，更多地也是为了在存+算的大数据生态上进行全盘考虑。
对象存储因为云计算的崛起和成本优势，对 HDFS 形成替代趋势
使用对象存储，可以以文件的形式存储所有的结构化、半结构化与非结构化数据，换句话说，只要是一个“文件”，所有数据一视同仁，都可以存储。当然它也有缺点：
没有针对系统级的读写优化，性能比块存储差 相比于块存储的支持在存储上的增删改，对象存储只能进行上传/下载的操作，无法修改，要想修改也是下载到本地修改后上传覆盖，使用方式类似于百度网盘
但是因为对象存储的价格实在是有太大的优势，所以现在云原生的产品技术栈都围绕着如何针对这些缺点尽可能地优化对象存储展开。
随着企业数据的爆炸式增长，各种各样的数据储量和复杂度都几何增长，数据不光要求能很好的保存，也要求云原生的基础设施能够充分利用，而作为低成本的，不挑存储格式的云原生的存储基础设施，恰好非常适合承担数据湖的落盘和存储介质。而 HDFS 的劣势相比之下也渐渐突出，因为其过度依赖 Hadoop 生态，并且成本高昂。
数据湖的元数据层
元数据（metadata）的概念在很多分布式系统里面都有所涉及，它一般描述的是数据自有的信息，在不同的系统中，元数据有着不一样的定义，因此很难对元数据下一个清晰、明确且通用的定义。好比一家公司里面有不同的员工，员工在公司工作，跟公司里面的业务产生交互。元数据更像是在描述这些员工本身的性别、职位、部门归属等，虽然不直接影响业务，但是组成业务和协作关系都离不开这些信息。元数据帮助体系运转，方便高效管理，但是不直接影响业务。元数据层一般包括但不限于以下的概念：
数据目录：记录了数据湖中存在哪些数据资产,包括数据的位置、格式、模式等信息,方便数据的发现和访问。
数据血缘：跟踪数据的来源和变更历史,包括数据从哪里来、经过了哪些处理等,有助于数据的审计和溯源。
数据质量：记录和管理数据的质量指标,如完整性、准确性、一致性等,确保数据质量满足要求。
数据安全和权限：管理数据的访问权限和安全策略,确保数据的安全性和合规性。
数据分类和标签：对数据进行分类和标注,方便数据的组织和管理。
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，这也是数据管理里面一个很重要的特性，可以允许数据的回溯，不同的分析结果可能对应不同时期的数据版本，通过这个特性可以很好管理数据分析流程。
结构化数据与半结构化数据直接用表格，那么非结构化数据怎么办呢？
其中存储又分为两种方式：blob 存储和文件存储。文件存储很好理解，就是把原始文件码放在指定的存储中，不更改其本身的编码方式、文件格式等等。另一种存储方式是 Blob 存储，Blob 指的是 Binary Large Objects，是一种常见于数据库系统的概念，不同的数据库系统以不同的方式存储 Blob。由于数据库结构通常不适合直接存储 Blob，因此它们存储在外部。因此，数据库本身仅包含对外部文件实际存储位置的引用。
下面列举一些实现：
把文件的路径等元数据以表格形式存储下来，使用 SQL 作为索引
使用 Catalog 等产品的产品功能进行文件的管理和索引，文件通过系统统一存储/读取
直接以 blob 的数据格式写入数据湖表格式，如几百万张小于1m的图像
将图像、视频等经过机器学习模型处理过的特征写入数据湖中，采用 SQL 进行索引
数据湖的计算层
数据湖中的数据要进行分析和挖掘，最后一公里即是计算与处理。最早的时候有 MapReduce 系统进行海量数据的计算，后来 Spark 以高计算效率著称，占据了数据湖计算层的半壁江山。对于结构化与半结构化数据而言，计算引擎基本都是基于 SQL，相比于传统的数据库系统而言，一个完整的分析型数据库有自己的存储、数据结构、计算引擎。而对于数据湖中的结构化数据与半结构化数据而言，有了 Iceberg 等表结构的帮助，SQL 的引擎直接在数据湖中的表上查询结构化的数据表格，非结构化数据也可以被解析为表格进行 SQL 查询。而对于非结构化数据而言，Catalog 系统也能提供良好的访问 API。数据都在湖中，计算是单独的基础设施，进行了存算分离解耦。如今，越来越多的分析型数据库和数据仓库供应商开始进行产品改造，让自家产品的 SQL 查询引擎层能够直接运行在数据湖中。
对象存储的大规模应用推动了数据湖脱离 Hadoop 生态
对象存储的大规模应用推动了数据湖脱离 Hadoop 生态
没有针对系统级的读写优化，性能比块存储差 相比于块存储的支持在存储上的增删改，对象存储只能进行上传/下载的操作，无法修改，要想修改也是下载到本地修改后上传覆盖，使用方式类似于百度网盘
但是因为对象存储的价格实在是有太大的优势，所以现在云原生的产品技术栈都围绕着如何针对这些缺点尽可能地优化对象存储展开。
随着企业数据的爆炸式增长，各种各样的数据储量和复杂度都几何增长，数据不光要求能很好的保存，也要求云原生的基础设施能够充分利用，而作为低成本的，不挑存储格式的云原生的存储基础设施，恰好非常适合承担数据湖的落盘和存储介质。随着对象存储的大量使用，渐渐形成了脱离 HDFS 构建数据湖方案的趋势。
更加开放和标准的生态与越来越强的计算引擎催生了湖仓的概念
更加开放和标准的生态与越来越强的计算引擎催生了湖仓的概念
生态的开放
在大数据时代的上半场，所有的产品技术栈几乎被 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 数据的计算 计算是可以被规模化的，即采用更多的计算节点，性能也可以获得线性的提升
分析型数据库在发展中，渐渐能够支持存算分离的设计，并且查询足够快，能够兼容表格式，针对对象存储做兼容和优化，这些进步都奠定了湖仓生态的繁荣的基础。
越来越多的数据库供应商开始拥抱湖仓方案
湖仓，也就是计算层的价值是全数据湖的产品中最大的
湖仓，也就是计算层的价值是全数据湖的产品中最大的
这些计算层的基础设施好比让数据湖中已积累大量资产变现的最后一公里，但是这件事情本身的难度又极大。做一个好的分析计算引擎需要从 CPU 指令集的层面开始考虑并设计相应的算子，还要考虑到对象存储的特性、表结构的特性等等，难度不亚于设计一个数据库系统。因此，计算层基础设施的建设属于极难但必须要做的事情。
对于存储层，因为 S3 等云上的对象存储服务几乎是开箱即用，并且在过去的十年中，存储已经足够成熟，并且全球的企业几乎都完成了数据积累，只是数据质量参差不齐，数据治理水平参差不齐，放在现在来看，似乎也没有必要为了数据湖专门打造存储，甚至有的已经被积累下来的数据其实并没有什么价值，这些数据存储的必要性也存疑，因此存储层被归在难度小，必要性一般的位置。
而表格式与元数据层中，表格式的设计比元数据的设计本身稍复杂一些，因为需要兼顾生态和写入/读取的性能，而元数据层更多反映的是数据治理与管理水平，这些设计比起技术能力的考验，更偏向于 CIO 的经验。但是正如前面分析，它也是挖掘数据资产这个金矿的“铲子”之一，关乎到数据资产变现
如果将难度和必要性看成一个直角坐标，那么这些基础设施的排布类似于这样：
湖仓概念下，各个技术与生态在数据湖版图上位置
湖仓概念下，各个技术与生态在数据湖版图上位置
湖仓的流行带动了整个软件生态的变化
湖仓的流行带动了整个软件生态的变化
因为湖上的计算引擎能力的增强，数据湖逐渐成为企业数据分析的 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 面临的许多挑战，归纳来看可以总结为三个点：
数据的管理与使用 计算的效率 对应的成本
在湖仓中，数据湖通过一套通用存储基础设施，作为企业的 Single Source of Truth 最大程度避免存储的重复建设从而降低成本。通过 Catalog、表格式、结构化索引、标签、框架等等手段解决数据的管理与使用问题，通过 Lakehouse 基础设施拔升计算效率。
举一个通俗的例子，数据的管理与使用好比好比用料清单和菜谱，对象存储和数据就是冰箱，而 Lakehouse 引擎是厨师，AI 是食客。食客的胃口随着 AI 技术的演进会越来越大，Lakehouse 就需要足够强大来满足食客的胃口。食客胃口膨胀，市场空间从千亿增长到万亿美金，对应的 Lakehouse 空间也会从几十亿增长到几百亿。
AI For Data
短期尚无最佳实践
通过在数据湖中存储向量，并且使用查询引擎去做匹配。但是目前尚不是业界共识，也没有进行大规模的生产级应用。生产级应用的向量匹配依然依赖类似于 ETL 的流程，从湖中抽取数据进入向量数据库完成匹配，并且仍然面临扩容、管道维护等等问题。
中长期来看湖仓一体价值不可替代
但是无论其能力如何整合演变，查询和数值计算本身是无法被替代的。可能在未来的某一时刻，我们扩展了计算的定义，使用结构化查询语言或者其他的 DSL 能够做更多的事情，甚至操纵一个带有智能的分析引擎对数据进行深度挖掘，但是 Lakehouse 本身的生态位置和数值计算能力是难以被替代的。
结语
综上，我们有如下观点和结论：
湖仓架构是 AI 对于多元化应用企业数据需求下的必然产物 湖仓的计算引擎层是高价值且重要的生态位，也是百亿美金级的黄金赛道，多家公司随着市场一起高速增长 数据湖与湖仓架构均不代指某个特定的软件或云基础设施，而是一套解决方案或者某一套最佳实践 虽然存量的建设有可能不会推倒重来，但是增量的数据基础设施一定都会 follow 湖仓趋势 以 SQL 为核心的结构化、半结构化的索引与非结构化的数据管理仍然是高效的，AI 并不会颠覆 SQL。相反，高效的数据索引与管理可以帮助企业加速 AI 的进程
关于 StarRocks
StarRocks 全球开源社区也正飞速成长。目前，StarRocks 的 GitHub star 数已达 8300，吸引了超过 350 位贡献者和数十家国内外行业头部企业参与共建，用户社区也有过万人的规模。凭借其卓越的表现，StarRocks 荣获了全球著名科技媒体 InfoWorld 颁发的 2023 BOSSIE Award 最佳开源软件奖项。
