Lakehouse 如何重塑企业数据生态？

大数据架构经过多年的演进，传统数据仓库和数据湖的局限性日益凸显。在此背景下，湖仓一体 Lakehouse 凭借其开放性和成本效益，迅速成为当今数据平台的主流架构。然而，随着进入 Data + AI 驱动的新时代，企业对实时数据分析的需求不断增加，对半结构化和非结构化数据的处理也愈显重要。那么，应该如何高效整合多种数据源，实现实时分析与智能决策？

近日 InfoQ《极客有约》X QCon 直播栏目特别邀请了 阿里云智能 Flink SQL 负责人伍翀 担任主持人，和 阿里云高级开发工程师罗宇侠、StarRocks 研发工程师王云霏、字节跳动研发工程师闵文俊 一起，在 Qcon 全球软件开发大会 2025 北京站 即将召开之际，共同探讨最新的 Lakehouse 架构演进趋势。

部分精彩观点如下：

• 未来 Lakehouse 架构将从分钟级逐步向秒级数据时效性迈进，以满足企业对不同数据时效性的需求。

• 技术选型需考虑存储格式、数据分析方式和底层数据的分层存储。

• 在计算引擎方面，可以根据负载类型选择最具性价比的计算引擎，许多引擎功能在逐步增强，满足更多需求，朝着“一个引擎满足所有需求”的目标迈进。

• 引擎应该越自治越好，功能开箱即用，功能开箱好用。

• 湖格式天然是为了更好地适应对象存储的特性而设计的。

• AI 对 Lakehouse 架构提出了数据时效性、存储格式、元数据、分析性能、操作语言等各方面的挑战，但也存在着很多机会。

在 4 月 10-12 日将于北京举办的 Qcon 全球软件开发大会上，我们特别设置了【Lakehouse 架构演进】专题。该专题将通过分享不同行业中的实际应用和成功案例，为业务发展提供新思路，并让参会者对未来的技术革新做好准备。查看大会日程解锁更多精彩内容。

以下内容基于直播速记整理，经 InfoQ 删减。

完整直播回放可查看：https://www.infoq.cn/video/dZmjyL6SMA5bTeet3oLS

Lakehouse 架构的演进与关键趋势

伍翀： 过去一年 Lakehouse 架构在国内和国外的发展都很迅猛，在商业上也发生几大引人注目的事件，比如 Databricks 十亿美金收购 Tabular，Snowflake 和 Databricks 都开源了他们的元数据产品，很多公司也都引入了或者正在引入 Lakehouse 架构，那么 Lakehouse 未来的关键发展趋势有哪些？

罗宇侠： 最重要的趋势是 Lakehouse 架构与 AI 技术的深度结合。Lakehouse 本身原生支持多模态数据的统一存储与管理，并能够结合向量嵌入（embedding）和索引技术，通过特征管理等方法，成为 AI 训练和 RAG 的基础设施。

其次，我认为另一个重要的趋势是数据时效性的提升。在 AI 时代，实时数据变得尤为重要，因为数据是否及时更新，直接影响到 AI 模型的准确性和有效性。因此，我认为未来 Lakehouse 架构将从分钟级逐步向秒级数据时效性迈进，以满足企业对不同数据时效性的需求。最近，像 Kafka 的商业化公司 Confluent 提出了 TableFlow，旨在将 Kafka 的数据流转移到 Iceberg 以及 Snowflake 公司准备收购消息队列创业公司 Redpanda 都进一步佐证了这一点。

最后，我认为未来 Lakehouse 架构将会更加标准化。随着生态中各个参与者的深入合作，包括数据集成服务商、BI 工具提供商、数据库和计算存储服务商等, 将推动形成一个标准化的 Lakehouse 全套解决方案。

王云霏：Lakehouse 的出现源于数据量和企业开销的高速增长，特别是在结构化、非结构化和半结构化数据的快速增长推动下。根据 IBM 报告，企业在数据上的年开销增长超过 30%，并随着 AI 的兴起，数据量和开销预计将继续增长。

