type
status
date
slug
summary
tags
category
icon
password
本文写作于 2025 年 8 月,截止到写作时间点为止,AWS 考试体系中涉及数据工程和机器学习的有 AIF、DEA、MLA、MLS 四部分和 SAP 的少部分问题。
本文知识总结自 DEA/MLA/MLS 的教学课程,梳理了其中我认为重要的考点,并不能覆盖整个考试的知识面,也不代表错题库。
并且,本文内容不牵扯统计机器学习与深度学习算法,也不涉及AIF中的大模型部分,目光基本只聚焦于 AWS Infra 方面以及少量的数据处理技巧。因为如果要写那个领域的东西,实在是篇幅和精力有限,而且现在已经有很多优秀的材料可以参考了,严格来说那也不属于 AWS 的范畴,那些 10 年前很流行的知识现在也是 PhD 们的必备技能了,我没有必要为此再整理一遍。
本文内容的正确性与非过时性都经过了 GPT-5 核查,但我无力随时更新这个总结,随着 AWS 技术本身的演进,其中的一些说法难免会和事实出现偏差,阅读时请注意这一点。
1. 数据接入 ——Kinesis Data Streams(KDS)
- 关键词:实时性
- 数据保持
- 数据最多保留 365 天
- 可以重放数据流
- 一旦数据进来了则不可变,无法删除,必须等过期
- KDS 是 Region 级服务,分片位于 AZ 内,KDS 到 VPC 内 EC2 的流量使用 VPC 终结点提供的 HTTPS,静态数据使用 KMS 加密
- 数据分片
- 分片由唯一 ID(shardId)标识,并有固定的哈希键范围,Partition Key 经过哈希后落在哪个范围,就进入对应分片
- 进入 KDS 的数据,由分片 Key 和二进制数据组成,从 KDS 读取的数据,由分片 Key、位置和二进制数据组成
- 分片数决定流量,假设每秒有 6M 数据流入,则需要 6 个分片支撑生产端,每个消费者可以按照 2M/s 的速度读取数据
- 当数据传入 KDS 时可以增加一个 Partition Key 在消息之间共享,同一个 key 的消息会进入同一个分片
- 分片扩容问题
- 假设有 1、2、3 三个分片,其中 2 中的数据量很多,那么可以把 2 的数据分别写入 4、5 分片,分片 2 将在数据过期后消失,这样就有了 1、4、5、3 分片,吞吐量得到了增加,这就是分片的分裂。同样,可以通过合并分片的方式减少成本
- 为了防止在分片过程中读取顺序发生混乱,建议首先读取老分片直到读完,再去读新分片的数据,KCL 已经内置了这种逻辑
- 大量分片数的扩展、缩小是相当耗时的,建议提前规划容量,并考虑自动扩容
- 数据重复问题
- 在生产端,KDS 不会自动去重,有时候因为 KDS 返回给客户端的 ACK 由于网络超时没有到达,数据会发送第二次,导致 KDS 中重复写入数据。解决方法是在数据内部添加唯一 ID
- 在消费端,可能由于分片扩展等多种因素导致客户端读取两次数据,没有很好的解决办法,建议让程序本身保持幂等性,以及在数据库级别进行重复对应
- 生产消费模式
- 生产端
- 生产者
- 在服务器上安装的 Kinesis Agent
- 程序里的 SDK,复杂编程下的 KPL
- 第三方库,如 Spark 和 Kafka 写入
- SDK
- 生产端 SDK 存在 PutRecords API 进行同步发送,会立刻发送数据,适合 IoT 这种无法容忍发送延迟或批量失败的情况
- KPL 客户端
- 是个 Java/C++ 库,分为同步和异步 API
- 可以直接发送指标,以便 CloudWatch 随时监控它
- 它支持两种批处理机制并且默认开启,具体的参数可以配置
- 支持将多条用户记录聚合成一条 Kinesis Record(Aggregation)
- 支持将多条 Kinesis Record 在一次 Put 请求中批量发送(Batching)
- KPL 不支持数据压缩,必须手动实现,并在 KCL 里手动解压
- Agent 内部使用的是 KPL
- 当写入超过负载时的对策
- 采用指数退避方式重发
- 增加分片数量
- 检查 Partition 不合理导致的数据倾斜
- 消费端
- 消费者
- 程序里的 SDK,复杂编程下的 KCL
- 整合 Firehose、Lambda 等服务
- 第三方库,如 Spark
- 吞吐量整理
- 写入吞吐量
- 在配置模式(Provisioned Mode)下,支持 SDK 和 KPL,每个分片吞吐量 1MB/s 或 1000TPS,按分片线性叠加,KPL 只是批处理优化
- 在按需模式(On-demand Mode)下,支持 SDK 和 KPL,总吞吐量从 4MB/s 或 4000TPS 动态扩容,根据过去 30 天的使用情况自动调节
- 读取吞吐量
- 如果不开启增强扇出,支持 SDK 和 KCL,所有客户端共享每个分片 2MB/s 的总吞吐量,每个消费者会轮询多个分片,每次最多拉取 10MB 或 10000 条记录,每个分片每秒最多可以被 Get 5 次,这意味着每次 get 之间会存在 200ms 的延迟
- 如果开启增强扇出,只支持 KCL(HTTP2 实现),消费者之间不会共享 2MS/s 的总带宽,而是各有各的限制,同时 get 之间的延迟降低到 70ms,默认最多支持 20 个消费者,这个数字可以申请提高
2. 数据接入 ——Kinesis Data Firehose(KDF)
- 关键词:把数据从一个地方发送到另一个地方
- 适用场景
- 日志收集与归档(如从 CloudWatch Logs → S3)
- IoT 或 Web 应用实时事件流入数仓
- 数据落地前进行格式转换、压缩、清洗
- 将 KDS 数据实时推送到 Redshift/OpenSearch
- 数据源
- 应用程序(通过 API)
- Kinesis Data Streams(KDF 从 KDS 拉取数据)
- AWS 服务:CloudWatch Logs、IoT Core 等
- 第三方系统(通过 HTTP Endpoint)
- 目的地:
- AWS 内置目的地:
- Amazon S3(最常见,可与 Athena/Glue 配合分析)
- Amazon Redshift(通过 S3 中转加载)
- Amazon OpenSearch Service
- Amazon Splunk(实时日志分析)
- 第三方目的地:
- HTTP Endpoint
- 部分 SaaS(通过 API Gateway 或 Lambda 处理后发送)
- 数据格式支持:
- 支持 JSON、CSV、Parquet、Avro(Parquet/Avro 仅在 S3 目标中支持)
- 压缩:GZIP、ZIP、Snappy(Parquet 专用)
- 数据处理:
- 可选 Lambda 转换
- 每批最多 6MB 数据
- 转换失败的数据可进入错误输出(S3)
- 超时或异常将触发重试或落入备份
- 缓冲机制
- 基于时间:最小 60 秒,最大 900 秒
- 基于大小:最小 1MB,最大 128MB
- 注意:
- 缓冲不可完全禁用,但可将参数设到最小值以接近实时传输
- 到达时间阈值或大小阈值时立即发送数据到目的地
- 不能回放数据,流经即消费
- 错误处理与备份
- 失败重试机制:
- 最长重试 24 小时
- 超过重试窗口后仍失败的数据会直接落到 S3 备份桶
- 备份选项:
- All records:所有经过 Firehose 的数据都会备份到 S3
- Failed records only:仅备份写入失败的数据
- 吞吐量与性能
- API 写入限制:
- 单条记录≤1MB
- 批量≤500 条,且总大小≤4MB
- 默认写入速率(同步 API 调用):
- 每个交付流最高 5000TPS 或 5MB/s
- 自动扩展(异步输入时可更高)
- 延迟:
- 取决于缓冲设置(通常 60 秒~数分钟)
3. 数据接入 ——MSK(Kafka)
- 关键词:AWS 托管的 Apache Kafka 服务
- MSK 最多部署三个 AZ 实现 HA,数据存储在 EBS 上
- 可以通过配置支持传输 1MB~10MB 的消息,而 KDS 有 1MB 的硬性限制
- 在加密方面,MSK 的 Broker 之间支持通过 TLS 加密,Broker 对应的 EBS 也支持 KMS 加密,但是为了效率可以禁用
- 在认证方面,支持双向 TLS 和 SASL/SCRAM(这些不能被 IAM 策略管理,必须在 Kafka 集群里定义)
- 在监控方面,支持 CoudWatch,支持开源监控,支持 Broker Log 传输到 CoudWatch 或 S3 以及 KDS
- MSK Connect 是一个插件,用来从 Kafka 集群读取数据到 S3 等地方,按 worker 和小时数收费
- MSK Serverless 可以自动扩展,不用认为控制,但是有 558 刀的基础月费还要收流量费
4. 数据加工 ——Glue
- ETL Job
- 支持使用 Spark 进行 ETL,并且是无服务器的
- 如果 Glue 运行过慢,需要增大 DPU 数
- 错误会报告给 CloudWatch
- 可以配置为事件驱动或者按时执行
- bookmark(书签)是 Glue ETL 任务中用于增量数据处理的机制。它的作用是记录上一次 ETL 作业处理的数据位置或状态,从而在下次运行时,只处理新增或变化过的数据,而不重复处理历史数据。仅在某些源 / 目标格式和 Glue DynamicFrame 转换中有效。
- Studio(面向开发者)
- 是一个基于 Jupyter 的 IDE,适合做探索数据分析
- 可以以可视化的方式编写 ETL 流程而无需代码,可以根据流程生成 Spark 代码
- DataBrew(面向分析师)
- 以 UI 的方式做数据预处理的工具,但其背后运行的并不是 Spark 代码
- 可以做归一化、空值填充等 250 多个任务
- 支持处理 PII(个人信息)
- Data Catalog
- 数据目录工具
- 可以使用 Data Catalog 充当 Hive 中的元数据,也可以将 Hive 中的元数据导出给 Data Catalog
- Data Catalog 有分区概念,能对应 S3 的前缀(Hive 风格分区)
- Crawlers
- 可以在 S3、Redshift 或 RDS 上创建爬虫程序,将数据模式提取到 Catalog 里
- 可以定期爬取
- Data Quality
- 是一个保障数据质量的部分,如果发现数据质量违规,可以停止 job 或者发送给 CloudWatch
- Workflow
- 是一套数据处理调度工具,可以编排 Crawler → Job → Trigger 等 Glue 任务
5. 数据加工 ——EMR
- 在 EMR 中,Master Node 是控制中心,Core Node 里面装有 HDFS,Task Node 不装 HDFS,Task Node 建议使用 Spot Instance。EMRFS 是允许 EMR 直接访问 S3 存储作为持久层的文件系统实现的工具
- EMR Serverless 将自行决定执行任务的节点数,能解决 Spark 没有提前规划好内存大小导致任务失败的问题,可以设定初始和最大情况下的 Capacity
- EMR Serverless 并没有公开底层架构,但是有 EMR on K8S 的选项
- EMR Serverless 和 S3 之间的通信可以强制使用 TLS 加密
6. 数据存储
- Redshift
- 数据加载
- S3→Redshift:支持自动加载(包括 COPY 命令批量导入),可在导入时解密文件
- Aurora→Redshift:支持 Zero-ETL 自动同步数据
- PostgreSQL→Redshift:可通过 DBLINK 连接并直接查询 / 导入数据
- 支持批量从 S3 导入数据(效率高、可并行处理),支持数据解密、压缩格式(GZIP、BZIP2 等)解析
- 数据分散风格
- AUTO:让 Redshift 自动选择并动态调整分布方式(推荐)
- EVEN:按行均匀分布到所有节点
- KEY:按指定列的哈希值分布,减少连接时的跨节点传输
- ALL:将小表完整复制到所有节点,适用于频繁 JOIN 的小型维度表
- VACUUM 的类型
- VACUUM FULL(默认):回收所有被删除的行并重新排序
- VACUUM DELETE ONLY:仅回收被删除行的空间
- VACUUM SORT ONLY:仅重新排序,不回收空间
- VACUUM REINDEX:重新生成索引并排序(很少使用)
- 查询与视图
- 物化视图(Materialized View)
- 保存查询结果及中间数据,提高查询速度
- 存在数据同步延迟,需要手动 REFRESH 或启用 AUTO REFRESH
- 联合查询(Federated Queries)
- 从 Redshift 查询外部数据库(PostgreSQL、Aurora 等)
- 通过外部表(External Table)使用外部数据
- 要求目标数据库与 Redshift 在同一 VPC 或通过 VPC Peering 连接
- 使用 Redshift 自身的计算资源
- 开发与集成
- Lambda 函数集成
- Lambda 可作为 Redshift 的 UDF(用户自定义函数)或过程调用
- Redshift Data API
- 基于 HTTPS 的 SQL 执行接口,无需 JDBC/ODBC 驱动即可从任意地方执行 SQL
- 适合无持久连接环境(如无服务器应用)
- LakeFormation
- 概述
- 基于 Glue 之上构建的数据湖管理服务,可快速在 S3 上搭建数据湖
- 统一管理数据的存储、访问权限、治理与安全
- 数据导入与存储
- 支持从多种数据源导入(RDS、DynamoDB、本地文件、流数据等)
- 数据会被同步 / 导入到 Amazon S3
- 自动执行数据压缩和格式转换(如 CSV → Parquet/ORC)以节省空间和提升查询性能
- 查询与集成
- 数据湖中的数据可直接通过 Amazon Athena、Amazon Redshift Spectrum、EMR/Spark 等查询
- 与 Glue Data Catalog 紧密集成,元数据统一管理
- 数据治理与安全
- Governed Tables(受管表)
- 提供 ACID 事务支持,解决多用户并发写入冲突
- 支持时间旅行(Time Travel)与回滚操作
- 细粒度访问控制
- 基于 IAM 和 Lake Formation 权限模型,支持列级访问控制
- 使用数据过滤器(Data Filter) 实现行级访问控制
- 列级与行级结合,可精确到单元格级别控制访问
7. 数据查询
- Apache Flink(MSAK) / Kinesis Data Analysis(KDA)
- 是流处理框架,数据源:KDS、MSK(Kafka),不支持 KDF
- KDA 的 for SQL 的服务,可以写 SELECT STREAM 语句读取 KDS 缓冲区里的内容,也可以结合 Lambda 把数据发送到任何地方,它正在被 Flink 取代,相比之下 Flink 是无服务器的,也可以使用表 API 做同样的事情
- QuickSight
- 是个基于用户收费的 SaaS 服务,支持探索机器学习的维度,比如用随机砍伐森林找离群点
- QuickSight 可以在查询时在分析视图中派生字段,并能基于查询引擎 SPICE 或直接查询数据源来做聚合、窗口函数等
- Athena
- 性能优化建议
- 推荐使用 ORC 或 Parquet 格式以获得更高性能和更低成本
- 文件组织上建议少量大文件优于大量小文件,以减少扫描开销
- 核心功能
- CTAS(CREATE TABLE AS SELECT):可直接读取 S3 数据并根据查询结果创建新表(原表的子集),查询结果会写入新的 S3 位置
- 工作组(Workgroups):控制查询权限,设置数据扫描量配额,限制和监控查询成本
- Iceberg 支持(ACID 特性)
- Iceberg 是一个不改变底层存储的数据表元数据层
- 作用:让数据湖具备数据仓库的管理特性,分离数据与元数据,保证不可变性与版本控制
- 架构位置:位于 Glue(Spark)与 S3/Data Catalog 之间,Athena 建表时可选择 Iceberg 作为底层元数据实现,Data Catalog 只是 Iceberg 的后端之一
- 在 Jupyter Notebook 中运行 Athena 查询时,可选择 Athena SQL 或 Spark SQL 作为底层执行引擎
- 跨源数据访问
- 通过 Data Source Connectors 连接 RDS、CloudWatch 等数据源
- 支持自定义 Connector,实现对 BigQuery 等第三方数据源的查询
8. 数据迁移
- Application Discovery Service
- 在迁移前发现和分析本地应用与服务器信息
- 分为有无 Agent 两种发现方式
- 无代理方式提供关于虚拟机的信息,比如配置、历史性能记录,CPU 内存硬盘等
- 代理模式能获取更多信息,比如运行的进程、网络连接等信息
- 可以通过 AWS Migration Hub 服务集中观察这些信息,来发现你真正需要搬运上云的服务,以及它们是怎么联系的
- MGN(Application Migration Service)
- 将本地服务器迁移为 AWS 上的 EC2
- 做法是在本地机房安装 MGN 代理,它会拷贝机器生成 EC2 和 EBS 卷
- DMS(Database Migration Service)
- DMS 数据库迁移服务保证数据库在迁移时可用
- 支持同构和异构数据库迁移
- 异构迁移需配合 SCT(Schema Conversion Tool)转换架构
- 支持 CDC(Change Data Capture)捕获实时变更
- DMS 支持多 AZ 部署提供弹性
- DataSync
- 跨机房或异构系统迁移时需要 DataSync Agent
- AWS 内部(S3、EFS、FSx 等)迁移无需 Agent
- 可以定义按时间计划同步数据
- 保留文件的元数据(权限、时间戳等)
- Transfer Family
- 把数据以 FTP 协议形式传输到 S3、EFS
- 让 Route53 给 Transfer Family 提供一个 DNS,让用户通过它访问
9. 数据标注
- 标注者
- Amazon Mechanical Turk(AMT)(公开众包)
- Private Workforce(私有劳动力)
- Vetted Vendors(Amazon 预选供应商)
- Ground Truth 支持 “自动标注 (auto-labeling)” 模式,先人工标注一小部分数据,然后用该数据训练模型,再用模型推测剩余数据(主动学习)
- 标注流程
- 传图或文本到 S3
- 使用 GroundTruth 生成一个不带结果标签的清单 jsonl 文件
- 发送工单,执行手工标注后,会在 S3 里生成 jsonl 文件,里面有标签
10. 特征处理
- Data Wrangler
- 这个工具加速了数据探索和准备的过程,让 ETL 变得简单
- 它无需代码,数据源也可以选择 S3 或 Redshift、Athena、Snowflake 等
- 它提供了 300 多种数据转化服务,比如缩放、独热编码或处理缺失值,并且可以编辑成管道
- 可以把 ETL 代码导出到笔记本中,相比之下,DataBrew 为数据分析师而生,无法导出为兼容 Pandas 或 Spark 的代码
- 坑:Data Wrangler 不适合直接做海量数据上的特征工程,毕竟它底层还是 pandas
- 通常建议抽取不超过 5G 的数据做特征工程
- 之后导出脚本 jupyter notebook 或 Glue Job 进行大规模处理
- 注意点:Spark 里可以通过 SageMaker SDK 调用 SageMaker 做 ETL,比如添加聚类特征等
- 但反过来 SageMaker 通过 PySpark 调用 MLLib 是非主流的用法,ETL 过程的事情不应该在训练阶段做
- Feature Store
- 相当基于原先的数据集生成一张新表保存特征
- 可以把特征保存在 S3 里做训练
- 它不是实时计算平台,做预测时不会动态计算新数据的特征,而是一个预处理结果的存储库
- 需要对新数据重新做预处理
- 特征工程
- 处理缺失值
- 对于数字类列,可以使用列的平均数或中位数替换,后者可以防止离群值干扰
- 对于非数字列,可以删除行(如果行数不多)但这种方法可能带来偏差,也可以用 K 临近插值但需要评估合理性
- 处理不平衡数据
- 欠采样:少抽取多数例子,试图让正反例子均衡,但这可能打乱数据分布
- smote:用 knn 插值插入一些和少数样本相似的样本
- 结合预测需求调整判断阈值,防止假阴性或假阳性
- 处理离群值
- AWS 有自己的算法 —— 随机砍伐森林算法 (RCF)
- 特征工程其他技术
- Binning:数值范围转分类
- Transforming:将数值转化为平方、平方根、对数等形式
- Encoding:独热编码,多分类列转 0000100 型态的多列
- Scaling、Normalization:将特征压缩到较小的数值范围内让模型容易收敛
- Shuffling:让训练数据随机进入模型训练
11. 模型训练
- SageMaker
- SageMaker 工具细节
- SageMaker 目前提供了和 sklearn 不同的 20 多种算法,适合大数据分布式学习,以及与 AWS 其他服务的集成(快速部署,AB 测试等),SageMaker 底层使用的是分布式格式,数据输入格式是 RecordIO、Parquet、CSV 等
- 每次运行 estimator.fit () 时,SageMaker 都会根据用户需求启动 EC2 上的容器,并把结果写回 S3 里
- 使用 SageMaker 需要导入 sagemaker_session,并指定 S3 存储桶、子文件夹和执行 role
- 在模型训练完成后,可以部署成为一个 API,对小数据进行实时计算
- 部署后,模型会出现在 AWS 网站控制台的 Endpoint 里(本质还是 EC2),它可以开放给外部使用
- 用户在 SageMaker 中做的所有操作,包括训练的结果,都会被记录到 CloudWatch Logs 中
- SageMaker 笔记本可以接受 KMS 加密,可以加密训练节点间的通信,但是会带来时间开销
- Warm Pool 指的是一种训练作业实例复用机制,让你在多次训练之间保留已经启动好的计算资源,从而减少每次启动的等待时间,不要每次 fit 都去启动容器
- 可以选择使用 Spot 实例减少开销
- Spot 虽然省钱但是可能会被回收,这就意味着省钱的代价可能是更花时间,需要增加检查点
- 利用 Checkpointing 在训练中插入检查点,处理任务的中断和自动重启
- SageMaker 的内置机器学习算法支持分布式训练,类似 MR 的方式分布式了梯度计算
- 关于深度学习
- 深度学习算法受益于 GPU 类型的实例,比如 P3 或 G4,推理类的可以用更便宜的 C5 或 M5
- 在一个实例里使用多 GPU 训练,效果比在多实例里分别使用一个 GPU 开销小,但是事无绝对
- SageMaker Training Compiler 是编译器层面的训练优化,专门用来优化深度学习算法,号称能提高 50% 训练速度,但是和 SageMaker 内置 ML 算法不兼容
- SageMaker 提供了强化学习服务,基于 tensorflow 和 MXNet 实现,训练可以被分发到集群
- EFA 是一个连接到 EC2 上的网络接口,用于 HPC 领域,能提供很强的网络带宽优化机器学习速度
- MiCS(最小化通信规模)是减少不同节点间通信规模的技术
- 网络配置
- 笔记本默认跑在公网,也可以使用私有 VPC 训练,但是需要 S3 终结点保证数据通信
- 通常关联一个 EFS 文件系统,用于存储 Studio 用户的 notebooks 和文件数据
- 一个 SageMaker Domain 配置时必须指定一个 VPC 及其子网,通过子网来控制 Internet 和 EFS 的访问权限
- 可以是两个 VPC,一个子网配置有 NAT 网关以支持 Internet 访问,另一个子网用于访问 EFS 文件系统。Studio 用户可以被分配到不同子网,以实现隔离或网络访问控制。
- 角色配置
- SageMaker Role Manager 是一个用来建立机器学习角色和职责的工具,以可视化的方式分离用于写代码的角色、用于训练的角色、用于部署的角色等
- Debugger
- 定期保存模型状态,返回查看训练期间的中间参数,以及系统资源,也可以自动发现过拟合、类别不平衡、梯度消失等问题
- 可以和 CloudWatch 联动,还提供了 Insight 仪表盘可视化监控
- Training Job
- 是在托管环境中执行一次完整的模型训练任务,免去手动配置计算资源和训练环境的步骤,支持内置算法或自定义脚本,但是依然要手动做特征工程和调参等
- 选择训练数据测试数据和 output 的 S3 路径,并且选择一个算法,配置一些简单的参数即可执行训练任务,无需编写代码,输出一个模型压缩包
- 可以在 CloudWatch 里看到对模型评价的各种参数
- 可以克隆任务用来修改超参数重新执行
- 可以把模型部署到 Endpoint 上
- JumpStart
- 是 SageMaker Studio 的一部分,是一个提供了市面上数百个预训练好的模型的仓库
- 可以选择现成的模型,上传数据,即可直接通过界面训练,以及部署 Endpoint,无需写代码
- 它的本质是对 Training Job 的包装,但是更适合粗粒度快速部署使用 ML 模型
- AutoGluon
- 只是一个单纯的 AutoML python 库,可以脱离 SageMaker 单独使用
- 它能用少量代码训练多种模型,甚至自动做特征工程,并给出在各种评价指标下每个模型的表现
- Autopilot
- 只要告诉平台数据和输出路径,选择任务类型,配置一些简单的参数,就能自动使用多个模型训练,它会自动做特征工程、超参数调优等 AutoML 工作
- Autopilot Explainability 功能用于提供自动 ML 结果的可解释性报告
12. 模型调整
- 超参数调整的方法有网格搜索,随机搜索和贝叶斯优化,还有其他优化器
- 贝叶斯优化是对优化过程的建模,基于历史智能选点,精准、训练次数少,但是实现复杂,对高维不友好,适合于成本高、不宜多次尝试的场景
- 更好的方法叫 Hyperband,它比贝叶斯优化快 5-30 倍,更适合调优代价高的深度学习。这两个一个像智能决策者,一个像高效筛选者
- 注意点
- 不要一次调整太多的超参数,优先调整对模型影响最大的超参数
- 如果超参数调优没能达到预期效果,可以设置提前停止,也可以从中断处热启动
- 偏差是模型太 “傻”,方差是模型太 “神经”,两者都会导致模型泛化能力差
- 偏差是模型预测值与真实值之间的系统性误差,起因是模型太简单假设太强,导致训练误差和测试误差都偏高
- 方差是模型在不同训练集之间预测结果的变化程度,起因是模型太复杂过度拟合训练数据,导致训练误差很低但测试误差很高
- 控制方法
- 使用更复杂的模型(深层网络等),降低偏差,提高方差,提升拟合能力,但更容易过拟合
- 强力的正则化(L1/L2、Dropout 等),可能会提高偏差,但可以降低方差,防止模型对训练数据过拟合
- 增加训练数据,不影响偏差,降低方差,提升模型对数据分布的理解
- 交叉验证,评估并减少方差,稳定模型在不同数据集上的表现
13. 模型部署
- 基本上 SageMaker 的自己训练的每个模型和部署都需要托管在一个 ECR 注册的容器中
- 也可以自己写一个特定格式的容器交给 AWS
- Model Registry 是对模型进行版本管理的工具
- 是对已注册到 SageMaker Model Registry 的模型版本进行集中管理,用于在不同应用中共享模型,也可以用在 CICD 中
- 模型可以通过 Endpoint 部署,接口分几种类型
- 实时接口:背后是 EC2
- Serverless 接口:需要配置内存,有冷启动慢问题,底层是自动扩缩的容器
- 异步接口:如果要处理的数据很大最大 1G,可以先放入 S3,然后告知异步接口,在 SQS 排队消化 job 后放入结果 S3
- 批处理转换:前面三个用来处理单个数据,这个用来处理数据集,也是走 S3 的构造
- SageMaker Inference Recommender 能提议使用哪一种实例更好,用来满足 SLA
- 在推理过程中可以配合 CloudWatch 进行节点的 AutoScaling,也可以通过跨 AZ 实现高可用
- 部署护栏可以部署到异步或实时推理终结点,它可以把流量切换到另一个模型上,用来做蓝绿部署,它分为一次性、金丝雀、线性三种方式
- 影子测试会复制流量到两个模型上同时运行预测,并监控结果,与现行环境做比较
- Warm Pool
- 训练完的实例可以放入 Warm Pool,这将保留 Instance,来减少冷启动时间
- SageMaker Neo
- 是一种将模型部署到边缘位置的服务,它负责把模型编译成适合特定硬件架构的格式,可以和 IoT Greengrass 一起使用
- SageMaker ML Lineage Tracker(机器学习谱系)自动记录和追踪整个机器学习生命周期中资源之间的关系和依赖,实现模型可追溯、可复现、审计等需求,非常适合规范化 MLOps 流程
- SageMaker Pipeline 是做 MLOps 流水线的工具,支持用 python 代码定义 DAG 形成机器学习流水线,使用 EventBridge 可以触发 Pipeline
- MLFlow 是管理整个 ML 生命周期的开源工具,与 SageMaker 集成
14. 模型解释和监控
- Clarify 用于解释模型为什么做出了某种判断,用于审计
- 可以分析训练数据中是否存在标签不平衡和特征类别分布不均的问题
- 能解释各个特征在预测中的重要性
- 能衡量数据在不同维度上的分布差异
- 可解释每个要素占比如何,或者检测某个要素的整体判定倾向如何,比如女性就如何如何
- SageMaker 模型卡片和 Dashboard 用来让人审计模型
- Model Dashboard 是模型上线后的整体监控面板
- Model Monitor 在模型上线后可以添加报警,能检测到数据漂移,错误率增长等指标
- 当模型出现数据异常或者预测异常,会发出 CloudWatch 警报
- Model Monitor Data Capture 可以把从 Endpoint 新进来的预测数据和输出结果保存到 S3 供后续使用
15. AWS 托管的高级 ML 服务
- Comprehend
- NLP 服务,识别语言,识别敏感信息,理解语气
- 名词提取,事件提取(比如 IPO 和破产)
- 可以将 S3 上的数据批量交给 Comprehend 做判断
- 可以进行骚扰及仇恨言论的毒性检测并标红
- Polly
- 文本转语音服务,可以定义词汇表,如看到 W3C 则读成其他读法
- Transcribe
- 语音转文本服务
- 可以识别语言,自动剔除敏感信息,可以自定义词汇表,如【AWS】用于特定领域演讲
- 适合客服语音转录,自动生成 CC 字幕等场景
- Translate
- 机器翻译服务,支持传入自定义词汇表文件
- Comprehend Medical,Transcribe Medical
- 医疗文本分析服务,医疗语音转文本服务
- Rekognition
- 从图片中识别内容
- 图片语义识别,图片文本提取,人脸识别
- 图片内容审核,图片生成时的辅助审核
- Textract
- 文本识别工具,比如提取卡片上的文字,读取财务发票,提取 PDF 文本等
- Contact Lens
- 帮助呼叫中心转录语音,进行 NLP 分析
- Kendra
- 企业内部的知识搜索服务,可以链接 SharePoint 和 S3 等
- Amazon Q Business
- 基于公司知识库的大语言模型,回答公司内部问题,类似于 RAG
- 建立在 Bedrock 之上,无法选择基础模型(今后可能会支持),可以限制敏感话题
- 它拥有插件,可以和外部服务沟通,比如 Slack
- 这个软件有泄露公司秘密的风险,所以用 IAM Identity Center 单点登录
- Monitron
- 端到端的传感器服务,收集振动之类的数据
- Panorama
- 端到端边缘计算机视觉服务,即给摄像头添加 AI 功能,可以结合 CloudWatch 报警
- Lookout
- 用于检测超出范围的异常值的服务,可以和各种数据存储服务集成使用,下游集成 SNS
- Fraud Detector
- 欺诈检测服务,能与 S3 集成
- Forecast
- 时间序列分析模型,支持 DeepAR+,Prophet,NPTS,ARIMA,ETS 等算法
- Personalize
- 托管的个性化物物推荐服务,需要导入 S3 上的数据,可以进行推荐或智能排序
- 能进行用户细分,也能设置剔除已经买过的东西,或注入推广内容
- 模型默认支持实时更新推荐结果
- Lex
- 聊天机器人工具
- 机器人会根据语义比如 “我想订披萨” 调用对应的 Lambda 函数完成业务逻辑
- Amazon Q Apps
- 基于提示词快速创建 APP 的工具,可以用来构建解析文件的程序等
- Amazon Q Developer
- 针对 AWS 内部资源的 QA 服务,也可以写代码,可以和 IDE 集成
- Mechanical Turk
- 众包市场,可以外包图片标注等任何事情
- Augmented AI
- 用于构建 AI + 人工审核的众包市场,如果其他 AI 工具的结果不可靠,对 AI 模型信心不足,可以发给众包公司人工审核其中的内容,比如色情内容