爱奇艺在搭建集群时遇到的那些“坑”

作者简介：

刘骋

毕业于上海交通大学，三年前加入了爱奇艺云平台。主要负责 Hadoop 的运维、Hadoop 工作平台的开发，以及我们内部的工作流系统 Gear 的开发。

今天介绍主要包括这五个方面：

• 爱奇艺 Hadoop 平台架构的演变；

• Hadoop 运维管理体系；

• 遇到的困难及应对措施；

• 爱奇艺自研 Gear 工作流管理系统；

• 未来可能的挑战；

1、爱奇艺平台架构演变

最早的 Hadoop 集群是从2010年8月份开始搭建的，那个时候爱奇艺刚刚成立大概三个月，Hadoop 集群还是由业务部门中负责日志收集、ETL 的团队来管理的。直到2013年6月份才正式交给基础架构部门，我们在多个机房分别部署了集群。

在2014年我们做了很多事情，包括上线 HA、Kerberos、YARN、Spark，直到2015年5月份，我们已经完成进入了 Hadoop2.0 时代，意味着所有的 Hadoop1.0 的集群都已经完全升级到2.0了，我们也算是比较领先地在生产环境中跑了 Spark on YARN。

目前我们的集群达到了上千台的规模，把各种类型的任务混合在一起。这个是我们现在的规模情况，存储规模大约 60PB 左右，每天增量大概在 200TB 左右。

计算方面，一共日均15万个计算任务，其中所有 MapReduce 的 Tasks 数加起来四千万。

我们的业务有公司各个部门，包括搜索、广告、推荐、用户行为分析以及日志分析、报表等数十个业务。

上图是我们当前的架构图：

1. 绿色的部分是存储层，存储层包括 Venus 日志采集，主要指的通过 Flume 进入 HDFS，另外还有 HBase。

2. 红色部分是 Hadoop2.0 的 YRAN，基于 YRAN 我们有离线计算和实时计算，实时计算方面我们采用主要是 Spark Streaming，也有部分的 Storm，我们的 SQL 接口包括 Hive 和 Spark SQL。

3. 右边蓝色的部分是我们内部自己开发的一些管理系统，Hadoop 工作平台和 Gear 工作流管理系统，提供给运维人员和业务方使用。

4. 紫色部分有各种业务，比如视频推荐、视频搜索等，还有大据探针，通过智能分析找到潜在的“大剧”，另外还有精准广告以及会员服务。

2、Hadoop运维管理体系

做 Hadoop 运维管理大概有这几块内容：

1. 首先我们要把服务端做好，也就是如何规划集群；

2. 第二个是规范业务的使用。即使服务端非常好，用户如果随意使用也肯定会出现各种问题；

在这两块都做好了的基础上，我们也需要对服务做一个平台化，就是我们 Hadoop 工作平台。

2.1 集群规划与规范使用

首先规划集群包括这三方面的因素：

• 第一个是提前采购，很多时候做 Hadoop 运维发现 Hadoop 资源又不够了，这个时候应该怎么处理呢？

  事实上，如果我们能够向各个使用方提前收集他所需要的资源，在将来六个月或者一年当中所需要的资源提前做好预算，并且同时采购，因为采购往往周期要半年以上会比较长，所以如果提前做好预算的话，这个机器资源才能够符合我们的预想。

• 第二个是旧机器退役，整个集群就好象一个蓄水池，不断有水进来，还有水要出去，因为我们 Hadoop 集群已经是最多的运营六年了，但是一台机器肯定不可能到六年这么长的时间。

  所以如果你突然发现有一些机器要下线了又不在你的计划之内这是非常头疼的。我们发现一些过保之后的旧机器经常出现磁盘损坏，或者内存 CPU 的故障等等各种问题。

• 第三要考虑各种机房的因素，比如机架、电源、网络。我做 Hadoop 运维这一块才意识到这些问题，比如：你的机器上架在什么位置，是不是同一个机架，是集中上架还是分散到各个交换机下，都是需要考虑的问题。

  电源问题，有时候机房同事会跟我们抱怨，说 Hadoop 机架又超电了，所以我们在这些问题上需要提前规划，这是非常必要的。

上图指规范用户的使用，用户如果不告诉他如何规范用 Hadoop 服务的话，基本上各种用法都有可能，所以我们在这 4 个方面都要做这样的规划。

