HarmonyOS开发者限时福利来啦!最高10w+现金激励等你拿~ 了解详情
写点什么

专访王峰:Hadoop 生态下一代计算引擎 -streaming 和 batch 的统一

  • 2016-03-02
  • 本文字数:5527 字

    阅读完需:约 18 分钟

编者按:Hadoop 于 2006 年 1 月 28 日诞生,至今已有 10 年,它改变了企业对数据的存储、处理和分析的过程,加速了大数据的发展,形成了自己的极其火爆的技术生态圈,并受到非常广泛的应用。在 2016 年 Hadoop 十岁生日之际,InfoQ 策划了一个 Hadoop 热点系列文章,为大家梳理 Hadoop 这十年的变化,技术圈的生态状况,回顾以前,激励以后。本次 InfoQ 便采访了阿里搜索离线基础平台团队负责人王峰,和大家一起聊一聊 Hadoop。

InfoQ:您是 2009 年开始关注 Hadoop 生态技术发展,并逐步将其引入阿里电商搜索技术体系。那时的 Hadoop 生态圈是怎样的?可否介绍下 Hadoop 在阿里的历史?

王峰:对于 Hadoop,我个人很早就了解了。Hadoop 06 年出来,我们 07 在雅虎中国见到用 Hadoop 做 search,搜索引擎是大数据的第一个应用场景。当时和雅虎美国合作看过 Hadoop 应用,那时还是 0.1x 版本,07 年也见到了 HBase 被首次尝试用于 yahoo vertical search 中。在 08 年阿里第一个 Hadoop 项目——云梯,就在我们搜索技术中心诞生的。09、10 年我重新到淘宝搜索后台开始建立 Hadoop,算是正式将 Hadoop 用于生产系统,以前是直接做离线数据分析、BI、统计,不支持在线业务。10 年我们将整个阿里巴巴的搜索、后台数据、商品更新这些数据用 Hadoop 从 MySQL 同步过来,做处理,建索引,更新到线上的搜索引擎,供买家搜索商品,做跟交易相关的线上系统的连接。那时也开始做 HBase,刚起步,做阿里集团以及全网商品的存储。10 年时集群才 100、200 台,而现在个性化搜索、推荐这种真正引导电商成交的关键链路都是在 Hadoop 上做,现在应该有几千台规模做实时交易的数据处理,这已经不是大数据场景的数据挖掘、数据训练,这是 online 或者说 nearline。我们是服务于在线的数据分析,比方说一个卖家更新一个商品,我们可以秒级同步到线上让买家看到。这听起来简单,但像淘宝这样的电商,这是要经过好几百个 feature 的计算,很多数据处理的环节,这个过程是很长的。而我们甚至在双 11 的场景,也能做到秒级。

InfoQ:对于 HBase 而言,Java GC 和读写性能是它的两大问题,这方面你们做了哪些优化吗?

王峰:HBase 我们是长期投入,现在我们有一些成员专注跟 HBase。GC 方面也是比较大的投入,在高并发读写、大数据量情况下,比如双 11,就有 2 千万 QPS,那 GC 就成了大问题。但又不好调,Java 的 GC 又不能代码级改动。现在主流是用 CMS GC,相对来说还是最稳定可调的,我们也针对我们应用场景做了定制调法,因为 GC 调法没有规范,只能说适合你的系统。比如你要考虑访问 IO 特性,来的 request 大小,新生代旧生代规律,像我们就是除了 GC log,还配合 visualvm 等工具直接去看 GC 情况,尝试各种参数组合去调,然后找到相对最优的,其实是磨出来的,经过实践找到的。
而关于读写性能,HBase 用 HDFS 做文件系统,而 HDFS 是高吞吐而不是低延迟,所以本身不是随机访问能力很强的。而且我们情况更为困难,为了提高效率,我们 HDFS,YARN 和 HBase 是混布的,HBase 和 HDFS 做存储,YARN 做计算调度,资源是共享的。 对此我们的解决方案是利用 HDFS 的新特性:支持内存、SSD、HDD 混合存储。不过混合存储不很稳定,不很成熟,我们做了自己的优化,改进了 one SSD 策略。就是 HDFS 有三个冗余备份, 我们用一块冗余备份做 SSD,同时我们在混合架构下也做了自己策略的优化,就是有些机器有 SSD,有些没有,因为集群的机器不可能都是一样的。我们做了特制的优化,做到访问热点数据或关键表数据都是 SSD,随机读在 SSD,顺序读在普通的机械硬盘做。这样随机读、顺序读、HDFS 和 HBase 在 IO 的隔离,就天然地实现了。这样后,在高并发时,SSD 的高 QPS 的特性可保证 HBase 的 latency,而且成本低很多,因为只是把重要的数据的一份放在 HDFS 上。