数据的使用方式也在发生变化。过去，数据主要用于商业分析和 BI 应用，但随着 AI 的发展，数据将更多应用于 AI 场景。企业需要更多的数据和实时更新的数据来挖掘深层洞察，并支持快速决策。新技术的出现进一步改变了数据使用方式。对象存储降低了成本，开放格式使得各种数据可以以灵活的方式存储，进而让不同应用选择最具性价比的存储方式。

Lakehouse 架构正是基于这些趋势，它解决了成本问题并满足了开放存储的需求。随着开放标准的确立，预计到 2025 年，模块化的 Lakehouse 架构将成为企业的优选，帮助企业根据需求选择最合适的存储方案、引擎和元数据管理方式，从而在满足不同需求的前提下提升性价比。

闵文俊： 随着 Databricks 收购 Iceberg 背后的商业公司，以及 Snowflake 开源其元数据层 Polaris，去年还出现了元数据目录项目 Gravitino 的诞生。可以看出，各大厂商越来越重视元数据层的建设。这背后映射出的是，厂商们对开放标准的重视。开放标准不仅意味着你对云厂商的选择有更大的灵活性，也意味着你对标准制定的能力有更高的要求。

未来的 Lakehouse 架构将更加注重元数据的标准化，并且也会关注跨平台的兼容性。企业能从这一趋势中获益的主要方面是，通过元数据的标准化，可以打破企业内部各个数据源之间的数据孤岛，从而使数据能够发挥更多的价值。

另外一个方面是，整体的大背景和企业面临的问题，尤其是降本增效的需求。降本增效在 Lakehouse 架构中也扮演着重要角色。目前，存算分离已经成为一个显著趋势。在成本压力下，用户对性能的需求并未减弱。因此，Lakehouse 架构面临的一个共同问题是，在降低成本的同时，如何尽量减少性能损失。为了应对这一问题，各家的 Lakehouse 引擎逐渐通过深入挖掘硬件层面的能力，来提升整体性能。例如，向量化引擎和计算缓存等技术被广泛应用，以弥补成本与性能之间的平衡。

Lakehouse 架构的挑战与技术创新

伍翀：在 Data + AI 深度融合的当下，数据规模与复杂度剧增，这给 Lakehouse 架构在数据存储、实时处理及 AI 模型适配等方面带来了哪些具体且关键的挑战？其架构设计又该如何针对性地调整以应对这些冲击，并实现创新性的改变？

王云霏：Lakehouse 架构的优势主要体现在以下几个方面：首先，力求实现“单一数据源”，即避免冗余，减少存储开销，实际使用中存储成本最高可能减少 90%。其次，Lakehouse 希望确保数据具有较高的新鲜度，以便快速查询和使用。第三，简化 ETL 作业是 Lakehouse 设计的另一目标。

然而，实际应用中面临挑战着如何确保数据分析的性能与传统数据仓库相当这一挑战。过去一年，我们在性能优化方面取得了进展，StarRocks 与 Iceberg 或 Paimon 等数据湖格式结合，查询性能提升至 Databricks 引擎的两倍。AI 方面，我们面临的挑战是如何将 AI agent 与 Lakehouse 中的数据结合，比如如何结合传统数据平台的聚合与关联计算能力，满足 AI agent 在趋势性数据处理中的需求。

伍翀：AI agent 在某些场景下，特别是在做统计分析和批处理（batch）任务时，展现了很大的潜力。您能否进一步展开介绍一下？是否有您那边观察到的具体场景或应用案例，能够展示 AI agent 与特定业务需求或技术结合的情况？

王云霏：AI agent 已有一些原型系统，能够查询 Lakehouse 中的数据，但还不成熟。AI agent 需要感知理解数据，这可能导致元数据请求量显著增加。随着并发增加，如何高效解析数据成为关键问题，还有就是 AI agent 对实时性的要求较高，需要快速交互并采取行动。

AI agent 对数据的实时性和计算性能要求较高，当前的应对方向是增量计算、预计算和缓存系统优化，以支持高性能、高并发、低延迟的需求。与传统数据分析师不同，AI agent 支持更高的并发和更短的实时响应，这使得如何处理高并发、低延迟需求成为系统设计中的重要课题。

