分享嘉宾：陈天明 汽车之家
编辑整理：徐焱森 中经惠众
出品平台：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任务申请的内存过大问题

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. 利用大数据治理大数据平台

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