Hadoop社区比 Ozone 更重要的事情-阿里云开发者社区

开发者社区> Apache Spark中国社区> 正文

Hadoop社区比 Ozone 更重要的事情

简介: 本文回顾了最近几年Hadoop项目的发展,着重探讨个人对Ozone的看法和理解,不求正确,引玉而已,欢迎业内专家拍砖讨论。

作者:郑锴,花名铁杰,阿里巴巴高级技术专家,Apache Hadoop PMC,Apache Kerby 创立者。深耕分布式系统开发和开源大数据多年,目前专注于在阿里云上提供更好用更有弹性的 Hadoop/Spark 大数据平台。


最近几年忙着优化大客户上云使用 Hadoop / Spark 这种事情,Hadoop 社区的工作参与得比较少了。偶尔参与一些投票表决的事情,貌似新晋的 committer 都跟一些新项目有关,比如 Ozone。这个事情在国内有大厂在参与,看起来力度还不小,然后时不时地就有同学跑过来问我的看法。正好 Spark 中国社区跟我约篇文章,何不就此把我的零碎看法整理出来,一箭双雕,如果再有人问类似的问题,我就可以把这篇文章转给 TA。

简单来讲。Ozone 是很不错,也很有用;但从我作为一个社区参与者的角度来看,它救不了 Hadoop,就这个项目的前后十年来说,Hadoop 社区有远比它更重要的挑战需要去解决。

再过个五年十年,我们不妨做个想象,在开源与云厂商相爱相杀的格局下,在开源大数据的这个生态系统和版图格局里面,哪些项目会活得更滋润,哪些项目则日渐式微?毫无疑问,新的技术新的项目仍将不断涌出,Spark,Flink 也不能说就高枕无忧,但我想说明的是,Hadoop 生态会继续向前发展,Hadoop 项目本身的前景则可能更加黯淡。有长久生命力的东西都有它核心的定位和使命,然后基于此不断革新和进化。Spark 和 Flink 都定位是计算平台,前者从批计算入手,后者从实时切入,都不断夯实基础补足短板支持新的计算场景完善它的生态。然而Hadoop呢?

Hadoop 项目的核心定位是什么?我想最没有争议的应该是大数据平台,核心支撑有二,一是存储,二是调度;承载的是计算,包括各种辅助支持,比如安全。我对调度略懂,存储上可以展开说说,姑妄言之。Hadoop 社区最近几年,在它的核心支撑点存储上面,应该最主要的工作就是开发 Ozone。Ozone 定位是对象存储,类似于 AWS 的 S3,阿里云的 OSS,只是 Hadoop 出品,虽然姗姗来迟。我记得大概是在五年前吧,那时正和社区热火朝天地搞 HDFS EC ,突然 HortonWorks 一帮人抛出 Ozone,说是要搞对象存储,当时给我的感觉就像是不务正业。

对吧,你不能说人家 AWS 搞 S3 受欢迎,你也要有,它跟 HDFS 有啥关系对解决 HDFS 核心挑战有啥助益?说的最多的是解决小文件,可这个问题并非核心,一般都从数据治理入手规避掉了。还有就是近乎无限的水平扩展性,可人家是云厂商面向海量用户海量提供,单个用户来部署 Hadoop 的哪有那么大的体量?阿里巴巴数据体量非常非常大,不可能靠 Hadoop 来支撑,所以自研飞天。Hadoop 比较合适的用户定位应该是中大规模部署,小到几十个节点几 PB 数据规模,大到上千节点上百 PB 数据这种。这类用户使用 HDFS 的核心痛点是什么呢?Ozone能不能实质性地解决这些核心挑战?下面我们来分析看看。

第一,复杂。非常的复杂。HDFS部署一套高可用的系统,不算 active/standby NameNode,相关的 master 服务七七八八的好多个,3 个 ZK 服务,3 个 JounalNode 服务,2个 ZKFC 服务。这还只是一个实例,如果用上 federation,比如支持 2 个 namespaces,那就要翻倍了。怎么运维管控这些服务,我想圈子里面的同学应该没少头疼过。这对大量的中小用户意味着什么,需要专家来支持;对大体量的用户则需要一大堆专家来优化。对大量的下游系统意味着什么?沉重的依赖。

