AWS Lambda传入StreamingBody到gzip.open触发TypeError问题求助

错误原因 #

你碰到的问题根源很清晰：gzip.open() 仅接受文件路径、字节串或类路径对象作为输入，但S3返回的csv_object["Body"]是StreamingBody类型的字节流对象，直接传入自然会触发TypeError。

另外你最初的代码处理大文件时无限运行，本质是因为逐行将内容拼接进变量，会把整个文件加载到内存，导致Lambda内存耗尽、超时。

解决方案 #

改用gzip.GzipFile替代gzip.open()，它支持直接传入字节流对象作为fileobj参数；同时采用分块读取的方式更新哈希，避免内存溢出：

import hashlib
import gzip
import boto3

def lambda_handler(event, context):
    s3 = boto3.client('s3')
    # 替换为你的存储桶名称和文件键
    csv_object = s3.get_object(Bucket='your-bucket-name', Key='target-file.csv.gz')
    sha512 = hashlib.sha512()
    
    # 用GzipFile包装S3的StreamingBody
    with gzip.GzipFile(fileobj=csv_object["Body"], mode='rb') as gz_file:
        # 分块读取（每次8KB，可按需调整块大小）
        chunk_size = 8192
        while chunk := gz_file.read(chunk_size):
            sha512.update(chunk)
    
    calculated_hash = sha512.hexdigest()
    # 此处添加与预期哈希值对比的逻辑
    print(f"计算得到的SHA512哈希: {calculated_hash}")
    return calculated_hash

关键说明 #

• gzip.GzipFile的fileobj参数兼容任何实现了read()方法的类文件对象，完美适配S3的StreamingBody。
• 分块读取的方式既避免了一次性加载大文件到内存（Lambda内存配额有限），也解决了最初代码逐行拼接导致的超时问题。

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