分享嘉宾：陈天明 汽车之家
编辑整理：徐焱森 中经惠众
出品平台：DataFunTalk

导读： 本文主要介绍汽车之家离线计算平台的建设过程，如何应对集群大规模增长带来的性能和稳定性的挑战，如何解决多租户情况下集群面临的运维难题以及如何提升服务器资源利用率问题等问题。

01 汽车之家离线计算平台现状

1. 汽车之家离线计算平台发展历程

2013 年的时候汽车之家集群的规模大概 50 台左右，主要是广告部门用于离线数据分析使用。

2018 年底集群规模大概有 800 台，面向之家所有的业务团队全面开放，用户大概有 200 个，日均处理作业 8 万左右。

2019 年底集群规模 1300 台；由于集群规模越来越大，用户越来越多以及不规范的使用，单一 namenode 无法承受压力，namenode 扩展为 6 组 namenode，日均作业 15 万，日均处理数据量 3PB。

2020 年底规模 2200 台，日均作业 23 万，日均处理数据量 5PB；metastore federation 正式上线，解决由于分区数多导致的查询性能问题;大数据智慧运营系统上线，主要是用大数据的理念来治理大数据平台；引入 hadoop EC 技术解决冷数据存储问题，提升存储利用效率。

2021 年集群规模 3050 台，日均作业 35 万，日均处理量 7PB，Cgroup 软隔离落地进一步提升集群的性能，由 hdfs viewfs 切换到 hdfs RBF ，hdfs RBF 上线，离在线混部提高集群的利用率，经过这几年的发展，集群性能越来越强大，服务越来越稳定。

2. 集群当前运行状态

从这个图中可以看出目前数据仓库的核心任务基本上提前一个小时完成；集群小文件占比逐步降低，目前百分之四十多；集群所有 MR 任务，平均作业运行时长在 100 秒上下浮动，整个集群的状态非常平稳。

02 平台构建过程中遇到的问题

1. 分区过多，hive 性能慢

随着平台的发展数据量越来越多，分区数也越来越多，去年初整个分区数在 5000 万左右每天还在 2 万左右的增加，如果有业务上线批量刷数会造成 hive 查询非常慢。

2. 大量小文件，用户使用不规范

平台在开放的过程中会有很多问题，最典型的例子我们单个 namenode 文件和块数大概有 4 亿左右，这样会造成很多问题，比如 namenode 响应时间非常长，namenode rpc 队列经常被打满，主节点重启用时较长(超过 30 分钟)；另外用户使用不规范的问题，比如队列资源之类的滥用比较多，MR 任务申请的内存过大问题

• 本文地址：汽车之家离线计算平台建设实践
• 本文版权归作者和AIQ共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出

3. 业务急剧增长导致计算资源不足

汽车之家业务的急剧增长导致计算资源不足，任务有延迟，核心任务 SLA 无法保证等问题；这个需要我们进行优化提高资源的利用率。

4. 离线计算资源总体利用率低

通过分析发现离线计算资源具有潮汐性：夜间利用率比较高，白天利用率比较低。怎么样提升资源使用率，是我们当下需要解决的问题。

03 基于构建过程中问题的解决方案

1. 解决 metastore 的问题

2020 年初集群大概有 5000 万左右分区，每天 2 万 + 的速度在增长导致平台的压力比较大，有新业务上线的时候需要批量更新数据，hive 查询比较慢。

业界解决方案主要有以下几种：

• MySQL 分库分表：无论是垂直分表还是水平分表我们通过 metastore 查询 MySQL 都需要修改大量的逻辑，如果使用这种方案改动较大，成本比较高。
• mysq 切换成 tidb：其他大厂也有实现过，但是通过测试发现需要关闭 metastore 事务等问题，对于 tidb 没有足够的信息，我们认为这个应该从架构层来解决，即使以后出现问题，所有的设计我们都清楚，能够快速解决问题。
• waggle-dance：这个方案滴滴有使用，汽车之家的 hadoop 平台是基于 kerberos 做的认证，这个组件没有 kerberos 认证所以这个也不太适合。

汽车之家解决方案：

在客户端与 metastore 之间建立统一的路由层，以 hive 的 DB 为粒度，不同的库转发到对应的 metastore 上，通过这种方式解决 hive 分区量过大的问题。

这种方式有两个优点：

• 支持横向扩展，出现性能瓶颈时，只需要把大库拆分下来即可，并且对业务几乎无感知
• 支持多集群，因为我们要建立海外站，我们可以将海外站和国内的 metastore 关联起来进行查询

上图是我们的架构图，我们的开发机客户端和 hiveserver2 通过代理来连接到 metastore，通过 metastore 来查询底层的分区信息。这种方案需要注意一个问题，由于集群里有认证，一个客户端可能会访问不同的 metastore，后来调研社区方案发现在 metastore 层面是可以共享托管的，将所有的 metastore 通过 zookeper 托管来解决客户端认证的问题。

2. viewfs 升级到 RBF 服务

我们之前用的是 viewfs，在使用 viewfs 遇到很多问题，我们总结主要有以下 4 个问题：

• 非集中式管理，配置都存放到客户端以及部分系统中，造成管理不便
• 挂载表信息更新时部分服务无法热加载，需要手动重新启动服务；比如 metastore
• 无法跨挂载点移动数据
• 不支持多重挂载，比如我们的集群所有的 application 日志保存到 hdfs 上，存放到一个单独的 namespace 上，但是应用程序日志比较多时对应的 hdfs rpc 队列经常被打满，如果支持多重挂载，我们就可以均衡这种数据

RBF 优点：

• 集中式管理，不需要将所有的配置都下发到客户端
• 支持热加载无需重启服务
• 支持跨集群的 mv,rename 操作等(在社区基础上自研功能)
• 配合不同的策略可以使用多重挂载

但是在从 viewfs 升级到 RBF 的过程中我们遇到了很多问题，修复了 80+bug，也增加了很多功能：

• 跨挂载点删除数据需要走 distcp，我们改造成直接把数据删除到对应的 namespace 上这样可以避免走 distcp 缩短删除数据时间
• 跨挂载点移动数据的时候对于超过 10G 大文件或者文件比较多的话走 dsctcp 拷贝任务，对于单个文件或者 1G 以下的文件直接走客户端拷贝
• 增加了 rbf balance 失败的时候一键重置的功能

3. 利用大数据治理大数据平台

用户在使用过程中会有很多不规范的行为，最初是由平台来兜底进行解决问题。刚开始工作量不大，平台还能承受。发展到后期我们筋疲力尽。最终经过讨论我们通过制定规范来规范用户的行为，建立系统来监管用户行为以纠正不规范的行为，通过各个规范的评分来评估客户使用是否合理，通过大数据的方式来治理大数据平台。