求助：Athena无法解析AWS DMS同步至S3的CSV文件

我之前也碰到过完全一样的情况——用AWS DMS把MySQL RDS的数据同步到S3，全量LOAD和CDC的gz文件都正常生成了，Glue Crawler跑完也建好了数据目录，但Athena一查询就报错。折腾了好一阵，总结出几个核心问题和对应的解决办法，你可以一步步排查：

1. 先确认DMS的CSV输出格式是否符合Glue/Athena的预期 #

DMS导出的CSV并非完全标准格式，默认会带一些特殊处理，这是最常见的坑：

• 全量LOAD文件：默认开头会有一行DMS的元数据（比如# DMS Stream开头的行），如果Crawler没跳过这行，会把它当成数据行，直接导致表结构推断错误。你可以在DMS任务的S3目标设置里，开启Skip header rows并把值设为1，跳过这行元数据。
• CDC文件：每行开头会额外增加两个字段：操作类型（I/U/D，对应插入/更新/删除）和操作时间戳。如果你的全量文件没有这两个字段，Crawler会把全量和CDC文件混在一起推断表结构，必然出现不匹配的情况。解决办法要么把全量和CDC放到S3的不同前缀下（比如testdb/addresses/full/和testdb/addresses/cdc/）分别建表；要么手动给表加上这两个前置字段。
• 分隔符/引号/转义符：DMS默认用逗号分隔字段，但如果数据里包含逗号，DMS会用双引号包裹字段，同时用反斜杠转义。要确保Glue表的SerDe参数和这个规则完全一致，不然会出现字段拆分错误。

2. 调整Glue Crawler的分类器配置 #

默认的CSV分类器可能识别不了DMS的特殊格式，建议自定义一个适配的分类器：

• 打开Glue控制台，进入分类器页面，创建新的CSV分类器。
• 配置参数：
  • 分隔符：和DMS设置一致（默认是逗号）
  • 引号字符：双引号"
  • 是否有表头：如果DMS开启了Add column names，就选“是”；如果没开建议开启，方便Crawler识别字段名
  • 跳过行数：如果全量文件有DMS元数据行，设为1
• 把这个自定义分类器加到你的Crawler里，重新执行一次爬取任务。

3. 手动修正Glue表的结构和属性 #

如果Crawler还是推断出错误的表结构，直接手动修改会更高效：

步骤1：确认实际文件结构 #

先下载一个全量和一个CDC的gz文件，解压后查看真实结构：

• 全量文件：是否有表头？字段数量是多少？
• CDC文件：开头是不是多了I,2024-05-20T12:34:56,...这样的操作类型和时间戳字段？

步骤2：重建或修改Glue表结构 #

比如如果CDC文件有额外的两个字段，你的表结构应该包含它们，可在Athena中执行以下SQL重建表：

CREATE EXTERNAL TABLE IF NOT EXISTS testdb.addresses (
  op_type string,
  op_timestamp string,
  id int,
  street string,
  city string,
  zip_code string
)
ROW FORMAT DELIMITED
FIELDS TERMINATED BY ','
ESCAPED BY '\\'
QUOTE BY '"'
LINES TERMINATED BY '\n'
STORED AS INPUTFORMAT
  'org.apache.hadoop.mapred.TextInputFormat'
OUTPUTFORMAT
  'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'
LOCATION
  's3://your-bucket/testdb/addresses/'
TBLPROPERTIES (
  'serialization.compression.type'='gzip',
  'skip.header.line.count'='1' -- 如果全量文件有元数据行则添加此配置
);

你也可以直接在Glue控制台编辑表的结构和SerDe参数。

步骤3：刷新表分区 #

如果文件是按时间分区存储的（DMS默认会按时间生成前缀），执行以下语句让Athena识别所有新分区：

MSCK REPAIR TABLE testdb.addresses;

4. 确认压缩格式支持 #

DMS生成的是gzip压缩文件，Glue/Athena默认支持，但要确保表的serialization.compression.type属性设为gzip，上面的建表语句已经包含了这个配置。

按这个流程排查下来，基本就能解决Athena无法解析的问题。我当时就是因为没注意CDC文件多了两个字段，Crawler推断的表结构缺失这两个字段，导致查询一直报错，手动加上后就正常了。

内容的提问来源于stack exchange，提问作者Eilliar