无EMR集群下AWS部署Hudi及结合S3、Glue实现SCD2咨询

先直接给两个问题的明确结论：

• 不用EMR完全可以落地SCD2逻辑，Glue 4.0及以上版本原生支持Hudi，不需要额外搭集群
• 不存在必须依赖EMR才能用Hudi的限制，多个AWS托管计算服务都内置了Hudi依赖，不需要手动安装部署

具体实操步骤（生产可用） #

1. 前置准备 #

• Glue版本选4.0（内置Spark3.3 + Hudi 0.12.x）或5.0（内置Spark3.5 + Hudi 0.14.x），这两个版本已经预打包了对应版本的hudi-spark-bundle，不用自己上传jar包，能避开90%的依赖冲突问题
• S3路径提前拆分：原始增量数据路径、Hudi维表存储路径、临时中间结果路径分开存放，不要混写，比如增量源数据存s3://<你的桶名>/ods/raw_dim_xxx/，最终SCD2维表存s3://<你的桶名>/dwd/dim_xxx_hudi/
• 给Glue执行角色配好对应S3路径的读写权限、Glue数据目录的表操作权限即可，不需要关联任何EMR相关资源

2. SCD2逻辑实现 #

Hudi表初始化时提前建好SCD2必需的字段：业务主键（比如user_id）、生效开始时间eff_start_date、生效结束时间eff_end_date（当前有效版本默认填9999-12-31）、当前版本标识is_current（当前有效版本默认填true）。表类型根据更新频率选：维表更新频率低选Copy On Write查询性能更好，更新频繁选Merge On Read写入成本更低。
核心合并逻辑直接用Spark SQL写MERGE语句即可，不用自己写全量关联的低效逻辑，参考模板：

-- 第一步：将已存在的当前有效版本，和本次增量数据比对，有字段变更就把旧版本置为失效
MERGE INTO dim_user_hudi t
USING (
    SELECT
        user_id,
        user_name,
        email,
        update_ts,
        DATE_FORMAT(update_ts, 'yyyy-MM-dd') AS eff_start_date
    FROM raw_dim_user_increment
    WHERE dt = '${调度传入的业务日期}'
) s
ON t.user_id = s.user_id AND t.is_current = true
WHEN MATCHED AND (t.user_name <> s.user_name OR t.email <> s.email) THEN
    UPDATE SET 
        t.eff_end_date = DATE_SUB(s.eff_start_date, 1),
        t.is_current = false;

-- 第二步：把本次增量的所有数据作为新版本插入Hudi表
INSERT INTO dim_user_hudi
SELECT
    user_id,
    user_name,
    email,
    update_ts,
    DATE_FORMAT(update_ts, 'yyyy-MM-dd') AS eff_start_date,
    '9999-12-31' AS eff_end_date,
    true AS is_current
FROM raw_dim_user_increment
WHERE dt = '${调度传入的业务日期}';

嫌两段SQL麻烦的话，可以直接配置Hudi写入参数hoodie.datasource.write.payload.class=org.apache.hudi.common.model.DefaultHoodieRecordPayload，配合前置combine字段配置，Hudi会自动处理版本合并，不用手动拆分失效更新和新数据插入步骤，注意参数里的类名要和你选的Glue版本内置的Hudi版本匹配，不然会报类不存在的错误。

3. Glue作业配置避坑 #

• 作业类型选Glue ETL，开发语言选PySpark或Spark SQL都可以，别选Python Shell，跑不了Spark和Hudi
• 不用额外在作业参数里配置Hudi的jar包路径，选对Glue版本就能直接识别内置依赖；如果遇到依赖冲突，加作业参数--user-jars-first true，优先加载用户指定的依赖，覆盖默认内置包
• 开启Glue作业书签功能，能自动识别S3源路径下已经处理过的文件，不用自己写逻辑过滤已处理数据，省掉增量消费的开发量
• 写入时开启Hudi自动同步Glue数据目录的配置：hoodie.datasource.hive_sync.enable=true、hoodie.datasource.hive_sync.table=<你的维表名>，数据写完自动同步元数据，Athena、Redshift Spectrum可以直接查询，不用额外跑Crawler爬元数据

除了上面说的Glue内置支持的方案，还有几个不需要搭EMR的路径，按需选：

• 小数据量场景（日更新10万条以内）可以用Lambda自定义运行时，把Hudi轻量依赖打进部署包做增量更新，注意Lambda的运行时长和内存限制，大数据量别用，容易超时OOM
• 灵活性要求高的场景可以用EKS跑自定义Spark镜像，把需要的Hudi版本打进镜像，配合MWAA做调度，这个方案可以自由选Hudi版本，但是需要自己维护镜像和EKS集群，运维成本比Glue高不少
• 临时调试场景可以用Athena Spark笔记本，内置了Hudi依赖，适合做逻辑验证，不适合跑生产调度作业
  避坑提醒：别自己在EC2上搭Standalone Spark集群装Hudi，本质和自建半托管集群没区别，弹性扩缩容、补丁升级、监控都要自己搞，运维成本极高，性价比极低

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