伍翀： 文俊老师和宇侠老师对 Data+ AI 这块的挑战有没有什么想法？

闵文俊：AI 场景中一个显著的特点是非结构化数据的急剧增加，所以我们需要支持跨数据类型的管理。常见的设计方法是通过统一的元数据目录，将多模态数据纳入 Lakehouse 的元数据管理体系中。具体来说，通常我们通过在 Lakehouse 中建立表模型，将多模态数据的一部分进行结构化存储，同时对于非结构化数据，我们仍然将其存储在对象存储中，并通过路径指向这些数据，从而将相关的元数据进行管理。

随着 AI 与 Lakehouse 架构的紧密结合，Python 作为 AI 生态中最通用的编程语言，其接口在整个 AI 生态中起到了至关重要的作用。因此另一个挑战是，Lakehouse 架构需要提供一套高性能的 Python 读写接口，以供 AI 框架使用。在不损失原始读写性能的情况下，这对 Lakehouse 架构提出了更高的要求。当前业界常见的做法是，使用原生语言（如 C++ 或 Rust）实现底层功能，并在其上封装 Python 接口，以调用这些底层库。这一做法背后需要一个稳定的内核支持，也就是我们之前提到的标准化。

此外，随着多模态数据的不断增长，相比于传统的结构化数据，非结构化数据在 Lakehouse 中存储时通常使用 Parquet 格式。然而，Parquet 格式更多适用于大规模扫描场景，对于 AI 场景中的高效检查和更新操作并不理想。在 AI 场景下，可能需要一些新的文件格式来支持更高效的数据存储和处理。

罗宇侠： 首先，对于 AI 而言，非结构化数据的组织和检索至关重要。Lakehouse 架构需要更加高效地组织并快速检索非结构化数据，例如，Paimon 正在探索的 Object Table 功能，通过对文本或图像根据文件信息建立表，并在其上建立索引，使得可以快速地检索到数据，如快速定位到某个特定日期生成的图像文件，从而高效支持 AI 训练。

其次，AI 更加倾向于使用嵌入或向量化的格式，而目前的 Lakehouse 架构更多侧重于分析场景，AI 大模型的需求与当前架构的计算范式并不完全对齐, 传统的数据分析架构很难完全匹配 AI 场景下的需求。

目前 Lakehouse 架构通常处理的是分钟级的数据新鲜度，实时数据仍然是一个缺失。我认为解决方案之一可能是引入额外的实时存储组件，例如 Kafka。这需要有效地处理 Kafka 中的实时数据流，并将其传输到 Lakehouse 中。Confluent 提供的 TableFlow 可以将数据从 Kafka 流转到 Iceberg。我们团队提出的 Fluss 湖流一体也正是为了弥补这个缺失，自动将实时数据流转到数据湖中, 无缝融合进 LakeHouse 架构中。

伍翀： 总结一下，在 AI 场景中，AI 对数据系统提出了更高的性能和实时性要求。数据的实时性对于 AI 应用尤为重要，因为一个好的 AI agent 需要高质量、实时的数据来提升其决策准确性和价值。此外，数据查询性能也需要进一步优化，以满足 AI 应用的需求。同时，Python 语言在数据湖框架中的应用也在不断演进。各大数据湖框架最近推出了自己的 Python 库，并且一些新型的数据湖格式，如针对 AI 场景构建的 LanceDB，也在不断发展。

目前在 AI 场景下，哪些开源的开放格式处于领先地位，或者在这一领域做得比较积极？比如 Paimon 提出的 Python 库和 Object Table，是否有其他相关的看法？

闵文俊： 我认为 Paimon 的跟进相当及时。此外，Iceberg 在社区中的参与也非常活跃，它的 Iceberg C++、Rust 和 Python 接口都很丰富。

王云霏： 是的，特别是在国外，Iceberg 被广泛采用，并且在各个方面的跟进也非常及时。

伍翀： 回到实时性的问题，大家都提到，在 AI agent 做决策时，数据的实时性显得尤为关键。与传统的 BI 决策场景不同，AI 应用对数据的实时性要求更加严格，因为它们需要即时反馈以支持动态决策。

