订阅云计算RSS CSDN首页> 云计算

大数据架构与系统(下午):YARN与Hadoop 2.0

发表于2013-12-06 17:23| 次阅读| 来源CSDN| 0 条评论| 作者包研

摘要:2013中国大数据技术大会大数据架构与系统专题论坛下午场,来自LinkedIn、Hortonworks、智明星通、阿里巴巴的嘉宾分别分享了各自在大数据领域的最新实践。

【CSDN现场报道】中国最具影响、规模最大的大数据领域盛会—— 2013中国大数据技术大会(Big Data Technology Conference,BDTC)于2013年12月5-6日在北京举行。数十家领军企业,近七十场主题演讲,不仅覆盖Hadoop生态系统与流式计算,实时计算与NoSQL、NewSQL等技术方向,还对互联网、金融、电信、交通、医疗等创新案例,大数据资源的法律法规、大数据商业利用的政策管制等有深入讨论。

大数据架构与系统专题论坛下午场,来自LinkedIn、Hortonworks、智明星通、阿里巴巴的嘉宾分别分享了各自在大数据领域的最新实践。

LinkedIn Hadoop核心团队成员俞晨杰:LinkedIn大数据应用和Azkaban

首先介绍LinkedIn在Hadoop平台上的大数据应用。包括其数据产品和推荐平台等。第二部分介绍我们的工作流调度平台Azkaban,包括我们如何设计Azkaban来满足大数据产品及工程师设计的要求,其中的一些特性来自于我们过去应用中的经验教训。

图:LinkedIn Hadoop核心团队成员 俞晨杰

俞晨杰表示,Azkaban最大的特色是非常强调可视化。如果每个月的PYMK(People You May Know)串起来看,大家看到这么多年一直不断在改进。在这种情况下,可视化帮助提高我们生产力是十分关键的。

俞晨杰认为,Azkaban的另外一个特色是支持各种各样的大数据平台,有非常好的兼容性。包括支持Hadoop 0.20、1.x和2.x;兼容Hadoop多种配置,如Hadoop security;支持Pig、Hive等SQL引擎的新旧版本兼容;最后还支持一些非Hadoop平台,如Teradata。

Apache Tez Committer Bikas Saha:下一代Hadoop

图:Apache Tez Committer Bikas Saha

Bikas Saha介绍,YARN的架构看上去与Hadoop 1.x非常类似,但是逻辑上两者不同。相对于Hadoop 1.x,YARN的优势包括了:增加了新的应用和服务;增强了集群的利用率;规模更大;实验的灵活性;共享服务等等。

增加了新的应用和服务:

  • 从应用逻辑中分离一般资源
  • 为开发者定义的一些列协议和库,并提供框架
  • 支持同一集群内的跨应用共享

