【AICon】探索八个行业创新案例,教你在教育、金融、医疗、法律等领域实践大模型技术! >>> 了解详情
写点什么

专访王峰: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:103124

评论

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

RabbitMQ 的五种消息模型

Ayue、

RabbitMQ 3月月更

《不敢止步》--读书笔记

stars

【面试-经验之谈】面霸是如何养成的,他的路子真的野

测试猿温大大

面试 涨薪 测试工程师

优秀程序员的30种思维--技术执念篇(22/100)

hackstoic

技术思维

架构学习总结

tony

「架构实战营」

掌握《网络》,见微才能知著

蔡农曰

TCP https 网络 HTTP TCP/IP

一个用于学习KVM的迷你虚拟机

ScratchLab

虚拟机 虚拟化 kvm VT-x

B端/C端中,产品or运营哪个更重要?

源字节1号

运营

高并发架构实战课 期中测试:某达架构设计说明书

👽

李智慧 高并发架构实战课 李智慧

当在线纠纷解决遇到区块链:去中心化司法的诞生

CECBC

架构实战营毕业总结

novoer

「架构实战营」

LabVIEW实现CRC校验

不脱发的程序猿

LabVIEW CRC校验

聊一聊C语言位域/位段

不脱发的程序猿

C语言 嵌入式开发 位域/位段

2万字详解测试金字塔

俞凡

最佳实践 测试 研发效能

云上业务配置选型的一些小Tips

穿过生命散发芬芳

3月月更

尤达 DDD 领域驱动设计思想 第四章作业(使用事件风暴建模法对SmartRM系统的交易域重新建模)

代廉洁

尤达DDD领域驱动设计思想

架构师实战营王者荣耀商城异地多活架构设计

刘洋

#架构实战营 「架构实战营」

Redis缓存应用—旁路缓存和数据一致性

javaadu

redis 缓存

更新丨织信Informat V1.12:审批流通知支持移动端打开链接,一键实现快速审批

优秀

低代码开发

ICT的圣杯(三):产业融合的技术乐章

脑极体

自己动手写Docker系列 -- 4.4实现简单镜像打包

Docker

一个LabVIEW控件,生成模拟波形效果

不脱发的程序猿

数据可视化 LabVIEW 生成模拟波形效果

元宇宙时代的5大风险

CECBC

区块链技术如何赋能公共资源招采管理服务?

CECBC

常见的社群玩法盘点,你做的是哪一种?

源字节1号

开源 社群

电路模型和电路定律(Ⅰ)

謓泽

3月月更

模块九秒杀作业

novoer

「架构实战营」

从简单代码入手,分析线程池原理

架构 线程池 池化思想

模块九:毕业设计

黄秀明

「架构实战营」

模块5作业-”微博评论“的高性能高可用计算架构

卡西毛豆静爸

「架构实战营」

腾讯一面:说一说 MySQL 中索引的底层原理

老周聊架构

MySQL 3月月更

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