数仓还是湖仓？专家圆桌深度解析

湖仓是不是 Hadoop 的升级版？在数据湖建设的理念上，与 Hadoop 有哪些异同点？

关于这个问题我们在 vivo 内部也经常讨论，到底 Hadoop 与 Hudi 是否能相提并论。Hudi，意为"Hadoop Upserts Deletes and Incrementals"，代表了一种新的计算与存储解决方案。HDFS 作为 Hadoop 的三大支柱之一，无论是 Hudi、Iceberg 或是 Paimon，在数据湖技术如 Hudi、Iceberg、Paimon 中并非必须，它们可以利用对象存储或本地存储。所以可以说 Hudi 和其他湖格式引入了更高效的更新机制和新的文件格式，帮助用户提升性能，解决痛点。我个人认为 Hudi 更类似于一种方法论的提升，借助于 Hadoop 的生态圈来将这套方案进行落地。在 Hadoop 的计算与存储上基础上，得到一个更大的能力升华。

我倾向于结合业务需求来探讨技术发展。湖仓技术的出现，是为了解决 Hive 在某些方面难以应对的问题。Hadoop 是一个庞大的系统，包括 Hive、YARN 等多个组件。如果单纯从我们经常用的数仓的 Hive 的这个构建来说，我觉得湖仓应该算是 Hadoop 的升级版。

1. 业务从 T+1 的离线更新转变为对实时性要求越来越高，导致 Hive 在性能上出现瓶颈。

2. 业务发展需要频繁变更 Hive 表结构，Hive 在这方面存在局限。

3. 多版本并发控制（MVCC）带来的 ACID 的需求 Hive 无法满足。

湖仓技术是在 Hive 或 Hadoop 体系的巨人肩膀上发展起来的新技术，它继承并改进了 Hive table format 的不足，引入了更多特性。目前，数据湖格式的四大技术——Iceberg、Hudi、Delta Lake、Paimon——虽然统称为湖仓，但各有特点，都是在不同背景下发展起来的。

我跟日宇老师的看法雷同，并想补充一些观点。数据湖的核心功能是存储大量数据，从这个角度来看，HDFS 和 OSS 本身就是数据湖产品。当我们讨论湖仓时，会提到 Iceberg、Paimon 等技术，它们是数据湖生态的一部分。

我理解湖仓是面向结构化数据的，可以看作是下一代的 Hive 表。Iceberg 的定位不仅是下一代 Hive 表，还有云原生。随着云计算的普及，Hadoop 可能不再适合云环境，因为云存储通常使用 S3，而且可能不再使用 Hive Metastore 或 Hive Server，而是采用与云结合更好的引擎，如 Spark、Flink、StarRocks。

我认为下一代的 Hadoop 可能是云上的湖仓一体架构。如果是私有化部署，可能仍会使用 HDFS 和 Hive Metastore，但不再使用 Hive Server，而是使用 Spark、Flink、StarRocks 等。同时，Hadoop 生态中的一些组件，如 Ranger，可能仍会被继续使用。

总结以上三位专家的观点，湖仓技术是对 Hadoop 的扩展和深化，它不仅提供了 Hadoop 所不具备的实时性和灵活性，还适应了云计算和大数据时代的需求。三位专家们普遍认为，无论是在私有化部署还是云环境中，湖仓技术都将在数据处理和分析领域发挥重要作用。

我们需要对数据进行复杂的分析和快速查询，且数据的准确性和一致性对我们至关重要，我们应该怎么选型？

如果目标是数据的正确性，传统 Hadoop 架构已经足够满足需求，并在许多企业和场景中得到广泛应用。湖仓技术主要针对实时性和数据更新性的需求，如果需要实时数据入湖和查询，可以考虑使用湖格式技术。选择哪种技术应根据具体需求而定。如果主要是进行 ETL 和确保数据准确性，传统 Hadoop 依然非常有效。

说到数据仓库的话，这是 StarRocks 的强项。几年前，StarRocks 在公开的标准测试集中进行复杂分析的性能已经达到世界领先水平。如果需要了解更多相关信息，可以访问 StarRocks 社区官方网站或查阅相关技术文档。

我们的数据治理和安全性要求很高，需要确保数据的质量和合规性，我们应该考虑哪种解决方案？

数据质量和安全性是数据使用中较为高级的特性。在许多公司中，这些特性并不是由湖仓或数仓产品直接提供，而是由数据中台等产品来覆盖。数据中台会将数据建模和质量控制抽象成一系列服务。

