使用 Amazon EMR、Amazon SageMaker 和 AWS Service Catalog 设置 Intuit 数据湖

Original URL:https://aws.amazon.com/blogs/big-data/provisioning-the-intuit-data-lake-with-amazon-emr-amazon-sagemaker-and-aws-service-catalog/

本文将分享 Intuit关于在 AWS 上运行数据湖的知识和建议。Intuit 数据湖由
Intuit 数据平台的多个团队构建与运营。感谢 Tristan Baker（首席架构师）、Neil Lamka（首席产品经理）、Achal Kumar（开发经理）、Nicholas Audo 和 Jimmy Armitage 提供的反馈和支持。

数据湖是一种集中的存储库，可以存储任何规模的各种结构化和非结构化数据。在 Intuit，创建大量原始数据非常容易。但是，一些更值得关注的挑战依然存在：

AWS 账户应如何组织？
应该使用哪种摄入方式？分析师将如何找到他们需要的数据？
数据应该存储在哪里？应如何管理访问？
需要采取哪些安全措施来保护 Intuit 的敏感数据？
该生态系统的哪些部分可以被自动化？

本文概述了 Intuit 采用的方法，但构建数据湖的方式很多（例如，AWS Lake Formation），这也非常重要。

我们将讨论在较高层面构建 Intuit 数据湖所包含的技术和过程，包括设置账户和资源所使用的整体结构与自动化等。请关注我们这个空间的未来动态，阅读由其他合作构建 Intuit 数据湖的团队和工程师发布的关于该系统特定方面的更详细博文。

架构

账户结构

数据湖通常采用hub-and-spoke模型，其中中心账户包含控制数据源访问权限的共享服务。在本文中，我们将hub账户称作中央数据湖（Central Data Lake）。

在此模式中，访问中央数据湖的权限被分配给名为“处理账户”（Processing Accounts）的spoke账户。此模型保持了最终用户之间的隔离，并允许在不同业务部门之间的划分账单。

维护两个生态系统的情况十分常见：分别为预生产 (Pre-Prod) 和生产 (Prod)。通过阻止预生产和生产之间的连接，数据湖管理员可以对数据进行单独访问。

为了进行实验和测试，建议在预生产账户内维护基于独立VPC 的环境，如 dev、qa 和 e2e。然后，处理账户 VPC 将连接到中央数据湖中的对应 VPC。

请注意，首先，我们使用 VPC对等连接连接账户。但随着扩展，我们很快就会达到 125 个 VPC 对等连接的硬性限制，这使得我们迁移至 AWS Transit Gateway。在撰写这篇博文时，我们每周都会连接多个新的处理账户。

中央数据湖

在hub账户中可能运行着很多服务，但我们将重点关注与本博文最密切相关的几个方面：摄入、清理、存储和数据目录。

摄入、清理和存储

中央数据湖的关键组成部分是对流式数据的统一摄入模式。一种示例的实现方式是在 Amazon EC2 上运行的 Apache Kafka 集群。（您可以阅读另一篇 AWS 博客了解 Intuit 工程师在这方面的实现方式）在处理数百个数据源时，我们已启用通过 AWS PrivateLink 访问摄入机制的功能。

注意：Amazon Managed Streaming for Apache Kafka (Amazon MSK) 是在 Amazon EC2 上运行 Apache Kafka 的替代方式，但在Intuit 迁移开始时该服务还没有发布。

除了流处理之外，另一种摄入方式是批处理，例如在 Amazon EMR 上运行的作业。在使用这些方式摄取数据后，可以将其存储在 Amazon S3 中进行进一步的处理与分析。

Intuit 处理大量客户数据，并且仔细考虑每个字段，并按照敏感级别对其进行分类。所有进入数据湖的敏感数据在源头就被加密。提取系统会检索加密数据，并将其移入数据湖。在将数据写入 S3 之前，使用专有的 RESTful 服务对此类数据进行清理。在数据湖中执行操作的分析师和工程师会使用这些屏蔽数据。

数据目录

数据目录是为最终用户提供关于数据及其所在位置信息的常见方式。其中一个示例是由 Amazon Aurora 提供支持的 Hive Metastore 。另一个替代方式是 AWS Glue 数据目录。

处理账户

当处理账户被交付给最终用户时，它们包含一系列相同的资源。我们将在下文讨论处理账户的自动化，但主要的组成部分如下：

通过 Transit Gateway 连接到中央数据湖
用于通过SSH访问 Amazon EMR 集群的堡垒主机
IAM 角色、S3 存储桶和 AWS Key Management Services (KMS) 密钥
使用配置管理工具的安全框架
支持对 Amazon EMR 和 Amazon SageMaker 进行预置的 AWS Service Catalog 产品

