Amica 成立于 1907 年，是美国历史最悠久的汽车互助保险公司，在客户服务方面有着良好的记录。如今，他们提供的保险产品组合包括汽车、家居、海运、人寿和个人雨伞。

在保险行业，“核心应用程序” 是指专门构建的系统，用于管理承运人的基本业务，包括承保单、追踪保费、处理索赔和维持监管合规性。这些系统是保险业务的记录系统，选择正确的平台是基础架构决策。Amica 委托 Guidewire Cloud 为其许多保险项目提供这些核心功能，使他们的工程团队能够专注于为投保人提供增值服务。

作为 Amica 保险业务的记录系统，Guidewire Cloud 已经积累了数十兆兆字节的表格数据，商业用户依赖这些数据进行财务报告和商业智能。以前，Amica 会提取这些数据，并通过关系数据库为业务用户提供访问权限。但是随着数据量的增长，他们面临着查询性能、架构演变和时间点分析方面的挑战。Amica 意识到，Apache Iceberg（一种用于在分布式存储中组织数据湖的开放表格式）可以解决这些挑战。然而，Iceberg 表需要定期维护（压缩、快照管理和删除未引用的文件），以维持 Amica 数据消费者可以接受的性能水平，这抵消了采用的价值。当 AWS 发布 Amazon S3 Tables 时，这种计算方式发生了变化。在这篇文章中，您将了解 Amica 如何使用 S3 Tables 为核心保险数据构建数据湖，将他们的 ETL 任务运行时间缩短 80％。

旧系统

在使用 S3 Tables 之前，Amica 使用亚马逊 EMR 提取和转换 Guidewire 云数据，然后将这些数据加载到关系数据库中，该数据库是企业用户的主要接入点。随着时间的推移，他们在使用这种设置时遇到了一些挑战：

-性能-数据量和用户数量都增加了，导致报告时间变慢和超时。添加数据库的只读副本有助于缓解问题，但是这种技术使基础架构成本翻了一番。

-架构演变-表格架构经常发生变化，随着保险产品的发展，会增加新的栏目。使关系数据库适应这些变化需要复杂的数据管理操作。

-时间点分析-为了便于月度或年终报告，Amica 必须执行加载数据库快照这一昂贵而耗时的过程。

随着数据量的增加，这些挑战变得更加严峻，因此 Amica 想重塑他们的数据管道。

解决方案

为了解决这些限制，Amica 选择在其 Parquet 文件之上使用 Apache Iceberg，这是一种用于生成大型分析表的开源高性能格式。该团队很快面临几项必须解决的设计决策。该解决方案需要支持数百个 Iceberg 桌子；管理和微调该环境需要自动化和工具。

S3 Tables 为 Amica 提供了一个替代存储选项，该选项可以在不增加运营开支的情况下提供 Apache Iceberg 的性能优势。作为一项完全托管的服务，S3 Tables 可自动处理表维护、压缩和优化，无需自定义工具和自动化。

这种转变解决了他们在传统系统中遇到的核心挑战，使他们能够专注于为业务用户创造价值。

-S3 Tables 通过提供可扩展的数据湖架构，在不降低查询性能的情况下处理不断增长的数据量和用户并发性，从而消除了对昂贵的只读副本的需求。

-S3 Tables 抽象了构成 Iceberg 表的组成数据和元数据文件，从而消除了这些文件作为操作方面的问题。

-架构演变变得无缝衔接，因为 Iceberg 格式本身支持随着保险产品的发展添加新列，无需进行关系数据库所需的复杂数据管理操作。

-时间点分析成为差异化因素。Iceberg 的时空旅行查询功能支持月末和年终报告，无需加载数据库快照这一昂贵而耗时的过程，从而可以即时访问历史数据状态。

实现

图 1：Amica 的核心应用程序数据管道架构，由 AWS Step Functions 编排，数据访问由 AWS Lake Formation 管理