第一点是 HDFS 用户我们是根据各个业务、各个部门进行分配，而不是分配一些个人用户，这样比较多比较难以管理。

一般来说，一个部门可能会有一到三个用户，然后我们需要管理他们的使用限额、配额，包括存储和计算，存储方面主要是 Name quota，是说文件数不能多，Space quota 是不能超过使用的空间。

所以 Name quota 是为了规范用户的使用，希望小文件不要太多，如果他们 Space quota 每年达到上线，但是 Name quota 达到了，就会把小文件合并成大文件，需要用户的主动性。

第二点是如何配置数据权限，在 Hadoop1.0 的时代，如果 A 用户想访问 B 用户数据，这个是非常麻烦的事情，我们可能一般来说会通过开放一个组的权限去设置，在 Hadoop2.3 就进入 ACL 的功能，可以让你针对单个目录配置单个用户的访问权限。

这个我们现在访问是通过 HDFS ACL 做的，虽然它有可能对 Name quota 造成一些压力，但是只要合理配置，不需要大批量的这个应该是可以避免的。最后计算资源管理我们用的是 Fair Scheduler，这个也是 CDH 默认的调度器。

2.2 Hadoop工作平台

Hadoop 工作平台，前面有规范用户的使用，以及我们对集群的规划之后，我们需要把一些机器的信息、集群的信息管理起来，这时候有了这样的东西。

右边红色的底下一层是后台管理数据库 CMDB，这个主要是包括集群、服务器、配置信息以及用户信息，所有的跟我们公司内部 Hadoop 集群相关的管理信息都是存在 CMDB 中，并提供 API 给上面4个模块使用，包括运维管理，就是所有运维操作都要平台化，而不是运维人员在登到命令行中操作。

这样有可能误操作我们还不知道，如果平台化有这样的好处，减少误操作的几率，降低运维的门槛，并且有一个记录谁操作什么样的事情，是否运维操作是否成功，以及可以察看一下 LOG。我们脚本主要以 Ansible 为主，这个工具非常适合管理 Hadoop 集群。

第二块是数据管理，用户可以直接上我们平台查看，而不需要输入 Hive 语句看那些表。公共库管理是在 Hive 用到 UDF，其实各位业务部门都会用到这个 UDF，大家我们希望放在统一进行管理，这样可以节省重复的人力劳动，并且质量上也比较容易把控。

QoS 这个模块指的是对 Hadoop 服务质量监控，我们平时经常会说到这样的反馈，“集群是不是又变慢了”，“我的任务又跑不了了是不是集群有问题？”

之前我们可能查看各种监控数据或者 LOG，最后找到一个原因，有这个 QoS 之后，我们的目的是希望直接打开 QoS，不管是运维人员还是使用方，都可以直接的看到当时的状况，如果有任何异常需要直接反映在这个上面，这是我们的目的。

3、遇到的困难及应对措施

下面讲一下我们遇到的一些坑，这些坑是大多数是 bug，以及我们做的应对方案。大概分为两类，一类是跟机器、网络或者系统相关的，另一类是 Hadoop 本身的 Bug。

第一个问题是伪高可用。HDFS 本身是配机架的信息，一个文件或者一个文件快是有三份副本存储，其中两份存储在一个机架下，另外一份是存在另外一个机架下，这种配置其实是一个高可用的。

但是有一个问题，我们在实际当中发现，交换机可能没有多高可用，也就是说一台交换机底下有可能连接很多个机架，这时候交换机高可用就挂了，就成为一个单点，有可能同时一堆机架都是出现不可用的情况。

为了避免这个问题，首先把交换机变成高可用就可以了。我们可能不是那么容易变的，不一定能够控制得了或者变更起来周期比较长，在这样基础上解决方案是，配置机架信息的时候不再用原本的传统的机架号，而是采用交换机的比如 ID，这样相当于欺骗 NameNode ，告诉它这个机器机架号是这样的。

其实这个并不是机架号而是交换机号，这样做在一个大集群里是没有什么问题的，把这个机架范围变大了之后，可以容忍整个交换机的 bug，不会出现任何 missing blocks，这是我们想出的一个替代方案。

