用“数据大超市”讲透 AWS 九大数据服务：定位、场景与选型

第一次打开 AWS 控制台的人，多半会被那几十个数据服务搞得头皮发麻：S3、RDS、DynamoDB、Redshift、EMR、Kinesis、Glue、Athena、QuickSight……名字长得像，功能又重叠，很多人一看就放弃了。我当年也是被绕得晕头转向，后来换了个思路——把这些服务想象成一家大型超市的数据流水线，一下就通了。这篇文章就用“数据大超市”的比喻，把 AWS 最常用的 9 大数据服务逐个讲透，适合刚入门云计算、准备做数据架构选型，或者只是想搞清楚这几个服务到底区别在哪的人。不堆概念，只讲人话，讲完你至少能判断自己项目该开哪几扇门。

1. 一家“数据大超市”的骨架：把九大服务先摆在对应的货区

超市的运作逻辑其实和数据处理一模一样：进货、搬运、上架、加工、收银、出报表。AWS 里的每一个数据服务，本质上就是这条流水线上的一个岗位。搞清楚每个岗位干什么，比死记硬背功能列表管用得多。

1.1 为什么是“超市”而不是“工具箱”

我之前给朋友讲 AWS 数据服务，最喜欢用“工具箱”打比方，后来发现不行。工具箱给人的错觉是：每个工具独立存在，用哪个都行。但真实的企业数据场景不是单个工具能用好的，而是一条链路：数据来了，先放哪；怎么清洗；怎么查询；最后怎么展示给老板。这条链路是连续的，服务之间需要配合。超市正好能把这条链路串起来——货物要先有仓库，再上货架，有些要进加工间，最后经过收银台变成消费者手里的东西。数据也是先落到存储，再被处理，再被分析，最后变成报表。所以你想学 AWS 数据服务，先得在脑子里画一张超市地图。

还有一个原因是，超市的岗位边界很清楚：仓库管理员不负责收银，收银员也不用管进货。这对应到 AWS 服务上，就是每个服务都有明确擅长和不擅长的事。你非让仓库管理员去收银，出纳报表就是灾难。后面讲的很多踩坑案例，本质都是“岗位错位”。

1.2 九个服务的“岗位图”

先看全景图，后面逐个拆开讲。

这张表建议先抄下来，后面每个服务我补充几个实操细节，你会发现它们之间的关系比想象中紧密得多。

2. 入口和货架：S3、RDS、DynamoDB，三种“存数据”的方式差在哪里

大多数系统的第一步都是“数据放哪”。S3、RDS、DynamoDB 是三种最常见的存放位置，但它们对应完全不同的货架类型。很多新手上来就选 S3，或者盲目用 RDS，都是没想清楚三种货架的区别。

2.1 S3：成本极低的地下大仓库，什么都能囤

S3 是对象存储，核心概念是“桶（Bucket）”和“对象（Object）”。你可以往桶里丢图片、日志、CSV、Parquet、备份文件，甚至整个数据库导出文件。它为什么能当大仓库？因为它几乎无限扩容，你不用提前规划容量；同时它便宜，存储单价随着存储等级变化，标准存储、低频访问、归档存储之间的价格能差一个数量级。

我自己的习惯是：只要数据暂时不知道往哪放，就先进 S3。原始日志、上游系统导出来的文件、临时中间结果，全都丢进去，配合生命周期策略，比如 30 天前自动转低频、90 天前自动转归档，一年下来能省不少钱。这里要记住一个关键点：S3 不是数据库。它没有事务锁，不适合频繁更新和复杂查询。有人把系统配置文件放 S3 并且程序每次启动都读一次，这没问题；但如果想用 S3 支撑线上交易系统的主表读写，那就完全用错了地方。

还要提一句，现在 S3 已经是强一致性了，写入后立刻读能看到最新数据，早年“最终一致”的坑已经不存在了。它自带版本控制、跨区域复制、静态网站托管，还能生成预签名 URL 给第三方临时上传文件，做图片服务、软件分发、数据交换都非常顺手。

2.2 RDS：货架上整整齐齐的标准包装

RDS 是托管的关系型数据库，支持 MySQL、PostgreSQL、MariaDB、SQL Server 等引擎。它对应超市货架上的标准包装商品：格式高度统一，有完整结构，开箱即用。关系型数据库强调 ACID 事务、SQL 查询、表之间有外键关系，适合订单、用户、库存这类强一致性场景。

