数仓还是湖仓?专家圆桌深度解析
![数仓还是湖仓?专家圆桌深度解析](https://static001.geekbang.org/infoq/09/09ef752c048e8219f672c81a02feb4ff.png)
近期,Databricks 以超过 10 亿美元的价格收购了 Tabular——Apache Iceberg 的商业支持公司,这一动作加剧了 Snowflake 和 Databricks 在开放湖仓标准发展上的竞争。这起收购也突显了数据湖表格式在现代数据分析架构中的关键地位。
在上月的 StarRocks Meetup 活动中,四位湖仓技术专家代表 Apache Iceberg、Apache Hudi、Apache Paimon 和 StarRocks 社区分享了他们的洞见。他们讨论了数据仓库、数据湖和湖仓技术的选择,并解答了如何选择合适湖仓表格式的问题。以下是这场圆桌讨论的专家介绍和精简摘要:
圆桌主持人:
StarRocks 代表:李昂——StarRocks Committer
圆桌嘉宾介绍:
Apache Iceberg 代表:周劲松——Apache Amoro (incubating) PPMC 成员/腾讯云专家工程师(前网易平台开发专家)
Apache Hudi 代表:徐昱——Apache Hudi & StarRocks Contributor/vivo 湖仓组件研发负责人
Apache Paimon 代表:王日宇——StarRocks Committer/阿里云高级研发工程师
话题一:数仓 vs. 数据湖 vs. 湖仓
Q1:湖仓是不是 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 的升级版。
湖仓技术的需求主要来源于:
业务从 T+1 的离线更新转变为对实时性要求越来越高,导致 Hive 在性能上出现瓶颈。
业务发展需要频繁变更 Hive 表结构,Hive 在这方面存在局限。
多版本并发控制(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 所不具备的实时性和灵活性,还适应了云计算和大数据时代的需求。三位专家们普遍认为,无论是在私有化部署还是云环境中,湖仓技术都将在数据处理和分析领域发挥重要作用。
Q2:我们需要对数据进行复杂的分析和快速查询,且数据的准确性和一致性对我们至关重要,我们应该怎么选型?
王日宇: 如果目标是数据的正确性,传统 Hadoop 架构已经足够满足需求,并在许多企业和场景中得到广泛应用。 湖仓技术主要针对实时性和数据更新性的需求,如果需要实时数据入湖和查询,可以考虑使用湖格式技术。选择哪种技术应根据具体需求而定。如果主要是进行 ETL 和确保数据准确性,传统 Hadoop 依然非常有效。
李昂:说到数据仓库的话,这是我们 StarRocks 的强项。几年前,StarRocks 在公开的标准测试集中进行复杂分析的性能已经达到世界领先水平。如果需要了解更多相关信息,可以访问我们的官方网站或查阅相关技术文档。
Q3:我们的 数据治理 和安全性要求很高,需要确保数据的质量和合规性,我们应该考虑哪种解决方案?
周劲松: 数据质量和安全性是数据使用中较为高级的特性。在许多公司中,这些特性并不是由湖仓或数仓产品直接提供,而是由数据中台等产品来覆盖。数据中台会将数据建模和质量控制抽象成一系列服务。
我认为数据质量本质上需要用户通过配置任务来处理数据,以发现潜在问题。不同公司的需求各异,数仓或湖仓产品可能提供基础能力,但更深入的功能可能需要企业或用户自行开发定制化任务。
数据质量更倾向于由上层产品来覆盖,一些企业级软件如 Databricks 可能内建了数据质量服务或模块。数据安全则是数仓和湖仓都应提供的基础功能。 数据质量服务通常既可以应用于数仓也可以应用于湖仓,因此它不应成为选择数仓或湖仓的主要考量因素。选择时应更多地从上层数据服务的角度考虑。
Q4:如果我们的预算有限,需要一种成本效益高的数据管理解决方案,应该如何选择?
徐昱: 在生产实践中,我们经常需要针对一些关键任务进行优化。Hive 在某些场景下具有不可替代性,比如数据写入后不需要更新的情况。在这种情况下,迁移到湖仓可能不会带来显著的性能提升或成本效益。
但如果我们的业务场景中存在大量更新需求,迁移到湖仓并使用其技术可以提高效率并降低资源消耗。 节省下来的资源可以用于其他任务。 对于需要架构改造的流批融合场景,我们可以优先考虑湖仓实践。 湖仓是一项新技术,我们需要通过具体的业务场景验证来确保其能带来正向收益,并据此决定推广规模。
李昂: 在预算有限的情况下,我们可以采用成本较低的数据湖存储方式,配合数仓进行高性能查询,湖仓是一个不错的选择。 StarRocks 自 3.0 版本以来,主打湖仓融合,除了可以使用成本较低的 对象存储 外,其性能也是主流数据库的 10 倍左右,是实现降本增效的理想选择。
话题二:表格式终极选择:Hudi vs. Iceberg vs. Paimon
Q1:刚才三位专家分别介绍了 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 则因其 中立性 和灵活性,适合需要自定义数据湖表格式的场景。每种格式的选择都应基于实际业务需求和场景特性。
Q2:这三种数据湖表格式都采用了 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 提供的接口能满足大部分用户需求,但对于深度使用的用户而言,这些可能不太足够。
以上就是我们湖仓技术圆桌讨论的主要内容,感谢大家的阅读。如果你有湖仓相关的用户案例、使用经验和调优思理愿意分享给大家,欢迎联系我们投稿(https://wx.focussend.com/weComLink/mobileQrCodeLink/33412/515d5)。优质内容我们将优先发布在公众号以及 StarRocks 中文社区等渠道!
相关视频推荐:
基于 Apache Amoro(incubating) 与 Apache Iceberg 的湖仓一体实践
版权声明: 本文为 InfoQ 作者【StarRocks】的原创文章。
原文链接:【http://xie.infoq.cn/article/794972d512b84bb92d5a49481】。文章转载请联系作者。
评论