近期,Cloudera宣布将Apache Iceberg集成到其云生态系统中,Iceberg的优势得以融入正在转向公有云和采用湖仓等融合架构的企业之中。可以说,集成了Iceberg的Cloudera CDP将强有力地帮助企业构建新一代数据架构,赋予企业更多的前瞻性和附加优势。
Apache Iceberg是一种高性能的开放表格式。它诞生于云端,可扩展到PB级并且独立于底层存储层和引擎存储层。作为一种真正的开放表格式,Apache Iceberg符合Cloudera Data Platform(CDP)的愿景。
原因一:多功能分析助力实现数据集共享
Apache Iceberg实现了不同流式传输和处理引擎之间的无缝集成,同时保持了它们之间的数据完整性。多个引擎可以同时更改表,即便是部分写入也不会出现正确性问题,而且也不需要昂贵的读取锁定。因此,降低了使用不同的连接器、维护不善的API、以及采取其他临时解决方案处理数据集的必要性。
Iceberg采用开放、兼容所有引擎的设计,实现了数据集的共享。Cloudera扩展了对Hive和Impala的支持,实现了从大规模数据工程工作负载和流处理,到智能大数据分析平台(Fast BI)和查询以及机器学习的多功能分析数据架构愿景。
Iceberg的多功能还意味着Cloudera数据平台就此拥有了打破数据孤岛的集成端到端数据管道,并将分析整合成一个连贯的生命周期,在每一个阶段都可以提取商业价值。用户将能够借助所需工具并充分利用其对工作负载所作出的特定优化。例如Jupyter笔记本可以使用Spark或Python框架直接访问Iceberg表来建立预测模型,同时通过NiFi流获取新数据,而SQL分析师则可以利用数据可视化监控收入目标。而作为一个完全开源的项目,这意味着将来会有更多的引擎和工具得到支持。
原因二:开放文件格式提升数据存用灵活度
作为一种表格式,Iceberg 支持一些最常用的开源文件格式,比如Avro、Parquet 和 ORC。这些都是众所周知且发展成熟的大数据文件格式,它们不仅被开源社区所使用,同时也被嵌入到第三方工具中。开放格式的价值在于灵活性和可移植性。用户可以在不受底层存储束缚的情况下移动他们的工作负载。但到目前为止,这种格式仍有一个缺点——由于表模式和存储优化与引擎等紧密耦合,因此使用起来难免“束手束脚”。
而Iceberg是一个通过与开放文件格式一起使用来避免这种耦合的开放表格式。模式、分区等表信息作为元数据文件的一部分单独存储,使应用更容易与表和它们所选择的存储格式快速集成。由于查询不再依赖于表的物理布局,Iceberg表可以随着数据量的变化而逐渐实现分区方案的演进。
原因三:开源功能有效规避供应商“陷阱”
开源对于避免供应商“陷阱”至关重要,但许多供应商会在兜售开源工具时隐瞒他们自主开发的版本与开源社区之间的差距。这意味着当客户尝试去使用开源版本时,他们才会发现二者之间存在显著差异。如此说来,避开供应商陷阱实则困难重重。
而Apache Iceberg项目是一个充满活力的社区,它正迅速扩大对各种处理引擎的支持并不断增加新功能。为了使该社区及新的表格式获得持续成功,Cloudera为上游社区提供跨Spark、Hive和Impala的支持,意在促使Apache Iceberg被广泛采纳并可供有意构建新一代数据架构的企业所使用。该社区提供了许多功能改进及性能特性,例如向量化读取和Z-Order等,无论用户使用什么引擎或供应商来访问表,都将从中受益。在CDP中,这已经作为Impala MPP开源引擎对Z-Order提供的一部分支持。
如之前所述,在查询规划方面Iceberg依赖于元数据文件,这些文件包含了数据驻留的位置以及分区和模式如何分布在文件中。虽然这实现了模式的演变,但如果表格的变化过多,就会带来问题。为此社区创建了一个API来读取元数据文件,同时也在同步进行其他类似的优化。这种开放标准方法让用户可以在Iceberg上以CDP中的性能运行工作负载,且无需担心落入供应商“陷阱”中。
原因四:有效降低企业级应用学习和管理门槛
作为Cloudera企业平台的一部分,Iceberg的原生集成受益于企业级的共享数据体验(SDX)功能,例如数据沿袭、审计和安全等,而且无需重新设计或第三方工具集成,因此不会增加管理的复杂性,也不需要额外学习。CDP中的Apache Iceberg表被集成在SDX Metastore中用于表结构和访问验证,这意味着用户可以进行审计并创建细粒度的政策,实现即开即用。
原因五:Apache Iceberg开启全新使用场景
Apache Hive表实现了对数据仓储、数据工程和机器学习的集中访问,奠定了良好的性能基础。同时,它还支持开放的文件格式(ORC、AVRO、Parquet等),并通过ACID和事务支持帮助实现新的用例。但由于元数据的集中化并且抽象化主要基于文件,因此它在规模等方面不免面临挑战。
Iceberg克服了规模和性能方面的挑战,同时加入了一系列新的功能,能够解决不同行业和用例的挑战。例如:
- 变更数据捕获(CDC)
能够处理具有原子性和一致性的Delta表虽然早已普及,而且Hive ACID等现有的解决方案也能提供这种功能,但该功能对大多数提供DW和BI用例的数据处理管道来说至关重要。因此Iceberg从一开始就通过支持行级更新和删除来解决这个问题。它在不深入到细节的情况下可以使用多种不同的方法来实现这一点,例如写时拷贝(Copy-on-write)与读时合并(Merge-on-read)。但更重要的是,随着这些解决方案以及Iceberg开放标准格式的持续发展,我们将看到处理类似用例的更优表现。
- 金融监管
许多金融和受到高度监管的行业都希望能够回溯历史,甚至希望能够将表状态恢复到特定的时间点。Apache Iceberg的“快照”和“时间旅行”功能可以帮助分析和审计人员轻松回溯历史并使用简单的SQL来分析数据。
- 机器学习运维的可重复性
通过允许检索之前的表状态,Iceberg让机器学习工程师能够使用原始状态的数据重新训练模型,并执行将预测与历史数据相匹配的事后分析。通过这些存储的历史特征,可以对模型进行重新评估、找出不足之处并部署更新、更好的模型。
- 简化数据管理
大多数数据从业者需要耗费很多时间来应对数据管理的复杂性,为项目确定新的数据源并将新的属性加入到现有的数据模型中就是其中之一。以前,这可能会因为需要重新创建和重新加载表而导致开发周期过于漫长,尤其是在引入新的分区时。但有了Iceberg表及其元数据清单文件,就可以简化这些更新并且不产生额外的费用。
模式演变:表中的列可以就地改变(添加、删除、重命名、更新或重新排序)而不影响数据的可用性。所有变化都可以在元数据文件中被追踪,Iceberg 确保模式变化独立且没有副作用(比如错误的值)。
分区演变:可通过与模式演变相同的方式改变Iceberg表中的分区。在分区演变过程中,旧的数据保持不变,新的数据将按照新的分区规格写入。Iceberg 使用隐藏分区,通过分割规划自动修剪包含新旧分区规格中的匹配数据的文件。
细粒度的分区:以前,在查询规划期间所面临的主要瓶颈是元数据仓以及将分区加载到内存中,限制了用户使用小时等细粒度的分区方案以避免随着表规模的增长而导致性能不佳。Iceberg克服了这些可扩展性方面的挑战,通过同时避免元数据仓和内存瓶颈,使用户能够使用更细粒度、最适合应用需求的分区方案来实现更快的查询。
这意味着数据从业者可以将更多的时间用于创造业务价值和开发新的数据应用,减少处理数据管理的时间,即根据业务的速度实现数据演进,避免本末倒置。
- 轻松构建数据仓库
我们已经看到了数据仓库领域的很多趋势,其中最新的趋势就是湖仓——一种将数据仓库和数据湖相结合的融合架构。在企业中,加速此类融合架构的一个关键因素是存储与处理引擎的解耦。但这必须与从串流和实时分析到仓储和机器学习等多功能分析服务相结合,仅凭分析工作负载或将两者相结合还不够。因此CDP中的Iceberg不具有固定形态,它更多的是一种兼容一切引擎的开放式数据底层,可以在云端进行扩展。
这使得企业可以轻松构建“任何”数据仓库,而不必使用专门的存储格式来获得最佳性能,也不必在一个引擎或服务中进行专有优化。