作者：郑锴，花名铁杰，阿里巴巴高级技术专家，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氛围，欢迎钉钉扫码加入！
对开源大数据和感兴趣的同学可以加小编微信（下图二维码，备注“进群”）进入技术交流微信群。
Apache Spark技术交流社区公众号，微信扫一扫关注