RDS 带来的最大价值不是让你学会 SQL，而是把数据库运维交给 AWS：自动备份、自动补丁、自动故障转移、一键扩缩容。我见过很多小团队放着 RDS 不用，非要自己搭 MySQL，结果半夜磁盘满了，主从不同步了，熬一宿修数据库，第二天还要上线。说实话，这种“纯手动”的坚持没有任何意义，除非你有安全合规层面不得不自建的理由。

实操层面注意三件事：第一，Multi-AZ 要开启，它会在另一个可用区维护一个同步备库，主库故障时自动切换，这是数据库可用的底裤；第二，读多写少的场景可以加只读副本（Read Replica），把查询流量分出去；第三，磁盘类型和 IOPS 直接影响性能和价格，不要买默认配置就不管了。RDS 的通用型 gp3 存储够用，但如果遇到高写入压力，IOPS 才是瓶颈，得提前看监控。

2.3 DynamoDB：快餐档口，来一份即刻拿走

DynamoDB 是 NoSQL 键值数据库，对应超市里的快餐档口：你点什么，它立刻给你什么，但菜单有限，别指望它给你做满汉全席。它的核心优势是毫秒级读写延迟，天然分布式自动扩展，不用管分区和副本，很适合高并发、简单查询的业务，比如购物车、会话状态、游戏玩家分数、设备状态。

用 DynamoDB 最重要的事是表设计。它只有主键，分“分区键”和“排序键”。你选什么字段做分区键，直接决定访问热点分布。举个例子，按“用户ID”做分区键，某个大 V 用户的数据就是天然热点，别人访问可能 5 毫秒，访问他可能慢 10 倍。我之前做过一个活动页，把所有用户计数都放在一张表，结果前几名的账号请求量太大，影响了整张表，后来改成了带随机后缀的分布式计数键才解决。

成本模式也要注意。DynamoDB 有两种计费：预置吞吐容量（RCU/WCU）和按需模式。预置省钱，但你要估量峰值；按需灵活，给你省了运维却贵好几倍。建议业务稳定后用预置加自动扩缩容，活动期间再临时调高。

2.4 三种“货架”选型对比

一句话总结：S3 负责“囤”，RDS 负责“管账”，DynamoDB 负责“秒回”。别搞混。

3. 拎进后台的加工区：Kinesis、Glue、EMR 怎么把生数据变成熟数据

数据光存下来没有意义，得加工。就好比超市仓库里的土豆，不会自动变成薯片。Kinesis、Glue、EMR 就是加工区的三种设备：一条传送带、一个搬运理货员、一个能开大火力的车间。

3.1 Kinesis：自动传送带，处理实时流进来的数据

Kinesis 解决的是“数据实时进来”的问题。你在超市出口放一条传送带，顾客拿完商品的每个动作都会产生一条数据，不停流过来。技术术语叫流式数据。Kinesis 家族有三个子产品，很多人一上来就混。

• Kinesis Data Streams：最底层的数据管道。数据先进入分片（Shard），然后你可以写消费者程序去读。数据可以保留 1 到 365 天，适合需要自己定制处理逻辑的场景。麻烦点在于分片数量要手动管理，吞吐量和分片数成正比。
• Kinesis Data Firehose：省心版。你不需要管理分片，直接把流式数据投递到 S3、Redshift、OpenSearch 等目标存储。适合“拿到数据后先存起来再说”的经典场景。
• Kinesis Data Analytics：对流数据做实时 SQL 分析，比如实时计算每分钟的订单金额。

实操心得：如果只是想“把日志实时存档”，选 Firehose，别选 Data Streams。我见过很多项目没分清这两个，白白搭了一个消费者集群去转发数据，运维成本直接翻倍。但如果你要做实时风控、实时推荐这类需要自定义逻辑的场景，Data Streams 才是正确选择，因为你有机会逐条处理。

Kinesis 的成本主要看吞吐量：Data Streams 按分片计费，Firehose 按写入的数据量计费。另外要注意，Firehose 写入 S3 时有个缓冲区间，可以设置缓冲大小或缓冲时间（比如 5 分钟或 64MB），本质就是攒一批再写，减少小文件数量。这个后面讲 Athena 查询优化时还要提，因为 S3 里小文件多了，查询会慢得你想哭。

3.2 Glue：搬运理货员，ETL 的粘合剂

