腾讯TDW:大型Hadoop集群应用

标签: Hadoop Linux 大数据应用 TDW 大型 | 发表时间:2014-08-04 08:49 | 作者:谋万世全局者
分享到:
出处:http://www.ha97.com
PS: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。 以前基于心跳模型的拉取调度被优化成独立并发式的下推调度之后,平均调度处理时间由80ms优化至1ms,集群的调度效率得到了提升。 3. Job提交过程 新架构下,一次Job提交过程,需要Client和ClusterManager、TaskTracker均进行交互(如图3所示):JobClient先向ClusterManager申请启动JobTracker所需要的资源;申请到之后,JobClient在指定的TaskTracker上启动JobTracker进程,将Job提交给JobTracker;JobTracker再向ClusterManager申请Map和Reduce资源;申请到之后,JobTracker将任务启动命令提交给指定的TaskTracker。 图3 Job提交过程 4. 存在的问题及应对措施 JobTracker分散化方案给计算引擎带来高效性和高扩展性,但没有带来高可用性,单一故障点的问题在此方案中仍然存在,此时的单一故障点问题有别于以前,如下所述。 (1)ClusterManager如果发生故障,不会造成Job状态丢失而且在短时间内即可恢复。它只存储资源情况,不存储状态,ClusterManager在很短的时间内可以重启完成。重启之后,TaskTracker重新向ClusterManager汇报资源,ClusterManager从重启至完全获得集群的资源情况整个阶段可以在10秒内完成。 (2)JobTracker如果发生故障,只会影响单个Job,对其他Job不会造成影响。 [...]

相关 [腾讯 tdw hadoop] 推荐:

腾讯TDW:大型Hadoop集群应用

- - 服务器运维与网站架构|Linux运维|X研究
PS:TDW是腾讯最大的离线数据处理平台. 本文主要从需求、挑战、方案和未来计划等方面,介绍了TDW在建设单个大规模集群中采取的JobTracker分散化和NameNode高可用两个优化方案. TDW(Tencent distributed Data Warehouse,腾讯分布式数据仓库)基于开源软件Hadoop和Hive进行构建,打破了传统数据仓库不能线性扩展、可控性差的局限,并且根据腾讯数据量大、计算复杂等特定情况进行了大量优化和改造.

大规模Hadoop集群在腾讯数据仓库TDW的实践

- - 标点符
随着业务的快速增长,TDW的节点数也在增加,对单个大规模Hadoop集群的需求也越来越强烈. TDW需要做单个大规模集群,主要是从数据共享、计算资源共享、减轻运营负担和成本等三个方面考虑. TDW之前在多个IDC部署数十个集群,主要是根据业务分别部署,这样当一个业务需要其他业务的数据,或者需要公共数据时,就需要跨集群或者跨IDC访问数据,这样会占用IDC之间的网络带宽.

Protobuf在腾讯数据仓库TDW的使用

- - 标点符
protobuf是google提供的一个开源序列化框架,类似于XML、JSON这样的数据表示语言,其最大的特点是基于二进制,因此比传统的XML表示高效短小得多. 虽然是二进制数据格式,但并没有因此变得复杂,开发人员通过按照一定的语法定义结构化的消息格式,然后送给命令行工具,工具将自动生成相关的类,可以支持java、c++、python等语言环境.

腾讯数据仓库TDW元数据重构方案

- - 标点符
大规模应用场景下HIVE暴露出的问题. HIVE进程内存占用高,GC频繁. 元数据接口性能下降(秒级->分钟级). 元数据库压力大,不堪重负. HIVE进程间各个session容易相互影响. HIVE出现session卡死现象. 高并发下容易发生死锁和死循环. HQL Translator层.

Hadoop使用(一)

- Pei - 博客园-首页原创精华区
Hadoop使用主/从(Master/Slave)架构,主要角色有NameNode,DataNode,secondary NameNode,JobTracker,TaskTracker组成. 其中NameNode,secondary NameNode,JobTracker运行在Master节点上,DataNode和TaskTracker运行在Slave节点上.

Hadoop TaskScheduler浅析

- - kouu's home
TaskScheduler,顾名思义,就是MapReduce中的任务调度器. 在MapReduce中,JobTracker接收JobClient提交的Job,将它们按InputFormat的划分以及其他相关配置,生成若干个Map和Reduce任务. 然后,当一个TaskTracker通过心跳告知JobTracker自己还有空闲的任务Slot时,JobTracker就会向其分派任务.

HADOOP安装

- - OracleDBA Blog---三少个人自留地
最近有时间看看hadoop的一些东西,而且在测试的环境上做了一些搭建的工作. 首先,安装前需要做一些准备工作. 使用一台pcserver作为测试服务器,同时使用Oracle VM VirtualBox来作为虚拟机的服务器. 新建了三个虚拟机以后,安装linux,我安装的linux的版本是redhat linux 5.4 x64版本.

Hadoop Streaming 编程

- - 学着站在巨人的肩膀上
Hadoop Streaming是Hadoop提供的一个编程工具,它允许用户使用任何可执行文件或者脚本文件作为Mapper和Reducer,例如:. 采用shell脚本语言中的一些命令作为mapper和reducer(cat作为mapper,wc作为reducer). 本文安排如下,第二节介绍Hadoop Streaming的原理,第三节介绍Hadoop Streaming的使用方法,第四节介绍Hadoop Streaming的程序编写方法,在这一节中,用C++、C、shell脚本 和python实现了WordCount作业,第五节总结了常见的问题.

Hadoop Corona介绍

- - 董的博客
Dong | 可以转载, 但必须以超链接形式标明文章原始出处和作者信息及 版权声明. 网址: http://dongxicheng.org/hadoop-corona/hadoop-corona/. Hadoop Corona是facebook开源的下一代MapReduce框架. 其基本设计动机和Apache的YARN一致,在此不再重复,读者可参考我的这篇文章 “下一代Apache Hadoop MapReduce框架的架构”.

Hadoop contrib介绍

- - 董的博客
Dong | 可以转载, 但必须以超链接形式标明文章原始出处和作者信息及 版权声明. 网址: http://dongxicheng.org/mapreduce/hadoop-contrib/. Hadoop Contrib是Hadoop代码中第三方公司贡献的工具包,一般作为Hadoop kernel的扩展功能,它包含多个非常有用的扩展包,本文以Hadoop 1.0为例对Hadoop Contrib中的各个工具包进行介绍.