增强了集群的利用率:

  • 通用的资源容器模型替代了死板的Map/Reduce格式。容器基于本地的内存(CPU将很快支持
  • 多应用共享集群

可扩展性:

  • 从RM中移除了复杂的应用逻辑
  • 消息传递基于松耦合
  • 紧凑的队列协议

实验的灵活性:

  • RPC使用协议化的缓冲区
  • Map Reduce成为用户空间的应用
  • 多版本应用共存
  • 更容易升级的框架和应用

共享服务:

  • 插件框架中,一般的服务需要建立分布式的应用
  • 分布式的文件贡献服务
  • 远程数据读服务
  • 日志聚合服务

Bikas Saha分享了YARN愿景的规划,通过YARN可以把所有的数据储存在一个地方,并且用不同的方式进行交互,同时提供性能预测。比如Windows或其他操作系统可以对系统内不同的资源进行分配和管理,YARN也能够进行这种集中管理。

Hortonworks Technical Lead Gunther Hagleitner:Apache Hive & Stinger


图:Hortonworks Technical Lead Gunther Hagleitner

Gunther Hagleitner首先分享了Stinger诞生的背景,希望通过社区推动下一带的Hive的发展,希望将Hive的查询速度提升一百倍,并支持交互查询。同时我们希望提升可扩展性,这是下一代Hive的目标。大约是一年之前,我们推出了Stinger,并不断对Stinger优化。在对一个查询进行分区的时候,可能会要用比较长的时间,于是希望Hive能够有更多的交互的响应。之后,我们也是希望进一步提升ORC的速度,能够更快、更有预见性。如果有一些文件在我们查询过程不需要,就能够自动忽略他。

接下来,Gunther详细介绍了插入、更新、删除操作。Gunther表示,那么对于Hive来讲,我们所加入一些相关内容就是实事的交易。我们客户的表格可能每个小时都要进行更新或删除。当每次如果出现更新时,会存储一个新文件,并记录所有的变化。当查询的时候,我们会有一系列的交易的列表,会把这些这些文件进行整合。

最后,Gunther也谈到了Tez。Gunther表示Tez替代了MapReduce。使用Tez后,Tez可以针对不同的任务MapReduce任务进行提交。

Sze, Tsz-Wo (Nicholas) :HDFS在Hadoop 2.0中的创新

图:Sze, Tsz-Wo (Nicholas) 

Nicholas首先介绍了如何解决Namenod的单点问题,解决方案就是Multiple Namenode Federation,他有有多个Namenode,每一个Namenode都是独立的。

Nicholas介绍了HA的2.0版,包括支持热备(热备的NameNode会在内存中维持数据结构),支持手动或自动的失效备援。在自动失效备援情况下,激活NameNode选择机制以及采用ZooKeeper侦测失效;周期性的NameNode健康检查;重放缓存。

接下来Nicholas介绍了文件系统快照。在没有文件系统快照前,删除文件是不能够恢复的,也不能在某时间点恢复,更不能周期性的恢复。

智明星通CTO穆黎森:基于Drill的实时游戏数据分析系统

图:智明星通CTO 穆黎森

穆黎森介绍了Xingcloud作为一个数据分析平台要解决什么问题。他表示,我们需要从数据挖掘出一些结论,包括今天有多少人登陆,收入是多少,即针对这些问题建立模型。我们用这样一张表就可以描述出,谁在什么时候做了什么事情。这是一个非常明确的,刚才我提出这些问题其实都可以转化成SQL语言,今天有多少的独立用户,或者是总的收入,或者是支付用户的数量也是可以相应的转化成SQL语言执行。

接下来我们的策划或运营人员了解运营情况之后,深入的挖掘DAU背后的信息,比如用户数量减少时,是来得于中国的数减少了,还是美国的数减少了。今天来用户贡献收入是什么样?所以这一类问题他们的共同点就是说他们引入了一个用户的概念。用户不仅有一个ID,在某个时候做了某件事情,并且一个用户是有属性的。比如注册时间,不同的用户,基于这两个表,我提出那几个问题可以得到很好的回答。大家应该会很清楚,他们其实就是在基于SQL基础上做一个操作。基本上来说,我们大部分的业务需求可以总结成这样一种语句,首先是一个聚合,选择一些用户详细探讨这部分用户的行为。他们一个共同点就是说有一个,这是一个简单的结论。

穆黎森在演讲中透露称,Xingcloud目前每天大约有20亿次插入/更新、200K+聚合数据,查询响应时间平均大约在10秒,而对于他们的Drill,目前也已经加入了分布式,与此同时存储引擎上加入了写入接口等。

阿里数据平台事业部海量数据技术专家 罗李:构建一个跨机房的Hadoop集群

图:阿里数据平台事业部海量数据技术专家 罗李

罗李首先介绍了阿里巴巴Hadoop集群——云梯的现状,以及产生跨机房部署的背景。罗李表示,,从2008年开始搭建Hadoop集群,2009年上线。从那以后这个集群的代码一直是自己的维护。我们可能会经常触及一些社区的改进,个性化的需求做我们自己的开发,这个版本是我们自己维护的版本。今年4月份规模是4500台机器,100PB存储容量。到4月份时运行非常好,但发现一个解决不了的问题,按照当时数据的量增长程度,最多到今年6月份就会达到机房5000台机器的上限。而且整个阿里集团,各个公司业务线历史数据也不能删掉,于是就不得不面对跨机房的Hadoop部署问题。

同时,阿里的集群是服务的地群,当数据跨机房了,多个NameNode分布也会因为机房在物理上做一个跨越,如何对用户作到透明。这个地址是一个IP地址,就是一个NameNode地址。我们不可能划分成了两个,肯定有一些数据放在另外一个NameNode上。最开始遇到一个问题,就是扩展性,四千多台机器的时候一个NameNode机器还是撑得下来,到一万台就不可能了,内存也撑不下来。因为内存不可能那么大。跨机房网络带宽限制,就是点对点的带宽是千兆,这种作用每台点对点的带宽是及十兆是不可想象。然后还有就是机房之间带宽有这个性质,这种延迟对业务上影响也是非常大。接下来一个问题是数据该怎么样分布。我们的集群里面的数据管理是按照组来划分,比如说这个目录是给淘宝用的。那么数据全部放在这个目录下边,这个目录给天猫用,那个给据划算用给B2B用,这个在目录上划好,哪些目录放在一起,哪些目录另外己方的一起,这些我们是没有经验。我们不知道是说哪些访问数据,一定要访问另外一个组的数据,这些数据我们是没有,我们就只能是说通过集群里面一些历史的日志,历史数据访问的日志做聚类,最后决定这个划分的策略。

罗李表示,存储利用率超过了80%是非常危险的信号,有一些机器数据非常的满,有两三千台达到了98%,非常危险。计算利率用接近100%。实现跨机房部署,困难其实非常多,包括不支持NameNode扩展,带宽如何解决,数据应该怎么去分布,最后怎么样把这个机房90%的数据进行迁移,这个数据量达到50多个P,迁移会非常慢。

更多精彩内容,请关注直播专题2013中国大数据技术大会(BDTC)  ,新浪微博@CSDN云计算
0
0
  • CSDN官方微信
  • 扫描二维码,向CSDN吐槽
  • 微信号:CSDNnews
程序员移动端订阅下载

微博关注

相关热门文章