Claimforce为何使用湖仓统一数据湖和数据仓库？

Claimforce为何使用湖仓统一数据湖和数据仓库？

在 Claimforce，我们最初的大数据方法是一个两层架构，包括 Amazon S3 中的数据湖阶段和 Amazon Redshift 中的数据仓库阶段（此处概述）。随着时间的推移，我们意识到拥有两个阶段会带来一些缺点，例如工程和维护工作、基础设施成本和数据陈旧。我们的目标是用一个统一的系统——Lakehouse 来取代数据湖和数据仓库的组合。
在本博客系列中，我们将记录我们的 Lakehouse 设置之旅。

介绍
在 Claimforce，我们的使命是创造出色的理赔体验。我们相信，可以利用数据来支持人类决策者，并在理赔领域创造完美的人机界面。正因为如此，我们不断质疑和重申我们的大数据基础设施，这是完成我们使命的所有模型和算法的基础。
在这篇文章中，我们想要鸟瞰。首先概述我们当前的两层架构，然后概述我们面临的挑战。然后我们介绍了新的 Lakehouse 架构，并讨论了它的优缺点。总结一下我们用于实现的具体技术集。本系列的其余部分将介绍这些具体技术。

我们的现状——两层分析数据架构
我们当前的数据架构包括两个阶段——数据湖和数据仓库。
我们在Amazon S3之上实现了一个数据湖。我们的操作系统将他们的数据卸载到这个阶段。在该阶段也会执行基本的转换，例如列重命名和日期标准化。
数据湖架构范式具有多个优点：

• 它基于 S3 构建，利用了服务的优势，例如低存储成本、无限无缝可扩展性、高持久性和可用性。
• 我们使用 ETL 作业从数据湖写入数据，并将存储和计算分开。这使我们能够单独扩展这两个方面，使我们能够更好地响应负载峰值并降低成本。
• 由于 File-Storage 不需要模式，我们可以将任何文件写入 S3，然后确定我们要使用哪个模式读取它（Schema-on-Read）
• 数据湖支持所有数据格式（也包括照片和视频等非结构化数据）

但是，数据湖阶段也有一些缺点：

• 对大量数据执行聚合时查询性能低
• 没有 ACID 事务
• 仅追加写入数据的样式。添加新的数据记录很容易。为了能够更新现有记录，有必要删除数据并对所有数据重新运行 ETL 脚本。

为了弥补数据湖阶段的缺点，我们在数据基础架构中添加了第二个阶段——数据仓库。我们使用了 Amazon 的数据仓库实施Redshift。这使我们能够更新现有行、执行 ACID 事务并有效地查询大量数据。
将这两个数据架构层结合起来解决了我们的一些问题，因为它们可以弥补彼此的弱点。然而，集成这两个系统会产生一系列新问题。

首先，我们面临着越来越多的维护工作，因为有两种不同类型的基础设施。此外，还需要为运行中的 Redshift 集群付费，因为计算和存储没有分离，这比将数据存储在像 S3 这样的分布式文件系统中要昂贵得多。
在内部，像 Redshift 这样的数据仓库使用针对大量数据的分析查询优化的专有数据格式。但是，从外部提取这些数据需要通过 JDBC/ODBC 进行查询，效率非常低。无法直接访问存储在数据仓库中的数据。
由于我们的机器学习用例需要对位于数据仓库中的精炼数据集进行处理，不幸的是，它成为了瓶颈并严重减慢了我们机器学习模型的开发周期。

我们想要的状态——The Lakehouse
Michael Armbrust 等人已经描述了我们在数据基础设施方面遇到的挑战。在他们的论文“ Lakehouse：统一数据仓库和高级分析的新一代开放平台”中。” 为了解决这些问题，他们提出了一种统一数据湖和数据仓库的架构类型——The Lakehouse。

Delta Lake、Apache Iceberg或Apache Hudi等开源库允许实现事务元数据层，启用ACID事务、更新插入和版本控制，同时将数据保留在现有 Data Lake 中。这允许具有 DWH / DBMS 的优势，数据位于低成本对象存储中，将存储与计算分离。
此外，这些框架使用现有的开源数据格式，如 parquet，使人们能够直接在文件之上进行机器学习，无需额外的反向 ETL。

我们的决定——Delta Lake + AWS Athena
在比较了 Iceberg、Hudi 和 Delta Lake 之后，我们决定使用Delta Lake（我们强烈推荐阅读 Michael Armbrust 等人的论文Delta Lake：High-Performance ACID Table Storage over Cloud Object Stores）。
这些是原因：

• Spark集成很棒
• 三个框架中最年轻但已经成熟的框架
• 快速发展的社区
• 由 Databricks 提供支持

我们相信不存在一刀切的框架，每个人都应该根据自己的用例决定使用什么。有一些很棒的比较文章，我们将在文章底部链接。
作为我们在 Lakehouse 之上的查询引擎，我们现在选择使用 AWS Athena，因为我们已经将它用于临时分析查询，而且价格便宜，每 TB 5 美元。选择 Athena 有一些缺点：

• 不幸的是，Athena 还没有与 Delta Lake本地集成。Athena 无法读取增量日志，只能读取表的最新状态。因此它只能为 Delta Table 提供一个只读接口。Athena不支持更新、时间旅行或真空等增量功能。
• Athena 无法像自我管理的 Presto/Trino 集群那样扩展；您最终将达到性能限制，并且资源可能暂时不可用。

这标志着我们旅程的第一部分结束，远离传统的数据仓库，完全拥抱 Lakehouse。