企业对数据分析实时化需求日益迫切，怎样在现有技术栈基础上，通过精准选型、合理配置与高效集成，实现 Lakehouse 架构与企业业务流程的无缝融合，从而保障实时数据分析的低延迟、高并发与高可靠性？

闵文俊： 从企业的角度来看，若要引入一套新的架构，背后一定有一个需要解决的关键痛点。无论是当前架构中的时效性问题，例如基于 Hive 的 T+1 时效无法满足需求，还是存储成本问题，例如 Hive 场景下每天全量增量处理带来的高存储成本，这些问题都可能推动企业引入新的架构。此外，企业可能还面临如何高效更新湖仓层、实现流批统一存储等挑战。

我认为，在做出新的架构选型时，企业首先应从当前面临的实际业务痛点出发，明确解决这些痛点的需求，之后另一个考量点是 Lakehouse 架构的生态成熟度。具体来说，生态成熟度包括以下几个方面：从数据摄入的角度来看，是否支持丰富的数据导入插件，尤其是如 CDC（Change Data Capture）等技术？从数据开发的角度，是否支持主流的计算引擎？在进行 OLAP 分析时，下游工具如支持程度如何？这些因素都会影响企业在引入实时 Lakehouse 架构时的选型决策。

在确定选型之后，还需考虑如何让新的 Lakehouse 架构与现有的企业生态兼容。正如我们所称的数据湖仓，它不仅仅是数据湖，还需要兼容历史数据仓库的架构。引入实时 Lakehouse 架构时，需要考虑如何在保持现有生态兼容的情况下，逐步进行架构的迭代与升级。

伍翀： 现在业界有没有什么比较成熟、典型的搭建实时数仓的架构？并且这个架构当前还会遇到什么样的问题吗？

闵文俊： 我们目前的实践基于 Paimon 架构，作为数据湖仓的底层架构，Paimon 提供了 HDFS 作为数据存储基础。Paimon 的一个显著特点是其时效性有保障，并且基于 LSM 结构，在主键表的高效更新场景中，表现出非常好的性能。同时，Paimon 针对流式场景提供了诸如 Changelog Producer 的能力，使得在企业开发数据管道时，能够以增量方式处理数据流，这对于流式开发场景非常友好。对于离线场景，Paimon 同样提供了良好的性能，包括列式存储、数据聚类、Z-Order 排序、基于数据过滤的下推优化等功能。此外，它与 Spark 引擎的集成优化也进一步提升了系统的性能。

目前业界也有许多优秀的选型，如 StarRocks 在社区中的优化，以及 Trino 等技术的集成。就我们刚才讨论的考虑因素，如时效性更新需求、流批存储统一性以及与市面查询引擎的兼容性，Paimon 在这些方面的表现都相当出色。

伍翀： 我想了解下 Paimon 目前在字节跳动的实时湖仓落地情况。通常情况下，这些数据的新鲜度可以达到什么水平？另外，我不清楚你们内部使用的是哪种查询引擎，查询延迟能达到什么程度？

闵文俊： 通常来说，Paimon 的数据新鲜度大约在分钟级别，因为它受到数据提交时效性的限制。最终数据会提交到 HDFS 上，因此从纯粹的 Change Log 角度来看，目前尚无法实现秒级的新鲜度。不过，Paimon 也支持像 Log System 这样的方案。

在我们的内部，Log System 方案在高时效场景中得到了广泛应用。所以，可以理解为大多数场景下的数据新鲜度为分钟级别，而在一些需要秒级时效的场景中，我们会通过 Log System 来满足这一需求。至于查询引擎，在 TP-CDS 等业务场景中，查询时可以通过添加本地缓存等优化手段来提升查询性能。此外，查询引擎的优化目标之一是尽可能减少 Merge-On-Read，最终能将查询时效接近内表查询的速度。

罗宇侠： 如果我来做选型，我会从几个部分来考虑。首先是存储格式的选择，我会将它分为两部分：分钟级别延迟的数据和秒级延迟的数据。

