走进 AWS 数据服务这个圈子很多人第一反应就是懵。S3、RDS、Aurora、DynamoDB、Redshift、Athena、Glue、EMR、Kinesis……光名字就够绕一阵子更别提搞清楚每个服务到底管什么、什么时候该用哪个。我刚开始接触 AWS 时也这样文档翻了一堆概念背了不少真到做架构选型时还是拿不准。后来我把这些服务想象成一家“数据大超市”思路一下就顺了。这篇就用这个比喻把 9 个主流 AWS 数据服务逐个拆开讲清楚帮你建立一张属于自己的选型地图。不论你是刚接触云开发的新手还是需要给团队做技术方案的老手这篇文章都能给你一套可以直接落地的判断逻辑。1. 数据大超市的整体布局9 个服务各自站哪个货架1.1 为什么把 AWS 数据服务比作超市你去一家大型超市不会指望同一个区域解决所有采购需求。生鲜在冷柜区粮油在货架区零食在促销堆头结账在出口。AWS 的数据服务也是一样——不同服务解决的是数据生命周期的不同环节有存放的、有加工的、有查询分析的、有实时流转的。你不是在“选一个最好的服务”而是在“为每个环节挑最合适的工具”。这套比喻的好处在于它能帮你摆脱“哪个服务更高级”这种错误比较。S3 不比 Redshift 低级DynamoDB 也不比 RDS 逊色——它们本来就是不同货架上的东西服务的目标场景完全不同。有了这层认知再看 AWS 的数据服务列表就不是一堆孤立名词而是一张有结构的地图。1.2 九大服务速览超市角色对照表先把 9 个服务按“超市角色”归个类后面逐一详解时你就有了整体框架。服务名称超市角色核心用途典型场景S3仓库区对象存储存放任意类型文件图片视频、备份归档、数据湖底座RDS标准货架托管关系型数据库ERP、CMS、传统业务系统Aurora精品货架高性能兼容 MySQL/PostgreSQL 的关系型数据库高并发在线业务、核心交易系统DynamoDB自助货架全托管 NoSQL 键值数据库游戏排行榜、购物车、物联网设备数据Redshift批发仓库列式存储数据仓库BI 报表、经营分析、海量数据聚合查询EMR加工车间托管大数据框架Spark/Hive 等复杂ETL、机器学习特征工程Glue搬运工无服务器数据集成与元数据管理数据清洗、格式转换、构建数据目录Athena自助扫码台直接用 SQL 查 S3 里的文件临时分析、查日志、数据湖查询Kinesis传送带实时数据流接入与处理点击流、日志实时收集、监控告警这张表建议存一下。后面你每次做架构方案先对着表确认环节再深入看细节思路会清晰很多。1.3 超市的三条主通道存放、加工、查询流转如果把这 9 个服务再往高层抽象其实就三条通道数据怎么放、数据怎么加工、数据怎么被查和流动。存放环节管的是“数据以什么形态待在哪里”——S3 管文件RDS/Aurora 管关系型数据DynamoDB 管海量键值数据。加工环节管的是“数据怎么变成有价值的东西”——Redshift 做大规模聚合分析EMR 做复杂计算Glue 做清洗和准备。查询与流转环节管的是“数据怎么被使用和传递”——Athena 让你直接查文件Kinesis 让数据实时流进来。一个典型的数据平台架构往往三条通道全都要走一遍Kinesis 把实时数据送进来S3 先存原始文件Glue 做清洗Redshift 承载分析查询Athena 做临时探索。理解了这个流转路径后面每个服务的定位你就不会记混。2. 存放区选型S3、RDS、Aurora、DynamoDB 怎么选2.1 S3超市的巨型仓库什么都能往里扔S3 是 AWS 最基础也最能打的存储服务。你可以把它理解成一个无限大的仓库——不关心里面放的是什么只管按“桶”为单位存放任意类型的文件。图片、视频、日志、备份、Parquet 文件、JSON 数据统统可以往里扔。扔进去之后AWS 负责 99.999999999% 的持久性你基本不用操心数据丢失问题。我实际用下来的体会是S3 最被低估的价值是它作为“数据湖底座”的定位。你不需要预先定义表结构先把所有原始数据扔进去之后想怎么分析再另说。这种灵活性让 S3 成了很多数据架构的第一站。实操中要注意的是存储类别选择——热数据放 Standard访问少的放 Standard-IA几乎不访问的放 Glacier选错了就等着月底账单教你做人。2.2 RDS标准货架上的盒装商品规规矩矩的关系型数据库RDS 是托管版的关系型数据库支持 MySQL、PostgreSQL、SQL Server 等主流引擎。它解决的痛点是“不用自己搭数据库”。传统你买台服务器自己装 MySQL要处理安装、配置、备份、主从、补丁升级一堆运维琐事RDS 把这些全部托管了你只需要在控制台点几下就能得到一个生产可用的数据库实例。选择 RDS 的场景很典型你的业务是传统架构用了多年 MySQL 或 PostgreSQL不想改代码只想少操心运维。需要注意的点是RDS 虽然托管了运维但不等于完全不管——连接数、慢查询、容量规划仍然要你自己盯。尤其是存储空间RDS 的存储扩容虽然可以动态调整但提前规划好增长趋势还是能省不少事。2.3 Aurora精品货架上的高定款性能与兼容兼得Aurora 是 AWS 自研的关系型数据库引擎兼容 MySQL 和 PostgreSQL 协议但底层存储和计算架构做了重构。它和 RDS 的关系你可以这么理解RDS 是把开源数据库搬上云做了托管Aurora 则是从零开始为云重新设计了一个“长得像 MySQL 但内核完全不同的数据库”。Aurora 的核心优势是性能和扩展性。它把存储层和计算层分离存储跨多个可用区冗余写入时自动复制六份副本计算节点可以秒级扩展只读副本轻松应对读多写少的业务高峰。省心程度也更高存储空间自动增长不需要像 RDS 那样手动规划容量。选 Aurora 还是选 RDS我的判断依据很简单如果业务对数据库性能、扩展性要求高而且预算允许直接上 Aurora如果业务规模不大追求低成本RDS 的常规实例完全够用。我自己在几个高并发项目里都用 Aurora实测下来主从切换的稳定性比自建 MySQL 手动切换体验好太多。2.4 DynamoDB自助货架即拿即走的海量键值数据库DynamoDB 是 AWS 的全托管 NoSQL 服务和你之前接触的 MySQL/PostgreSQL 完全不是一个物种。它不要求你定义表结构每条记录就是一组属性类似 JSON查询靠主键适合海量写入和高并发读写的场景。游戏排行榜、用户会话、购物车、设备状态这类数据天然适合 DynamoDB。上手 DynamoDB 最容易踩的坑是读写容量单位RCU/WCU的预置。它有两种计费模式按量付费和预置容量。业务平稳用预置容量更省钱流量波动大用按量付费更省心。我见过不少团队因为没算好 WCU高并发写入时直接触发限流线上告警响成一片。还有一个容易忽略的点DynamoDB 的查询能力受限。它能按主键精确定位也能用排序键做范围查询但如果你的查询条件不是基于主键的性能会大打折扣。设计表结构时先想清楚查询模式再反推主键设计这是 DynamoDB 和关系型数据库最不一样的地方。对比维度S3RDSAuroraDynamoDB数据形态任意文件关系型表关系型表键值/文档查询方式不直接查询SQLSQL主键查询扩展性无限垂直只读副本存储计算分离、秒级扩展水平自动扩展运维成本极低中低极低典型场景数据湖、备份传统业务高并发在线业务海量高并发键值3. 加工与批售区Redshift、EMR、Glue 如何配合3.1 Redshift批发仓库专为大规模分析而生Redshift 是 AWS 的数据仓库服务列式存储MPP大规模并行处理架构。普通数据库面向的是“在线事务处理”OLTP每次操作小批量读写Redshift 面向的是“在线分析处理”OLAP一次查询要扫描几十亿行数据做聚合计算。超市比喻里它是批发仓库——别人按件买它按吨卖。用 Redshift 最常见的场景是 BI 报表。业务数据从各个系统汇总进来Redshift 做清洗、加工、聚合然后 Tableau、QuickSight 等工具从里面取数展示。我团队的日常就是每天定时任务把业务库数据同步到 Redshift分析师写 SQL 出报表查询速度从原来 MySQL 上的几十秒降到秒级体验完全不一样。Redshift 有排序键和分布键两个概念用好了性能起飞用不好查询照样卡死。排序键决定数据在磁盘上的物理顺序分布键决定数据分配到各个计算节点的方式。设计键时排序键要尽量匹配常用查询的过滤条件分布键要尽量让关联查询在本地完成避免数据跨节点传输。这是 Redshift 调优最核心的部分。3.2 EMR加工车间灵活的大数据处理工作台EMR 是 AWS 上的托管大数据平台支持 Spark、Hive、HBase、Flink 等主流框架。你可以把它理解成一个可以随时开张、用完就关的“加工车间”——需要时拉起一批计算节点跑作业跑完释放按使用时长付费。什么时候用 EMR什么时候用 Redshift很多人搞不清楚。我的经验是这样的如果任务是复杂的 ETL 逻辑、机器学习特征工程、或者需要 Spark 的分布式计算能力选 EMR如果任务是结构化的 SQL 聚合分析Redshift 更省心。EMR 给的是计算框架的灵活性Redshift 给的是开箱即用的数仓体验。二者完全可以配合——EMR 处理完数据写到 S3Redshift 再从 S3 加载做分析。用 EMR 最大的成本坑是“忘记关闭集群”。它按节点计费机器一直开着账单就一直涨。最好设置空闲自动终止策略或者建立标准的集群启停流程。我在项目里都是把 EMR 集群的启动和作业提交写成脚本跑完自动关闭避免人工操作遗漏。3.3 Glue不知疲倦的搬运工数据管线的无名英雄Glue 是 AWS 的无服务器数据集成服务。它有两大职责一是元数据管理通过 Crawler 扫描数据源自动生成数据目录二是ETL 作业用 PySpark 脚本做数据清洗和转换。超市比喻里它是那个不停搬运货物的员工——业务系统数据搬进数仓一个格式转成另一个格式全部由它完成。Glue 的 Crawler 是我用得最多的功能。设置好数据源路径后它会自动扫描 S3 里的文件结构在 Glue 数据目录中生成表定义。这样 Athena 就能直接查询这些文件不需要手工建表。整个过程点几下就能完成对数据工程师来说省了大量重复工作。Glue ETL 作业的计价是按 DPU数据处理单元小时计费作业跑得越久成本越高。优化的核心思路有两个控制数据倾斜某些 key 数据过多导致单任务卡死和合理设置 DPU 数量。别一味加大 DPU有时候数据量不大加大 DPU 反而浪费钱。4. 查询与流转区Athena 和 Kinesis 的实务运用4.1 Athena自助扫码台直接对文件跑 SQLAthena 是一个很神奇的服务它没有集群、没有服务器你给它一个 S3 路径和表结构它就能直接对文件执行 SQL 查询按扫描的数据量计费。你可以把它理解成超市出口的自助结算台——扫码就知道价格不挑商品种类随用随走。我对 Athena 的评价是“临时分析救星”。业务想查某个时间段的历史日志不用起一个数仓不用导数据直接把 S3 里的日志文件用 Athena 查一遍几分钟出结果。成本也便宜扫描 500GB 数据大约花几美元比搭一套环境便宜太多。要注意的是Athena 不适合高频查询和高并发访问。按量计费决定了查询越多成本越线性增长而且每次查询都有几秒的启动时间。我的建议是Ad-hoc 探索和低频报表用 Athena高频查询数据扔进 Redshift 或做物化缓存。另外对文件做分区存储能显著减少扫描量比如按天分区、按业务类型分区查询时只扫相关分区成本能降一个量级。4.2 Kinesis传送带上的实时数据流Kinesis 是 AWS 的实时数据流服务。它的核心功能是把“连续产生的事件”持续接入云端——网站点击流、App 埋点日志、IoT 传感器数据等。你可以把 Kinesis 想象成超市里的传送带货物不断放上来后端消费者在传送带另一头持续取走处理。Kinesis 家族里有几个子产品最常用的是 Kinesis Data Streams 和 Kinesis Data Firehose。Data Streams 面向需要自定义处理逻辑的开发者提供低延迟的流式接入消费者用 Lambda 或 Kinesis Data Analytics 处理。Firehose 则更傻瓜——直接把流数据投递到 S3、Redshift 等目标存储中间可做格式转换。用 Kinesis 时最需要注意 Shard 数量设计。Shard 是 Kinesis 的吞吐量单位每个 Shard 每秒支持 1MB 写入和 2MB 读取。Shard 太少会写入限流太多则成本浪费。预估好峰值流量再定 Shard 数并且设置好监控流量上涨时及时扩容这是 Kinesis 稳定运行的前提。5. 端到端实战串联从零构建一个简易数据平台5.1 场景设定与架构选型为了让你真正理解这几个服务怎么配合我模拟一个常见实战场景一个电商平台需要实时收集用户行为日志做清洗加工最后支持业务报表和临时探索。数据量每天大约 2 亿条事件峰值 QPS 约 5000。基于前面的选型逻辑这套架构可以这样搭数据接入Kinesis Data Streams 接收点击流和订单流设置适当 Shard 数支撑峰值流量原始存储Kinesis Data Firehose 把流数据持续写入 S3按天分区存储数据清洗Glue 作业定时读取 S3 原始数据做格式转换、去重、字段补齐写入 S3 的清洗层数据建模Redshift 从 S3 清洗层加载数据建立分析模型支撑 BI 报表临时分析Athena 直接查询 S3 原始文件和清洗文件做探索性分析这个架构覆盖了存放、加工、查询、流转全链路而且每层之间通过 S3 解耦。每一层都可以独立扩展或替换这是 AWS 数据服务组合起来最大的好处。5.2 关键实现步骤与参数选择第一步是创建 Kinesis Data Streams。估算峰值流量 5000 QPS每条记录平均 1KB则写入流量约 5MB/s。每个 Shard 支持 1MB/s建议配置 8~10 个 Shard 留出余量。创建后用 Kinesis Producer Library 接入应用日志。第二步是配置 Firehose 投递到 S3。这里要设置好缓冲条件缓冲区大小 64MB 或缓冲间隔 300 秒哪个先到就触发写入。要注意 S3 的前缀命名建议用log/year2025/month05/day01/这种 Hive 风格分区路径这样 Athena 和 Glue 都能直接利用分区裁剪减少扫描量。第三步是编写 Glue 清洗作业。用 Glue Studio 可视化定义数据源、转换逻辑、目标存储也可以直接写 PySpark 脚本。清洗逻辑通常包括过滤无效字段、时间格式标准化、用户 ID 统一、去重。作业调度用 Glue Workflow 配置每天凌晨跑一次。第四步是 Redshift 建模。先用 Redshift Spectrum 或 COPY 命令从 S3 加载数据设计事实表和维度表。订单事实表按下单时间做排序键按用户 ID 做分布键。写完建表语句后设置定时的 ETL 任务把清洗层数据刷进 Redshift。第五步是 Athena 做探索查询。Glue Crawler 扫描 S3 分区路径自动生成表结构Athena 里直接写 SQL。比如查某天各品类浏览次数 Top 榜单一条带 WHERE 分区过滤的 SQL扫描量控制在几百 MB几秒钟出结果费用约几美分。5.3 实测经验总结这套架构实跑下来最明显的收益是分层清晰、出问题好排查。Kinesis 消费堆积了查 Shard 监控数据缺失查 Firehose 投递日志格式不对查 Glue 脚本查询慢查 Redshift 排序键设计。每一层都有独立指标不用从入口一路排查到出口。成本方面最大开销集中在 Redshift 的常驻节点。为了控制成本我把 Redshift 配置在非工作时间自动暂停早晨自动恢复。实测每个月能省将近一半的 Redshift 费用。S3 存储和 Athena 查询成本反而是小头因为分区裁剪做得好每次查询扫描的数据量被压得很低。6. 常见问题与避坑清单实录6.1 选型误区与典型踩坑场景我在多个项目里见过同样的选型错误最有代表性的有三个。第一个是把 DynamoDB 当关系型数据库用。业务方习惯了 MySQL 的联合查询和灵活条件筛选换了 DynamoDB 之后发现查不了多条件组合只能按主键查代码重写了一大堆性能还不如原来的 MySQL。DynamoDB 的适用前提是先设计好查询模式不是先迁移数据。第二个是 Athena 被当成数仓用来跑高频报表。刚开始成本看着很低业务方越来越依赖每天成百上千次查询月底账单直接翻了几番。查询频率一高就必须考虑把结果物化到 Redshift 或做缓存不能所有查询都去扫原始文件。第三个是 S3 存储类别选型图省事全部默认 Standard。日志类数据越来越多长期不访问却按热数据计费成本白白上涨。实际只要在 S3 生命周期规则里配上自动转储策略比如 30 天后转 Standard-IA、90 天后转 Glacier成本能下降 60% 以上。6.2 问题排查速查手册症状可能原因排查思路Kinesis 数据消费延迟增大Shard 数量不足写入被限流检查 CloudWatch 的 WriteProvisionedThroughputExceeded 指标按需扩容Athena 查询费用异常高查询没有走分区过滤全表扫描查看查询扫描字节数优化 WHERE 条件使用分区列Redshift 查询突然变慢排序键设计不合理或数据倾斜查看 EXPLAIN 执行计划检查 Distribution 是否均匀Glue 作业长时间卡住数据倾斜导致部分任务拖尾查看 Spark UI 的 Stage 耗时对热点 key 做加盐处理S3 中文件出现损坏格式多个写入任务并发覆盖同一路径改用 S3 PUT 的原子性和分目录写入策略避免覆盖DynamoDB 出现限流错误WCU/RCU 预置不足启用 Auto Scaling 或改用按量计费模式6.3 几条少走弯路的实操心得第一个心得是分区策略越早规划越好。很多人先把数据扔进 S3 再说后面才补分区折腾半天。我现在的做法是所有数据写入 S3 之前先定好日期分区和业务分区字段这直接决定了后续 Athena 查询成本和 Glue 处理效率。第二个心得是Glue Crawler 不是建表的唯一方式。如果表结构是明确的手工在 Glue 数据目录里建表更可控。Crawler 自动推断字段类型偶尔会出错像时间戳字段会被自动识别成 string手工建表反而省去这些麻烦。第三个心得是Redshift 不能无脑不加索引。虽然 Redshift 是列式存储但也有类似分布键、排序键的设计。建表前用 EXPLAIN 查看查询计划针对慢查询优化键设计效果比堆节点数明显得多。第四个心得是所有核心配置都要用基础设施即代码管理。数据服务的配置项太多了——Kinesis Shard 数、Redshift 并发量、Glue 的 DPU 数手动在控制台点很容易出现“测试环境改了一版生产环境忘了同步”的问题。用 Terraform 或 CloudFormation 统一管理变更记录清晰回滚也方便。7. 后续方向这套数据方法论还能怎么延伸掌握了这 9 个服务的基本功之后下一步可以考虑两个常见升级方向。一是从批处理走向实时化。当前的架构里Kinesis 负责接入流数据但清洗和加工更多还是定时批处理。如果业务对数据时效性要求更高可以用 Kinesis Data Analytics 做流式 SQL 分析数据到达秒级就能产出结果比如实时大屏、实时风控。二是引入机器学习能力。S3 里的数据经过 Glue 清洗后可以直接用 SageMaker 做模型训练。数据平台的沉淀越久历史数据越丰富模型效果越好。这也让“数据服务”从支撑报表分析升级为驱动智能决策。这两个方向不需要一次性全部铺开可以先选一个业务痛点做小规模试点。比如先做一个实时监控看板验证流处理链路是否稳定再逐步扩大范围。AWS 数据服务的灵活性就在这里——你完全可以从一个小场景切入逐步演进成完整的数据体系。我个人实操中的感受是AWS 这些数据服务单个看不复杂真正的难点在于组合运用时如何保证数据一致性、控制成本、以及让每个环节可观测。把“数据大超市”这个框架记在心里每次做选型先确认自己站在哪个通道上再挑对应货架上的工具思路就会清晰很多。最后再分享一个小建议不要试图一次把所有服务都用上从一个最小的可运行闭环开始跑通了再逐步加环节这条路走起来远比想象中稳。