Apache Iceberg 存储和 Pandas Analytics：第一部分
- Claude Paugh
- 5月7日
- 讀畢需時 6 分鐘
已更新：6月26日
我通常喜欢尝试新事物，技术也不例外。因此，我决定对 Apache Iceberg 的底层机制，特别是它的 Python 实现 PyIceberg 进行更深入的研究。
我特别关注了一些通常属于数据管理实践的关键项目，无论采用何种技术：
数据质量控制：我至少可以通过数据类型来验证模式，但最好是通过值检查来验证。
数据完整性：当数据跨数据结构链接时，是否可以防止重复、强制密钥并维持一定程度的参照完整性
数据访问：您是否可以通过行级访问来管理安全性，以及访问时间是否稳健，以便检索和加载合理，即对用户、服务和应用程序的平均期望
元数据管理：我是否可以拥有可以通过多个版本演变的模式，并可能为我提供回滚/撤消更改的能力。
如果您是 PyIceberg 的新手，它是 Apache Iceberg 的 Python 实现，无需 JVM。它是开源的，因此 PyIceberg 的 GitHub 仓库在这里，社区支持在这里。该项目最初是作为 Apache Spark 的扩展，后来扩展到 Flink 和 Hive。
Apache Arrow基金会
它的数据 I/O 机制基于Apache Arrow ，该项目旨在定义表格数据及其在系统间交换的规范，尤其是在内存分析领域。Arrow 最初是用 C 语言编写的，后来移植到了其他几种语言（请参阅上面主页链接中的“实现”）。
在主页链接的底部，您将看到指向C++ 、 Java 、 Python和R的更多参考手册链接，帮助您快速入门这些语言的实现。此外，您还可以移植到 C#、Rust、Ruby 和 MATLAB 等热门语言和工具包。
如果您当前或计划使用 Apache Parquet 或 ORC 格式，您可能会发现来自云供应商或查询引擎的库，将 Arrow 库作为每个提供商特定扩展的起始基础进行来源和包装。
AI/ML扩展
有针对 AI/ML 社区的 CUDA 扩展，但希望您避免在昂贵的 GPU 资源上执行数据转换和操作，这样您将更具成本效益和处理效率。
我认为，这些以数据为中心的任务缺乏关注点分离，是导致训练和运行 AI/ML 模型对 GPU 的需求增加，以及 CPU 消耗不足的原因之一。这与其说是缺乏对分离必要性的认识，不如说是设计和实现分离所需的时间；也就是说，分离并没有真正实现。
GPU 并非像 CPU 那样的通用处理器，它更适合（至少目前为止）用于算法和可视化计算——它们的发明是为了并行计算三角形上的点以进行图形显示。NVIDIA 提供了一些关于GPU 性能的介绍。以下是俄亥俄超级计算实验室 (2007) 对基于单元的处理器（GPU 是其中一种）的基本概述：
基于单元处理器的具体用例是关键要点，因为从开发角度来看，大多数工程师的职业生涯都专注于单处理器而非多处理器。针对特定计算资源进行工作负载分离的技能需要进一步培养和提升（插曲主题结束）。
Apache Iceberg 的幕后
元数据和数据存储的总体方法是确保不变性，这无疑是一个优势。为什么？简而言之，数据访问的并发性和性能在实现不变性的情况下（如果做得好）可以更好地扩展，此外，随着模式和数据的演变，还能提供可追溯性。如果您是 RDBMS 产品的用户，熟悉的数据（元数据）和索引碎片问题可能需要警惕并需要维护周期。它在分析（ROLAP）或混合（OLTP+长历史记录）案例中尤其重要，但随着不变性的实现，这个问题就会消失。
正如我上面指出或暗示的那样，Iceberg 包装并使用了来自 Apache 项目的多个不同库，例如 Arrow、Parquet、ORC 和 AVRO。这些库主要关注 I/O 操作，无论是内存持久化还是基于文件的持久化。Iceberg 还大量使用了Pydantic来用 Python 实现元数据。
模式结构的“模型”使用 Pydantic 构建和验证，元数据对象则使用持久化存储存储在目录中。持久化存储可以通过 REST、SQL DBMS、内存存储、Apache Hive、AWS Glue 或自定义方式访问。下方概述（源自https://iceberg.apache.org/spec/）可直观地了解其组织结构。下图中需要指出的一些额外细节：元数据文件是 Apache AVRO 文件，清单列表采用 JSON 格式。模式验证属性与 Pydantic 的结合可能是选择这种组合的原因。
元数据和数据质量
元数据组织始于命名空间级别，是对数据的逻辑或上下文分离。如果需要，您可以在访问数据时进行跨命名空间引用。表对象在命名空间“下”创建，并提供您可以在此处找到的模式的实现类型。如果您需要存储地理空间数据，Iceberg 支持几何和地理类型，并在元数据层提供对 CRS（坐标参考系）和边缘插值的支持。此外，Iceberg 还提供数据分区和行沿袭功能，并且可以在创建目录时设置保留到详细沿袭的记录数量。
为了更好地说明上图，我包含了为第二部分中的示例实现创建的 Iceberg 表的控制台文件输出。我在设备上创建了一个“warehouse”文件夹，列表从“docs”命名空间开始。它深入分析了“forecast”数据和元数据。
Pydantic 的实现，尤其是在使用“严格”模式（元数据和数据）时，涵盖了文章开头提到的“元数据”和“数据质量”要点。您还可以在元数据中获得模式版本控制，直至列级别，并且它具有非常好的机制来帮助您进行模式演化。Iceberg 元数据确实提供了许多使用 RDBMS 中等效于“约束”（而非文字表 DDL）实现的变体。您可以获得类型验证、必需字段指定以及大小和精度检查，但它缺少将自定义值列表应用于特定字段的功能。
根据我的经验，值列表在 OLTP 设计模式中比在 RDBMS 的 OLAP（分析）场景中更常见，而且 Apache Iceberg 显然是为分析用例而非事务处理而设计的。总的来说，它在数据质量和元数据方面是一个良好的开端。“默认”值属性确实提供了实现等效的代理“键”或使用“标识符”字段 ID 的能力。
它不提供相当于主键或唯一键的功能，后者是一种数据库约束类型，无论是否有关联索引，都能确保唯一性。它也没有用户管理的索引，但如果您是之前提到的任何文件格式的现有用户，这并不是什么新鲜事，而且我们也不期望它存在。确保唯一性取决于“用户”。例如，您可以在结构体中强制执行唯一性，但这取决于您自己，Iceberg 不会替您完成。
行级安全性
Apache Iceberg 面临的挑战在于 RWA（行级访问安全性）和数据完整性。我评估的是库中“内置”的功能，而不是如何使用其他工具构建解决方案来解决这些问题。
RWA 安全性并非内置于库中。行和元数据功能有一些非常优秀的谱系，可以帮助您诊断数据质量问题并提供随时间变化的功能。后者在时间序列用例中可能非常有用。但 RWA 安全性往往是企业安全需求；希望 LDAP 集成能够在未来实现这一点。
数据完整性
Iceberg 并没有真正关注数据完整性功能，或许是因为 AI/ML 数据访问的趋势是数据表去规范化，这样就不需要外键了，也就是说，只需要一个大表。在更传统的分析用例中，当多个表需要关系链接（物理或虚拟）时，数据完整性功能确实会出现，因此对于这些情况来说，添加此功能会很有帮助。即使它只是在元数据中跟踪信息，也能提升验证效率。这是 Iceberg 中一个被忽视的领域。
数据访问
目前使用上述任何一种 Apache Arrow 格式的用户都知道每种格式的优缺点。对于海量数据存储，Parquet 确实经常用于处理大型到超大型数据集，尤其是在需要分区以确保查询响应时间合理的情况下。我做了一个小规模的实现，将在本文的第二部分详细介绍，其中只记录简单的响应时间。但众所周知，Parquet 对查询请求的响应速度非常快，尤其是在分区良好的情况下。它的列式存储格式设计精良，非常适合并服务于分析用例。
在本文的下一部分中，我将介绍使用 Apache Iceberg 和财务数据以及一些 Python 聚合的简单实现。
