持续收获更多独家原创干货！
本文根据刘晓龙老师在〖deeplus直播第257期〗线上分享演讲内容整理而成。
刘晓龙
知乎数据架构平台开发工程师
- 2018年加入知乎离线架构组，主要负责离线大数据集群的管理和优化，对大数据存储有丰富经验。
背景
本次分享主要分为三部分。首先介绍下我们的成本治理之路，然后介绍下分级存储方案，最后讲讲我们基于云上功能做的一些扩展和未来规划。
一、数据治理
早期我们的离线集群没有统一规范，成本治理很难下手。为了解决这个问题，我们首先制定了一套数据规范：
基于该规范，我们推动业务线进行了一次长达数月的数据治理。经过治理，我们获得了很大收益：首先HDFS的数据更清晰，更规范，更安全；其次，我们清理出了数 PB 的废弃数据；最后，也让业务线有了成本意识，能够更合理的使用集群资源。
二、机房迁移
数据治理之后不久，我们又遇到了新的挑战。数据增长变快，老机房机架资源严重不足，服务器采购交付周期很长。因此，我们进行了一次大规模的机房迁移。
架构升级
在迁移机房时，我们对原有的架构做了一次升级。
1）升级原因
①版本考虑
- 集群 CDH 版本落后
- Apache Hadoop 3.x 支持 EC
- 内部 patch 的代码，迁移后改动不大
②机型考虑
- CVM 标准大存储机型，费用低，采购周期短
2）新机型选择
数据迁移
1）数据 GAP
在数据迁移时，我们基于新旧机集群的 fsimage 整理出了一张 diff 表，基于该表，我们可以清晰的知道两个集群的数据 GAP：
- 数据路径（未迁移 和 已迁移）
- 元信息变化情况（已迁移）
- 冗余数据（已删除）
2）迁移问题
①DistCp 性能
Distcp 会寻找并清理中间文件，如果是大目录，可能影响集群性能。我们 迁移时指定了 -direct 参数，不会产生中间文件，因此没必要进行这段逻辑， 因此，我们进行了 HADOOP-16872 的改进。
②专线带宽争用
在做增量数据同步的时候，我们的一些线上业务已经跨专线的在新旧集群进 行了数据双写。为了避免数据同步影响这些线上任务，我们控制了DistCp Job的 mapper 数 和bandwidth 参数，基于带宽情况，对YARN 队列 资源进行限制。
③增量数据同步慢
大量的 Hive表的历史数据，我们按照分区级别，提交到 YARN 上进行同步；剩下的少量「非表数据」和「增量数据」，我们采用了 local 模式进行 同步。
3）迁移收益
三、分级存储
经过机房迁移，我们完成了架构升级，同时也获得了硬件红利带来的巨大成本收益。为了更好的应对未来数据规模的增长，我们对 HDFS 数据进行了分级存储。
1）数据分级
①分级方案
我们将 HDFS 数据划分了以下四个级别，并选用不同方式进行存储。
②热度分析
为了方便业务对 Hive 表分区路径进行热度分析，我们基于 fsimage 和Hive Metastore 分区信息表，整理出了一张hive_partition_detail 表。
③热度划分举例
下图是我们提供的一个热度划分的例子，业务线会根据实际的热度分析结果，进行调整。
2）EC 冷数据存储
我们基于以下两点原因，首先对冷数据选用了 EC 进行存储：
- EC 相对三副本策略可以节省 50% 的存储空间
- 目录的path，账号，权限等都保持不变，业务感知度极低。
①EC目录收集
②EC目录筛选
由于太小的目录不适用 EC，我们对集群数据的实际大小分布情况，进行分析后，决定选择目录平均文件大小 > 2M 的目录才允许使用 EC进行存储。
③EC 自动转储服务流程
我们开发了一套 EC转换服务，进行自动转储，详细流程如下：
- 筛选分区路径，入库
- 调度 DistCp 同步 目录 A 到 临时目录 B（EC 目录）
- 校验 A 和 B 数据
- 目录 A 移动到回收站
- 临时目录 B 移到 A
④EC 需要关注的问题
- 组件兼容性
- EC和副本的性能差异
- 适用 EC 的文件大小
⑤EC 收益
从5月中旬 EC上线后，HDFS 集群的存储使用量和增速得到了有效控制。
收益：
3）COS 极冷数据存储
处理完冷数据，我们又开始对极冷数据进行分析，这部分数据约占3%，我们选择了价格较低的腾讯云 COS 进行存储。
①COS 自动转储流程
我们扩展了之前的 EC 自动转储服务，对 COS 进行了支持，详细流程如下：
- 找出满足时间条件的分区路径
- 以分区为粒度，DistCp 上传数据到 COS
- 数据校验
- 修改 Hive 表分区 location
- 删除 HDFS 分区目录
②COS 问题
- COS 校验失败
我们的COS 桶设置返回 SHA 值，而 DistCp 检测 md5 值，需要修改 COS 桶策略。
- 使用 DistCp -update，COS 端数据被 overwrite
提交 issue HADOOP-17256， 原因是 HADOOP-8143 引入的 Bug（默 认指定 -pb）
- DistCp 触发大量 delete 操作影响性能
去掉 Delete 相关权限，保留 PUTObject 权限
- 同步小文件到 COS 比 HDFS 慢
社区有一些 S3A 相关的优化 HADOOP-16829
- Hive 查询慢
在做 split 的时候，COS 所有 block 对应到一个local 的 node，会创建 大切片，切片个数会变少，因此 COS job 的map 数比 HDFS job 少， 造成查询慢。需要对 mapred.max.split.size 参数进行调优。
查询 HDFS 的 job
查询 COS 的 job
- hadoop-2.7.7 + Flink SqlClient 查询 COS 失败
低版本 aws sdk 解析 response 不过滤 /n/t，高版本已 fix。
- Hive 配置 AK / SK 无效
分析发现是hive.conf.hidden.list 参数隐藏了 AK 和 SK，需要去掉
4）极热数据存储
处理完冷数据和极冷数据，我们计划对热数据进行加速。首先我们进行了机型筛选，找到了一种带一块 NVMe 盘的大存储机型，从成本角度看，比较适合做 DataNode 节点；同时，也对 Hadoop Cache Manager / Lazy Persist / 分级存储等方案进行了前期调研。因此，我们计划利用该机型自带的NVMe 盘做 Cache，进行热数据加速，该功能目前处于开发中。
四、云上功能扩展
在使用 COS 的过程中，我们进行了一些云上功能的扩展：
COS 认证
我们希望内部自研的「用户名+ 密码」机制，适配 COS；同时需要对业务隐藏 COS 的 AK/SK 信息，而目前的大数据组件只支持静态单 AK / SK 配置。因此，我们开发了「组账号/密码 -> COS AK/SK 自动切换」功能。
目前，我们已对 Hadoop，Hive，Presto，Spark，Flink 都做了支持。
COS Select
COS 提供了对 CSV 和 Parquet 格式的下推，因此，我们的内部计算组件也需要做相应支持。
未来规划
- 极热数据：NVMe Cache；
- 统一管理：HDFS 和 COS 数据，包括生命周期，权限管理，auditlog，meta 管理等。
