如何提高AWS Glue服务Data Catalog的payload限制并解决相关报错

你遇到的Payload size of request exceeded limit报错触发原因是AWS Glue服务的硬限制：Glue CreateTable API单次请求的payload最大上限为10MB。
当你爬取大容量DynamoDB表时，Glue爬虫默认会抽样扫描表内数据推断Schema，如果表的稀疏字段多、嵌套结构复杂，或是存在动态生成的字段名，爬虫推断出的Schema元数据体量会大幅膨胀，最终调用CreateTable接口写入Glue Catalog时请求体超过10MB限制，就会抛出你在CloudTrail中查到的InvalidInputException错误。小容量表因为抽样数据覆盖的字段少，Schema元数据体积小，所以可以正常执行。

• 调整爬虫抽样配置：调低Glue爬虫的DynamoDB数据抽样比例或抽样行数上限，默认配置为扫描前0.5%数据或前1000行数据，你可以根据业务需求将抽样行数限制调整为100~200行，或把抽样比例调低到0.1%及以下，减少爬虫识别到的冷门稀疏字段数量，缩小Schema体积。
• 手动预创建Glue Catalog表：提前按照业务需要的字段定义好表结构，在Glue Catalog中手动创建对应DynamoDB源的表，再配置爬虫时关闭自动新增字段的功能，仅让爬虫刷新元数据信息，不修改表结构，避免触发大体积的CreateTable请求。
• 优化DynamoDB表结构：如果你的表存在大量动态生成的字段名（例如用用户ID、时间戳作为顶层字段名），爬虫会将每个动态键识别为独立字段导致Schema爆炸，你可以调整表结构，将动态键值对收敛到固定的嵌套字段下，从源头减少Schema的字段数量。
• 拆分Schema更新逻辑：如果确实需要保留全量字段的元数据，你可以拆分任务，先通过爬虫生成核心字段的基础表，再通过Glue API分批补充剩余字段的元数据，避免单次请求payload超限。

内容的提问来源于stack exchange，提问作者Miguel Rueda