交付给客户时处理账户的结构

数据存储机制

一个合理的问题是，是否所有数据都应该存储在中央数据湖吗，或者在多个账户分布数据是否可被接受？数据湖可以同时采用两种方法的组合，并将数据位置分类为主要或次要。

中央数据湖是数据的主要位置，数据通过上文讨论过的摄入管道被传送到这里。处理账户可以通过直接从摄入管道或从 S3 对主要源进行读取。处理账户可以将经其转换后的数据重新贡献到（主要）中央数据湖，或将其存储于自己的账户（次要）。正确的存储位置取决于数据的类型，以及需要用到这些数据的使用者。

不允许跨账户写入是一条应该被执行的规则。换句话说就是，IAM 主体（在大多数情况下为，由 EC2 通过实例配置文件代入的 IAM 角色）必须和目标 S3 存储桶属于相同的账户。这是因为不支持跨账户授权—具体来说，中央数据湖中的 S3 存储桶政策无法授予处理账户 A 访问由处理账户 B 中的角色写入对象的权限。

另一种可能是，由 EMR 通过自定义凭证提供者代入不同的 IAM 角色（参见 AWS 博客），但我们没有选择这条路线，因为Intuit需要重写很多 EMR 作业。

数据访问模式

大多数最终用户都需要访问位于 S3 中的数据。在中央数据湖和部分处理账户中，可能存在一系列只读 S3 存储桶：数据湖生态系统中的任何账户都可以从此类型存储桶中读取数据。

为了简化对只读存储桶的S3 访问管理，我们构建了一种控制 S3 存储桶政策的机制，这种机制完全通过代码进行管理。我们的部署管道采用账户元数据以基于账户的类型（Pre-Prod 或 Prod）动态生成正确的 S3 存储桶政策。这些政策会被提交回我们的代码存储库，以实现可审计性并且易于管理。

我们利用相同的方法管理 KMS 密钥策略，因为我们使用 KMS 和客户管理的客户主密钥 (CMK) 对S3 中的数据进行静态加密。

