转载

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

编者按：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生态圈内的有志之士加入我们（微博：淘莫问），一起打造世界一流的数据基础设施团队。

原文 http://www.infoq.com/cn/articles/hadoop-ten-years-part01

正文到此结束