专访郑锴：EC之后，HDFS下一步新思考

杭州·云栖大会将于2016年10月13-16日在云栖小镇举办，在这场标签为互联网、创新、创业的云计算盛宴上，众多行业精英都将在这几天里分享超过450个演讲主题（参会报名>>>https://yunqi.aliyun.com）。

为了帮助大家进一步了解这场全球前言技术共振盛会的内容，云栖社区采访了各个论坛的大咖，以飨读者。

以下为正文：

郑锴，现就职于Intel亚太研发中心大数据部门，从事Apache开源社区贡献和大数据相关优化，是Apache Hadoop committer和Apache Directory PMC，目前担任大数据研发经理，带领团队在一些主要的Hadoop项目上做优化。其带领的团队在Intel乃至在国内很早就开始做Hadoop开源贡献，在不少项目上比如Hadoop、HBase、Hive、Storm、Flink和Directory，产生过不少committer和PMC成员。

郑锴所带领的团队也发起过不少新的像Apache Gearpump和Apache Kerby这样的开源项目。他在Hadoop上开始做开源也比较早，也比较杂，最开始关注于Hadoop安全，研究如何简化和改善Kerberos部署，以及基于Kerberos支持其他更主流的认证方式，比如OAuth token。

为此一段时间内，当同事都扎堆在钻研大数据的时候，郑锴还埋头在Kerberos这门古老的认证协议中，精读了几乎所有跟这个协议有关的RFC标准，后来琢磨出一个token-preauth的方案，基于Kerberos FAST通道支持token，向MIT Kerberos委员会和IETF Kitten标准工作组专门演示过。

为了提供一个该草案的参考实现，同时也有感于Java对Kerberos协议支持的滞后，他又花了大半年业余时间用Java重新实现了Kerberos，然后将该代码贡献给Apache并同Apache Directory社区一起发起了Apache Kerby项目。Kerby目前进展顺利，已经被广泛的用于很多Hadoop项目。

在这之后，郑锴转向到分布式存储和HDFS这一领域，在Intel协调一帮人和社区一起开发HDFS erasure coding（HDFS-EC），个人主攻EC编解码器、编解码器框架和Intel ISA-L的集成。目前随着Hadoop主要是基于HDFS-EC的3.0第一个alpha发布逐步接近，这个特性也逐步稳定和可用。

郑锴表示本次主要是想从布道者的身份分享HDFS-EC，或者说是HDFS纠删码支持。关于这方面，之前在研发的过程中他所在团队和Cloudera的工程师已经作过大量的分享，本次主要是想做一次比较全面的分享介绍，重点关注国内用户可能比较关心的问题，比如性能、部署和实践。同时综合了不少社区同行的见解，来谈一下Hadoop目前发展的动向和在未来可能的走向。

郑锴表示HDFS-EC应该算是HDFS自诞生以来最重大的一个改进了，应该是打破了Hadoop创立之初的很多基本假定，适应Hadoop平台在存储、网络和部署场景上的最新发展趋势，同时也对上层计算框架带来了新的挑战和优化机会。这一特性对用户的价值是不言而喻的，可以在不牺牲数据可靠性的前提下大幅度的降低存储开销。目前国内的一些主要HDFS深度用户都对尝试部署这一特性都表示出了浓厚的兴趣，其所在团队也在持续不断的跟他们保持沟通。云栖社区和阿里云在大数据上对于国内用户有很大的影响力，很高兴有机会在此分享在对于HDFS-EC这个关键特性的支持上的经验，希望对有意向部署EC的用户有一定参考价值。

另外一方面，HDFS-EC从发起到现在，历时两年多，得到了Hadoop社区的主要玩家的大力支持，包括Intel、Cloudera、Hortonworks、Huawei和Yahoo。这在近些年来还是非常罕见的，考虑到这个市场的竞争激烈程度。郑锴还表示作为这个项目的主要发起者和参与者之一，从中学习和收获良多，从开源贡献者的角度上来讲也有很多心得可以和国内的一线开发人员分享。

Hadoop创立之初的初衷是利用普通的服务器来搭建集群以水平扩展的方式存储和处理海量数据，因为极大降低了使用门槛满足了当时业界处理海量数据的客观需求，获得了很大成功。当时作了不少基本假定，首先是可以采用的存储设备很廉价，因此简单粗暴的对数据块采用多备份的机制来保证数据的可靠性；网络带宽是瓶颈，移动计算比移动数据更高效，因此极力追求计算和存储的亲和性。Hadoop在骨子里依赖这些假定，从存储到计算体现在很多设计和实现上面，因此HDFS-EC要考虑业界发展的最新趋势，突破这些假定，在架构、设计和实现层面都面临着非常大的挑战。

在存储上，虽然存储设备本身一直在不断地降低单位价格，但同要存储的数据量不断飞涨比较起来，简单可靠的多备份机制愈加显得代价昂贵和难以承受，特别是在备份冷数据上，有的用户为此甘冒数据丢失的风险干脆单纯把备份数降为1。有没有更好的办法，不牺牲数据的可靠性又能大幅降低存储开销？郑锴谈到，EC就是这样一种技术以计算换存储，其实在工业界早已被广泛使用（RAID），在众多的分布式存储实现上也不乏实现（比如Ceph），因此无论从理论还是实践的角度来讲，引入EC并将EC作为HDFS的内置选项之一，应该只是早晚的事。

在网络带宽上，随着10Gb网络的普遍流行和更高带宽的到来，移动数据并非不可忍受，而且随着云端的发展和计算伸缩性灵活性的需求，计算和存储本身呈现分离的趋势，这就打破了计算亲和性的假定。HDFS-EC的实现考虑到这一点，没有将保持数据的块状性和计算的亲和性作为主要考虑，而是根据HDFS主要用户场景和带宽的这一发展趋势，将EC的实现和striping的引入结合起来，并首先加以实现。

