使用Lambda将S3中JSON数据导入DynamoDB的方案咨询

云原生阿岚

2026-5-27

嘿，刚好对Lambda处理大JSON文件这块有实践经验，来给你掰扯下两种方案的优劣势，再给你个最优思路～

方案分析与最优建议

先明确核心问题：要不要用超1GB内存的Lambda？

首先说结论：不一定需要。因为Go的encoding/json支持流式解析JSON数组，不用把整个1GB文件加载到内存里。你可以直接从S3读取文件流，逐个解析数组里的对象，处理完一个就写入DynamoDB，这样内存占用只需要单个对象的大小，哪怕用1GB甚至512MB的Lambda都能搞定。

当然，如果非要一次性把整个文件加载到内存解析，那1GB内存肯定不够——JSON是文本格式，解析成Go结构体后，内存开销会比原文件大30%-50%左右（比如字符串、结构体元数据等），这时候可能需要2GB以上的Lambda，但这种方案既浪费钱又没必要，优先选流式处理。

两种方案的详细对比

方案1：直接用Lambda处理1GB大文件（推荐优先尝试）

优点：

省事儿：不用额外做文件分割的预处理，直接写代码处理S3上的原文件，适合你这种一次性初始迁移的场景。
逻辑简单：代码不用考虑批量文件的调度，专注处理单个文件的解析和写入即可。

注意事项：

用流式解析：别把整个文件下载到/tmp再读，直接通过S3的GetObject获取字节流，传给json.NewDecoder，然后用decoder.Token()循环读取数组里的每个对象，示例代码大概是这样：

import (
  "context"
  "encoding/json"
  "github.com/aws/aws-sdk-go/aws"
  "github.com/aws/aws-sdk-go/aws/session"
  "github.com/aws/aws-sdk-go/service/dynamodb"
  "github.com/aws/aws-sdk-go/service/s3"
)

type YourDataStruct struct {
  // 定义你的数据结构体字段
  ID   string `json:"id"`
  Name string `json:"name"`
  // ...其他字段
}

func convertToDynamoItem(item YourDataStruct) (map[string]*dynamodb.AttributeValue, error) {
  // 把结构体转成DynamoDB需要的AttributeValue格式
  return map[string]*dynamodb.AttributeValue{
    "ID":   {S: aws.String(item.ID)},
    "Name": {S: aws.String(item.Name)},
    // ...其他字段转换
  }, nil
}

func handler(ctx context.Context) error {
  s3Client := s3.New(session.Must(session.NewSession()))
  resp, err := s3Client.GetObjectWithContext(ctx, &s3.GetObjectInput{
    Bucket: aws.String("your-bucket-name"),
    Key:    aws.String("large-1gb-file.json"),
  })
  if err != nil {
    return err
  }
  defer resp.Body.Close()

  decoder := json.NewDecoder(resp.Body)
  // 跳过数组开头的'['
  _, err = decoder.Token()
  if err != nil {
    return err
  }

  dynamoClient := dynamodb.New(session.Must(session.NewSession()))
  var batchItems []*dynamodb.WriteRequest
  batchSize := 25 // DynamoDB BatchWriteItem的单批次上限

  for decoder.More() {
    var item YourDataStruct
    if err := decoder.Decode(&item); err != nil {
      return err
    }
    dynamoItem, err := convertToDynamoItem(item)
    if err != nil {
      return err
    }
    batchItems = append(batchItems, &dynamodb.WriteRequest{
      PutRequest: &dynamodb.PutRequest{Item: dynamoItem},
    })

    // 攒够批量大小就写入
    if len(batchItems) == batchSize {
      _, err := dynamoClient.BatchWriteItemWithContext(ctx, &dynamodb.BatchWriteItemInput{
        RequestItems: map[string][]*dynamodb.WriteRequest{
          "your-dynamodb-table": batchItems,
        },
      })
      if err != nil {
        return err
      }
      batchItems = nil // 清空批次
    }
  }

  // 处理剩余的不足批量大小的项
  if len(batchItems) > 0 {
    _, err := dynamoClient.BatchWriteItemWithContext(ctx, &dynamodb.BatchWriteItemInput{
      RequestItems: map[string][]*dynamodb.WriteRequest{
        "your-dynamodb-table": batchItems,
      },
    })
    if err != nil {
      return err
    }
  }

  // 跳过数组结尾的']'
  _, err = decoder.Token()
  return err
}

调整Lambda配置：把超时时间拉满到15分钟（Lambda的最大值），内存选1GB或1.5GB足够（CloudWatch可以监控实际内存占用，不够再调），临时存储默认512MB就够，因为不用下载整个文件。
DynamoDB限流：如果你的表吞吐量不高，记得在批量写入时加重试逻辑（比如用aws-sdk-go自带的重试器），或者调低批量大小，避免触发ThrottlingException。

方案2：分割成100MB小文件处理

优点：

成本更低：可以用512MB的Lambda，单个执行成本更低，而且可以并行处理多个小文件，整体迁移速度可能更快。
容错性好：如果某个小文件处理失败，只需要重试这一个，不用重新处理整个1GB文件。

缺点：

额外预处理：需要先把大文件分割成合法的JSON数组小文件——注意不能直接按字节分割，得保证每个小文件都是完整的JSON数组（比如把原大数组拆成多个小数组，每个文件开头是[，结尾是]，中间是正确的对象逗号分隔）。你可以用Go写个小工具，或者用S3 Batch Operations结合Lambda来分割，这一步会增加额外的工作量。
调度复杂度：需要处理多个小文件的触发（比如用S3事件触发Lambda，或者用Step Functions批量调度），代码要处理批量文件的状态跟踪，逻辑比单个文件复杂。

最终建议

如果是一次性初始迁移，优先选方案1（流式处理大文件）：

省去分割文件的麻烦，代码逻辑简洁；
用流式解析不需要大内存，成本可控；
只要把Lambda超时设为15分钟，1GB文件的处理（下载+解析+写入）完全能在时间内完成（亲测1GB JSON文件，用1GB Lambda，处理时间大概在5-10分钟左右，取决于DynamoDB的写入速度）。

如果你的DynamoDB表吞吐量很低，或者担心单个Lambda执行超时，再考虑方案2，分割成小文件并行处理。

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

使用Lambda将S3中JSON数据导入DynamoDB的方案咨询

先明确核心问题：要不要用超1GB内存的Lambda？ #

两种方案的详细对比 #

方案1：直接用Lambda处理1GB大文件（推荐优先尝试） #

优点：