Glue 是 AWS 的无服务器 ETL 服务，配套一个非常重要的组件叫 Glue Data Catalog。你想象一下：S3 里堆了几百个 CSV 和 JSON 文件，格式乱七八糟，字段一会儿有一会儿没有。这时候 Athena、Redshift 想分析都不知道字段在哪。Glue 的爬虫（Crawler）会去扫描数据源，自动识别表结构，把元数据登记到 Data Catalog。有了这个目录，Athena 才能像查数据库一样查文件。

Glue 的另一半是 ETL 任务。你可以在 Glue Studio 上拖拽或者写 PySpark/Scala 代码，把数据从 S3 读出来，清洗、去重、转格式，再写成 Parquet 落到 S3，或者直接导入 Redshift。这个过程是定时或按事件触发的，跑完就自动释放资源。

和 EMR 的区别要讲清楚：EMR 是你自己管理集群，你想装什么框架、想调多少节点都行，灵活但费心；Glue 是无服务器，你不用关心集群，就行。对大多数常规 ETL、日加工、小时级处理，Glue 足够。但如果你要做超复杂的机器学习特征工程，或者要精确控制 Spark 参数，EMR 更合适。我给朋友的建议是：默认先用 Glue，觉得 Resource 不够再上 EMR。

这里补一个小经验：Glue 和 Athena、Redshift 是连续作战的好搭档。很多项目第一次打通报告链路，就是从 S3 原始日志开始，用 Glue 爬取目录建表，然后 Athena 做查询验证，最后把验证通过的逻辑固化到 Glue ETL 里，生成清洗后的数据供报表服务使用。

3.3 EMR：食品加工车间，一次性处理超大块头的货

EMR 是托管的 Hadoop 生态集群，预装了 Spark、Hive、Presto、Trino、Flink、HBase 等组件。它对应超市里的中央厨房：接单能力极强，接的是大单。什么时候需要它？一次性处理几百 GB 甚至 PB 级数据的批处理任务、复杂的机器学习训练前特征计算、从外部 Hadoop 集群迁移上云，这些重活得开大车。

EMR 的核心用法是“用完就关”。启动一个集群处理任务，处理完立刻终止，只为实际运行的时间付费。很多人不适应这种模式，总想保持集群常开。除非是交互式查询，否则别这么做，钱烧得很快。另一个省钱大招是用竞价实例（Spot Instance）跑非核心任务，价格能比按需便宜一半以上，但节点可能被回收，所以任务要设计成能断点续跑。

需要注意，EMR 现在最常跟 S3 配合使用，而不是 HDFS。因为计算存储分离之后，集群随时可以关闭，数据仍然安全存在 S3 上。如果你用了 HDFS，集群一关数据就丢了，这思想已经过时了。我自己做离线统计时，流程通常是这样：S3 原始数据 -> EMR 跑 Spark 任务 -> 结果写回 S3 -> Athena 查询验证 -> QuickSight 出报表，整条链路不需要长期保留大集群。

3.4 加工区的一个常见瓶颈：盲目跳步

我见过不少项目跳过了 Glue 这一步，直接让 Athena 或者 Redshift 读原始 CSV，结果字段错位、字符编码混乱、日期格式不统一，分析出来的报表根本没法看。原始数据永远是为加工准备的，不是为分析准备的。正确路径是：先进 S3 原始区，再用 Glue 清洗成分析区，最后分析师只查分析区。哪怕你只是一个人在做数据，也建议把 S3 拆成 raw 和 processed 两个桶。这个习惯能帮你省掉无数脏数据的坑。

4. 出报表的收银台：Redshift、Athena、QuickSight 从数据到答案

数据加工好之后，终于到“出结果”的环节了。Redshift、Athena、QuickSight 对应超市的收银台和分析室。这一段的重点不是“谁更快”，而是“谁适合谁来用、什么时候用”。

4.1 Redshift：大型分析仓库，面对的是严肃的商业分析

Redshift 是云数仓，真正为大规模 SQL 分析设计的。它和 RDS 最本质的区别在于存储引擎：RDS 用的是行式存储，Redshift 是列式存储加 MPP（大规模并行处理）架构。列式存储的好处是，分析查询通常只扫描少数几个字段，不用把整行数据都读出来，大表聚合速度能差出几十倍。这就是为什么经营报表放在 RDS 上跑到数据库崩溃，搬到 Redshift 就能顺滑跑完。

用 Redshift 要理解几个核心概念：Distribution Key 决定数据在节点之间的分布策略，Sort Key 决定数据在每个节点上的排序规则。这两个键设计得当，查询性能能翻倍；设计不当，数据歪斜到某个节点，整个集群都会慢。我建议新手上路时先用最简单的 even 分布加自动排序，等真实查询模式稳定了再精调。