InfoQ: 有人说,目前 YARN 和 HDFS 是同级别的模块,而以后 HDFS 会成为 YARN 的一个组件,也由 YARN 统一调度

王峰:我觉得理论上是可以的,但这里有一个相互依赖的问题,你要用 YARN,就要有一些 Storage 的支持,现在是 HDFS 作支持,这是循环依赖。比如我提交了我的代码,部署一个 application 到 YARN,比如 HDFS 作为第一个 application,那它存在哪里,要把包传上来,所以至少要有一个存储。或者说你为它单独定制一个存储,但我个人认为这个意义不大,比如很多人谈 HBase on YARN,Kafka on YARN,我觉得运维或临时搭集群才有这个需求,生产系统没有。因为 HDFS ,HBase,Kafka 都用到本地磁盘,不可能临时搭一个就换了,因为 on YARN 的东西就是可以随时漂移嘛,但我搭了 HDFS ,肯定是每台机器一个嘛, 不能是有些机器有,有些机器没有,而且过两天还要换?! 数据是不适合来回移动的,否则成本会很高。你有这个需求那就类似搭虚拟机一样,我先起来一个 instance,过两天不用了就关掉,过两天再起起来,这个适合临时集群,对稳定的生产集群意义不大。

InfoQ:YARN 增加了对 Docker 的支持,您觉得 Docker 对 YARN 意义大吗?

王峰:Docker on YARN 也是一种尝试嘛,这并不冲突,YARN 作为调度管理。Docker 可作为容器部分和执行器,这个趋势更像一个轻量级虚拟化的资源管理方式,我个人觉得这是有用武之地的,特别是做一些轻量级的 application 的资源复用。做一些简单的 web 服务啊,python 程序,如果都做一个虚拟机,隔离太重了,毕竟有开销。而这么做就好很多。YARN 专注于调度,将隔离交给 Docker,是不错的解决方案,阿里内部就有很多这样的思路,已经实现了。

InfoQ:Yarn 会朝着通用资源管理和调度方向发展吧?包括对 MapReduce、Spark 短作业的支持,以及对 Web Service 等长服务的支持

王峰:恩。我觉得这是 Hadoop 社区最大的成长空间,一开始 1.0 是 HDFS +MapReduce,2.0 后是 HDFS +YARN。HDFS 作为基于大文件的分布式文件系统基本比较通用了,没有必要找替代物了,但 YARN 还有类似的系统,如 Mesos。不过它与 YARN 理念不完全一样,也有不少场景在用 Mesos。
刚刚说,作为 Hadoop 生态系统最大的生长空间其实在于 YARN,因为 HDFS 比较稳定,文件系统的新功能推出也相对慢一些,重点还是在性能改进。反而是 YARN 可以让更多的生态进来,比如 Spark,Flink 这些东西都可以 on YARN,因为你在上面就可以和大家共享计算资源,所以 YARN 更像一个大的 Hadoop 生态的容器,希望把更多的新的技术包进来。这个做的好的话,我觉得它就类似 linux 成为大数据的 os,不管什么好的东西出来,你都可以运行在这个平台上。到那时 Hadoop 就只是一个代名词,那就意味着一种大数据的开源生态啦。 现在 Hadoop 已经是一个生态,但现在它和 Spark 是非常微妙的,Spark 也是一个生态,不过 YARN 的生态和 Spark 的生态不是一个概念。YARN 说 Spark 可以跑在我上面,Spark 说我可以不跑在你上面,这是一个矩阵交叉的感觉。但任何计算模型都是有生命周期的。所以我觉得 Hadoop 做的聪明的一点就是,把 YARN 这种 os 的概念放进来了,我不管你多好,我都可以把你放在我上面。你基于我来做,我不断沉淀我的 web os 系统,以后的模型都可以跑在我上面。所以它放掉了 MapReduce,MapReduce 其实是配角了,我觉得它慢慢就会荒废掉。但如果以后的计算模型可以和 YARN 结合好,那 Hadoop 生态社区就非常丰富,百花齐放。不同的新的好的东西都 share 资源,跑在一起,我个人觉得这是比较健康的发展方向

InfoQ:Spark vs Hadoop?它们是竞争关系?

