最近几年时间玩Hive系统以及Hadoop系统更多一些，现在想来这几年的主要工作如果要系统性的总结，可以归纳为如下几个关键字：数据安全、集群稳定、降本、提效、集群容灾，另外加上一些日常工作比如版本升级、机房搬迁等，这和我去年在文章《大数据底层团队工作阶段性复盘》中的提法是基本一致的，新加入了几个关键字，可能更全面一些。当然每一年通常只会聚焦于一两个主题，比如2019年重点是HDFS数据安全和Hive集群稳定性保障，2020年是Hive大版本升级和HDFS集群稳定性保障，2021年全年是HDFS集群稳定性保障，2022年重点是大数据降本、HDFS层面提效，2023年是任务优化、机房搬迁和容灾。这些工作不再像从前一样每件事情都亲力亲为，更多是进行方案方向指导、产品形态设计、重点问题分析解决、方法论归纳整理以及进度协调把控等。

接下来大数据专题将会围绕这些关键字深度展开，将笔者近几年的工作进行一次全方位的整理总结。之所以起意给过去的几年工作做总结，因为接下来笔者会将更多精力投入新的领域 - 大数据平台商业化，这个方向对我来说是一个全新的开始，里面会碰到很多和之前不一样的人，做的事情和之前也大不一样，也许等过几年我也会像现在一样写写商业化的故事。

好了，就从这里开始这个专题吧。这篇文章我们聊聊HDFS数据安全这个相对来说不是那么复杂的事情。HDFS数据安全问题最终本质是说三数据副本都找不到了，那哪些场景下会出现这种情况呢？理论上有这么几种情况，比如数据被误删、集群所在机房发生故障所有数据都丢失了，但是实际生产环境中，数据被误删的场景远远多于其他场景。今天这篇文章我们就重点聚焦于在HDFS层面如何防止数据误删。

HDFS数据经常会被误删。根据笔者近几年的观察，误删的场景非常之多，有的是SQL有问题导致数据误删，有的是运维工具有bug导致误删，也有纯粹手抖误删。为了降低数据误删带来的数据丢失风险甚至更进一步防止数据误删，网易内部实践了包括数据备份、目录冻结以及公共回收站等多种策略。

数据备份

数据误删最常见的保护策略是数据备份，一旦数据误删是可以从备份中恢复的。但是HDFS集群规模变大之后，所有数据都进行备份所需要投入的成本会非常之高，即使可以采用EC进行压缩，成本开销也非常之大，而且这部分数据很可能一年一次都用不上，对大多数公司来说可能性价比并不高。

为了降低成本，一般会在两个方面做一些选择上的优化：

其一是备份的数据并不推荐将整个集群所有数据都进行备份，而是备份核心表和原始数据。因为核心表如果有备份，是可以保证即使这些表被误删，核心任务也可以快速恢复，其他误删数据可以通过原始数据逐步恢复出来。

其二是备份的集群可以选择高密EC集群，这样单台物理机的存储规模可以做的比较大，即便数据量很大，采购的物理机数量也相对比较可控。甚至可以将数据备份到云上的对象存储上进一步节省成本。

上述数据冷备方案可以在数据发生误删的时候从备份中恢复数据，但实际上真实恢复数据的时候，可能会遇到一些问题：比如如果存储在对象存储上的话是需要先将数据移动到本地集群，这个费用和实际投入人天还是有不少的。另外很多数据不是直接可以从备份数据中恢复出来的，而是需要从备份数据中通过计算逻辑修复出来，这也是需要额外投入不少实际人天成本。

既然这样，那有没有能够直接阻止核心表或者大量文件被误删的方法？我们提出并实现了两个方案，其一是目录冻结机制，另外一个是公共回收站机制。下文笔者对这两个方案分别进行介绍。

目录冻结机制

目录冻结机制利用Ranger作为NameNode权限管理器这个角色，将部分禁止删除的目录设置为冻结目录，用户执行目录删除时，Ranger在检查权限的同时还会检查该目录是否为冻结目录，如果是的话就拒绝执行删除操作。整体架构如下图所示：

上图展示了目录冻结机制的核心原理，主要步骤有：

1. 设置目录冻结名单

（1）管理员根据业务梳理将重要的目录设置为冻结目录，这些目录及其子目录不允许执行删除操作。

（2）除了这部分重要目录会被设置为冻结目录外，还有一些目录因为其中包含的文件数比较多，无法评估是否允许删除，这部分目录也会被设置为冻结目录。

2. NameNode中的Ranger Plugin启动一个线程定期将目录冻结名单拉取到本地缓存起来。

3. 用户执行目录删除命令后，Ranger Plugin首先检查待删除目录是否在本地冻结目录名单中，如果在的话就拒绝执行。

通过目录冻结机制可以有效防止一些非常重要的数据仓库目录以及大目录被误删。但是实际场景中还是会有一些用户反馈因为程序bug或其他原因删除了没有在冻结目录名单中的表数据，这种场景应该如何有效避免误删呢？

公共回收站机制

HDFS原生支持个人回收站，所谓个人回收站，是指用户执行rm命令之后被删除文件会进入用户目录下的.Trash目录，我们将这个.Trash目录称为个人回收站。如下示例：

//假设用户zhangsan执行删除命令 hadoop fs -rm <path> //被删除的文件会进入如下路径 /user/zhangsan/.Trash/Current/<path>

因此，用户执行rm命令删除的文件实际上并没有被真正删除，而是进入回收站目录。但是用户在实际操作数据文件或者通过计算引擎操作数据文件时，经常会调用delete接口删除文件，这种场景下HDFS原生并没有提供回收站保障机制，被删除的文件就真正被删除了，也就是这种场景容易发生数据误删。