对于分钟级别的数据，主要选择四大湖格式：Iceberg、Paimon、Hudi 和 Delta。这些都是成熟的数据湖格式。如果对数据的更新能力有较高要求，可能会选择 Paimon 或 Hudi，因为它们对 upsert（增量更新）的支持较好，更适合直接从业务系统的 binlog 中抽取数据并写入数据湖。在这方面，我可能会偏爱 Paimon，因为它对 Flink 的支持最为完善。

对于秒级延迟的数据，可能会选择 Kafka 等流式存储解决方案，或者使用最近开源的 Fluss，这些工具可以提供秒级新鲜度的数据处理能力。但需要注意的是，这类流式工具通常不擅长做数据分析，最终还是需要将数据流转到数据湖中，来进行进一步的数据分析处理。

接下来，我会考虑数据分析的方式。对于实时数据处理，我会选择 Flink，可以满足秒级延迟的数据处理。对于批处理数据我会选择 Spark，估计也没什么争议。对于报表和 BI 分析，如果需要非常高效的实时查询，我会选择成熟的 OLAP 引擎，如 StarRocks、Trino 等，这些引擎在处理实时查询和高效数据分析方面表现出色。

最后，我还会考虑底层数据的分层存储。在 Lakehouse 架构中，虽然存储成本较低，但我希望能在低成本的存储下提供更快的查询速度。比如，将低频访问的数据存放到 OSS（对象存储服务）或 HDFS（分布式存储系统）上，而对高频查询的数据，则可以使用内存或 SSD 进行缓存，以提供低延迟的访问。开源社区中已经有成熟的解决方案，如 Alluxio，它能够自动地进行多层级存储缓存。

王云霏：我想补充一下在分析引擎选型方面的一些参考。首先，由于我们需要进行实时查询，查询引擎的高性能计算能力是必须的，特别是在 OLAP 分析方面，性能是关键要素。在此基础上，引擎需要能够利用缓存来进一步提高性能，同时降低成本。因为数据的远程访问，特别是从对象存储进行访问时，会带来一定的成本开销，而缓存能够有效减少这些开销。

其次，引擎如果能够支持预计算或增量计算，将能显著提升计算效率和资源使用效率。然后如果引擎能够脱离传统的 OLAP 范畴，支持数据湖上的数据维护工作，这将对运维和整体性能的提升有很大帮助。具体来说，我们希望这些优化能够是“开箱即用”的，最好是系统能够根据用户的使用模式自动进行优化，从而选择出高效的优化策略。

伍翀： 现在业界内像 Iceberg、Paimon 或 Delta 等存储格式，在提升 Lakehouse 性能方面有什么最新的进展可以分享吗？

王云霏： 首先，为了提升 Lakehouse 的性能，数据缓存是一个关键部分。无论是基于第三方缓存库，还是像 StarRocks 将缓存功能集成到自身系统中，大家都在积极进行这方面的工作。因为如果数据仅从对象存储或 HDFS 中提取，往往无法满足 OLAP 实时查询的要求。

另外，关于预计算，像 Iceberg 已经支持物化视图（MV），它能够将数据以 MV 形式存储，并感知 MV 的新鲜度。在查询时，如果能够命中 MV，之前的预计算结果将直接使用，从而大大提升计算效率和实时性。StarRocks 也支持类似的功能，除了支持 Iceberg MV 外，还提供了一种内表格式的 MV 存储方式，可以在查询时自动改写 SQL，使得查询能够直接命中内表，从而提升查询性能，性能提升幅度可达到 10 倍以上。

尽管每个引擎可能擅长于不同的场景，它们都在拓展和增强自己的功能，许多引擎正在朝着“一个引擎满足所有需求”的目标迈进，以最终的目标是让用户的使用体验更加流畅和高效。

闵文俊： 正如刚才提到的，在 Lakehouse 架构中，读取远程湖仓表时，主要的瓶颈通常在于扫描性能。因此，湖仓的一项重要特性就是支持 Deletion Vector。在 Paimon 中支持 Deletion Vector 后，带来了多方面的好处。首先，避免了 Merge-On-Read 的需求，进而减少了对传统读取方式的依赖，这样整体性能得到了显著提升。

