网站地图 | RSS订阅 老铁博客 - 上海SEO优化|上海网站建设|蜘蛛池出租|站群代搭建
你的位置:首页 » 站群搭建 » 正文

腾讯大规模Hadoop集群实践 [转程序员杂志]

2019-7-28 2:0:56 | 作者:老铁SEO | 0个评论 | 人浏览

  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任务调度系统是整个数据仓库的总管,提供一站式任务调度与管理。

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

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

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

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

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

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

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

  新架构下三个角色分别是: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通过心跳的方式获取分配的资源。

  以前基于心跳模型的拉取调度被优化成独立并发式的下推调度之后,平均调度处理时间由80ms优化至1ms,集群的调度效率得到了提升。

  JobTracker分散化方案给计算引擎带来高效性和高扩展性,但没有带来高可用性,单一故障点的问题在此方案中仍然存在,此时的单一故障点问题有别于以前,如下所述。

  (1)ClusterManager如果发生故障,不会造成Job状态丢失而且在短时间内即可恢复。它只存储资源情况,不存储状态,ClusterManager在很短的时间内可以重启完成。重启之后,TaskTracker重新向ClusterManager汇报资源,ClusterManager从重启至完全获得集群的资源情况整个阶段可以在10秒内完成。

  (2)JobTracker如果发生故障,只会影响单个Job,对其他Job不会造成影响。

  基于以上两点,认为新方案的单一故障点问题影响不大,而且考虑方案实施的复杂度和时效性,TDW在JobTracker分散化方案中没有设计高可用方案,而是通过外围系统来降低影响:监控系统保证ClusterManager故障及时发现和恢复;Lhotse调度系统从用户任务级别保证Job重试。

  TDW以前的存储引擎是单点NameNode,在一个业务对应一个集群的情况下,NameNode压力较小,出故障的几率也较小,而且NameNode单点故障带来的影响不会波及全部业务。但当把各个小集群统一到大集群,各个业务都存储之上时,NameNode压力变大,出故障的几率也变大,NameNode单点故障造成的影响将会非常严重。即使是计划内变更,停止NameNode服务耗时将近2个小时,计划内的停止服务变更也给用户带来了较大的影响。

  (3)事务日志序号。为了验证事务日志是否丢失或者重复,为事务日志指定递增连续的记录号txid。在事务日志文件edits中加入txid,保证txid的连续性,日志传输和加载时保证txid连续递增,保存内存中的元数据信息到fsimage文件时,将当前txid写入fsimage头部,载入fsimage文件到内存中时,设置元数据当前txid为fsimage头部的txid。安全日志序号(safe txid)保存在ZooKeeper上,ActiveNameNode周期性地将txid写入ZooKeeper作为safe txid,在BackupNameNode转换为ActiveNameNode时,需要检查BackupNameNode当前的txid是否小于safe txid,若小于则禁止这次角色转换。

  (5)DataNode双报。Block副本所在的节点列表是NameNode元数据信息的一部分,为了保证这部分信息在主备间一致性,DataNode采用双报机制。DataNode对块的改动会同时广播到主备,对主备下发的命令,DataNode区别对待,只执行主机下发的命令而忽略掉备机下发的命令。

  (6)引入ZooKeeper。主要用来做主节点选举和记录相关日志:NameNode节点状态、安全日志序号、必要时记录edit log。

  当主退出时主备状态切换的过程(如图4所示):当ActiveNameNode节点IP1由于某些原因退出时,两个备节点IP2和IP3通过向ZooKeeper抢锁竞争主节点角色;IP2抢到锁成为ActiveNameNode,客户端从ZooKeeper上重新获取主节点信息,和IP2进行交互,这时即使IP1服务恢复,也是newbie状态;事务日志在主备间同步,newbie IP1通过向主节点IP2学习成为standby状态。

  NameNode高可用方案给存储引擎带来了高可用性,但在高效性方面做出了一些牺牲,由于事务日志需要同步,写性能有20%左右的下降。

  TDW在实施大集群过程中,除了主要实施JobTracker分散化和NameNode高可用两个方案,还进行了一些其他优化。

  随着存储量和业务的不断增长,一个HDFS元数据空间的访问压力与日俱增。通过NameNode分散化来减少一个元数据空间的访问压力。NameNode分散化主要对元数据信息进行分拆,对用户透明,用户访问认为处于同一个存储引擎,底层可以拆分成多个集群。TDW在Hive层增加用户到HDFS集群的路由表,用户表的数据将写入对应的HDFS集群,对外透明,用户只需使用标准的建表语句即可。TDW根据公司业务的实际应用场景,根据业务线和共享数据等把数据分散到两个HDFS集群,有利于数据共享同时也尽量规避集群间的数据拷贝。采用简单、改动最少的方案解决了实际的问题。

  TDW内部有三个HDFS版本:0.20.1、CDH3u3、2.0,线,主流HDFS版本使用的RPC框架尚未优化成Thrift或者Protocol Buffers等,三个版本互不兼容,增加了互相访问的困难。通过RPC层兼容方式实现了CDH3u3和0.20.1之间的互通,通过完全实现两套接口方式实现了CDH3u3和2.0之间的互通。

  重要数据的误删除会给TDW带来不可估量的影响,TDW为了进一步增加数据存储可靠性,不仅开启NameNode回收站特性,还增加两个特性: 删除黑白名单,删除接口修改成重命名接口,白名单中的目录可以被删除,白名单中的IP可以进行删除操作,其他则不可;DataNode回收站,块删除操作不会立即进行磁盘文件的删除,而是维护在待删除队列里,过期之后才进行实际的删除操作,这样可以保证在一定时间内如果发现重要的数据被误删除时可以进行数据恢复,还可以防止NameNode启动之后元数据意外缺失而造成数据直接被删除的风险。

  TDW从实际情况出发,采取了一系列的优化措施,成功实施了单个大规模集群的建设。为了满足用户日益增长的计算需求,TDW正在进行更大规模集群的建设,并向实时化、集约化方向发展。TDW准备引入YARN作为统一的资源管理平台,在此基础上构建离线计算模型和Storm、Spark、Impala等各种实时计算模型,为用户提供更加丰富的服务。

  腾讯是一个巨无霸公司,我们日常的生活中已与它产生了千丝万缕的联系,不可避免的也产生了海量的数据,如何正确而快速地处理这些海量数据,腾讯数据平台高级架构师郭玮通过发表主题为“TDW在Hadoop上的实践...博文来自:阳光灿烂的日子的博客

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

  1.准备工作:jdk安装(个人选择的1.8版本)2.ssh免密登陆:关闭放火墙(可以将要开放的端口加入防火墙的开发端口中,学习用就直接关闭防火墙了):1)关闭firewall:systemctlsto...博文来自:gakki_smile的博客

  之前成为CSDN的博客专家,昨天竟然还送了本《程序员》杂志过来!看来CSDN的博客专家还是有些实际的福利的。以前曾经买过几次《程序员》,但是后来就买不到了,据说只有电子版。现在看来还是有纸质的,只不过...博文来自:干勾鱼的CSDN博客

  【大数据架构与系统】腾讯数据中心资深专家翟艳堂分享了腾讯建立大规模Hadoop集群的过程,首先要解决单点问题,将JobTracker分散化,做NameNode高可用。在业务选型方面,选择了成熟度更高的Facebook开源的Corona。

  为普及大数据相关知识,促进广州、深圳地区大数据爱好者的交流,增强企业使用大数据相关开源项目的意识,特地举办了“大数据开放日”深圳活动。 本活动由 CSDN CODE与腾讯大讲堂联合主办,活动同时得到了CSDN战略合作伙伴腾讯公司、腾...

  内容简介生物在适者生存的“演化”过程中塑造,而未必愈加清晰地感知世界。例如青蛙的大脑被设定为捕食移动的椭圆。把苍蝇麻醉,摆在它旁边,青蛙视若不见——他们能饿死在食物近前;然而又会毫不犹豫地捕食由人抛出...博文来自:GitChat

  这本书,我看了两遍。为什么看两遍呢,因为说实话,第一遍没有完全看懂。第一遍读过来,感觉作者讲了很多东西,但似乎又什么都没讲,总之看完之后有一种很奇怪的感觉。于是,便看了第二遍。第二遍读下来,才算是对这...博文来自:oarsman的专栏

  知识图谱的相关研究如火如荼地开展着,知识图谱的构建与应用如雨后春笋般出现。大规模知识图谱的构建与应用发展十分迅速,具有广阔的前景。本次分享将着重探讨知识图谱构建的技术、方案、策略和知识图谱的一些应用,...博文来自:GitChat

  1.Ulimit配置操作系统默认只能打开1024个文件,打开的文件超过这个数发现程序会有“toomanyopenfiles”的错误,1024对于大数据系统来说显然是不够的,如果不设置,基本上整个大数据...博文来自:u014516601的博客

  前言本篇介绍Hadoop的一些常用知识。要说和网上其他manual的区别,那就是这是笔者写的一套成体系的文档,不是随心所欲而作。常用HDFS命令hadoopfs-lsURIhadoopfs-du-hU...博文来自:谷震平的专栏

  人脸识别已经成为成为计算机视觉领域最热门的应用之一,很多刚入门的AI新手都或多或少接触过人脸识别的相关知识,但是纸上得来终觉浅,在实际应用中,往往会遇到各种各样的问题,比如如何保证不同环境下人脸识别的...博文来自:CSDN人工智能头条

  安装一个Linux系统配置网卡重启网络服务pingbaidu修改主机名关闭防火墙安装ssh客户端克隆Linux系统对克隆好的系统配置网卡ssh链接及免密登录安装JDK安装hadoopshare中doc...博文来自:amin_hui的博客

  hadoop集群运行的原理与使用就是在每台服务器上分别安装hadoop环境,配置文件中指定master在那个服务器上,yarn的ResourceManager在那个服务器上,在salves上指定从机的...博文来自:jie310600的博客

  分布式系统的基础理论:一、基础理论知识:数据分布、复制、一致性、容错。1、异常(1)服务器宕机(内存错误,服务器停电):如何通过读取持久化戒指(机械硬盘/固态硬盘)中的数据恢复内存信息,从而恢复宕机前...博文来自:岁月静好,做自己。

  导读#开始敲这篇“软”文,我觉得颈肩都好硬,转转头抖抖肩,许多事情如开闸水般涌入脑海,整个人顿时放松了下来。也烦请读者朋友耐心读下来,看一看这千千万万测试人的一些共鸣!我们是谁2012年,我入职腾讯无...博文来自:TMQ1225的博客

  作者|腾讯编辑|DebraAI前线导读:在互联网场景中,亿级的用户每天产生着百亿规模的用户数据,形成了超大规模的训练样本。如何利用这些数据训练出更好的模型并用这些模型为用户服务,给机器学习平台带来了巨...博文来自:weixin_33939380的博客

  作者:袁宜霞团队:腾讯移动品质中心TMQ一、怎么界定自动化测试范围白盒测试主要测试APP的内部结构或运作,以代码实现的角度来设计测试案例。白盒测试优点在于要求测试人员去学习软件的实现,可以检测代码中的...博文来自:TMQ1225的博客

  阿里腾讯云hadoop+spark集群搭建(1)linux版本:centos7hadoop版本:3.1.1手上有三台学生机,完全没动过的:一台是阿里云服务器,两台是腾讯云。用阿里云做namenode,...博文来自:karwik的博客

  \u003cp\u003e3月23日下午4点左右,腾讯多个产品出现大规模宕机,原因是上海当地网络运营商光纤线点半,腾讯公司官方微博发布紧急公告:\u003c/p\u003e\n\u...博文来自:cpongo5的博客 天猫

  有关SAFe实质概要介绍面向企业的Scrum-SAFe常规的敏捷框架适用于中小型项目团队,而且不具有扩展性。基于常规的敏捷框架,SAFe定义了一个可扩展的敏捷框架模型,它适用于大型团队的合作开发,可以...博文来自:weixin_34392906的博客

  30份腾讯人力资源管理文档,包括人力资源管理体系、实践案例、管理制度、各模块职业发展规划书,各模块能力模型等,超级实用!

  MySQL的Docker容器化大规模实践,提到了资源隔离、容器的调度、磁盘挂载、集群扩容、高可用管理等。

  大规模分布式存储系统:原理解析与架构实战》是分布式系统领域的经典著作,由阿里巴巴高级技术专家“阿里日照”(OceanBase核心开发人员)撰写,阳振坤、章文嵩、杨卫华、汪源、余锋(褚霸)、赖春波等来自阿里、新浪、网易和百度的资深技术专家联...

  图神经网络(GNN)主要是利用神经网络处理复杂的图数据,它将图数据转换到低维空间,同时最大限度保留结构和属性信息,并构造一个用于训练和推理的神经网络。在实际应用中,为了加速GNN训练和新算法的快速迭代...博文来自:cpongo4的博客

  node1与node2主机角色分配:NameNode、DFSZKFailoverController;需要安装软件有:JDK、Hadoop2.7.1 nod3主机角色分配:ResourceManager;需要安装软件有:JDK、H...

  Kubernetes 原生的 Service 负载均衡基于 Iptables 实现,其规则链会随 Service 的数量呈线性增长,在大规模场景下对 Service 性能影响严重。本次分享介绍了华为云在 Kubernetes servic...

  内容简介 · · · · · · 《大规模分布式存储系统:原理解析与架构实战》是分布式系统领域的经典著作,由阿里巴巴高级技术专家“阿里日照”(OceanBase核心开发人员)撰写,阳振坤、章文嵩、杨卫华、汪源、余锋(褚霸)、赖春波等来自...

  大数据的ppt: 翟艳堂:腾讯大规模Hadoop集群实践 俞晨杰:LinkedIn大数据应用和Azkaban 杨少华:阿里开放数据处理服务 薛伟:腾讯广点通——大数据之上的实时精准推荐 夏俊鸾:Spark——高速大数据分析平台。。。。。。...

  2014年4月和5月,云栖小镇联盟先后两次在第二届中国电子信息博览会和第六届中国云计算大会亮相,越来越多的人知道这个组织的存在。很多参会者都惊奇于展区找不到阿里云,只有一个物种丰富的生态系统

  第一章:面向服务的体系架构(SOA)分布式首要面临的问题:如何实现应用之间的远程调用(RPC:RemoteProcessCall即远程过程调用,实现的方式如:RMI,WebService等方案)a。基...博文来自:cuichunchi的博客

  视频包含了图像、声音、文字等多种信息,可以表达生动、丰富的内容。随着AI时代的带来,互联网视频应用高速发展,视频更成为一种人人可生成的内容,数据量暴涨。如何利用机器学习将海量的视频内容充分利用起来,成...博文来自:weixin_33806914的博客

  最近,腾讯游戏学院放出了《腾讯移动游戏技术评审标准与实践案例》。正好最近不忙,就找时间通读一遍。记录一下有用的知识点。鉴于书内容较多,所以拆分为多篇博客。标题好长,改为:2018腾讯移动游戏实践经验。...博文来自:NRatel的博客

  PolarisSeven:虽然知道你想表达什么。。但是仍然不知道要如何做

  • 本文来自: 老铁博客,转载请保留出处!欢迎发表您的评论
  • 相关标签:程序员杂志  
  • 已有0位网友发表了一针见血的评论,你还等什么?

    必填

    选填

    记住我,下次回复时不用重新输入个人信息

    必填,不填不让过哦,嘻嘻。

    ◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。