各类组织不断寻求创新解决方案，以更高效地管理数据。Apache Iceberg 作为数据湖的一种强大框架，提供了一种高性能的表格式，运作方式类似于关系数据库管理系统 (RDBMS) 表。本章深入探讨如何迁移您的数据架构，以利用 Apache Iceberg 带来的优势。

为什么要迁移到 Apache Iceberg？

您没有数据湖仓库或正在使用 Hive 表格式

Apache Iceberg 将通过 ACID 事务、模式/分区演进、时间旅行等功能，极大提升数据湖的数据处理能力，将您的数据湖转变为一个结合了数据湖灵活性和数据仓库性能/特性的湖仓库。

Iceberg 提供了其他表格式无法比拟的独特优势

Apache Iceberg 的独特功能包括开放规范、开源库、透明的项目治理、多元化的项目治理、无供应商锁定以及多样化的生态系统。

虽然迁移到 Apache Iceberg 承诺能实现更简化的数据架构，但这一过程如同任何迁移一样，可能复杂且具有挑战性。转变需要适应现有的数据结构、修改数据摄取管道并更新数据处理工作流。此外，组织可能需要重构现有的数据模型，并将数据存储重组为兼容 Iceberg 的格式。迁移还需要解决向后兼容性问题，确保现有数据能够无缝集成到新架构中。在本章中，我们将探讨最佳实践和策略，以有效克服这些挑战。我们将本章划分为多个部分，每个部分都解决迁移过程中的特定方面。

迁移注意事项

数据迁移需要仔细规划并遵循最佳实践，以确保迁移过程顺利可靠。本节作为一个重要基础，概述了在开始迁移之前需要考虑的关键因素。我们将讨论最佳实践、常见陷阱以及如何以结构化方式进行数据迁移。以下是一些关键考虑事项：

适应数据结构

在将数据迁移到 Apache Iceberg 之前，评估现有的数据结构并使其适应 Iceberg 的表格式。这可能涉及重组数据、重命名列或调整数据类型以符合 Iceberg 的要求。确保数据兼容性对于成功迁移至关重要。Apache Iceberg 对各种数据类型都具有灵活性，但对于复杂类型，Iceberg 提供了列表、结构体和映射。因此，对于像 JSON 数据这样在其他平台上可能有其自己的字段类型的情况，您需要决定是将数据转换为映射还是将其保存为字符串。

适应数据管道

更新您的数据管道以支持将数据写入 Iceberg 表。这可能涉及修改 ETL 过程并确保数据正确分区。幸运的是，Apache Iceberg 具有许多实用工具，可以使迁移 Hive、Delta Lake 和 Hudi 表等变得相当简单。

适应工作流

检查并调整您的数据工作流以适应 Iceberg。这包括考虑数据依赖关系、调度和数据访问如何随着新数据存储格式的改变而变化。例如，如果您将多个数据集去规范化为一个 Apache Iceberg 表，您需要确保这些表是最新的，并且任何有向无环图 (DAG) 在源表上的工作完成后才开始数据摄取任务。

您还需要考虑是执行就地迁移还是影子迁移。就地迁移使用现有的数据文件构建 Apache Iceberg 表，而影子迁移涉及在 Apache Iceberg 中创建一个重复的数据集，然后逐步转移掉旧数据集。表 13-1 列出了每种方法的优缺点。

就地迁移	影子迁移
优点	简单性
	可能较低的初始存储成本
缺点	风险更高，因为数据被直接修改，如果出现问题，没有简单的回滚选项

三步就地迁移计划

如本章所述，有多种工具可用于进行就地迁移，包括 migrate 和 add_files 过程。由于不需要写入新文件，需要考虑的问题是：

我是要在一个事务中迁移整个表，还是按分区逐步迁移？
何时应将所有读取和写入机制更改为使用新表而不是旧表？

对于小型到中型数据集，可以在一个事务中轻松迁移，但对于较大的表，更明智的是逐步迁移，每次将一个分区添加到 Apache Iceberg 表中，直到所有分区都添加完毕。在进行增量迁移时，在每个作业之间运行记录数和文件数检查将有助于确保新 Iceberg 表准确复制了旧表使用的现有数据文件。基本上，就地迁移计划包括以下步骤：

确定旧表中分区的文件和记录数量。
将分区的现有文件迁移到现有的 Apache Iceberg 表中。
确定 Iceberg 表中相同分区的文件和记录数量，以确保匹配。