另外，避免 MOR 读取后，整个读取的并行度得以提高。因为在文件合并的过程中，如果数据有交叉，就会导致并行读取受限，而 Deletion Vector 的优化可以解决这个问题，显著提升读取并行度。这一优化主要体现在湖仓表的层面，进而帮助上层的 OLAP 引擎提升扫描性能。

此外，在 Paimon 中，不同的湖表数据本身有一定的分布特征。例如，桶表（bucket table）已经按照用户指定的字段进行了分桶。如果这种分桶数据能够报告给计算引擎，像 Spark 的桶连接（bucket join）或是适配引擎中的分区去除（partition remove）优化规则，就能够在识别到特定分区条件后，移除一些不必要的 shuffle 操作。在 OLAP 计算中，shuffle 是一个非常重量级的操作，通过减少 shuffle 的需求，可以极大地提升性能。因此，这些优化不仅针对湖仓表本身，也涉及 OLAP 引擎的操作，从而能在整体架构中获得更大的性能提升。

罗宇侠： 我想补充一下关于增量计算的部分。我了解到，像 Flink 也在提出 Materialized Table 的概念，基于 Materialized Table 进行增量计算。传统的流计算通常是常驻进程，而增量计算则通过启动批处理任务来计算 Delta 数据，相比全量计算，它所需要处理的数据量更小，因此能够大大节省资源。

3 Lakehouse 在云原生、多云与开源生态中的发展

伍翀：Lakehouse 架构如何与云原生环境深度融合，借助云的弹性、可扩展性与托管服务优势，实现架构的轻量化部署与高效运维？在多云、混合云场景下，又面临哪些新的挑战与机遇，该如何应对？

罗宇侠： 我认为 Lakehouse 架构非常适合这种云原生环境，主要因为它的存储和计算分离的设计。在存储方面，云环境提供了可靠、按需扩展的存储服务，尤其是对象存储。如果你自己维护存储集群，可能需要关注数据冗余和扩容问题，但在云环境中，存储几乎是免运维的，并且提供按量计费服务，用户无需担心扩容或缩容的问题。

在计算方面，云环境也提供了无限扩展的计算池，Lakehouse 架构的存算分离特点使得计算节点的增加和减少非常灵活，能够轻松适应计算资源的变化。许多云厂商还提供了按量计费的计算引擎，用户无需关心计算资源是否充足，也不需要手动调整资源的分配，确保高峰期和低峰期的计算需求得到满足。

多云部署的主要优势是避免供应商锁定，从而可以选择性价比最高的云服务。然而，核心挑战在于异构环境的兼容性问题。不同云厂商提供的 API 差异较大，因此即便你在一个云平台上部署，也可能需要适配另一个云厂商的 API。应对这个挑战的一个有效方法是采用开源技术，因为基本上不同云厂商都会兼容开源 API。

王云霏： 在云环境下，弹性是一个非常重要的考虑因素。在弹性环境下，如何确保系统的高效运作是一个挑战。比如，在缓存系统中，弹性扩缩容可能带来较大的挑战。特别是在发生缓存未命中（cache miss）时，查询延迟可能会显著增加，从而影响整体性能。

如果用户只需要一个引擎，那么它的部署和运维就会变得非常简单。目前，像 Spark、Flink 和 StarRocks 等引擎各有擅长的领域。例如，StarRocks 可能需要加强批处理能力和实时计算能力，同时保持其在 OLAP 方面的优势。同时，所有引擎也在尽量减少用户需要进行的运维和优化操作。理想情况下，引擎应该越自治越好，好的功能开箱即用。

闵文俊： 回顾数据湖诞生时，面临的许多问题与云环境密切相关。在云环境中，数据湖的构建通常依赖对象存储作为存储系统。对象存储的优势在于其弹性和成本效益，相比传统的 HDFS，弹性存储更加适应云环境，并且成本更低。但对象存储和传统文件系统存储之间有显著差异，需要在数据湖的设计中解决这些问题。