郑锴谈到也想借这个机会表示对当时社区主要领导者作出这一方向决定的钦佩，特别是HDFS-EC的主要协调者Cloudera工程师张喆。郑锴谈到当时张喆跟自己提出要首先考虑stripping的方向时，郑锴和同事都很惊讶。

当然这个方案也并非十全十美，怎么保持数据的块状性并在HDFS块级别上支持EC计算，至今仍是不少用户的诉求，HDFS-EC本身也为此留下了第二阶段的尾巴。郑锴表示作为这个项目的主要开发者之一，而且贡献过多个相关开源项目，从开源贡献者的角度有不少切身感触可以分享，希望对国内有兴趣做开源贡献的同行们有所帮助。首先是开源这种模式，在大数据上已经变得非常主流，连微软都在大力投入，对用户、公司和个人而言都具有很大的价值。EC这么大的改动、难度和工作量，对于任何一家公司都是难以承受的；对贡献者而言，可以和世界范围内的优秀开发人员一起工作，相互学习和协作，成长起来也就特别快。

个人从中展现出来的技术能力和相应的成果也是社区和世界可见的，并能得到很好认可，具有很大的流通性。然后是开源的复杂性，开源同一家公司的内部项目比较起来，非技术性的因素特别多，沟通的成本特别大。原本是几个同事可以走到位子上简单聊一下就可以敲定的问题，在这儿就需要花心思把这个问题在jira上或者邮件里描述清楚，然后等待社区上其他协作者响应和同你反复讨论，简单的问题也需要一两天。这个问题对习惯了公司内部项目开发和刚开始做开源的开发者而言特别突出，因此需要一定时间的适应。

郑锴对此给出的建议是：耐心，再耐心。你不能期待马上得到回复，如果得到立即回复了那是你运气特别好，你要心存感激；千万不能抱怨和指责，开源协作其实是非常松散的，别人没有严格的责任和义务及时帮助你。这也要求贡献者具有另外一种能力，就是多任务并发，能够将复杂的任务分解，或者快速理解上手不同的任务，一段时间内同时工作在多个任务上面，并能快速切换。有的开发人员很喜欢做事情有先有后，将很多事情耦合在一起，造成前后等待，这个是一定要避免的，开发的效率要更多的考虑开源协作的整体，而不是单纯的个人。另外就是开源质量如何保证。单元测试、自动化测试和持续集成对于开源项目非常重要，因为并没有一个专门的QA团队帮大家测试，你写的每一块代码做的每一处改动，都要考虑是不是添加或修改一些测试保证被系统自动测到，有时花在写测试代码上的时间比重更大，包含测试的patch被社区review和接受的可能性也要大得多。

谈到未来的变化，郑锴认为大数据发展日新月异，Hadoop平台也在不断演进，一方面适应新的硬件条件发挥更好的性能，同时也要满足新的业务场景和需求。从存储上，Hadoop不仅仍要支持廉价设备以存储越来越多的数据，也要支持更强劲的新型存储介质比如SSD和NVM从而提供对热数据的快速访问，Intel很快就有一些3D XPoint的产品面世，容量比内存大比SSD快，还可以byte寻址。同时，存储云端化是一个非常明显的趋势，维护大数据存储系统具有很大的复杂性和代价，很多用户选择将数据放在云上，比如国外的Amazon和Azure，国内Aliyun，Hadoop乃至HDFS如何适配和支持这些云端存储？在计算上，MapReduce这一特定的编程模型早已被泛华成Spark，Hadoop如何同Spark合作共赢为用户提供更大的价值？如何支持异构，考虑FPGA甚至是GPU，也是将来需要面对的问题。

郑锴谈到在集群资源管理和调度上，YARN同样面临着Docker这一基本计算打包方式和云端化的冲击，Apache Mesos和Kubernetes在很多场景上更受欢迎。更重要的是，计算的热点已经转向到机器学习和深度学习上，一些更有效的能够适应和应对深度学习的集群组织方式或框架可能产生并变得主流，从长远来看这会对Hadoop造成更深远的影响。当然并不是说Hadoop就只能束手待毙，实际上在这些方面Hadoop都在进一步演化和发展，因为从用户的角度来看，Hadoop平台掌管着用户数据和计算资源，利用一个现有的集群跑新型的计算任务比如进行深度学习，都是何乐而不为的，前提是Hadoop也能与时俱进。具体都有哪些相关工作，郑锴表示在云栖大会上都将展开来讲。

最后郑锴为技术初学者给出了一些建议：从技术上来讲，从事开源贡献不一定是最快的成长方式，相反在一流的互联网公司进行打拼会得到更快的锻炼。但是综合来看，如果有合适的开源贡献机会，在比较热门的开源项目上比如Hadoop和Spark，从事开源贡献的益处是不言而喻的，这尤其体现在对提高语言沟通、项目管理和工程技术素养等方面。当然开源也对初学者有很大的考验，建议入门时找个人带，从基本功能和容易的地方入手，先做些小的改进哪怕是文档和注释；可能的话参与到一个比较大的项目中去，这样会有比较多的代码贡献机会，和其他开发人员相互学习一起成长。在这个过程中要不断提高对自己的要求最终向社区的牛人看齐，从获取别人帮助到能够帮助其他人。

最后，郑锴还想提醒一点，做开源贡献是很辛苦的，需要付出很大的业余时间，对国内的开发者而言尤其如此。在Intel是有专门从事开源工作的机会，但即使这样关注点和优先级也会经常调整，如何兼顾工作正常分配和个人贡献也还是需要经常面对。如果想保持对一个项目的持续贡献，花费业余时间就是必须的。