腾讯大规模Hadoop集群实践

腾讯大规模Hadoop集群实践

发表于2014-02-19 21:26| 21878次阅读| 来源《程序员》| 45条评论| 作者翟艳堂

《程序员》杂志2014年2月刊hadoop集群腾讯分布式计算数据存储云计算大数据TDW

摘要：TDW是腾讯最大的离线数据处理平台。本文主要从需求、挑战、方案和未来计划等方面，介绍了TDW 在建设单个大规模集群中采取的JobTracker分散化和NameNode高可用两个优化方案。

TDW（Tencent distributed Data Warehouse，腾讯分布式数据仓库）基于开源软件Hadoop和Hive进行构建，打破了传统数据仓库不能线性扩展、可控性差的局限，并且根据腾讯数据量大、计算复杂等特定情况进行了大量优化和改造。

TDW服务覆盖了腾讯绝大部分业务产品，单集群规模达到4400台，CPU总核数达到10万左右，存储容量达到100PB；每日作业数100多万，每日计算量4PB，作业并发数2000左右；实际存储数据量80PB，文件数和块数达到6亿多；存储利用率83%左右，CPU利用率85%左右。经过四年多的持续投入和建设，TDW已经成为腾讯最大的离线数据处理平台。

TDW的功能模块主要包括：Hive、MapReduce、HDFS、TDBank、Lhotse等，如图1所示。TDW Core 主要包括存储引擎HDFS、计算引擎MapReduce、查询引擎Hive，分别提供底层的存储、计算、查询服务，并且根据公司业务产品的应用情况进行了很多深度订制。TDBank负责数据采集，旨在统一数据接入入口，提供多样的数据接入方式。Lhotse任务调度系统是整个数据仓库的总管，提供一站式任务调度与管理。

图1 TDW的功能模块

建设单个大规模集群的原因

随着业务的快速增长，TDW的节点数也在增加，对单个大规模Hadoop集群的需求也越来越强烈。TDW 需要做单个大规模集群，主要是从数据共享、计算资源共享、减轻运营负担和成本等三个方面考虑。

1. 数据共享。TDW之前在多个IDC部署数十个集群，主要是根据业务分别部署，这样当一个业务需要其他业务的数据，或者需要公共数据时，就需要跨集群或者跨IDC访问数据，这样会占用IDC之间的网络带宽。为了减少跨IDC的数据传输，有时会将公共数据冗余分布到多个IDC的集群，这样又会带来存储空间浪费。

2. 计算资源共享。当一个集群的计算资源由于某些原因变得紧张时，例如需要数据补录时，这个集群的计算资源就捉襟见肘，而同时，另一个集群的计算资源可能空闲，但这两者之间没有做到互通有无。

3. 减轻运营负担和成本。十几个集群同时需要稳定运营，而且当一个集群的问题解决时，也需要解决其他集群已经出现的或者潜在的问题。一个Hadoop版本要在十几个集群逐一变更，监控系统也要在十几个集群上部署。这些都给运营带来了很大负担。此外，分散的多个小集群，资源利用率不高，机器成本较大。

建设单个大规模集群的方案及优化

面临的挑战

TDW从单集群400台规模建设成单集群4000台规模，面临的最大挑战是Hadoop架构的单点问题：计算引擎单点JobTracker负载重，使得调度效率低、集群扩展性不好；存储引擎单点NameNode没有容灾，使得重启耗时长、不支持灰度变更、具有丢失数据的风险。TDW单点瓶颈导致平台的高可用性、高效性、高扩展性三方面都有所欠缺，将无法支撑4000台规模。为了解决单点瓶颈，TDW主要进行了JobTracker 分散化和NameNode高可用两方面的实施。

JobTracker分散化

1.单点JobTracker的瓶颈

TDW以前的计算引擎是传统的两层架构，单点JobTracker负责整个集群的资源管理、任务调度和任务管理，TaskTracker负责任务执行。JobTracker的三个功能模块耦合在一起，而且全部由一个Master节点负责执行，当集群并发任务数较少时，这种架构可以正常运行，但当集群并发任务数达到2000、节点数达到4000时，任务调度就会出现瓶颈，节点心跳处理迟缓，集群扩展也会遇到瓶颈。