所以这也就难怪近几年有个怪现象,发轫于 Hadoop生态,却不断见到喊着要逃离 Hadoop,去 Hadoop 化。这里面最明显的就是 Spark 和它背后的 Databricks 了。解决这个复杂性的技术方案并非没有,比如最近几年流行起来的 Raft + RocksDB,Ozone 现在就在用。我们在阿里云开发 JindoFS 系统,部署3个节点的 Raft Group 来提供元数据服务,把文件元数据放置在 RocksDB,靠内存来做缓存,然后用上细粒度的锁,在部署维护上的简便性和支撑的元数据规模上面,比 HDFS NameNode 方案简直好太多。HDFS 社区对于改造 NameNode 实现它的 scale up 和 out,有过多次冲动,可惜因为各方势力斗法,一次次错过良机,在这方面现在基本上偃旗息鼓感觉就是坐吃等死了。

其次,成本。本地存储,数据 3 备份,简单粗暴可靠。这在大数据的发展阶段是无可置疑的,可是搞到现在基本还停留在这个水平,就有疑问了。存储成本应该是大数据发展起来后作为存储系统的最核心问题,毕竟数据规模一直在膨胀,要么加快数据淘汰,要么支持更低成本,谁能做到单位存储成本最低,谁就能笑到最后。

解决数据3备份存储开销的最有效手段毫无疑问是 EC(Erasure Coding,国内译为纠删码),用 6+3 的配置成本能降低到一半。HDFS 曾经两次向 EC 发起冲锋。第一次应该是 Hadoop 1.x,代号HDFS-RAID志气不小,应该主要是 Facebook贡献的,不过沿袭了他们在 Apache社区一贯的手法,虽然能 work但实现方式却非常粗鄙,依赖着 MySQL 倒过来耦合计算框架MapReduce,非常像某个Hadoop 集群上开发的一个工具,因此在 Hadoop 升级到 YARN 时代的时候就从代码库里面删掉了。

第二次是大概五年前,Intel 在 X86 上有个 ISA-L 的库专门做 EC 加速的,想把 EC 做进 HDFS 的心思其实早就有了,在对 Cloudera 投了大把的钱之后,终于在社区轰轰烈烈的联手发起了代号 HDFS-EC 的又一次冲锋。这一次发誓要做到存储系统里面,而不是个外挂,在最初的两年,声势浩大,开发迅速,可惜因为 Hadoop 3 改动太大一直不能直接从 Hadoop 2 升级,就导致用户一直处于观望状态,这后面的事情就比较拖沓了。EC 的核心贡献者慢慢转向新的领域,Ozone搅局分散了大半社区精力,基本上在促进 EC 落地的事情上,我认为社区不必要地耽搁了至少2年时间。也就是直到现在,大规模的 EC 上线生产部署才初见端倪,可谓姗姗来迟。

降低存储成本的另外一种方式是使用更为廉价的后端存储系统。HDFS 是事实上的大数据存储系统接口标准,本来是持有数据坐拥天下之利的,可惜在架构上一直未能有效地演进革新,来支持本地存储之外的更为廉价的后端存储系统。微软在 Hadoop 社区的领导者 Chris 做过这方面的努力,支持了把 Azure Blob 挂载到 HDFS 映射到 DataNode 上的一个 tier,可惜功亏一篑,最终只是个半成品。在 JindoFS 上,我们支持 OSS 这种后端,可以只写1备份数据到它上面,数据高可靠高可用,自身只需要做好缓存加速,同时利用 OSS 的数据分层能力支持好冷热分层存储,在成本上能做到非常大的节省。

第三,性能。在存储系统层面,Hadoop 利用 HDFS 多备份和数据本地化把大数据分析处理的吞吐发挥到极致,应该是到顶了。可惜 Hadoop 项目本身在大数据平台层面,就此裹足不前,未能及时在存储格式上进行创新和消化业界的进展(Parquet,Orc,Arrow),也就未能为各种计算引擎提供更好的支持(Spark,Flink),在场景上不能有力地支撑跟进存储计算分离的趋势(Alluxio),在架构上不能容纳更新的存储硬件体系(SSD,AEP,因为无用武之地)。

