如题所述
第1个回答 2022-06-12
这样设计的目的，是为了保证在 HDFS 中，不保存任何明文密钥信息，这样即使恶意用户攻破了 HDFS，也只能拿到加密后的文件和加密后的 DEK，依然读不到文件的原始内容。
多个 KMS Server 的 backing keystore 并不共享，原生 KMS Server 使用的是 JKS（Java KeyStore） 存储机制，EZ Key 都保存在本地文件系统上的 keyStore 文件中，这样的话，由于 keyStore 文件无法在多个 KMS Server 之间共享，导致挂掉任何一个 Server 后，其它剩余的 KMS Server 都可能读取不到已有的 EZ Key，导致 EZ key 丢失，进而使得加密文件打不开。
原生的这种集群组织方式，更像是一种负载均衡策略，从这种情况下 KMS 客户端的名字也能看的出来：LoadBalancingKMSClientProvider。在 Hadoop 的官方文档中，也强调了 JKS 这种存储机制不能用在生产环境中。
这个地方需要实现一个新的分布式的、共享存储的 backing keyStore 方式，可以使用 zookeeper 或者 ratis 等等。Apache Zookeeper 和 Apache Ratis 的比较：
目前的话，还是建议：
在普通的 HDFS 目录之间，文件的 move 并不涉及到数据的移动，仅仅是元数据的修改，速度非常快，但在 EZ 和非 EZ 之间、不同 EZ 之间，并不支持 move 操作，只支持 copy 操作，相对较慢，具体如下图所示：
这其中的原因是，HDFS client 无论 create、append 还是 open 一个文件时，如果发现这个文件是一个加密文件，那就需要特殊处理，而判断文件是否加密及随后正确的加解密处理（写入需要加密、读取需要解密），需要来自两方面的信息：
既然如此，那么：
如前所述，EZ 和 非 EZ 之间的 move 操作是禁止的，换句话说 Trash 功能对 EZ 中的文件是不可用的，而在 TDWHadoop 中，数据保护功能默认打开（配置项 hadoop.tdw.protect.data.enable 默认为 true），客户端的 delete 操作实际上最终是一个 move 操作，既然 move 被禁止，那么最终表现为EZ 中的文件无法删除。
这个问题在 Hadoop 2.8.0 中得到解决，解决思路如下：
多个 KMS Server 的 backing keystore 并不共享，原生 KMS Server 使用的是 JKS（Java KeyStore） 存储机制，EZ Key 都保存在本地文件系统上的 keyStore 文件中，这样的话，由于 keyStore 文件无法在多个 KMS Server 之间共享，导致挂掉任何一个 Server 后，其它剩余的 KMS Server 都可能读取不到已有的 EZ Key，导致 EZ key 丢失，进而使得加密文件打不开。
原生的这种集群组织方式，更像是一种负载均衡策略，从这种情况下 KMS 客户端的名字也能看的出来：LoadBalancingKMSClientProvider。在 Hadoop 的官方文档中，也强调了 JKS 这种存储机制不能用在生产环境中。
这个地方需要实现一个新的分布式的、共享存储的 backing keyStore 方式，可以使用 zookeeper 或者 ratis 等等。Apache Zookeeper 和 Apache Ratis 的比较：
目前的话，还是建议：
在普通的 HDFS 目录之间，文件的 move 并不涉及到数据的移动，仅仅是元数据的修改，速度非常快，但在 EZ 和非 EZ 之间、不同 EZ 之间，并不支持 move 操作，只支持 copy 操作，相对较慢，具体如下图所示：
这其中的原因是，HDFS client 无论 create、append 还是 open 一个文件时，如果发现这个文件是一个加密文件，那就需要特殊处理，而判断文件是否加密及随后正确的加解密处理（写入需要加密、读取需要解密），需要来自两方面的信息：
既然如此，那么：
如前所述，EZ 和 非 EZ 之间的 move 操作是禁止的，换句话说 Trash 功能对 EZ 中的文件是不可用的，而在 TDWHadoop 中，数据保护功能默认打开（配置项 hadoop.tdw.protect.data.enable 默认为 true），客户端的 delete 操作实际上最终是一个 move 操作，既然 move 被禁止，那么最终表现为EZ 中的文件无法删除。
这个问题在 Hadoop 2.8.0 中得到解决，解决思路如下：
