如何在Glue的create_dynamic_frame.from_options中针对DynamoDB避免全表扫描

我来帮你解决这个问题——你当前的参数配置没有正确触发DynamoDB的Query操作，导致Glue fallback到了全表Scan，这才引发了超时和高RCU的问题。下面是针对create_dynamic_frame.from_options的专属解决方案，完全不需要依赖boto3：

首先得明确几个关键的错误点，再给你正确的代码示例：

• 必须明确指定执行Query操作：Glue的DynamoDB连接器默认可能会使用Scan，你需要显式告诉它要执行Query，这是避免全表扫描的核心。
• 主键条件要用keyConditionExpression而非filterExpression：DynamoDB的Query操作要求分区键（PK）的条件必须放在keyConditionExpression里，filterExpression是用来过滤非主键属性的（而且是在Query结果返回后再过滤，完全不影响底层的查询范围）。你之前用filterExpression来指定PK，这会导致Glue无法正确识别主键查询条件，只能走Scan。
• expressionAttributeValues要传字典而非字符串：你之前把属性值序列化成了字符串，这会导致Glue解析失败，进而触发全表扫描，直接传递Python字典就可以了。

下面是修正后的完整代码：

dyf = glueContext.create_dynamic_frame.from_options(
    connection_type="dynamodb",
    connection_options={
        "dynamodb.region": region,
        "dynamodb.input.tableName": tablename,
        "dynamodb.operation": "query",  # 关键：明确指定执行Query操作
        "dynamodb.query.keyConditionExpression": f"prt_key = :pv",  # 主键条件必须用这个参数
        "dynamodb.query.expressionAttributeValues": {":pv": {"S": id}}  # 直接传递字典格式
    }
)
df = dyf.toDF()

执行这段代码后，你可以通过DynamoDB控制台的CloudWatch指标（比如ConsumedReadCapacityUnits）或者Glue的任务日志来验证：全表扫描应该被彻底避免，RCU消耗会大幅降低，任务超时的问题也会得到解决。

另外再提个小验证点：确保你的prt_key确实是表的分区键（PK），如果是排序键的话语法会有差异，但根据你的描述，这里应该没问题。

内容来源于stack exchange