这就形成一个局面是 Hadoop 自身日渐式微,但新项目却不断涌现,基础性的重复性的大家各自造轮子,导致整个生态系统臃肿不堪集成难度非常之大,看看 Hadoop 背后的厂商Cloudera和它的主要产品CDH,就知道它为什么越来越名副其实真像头大象了。我们在 JindoFS 上面的做法是,在各个计算引擎都依赖的基础支持都会尽量下沉,存储和计算结合起来优化,除了Hadoop 标准的那些文件系统接口外,我们支持额外的扩展方式,避免中间适配实现直通。达到的效果是,用相同的集群配置,在单文件操作上我们跟 HDFS 不相上下,但是在端到端的作业性能上面,我们能够普遍比 HDFS快,很多情况下甚至有几倍的性能提升。

在平台层面,Hadoop 需要不断进化的事情就太多了,然而因为类似的情况,不能说是停滞不前也谈不上有非常大的发展。比如安全,Hadoop很早就支持了Kerberos,可是在怎么集成和支持更多的企业级认证,或者适配云端环境上,一直没有什么实质性的变化。权限支持是在外围项目里面做的,Cloudera 的 Sentry 和 HortonWorks 的 Ranger 各行其是终于又合二为一。YARN 上面的调度可能稍微好些,不过还是力量发散,之前分出去个 Slider做了很久又合并回YARN,这两年又在忙活一个 Submarine支持深度学习,然后在关键核心的追赶 K8S 或者是拥抱融入K8S上面显得后劲乏力,导致YARN现在也是进退失据。

Hadoop社区之所以一再地发生上述情况,究其原因是在它发展的关键阶段,缺乏一个主心骨,Cloudera 和HortonWorks 长期斗法相互拆台,即便现在合并了,也仍然缺乏一个核心的领导人物,协调好各大山头能够聚焦在真正核心的问题上,而是各凭兴趣自打小算盘,不断地挖墙脚分化Hadoop 社区本就日渐式微的力量,东搞一块,西拉一堆,看上去都挺有道理的,但对Hadoop 项目本身,对Hadoop这个大数据平台的核心定位,从长远来看百害而无一益。Ozone就是这个情形下的产物,也是最好的例证。

回到Ozone,它能代替HDFS成为一个更好的大数据存储方案吗?它能解决上面所说的核心痛点吗?复杂,成本,和性能。并不能,实际上也许恰恰相反。Ozone使得Hadoop看上去更加庞大复杂了,一个对象存储系统做到生产上线的程度它不会复杂吗?复杂 + 复杂。在存储上它仍然采取三备份的策略,也未必会有社区精力去支持EC,因此成本也不会降低。至于性能?HDFS 是为大数据分析量身打造的文件系统,是计算对存储的原生依赖,一个对象存储系统必须要再加上一层适配,比如OzoneFS,才能满足计算上的用途,即使是在一些场景上比HDFS快,那也是拿长处比短处,不见得真英雄。如果把HDFS的弊端给干掉,比如像JindoFS,把元数据放在K/V的数据库里面,采取细粒度的目录/文件锁,充分的并发,HDFS文件系统方式而不是对象存储这种实际上可以做得更快。

公有云上不大可能有Ozone什么事,各家云厂商都在主推自己的对象存储产品(AWS的S3,Aliyun 上的OSS),而且已经形成规模效应会越来越便宜,可以保证好多个9的高可用,有哪个用户会蛋疼到自己来自建Ozone集群为了使用对象存储,成本不低,性能不高,又很复杂?混合云或者Cloudera所谓的企业云上,可能有一定的用户,但是它能跑得过云计算发展的大势吗?不排除有一些重量级的走开源路线的互联网公司,比如国内的小米,滴滴,美团,京东这种,基于Ozone来构建自己的存储计算分离方案,目前来看也不太明朗,因为Ozone来得太次了,这些互联网公司红利吃尽规模到顶,搞到现在基本上都已经有了自己成熟的一套。现在是需要省成本,所以反倒像HDFS EC这种技术应该会加快部署落地,线下IDC机房扩不动了或者相比上云代价太大,增量基本上都会上公有云,哪有资源大规模部署Ozone?。

