DB2加密数据导入Hive后解密返回空值的解决方法

以下是针对性的排查和解决步骤：

1. 对齐加密解密的算法细节 #

• 放弃使用数据库通用的encrypt函数，换成明确的AES加密函数（比如MySQL的aes_encrypt），确保和Hive的aes_decrypt算法逻辑完全一致。很多通用encrypt默认算法和Hive的AES不兼容，比如有的默认用DES，或者AES的模式、填充规则不同。

  -- 替换原加密语句，生成标准AES加密的十六进制字符串
  select hex(aes_encrypt('要加密的内容', '密钥')) from 源表;
  

2. 核对密钥的一致性 #

• 确保加密和解密用的密钥完全一致，包括大小写、特殊字符，避免出现加密用MyKey123、解密用mykey123的低级错误。另外密钥长度要符合AES标准：128位密钥对应16个字符，256位对应32个字符，部分数据库会自动调整密钥长度，但Hive不会，长度不符直接导致解密失败。

3. 确认Hive中的加密数据未被破坏 #

• 插入Hive后先查询加密列的内容，和原加密结果对比，检查是否存在数据截断、转义丢失的情况：

  select 加密列 from Hive表 limit 5;
  

  如果数据不一致，排查插入语句的问题，比如是否用了错误的字段分隔符，或是字符串转义规则导致数据受损。

4. 给Hive的解密函数指定明确参数 #

Hive的aes_decrypt默认的模式和填充方式可能和加密端不匹配，显式指定参数尝试解密：

-- 示例：指定AES-128-ECB模式+PKCS5填充，需根据加密端实际情况调整
select aes_decrypt(unhex(加密列), '密钥', 'AES/ECB/PKCS5Padding') from Hive表;

如果加密时用了CBC模式，还需要额外传入初始化向量（IV），且加密和解密的IV必须完全一致。

5. 检查Hive表的字段类型 #

• 加密列必须存储为STRING类型，不要用CHAR或长度不足的VARCHAR，否则插入时数据会被截断，解密自然返回空值。可以修改表结构调整字段类型：

  alter table Hive表 change column 加密列 加密列 string;
  

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