DynamoDB 和 Redshift 都是 AWS 上再常见不过的服务但把两者做跨账号的数据同步以前要么靠 Spark ETL 脚本硬啃要么靠 Lambda 接 Firehose 再 COPY链路又臭又长。前段时间我刚好把一个跨账号的订单表同步需求从自建管道换成了 DynamoDB 到 Redshift 的零 ETL 集成整体替换比想象中顺利但配置过程中也踩了几个很隐蔽的坑尤其是跨账号下的 IAM 和 KMS 授权。这篇文章我会把完整配置过程、排查思路和注意事项都写出来给要做同样事情的人省点查文档的时间。不管你是刚接触 AWS 的工程师还是已经维护了好几条数据管道的老手这篇文章都适合你看。零 ETL 并不是玄学它只是把原来需要你写代码、搭调度、做重试的链路换成由云平台托管的集成服务。理解它的原理和限制后你会发现很多同步场景其实都可以不用再维护 Spark 脚本了。1. 零 ETL 集成到底解决什么问题1.1 先搞清楚零 ETL 是啥先说结论零 ETL 不是没有 ETL而是把 ETL 过程的“搬运部分”托管给了云厂商。DynamoDB 到 Redshift 的零 ETL 集成本质上是 AWS 提供的全托管数据管道。你只需要指定源 DynamoDB 表的 ARN再指定目标 Redshift 命名空间的 ARN平台会自动完成流读取、数据转换、写入目标表这一系列动作。这个集成依赖 DynamoDB Streams。DynamoDB 表开启流之后每一次增删改都会产生流记录零 ETL 集成服务会持续消费这些流记录按近实时的节奏把变更同步到 Redshift 的本地表中。你不需要搭建 Flink 任务不需要写 Spark ETL 脚本也不需要处理分片再平衡、checkpoint、失败重试这类琐碎问题。数据从源表产生到出现在 Redshift 目标表延迟通常在几十秒级别体感上就是“写完 DynamoDB 没多久Redshift 就能查到”。需要注意一点目标表在 Redshift 中是一张真实存在的本地表不是外部表也不是 S3 上的数据湖文件。数据真正落在 Redshift 存储里这意味着你可以直接对它跑标准 SQL 查询也可以在这张表之上建物化视图做进一步加工。表结构由集成服务自动创建通常包含一个 SUPER 类型的列来保存整个 DynamoDB 文档具体细节后面我会展开。1.2 和传统管道对比为什么值得换以前做同样的事最常见的方案是 DynamoDB Streams 触发 Lambda把数据写到 Kinesis Data FirehoseFirehose 落地到 S3再用 Redshift COPY 命令或者 Spectrum 做查询。这套链路能跑但你得维护的东西太多了Lambda 的超时和重试策略、Firehose 的缓冲间隔、S3 分区规划、COPY 脚本的调度与失败告警这些都要自己管。后来很多人改用 Spark ETL 脚本处理我之前的订单同步就是 Spark 写的。Spark 方案灵活性高能做复杂清洗和类型转换但问题在于它太重了。为了同步一个 DynamoDB 表你要准备 EMR 集群或 Glue 作业要处理流式消费和批次调度数据量小的时候纯粹是杀鸡用牛刀。而且跨账号场景下Spark 还需要访问源账号的数据流权限配置和网络打通又是一层额外工作量。零 ETL 集成把这些全砍掉了。不需要自己写管道代码数据以流的方式自动进入 Redshift没有单独的 ETL 工具要部署控制台里创建一条集成就完事运维维度也从“监控 Lambda 错误率、Firehose 积压、COPY 失败”收敛成“看一眼集成的状态是否 Active”。对大多数需要 DynamoDB 数据进入仓库做分析的业务来说这个方案在延迟、成本和维护复杂度上都是更优解。当然它也不是万能若你需要多表关联后做复杂清洗再落库那还是得在上层加转换层。1.3 跨账号场景的难点在哪跨账号是这次集成里最容易出问题的地方。集成本身创建起来很快但前置权限如果没配好状态会一直在 Failed 和 Retry 之间徘徊。核心难点有三个第一源端 DynamoDB 表在账号 A目标端 Redshift 在账号 B读取 DynamoDB 流的角色却要在账号 B 里创建这就涉及跨账号 IAM 授权。角色要能对账号 A 的表做 DescribeTable、DescribeStream、GetRecords 这类操作资源 ARN 必须精确指向源表及其 stream 子资源。第二如果源表或目标端用了 AWS KMS 客户管理密钥加密跨账号使用密钥需要同时修改两个密钥的 key policy。只给目标端授权还不够源端 DynamoDB 表使用的 KMS key 也要显式允许账号 B 的角色来解密否则集成服务连流记录都读不出来。第三出问题之后排查起来比较费劲。跨账号场景下 CloudTrail 日志分散在两个账号里如果对 AWS API 调用不够熟悉很容易找到不到真正报错点。我后面会专门列一个故障排查章节把常见问题一次性说清楚。2. 前置准备资源和权限一次性捋清楚2.1 资源清单先列明白动手之前建议先把下面这些信息收集齐后面创建集成时可以少来回切换控制台。项目说明所在账号DynamoDB 表 ARN形如 arn:aws:dynamodb:region:account-a:table/orders账号 ADynamoDB 流 ARN形如 arn:aws:dynamodb:region:account-a:table/orders/stream/*账号 ARedshift 命名空间 ARN形如 arn:aws:redshift:region:account-b:namespace:uuidServerless 或 Provisioned 均可账号 B跨账号集成角色在账号 B 创建被集成服务代入读取账号 A 的流并操作 Redshift 目标账号 BKMS 密钥源表加密用的密钥和目标端加密用的密钥若自定义则需配置跨账号策略视配置而定除了 ARN还要确认账号 B 的 Redshift 命名空间能接受集成服务的访问。大部分时候只要 Redshift 处于可用状态、具备可达的端点就行。但如果 Redshift 被配置成完全私有没有公开端点就需要事先在 VPC 里创建好连接 Redshift 命名空间的接口端点并保证安全组放行集成服务来源。我建议在测试环境先把 Redshift 设为可访问再验证链路通了之后再收紧网络策略。2.2 源端DynamoDB 表与流的配置细节不是随便一张 DynamoDB 表都能用来建零 ETL 集成。源表必须满足几个基本条件。第一表必须启用 DynamoDB Streams而且 StreamViewType 要选 NEW_AND_OLD_IMAGES。这个视图类型会同时包含变更前和变更后的数据集成服务需要用它做幂等同步。如果你之前为了省钱选的是 KEYS_ONLY创建集成时会直接失败或者一直拉不到数据。我自己的表最开始就是 KEYS_ONLY排查了半天才发现问题出在这。第二源表必须是标准表。DynamoDB 的全局表、某些特定配置的表可能不被支持这点在官方文档里有约束创建集成时如果校验不通过也会提示。安全起见生产环境的主表一般都满足条件主要是测试时别拿那种开了一堆特殊功能的表来试。第三表的读写容量模式不影响集成但建议使用按量计费 PAY_PER_REQUEST。流读取不会消耗表的读取容量单元使用的是 DynamoDB Streams 自身的读取 API所以不用担心同步任务把表的读能力打爆。我这里给一个建表示例方便你对照检查配置aws dynamodb create-table \ --table-name orders \ --attribute-definitions \ AttributeNamepk,AttributeTypeS \ AttributeNamesk,AttributeTypeS \ --key-schema \ AttributeNamepk,KeyTypeHASH \ AttributeNamesk,KeyTypeRANGE \ --billing-mode PAY_PER_REQUEST \ --stream-specification StreamEnabledtrue,StreamViewTypeNEW_AND_OLD_IMAGES如果你表已经存在只需要改流配置用 update-table 命令调整 StreamSpecification 即可。2.3 目标端Redshift 命名空间与网络要求Redshift 这边相对简单。你只需要一个可用的命名空间可以是 Serverless 也可以是 Provisioned 集群。集成创建过程中需要选目标数据库名和关联的 IAM 角色之后 Redshift 会自动创建数据库和表不需要你在控制台里提前建库建表。网络方面大原则是“集成服务必须能够访问到 Redshift 命名空间”。Redshift Serverless 通常会有一个可达端点Provisioned 集群如果开启了公开访问也可以。如果集群完全私有就要在 VPC 中配置到 Redshift 命名空间的接口 VPC 端点并确保子网路由、安全组规则放行对应流量。我在测试时是先保持默认网络配置等集成变成 Active 之后再逐步收紧网络边界这样定位问题会更干净。还有一个细节跨账号场景下集成服务的创建请求是从账号 B 发出的目标 Redshift 也在账号 B因此你不需要在账号 A 里配置任何 Redshift 相关的网络授权。账号 A 只需要放开 DynamoDB 流的读取权限即可。2.4 跨账号 IAM 角色与 KMS 密钥策略这一节是整篇文章的核心也是最容易踩坑的地方。先建角色再配 KMS顺序不要搞反。在账号 B 中创建名为 zero-etl-cross-account-role 的 IAM 角色。信任关系要允许 Redshift 服务代入该角色标准 trust policy 如下{ Version: 2012-10-17, Statement: [ { Effect: Allow, Principal: { Service: [ redshift.amazonaws.com, redshift-serverless.amazonaws.com ] }, Action: sts:AssumeRole } ] }角色权限策略需要按最小权限原则写。读取 DynamoDB 流的部分资源要精确到源表的流子资源。Redshift 侧的操作则是指向账号 B 的命名空间。下面这个策略是我实际验证过可用的基线版本{ Version: 2012-10-17, Statement: [ { Sid: ReadDynamoDBStreamsCrossAccount, Effect: Allow, Action: [ dynamodb:DescribeTable, dynamodb:DescribeStream, dynamodb:GetRecords, dynamodb:GetShardIterator, dynamodb:ListStreams ], Resource: [ arn:aws:dynamodb:us-east-1:111122223333:table/orders, arn:aws:dynamodb:us-east-1:111122223333:table/orders/stream/* ] }, { Sid: UseRedshiftNamespace, Effect: Allow, Action: [ redshift:DescribeIntegration, redshift:DescribeInboundIntegrations, redshift:GetClusterCredentials ], Resource: * } ] }这里有个容易误解的点角色虽然创建在账号 B但它要访问的资源在账号 A。因此账号 A 侧的 DynamoDB 表还有一个隐藏前提——DynamoDB 允许跨账号 IAM 访问流。默认情况下只要角色有正确的权限策略且资源授权允许跨账号访问就能成立。不像 S3 那样还要额外配置 bucket policyDynamoDB 流读取主要看调用方角色权限。KMS 就麻烦一些。假设账号 A 的 DynamoDB 表使用了客户管理密钥 kms-key-ddb账号 B 的 Redshift 使用了 kms-key-rs。跨账号集成要求账号 B 的角色可以解密这两个密钥。在账号 A 的 KMS key policy 中需要加入类似下面的语句授权账号 B 的角色使用解密相关操作{ Sid: AllowZeroETLCrossAccountUse, Effect: Allow, Principal: { AWS: arn:aws:iam::444455556666:role/zero-etl-cross-account-role }, Action: [ kms:Decrypt, kms:GenerateDataKey, kms:ReEncryptFrom ], Resource: * }账号 B 的 KMS key policy 也要放行同一角色Action 里至少包含 kms:Decrypt 和 kms:GenerateDataKey。很多集成失败案例都是只改了一边导致集成服务无法解密日志记录或者流数据。建议创建完角色之后先用 CLI 手动验证一次跨账号读取再创建集成。3. 实操创建跨账号零 ETL 集成3.1 控制台创建步骤登录账号 B 的 AWS 控制台进入 Redshift 服务页面左侧菜单找到 Zero-ETL integrations点创建。源类型选择 DynamoDB然后填入账号 A 的 DynamoDB 表 ARN。这里必须用完整的 ARN 格式例如 arn:aws:dynamodb:us-east-1:111122223333:table/orders控制台会自动校验表是否存在以及是否满足集成条件。目标部分选择账号 B 下的 Redshift 命名空间。如果你有多个命名空间下拉框里会列出当前账号下所有命名空间选择之后还需要指定目标数据库名和集成角色。目标数据库名可以自定义我习惯用一个独立的数据库名比如 orders_dw这样后续如果要单独管理权限也比较清晰。关联角色选择刚才创建的 zero-etl-cross-account-role。如果 DynamoDB 表或 Redshift 启用了客户管理的 KMS 密钥控制台会要求指定相关密钥 ARN也可能要求填写加密配置。没有自定义密钥的话用默认的 aws/redshift 和 aws/dynamodb 密钥即可。填完所有配置点创建集成会进入创建中状态。正常情况下几分钟内状态会变成 Active如果一直是 Failed后面排查章节会讲到常见原因。3.2 用 AWS CLI 替代控制台操作习惯用命令行的同学可以直接通过 AWS CLI 创建。在账号 B 的终端执行下面的命令aws redshift create-integration \ --integration-name orders-to-redshift \ --source-arn arn:aws:dynamodb:us-east-1:111122223333:table/orders \ --target-arn arn:aws:redshift:us-east-1:444455556666:namespace:aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee \ --region us-east-1命令本身不复杂关键是 target-arn 必须是 Redshift 命名空间的 ARN。命名空间 ARN 可以在 Redshift 控制台的命名空间详情页看到也可以从 CloudFormation 输出里拿到。创建之后用 describe-integrations 查看状态aws redshift describe-integrations --integration-arn arn:aws:redshift:us-east-1:444455556666:integration:xxxxxx如果状态是 Active说明这条集成已经可用。暂停和恢复同样有对应命令pause-integration 和 resume-integration。生产环境切换时建议先暂停而不是直接删除等确认新管道稳定后再清理旧资源这样回滚成本最低。3.3 创建成功后如何验证数据集成状态 Active 不代表数据已经正确同步建议立刻做一轮端到端验证。先往 DynamoDB 表里写入一条测试数据aws dynamodb put-item \ --table-name orders \ --item { pk: {S: 1001}, sk: {S: 2025-01-01}, customer_id: {S: C1001}, amount: {N: 299.9}, status: {S: PAID} }然后打开 Redshift Query Editor v2执行SELECT data.pk, data.sk, data.customer_id, data.amount, data.status FROM orders_dw.public.orders LIMIT 10;如果一切正常你应该能在几十秒到一两分钟内查到刚才写入的数据。我实测的时候数据延迟一般在 30 秒以内比预想快。查询时需要注意data 是一个 SUPER 类型列访问嵌套属性要用点号语法MySQL 习惯的>CREATE MATERIALIZED VIEW orders_flat AS SELECT data.pk, data.sk, data.customer_id, CAST(data.amount AS DECIMAL(10, 2)) AS amount, data.status, data.order_time FROM orders_dw.public.orders WHERE data.amount IS NOT NULL;物化视图创建后会实时或高频刷新BI 工具查视图时体验会好很多。需要注意SUPER 类型的属性在返回时是 JSON 类型数值计算前建议用 CAST 转成 DECIMAL 或 INT避免隐式转换引发结果不符合预期。判空时用 IS NULL 或 IS NOT NULL不要把 JSON 里的 null 和 SQL 的 null 搞混。再进一步你完全可以在物化视图之上继续做统计查询比如按客户维度聚合订单金额SELECT customer_id, COUNT(*) AS order_cnt, SUM(amount) AS total_spend FROM orders_flat WHERE status PAID GROUP BY customer_id ORDER BY total_spend DESC;这套链路跑下来DynamoDB 里一有新订单Redshift 中很快就能在统计报表里看到。相比以前手动 COPY 到 S3 再做聚合效率和体验完全不是一个级别。4.3 监控指标与数据新鲜度集成并不是创建完就撒手不管了。控制台里 Zero-ETL integrations 页面会显示每条集成的健康状态正常是 Active异常时会变成 Failed 或 Paused。建议把集成的状态变化接入 AWS Health Dashboard 或者用 EventBridge 监听相关事件状态异常时能第一时间收到通知。数据新鲜度方面DynamoDB 零 ETL 集成一般是秒级到分钟级延迟具体取决于流分片数量和数据量。如果源表 TPS 非常高流分片增多集成服务会自动扩展消费能力延迟通常能保持稳定。不过延迟指标和同步行数等数据建议在 CloudWatch 里订阅查看。创建零 ETL 集成后Redshift 控制台会自动关联相关指标包括同步延迟、处理行数、错误计数等。我在生产环境会额外建一个看板把集成的状态、目标表的行数增长趋势放一起每周过一遍基本能做到问题早发现。5. 常见故障与排查实录5.1 集成失败场景速查表下面这张表是我实际项目和文档阅读过程中整理的常见问题基本都是配置层面的坑对照排查能省不少时间。现象可能原因处理方式集成一直处于 FailedDynamoDB Streams 未启用或视图类型不对检查流是否开启StreamViewType 必须为 NEW_AND_OLD_IMAGES创建集成时提示权限不足账号 B 的角色没有 DynamoDB 流读取权限在角色策略里加入 GetRecords、DescribeStream、GetShardIterator 等流读取被拒绝角色信任关系未包含 redshift 服务修改信任策略允许 Redshift 相关服务代入该角色KMS 解密失败密钥策略只授权了一个账号同时修改源端和目标端两个 KMS key policy目标表数据长时间不增长集成被暂停或流消费出现问题查看集成状态是否为 Active必要时暂停再恢复创建集成报错“表不支持”源表某些特殊配置与集成不兼容确认源表为标准表国际版区域通常都支持但仍需以校验结果为准5.2 我踩过的三个具体坑第一个坑就是 StreamViewType。最初我建表时开了流图省事选的 KEYS_ONLY想着反正只要主键就能定位数据。结果创建集成之后状态一直处于 Failed控制台也没有特别明显的错误提示最后翻 CloudTrail 才看到校验逻辑要求 NEW_AND_OLD_IMAGES。这个坑非常隐蔽因为表确实开了流只是视图类型不对。如果你遇到集成创建后卡住不动先检查流的视图类型十有八九是这个问题。第二个坑是 KMS 跨账号授权只做了一半。我的源表和目标端都用了自定义加密密钥最开始只在账号 B 的 key policy 里加了角色授权账号 A 的 key policy 一直没动。结果集成创建之后几乎每隔几分钟就会报一次 KMS 权限错误。后来在两个 key policy 里都加了角色权限问题立刻消失。记住跨账号 KMS 一定是两个 key 都要配别只想着目标端。第三个坑是手动去改目标表结构。零 ETL 自动建好的表我一开始以为就是个普通表想加个分区字段方便查询。结果改完之后集成状态直接变异常回滚 schema 之后才恢复。后来学乖了所有额外的加工都放在物化视图层源表对应的目标表就当它是个中间存储别动手。排查过程中还有一个心得大部分错误在 CloudTrail 的事件里都能看到完整信息尤其是涉及 KMS 和 DynamoDB 的权限问题。跨账号场景记得切换事件历史到对应账号查看两边都翻一遍基本能定位到具体权限缺口。6. 集成方案落地后的几点体会这次把跨账号的 DynamoDB 同步切换到零 ETL 之后我对托管型数据链路有了更直观的感受。以前维护 Spark ETL 脚本每隔一段时间就要处理依赖版本、数据倾斜、重试逻辑这些问题人力和时间成本都不小。换到零 ETL 集成以后日常运维基本就剩下看一眼集成状态和监控指标省下来的时间可以去优化 Redshift 层的查询性能和做更细的数据治理。最后再分享两个实际建议。第一生产环境切换时不要立刻删旧管道。我当时让新旧管道并行跑了大概三天确认两个链路查到的数据保持一致后才下线旧任务期间如果新管道有任何数据缺失还能随时切回旧方案。第二零 ETL 集成虽然托管了搬运过程但它不等于万事大吉。最好在建表规范、命名规范、数据质量监控上提前想清楚否则源表字段一多目标表里全是 SUPER 类型的半结构化数据分析和排查都会变得复杂。对我来说从“自己写管道”到“配置一条集成”这一步真正值钱的地方不是省下的开发量而是把数据工程师从重复的搬运劳动里解放出来让人有时间去思考数据怎么用而不是数据怎么搬。希望这篇文章能让你在跨账号同步这条路上少走些弯路。