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，让用户通过它访问