只需重复这些步骤，直到所有分区都添加完毕。然后，您可以将所有读写操作迁移到 Apache Iceberg 表。

四阶段影子迁移计划

在制定影子迁移计划时，表的数据文件被重写为新的 Apache Iceberg 表，您需要采用多阶段方法，以便有足够的时间逐步采用新系统。以下是这种计划的高级别大纲（参见图 13-1 了解摘要）：

阶段 1：向旧系统写入数据，从旧系统读取数据

最初，继续向现有系统写入数据，同时设置 Iceberg 表。此阶段允许您在不影响正在进行的操作的情况下建立 Iceberg 基础设施。但此时您还无法享受 Iceberg 的功能。您还应确保在将新数据写入 Iceberg 之前，将所有历史数据从旧表写入新的 Iceberg 表。

阶段 2：向旧系统和新系统写入数据，从旧系统读取数据

在此阶段，将数据复制写入旧系统和新系统。这种冗余确保数据一致性，但增加了存储成本。

阶段 3：向旧系统和新系统写入数据，从新系统读取数据

一旦您对新的 Iceberg 设置有信心，将读操作切换为使用新的 Iceberg 表。在此过渡期间，确保数据一致性。

阶段 4：向新系统写入数据，从新系统读取数据

逐步淘汰旧系统，开始将数据专门写入新的 Iceberg 表。仔细监控过渡过程，以发现任何潜在问题。

通过遵循这些最佳实践并采用结构化的影子迁移计划，您可以最小化中断、降低风险，并确保数据迁移到 Apache Iceberg 的成功，同时维护数据完整性和可用性。

将 Hive 表迁移到 Apache Iceberg

使用 Iceberg 的原生过程从 Hive 表迁移到 Apache Iceberg 表可以大大增强数据管理能力，并为您的分析工作流程提供更强大的功能。在本节中，我们将探讨使用 Spark 和 Dremio 将 Hive 表迁移到 Iceberg 的过程，使用户能够充分利用 Iceberg 的性能和可靠性特性。Iceberg 的 Spark 扩展提供了两个主要过程：snapshot 和 migrate，每个过程在 Hive 表迁移过程中都有其特定用途。

Snapshot 过程

在从 Hive 表迁移到 Apache Iceberg 时，snapshot 过程非常适合用于创建一个专门用于测试目的的临时 Iceberg 副本。这是一种不影响源表的数据实验方法。快照使用原始表的数据文件创建。

以下是示例代码：

objectivec 复制代码

-- 创建 'db.tableA' 表的快照，命名为 'db.tableAsnapshot'
CALL catalog.system.snapshot('hive.db.tableA', 'db.tableAsnapshot')

-- 或者，指定快照的自定义位置
CALL catalog.system.snapshot('hive.db.tableA', 'db.tableAsnapshot', 's3://bucket/location')

在第一个示例中，我们将 Hive 表 tableA 创建一个名为 tableAsnapshot 的 Apache Iceberg 快照，这样我们就有一个 Hive 表和一个使用相同数据文件的 Apache Iceberg 表。默认情况下，这将基于表路径创建一个文件夹，用于存储元数据和以后创建的任何数据文件。如果我们想自定义这个位置，可以像前面的代码第二个示例那样指定一个自定义位置作为第三个参数。

Migrate 过程

migrate 过程简化了从 Hive 表到 Apache Iceberg 表的过渡，同时保留源表的数据文件。它复制表模式、分区、属性和位置到新的 Iceberg 表。这个过程对于数据迁移来说是一个强大的工具。如果您的源表数据文件是支持的格式（如 Avro、Parquet 或 ORC），此过程特别有效。

以下是如何使用 migrate 过程的示例：

c 复制代码

-- 将 'hive.db.sample' 表迁移到具有附加属性的 Iceberg 表
CALL catalog.system.migrate('hive.db.sample', map('foo', 'bar'))

在此示例中，我们将名为 sample 的 Hive 表迁移到我们的 Apache Iceberg 目录。新的表元数据围绕现有数据文件写入，但通过旧 Hive 表访问该表已被消除。现在必须作为 Apache Iceberg 表进行访问。如果您有自定义属性希望在新表中指定，可以选择性地传递一个 map 作为第二个参数。

在使用 migrate 过程时，您应仔细计划模式兼容性，考虑是否保留原始表，并提供任何必要的附加属性：

兼容性 确保源表的模式与 Iceberg 的要求兼容。如前所述，数据文件的支持格式包括 Avro、Parquet 和 ORC。如果源表的模式不兼容，您在迁移过程中可能会遇到问题。

