简介这是一份面向云端架构师、数据工程师与解决方案顾问的AWS云端数据湖架构PPT系统讲解如何基于AWS构建集中式数据湖解决多源数据汇聚、存储与计算分离、读取时范式化等核心设计问题。内容覆盖客户忠诚度计划、实时订单追踪、互动式语音机器人、动态个人报价等典型业务场景并梳理了S3、Glue、Athena、EMR、Redshift等组件在数据摄入、目录搜索、处理分析及安全管控中的具体分工适合直接用于方案汇报或团队内部分享。压缩包内仅含1个pptx文件大小约2.37MB内容组织紧凑、图表丰富。这份PPT结合了实际查询案例例如通过Athena在8.47秒内扫描10.19GB订单数据以及S3与传统HDFS在1PB数据规模下的成本对比能让读者直观体会云端数据湖的高性能与经济性并理解无集群架构的选型价值。目前已有203人学习下载。1. 数据湖架构在AWS云端落地PPT上几条箭头跑起来全是细节在一张AWS云端数据湖架构的PPT里S3、Glue、Athena、Lake Formation四块方块连几条箭头讲方案十分钟就够了。但真正把数据湖架构建在AWS云端落地成一条让业务愿意每天使用的数据链路完全是另一件事。这篇笔记不写PPT怎么画写的是存储怎么铺分区、元数据目录怎么建、查询怎么控制扫描量、权限怎么做到不多给也不少给再补几个文档里没有的血泪踩坑记录。适合正在评估或已经决定用AWS搭数据湖但还没整体踩过一遍的工程师和数据架构师。2. 存储底座选型S3上设计数据湖的分区与文件布局2.1 为什么数据湖通常建在S3而不是自建HDFS数据湖架构里最容易被低估的是“湖”本身。很多人一听到大数据第一反应是HDFS但AWS云端的数据湖几乎都默认落在S3上。原因是S3把存储和计算彻底拆开了Glue做ETL、Athena做查询、EMR跑Spark都是计算资源按需启动用完就释放而数据始终留在S3上。HDFS则相反数据跟着集群走集群缩容数据就危险长期闲置的HDFS集群只为“那点数据”烧着昂贵的计算费用。另外S3的可用性和持久性设计得足够省心跨可用区冗余是默认能力不需要像HDFS那样维护三副本。S3的存储等级还能做生命周期管理热数据放Standard半年以上的冷数据转Glacier成本可控。这个优势在架构图上看不出来只有跑过一两年账单的人才有体会。2.2 分区策略分区键的层级顺序决定查询扫描量数据湖的分区逻辑是查询性能的命门而且它从“铺路径”那一刻就决定了。常见做法是Hive风格分区S3对象路径写成keyvalue的形式查询引擎通过路径裁剪跳过无关数据。比如订单事件表路径是s3://my-data-lake-bucket/order_events/year2025/month01/day01/part-0001.parquet分区键顺序和层级有讲究。我一般遵循一条原则过滤基数从大到小排列把业务查询里最常过滤的维度放前面。日志和订单类数据几乎都按时间查所以year/month/day比day/month/year合理。查询条件里给了月和天但没给年Athena仍然会扫描所有年份吗会因为第一个分区键是year没过滤就全部扫描。分区键粒度也要控制按小时分区且数据量只有每天几百MB每小时分区会切出大量小目录查询时向S3发几百次List请求慢且贵。2.3 文件格式与压缩Parquet、ORC怎么选铺完目录文件格式决定这桶数据好不好查。对象存储上的主流列式格式是Parquet和ORCAWS生态里出镜率最高的是Parquet。原因很直接Athena、Redshift Spectrum、EMR、Glue都对Parquet的兼容性做得扎实谓词下推和列裁剪都能正常命中。ORC在Hive和Spark里表现同样优秀压缩率和查询性能不输Parquet但如果你的下游主要走Athena我更推荐Parquet少踩格式识别层面的兼容坑。压缩建议用snappy或zstd追求平衡选snappy追求压缩比选zstdgzip在Parquet里压缩率最高但查询时CPU开销大。文件大小也要盯Parquet单文件尽量到128MB上下每个row group按64MB到128MB切查询引擎扫起来才高效。文件太小S3的List请求和Athena的调度开销都会明显放大。2.4 最小落地在Mac上装AWS CLI并铺出第一个分区不管PPT画得多复杂落地的第一步一定是把S3桶和第一个数据目录建起来。在Mac上安装AWS CLI是Windows和Linux之外最常见的工作场景一条命令的事brew install awscli aws configure # 按提示依次输入 AWS Access Key ID、Secret Access Key、默认Region、输出格式aws configure会把凭证写到~/.aws/credentials把默认Region写到~/.aws/config。AccessKey建议用IAM用户的最小权限密钥别把根用户的密钥配到笔记本上后续泄露处理起来很痛。配置完成后建桶并上传第一批数据aws s3 mb s3://your-data-lake-bucket --region your-region-1 aws s3 cp ./order_sample.parquet \ s3://your-data-lake-bucket/order_events/year2025/month01/day01/ aws s3 ls s3://your-data-lake-bucket/order_events/year2025/month01/day01/桶名是全局唯一的重复会直接报BucketAlreadyExists。--region必须和后续Glue、Athena选同一个Region跨Region访问S3不是不行但延迟和请求费用都会上升。上传后分区路径已经就位但这时数据还只是“文件”要让查询引擎认识它得做元数据注册这就是下一章的事。3. 元数据目录与查询引擎用Glue和Athena把文件变成可查询的表3.1 Glue Catalog和Crawler让数据湖先“有目录”S3上的Parquet文件再规整Athena也不会自动知道它的列名和类型。查询引擎需要一个集中的元数据目录里面记录“表有哪些列、文件在哪个S3前缀、分区有哪些”。AWS上承担这个角色的是Glue Catalog它本质上是基于Hive Metastore思想实现的服务。有了目录Athena才能把你的SQL翻译成对S3文件的扫描计划。注册元数据的两种常见方式是Glue Crawler和手动建表。Crawler适合数据源多、Schema相对稳定的场景它会扫描S3路径推断列类型自动往Catalog里写表定义。Crawler有几个关键参数值得盯参数推荐配置说明Include path分区的父目录比如/order_events/别指到单日分区Schema update behaviorAppend-only表选“Add new partitions only”避免每次跑都重刷所有表定义Recrawl policy按需或基于Schedule频繁全量recrawl会拉高成本和S3请求数Table name prefix按业务域加前缀例如ods_、app_方便分类Crawler跑完去Glue控制台的“Tables”里能看到生成的表定义也能看到分区列表。这里注意Crawler推断出的Schema可能和你预期有偏差比如把string推成bigint或者把mapstring,string拆错。我在生产环境里的做法是表定义交给Crawler初始化跑完后人工审查一遍列类型再用ALTER TABLE修正不让它完全放养。3.2 Athena查询引擎与分区投影不跑ETL也能直接查Athena让数据湖的价值立刻兑现你不需要先建一个数仓、不需要把数据搬运一遍只要Catalog里有表定义就能用标准SQL在S3上直接查。执行模式是“扫描再计算”按扫描的数据量计费。所以Athena的性能和成本本质由两个东西决定文件格式和分区裁剪。分区裁剪做得最好的场景是查询条件里带上完整分区键Athena能精准定位到某几个前缀。但在没有Crawler刷新分区的情况下Athena默认要调用GetPartitions拿到全部分区列表再挨个判断。分区多到上千个时这个动作会拖慢查询。这时要打开分区投影Partition Projection让Athena靠规则推算分区路径而不是真正去S3列目录。配置得当扫描量能从“全表”降到“一个分区”。这个优化对日志型数据的价值极大。3.3 一个可执行的建表示例手动建表加分区投影如果你的ETL流程已经能保证按时产出分区文件可以在Glue Catalog里手动建表并直接开启分区投影。下面这个例子把三张日常场景串起来Parquet格式、分区路径是year/month/day、用投影代替Crawler刷新CREATE EXTERNAL TABLE order_events ( order_id string, user_id string, amount double, event_time timestamp ) PARTITIONED BY (year string, month string, day string) STORED AS PARQUET LOCATION s3://your-data-lake-bucket/order_events/ TBLPROPERTIES ( projection.enabled true, projection.year.type integer, projection.year.range 2020,2030, projection.month.type integer, projection.month.range 1,12, projection.day.type integer, projection.day.range 1,31, projection.year.digits 4, projection.month.digits 2, projection.day.digits 2, storage.location.template s3://your-data-lake-bucket/order_events/year${year}/month${month}/day${day} );分区投影的关键在storage.location.template它把查询条件里的值拼成S3路径。digits参数必须和实际路径对齐路径里存的是01投影就得写projection.month.digits 2写成1就匹配不到目录。范围参数range要预留未来年份否则查超出范围的分区会直接报错。这种方式的好处是省掉了每天跑Crawler的麻烦代价是数据文件必须严格落在模板指定的路径路径偏移就得手工改模板。如果表已经由Crawler生成不用重删重建用一条语句补上投影配置即可ALTER TABLE order_events SET TBLPROPERTIES ( projection.enabled true, projection.year.type integer, projection.year.range 2020,2030 );注意ALTER TABLE SET TBLPROPERTIES只能追加或覆盖属性不能自动帮你补齐全部投影字段需要把整套投影参数都写好再执行。配好后跑一次SELECT * FROM order_events WHERE year2025 AND month01 AND day01Athena控制台会显示这次只扫了对应分区的数据不到全表的几十分之一。4. 权限、加密与数据治理给湖加护栏的几种常见做法4.1 Lake Formation与IAM的角色边界数据湖建好以后比“能查数据”更重要的下一步是“谁能查哪些数据”。AWS上的权限模型是分层的IAM管API级别的权限S3桶策略管对象访问Lake Formation管表、列、行级的数据权限。如果团队规模不大、只有几个人用Athena可以只配IAM和桶策略。但只要数据开始分给数据工程师、分析师、外部合作方就一定要上Lake Formation否则权限迟早会变成一团乱麻。Lake Formation的常见配置方式是把S3位置注册进Lake Formation然后通过LF Grants给PrincipalIAM用户或角色分配SELECT权限粒度可以到列级。它和IAM的边界在于LF管“这张表能不能查”IAM管“能不能调用Athena和Glue API”。生产环境的经验是IAM里做粗粒度控制比如给某个角色Athena:StartQueryExecution和Glue:GetTable真正的行列权限全部放在LF里做这样审计和回收权限都集中在同一个面板。这里有个容易绕进去的信任关系问题Athena查询时会扮演执行角色的IAM身份去读S3和Glue这个身份必须被LF授权。如果角色能通过IAM调用Glue API却没有LF的Table Grant查询时会报AccessDeniedException而且报错不会明确告诉你缺的是LF权限排查起来很玄学。先查LF的Grants列表再查IAM策略顺序别反。4.2 S3桶策略与跨账号访问跨账号数据共享是数据湖架构里躲不开的场景生产账号负责采集数据分析账号负责查询。这种情况下不能只给分析账号的IAM用户配权限因为S3桶和生产账号的Glue Catalog并不属于分析账号。要做的配置有三层第一层生产账号给分析账号的执行角色授权S3访问方式是在S3桶策略里允许该角色s3:GetObject、s3:ListBucket。第二层Glue Catalog需要在生产账号里对分析账号角色执行glue:GetTable和glue:GetDatabase。第三层如果启用了Lake Formation生产账号还要在LF里注册分析账号角色作为Principal并Grant权限。桶策略最容易犯的错误是Principal写成账号ID而不是角色ARN。写成账号ID意味着该账号里所有角色都能直接读S3范围过大正确写法是直接指定AWS: arn:aws:iam::123456789012:role/analytics-athena-role把访问限制在具体的执行角色上。跨账号KMS加密桶还要多检查一层Key Policy否则前两层都放行了最后卡在kms:Decrypt上报错信息往往是通用的AccessDeniedException。4.3 加密选项SSE-S3、SSE-KMS与Glue连接数据湖里的数据往往比计算资源更敏感S3桶默认就该开加密。AWS有三种常见方式SSE-S3是AWS托管密钥配置最省事适合明文业务数据SSE-KMS用你自建的KMS密钥支持密钥轮换和访问审计适合有合规要求的场景SSE-C是客户提供密钥流程负担重一般很少用在数据湖里。我推荐默认开SSE-KMS并把密钥策略纳入权限设计。因为开了SSE-KMS之后查询链路上每个环节都要过密钥策略Athena的执行角色要有kms:DecryptGlue Job的IAM角色要有kms:GenerateDataKey跨账号场景还要在KMS Key Policy里显式Allow对方的角色。任何一环漏配查询就失败。排错的时候在CloudTrail里搜Decrypt事件能很快定位是哪个角色没有权限。4.4 权限模型对比选哪种组合更合适控制层管控粒度适合场景常见错误IAM PolicyAPI级别、资源级别控制谁能启动查询、读写哪个桶漏掉s3:ListBucketGET有权限但LIST没有S3 Bucket Policy桶级、前缀级跨账号授权、开放只读Principal写成账号ID而不是角色ARNLake Formation表级、列级、行级数据团队内部精细化授权忘记注册S3 location授权不生效KMS Key Policy解密、生成数据密钥加密审计、合规要求未给Athena角色kms:Decrypt小团队起步阶段IAM加桶策略就够用了。规模上来之后再平滑迁移到Lake Formation不要让权限模型一开始就铺得过重否则维护成本会压过收益。5. 数据湖架构常见踩坑分区爆炸、小文件与成本失控5.1 小文件太多查询越跑越慢账单越来越贵现象表每天写入的数据量不大但文件数以千计每个文件只有几十KB。Athena查询一个月的订单数据要花几十秒甚至几分钟账单里S3请求费用和Athena扫描费用同时上涨。原因对象存储和查询引擎都喜欢大文件。Parquet的row group默认目标接近128MB大量小文件会让Athena启动大量Task去分别打开和扫描调度开销超过实际读取开销。数据如果是从Kafka或业务库直接同步到S3常常一个批次就落一个小文件日积月累就成了“文件碎片化”。解决写入侧尽量攒批把数据在内存里聚合到单个文件接近128MB再落S3。已经碎了的做一次compaction用Spark或Glue Job读入分区数据重分区后覆盖写回df spark.read.format(parquet).load( s3://your-data-lake-bucket/order_events/year2025/month01/day01 ) df.repartition(4).write.mode(overwrite).format(parquet).save( s3://your-data-lake-bucket/order_events/year2025/month01/day01 )repartition的并行度按分区总大小除以128MB估算。比如分区里原始文件共400MB设4到5个分区就能压到单文件接近100MB。执行compaction前先确认分区数据没有正在被生产任务写入避免覆盖掉未落盘的新数据。更好的做法是把compaction任务排在业务低峰期并且只重写近一周的热分区。5.2 分区键顺序与路径不匹配预览表没事生产查询扫全表现象建表时把路径设计成day01/month01/year2025表能查到但生产查询一旦过滤year和monthAthena的扫描量还是全表。原因Hive风格分区的路径裁剪严格依赖目录层级。查询引擎按PARTITIONED BY里的列顺序逐级匹配路径如果分区键和路径顺序不一致或者路径里有脏目录比如_rescue/、临时目录Athena会退化成扫描父目录下所有子前缀。解决在建表阶段就把路径固定成year/month/day这种基数从大到小的层级。如果表已经建错最省事的做法是重建整张表并做一次数据目录迁移而不是试图让查询引擎容忍乱序路径。检查路径是否干净用一条CLI命令aws s3 ls s3://your-data-lake-bucket/order_events/year2025/month01/ --recursive输出里凡是看到非day开头的对象比如_tmp/、date2025-01-01/都会干扰分区裁剪。这些目录要清理掉或者用表属性把无效分区排除在外。路径问题拖得越久修起来越痛因为还要考虑下游报表已经依赖了旧的表名。5.3 Crawler不回补新分区查不到当天数据现象生产任务每天往S3写新日期的分区文件Crawler也按Schedule跑了但Athena查询当天数据一直是零行。手动执行Crawler一次有时候又好了。原因Crawler的Schema update behavior没有覆盖新增分区的情况。配置里选了Update the table definition但Recrawl policy设成了“只在表结构变更时重爬”新增分区这种“数据变更”不会触发它的重爬逻辑。另一个常见原因是Crawler的Include path指到了具体分区目录比如/order_events/year2025/month01/第二天新月份目录一出现这个路径下根本没有新分区。解决把Include path指到分区父目录即/order_events/让Crawler能扫到新增的月份和日期层级。Crawler执行频率按分区产出频率定数据每天凌晨产出就每天早晨跑一次Crawler没必要小时级频繁爬。如果急着跑一次查询可以用Athena手动修复分区MSCK REPAIR TABLE order_events;MSCK能扫描S3位置下所有符合Hive风格路径的分区并注册到Catalog比重新跑一遍Crawler更快但前提是路径命名规范完全匹配。这个命令在日常排错里相当于后悔药推荐先记住它。5.4 权限配置“能打开文件但查不了表”Athena数据目录权限的信任链条现象用IAM用户登录AWS控制台能看到S3里的Parquet文件也能在Glue Catalog里看到表定义但一跑Athena查询就报错错误信息是通用权限拒绝日志里看不出到底卡在哪一环。原因Athena查询的权限链路比表面复杂首先要能调用Glue API读取表定义然后要能通过Lake Formation的Table Grant最后还要能读S3文件。任何一个环节有问题都会报成一样的拒绝错误。最常见的是执行角色只有s3:GetObject没有glue:GetTable和glue:GetDatabase而控制台手点操作时用的是人的IAM权限和Athena执行SQL时用的角色权限不是同一套。解决找到Athena工作组的执行角色给它补上Glue的只读权限和LF的SELECT授权。下面这个策略是Glue部分的最小组件{ Version: 2012-10-17, Statement: [ { Effect: Allow, Action: [ glue:GetDatabase, glue:GetTable, glue:GetPartition, glue:GetTables, glue:GetDatabases ], Resource: * } ] }在Lake Formation侧还需要确认这个角色被Grant了对数据库和表的DESCRIBE与SELECT权限。排错顺序建议先用同一个角色在Athena里跑一条最简单的SHOW CREATE TABLE order_events能过说明Glue权限通再跑SELECT count(*) FROM order_events WHERE ...能过说明LF和S3都通。哪一步挂了就修哪一环比直接翻IAM整整快半小时。6. 进阶把数据湖跑稳的验证手段与三个日常习惯6.1 用EXPLAIN ANALYZE定位到底扫了多少数据不要等月底账单出来才被扫描量吓一跳。Athena的SQL前加上EXPLAIN ANALYZE就能在查询计划里看到实际的扫描字节数比CloudWatch上翻指标直观得多EXPLAIN ANALYZE SELECT user_id, count(*) FROM order_events WHERE year2025 AND month01 GROUP BY user_id;返回结果里重点看两个数字Scan data和Partitions scanned。如果Scan data明显超过目标分区的大小优先怀疑分区投影没有生效或者路径里有多个分支。养成每次新写查询先做一次EXPLAIN的习惯防的是“凭感觉觉得查得快”。6.2 每周做一次compaction数据湖不用每天过度维护但每周一次的compaction值得固定下来。我的做法是建一个定时Glue Job扫描最近七天有数据写入的分区目录找出文件数超过100或平均文件大小低于64MB的 abnormal 分区重写一遍。Spark重读再重写的方式最直接代价是扫描一次数据对于活跃业务分区这个成本完全可以接受。做了compaction后Athena上的月查询速度提升肉眼可见账单也会跟着降。6.3 给关键路径加成本告警每条查询都控制是不现实的但“兜底告警”可以有。在AWS Budgets里给Athena服务和S3的请求费用设置预算阈值设到预估月成本的80%。另外给不同的业务表打上不同的Cost Allocation Tag例如tableorder_events月底看Cost Explorer时能直接看出哪个业务域最烧钱也好在复盘时找到元凶表。做数据湖架构这几年我最大的体会是一个能写进PPT也能真正跑稳的架构不是靠一开始设计得尽善尽美而是把“新分区有没有注册、小文件有没有合并、扫描量有没有异常”这三个动作变成习惯。这套流程能帮你避开大多数半路翻车的问题希望帮到你。本文还有配套的精品资源点击获取