传统 Hive 数据仓库在进行分区级计算时，通常通过列出分区目录来获取数据，而这种列出操作在对象存储中非常昂贵。与此不同，Lakehouse 架构通过元数据（如 Manifest 文件）来记录每个分区的数据文件，因此能够直接通过元数据访问文件列表，避免了昂贵的目录列出操作，从而大大减少了扫描和计划阶段的时间消耗。

另一个问题是，对象存储中的小 IO 代价非常高。当进行过滤下推（filter pushdown）时，计算引擎通常会根据文件的 footer 中的 min/max 索引来过滤数据。在传统 Hive 等数据仓库中，这通常意味着每次都需要打开每个文件来获取 footer，从而增加了 IO 开销。尤其是在文件数量非常多时，文件打开操作的开销可能会超过扫描整个文件的数据处理开销。为了降低小 IO 代价，数据湖的设计将每个文件的 Manifest 和统计信息记录在 Manifest 文件中，通过这些元数据进行过滤。

在云环境中使用对象存储时，一些云存储服务并未提供非原子性的重命名 API，这会带来一定的问题。为了解决这个问题，通常需要借助分布式锁来确保数据的完整性。虽然存算分离架构带来了更高的资源使用效率和更强的弹性（因为存储和计算可以独立扩展），但它也带来了远程访问扫描的问题，通常的做法是通过本地缓存或远程分布式缓存来缓解。

关于多云部署，跨云之间的网络带宽限制是一个显著的挑战。如果需要在不同云平台之间进行数据传输，网络带宽的限制会影响整体性能和吞吐量，成为业务的瓶颈。业界的一些解决方案通过使用近端缓存来减少跨云带宽限制带来的影响，降低网络带宽对性能的负面影响。

伍翀：Lakehouse 架构凭借其灵活性、高性能和开放性，正成为企业数据管理的未来方向。当前，Lakehouse 架构在开源生态建设方面进展如何？有哪些主流的开源项目与工具推动其发展？如何推动 Lakehouse 架构的开放性和兼容性？

王云霏： 首先是表格式存储。在海外，云对象存储已经相当成熟，国内则可能更多采用如 hdfs 文件系统或其他 OSS（对象存储服务）解决方案。在表格式存储方面，当前比较活跃的项目包括 Iceberg、Hudi 和 Delta Lake，这些项目各自占据着不同的市场领域。

每个引擎都有自己的特点和擅长的领域，同时它们也在不断扩展自己的功能。目前国际领先的数据分析厂商，如 Snowflake 和 Databricks，已开源了自己的元数据管理项目。此外，国内也有像 Gravitino 等发展较好的项目。在元数据管理方面，目前可以说是百花齐放，在统一标准的前体下，提供针对不同场景的强大功能，从而为用户提供更高的性价比。

罗宇侠： 我觉得 Iceberg 就是生态本身，很多项目都在与 Iceberg 兼容。比如说，Paimon,Delta Lake 这种湖格式甚至都兼容 Iceberg。还有一个项目叫做 Apache XTable，它实际上提供了多种湖格式的互操作性，用户可以通过 XTable 无缝对接那些支持 Iceberg 的计算引擎。

另外，像 Lakehouse 的管理系统也有很多支持。比如 Amoro 的项目，也是 Apache 社区的一个项目，它基于开放湖格式，帮助你构建 Lakehouse 管理系统，这样就能方便地管理 Lakehouse 架构。

至于企业的选型分析和建议，我个人的看法是，最好选择一些比较主流和成熟的组件。理想的做法是，首先基于一些稳定的技术栈构建架构，例如 Iceberg 加 Spark，再慢慢引入其他新的引擎。可以类比为搭积木，先从最成熟的组件开始，逐步引入新技术，最终搭建出完整的 Lakehouse 技术栈。

闵文俊： 从整体 Lakehouse 架构的角度来看，越接近底层的技术，其生态的成熟度和行业标准化程度就越高。例如，HDFS 作为存储层已经发展多年，基本上已经成为企业级分布式文件存储的标准。而在它之上，我们可能有多个数据湖格式，这些格式各自提供了不同的功能，但在元数据层的标准化上，至今还没有统一的实时标准。