我认为数据质量本质上需要用户通过配置任务来处理数据，以发现潜在问题。不同公司的需求各异，数仓或湖仓产品可能提供基础能力，但更深入的功能可能需要企业或用户自行开发定制化任务。

数据质量更倾向于由上层产品来覆盖，一些企业级软件如 Databricks 可能内建了数据质量服务或模块。数据安全则是数仓和湖仓都应提供的基础功能。数据质量服务通常既可以应用于数仓也可以应用于湖仓，因此它不应成为选择数仓或湖仓的主要考量因素。选择时应更多地从上层数据服务的角度考虑。

如果我们的预算有限，需要一种成本效益高的数据管理解决方案，应该如何选择？

在生产实践中，我们经常需要针对一些关键任务进行优化。Hive 在某些场景下具有不可替代性，比如数据写入后不需要更新的情况。在这种情况下，迁移到湖仓可能不会带来显著的性能提升或成本效益。

但如果我们的业务场景中存在大量更新需求，迁移到湖仓并使用其技术可以提高效率并降低资源消耗。节省下来的资源可以用于其他任务。对于需要架构改造的流批融合场景，我们可以优先考虑湖仓实践。湖仓是一项新技术，我们需要通过具体的业务场景验证来确保其能带来正向收益，并据此决定推广规模。

在预算有限的情况下，我们可以采用成本较低的数据湖存储方式，配合数仓进行高性能查询，湖仓是一个不错的选择。StarRocks 自 3.0 版本以来，主打湖仓融合，除了可以使用成本较低的对象存储外，其性能也是主流数据库的 10 倍左右，是实现降本增效的理想选择。

刚才三位专家分别介绍了 Iceberg、Hudi 和 Paimon 这三种数据湖表格式。请问各位专家，您认为在哪些场景下，您介绍的表格式是最佳选择？为什么它适合这些场景？是哪些特性使其成为这些场景下的最佳实践？

选择技术组件时，没有所谓的万能或最佳选择，关键在于找到最适合特定场景的组件。每个组件都有其独特的优势。例如，Hudi 在小文件管理方面表现出色，特别是在面对高流量写入时，能够高效地组织数据并保证写入效率。之后，Hudi 还可以通过合并方案对数据进行优化重组，这在我们的应用场景中取得了良好的效果。

当考虑数据湖格式的选型时，Paimon 的优势在于其实时更新和写入能力，特别是与 Flink 生态的紧密结合。由于 Paimon 是在 Flink Table Store 中孵化的，它自然拥有许多优势。Flink 是众所周知的实时处理引擎，因此 Paimon 作为 Flink 原生表格格式，在实时更新和数据入湖的效率上表现突出。

Hudi 也以实时 upsert 为特色，我想知道在这个场景下使用 Hudi 会怎么样？想请日宇老师分享一些个人看法。

Hudi 和 Paimon 在某些方面有相似之处，但也存在显著差异。Hudi 作为一个较早出现的湖格式，有着丰富的发展历程；Paimon 作为较新加入的成员，今年刚从 Apache 基金会毕业。Paimon 在设计时吸取了包括 Iceberg 在内的其他湖格式的优点，并结合了实时入湖的能力。Paimon 不仅在实时更新方面表现出色，还在文件合并方面采用了 LSM-Tree 的思想，这是在 Hudi 和 Iceberg 的基础上进行的创新。最终选择哪种格式，应根据具体的业务需求、测试结果和场景来决定。实际的性能比较不应仅停留在表面，而应通过线上业务的实际测试来得出结论。

感谢日宇老师的深入分析。这个问题确实容易引发争议。老师的意思似乎是，虽然 Paimon 是在 Hudi 等巨人的肩膀上上发展起来的，但是 Hudi 这个巨人它也并没有停止前进的脚步，也在不断的更新迭代。接下来，我们请周劲松老师谈谈 Iceberg 在选型方面的考虑。

我的出发点与日宇和徐昱老师有所不同，更多从用户角度考虑。之前我在网易的团队使用 Iceberg 时，我们没有厂商背景，选型相对灵活。当时 Paimon 尚未出现，Delta Lake 与 Spark 绑定太深，所以我们在 Hudi 和 Iceberg 之间进行了对比。虽然 Hudi 功能看似更全，但深入代码研究后，我们选择了 Iceberg。

Iceberg 的优势是它是一个相当中立的项目，不强绑定任何引擎，抽象设计做得很好，为用户留出空间进行自定义开发。相比之下，Hudi 像是面向特定需求设计的，与 Hadoop 绑定较深。Iceberg 的目标是替换 Hive，定位为一种表格格式，不解决具体需求，而是解决数据湖上表格式的需求。它的所有元数据变更都非常谨慎，不会为任何特定引擎妥协。

