我计划利用 AWG Glue 进行增量数据处理。基于每小时计划，触发器将调用 Glue Crawler 和 Glue ETL Job，后者将增量数据加载到目录并通过 ETL 处理增量文件。而且看起来也很直截了当。有了这个，我遇到了几个问题。
假设我们将各种表和各种数据库的数据流式传输到 S3 位置，并且我们希望基于登陆数据创建数据库和表。例如： s3://landingbucket/ database1 / table1 /YYYYMMDDHH/some_incremental_files.json s3://landingbucket/ database1 / table2 /YYYYMMDDHH/some_incremental_files.json s3://landingbucket/ database1 /somedata/ tablex /YYYYMMDDHH/some_incremental_files.json s3 ://landingbucket/ database2 / table1 /YYYYMMDDHH/some_incremental_files.json s3://landingbucket/ datasource_external /data/table1/YYYYMMDDHH/some_incremental_files.json
随着数据进入上述 s3 结构，我们希望为这些数据库和具有有限爬虫的表创建粘合目录。这里我们有数据库数量作为爬虫的数量。注意：我们有一个database1的爬虫，它在database1下创建表，这很好并且符合预期，但是我们在database1中有一个特殊的家伙“somedata”，它的结构与其他表不标准，它创建了表somedata并使用分区“partitions_0=tablex 和 partition_1=YYYYMMDDHH”。有没有比每个数据库一个爬虫更好的方法来处理这些爬虫数量更少。
Glue ETL，我们有类似的挑战，我们希望将传入的数据格式化为标准 parquet 格式，并且每个数据库有一个存储桶，并且表将位于该存储桶下，因为数据量很大，我们不想要一个带有分区的表作为数据库和数据。这样我们就不会遇到传入负载的 s3 减速问题。由于许多团队将从这里查询数据，所以我们不希望他们的分析工作出现 s3 减速问题。
不是每个表，每个数据库都有一个 ETL 作业，有没有一种方法可以让我们用有限的作业来处理这个问题。当新表出现时，ETL 作业应该有一种方法应该将这个 json 数据转换为格式化区域。所以输入数据和输出路径都可以动态处理，而不是硬编码。
打开任何更好的主意！
谢谢，克里什！