2.JobTracker分散化方案

TDW借鉴YARN和Facebook版corona设计方案，进行了计算引擎的三层架构优化（如图2所示）：将资源管理、任务调度和任务管理三个功能模块解耦；JobTracker只负责任务管理功能，而且一个JobTracker 只管理一个Job；将比较轻量的资源管理功能模块剥离出来交给新的称为ClusterManager的Master负责执行；任务调度也剥离出来，交给具有资源信息的ClusterManager负责执行；对性能要求较高的任务调度模块采用更加精细的调度方式。

图2 JobTracker分散化架构

新架构下三个角色分别是：ClusterManager负责整个集群的资源管理和任务调度，JobTracker负责单个Job 的管理，TaskTracker负责任务的执行。

（1）两路心跳。之前的架构下，TaskTracker向JobTracker上报心跳，JobTracker串行地处理这些心跳，心跳处理中进行节点管理、任务管理、任务调度等，心跳繁重，影响任务调度和集群扩展性。新架构下，心跳被拆分成两路心跳，分别上报任务和资源信息。

JobTracker获知任务信息通过任务上报心跳的方式。任务上报心跳是通过任务所在的TaskTracker启动一个新的独立线程向对应的JobTracker上报心跳这条途径，在同一个TaskTracker上，不同Job的任务使用不同的线程向不同的JobTracker上报心跳，途径分散，提升了心跳上报效率。

TaskTracker通过上报心跳的方式将资源信息汇报给ClusterManager。ClusterManager从TaskTracker的心跳中获取节点的资源信息：CPU数量、内存空间大小、磁盘空间大小等的总值和剩余值，根据这些信息判断节点是否还能执行更多的任务。同时，ClusterManager通过TaskTracker与其之间维系的心跳来管理节点的生死存亡。

以前繁重的一路心跳被拆分成了两路轻量的心跳，心跳间隔由40s优化成1s，集群的可扩展性得到了提升。

（2）资源概念。之前架构只有slot概念，一般根据核数来设置slot数量，对内存、磁盘空间等没有控制。新架构弱化了slot概念，加强了资源的概念。

每个资源请求包括具体的物理资源需求描述，包括内存、磁盘和CPU等。向ClusterManager进行资源申

请的有三种来源类型：Map、Reduce、JobTracker，每种来源需要的具体资源量不同。在CPU资源上，

调度器仍然保留slot概念，并且针对三种来源保证各自固定的资源帽。

例如，对于24核的节点，配置13个核给Map用、6个核给Reduce用、1个核给JobTracker用，则认为该节点上有1个JobTracker slot、13个Map slot、6个Reduce slot。某个Map请求的资源需要2个核，则认为需要两个Map slot，当一个节点的Map slot用完之后，即使有剩余的CPU，也不会继续分配Map

予其执行了。内存空间、磁盘空间等资源没有slot概念，剩余空间大小满足需求即认为可以分配。在查找

满足资源请求的节点时，会比较节点的这些剩余资源是否满足请求，而且还会优先选择负载低于集群平均

值的节点。

（3）独立并发式的下推调度。之前架构下，调度器采用的是基于心跳模型的拉取调度：任务调度依赖于心跳，Map、Reduce的调度耦合在一起，而且对请求优先级采取全排序方式，时间复杂度为nlog(n)，任务

调度效率低下。

新架构采用独立并发式的下推调度。Map、Reduce、JobTracker三种资源请求使用三个线程进行独立调度，对请求优先级采取堆排序的方式，时间复杂度为log(n)。当有资源满足请求时，ClusterManager直接将资

源下推到请求者，而不再被动地等待TaskTracker通过心跳的方式获取分配的资源。

例如，一个Job有10个Map，每个Map需要1个核、2GB内存空间、10GB磁盘空间，如果有足够的资源，Map调度线程查找到了满足这10个Map的节点列表，ClusterManager会把节点列表下推到JobTracker；如果Map调度线程第一次只查找到了满足5个Map的节点列表，ClusterManager会把这个列表下推到JobTracker，随后Map调度线程查找到了剩下5个Map的节点列表，ClusterManager再把这个列表下推到JobTracker。