备份保留 在使用 migrate 过程时，必须决定是否保留原始表作为备份。保留备份有助于回滚或参考目的。然而，这样做可能会增加存储成本。设置 drop_backup 为 true 确保不保留原始表（这意味着在 Hive Metastore 中不保留指向备份命名空间下的表的引用；数据文件仍在新的 Apache Iceberg 表中使用）。

将 Delta Lake 迁移到 Apache Iceberg

从 Delta Lake 迁移到 Apache Iceberg 可以在保留数据历史记录的同时打开新的数据管理可能性，并确保与强大的表格式兼容。Delta Lake 以其对 Parquet 文件格式的支持和时间旅行/版本控制功能而闻名，为数据管理提供了宝贵的能力。

在从 Delta Lake 迁移到 Iceberg 时，可以使用 iceberg-delta-lake 模块提供的 snapshotDeltaLakeTable 操作。此操作允许使用原始表的数据文件将现有的 Delta Lake 表快照为新的 Iceberg 表。新创建的 Iceberg 表将镜像源 Delta Lake 表的模式和分区。此迁移操作提供了一个无缝的过渡路径，同时保留数据的完整性。

要从 Delta Lake 迁移到 Iceberg，您需要以下最低依赖项：iceberg-delta-lake、delta-standalone-0.6.0 和 delta-storage-2.2.0。迁移过程支持特定协议版本的 Delta Lake 表，确保在迁移过程中兼容。

以下代码示例演示了 snapshotDeltaLakeTable 操作。它包括指定源 Delta Lake 表的位置、目标表的位置、新 Iceberg 表的标识符、要使用的目录、访问所需的 Hadoop 配置和其他表属性：

ini 复制代码

import org.apache.iceberg.catalog.TableIdentifier;
import org.apache.iceberg.catalog.Catalog;
import org.apache.hadoop.conf.Configuration;
import org.apache.iceberg.delta.DeltaLakeToIcebergMigrationActionsProvider;

// 源 Delta Lake 表的位置
String sourceDeltaLakeTableLocation = "s3://my-bucket/delta-table";

// 新 Apache Iceberg 表的位置
String destTableLocation = "s3://my-bucket/iceberg-table";

// 表名
TableIdentifier destTableIdentifier = TableIdentifier.of("my_db", "my_table");

// Iceberg 目录，用于添加表
Catalog icebergCatalog = ...;

// Delta Lake 表的文件系统配置
Configuration hadoopConf = ...;

DeltaLakeToIcebergMigrationActionsProvider.defaultActions()
    .snapshotDeltaLakeTable(sourceDeltaLakeTableLocation)
    .as(destTableIdentifier)
    .icebergCatalog(icebergCatalog)
    .tableLocation(destTableLocation)
    .deltaLakeConfiguration(hadoopConf)
    .tableProperty("my_property", "my_value")
    .execute();

snapshotDeltaLakeTable 操作简化了迁移过程，确保保留数据的历史记录，同时提供 Iceberg 独有的功能优势。

将 Apache Hudi 迁移到 Apache Iceberg

Apache Hudi 是一种流行的数据湖存储格式，以支持 ACID 事务和高效的数据管理功能而闻名。但是，如果您正在考虑从 Hudi 迁移到 Apache Iceberg，您会很高兴知道，目前正在开发类似于 Delta Lake 快照过程的 Hudi 表迁移过程（拉取请求 #6642）。此过程允许您使用现有表的数据文件无缝迁移数据。

将 Hudi 表迁移到 Iceberg 表的迁移过程涉及使用 iceberg-hudi 模块提供的 HudiToIcebergMigrationActionsProvider 类。此迁移的关键操作是 snapshotHudiTable，它使您能够将现有的 Hudi 表快照为新的 Iceberg 表。此迁移操作为从 Hudi 迁移到 Iceberg 提供了可靠的路径。

以下是如何使用 snapshotHudiTable 操作将 Hudi 表迁移到 Iceberg 表的示例：

ini 复制代码

import org.apache.iceberg.catalog.TableIdentifier;
import org.apache.iceberg.catalog.Catalog;
import org.apache.hadoop.conf.Configuration;
import org.apache.iceberg.hudi.HudiToIcebergMigrationActionsProvider;

// 现有 Hudi 表的位置
String hudiTablePath = "hdfs://my-hudi-table";