王峰:我觉得现在来看,竞争关系也有一部分。就跟我们做产品一样,这就像微信和 ios 的关系,Spark 像微信,YARN 像 ios,当你的计算模型强到一定程度时,就希望把底下的东西盖住。就比如微信强到一定程度时,你就不需要用 ios 的东西,用我微信的东西就足够了,微信里什么东西都很全面。Spark 就这样,它很强势,它有自己的管理系统,其实你不用考虑在 YARN 上起别的东西,我这已经是个生态了,要跑批处理、跑流式、跑机器学习,它很全面,它都有。这就相当于说我不是直接说和 Hadoop 竞争,不是对等关系,但从用户角度来说,你的需求在 Spark 这层已经解决了,你可以忘记 YARN 那个东西,是这么一个竞争关系。但也可以是一个竞合关系,就是 Spark 可以把他的资源管理和 YARN 合作,你不能假设你解决了一切的问题,这是用户的选择,你不可能想到一切,而如果 YARN 上其他方案能解决,那你 run on YARN,这就是合作关系。

InfoQ:可否介绍下 Hadoop 生态目前最前沿的技术和概念?

王峰:分三个方向,一是调度,以 YARN 为主,这是一个比较核心的能力,往在线高可用方向发展。Hadoop 以前是离线,以后应该走向 online。以前离线调度作业,失败就失败了,而走向 online 调度就很有挑战。现在 YARN 也在努力,比如说没有单点,但离 Borg 还有差距。
二是存储,HBase ,HDFS 是老牌的,新的存储出现了,druid,pinot 这种新的列存储,真正的 colume 加上 index 的这种列存储,尤其是做数据分析的列存储技术都是相对新的,不再是老的那些概念了。也有一些新的方向,tachyon 这种分布式内存的,支持 Spark 的分布式内存存储系统,这都是一些新的思路,而且以后会有很好的业务场景的,因为这都是需求逼出来的系统,有很大的应用场景。
最火的还是计算,MapReduce 基本就更新掉,但不会马上离开,它的稳定性、吞吐量还是最好的,因为它积累了太多年,在一定场景内可以存在。但我觉得就是落后产业了。 新的像实时计算,Storm,不过 Storm 本身不是很先进的系统,可以说是上时代的产物了,Twitter 的 heron 以及阿里的 jstrom 还在发展 Storm 体系,但我觉得这也不是体量大的系统。最大的还是 Spark,Spark 是现在最辉煌的系统。我们还关注 Flink 这个系统,这是一个新的计算引擎。从理论来看,它比 Spark 更没有边界,更先进。Spark 很火,但是它毕竟是一个(batch)系统,做离线的,批处理的是它的先天优势,可能做一些内存迭代、机器学习或者替代 MapReduce 做算子层更丰富的批处理。但它本质是一个 batch,它最大的问题就是 Spark stream, 转换成一个离散的流,可以认为是把 batch 切小,每个 batch 可以认为是无限小,比如网络上一秒的数据形成一个 RDD 的 batch,再来一个,再提一个,不停地提 job。但是这个是 batch,就相当于你再切,他还是一个 batch,这是一个理论问题,不是你技术牛不牛的问题,就相当于给你一个木棍子,你切切切,你再切,切再薄的片,它还是有厚度的。但 Flink 是反的,它认为 stream 是一切,batch 是 special case,batch 只是一个有明确 start 和 end 的 stream,它是德国那个论文发的,Flink 的模型在我们看来是更先进的,它自己号称是第四代,它是说 MapReduce 第一代,Storm 第二代,Spark 第三代,它第四代。 Flink 还没发展起来,没大厂验证,但它基因更好,它拿流可以模拟 batch,这是完全没有约束的,就像我可以拿原子组成物体。而这是不可逆的,就像你不能把一个东西碎成原子,你只是一直切切切,但是原子可以组成任何东西。从这里来说,Flink 是 unlimited,它没有明显的技术限制。现实的例子是,我们想把数据做到毫秒级更新超大规模场景,Spark 是做不到的,根据他现在的理论架构无论如何做不到,RDD 是如何也做不到的。一个 batch,你怎么弄也做不到一毫秒提一个 job,这是不可能的。batch 粒度有点粗,你要想做到,你要做无限优化,还不敢保证成功。而 Flink 若做无限优化,就可以 stream 转 batch,所有你有的东西我都有。这其实是很恐怖的,特别在一个互联网领域,一个小东西如果基因足够好,有足够的成长空间,它可以长到无限大。而再大的东西遇到瓶颈的话,也会遇到危险。反正现在能看到的就是,Spark 能稳定的往前走,Flink 就看能不能冲起来。

InfoQ:最后一个问题,现有的 Hadoop 集群,版本是如何管理的?