如下是为只读存储桶生成的 S3 存储桶策略的示例：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ProcessingAccountReadOnly",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::111111111111:root",
                    "arn:aws:iam::222222222222:root",
                    "arn:aws:iam::333333333333:root",
                    "arn:aws:iam::444444444444:root",
                    "arn:aws:iam::555555555555:root",
                    ...
                    ...
                    ...
                    "arn:aws:iam::999999999999:root",
                ]
            },
            "Action": [
                "s3:ListBucket",
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::intuit-data-lake-example/*",
                "arn:aws:s3:::intuit-data-lake-example"
            ]
        }
    ]
}

请注意，我们会在账户级别授予访问权限，而不是使用显式的 IAM 主体 ARN。因为读取是跨账户的，所以处理账户中的 IAM 主体也需要权限。在这种粒度级别上对此类策略进行自动化维护不大可行。此外，使用特定的 IAM 主体 ARN 可能对外部账户产生外部依赖关系。 例如，如果处理账户删除了在中央数据湖的 S3 存储桶策略中引用的 IAM 角色，将无法再保存存储桶策略，从而导致部署管道的中断。

安全性

对于任何数据湖来说，安全性都是至关重要的。我们将提到所使用控件的子集，但不会做深入讨论。

加密

可以通过多种方式在传输时和静态进行强制加密：

数据湖中的流量应使用最新版本的 TLS（在写作本文时是 1.2）
数据可以使用应用程序级（客户端）加密进行加密
KMS 密钥可被用于 S3、EBS 和 RDS 的静态加密

入栈和出栈

我们为入栈和出栈采取的方法并不特殊，非常值得一提的是，我们发现重要的标准模式：

将堡垒主机和安全组配合使用，将 SSH 流量限制在适当的 CIDR 范围
通过网络访问控制列表 (ACL) 避免多余的的数据传入
通过 VPC 终端节点将访问路由到 S3 存储桶，以避免其通过公共互联网

限制入栈和出栈的策略是数据湖可以保证质量（入栈）并防止数据丢失（出栈）的主要方面。

授权

通过 IAM 角色控制对 Intuit 数据湖的访问，这意味着不会创建任何（具有长期凭证的）IAM 用户。最终用户会通过内部服务被授予访问权限，而该内部服务则对基于角色的 AWS 账户联合访问进行管理。定期进行审核，以删除不必要的用户。

配置管理

我们使用 Cloud Custodian 的内部分支，它是一整套预防、检测和响应式控件，由 Amazon CloudWatch Events 和 AWS Config 规则组成。它会报告并（可选）缓解的一些违规行为包括：

入站安全组规则中的未经授权 CIDR
公有 S3 存储桶策略和 ACL
IAM 用户控制台访问
未加密的 S3 存储桶、EBS 卷和 RDS 实例

最后，所有 Intuit 数据湖账户中都会启用 Amazon GuardDuty，并由 Intuit Security 加以监控。

自动化

如果说我们在构建 Intuit 数据湖时有什么收获的话，那就是要对一切进行自动化。

在本博文中，我们将讨论四个领域的自动化：

创建处理账户
处理账户编排管道
处理账户 Terraform 管道
通过 Service Catalog 进行 EMR 和 SageMaker 部署

创建处理账户

创建处理账户的第一步是通过内部工具发起请求。这会触发自动化，对正确业务部门下带有 Intuit 标记的 AWS 账户进行设置。

注意：AWS Control Tower 的账户工厂在我们刚开始这段旅程时还没有发布。但您可以利用它以安全、符合最佳实践的自助式方式对新的 AWS 账户进行设置。

账户设置还包括自动化的 VPC 创建（带有可选 VPN），以及使用 Service Catalog 实现完全自动化。最终用户只需指定子网大小即可。

另外值得一提的是，Intuit 可利用 Service Catalog 自助部署其他常见的模式，包括入栈安全组、VPC 终端节点和 VPC 对等连接。以下是一个示例产品组合：

处理账户编排管道

在创建账户并对 VPC 进行设置后，处理账户编排管道将会运行。此管道会执行处理账户所需的一次性任务。这些任务包括：

引导IAM 角色以用于进一步的配置管理
为 S3、EBS 和 RDS创建 KMS 加密密钥
为新账户创建变量文件
使用账户元数据更新主配置文件
生成脚本以编排下文要讨论的 Terraform 管道
通过 Resource Access Manager 分享 Transit Gateway

处理账户 Terraform 管道

该管道管理动态且经常更新的资源的生命周期，包括 IAM 角色、S3 存储桶和存储桶策略、KMS 密钥策略、安全组、NACL 以及堡垒主机。

每个处理账户都有一条管道，而且每条管道都会使用一组参数化部署作业在账户中部署一系列层。层是 Terraform 模块和 AWS 资源的逻辑分组，在需要重新部署特定资源时提供一种方式以缩小 Terraform 状态文件和爆炸半径。

通过 Service Catalog 进行 EMR 和 SageMaker 部署

AWS Service Catalog 简化了Amazon EMR 和 Amazon SageMaker 的设置，允许最终用户通过嵌入式安全方式启动即用型EMR 集群和的 SageMaker Notebook实例。

Service Catalog 让数据科学家和数据工程师可以采用自助式方式和用户友好的参数启动 EMR 集群，并为他们提供以下各项服务：

引导操作，以便与中央数据湖中的服务实现连接
EC2 实例配置文件，以控制 S3、KMS 和其他细粒度权限
可启用静态和传输时加密的安全配置
配置分类，以实现最佳 EMR 性能
启用监控与日志记录的加密 AMI
自定义 Kerberos 连接至 LDAP

对于 SageMaker，我们使用 Service Catalog 以启动具有生命周期配置的Notebook实例，以设置连接或初始化以下各项：Hive Metastore、Kerberos、安全性、Splunk 日志记录和 OpenDNS。您可以参考该 AWS 博文，以了解关于生命周期配置的更多信息。启动具有最佳实践配置的 SageMaker Notebook实例非常简单，具体方式如下：

结论

本文介绍了我们用于创建 Intuit 数据湖的构建模块。我们的解决方案并不独特，它由从数十位 Intuit 工程师那里收集的常识性方法构成，代表着我们的数十年经验。这些做法让我们能够将 PB 级数据推送到数据湖，以满足数百个处理账户的各种需求。我们还在继续努力，但希望我们的经历可以在您构建数据湖的过程中为您提供帮助。

本博文中的内容和意见属于第三方作者，AWS 不对本博文的内容或准确性负责。

关于作者

Michael Sambol 是 AWS 的一名高级顾问。他拥有佐治亚理工学院计算机科学硕士学位。Michael 喜爱健身、打网球、旅游和观赏西方电影。

Ben Covi 是 Intuit 的一名软件主管工程师。 他在玩 Catan 游戏时从来就没有赢过。

亚马逊AWS官方博客