// 新 Iceberg 表的名称
String newTableIdentifier = "my_db.my_table";

// 将新表注册到的 Iceberg 目录
Catalog icebergCatalog = ...;

// Hudi 表的文件系统配置
Configuration hadoopConf = ...;

HudiToIcebergMigrationActionsProvider.defaultProvider()
    .snapshotHudiTable(hudiTablePath)
    .as(TableIdentifier.parse(newTableIdentifier))
    .hoodieConfiguration(hadoopConf)
    .icebergCatalog(icebergCatalog)
    .execute();

在此示例中，我们指定了 Hudi 表的路径、新 Iceberg 表的标识符、访问所需的 Hadoop 配置以及要使用的 Iceberg 目录。

将单个文件迁移到 Apache Iceberg

在某些情况下，您可能有存储为单个文件的数据集，例如纯 Parquet 数据集（即 Hive Metastore 未跟踪包含这些文件的分区目录），并希望将这些文件迁移到 Apache Iceberg 表中，以提高管理、查询性能和模式演变能力。Apache Iceberg 提供了 add_files 过程来促进这一迁移过程，使您可以将文件导入现有的 Iceberg 表中，而无需创建新表。此外，您还可以使用此过程将数据从 Delta Lake 和 Apache Hudi 表迁移过来，而无需保留历史记录，方法是过期所有先前的快照。

使用 add_files 过程

add_files 过程是一种将外部数据文件添加到 Apache Iceberg 表中的多功能方法。它不会分析文件的模式，因此需要确保文件与目标 Iceberg 表的模式和分区匹配，以防止读取 Iceberg 表时出现不一致情况。以下是如何使用 add_files 过程的示例：

ini 复制代码

CALL catalog.system.add_files(
  table => 'db.my_table',
  source_table => 's3://my-parquet-tables/tables',
  partition_filter => map('partition_col', 'partition_value'),
  check_duplicate_files => true
)

在这个示例中，我们告诉引擎将特定文件夹中的表中所有数据文件添加到 my_table 中。我们可以使用 partition_filter 参数仅添加来自特定分区的文件以进行增量处理，并启用重复文件检查以避免重复添加。

此过程将为新文件创建元数据，并将它们视为 Iceberg 表文件集的一部分（假定这些文件与 Iceberg 表的分区和模式匹配）。值得注意的是，后续的 Iceberg 操作可以物理删除使用此方法添加的文件。

从 Delta Lake 或 Apache Hudi 迁移而不保留历史记录

要将数据从 Delta Lake 或 Apache Hudi 表迁移到 Apache Iceberg 表而不保留历史记录，请按照以下步骤操作：

过期 Delta Lake 或 Hudi 表中的所有先前快照，以仅保留当前快照的文件。
使用 add_files 过程将当前快照中的文件导入目标 Iceberg 表，如前述示例所示。

这种方法使您能够在保持数据的最新版本的同时迁移到 Apache Iceberg，这在维护简化的数据湖版本时非常有利。

通过利用 add_files 过程，Apache Iceberg 提供了一种灵活且高效的方法，将单个文件或其他存储格式的数据迁移到 Iceberg 表中。

从任意位置迁移数据到 Apache Iceberg

灵活性通常是最重要的目标之一。在将数据从各种来源迁移到 Apache Iceberg 表时，有两种方法可以选择。您可以使用 CREATE TABLE...AS SELECT（CTAS）语句通过任何引擎（包括 Spark、Dremio、Trino 和 Presto）将数据迁移到新表中。您还可以使用 COPY INTO 命令（Dremio/Snowflake）从非表源（如 JSON/CSV）中插入数据到现有的 Iceberg 表中，或者使用 INSERT INTO SELECT 命令从任何其他表中插入数据。

将数据迁移到新的 Iceberg 表

使用 CTAS 语句将数据迁移到新的 Apache Iceberg 表是一种强大且多功能的方法，原因如下：

模式演变

CTAS 允许您在迁移过程中调整模式。您可以将源表的列映射到目标表，重命名列，更改数据类型，并应用计算列的表达式。

分区控制

如果源数据没有按所需方式进行分区，您可以使用 CTAS 根据特定的列、日期或其他标准创建分区。这可以提高数据组织和查询性能。

数据转换

您可以在 CTAS 查询中应用数据转换，使迁移过程中能够清理、聚合或预处理数据。

这种方法允许对迁移过程进行细粒度的控制，并在数据传输过程中进行模式、分区和数据修改。以下是执行此迁移的步骤：