-Guidewire 会定期将 Parquet 格式的变更数据捕获 (CDC) 记录发送到位于 Guidewire 拥有的 AWS 账户中的 S3 通用存储桶。Guidewire 还向该存储桶提供了一份 JSON 格式的清单，该清单标识了新记录的 S3 前缀。Guidewire 授予 Amica 的 AWS 账户对存储桶的读取权限。

-EventBridge 调度器每天多次调用 AWS Step Functions 状态机，该状态机协调管道的摄取部分。

-在状态机内，Lambda 函数从 DynamoDB 表中读取时间戳检查点，以确定上次执行管道的时间。它还会创建一个新的检查点供后续执行使用。

-Lambda 函数读取清单以识别自上次执行以来生成的 CDC 记录。

-AWS Glue 任务将传入的 Parquet 文件转换为两个表格集。“原始” 表包含未经编辑的 CDC 跨表记录。“合并” 表捕获每个表在检查点的状态。每个集合都位于单独的 S3 Tables 存储桶中，并启用了 Lake Formation 集成。

数据授权

-当摄取状态机完成执行时，Lambda 函数将架构更改记录到 DynamoDB 表中，并在 IT 服务管理 (ITSM) 系统中创建票证。（Guidewire 可能会引入新列，但不会移除现有列。）

-数据管理员通过 ITSM 系统审查票证并对新的数据列进行分类。当监管员解决票证时，Lambda 函数会根据这些分类自动创建或修改 Lake Formation 数据过滤器。

-Amica 用户根据其数据分类授权属于 IAM 身份中心群组。分配给这些群组的 Lake Formation 拨款控制他们对 S3 Tables 数据的 Athena 查询访问权限。

自己试试

AWS 已经发布了开源示例代码，该代码为 Guidewire CDA 实现了类似的架构，您可以将其部署到自己的账户中作为起点。示例代码遵循此处描述的相同端到端模式——Guidewire CDA 清单驱动 AWS Step Functions 向合并（“合并”）和仅附加变更历史记录（“原始”）表中增量摄取，Athena 访问权限受 AWS Lake Formation 管辖，包括架构演变、增量检查点以及与 Guidewire 的行数对账。它在亚马逊 EMR Serverless 上使用 Apache Spark 进行转换步骤，而 Amica 使用 AWS Glue，因此它作为该模式的参考，而不是 Amica 管道的副本。示例代码是在 MIT-0 许可下提供的。

影响

在采用 S3 Tables 之前，Amica 操作了四个数据库实例：两个表集各有一个写入器和一个读取器。通过整合到两个 S3 Tables 表存储桶，Amica 将生产和非生产环境的每月基础设施成本降低了 83%。他们改进的数据管道消除了对耗时的 UPDATE TABLE 操作的需求，而是利用了 Apache Iceberg 的架构演变能力。结果，数据管道的运行时间缩短了 5 倍，从 20 小时缩短到 4 小时。

结论

Amica 从传统关系数据库到 S3 Tables 的旅程展示了现代数据架构如何改变核心保险业务。通过采用 S3 Tables，Amica 提高了数据管道效率，同时消除了管理关系数据库的运营开销，并避免了维护标准 Apache Iceberg 表。由于 S3 Tables 可以自动处理表格维护、压缩和优化，因此 Amica 的工程团队可以将注意力从运营转移到业务创新上。

对于面临类似挑战且核心应用程序数据量不断增长的保险公司而言，S3 Tables 提供了一条引人注目的前进道路。Apache Iceberg 的性能优势与 AWS 的完全托管服务相结合，消除了功能和操作复杂性之间的传统权衡。

要了解有关 Amazon S3 Tables 的更多信息，请阅读 S3 Tables 文档。有关使用 Apache Iceberg 实施数据湖的指导，请浏览 AWS Lake Formation 最佳实践。要实现类似的管道，您可以部署开源 AWS 示例代码作为您自己的 Guidewire CDA 数据湖的起点。