第二个问题 Linux kernel bug 。不一定大家都会碰到这个问题，Linux kernel 这种文件怎么会有 bug，但是确实是我们上线 Hadoop2.0 以前，做了压力测试，发现高负载下它有一些问题，比如高幅会卡顿，或者有 Cgroup bug 导致自己会重启。

这个解决方案首先是要把 patch 打上 YARN-2809，但是打上还是不能完全解决这个问题，我们如果配置用 Cgroup 严格的 CPU 隔离，依然发现 panic 情况，所以需要升级一下系统的 kernel，最好到 CentOS 7.2 自带的版本，这样才可以完全避免这个 问题。

第三个是 JobTracker 的问题。在 Hadoop1.0 时代，如果你的集群规模一旦达到比如两三百台可能会碰到这个情况，当集群特别繁忙的时候调度性能非常差，也就是我们可能集群上任务同时跑四五十个，一切都正常。

但是如果集群上同时提交四五百个任务，这个时候会发现整体的 CPU 利用率还不如提交四五十个的时候，原因是什么？

就是因为调度性能非常差。因为它同时运行的任务越多，它的调度时间越长。随着同时运行任务变多，比如让调度时间超过 60ms，60ms 的概念是如果设置心跳间隔周期是三秒，也就是 60ms 大概只能承受 50 台集群的规模，这是非常小的。

如果集群达到 500 台，也就是说你的两次心跳间隔可能差 30 秒，这 30 秒的概念是任务完成了，但是要等 30 秒 JobTracker 才知道，也就是要闲置非常长的时间。

我们的解决方案是修改 FairScheduler 源代码，这是我们团队这边第一次改动 Hadoop 内部源代码。万事开头难，第一次改可能怕改错了，但是后面会越来越熟，其实这还是一件不太难的事情。

我们修改之后做了一些简化，比如把之前的排序简化，排一次可以多分配几个等等，这样整个调度时间就降到 5 毫秒以下，5 毫秒大概可以支撑 600 台的规模。

第四个是在Hadoop2.5.0 版本上碰到的HDFS balancer 速度慢的问题。这个首先是因为我们的配置异构，随着集群有几年的历史，之前可能一台机器总共磁盘只有 10T、20T，新采购机器这个磁盘可能将近 60T。

有这么大的差距之后会发现 HDFS 至少现在这个版本对各个异构存储的支持并不是太好，也就是好象蓄水池有小有大，雨下下来会把小的池先填满，所以我们需要不断把小的蓄水池里的水放到大的水池里，这是 balancer 做的事情。

但是随着写入速度越来越快可能来不及做这个事情，这是为什么？一部分是 Dispatcher 类的锁范围太大，我们其实锁住两个传输的节点就可以了，这里还有一个是计算逻辑的优化，具体就不展开了。

第五个，YARN 的 bugs 。ResourceManager 有时会报错或退出，这个问题比较复杂，涉及到 ResourceManager 各个 bug。

爱奇艺云平台也会将我们对源码的研究回馈给社区。其中我们已经向 Hadoop 社区贡献 20 个 Patches，下面是几个简单的例子，其中有一些也被 CDH 的新版本采用，包括 HDFS、YARN 和 Hive。

4、Gear工作管理系统

用 Hadoop 的用户一般会怎么部署定时任务，最简单的是 crontab，这个方式不太好，首先很容易遗漏，并不能解决各个作业之间的依赖问题，或者自己要通过脚本代码去实现。

我们把这些问题共性问题都抽出来之后，发现可以有这样一套系统去对 Hadoop 上的任务做管理。

上面是我们简单的一张图，Gear 主要的功能有作业管理、定时启动、依赖管理、报警订阅、重试机制，其中作业管理、定时启动、和依赖管理在 Hadoop 生态当中本身有这样的产品，事实上我们这个系统底层工作引擎是采用 Oozie，我们在上面做了其他的工作。

Gear 的架构：底层引擎是定制版的 Oozie，可以配置多台任务机，还有支持报警平台，这个报警平台是我们爱奇艺内部的报警功能，可以支持把发送方和接收方分离，发送的人往某一个 topic 发送，接收方直接订阅这个 topic，这样在人员变动的情况下不需要修改这个工作流。