首先，连接到原始数据源和目标 Iceberg 目录。这通常涉及配置查询引擎（例如 Dremio 的 SQL 查询引擎、Apache Spark、Trino、Presto）以访问源数据和目标 Iceberg 目录。

连接建立后，您可以使用 CTAS 语句迁移数据。CTAS 语句创建一个新的 Iceberg 表并用源数据填充它。以下是使用 Apache Spark SQL 的示例：

sql 复制代码

CREATE TABLE catalog.db.tableA
USING iceberg
PARTITIONED BY (month(ts_field))
AS
SELECT *,
       CAST(old_field AS <data_type>) AS updated_field
FROM my_source_table;

在这个示例中，我们在名为 tableA 的目录中创建一个新的 Apache Iceberg 表。该表将复制 SELECT 查询的结果，该查询将旧字段的数据类型转换为我们想要更新的类型。我们还指定了一个分区方案，使用 month 转换来利用 Iceberg 的分区功能，因为新数据在写入时会生成新的数据文件。

在将大型数据集迁移到新的 Iceberg 表时，有一些关于可伸缩性和性能的最佳实践需要考虑：

增量迁移

考虑采用增量迁移的方法，而不是一次性迁移整个数据集。首先使用 CTAS 语句覆盖单个分区或部分数据，然后使用 INSERT INTO SELECT 语句逐步添加其他分区的数据。这可以减少资源过载的风险并提高可管理性。在此过程中，确保按分区运行记录数检查，以检查数据的完整性。

并行优化

根据您的查询引擎，您可以通过利用并行处理来优化性能。确保查询引擎的并行设置适当配置，以适应迁移任务。

监控和日志记录

密切关注迁移过程。监控进度、资源使用情况以及潜在的错误或问题。记录迁移活动对于故障排除和审计目的非常重要。

总而言之，使用 CTAS 语句与查询引擎将数据迁移到 Apache Iceberg 表中，为您提供对迁移过程的细粒度控制。此方法适用于各种迁移场景，包括模式更改、分区策略和数据转换。处理大型数据集时，考虑增量迁移和性能优化，以实现平稳高效的数据传输过程，同时保留表历史记录。

将数据迁移到现有 Iceberg 表

将数据迁移到现有的 Apache Iceberg 表需要不同于 CTAS 的路径，CTAS 创建新表。我们将在这里讨论两种常见路径：

使用 COPY INTO 语句从非表源（文件）插入数据。
使用 INSERT INTO SELECT 语句从另一个表插入数据。

COPY INTO 命令

COPY INTO 命令从不是引擎中目录化表的源获取数据并将其插入目标表（写入新的数据文件）。使用 COPY INTO 的好处包括：

模式强制

COPY INTO 命令会自动强制来自无模式源（如 CSV）的文件中的数据匹配目标 Iceberg 表的模式。这意味着数据类型、列名和结构将根据需要进行调整，从而减少数据类型不匹配的风险。

高效的数据摄取

COPY INTO 命令优化了高效的数据摄取。它节省了将数据分阶段作为另一个表的时间。

增量数据摄取

您可以使用 COPY INTO 命令进行增量数据摄取。如果有新的 CSV、JSON 或 Parquet 文件要添加到 Iceberg 表，只需再次运行命令即可。

这非常有帮助，因为当您只打算将数据插入另一个表时，省去了将数据分阶段作为表的步骤。以下是一个示例：

sql 复制代码

-- 使用 Dremio 语法的 COPY INTO 示例
COPY INTO catalog.db.my_iceberg_table
FROM '@my_dremio_source/folder'
FILE_FORMAT 'csv';

在这个示例中，目的是将文件夹中的 CSV 文件的数据添加到名为 my_iceberg_table 的表中。Dremio 将读取 CSV 文件中的所有数据，应用目标表的模式，并写入将添加到该表的新数据文件。

使用 COPY INTO 进行成功迁移的几个注意事项：

数据质量

确保 CSV、JSON 或 Parquet 文件中的数据是干净的，并符合目标 Iceberg 表的模式。不一致或格式错误的数据可能导致摄取错误。

文件组织

以适合您的用例的方式组织数据文件。例如，如果按日期对 Iceberg 表进行分区并进行增量摄取，请将文件组织到日期特定的文件夹中，使其易于在每个增量步骤中指定要摄取的数据。

文件格式选项

根据数据的特性，您可以在 FILE_FORMAT 子句中指定其他选项，例如日期和时间格式、分隔符字符以及 NULL 值的处理方式。

