从一到无穷大 #44：AWS Glue： Data integration + Catalog

本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。

本作品 (李兆龙博文, 由李兆龙创作)，由李兆龙确认，转载请注明版权。

文章目录

引言
Glue的历史，设计原则与挑战
[Serverless ETL 功能设计](#Serverless ETL 功能设计)
- [Glue Studio](#Glue Studio)
- [Glue ETL Library with DynamicFrames](#Glue ETL Library with DynamicFrames)
- [Serverless, Fast Startup, and Auto-scaling](#Serverless, Fast Startup, and Auto-scaling)
- 存储计算解耦与性能加速
[Catalog 和 Crawler 设计](#Catalog 和 Crawler 设计)
结束语

引言

在如今云产品赛道逐渐细分，如乐高积木一般的时代，时序数据库AP化于我而言带来的疑问是时间线爆炸场景下时序数据库的必要性何在？

一般的AP架构组件基本如下：

S3 + ETL + RedShift
S3 + Catalog（Glue or HiveMetaStore） + Athena or Presto

其实依赖现有组件搭建一个可用的，解决时间线爆炸问题的时序数据库非常容易，把数据打包成Parquet直接基于指定前缀格式写入到S3，Glue的爬虫直接识别Schema格式写入到Glue Catalog，上层直接用Presto或Athena这样的AP引擎直接查，如果再给S3做一层缓存加速，类似于ElastiCache[11]和腾讯云GooseFS，基本上性能不会有特别大差别，因为时间线爆炸也没有上倒排索引的必要（不管是Fst还是哈希结构都存在膨胀）。

现在看来，时间线形态的引擎其实有其存在的必要性，其次双引擎也是必要的。

回到论文来，Glue官方的定义是Data integration cloud service，我第一次认识到Glue其实是因为其一统了AWS的元数据管理市场，可以作为Hive，Trio，Spark，Athena的Catalog模块用于查询服务，但在研究了论文后，发现Glue其实是一个巨无霸系统，其至少包括以下重量级功能：

Glue Studio：允许用户以可视化方式创建ETL脚本
Glue ETL ：Glue Runtime中的Dynamic Frame和Parquet Writer保证了其性能高于Spark，ChoiceType确保其可以优雅解决单字段类型冲突；独特的资源管理器和WarmPool保证了Serverless的快启动和自动扩展；Decoupling Storage for Cloud Shufle可以降低用户的Worker使用量从而降低成本；
Glue Data Quality[12]：用于检测数据湖中的数据质量， It automatically computes statistics, recommends quality rules, and can monitor and alert you when it detects missing, stale, or bad data.
Glue Data Catalog：基本兼容HiveMetaStore的Catalog服务
Glue Crawler：Classifers推断文件的识别文件的类型和Schema，Finalizer负责基于前缀的相似性自动化识别Table与Partition
Glue DataBrew[13]：Data preparation工具，允许250多种预构建转换中进行选择，不需要写一行代码，看起来是ETL的上层封装

论文中重点放在了三个点：

Glue的历史，设计原则与挑战
Serverless ETL 功能设计
Catalog 和 Crawler 模块设计

这篇文章也从这三个点去做分析

Glue的历史，设计原则与挑战

Glue由2016年推出，随着数据类型和数据种类的激增，用于查询这些数据的系统层出不穷，但是缺乏简单的数据 discover, prepare 和 ETL工具。

开始时的设计约束如下：

第一条原则是为客户提供自助服务，让他们在系统出现问题时自行解决。例如，我们让客户可以轻松编写代码来定制他们的 ETL 管道，或直接编辑服务生成的脚本以满足他们的用例。
分析环境的异构性越来越强，不可能总是定义单一的数据模型、类型系统或查询语言来支持所有用例。Glue并不要求客户在开始使用之前将数据标准化，而是让他们使用现有的数据，即使这些数据不能在所有地方使用，这样他们就可以逐步采用 Glue 来处理新的应用和用例。
尽量减少无差异的工作，虽然我客户都是开发人员，但他们并不想花时间管理基础设施。

基本是以用户的易用性为设计原则。

以前的ETL系统有如下问题：

Data Discovery and Ingest：相同的数据项在不同的问题之间存在类型不一致；与外部系统集成时需要解决各种网络隔离问题与鉴权问题；不同的源系统扩展性不同，需要客户自己限制ETL的速率防止源系统过载；
Reliable Data Processing：可靠性十分重要，因为数据规模总会发生变化，因为一般测试使用的数据集远小于现网，会因为ETL机器内存或磁盘耗尽而失败；
Output and Physical Layout：数据本身在S3这样的系统，为了查询时的分区裁剪，需要工具去管理分区，并在不均衡时重新分区；

Serverless ETL 功能设计

基本分为下面几个方面：

Glue Studio

为了让用户更容易开始使用 AWS Glue，Glue为 ETL 脚本构建了一个可视化 ETL 界面和代码生成机制。核心依赖于将 ETL 脚本作为 DAG。

上图显示了一个使用 Glue Studio UI 的示例，允许客户以可视化方式创建 ETL 脚本：

从S3 获取一个数据源
执行 ApplyMapping（用于restructure 或者 fatten nested objects）
将结果与Catalog中的一个表Join
将输出写入亚马逊 S3

Glue ETL Library with DynamicFrames

与传统Spark需要两次遍历（Schema推断+数据处理）不同，DynamicFrames通过延迟Schema计算实现了单次遍历处理。如上图所示，在处理GitHub时间线数据（包含751个动态属性）时，Glue的过滤+Parquet写入任务耗时仅为Spark DataFrame的66%（136GB数据集）。

其次传统Spark DataFrames要求预先定义静态Schema，而Glue的DynamicFrame采用了完全不同的设计哲学。其核心数据结构DynamicRecord采用树状存储结构，每个记录内嵌自描述元数据，支持灵活的模式演进。在Schema推断过程中，Glue引入了ChoiceType机制，能够自动识别字段的类型冲突（如某字段同时存在string和int类型值），并将其记录为联合类型。这种设计避免了传统Schema推断中的强制类型转换导致的数据丢失。

Serverless, Fast Startup, and Auto-scaling

Glue 1.0的集群冷启动需要等待完整集群（含Driver+Executors）的EC2实例分配，导致平均启动延迟超过8分钟（上图a），Glue 2.0引入分层资源池架构：

Warm Pool预测模型：基于时间序列分析预测各区域/可用区的实例需求，预分配Spark执行环境
动态分阶段启动：Driver优先启动后立即开始任务调度，Executor按需动态加入
Shuffle状态感知：通过扩展Spark的Shuffle Tracking机制，确保含中间状态的Executor不被提前终止

通过上述优化，Glue 4.0的作业启动P99延迟降至10秒内（上图b），支持秒级响应的交互式ETL开发。

存储计算解耦与性能加速

传统Spark Shuffle依赖本地磁盘存储中间数据，存在单点故障和扩展性限制。Glue的Cloud Shuffle Storage Plugin将中间结果写入S3，减少了用户的成本。

针对CSV/JSON解析的CPU瓶颈，Glue开发了C++原生向量化读取器

下面三点可以看论文：

Glue Workfows & Incremental Processing
Monitoring Pipelines and Data Quality
Connectivity for Data Integration

Catalog 和 Crawler 设计

随着客户越来越多地在亚马逊 S3 等数据存储中构建和管理持久性数据湖，他们需要发现和管理数据集元数据的机制。查询引擎需要模式和数据位置等元数据来规划和执行查询，而客户也依赖元数据在大型企业中进行数据发现和管理。传统数据库将这些元数据存储在内部目录中，但在数据湖环境中，许多引擎都可用于查询相同的数据集，因此元数据必须与查询引擎分离。

开源社区率先在这一领域推出了 Hive metastore[15]，它已成为 Hadoop 生态系统中元数据管理的事实标准。它为访问数据库、表和分区的元数据提供了一个通用接口，并得到 Apache Hive、Trino 和 Apache Spark 等开源查询引擎的广泛支持。虽然 Hive 元存储已被广泛部署并经过实践检验，但它也有一些局限性，使其不足以管理大型数据湖。首先，它成为数据湖管理员必须管理的另一个系统。Hive 元存储的标准实现使用关系数据库，客户需要负责元存储的配置、扩展和打补丁。此外，性能也是一个挑战，用户通常需要对大型 Hive 元存储进行分片，这又增加了一层复杂性。

论文中主要提到Catalog是Serverless且支持分区索引（允许用户把分区谓词下刷至Catalog）

Crawler逻辑上也好理解，Classifier做类型识别，Finalizer做Table与分区自动识别，为了实现自动化的核心假设是表中的分区可能具有相同或相似的模式，而两个不同表的模式可能有很大差异，以此分析不同路径的相似程度。

结束语

这篇文章的意义除了在于了解了一个新的云产品的设计理念和功能外，比较重要的一点是笃定了Catalog模块需要去适配开源协议[14][15][16]，否则就让对象存储上的数据无法被用户的其他查询引擎和ETL工具使用了

参考：