大家都知道 Oozie 的配置非常麻烦，是采用 XML 的配置，我们两年前向各个业务组征求过意见要不要使用 Oozie，事实上每一个业务组调研之后都发现 Oozie 太麻烦，因为 XML 配置非常复杂而且特别冗余。

红色的中间层是提供了基于 YAML 的配置文件格式，基本不含任何冗余信息，这是我们对 Oozie 的配置做了很多的简化之后的成果。

然后在访问层有这三种途径：

• 首先 Web UI，可以看到你提交的作业，在上面运行作业等；

• 其次 Gitlab CI 就是把工作流的配置写在 GitLab，使用 CI 脚本可以直接提交到 Gear 上；

• 另外我们也提供 JAVA 语言的 SDK，用户可以直接通过 Java 构件一个工作流并且提交运行。

我们的特色功能：

• 一种是工作流定义方式，我们是通过配置文件，通过 GitLab CI 自动提交；

• 另一种方式是通过 Java SDK 提交；

配置文件是大幅度简化 Oozie 配置，消除冗余，我们还支持一些模板，比如有各个工作流，可能功用一些属性，可以用一个模板抽象出来，在配置各个工作流的时候不必要再重复写。

我们还增加了工作流的负责人和项目字段，这样用户可以直接在我们页面只上进行筛选，之后有一个代码式统一管理。

我们调研过各种方式后发现，我们公司内部更多的还是开发人员，开发人员比较喜欢用代码式的管理方式，而不是图形的 UI 构建一个工作流。

如果只有一两个工作流，用图形的方式拖拽是挺方便，但是如果有几十个工作流，这个操作就可能变得非常麻烦，而且比较容易出错。

接下来的报警订阅，我们可以选择邮件、短信或者是热聊，热聊是我们内部的一个聊天工具，可以订阅单独工作流，也可以订阅整个项目。

我们还支持自定义的报警接口，比如工作流跑失败了，会发一个 HTTP 请求到你指定的地址，这样方便对接其他系统。最后一个功能是任务机的负载均衡，用户可以配置多个任务机，Gear 通过 SSH 登录到这些机器执行脚本。

Oozie 本身支持配置一台，我们做了改进，可以配置多台，并且智能选择一台负载比较合适的机器去执行，还可以限制一台任务机同时可运行的任务数，防止机器 Load 过高。以上是我们 Gear 工作管理系统的一些介绍。

5、面对的挑战

我们未来的挑战包括以下几点：

• 第一个是降低存储成本，这是一个比较有挑战的课题，因为 Hadoop 存储相对于其他纯存储系统来说比较贵，因为它的机器配置要考虑到计算，我们用户的数据可能只能保存一年的时间，甚至更少。

  他们很多时候有这样的需求，比如统计过去三年某一个数据的变化趋势，这个数据量非常大。

  现有一些解决方案可以降低存储成本，比如分级存储，把一些冷数据，可能减少它的存储的副本数，或者把一些时间较长的数据自动的放在比如我们冷存储当中。

  Hadoop3.0 支持了 Erasure Code 也可以帮助我们实现这一点。

• 第二个是更实时的分析计算，我们当前在做研究测试，Hadoop 之上有很多 SQL 查询的产品，业务越来越要求我们计算需要能够快一点，再快一点，这个时候我们需要上线这样更加实时的分析产品，尽管它有可能消耗比较多的资源。

  在运维管理方面，我们脚本化做的相对完善，但是可能不够自动化。

  所谓自动化是说你能够做到无人职守的状态，比如当你的某台机器挂了可以自动检查什么原因，如果不是硬件故障的话可以帮你自动恢复，如果是硬件故障可以帮你自动报修，这个是我们努力的方向。

最后我认为大数据的本质是连接数据，包含几个方面的意思：

• 首先要连接数据，就要统一数据之间的格式，也就是通常说的数据标准化，这是连接数据的基础。

• 其次数据可以通过血缘关系连接在一起，有了 Gear 工作流系统之后，推断数据血缘关系就变得有可能了，我们需要知道这份数据是由哪些数据产生的，并且根据这份数据生产出来的哪些其他数据，当某一份数据出现问题你可以马上追溯到由于谁的问题造成的。

• 最后是减少不必要的冗余，有的冗余是不必要的，怎样减少不必要的冗余，这个也是我们之后的工作方向。

近期好文：

声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系 [邮箱地址] 删除