1. 概述

在企业模式下，数据会本地存储并分布在所有节点上，以减少查询时间。Vertica 的 Eon 模式使用 Amazon S3 来存储数据。Amazon S3 提供了一种不同类型的存储范例。
Eon 模式是一种基于订阅的模型，其中数据存储与计算分开，存储成本较低。此外，用户无需负责备份和数据生命周期管理等任务。
这里需要更多关注的是数据访问的财务和性能成本，如 Amazon S3 定价所示。在大多数情况下，数据访问是存储数据的主要目的。

在针对 S3 等存储系统设计工作负载时，请注意需要大量且频繁的数据访问的 ETL 流程。如果数据访问效率不高，可能会抵消从数据存储中获得的节省并导致性能不佳。

本文提供了一些指示，以尽量减少数据访问并提高 Vertica 中 ETL 处理的性能。

2. 传统存储与 S3 的差异

以下是传统存储（如 RAID 存储）与 S3 存储之间的一些技术差异：

• 与直接连接存储相比，访问 S3 会消耗网络带宽，并且延迟要大得多。
• 一致性模型可能会给分布式数据库带来一些有趣的挑战，这些数据库在使用最终一致且不可变的存储系统（如 S3）时必须提供 ACID 特性。
• 传统存储没有每次访问成本。每次从 S3 读取数据时都会产生成本。

3. 在 Eon 模式存储系统的关键考虑因素

与企业模式数据库相比，在 Eon 模式下，加载、修改和访问数据时需要格外小心。

• 某些在企业模式上同步进行的数据库操作现在在 Eon 模式下变为异步。例如Delete、Truncate和ROS删除（对于 TM MergeOut）。通常，将这些操作推迟到一定程度就足以实现实时性能。然而，其本质就是一个权衡，即共享公共存储在清除数据库已删除数据的时间落后于当前集群状态的程度。
• Insert或Copy等操作会立即写入共享存储，而不会推迟到客户端提交。这意味着插入会导致立即上传到 S3。当客户端最终“commit”事务时，只会更新事务日志以包含先前上传的文件。这可以提高commit操作在性能较差的存储系统上的性能。
• 最后，因为公共存储上的文件是不可修改的，所以事务日志（Transaction Log）更新是批量的（通常是每5分钟将本地文件上传到公共存储），不是流式的。企业模式的数据库在将内存中的数据写入磁盘后“干净的”关闭数据库。同样， Eon 模式的数据库也需要将事务日志在共享存储上持久保存（同步）以“干净”的关闭数据库。

4. 本文符号的使用

本文图示中使用了如下一些符号：

5. Eon 模式事务示例

为了理解 Eon 模式事务，举一个示例，当用户创建表并提交一些数据时会发生什么。此示例将在以下部分逐步解释。

5.1 步骤 1：DDL 语句

Create Table T (I int);

事务日志文件是跟踪数据库系统上所有事务的文件。此文件通常仅在事务发生时进行追加，并且每个提交的事务都有一个递增的序列值。

DDL 语句被视为事务并导致此序列号递增。在本地创建表时，不会立即从本地文件系统同步到 S3。出于效率原因，这些同步会定期（每 5 分钟）分批进行。

5.2 步骤 2：DML（Insert/Update/Delete/Merge）语句

Insert Into T Values (1);

通常，Insert或copy任务都会产生一个或一批新的数据文件。
这些文件在本地存储中创建并立即（同步）上传到 S3。当用户提交时，会相应增加会话事务（Transaction Log）的序列号。

5.3 步骤3：Commit语句

commit;

提交语句将序列号保留在事务日志文件（Transaction Log）中，从而使对新数据文件（在上一步中添加）的引用永久生效。

5.4 步骤4：Drop/Truncate 对象

Drop Table T;

事务日志（Transaction Log）文件将会记录drop table 语句，并增加事务日志的序列号，引用Drop语句删除的文件。然后从数据库catalog中删除这些已删除文件的引用，最终在计算节点上删除该drop语句删除的相关文件。

但是，该drop语句删除的相关数据文件并不会立即从 S3 中删除或移除。文件将排队等待稍后删除。此队列称为“Reaper Queue”。

Reaper 进程每 5 分钟检查一次，并删除符合删除条件的文件（本地和 S3 均有）。同样，这样做是出于性能原因，以实现 DROP/TRUNCATE/DELETE（通过 TM MergeOut）语句的实时性。
如果每次在数据库执行数据删除都需要同步清理公共存储上文件的话，那势必会造成等待，降低性能。

在停库关闭Vertica时，有一个参数设置确保Reaper进程有足够的时间删除Reaper Queue中的文件。

但如果出现意外的实例终止、重新启动或 Vertica 进程被强制终止的情况，Reaper 进程可能没有机会删除 S3 中的文件。 因此，正常关闭数据库非常重要。

6. Eon 模式下 ETL 的建议

我们强烈建议在 Eon 模式下进行 ETL 事务时遵循以下做法：

• 使用临时表
• 正常的关闭数据库
• Tuple Mover 活动

6.1 使用临时表

在 Eon 模式下，我们强烈建议使用临时表来暂存、合并和转换最终可能被 Delete 或 Truncate 的数据。
临时表是会话范围的，不会在 S3 上创建对象。因此，它们性能更好，并节省了 S3 访问成本。
TEMPSPACE 可以是一个快速的临时卷，以获得最佳效果，并且包含在实例中，无需额外费用。
有关创建临时表的更多信息，请参阅创建临时表。