在这个市场中，我认为像 Iceberg 这样的格式在国外社区得到了广泛的关注和推进。相比之下，国内社区，尤其是像 Paimon 这样的项目，往往更加注重务实性，致力于解决实际业务场景中的问题，并且在设计上非常注重可操作性和实用性。

对于 Lakehouse 架构本身的标准化和开放性，市场的需求和选择会逐渐推选出一种事实上的标准。例如，HDFS、流计算和批处理计算框架如 Spark 和 Flink 等技术，都是经过市场检验并逐渐成熟的。对于湖格式来说，虽然当前大家逐渐向 Iceberg 的格式和元数据靠拢，但这并不意味着其他厂商没有机会。

伍翀： 目前，各个开源项目在每个层级的发展都非常活跃。比如在开放数据格式（open data format）层面，海外的 Iceberg 目前是一个比较标准的格式，而在国内，Paimon 使用得较为广泛。在元数据层面，现在呈现出百花齐放的局面，多个项目各有特色。对于实时数据层，很多流存储系统也在积极对接并支持数据湖架构。而在查询引擎层，也有许多不同的引擎各自拥有优势，能够对接各种数据湖。

对于用户的选型来说，最重要的因素之一是选择具有活跃社区的项目。社区活跃意味着有丰富的资料可以帮助解决问题，同时也意味着该项目在持续发展和演进。最终，最关键的还是要根据自身的需求和问题来选择最适合自己的技术栈。

观众：Lakehouse 去 Hadoop 会是一个趋势吗？

罗宇侠：Lakehouse 架构提出之初其实就假定是在对象存储上进行构建。湖格式天然是为了更好地适应对象存储的特性而设计的. 以 Iceberg 为例，它的表格式设计实际上也是更加适配对象存储的特性。比如对象存储不擅长对目录进行 list 操作，对于这一点,Iceberg 通过使用 Manifest 文件来记录文件列表，从而避免了目录 list 操作。

我认为对象存储可能是未来的一个大趋势，但与此同时，HDFS 仍然会长期存在，特别是对于一些不愿将数据存放在云端的企业，依然会选择 HDFS。而且对象存储虽然便宜, 但其实性能也是一个大问题, HDFS 性能是要比对象存储更高的, 如果考虑性能的话, 可能还是绕不过 HDFS。

闵文俊： 我个人认为这并不是一个必然的趋势。首先，从云环境的角度来看，大多数存储选型更倾向于使用对象存储，主要是因为对象存储在成本方面具有优势。然而，在企业内部的实际情况可能会有所不同。例如，如果从企业内部的角度来看，使用 HDFS 作为存储未必比对象存储更昂贵。

HDFS 经过多年发展，已经积累了大量技术沉淀，并且在成本控制和集群治理方面都有很好的优化。因此，企业内使用 HDFS 存储时，成本并未必比对象存储更高。若在成本和性能上没有明显的优势，那么企业可能不一定会选择使用对象存储来替代 HDFS。

另外，关于 Lakehouse 是否会取代其他存储系统，我认为背后有一个前提：Lakehouse 架构本身依赖于底层存储系统的支持。正如之前提到的，HDFS 作为底层存储依然是一个有效的选择，尤其是在成本和性能都得到优化的情况下。因此，即使是 Lakehouse 架构，底层的 HDFS 并不会因为架构的变化而被完全替代。

王云霏： 我们确实发现，海外市场对于对象存储取代 HDFS 的趋势较国内更为明显，许多国外的厂商已经逐步采用了云对象存储的方式。对象存储的优点在于其标准接口比 HDFS 更加统一。我们发现，在国内，许多厂商的 HDFS 系统经过了特殊的优化或定制，这使得计算引擎在对接时遇到了一些困难。而在海外，S3 基本已经成为事实标准，接口非常统一，这使得对接工作变得更加简单。

然而，在国内，讨论 HDFS 是否被替代可能还为时过早。正如刚才提到的，许多企业仍然能够控制自己的 HDFS 系统，并在此基础上进行定制优化。在安全性和成本方面，企业甚至可以通过这种方式使成本低于云对象存储。因此，HDFS 的存在确实有其必要性和优势。