Redshift Spectrum/EMR直接对接Hudi与通过Glue Data Catalog选型咨询

通过AWS Glue Data Catalog对接Hudi的核心优势 #

• 统一元数据管理：所有Hudi表的结构、分区、存储路径、序列化配置等元数据仅需在Glue中维护一份，Redshift Spectrum、EMR Spark、Athena等AWS数据分析服务都可以直接复用，无需在每个服务中单独创建、更新外部表定义，完全避免多份元数据不一致的问题。比如Hudi表做了Schema变更，仅需更新Glue一次，所有对接的服务都能同步读取到最新的表结构。
• 降低运维成本：如果不使用Glue，Redshift的外部表、EMR Spark中的表定义都需要单独维护，每次Hudi表的分区更新、存储路径变更、Schema调整都要分别修改两个服务的配置，使用Glue仅需做一次元数据同步即可，大幅减少重复操作。
• 多集群/多服务共享：多个EMR集群、多个Redshift集群都可以直接访问Glue中的同一份Hudi元数据，不需要每个集群单独配置表定义，非常适合有多集群使用需求的场景。
• 自动元数据同步：可以配置Glue爬虫自动识别S3上的Hudi表结构、分区变化，自动更新元数据，无需手动修改表定义，对频繁更新的Hudi表场景适配性更好。
• 配置容错性更高：直接对接Redshift Spectrum时需要手动填写Hudi相关的SerDe、输入输出格式等参数，配置出错概率更高，走Glue对接时这些参数在Glue表中维护一次即可，所有服务调用时都不需要重复配置。

对接方案选择建议 #

你可以根据自身实际场景选择对应的方案：

• 若你的使用场景非常单一，仅需使用Redshift Spectrum或EMR其中一个服务访问Hudi，后续也没有拓展其他服务访问同一份Hudi数据的需求，且Hudi表的Schema、分区基本不会发生变动，可以选择直接对接的方式，初始配置更简单，不需要额外维护Glue的元数据流程。
• 若你的场景同时需要Redshift Spectrum和EMR Spark访问同一份Hudi数据，或者后续可能用到Athena、Glue ETL等其他AWS数据分析服务，或者你的Hudi表会频繁做Schema变更、分区更新，优先选择通过Glue Data Catalog对接的方案，长期来看能节省大量运维成本，也能避免多个服务元数据不一致的问题。

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