王峰:我们团队是使用社区的版本,做一些自己的改进,并且会把改进提交到社区。因为我觉得很私有地维护一个版本是有问题的,因为社区发展很快,你私有一个版本,短期你觉得占便宜了,把很多新的东西弄进来,自己加了一些东西社区都没有。但一两年以后呢?这是长跑,你可以冲刺一下,但不能年年这样。你的团队会有变化,人员会有更改,会有业务上的紧张,资源进度上的变化。长期跑赢社区几乎是不可能的。我们选择的就是专门几个人跟这个方向,如果我们觉得这是一个好的抽象好的 feature,我们就会提交给社区。我们也在培养自己的 committer。我们不私有化这个东西,但肯定有一些非常定制的,这是不可避免的。比如社区就是不认这个东西,但我们业务的确有这个需求。我们会有一个阿里内部的发行版,用作集群部署的版本管理。这个版本会结合 Cloudera、社区版的(patch),把有些东西拿过来,和我们自己的(patch) 合进来,但是和社区是兼容的,比如社区升级,我们也会升过来,有些(patch)已经被合进社区版本了,没合进去的我们再合一次。但不会保留太多私有版本。

受访者简介

王峰,淘宝花名莫问,2006 年毕业后即加入阿里巴巴集团,长期从事搜索和大数据基础技术研发工作,目前负责阿里搜索事业部离线基础平台团队。自 2010 年开始将 hadoop 生态技术正式引入阿里搜索技术体系,带领团队打造出的数据基础设施,每日可实时处理阿里集团内的海量商品和用户行为数据更新,直接影响并提升搜索和推荐引导成交,承担了阿里电商数据流程的核心职责。我们团队管理着目前阿里最大的 Hadoop 集群,上面运行的搜索以及推荐业务也是阿里集团最核心的电商场景。我们希望站在 Hadoop 生态圈的肩膀上,基于自身业务场景优势,在实践中不断产生新技术并回馈给社区,与开源技术发展形成良性循环和促进,欢迎各位 Hadoop 生态圈内的有志之士加入我们(微博:淘莫问),一起打造世界一流的数据基础设施团队。

2016-03-02 16:103237

评论

发布
暂无评论
发现更多内容

【MySQL】面试官:如何添加新数据库到MySQL主从复制环境?

冰河

MySQL 高可用 主从复制

网易伏羲问鼎全球AI文创大赛:用户可零门槛生产音视频动画

核桃Eason

人工智能 AI 动画 网易

99%的人都能看懂的分布式系统「补偿」机制

华为云开发者联盟

分布式 高可用 系统

极客大学 - 架构师训练营 第二周

9527

面试官,ThreadLocal 你要这么问,我就挂了!

小傅哥

Java 面试 小傅哥 ThreadLocal 开放寻址

软件开发的 5 条核心原则,让工作事半功倍

沉默王二

程序员 软件开发

架构师训练营第一期-第二周课后-作业二

极客大学架构师训练营

免费CA证书安装配置与背后原理浅析

陈德伟

架构师 0 期 | 大数据相关技术

刁架构

架构师训练

第二周 框架设计学习总结

蓝黑

极客大学架构师训练营

大作业二:总结

zcj

HashMap源码解析

彭阿三

hashmap HashMap底层原理

不一样的面向对象(一)

书旅

php 面向对象

聊聊布隆过滤器

大头星

滴滴开源AgileTC:敏捷测试用例管理平台

滴滴技术

开源 滴滴技术 滴滴开源

LeetCode题解:83. 删除排序链表中的重复元素,迭代,JavaScript,详细注释

Lee Chen

大前端 LeetCode

多端消息推送的设计思考

TaurusCode

Java spring 设计模式 消息推送

C++的匿名函数(lambda表达式)

良知犹存

c++ 编程开发

TensorFlow 篇 | TensorFlow 2.x 基于 Keras 的模型构建

Alex

tensorflow keras model

学习Java的三个阶段(学习目标+知识点),一起努力吧!

Java架构师迁哥

10个常见的软件架构模式

GuoYaxiang

架构模式 软件架构 架构设计

第13周作业

阿里架构师不慎泄露内部互联网架构面试题库。你确定不看一下吗?

小Q

Java 学习 架构 面试 阿里

LeetCode题解:83. 删除排序链表中的重复元素,递归,JavaScript,详细注释

Lee Chen

大前端 LeetCode

架构师训练营第一期-第二周课后-作业一

极客大学架构师训练营

线上医疗未来的发展

anyRTC开发者

ios 音视频 WebRTC RTC 安卓

动图演示:手撸堆栈的两种实现方法!

王磊

Java 数据结构 算法

高难度对话读书笔记—认知篇

wo是一棵草

双亲委派模型与 Flink 的类加载策略

Apache Flink

flink

Java8 之 Lambda 表达式

hepingfly

Lambda java8 新特性

从 LRU Cache 带你看面试的本质

小齐本齐

算法

专访王峰:Hadoop生态下一代计算引擎-streaming和batch的统一_阿里巴巴_姚梦龙_InfoQ精选文章