事务语义

Redshift Iceberg 写入查询支持 ACID 和快照隔离。写事务可以保证原子性，并且在查询意外失败时不会造成部分更新。

多个 Iceberg 事务可以同时运行，如果两个事务尝试并发修改同一个表或分区，则事务提交将失败。这样可以确保数据的完整性。出现这种情况时，您必须手动解决冲突并重新运行失败的查询。Amazon Redshift 不会自动重试和解决冲突。

单个 Iceberg 写入查询始终被视为单个自动提交事务。当 Iceberg 写入查询（例如 CREATE 或 INSERT 查询）包含在显式事务块中时，同一个事务块中无法运行任何其他查询。事务将失败。

下面是一些示例。第一个示例演示单语句查询始终在查询完成后自动提交。在此场景中，您要创建新的销售订单表：

CREATE TABLE sales_schema.orders (
    order_id int, 
    customer_id int, 
    order_date date, 
    total_amount decimal(10,2)
) USING ICEBERG LOCATION 's3://my-data-lake/sales/orders/';

此示例是一个显式事务块，针对 S3 表存储桶，使用三部分表示法插入客户订单。事务没有在 INSERT 查询之后自动提交，而是使用 COMMIT 命令提交并插入订单数据：

BEGIN;
INSERT INTO "analytics_bucket@s3tablescatalog".sales_db.orders VALUES (12345, 9876, '2024-10-30', 299.99);
COMMIT; 

此示例是一个显式事务块回滚场景，在此场景中，您测试插入订单然后决定取消订单的情况。事务没有在 INSERT 查询之后自动提交，而是使用 ROLLBACK 命令进行回滚，不插入测试订单。

BEGIN;
INSERT INTO sales_schema.orders VALUES (12346, 5432, '2024-10-30', 150.75);
ROLLBACK; 

最后一个示例演示的情况是，当您尝试在与 INSERT 查询相同的事务块中运行另一条语句时，事务会如何失败而不插入订单数据。在这个场景下，您尝试插入订单并立即查询表：

BEGIN;
INSERT INTO sales_schema.orders VALUES (12347, 7890, '2024-10-30', 425.50);
SELECT * FROM sales_schema.orders WHERE order_id = 12347;

这个场景中的唯一例外是 DROP TABLE 语句，其行为始终是自动提交语句，而且无法在显式事务块中运行。这是为了保持与对外部表执行 DROP TABLE 操作时相同的行为。有关更多信息，请参阅 DROP TABLE。