Dremio 版本的 COPY INTO 语句可以执行增量数据摄取。这意味着您可以在不重新加载整个数据集的情况下将新数据添加到现有的 Iceberg 表中。

首先，您必须通过将数据组织到文件中，放置文件到源位置，并在文件名前加上目标摄取日期来准备新数据。接下来，重新运行 COPY INTO 命令，并使用正则表达式过滤文件，仅针对特定日期前缀的文件，指定相同的目标 Iceberg 表。以下是一个示例：

sql 复制代码

-- DremioSQL 语法
-- 使用正则表达式模式的 COPY INTO 命令
COPY INTO my_table
FROM '@my_storage_location'
REGEX '^2023-10-11_.*.csv'
FILE_FORMAT 'csv';

对于 Snowflake COPY INTO，您可以让不同的文件夹表示不同的摄取点：

sql 复制代码

-- SnowflakeDB 语法
-- 使用 COPY INTO 命令摄取文件
COPY INTO '@my_external_stage'
FROM '@s3://my-s3-bucket/path/tablea-2023-10-11'
FILE_FORMAT = (TYPE = 'CSV' FIELD_DELIMITER = ',' SKIP_HEADER = 1)
CREDENTIALS = (AWS_KEY_ID = '<your_aws_key_id>' AWS_SECRET_KEY = 
'<your_aws_secret_key>')
VALIDATION_MODE = RETURN_ROWS;

COPY INTO 命令提供了一种简单高效的方法将数据迁移到现有的 Apache Iceberg 表中。这种方法确保模式强制和高效的数据摄取，还支持增量更新，使其成为保持 Iceberg 表与新数据同步的宝贵选择。

INSERT INTO SELECT 命令

使用任何查询引擎，您可以使用 INSERT INTO SELECT 将数据从任何表插入到 Apache Iceberg 表中。这对于可以从多个来源联邦数据的引擎（例如 Dremio、Trino 和 Presto）特别有用。只需从另一个表插入数据：

sql 复制代码

INSERT INTO tableB
SELECT * FROM tableA;

要更新数据，您可以使用 MERGE INTO 语句，如果源表有 updated_at 和 created_at 字段，这会更容易：

sql 复制代码

-- DremioSQL 语法
MERGE INTO tableB AS target
USING (
    SELECT *
    FROM tableA
    WHERE created_at >= DATE_DIFF(CURRENT_DATE(), CAST(30 AS INTERVAL DAY))
       OR updated_at >= DATE_DIFF(CURRENT_DATE(), CAST(30 AS INTERVAL DAY))
) AS source
ON target.id = source.id
WHEN MATCHED THEN
    UPDATE SET
        target.column1 = source.column1,
        target.column2 = source.column2, 
        target.created_at = source.created_at,
        target.updated_at = source.updated_at
WHEN NOT MATCHED THEN
    INSERT *

在上述示例中，我们合并了在过去 30 天内创建或更新的数据。这使作业更具性能，因为我们不会合并两个表中的每条记录，只是相关记录。当处理表时，使用 INSERT INTO 命令允许您轻松地将数据从一个表插入到 Apache Iceberg 表中。此外，MERGE INTO 可以使在支持该功能的平台上运行全面的 upsert 操作变得容易。

结论

本章全面概述了迁移到 Apache Iceberg 的数据迁移策略和最佳实践。我们首先奠定了基础，强调了成功迁移所需的关键考虑因素和结构化方法。理解挑战和陷阱对于实现无缝过渡至关重要。

接下来，我们深入探讨了具体的迁移场景，从 Hive 表的迁移开始，展示了如何使用 migrate 和 snapshot 程序。我们还探讨了从 Delta Lake 和 Apache Hudi 迁移的过程，并讨论了对于没有表格式的情况，如何将单个文件迁移到 Apache Iceberg。这样的灵活性允许高效的数据移动，同时不影响 Iceberg 的管理和性能能力。

此外，我们还探讨了如何重写来自各种来源的数据，包括使用 CTAS 语句将数据填充到新的 Apache Iceberg 表中，或者使用 COPY INTO 或 INSERT INTO SELECT 语句将数据注入到现有的 Iceberg 表中，无论其原始格式如何。这种适应性允许您无缝处理来自不同来源的数据。

在第14章中，我们将演示在多个用例中使用 Apache Iceberg 的过程，包括商业智能仪表板和 AI/ML 应用。