Iceberg 社区非常严格，会严格遵循自己的定位和方向，对于不符合社区方向的提案可能不会被接受。这使得一些公司或个人可能难以融入 Iceberg 社区，因为他们有明确的目标。虽然 Iceberg 在实时方面可能不如 Paimon，但它提供了接口，允许用户根据自己的需求进行定制化开发。从长远来看，我认为 Iceberg 将成为一个中立的、真正能替换 Hive 的表格式，其发展空间更大，因为它不与任何引擎绑定，可以按照自己的中立发展路线前进。

综上所述，Hudi 适合需要高效小文件管理和高写入流量的场景，Paimon 适合需要实时数据处理与 Flink 紧密结合的场景，而 Iceberg 则因其中立性和灵活性，适合需要自定义数据湖表格式的场景。每种格式的选择都应基于实际业务需求和场景特性。

这三种数据湖表格式都采用了 MVCC  进行版本控制并支持 Merge-on-Read。这种做法可能会引起数据和元数据的冗余或分布不均匀。用户为了优化查询性能，常常需要手动调整策略。请问在这三种表格式中，哪一种的维护成本较低，以及日常维护工作主要包括哪些内容？

在实际工作中，Hudi 的运维工作包括 compaction 和 clustering 的自动化处理，用户可以选择自动化或定期手动维护。这涉及到元数据归档，需要用户关注并配置清理策略，比如归档周期和数量。虽然大部分操作自动化，但在特殊情况下，如用户操作失误导致归档失败，可能需要手动整理元数据记录。

日常运维工作量取决于用户对表性能的要求。如果不是特别追求查询性能，可以延长归档周期或等待固定周期后进行合并。但如果用户需要即时性能，可能需要定时任务或在合并失败时人工介入，这也是时常会有的情况。

另外，生命周期管理可以通过自动化方式删除过期数据和同步冷备。但追求极致性能时，可能需要结合元数据的时间和类型进行物理删除，包括目录删除和合法性校验，这需要在脚本或程序中考虑。

维护成本不仅包括资源消耗和查询延时，还涉及易用性。用户选择湖仓格式时，关心的是维护资源投入及其带来的读写延迟。维护成本应综合考虑易用性和代价。易用性方面，各湖仓格式都致力于简化用户体验，如自动合并和手动定时合并功能。目前这些机制都相对容易使用。

Paimon 在维护成本上有其优势。例如，Hudi 的 Merge-on-Read 表在 compaction 时会消耗大量 CPU 和 I/O 资源。而 Paimon 利用其创新的 LSM Tree 数据组织方式，通过分层合并减少了资源消耗。大部分情况下，minor compaction 已足够，实现快速合并并使下游迅速可见数据。只有当数据累积到一定程度时，才会进行 full compaction。这种策略避免了频繁的 full compaction，从而降低了维护成本。这是 Paimon 相比其他格式的一个显著优势。

接下来由我作为 Iceberg 代表聊一下我对这个问题的看法。

首先，我们的用户在日常维护工作中，如果希望提升查询性能需要做哪些工作？这时元数据和数据的优化非常重要。用元数据来说，Iceberg 的 manifest 文件可能包含数万数据文件的列统计信息，但实际查询中很少用到所有列的统计信息进行 CBO 优化。因此，用户在写入数据时，可能只需要提取特定几列的统计信息，避免写入不必要的元数据，这样可以在读取 manifest 时显著提升性能。

其次，元数据的分布也会影响查询效率。Iceberg 的查询规划 data skipping 简单来讲分为两层：首先是根据 partition value 的 min/max 过滤 manifest list 中的 manifest，其次是根据非分区谓词进行过滤 data file。如果 manifest list 层面的分区值非常精确，那么将极大减少本次读取的 manifest 文件。如果用户没有进行适当的维护，可能将几个月的文件都存储在一个 默认 8MB 大小 的 manifest 中，这会导致即使是查询一天的数据，也需要读取整个8MB的 manifest，增加了查询成本。

此外，对于需要高性能查询的情况，用户可能会使用 Spark 等工具对数据进行重写，比如按照某一列进行排序，这样在查询时可以利用非分区列的谓词直接进行高效的数据过滤。

总的来说，Iceberg 需要手动维护的地方较多，我个人觉得可能是这三个表格式中最多的。用户需要深入了解其写入和查询原理，才能制定出有效的优化策略。虽然 Iceberg 提供的接口能满足大部分用户需求，但对于深度使用的用户而言，这些可能不太足够。