那回到这篇文章的题目本身,Hadoop社区比Ozone更重要的事情是什么?总结一下,那就是坚持Hadoop作为大数据基础平台这一核心定位,同时积极拥抱云计算发展大势,重点做好以下几个方面。

第一,强化大数据存储解决方案的定位,加快完善落地EC这一关键成本利器,技术架构改造升级,去除HDFS不合时宜的复杂性并能够支持各种后端系统,做好数据冷热分层,利用各种手段降本提效。

第二,积极支持存储计算分离场景,引入缓存架构(Alluxio),在存储格式等方面提供基础框架,有能力充分发挥各种硬件潜力,为各种计算引擎做好优化支持,增强Hadoop平台的粘性和向心力 。

第三,积极拥抱公有云,充分支持和优化好主要云厂商的对象存储产品而不是自己另搞一套(Ozone);面对现实拥抱容器化和云原生,改造YARN积极融入K8S结束精神分裂,为用户提供更好的计算调度方案,而不是让广大的用户观望纠结。

像从Hadoop社区走出去的众多项目(Hbase)一样,我不否认Ozone本身的价值,放眼开源世界,貌似还找不到像样的对象存储项目(也许Ceph算一个?),Hadoop利用余晖赶紧推出一个新的方案绑定输出,也不失为一个策略,而且脱掉社区的外衣就具体的厂商而言,未必就没有很大的落地应用价值。我只是想说,从这个项目的长远考虑,Hadoop社区有比它更重要的事情,关乎未来。

姑妄言之吧。作为Hadoop社区一位成员的反思,我仍然是希望Hadoop项目能够继续向前健康发展,也希望哪一天条件成熟在更大层面回过头去为Hadoop再做一些贡献。现在Hadoop社区有一个好现象是,华人面孔越来越多了,像Ozone和Submarine这种新拉出来的子项目,可以起到发展社区的作用,所以有兴趣做开源同时又需要造轮子的同学,建议参与到这些新项目,与社区共同成长。阿里巴巴计算平台的开源大数据部门(EMR),也非常欢迎有社区经验的同学加入我们共同打造JindoFS,一起繁荣开源生态。

关于JindoFS,它沉淀了我们在Hadoop上关于核心定位的诸多思考,事实证明,这种思考非常有益。正是两年前我们在阿里云上结合大量的各种用户使用场景反复琢磨,什么才是EMR这种开源大数据平台(基于Hadoop/Spark)的真正核心价值,我们才决定兵分两路研发Jindo引擎,一路指向以Spark为核心的计算(JindoSpark,杭州团队,计算),一路就是本文反复提到的JindoFS( 上海团队,计算+存储),在云原生上我们去年也开始了团队的组建(北京)。在核心价值上做文章,如今成效显著,JindoFS大量用户落地,我们的开源大数据产品E-MapReduce也刚刚喜报传来,性价比(性能/成本)再一次打破世界纪录,霸榜TPC-DS,有好奇心的同学可以自己去上TPC官网上看看。JindoFS的全面介绍敬请期待下文,到时探讨一下看它是怎么在云原生大行其道的今天,如何在诸多方面继承,发展和超越HDFS的。对我们上述相关工作领域感兴趣的同学可以邮件联系我(zhengkai.zkATalibaba-inc.com),北上杭都在大量找人,我们欢迎你。


阿里巴巴开源大数据技术团队成立Apache Spark中国技术社区,定期推送精彩案例,技术专家直播,问答区近万人Spark技术同学在线提问答疑,只为营造纯粹的Spark氛围,欢迎钉钉扫码加入!
image.png

对开源大数据和感兴趣的同学可以加小编微信(下图二维码,备注“进群”)进入技术交流微信群。
image.png

Apache Spark技术交流社区公众号,微信扫一扫关注

image.png

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

阿里巴巴开源大数据技术团队成立Apache Spark中国技术社区,定期推送精彩案例,问答区数个Spark技术同学每日在线答疑,只为营造纯粹的Spark氛围,欢迎加入!邀请你加入钉钉群聊Apache Spark中国技术交流社区,点击进入查看详情 https://qr.dingtalk.com/action/joingroup?code=v1,k1,X7S/0/QcrLMkK7QZ5sw2oTvoYW49u0g5dvGu7PW+sm4=&_dt_no_comment=1&origin=11

官方博客
官网链接