现在的 Redshift 生态有个很关键的能力叫 Redshift Spectrum，它可以直接查询 S3 里的外部表，不需要先把数据导入进来。这就意味着，你的“数仓”可以分成两层：热数据在 Redshift 里，冷数据放在 S3，通过 Spectrum 统一查询。成本结构一下子灵活很多。

使用场景上，Redshift 典型用来做宽表：业务库的数据通过 Glue 或 Redshift COPY 命令，定期同步进来，然后攒成用户宽表、订单宽表，QuickSight 背后可以接的就是这份宽表。千万不要拿 Redshift 当在线交易库，它的写入更新性能远不如 RDS，并发能力也弱。

4.2 Athena：自助查询台，不搬数据也能查数

Athena 是让我最惊喜的服务，它没有服务器，不用建数仓，不用导数据，直接在你的 S3 文件上执行 SQL。底层是 Presto/Trino 的分布式查询引擎，计价方式是按扫描的数据量收费，每 TB 价格也不贵，小规模查询几乎可以忽略。

什么时候用 Athena？我自己的经验有三类：第一，探索式分析，数据形态还不稳定，先建表跑几个 SQL 看看有没有价值；第二，低频报表和临时排查，比如查某一天的日志错误率，需求来得急，不值得为此搭一套数仓；第三，团队所有人共享 S3 数据湖时，让分析师直接用一个统一 SQL 入口查文件。

唯一的重点：性能取决于文件格式和布局。如果你把 CSV 直接丢进 S3，一个 50GB 的文件放那里，Athena 查起来会很痛苦且烧钱。正确做法是用 Glue 把数据转成 Parquet 格式，按时间做分区（比如 dt=2025-01-01），再用压缩。同样的数据量，查询时间和费用能省 70% 以上。这是我从踩坑里学到的——第一次我用 Athena 查原始 CSV 日志，账单出来的时候我整个人都不好了。

Athena 和 Redshift 不是互斥关系，而是递进关系。数据量小、并发不高、无固定节奏时用 Athena；数据量大、报表要稳定跑、并发查询多时用 Redshift。很多人以为一定要上数仓才能做分析，这个门槛其实被 Athena 打破了。

4.3 QuickSight：把答案摆上桌面的收银小票

QuickSight 是 AWS 全托管的 BI 服务。你给它接数据源（Athena、Redshift、S3 都行），它给你出图表、仪表盘和报表。对应到超市就是收银台——数据终于在最后变成了普通人能看懂的东西。

它的几个亮点值得说：第一，自带 SPICE 内存加速引擎，数据先导进内存，报表页面加载很快，不会每次点击都打到 Redshift 上；第二，按会话付费，创建仪表盘的用户可能要付作者费，但看报表的用户可以按需付费，这个成本模型在 AWS 生态里挺友好；第三，内置行级安全，不同的销售看同一个仪表盘，只能看到自己负责区域的数据。

很多团队其实已经有了 Grafana 或者 Superset，为什么还要考虑 QuickSight？因为重点不是工具本身，而是托管、认证、权限集成和后续维护成本。如果你想少养一套 BI 系统，用 QuickSight 做企业内部报表是很省事的选择。不过我对 QuickSight 的图表自由度评价一般，如果不差钱又需要高度定制化报表，Tableau 或者 Power BI 也完全可以接 AWS 数据源，没有谁规定你必须用全家桶。

4.4 查询路线的两条核心逻辑

到这里，你会发现查询体系的选型其实全部取决于“数据在哪个货架”以及“你现在要什么答案”。日常临时探索，直接 S3 + Athena；稳定运营报表，走 S3 + Glue/EMR + Redshift + QuickSight；数据量不大又想省钱，可以 S3 + Athena + QuickSight，把 Redshift 整个省掉。先用最便宜的路线跑通业务，再在性能不够时补上 Redshift，是我最推荐的做法。

5. 站在大门口怎么走：三种真实业务场景的选型路线

如果把前面每个服务比作岗位，那具体到项目里，你怎么从门口走到对应的货区？这里拿三个我实际遇到过的场景举例，你可以直接对照着抄。

5.1 场景一：电商订单和经营分析