优点：
以下是使用临时表进行 ETL 和暂存数据的优点：
• 由于没有数据写入 S3，因此 INSERTS/UPDATES/DELETES 速度更快
• 节省网络带宽
• 节省 S3 读/写和访问成本
• 节省 S3 API 调用成本
• 节省 S3 存储成本
• 临时表不会在公共存储中创建文件，因此，在实例终止期间消除了一些清理开销，并且不使用 Reaper Queue。

示例：
以下示例说明了如何使用本地临时表来完成简单的工作负载。

在此案例中，对临时表上执行的任何操作都不会下载或上传（访问）到 S3。只有在数据转换、更新、合并和处理后，最终对 Final_T 的 Insert … select … 结果才会更新到 S3 的文件，这大大降低了访问 s3 的频率。

6.2 关闭和突然进程终止

Eon Mode 数据库必须始终干净地终止。突然终止 Eon Mode 数据库可能会导致数据丢失，因为事务日志每 5 分钟同步一次。如果发生异常终止，过去 5 分钟内提交的数据可能会丢失。

此外，如果不允许 Reaper 进程删除 Reaper Queue 中的文件，这些文件将留在 S3 中（文件泄漏），这些泄漏的文件只能通过手动删除。

6.3 Tuple Mover 活动

Tuple Mover 整合 ROS 数据存储并执行重要功能 Mergeout。

在 Eon 模式下，建议不要将数据加载到分区表的非活动分区中。

6.3.1 分区和 MergeOuts

Tuple Mover 认为，业务对分区表的所有数据加载和更新都是针对一个或多个被标识为活动的分区。

通常，具有最新分区键的分区（通常是最近创建的分区）被视为活动分区。随着分区老化，它通常会转变为大部分只读工作负载，并且需要的活动要少得多。也就是说，分区变为非活动分区。

6.3.2 相关文章

• Active and Inactive Partitions
• Vertica Partitions: The FAQs
• Tuple Mover Best Practices

Tuple Mover 会将非活动分区的 ROS 容器合并到单个 ROS 容器中。这可能会导致大量从 S3 读取/写入，并可能产生 S3 访问成本。

6.3.3 案例

这是一个 Active Partition Key=4 和Active Partition Count = 1 的案例。

在此案例中，我们已将 key=1 加载到分区中。每次加载时都会创建一个容器。此外，这会将活动分区键更改为 1。

一旦您加载到下一个分区（key=2），此分区就会变为活动分区。现在，活动分区键=2，这意味着 TM 将合并分区键=1 的所有容器。此合并是异步发生的。因此，最终状态是分区键 1 的所有文件都合并为一个文件。

在 Eon 模式下，这需要

1. 从 S3 下载整个非活动分区（key=1）。
2. 在本地合并。
3. 上传合并后的单个文件。
4. 通过 reaper 进程删除旧分区文件。

假设您有 4 个分区，并且活动分区数设置为 1。例如，分区键 =(1,2,3) 被视为非活动分区，而分区键 = 4 为活动分区。Vertica 希望您仅将数据加载到一个活动分区键 = 4。
假设您决定加载到所有分区，将发生以下情况：

1. 当前活动分区键 =4 ，非活动分区键 = 1,2,3。加载数据到键 =1 的非活动分区，Vertica 上传分区键 =1 的新容器
2. 现在活动分区键 =1 ，非活动分区键 = 2,3,4。TM 将下载键 =4 的非活动分区的所有容器并将其合并为一个文件，然后删除所有旧文件。
3. 当前活动分区键 =1 ，非活动分区键 = 2,3,4。加载数据到分区键 =2 的非活动分区，Vertica 上传分区键 =2 的新容器
4. 现在活动分区键 =2 ，非活动分区键 = 1,3,4。TM 将下载键 =1 的非活动分区的所有容器并将其合并为一个文件，然后删除所有旧文件。
5. 当前活动分区键 =2 ，非活动分区键 = 1,3,4。加载数据到 Key =3 的非活动分区，Vertica 上传分区键 =3 的新容器
6. 现在活动分区键 =3，非活动分区键 = 1,2,4。TM 将下载 Key =2 的非活动分区的所有容器并将其合并为一个文件，并删除所有旧文件。

这里的问题是，每次加载到非活动分区时，都会下载旧分区文件，将其与新数据合并以创建新文件，上传新文件，然后删除旧文件。

在 Eon 模式下，更重要的是不要加载到非活动分区。分区需要按照最佳实践使用，主要用于管理数据保留。分区使用不当可能会产生大量的 AWS 访问成本。

例如，如果您要在任何给定时间同时加载过去三天生成的数据，按天分区并将活动分区计数设置为 1（默认）可能不是正确的做法。

您必须执行以下任一操作，以便最近三天的数据始终加载到活动分区中：

• 按天分区（但设置活动分区计数 = 3）
  或
• 按周分区（并设置活动分区计数 = 2）

Tips：
在 Eon 模式下使用移动、复制和交换分区功能非常有益，因为它们不会导致任何数据文件的移动。这纯粹是一个目录 (DDL) 操作。