假设你要做一个电商系统。订单、用户、库存这些交易数据写入 RDS（MySQL 或 PostgreSQL），这是业务系统的“账本”，不能丢，必须强一致。每天的销售明细同步到 Redshift，用 Glue 做 ETL，生成日维度销售宽表和用户宽表。QuickSight 接 Redshift 出经营看板，老板每天早上打开看营业额、转化率、退货率。同步频率可以每小时或每天一次，看业务需求。这套组合的本质是让业务库和分析库分开，不让分析查询拖垮线上交易。

5.2 场景二：海量日志与安全审计分析

现在要处理所有 Web 服务的访问日志和错误日志。日志统一打到 Kinesis Data Firehose，Firehose 按 5 分钟或 64MB 缓冲写入 S3，并按日期路径分桶。Glue 每天跑一次 Crawler，识别当天新增的分区表结构；同时跑一个 ETL 任务，把日志里的用户字段标准化，去重和剔除爬虫流量，生成 Parquet 格式的清洗后数据。分析师要查问题时直接 Athena 写 SQL，比如“查昨天 /api/login 的 5xx 错误来源 IP”。如果后期需要长期安全分析，把清洗后数据定期导入 Redshift。这个链路从头到尾没有自己搭任何服务器，成本最可控。

5.3 场景三：实时排行榜和在线活动

游戏或者营销活动的实时排行榜，数据特点是写多读多、延迟要求极高、字段简单。直接把用户参与记录写到 DynamoDB，按活动 ID 加用户 ID 设计联合主键，再用 Kinesis Data Streams 捕获 DynamoDB 的变更流，通过 Lambda 做实时聚合，结果写回另一个 DynamoDB 聚合表。前端读取时走 DAX 加速缓存，毫秒级返回排行榜数据。整套方案里，你不需要 RDS，也不需要 Redshift，因为实时场景的重点是“当前状态”，不是历史分析。注意，分析型查询和实时查询是两种截然不同的需求，别为了省事把实时业务强行放到分析引擎上。

三个场景看下来，你会发现规律非常清楚：先想数据从哪里来、要求多快的响应、最后给谁看。想清楚这三件事，选型基本不会错。

6. 亲自经营“超市”后的避坑记录：关于成本、角色错位和落地顺序

最后写一点自己的教训。这些坑不是从文档里看来的，都是真金白银和深夜修数据换来的。

6.1 最常见的三个“岗位错位”

第一个是拿 S3 当业务数据库。有人把业务接口的响应数据直接写 S3，然后程序读取原样返回，听着简单，但更新和删改非常痛苦，版本管理混乱，最终一定返工。S3 是仓库，不是货架。

第二个是拿 RDS 跑分析报表。业务量一上来，复杂聚合查询把 RDS 的 CPU 打满，影响线上交易。再贵的数据库也扛不住分析师跑全表扫。分析的事，应该交给 Redshift 或 Athena。

第三个是让 Athena 扫未压缩的原始 CSV 大文件。一次扫描几 GB，费用还算能忍，一旦有人天天点仪表盘，账单立刻失控。Athena 的优化核心永远是数据格式和分区，不是换更大机器。

6.2 成本账户上容易被忽视的三个细节

• 跨区域传输费用：日志在美东，数据处理和美西，每天同步几 TB，流量费用会吓到你。尽量让服务在同一区域，避免跨区搬数。
• DynamoDB 预留流量的浪费：很多人为了防止限流，开了双倍预置容量，结果闲置浪费。建议用按需模式起步，等测出真实流量曲线后再换预置。
• Redshift 空转成本：集群没有查询也在烧钱。低频分析场景优先考虑 Redshift Serverless，按实际查询时间计费，和 Athena 一样是按需思路。

6.3 我的最小化起步建议

如果你刚接手一个数据项目，别再追求“全套齐活”。最轻的路线是：日志进 S3，Glue 爬目录，Athena 查数据，QuickSight 出报表。整套下来没有常驻服务器，只有查询时才花钱。当这个链路跑稳定，需求越来越重，再迁移到 Redshift、加入实时 Kinesis、引入 EMR。这种渐进式落地的好处是从第一天就有结果，而不是搭了两个月平台最后被业务方放弃。

我个人的体会是，AWS 数据服务的学习曲线看着陡，本质上就一条主线：数据从哪进、放在哪、怎么洗、如何查、给谁看。你用超市这个框架，把这九个岗位的职责和衔接搞清楚，以后不管 AWS 再出多少新服务，你都能一眼看出它替代的是哪个环节、解决的是什么问题。希望这篇“超市地图”，能帮你少走点弯路。