阿里高级专家应答：各种数据在一个统一计算平台上的融合，才能产生更大的价值

摘要： 阿里巴巴这种超大数据体量上才会遇到的独特挑战，让应答在技术上有了更清晰的认识，一定要夯实分布式系统的基础。“只有把基础夯实了，才能支持上层各种计算场景在大体量上的实现，让各种新的算法在‘阿里体量’上真正发挥潜力。”

《沉淀》是云栖社区展示专家风采的人物栏目。它呈现每个专家独一无二的人生经历、认识和感悟的同时，也能帮助你沉淀技术，收获对技术和人生的判断。我们的想法是：“若你想精进为一个很厉害的人，不妨细细品味这些技术牛人背后的沉淀。”如果你想了解这些云栖专家更多分享时，请点击云栖专家频道，当然我们也欢迎你往前走一步，成为我们的云栖专家（https://yq.aliyun.com/expert），与技术大牛一起“煮酒论英雄”。

---

“这个没啥好讲的，找XX和XX技术Leader吧？”

“为什么挑中我？”

“时间点再考虑下吧，要不要等……”

……

当云栖社区发出云栖专家风采展示邀请时，应答没有直接答应。进一步沟通，你会发现推脱的背后，却是一位实实在在技术大牛的低调和谦逊。

应答认为，分布式系统架构设计为了满足20%高级用户的需求，有可能要提供80%的接口（原因见完整对话）

应答是阿里巴巴技术平台事业部架构与专家咨询的高级专家。架构与专家咨询究竟是什么样的一个岗位？应答做了剖析：本质上他们也是一线的开发工程师，只不过写代码之余可能会花更多一点时间来思考——怎样让系统架构在满足当前需求的同时，同时具备一定的技术前瞻性，能够在将来的较长一段时间内保持技术领先性。

这位身处一线的“开发工程师“求学经历颇为完美。本科中科大，硕士在世界著名的常青藤大学布朗大学，而博士则在研究型学府理海大学完成。在保送到中科大的时候，这位学霸颇为霸气地选择了电子工程专业，之所以说他霸气，是因为他选择电子工程专业的原因让人多少有点吃惊——竟然是因为专业分数线最高，听起来高精尖。

求学和毕业后，应答也在世界一流会议SIGMOD等以及一流期刊Transactions on Computer Systems等处发表多篇文章和论文，Google Scholar 上则有500多个citations。他对其中的一篇文章特别印象深刻，那篇文章介绍了在通常的分布式系统的资源调度器（比如YARN 或者 Mesos）之上，怎么提供一个开发分布式应用的通用框架，让各种各样的分布式应用或者服务能尽量避免与底层分布式基础设施打交道，同时通过这种隔离，使得其在不同的分布式框架上均可以运行。探究印象深刻的背后，是应答对研究能够真正转化成生产力的成就感。

走上工作岗位后，他先是作为微软Azure机器学习平台（AzureML）服务的核心开发人员。接着，参与了微软开源大数据框架Apache REEF项目从最初的微软内部项目到Apache incubator，再到成为Apache top level project的过程。作为PMC，在谈到开发Apache REEF过程中遇到的挑战时，他说主要是在早期一些方向的选择上，因为早期每一步的方向都决定了将来很长一段时间是在向正确的方向迈进，还是在错误的道路上越走越远。

后来，他加入阿里，参与搭建了超大规模数据和参数上的分布式学习的高效平台。进入计算平台架构组后，应答又参与了阿里自研的核心计算平台MaxCompute的更新换代。“新的计算平台在更加易扩展的架构上，实现了性能的成倍提升，以及功能的丰富和计算数据生态的外扩。”一位阿里同事这么积极评价这些工作。

阿里巴巴这种超大数据体量上才会遇到的独特挑战，让应答在技术上有了更清晰的认识，一定要夯实分布式系统的基础。“只有把基础夯实了，才能支持上层各种计算场景在大体量上的实现，让各种新的算法在‘阿里体量’上真正发挥潜力。”

对于如何夯实，他无私地分享了自己的宝贵经验：底层系统的设计，一定要走在用户前面，且越往底层走，这么做的重要性就越高。这要求系统架构设计时要做到先发性和预见性，而做到这点，除了需要长期积累经验，还要主动去了解上层用户各种各样的使用模式。应答强调：“系统的开发和架构不能只局限在自己熟悉的领域，也不能只局限在单一用户场景上。”

在分布式系统架构设计上，他指出稳定是分布式系统的最基本要求。在满足稳定要求后，在分布式系统灵活和易用的两者关系上，他非常认同二八原则。什么样的二八？三点，第一用20%的接口实现80%用户的需求；第二80%的系统要为20%的接口服务；第三，为了能满足另外20%高级用户的需求，我们可能要提供80%的接口（笔者注：至于为什么，请见下面对话）。他表示，接口的“收”与“放”都是需要精心考量的。

对于分布式系统架构的未来，应答有两个思考：

• 第一个是怎样在一个统一的计算平台上，满足用户多种多样的计算需求：这包括两个方面，一个是多种的计算模式，比如离线大规模运算，流计算，图计算等；另外一个是处理多样的数据格式，比如关系式数据，文本数据，音视图数据，甚至是用户自定义特殊数据，比如基因，天气数据等。

• 第二是多种硬件的使用以及统一：怎样在一个集群上实现多种硬件的混部，来满足一个系统上的多种计算需求，这会是一个很有意义的问题。

总结过去的技术生涯，应答说：“近几年在阿里其实整体的是一个逐步在系统堆栈上往下做的过程，从一开始的偏机器学习应用，逐渐转移到分布式系统基础架构方面的工作。”他解释，这个过程也是在堆栈上层开发中，能越来越切实的感受到底层分布式系统的稳定性和灵活度的重要性，从而往下探索的一个经历。

在沟通的最后，笔者问起眼前的这位技术专家有什么格言时，他说了一个觉得挺有道理的一句话——“people will choose to believe what he wants to believe.”

“为什么觉得它有道理？”

连续追问，他说出了自己的想法：“我们不要动不动就想说服别入。从技术角度来看就是：做一个系统/产品，不要老是想着要说服别人用你的，很多时候每个人是有一个预判的，也只会做出选择符合他预判的决定。要让别人相信你，首先要解决人家的问题，一个系统解决了用户在其他地方解决不了的问题，用户才会‘想要’相信你，在这种预判下，才会更客观的来审查整个系统方方面面的优势。”

至此，笔者也明白，为什么当发起云栖专家风采展示时，应答是推却的，因为他知道行动和拿到结果是最好的专家风采展示。

好一个低调和谦逊的技术大牛！

以下是更为精彩的内容：

云栖社区：请介绍下自己以及所从事的工作（架构与专家咨询具体干什么）。

应答：虚一点来讲，架构和专家咨询组从负责上来说是计算平台整体技术走向和大的架构设计。但是实际上，我们本质上也都是一线的开发工程师，只是写代码之余可能会花更多一点时间来思考：怎样让我们系统架构在满足当前需求的同时，同时具备一定的技术前瞻性，能够在将来的较长一段时间内保持技术领先性。尤其是在预期、在数据规模不断增长和计算模式日益多样化的趋势下，怎样做到上面几点。

当然思考只停留在脑子里和PPT里是没有用的，只要架构没有实现都是空中楼阁。所有的想法最后需要转化成包括我们自己和团队每一行代码的实现，功能的设计，与团队的Code Review交互以及开发计划讨论等等……

云栖社区：你的求学经历包括中科大、美国布朗大学（Brown University）, 理海大学（Lehigh University），能否谈下这三段求学生涯里，分别有哪些让你难忘或记忆深刻的事。

 

应答：选择科大是因为从初中起就对其严谨朴素学风的向往，当时是保送到中科大电子工程系。对于选择电子工程这个专业，老实说，反而还是比较懵懂的，基本上就是觉得分数线最高，而且听起来比较高精尖。不过回头来看这个选择，那个时候对专业一知半解，也并没有产生什么不好的后果，因为更重要的是，选择学校的过程是理性的和有针对性的。我个人觉得学校选对了，具体的专业反而不是那么重要了。在科大的求学过程中，印象深刻的事情已经不好罗列了。大部分时间都在学习，上自习，感觉没有太多波澜。当时很多事情，我们都觉得是平平淡淡。反倒是临近毕业以及毕业以后，有了更多和来自其他学校的朋友交流的机会，才能体会到一些学校的不同。比如最近在微信上刷屏的关于科大机智地为贫困学生提供生活餐卡补助的事情，这个其实是在我毕业后才大规模实行的，但是作为科大毕业生，我们看起来觉得学校会这样做其实是非常自然的。在科大大家都习惯了学生第一，学习第一，也相对单纯一些，像补助学生这样的事情，都觉得是理所当然的。另外还有，比如学校是淮河以南第一个为学生提供冬季供暖的，而学生宿舍的供暖也早于教工宿舍，现在回想起来都有点身在福中不知福的味道。

到美国的第一站是布朗大学，其所在的Providence也是我到美国后居住的第一个城市。印象深刻的事情很多，很多时候是体会另外一个文化不同的地方。布朗是常青藤里一个相对小的学校，但也因为小，所以系和系之间的边界就没有那么严格清楚，很多本科生都是满学校到处选课，而研究生也能有机会接触到许多本专业以外的东西。印象比较深的是在各种研究生课程上做过的各种各样的project。比如当时选的高级信号处理课，期末的project是生物信息学中的信号处理，概括点说就是通过把怎么基因数据中ATCG碱基看待成一串时序信号，然后映射成一些时空域信号空间上的点，在这个基础上做信号的频谱分析。一个很有趣的观察就是在频谱上的突出点，对应的信息如果转换回时域，往往对应的就是基因里带有遗传信息的基因段。频谱转换和分析其实都是本科在科大都学过的内容，但是把这些信号处理的知识，具体应用到基因数据分析上，还是蛮有趣的。我觉得这段经历对于以后自己从更加开阔的方向去思考问题也很有帮助。

后来到了里海完成了博士学业。博士期间的训练和本科就有比较的的区别了。从研究方向上也有了更大的自由度。当然更大的自由也意味着更多的未知性，也要为自己的选择负责。读博士期间，有拍脑袋想到一个想法最后变成很不错的paper的经历，也有仔细研究了半年的想法，结果最后真正搭建和模拟的时候，才发现结果不尽人意。但在探索的过程中，不管是成功还是失败，其实都是很有益的经历。这不只是像鸡汤文里说的“失败能避免下一次犯错”，我觉得更重要的是有一些不成功的经历，能让人对处理各种工作学习生活的各种不确定性有更丰富的经验。

云栖社区：你在世界一流会议SIGMOD等以及一流期刊Transactions on Computer Systems等上均有发表文章，Google学术搜索里有500多个引用……在这么多文章或论文中，你对哪个最为看重，请介绍下它，以及说明下看重的原因。

应答：最看重的应该是在毕业后在工业界时，发在SIGMOD等处的文章。虽然这些文章并没有我在学校发的一些文章引用来得多，但不同的是它并不只是学术上的探讨，而是对工作中研发系统的整理和总结。

这个文章介绍了在通常的分布式系统的资源调度器（比如YARN 或者 Mesos）之上，怎么提供一个开发分布式应用的通用框架，让各种各样的分布式应用或者服务能尽量避免与底层分布式基础设施打交道，同时通过这种隔离，使得其在不同的分布式框架上均可以运行。另外在此基础上，分布式应用的实现可选的编程语言也可以与底层框架解耦。比如微软的流计算服务ASA（Azure Streaming Analytics）就是一个搭建在我们的框架之上使用.NET开发的计算服务，但是底层其实是基于Java的YARN集群。我们的中间框架使得ASA可以完全不用考虑这些区别。

基于我们的框架搭建的类似服务还有很多，我觉得这些都是真正转化成生产力的工作，所以也觉得有些成就感。

云栖社区：加入阿里之前，作为Apache REEF的PMC，你在微软大数据事业部工作，并经历了从立项到成为Apache top level project的过程，能否聊聊这段经历里都遇到哪些挑战，都是怎么解决的？

 

应答：挑战主要都在早期，怎么把一个适用于各种分布式系统的中间框架搭建起来，接口上设计怎样选择才是合理的，如何避免行差踏错。因为早期每一步的方向都决定了将来很长一段时间，是在向正确的方向迈进，还是在错误的道路上越走越远。

除了仔细调研设计以外，我们找了同样在设计开发初期的Azure Streaming Analytics（ASA） 团队，和他们一起开发，直到最后上线。当然现在回头看这个项目，还是有不少不满意的地方，今天如果重新再来做的话，我可能会做得更好。

云栖社区：加入阿里后，你搭建了超大规模数据和参数上的分布式学习的高效平台，你在开发中主要负责哪块？另外，这与你之前在微软负责开发的Azure机器学习平台服务相比有什么不同？

 

应答：加入阿里的时候，其实参数服务器的开发第一版已经有了模样了，也在集团内部的一些场景中用了起来。但是具体实现和单个业务场景和单个算法都绑定得比较紧，所以扩展新算法上会遇到一些挑战。我和团队一起基本上重新设计和实现了整套系统，让其对接口、对多种算法更加友好，同时也支持更多维度上的性能的改进；另外抽象出了SDK让平台的开发也更加开放：能让我们的用户也进来参与新算法的开发。

这个分布式机器学习平台和我在微软做过的Azure机器学习平台服务还是很不一样的。一个最显著的区别是规模。事实上Azure机器学习平台面对的是微软外部的中小企业用户，而这些用户需要处理的数据和算法模型，在规模其实都是比较有限的，这和阿里几个实际业务场景的体量完全不在一个量级上。在阿里实现的基于参数服务器的分布式机器学习平台，面对的百亿级别的特征，千亿级别的数据。这种量级的分布式学习，很多普通的中小型公司现在还没有太多机会接触到，所以针对中小公司以及针对阿里量级数据场景的分布式机器学习平台，要解决的问题可能是完全不一样的。在AzureML的工作可能更多的集中在整体框架灵活性搭建，以及很多安全，生态开发等方面。而在阿里，处理“阿里体量”的数据是第一要务，在这个基础上才有下一步在灵活性等方面的扩展，从时间点上的优先级别的不同，对于一个系统开发的计划和设计也会有不同的考虑。

云栖社区：接着，你加入计算平台架构组，参与了阿里自研的核心计算平台MaxCompute的更新换代，在这个过程中，你有没有遇到“转型”的压力？又是如何解决的？

 

应答：其实没有什么“转型”的压力。不同的分布式系统设计有很多共通的地方。当然会有一些之前没有做过的东西，但是学习新的东西对我来说应该是比较常态了。

当时有这个变化，主要是在做分布式机器学习平台的过程中，感觉一些更普遍的大数据分析功能，在当时的计算平台上还有不少可以再进一步改进的空间，而把底层系统夯实了，对上层的各种应用都会是一个有益的正反馈。

云栖社区：据说新的计算平台MaxCompute在更加易扩展的架构上，实现了性能的成倍提升，以及功能的丰富和计算数据生态的外扩，就你经验来看：一个稳定、灵活的分布式系统架构设计该如何做？应该遵守哪些原则？

 

应答：我觉得稳定是分布式系统的最基本要求，任何一个分布式系统从设计的第一天开始就应该把稳定放在第一位。

其实这里我更想聊一下一个分布式系统灵活和易用两者的关系。这个其实也不是我自己的原创，但在分布式系统的设计上，我非常认同“二八原则”。这有好几个点，第一是应该能够用20%的接口实现80%用户的需求，接口的收敛，往往能带来简单易用。这能方便大部分用户上手。现实中，大部分用户都会需要用到相对小的一部分基础功能，这也是一个系统需要花大精力把做好。这就涉及到第二点，那就是80%的系统要为20%的接口服务。这也就是说分布式系统就像一个冰山，或者像一个金字塔一样，底层大量的实现（包括对性能的优化，以及对各种失败的处理）就是为了把上层用户看得到的几个主要功能，做到各种场景上的最优。第三点，是为了能满足20%高级用户的需求，我们可能要提供80%的接口。这一点争议可能比较大，但我想说的是这一点上比较适用的是底层的系统设计，也就是说如果你设计的是一个分布式系统底层的接口，你的直接用户可能是另一个”系统“的开发者，这时候提供灵活的接口和功能是非常重要的。反而是越到上层靠近终端普通用户，接口可能越少会越好。接口的“收”与“放”都是需要精心考量的。

云栖社区：从你的这几年技术生涯来看，不论是微软Azure机器学习平台（AzureML）服务开发，还是阿里的分布式学习的高效平台、MaxCompute的更新换代，你都是在做更加深入的事情——在系统堆栈上逐步往下做，能否具体聊聊在过程中遇到的独特挑战。

​

应答：一个重要的挑战就是一个系统，不论是机器学习平台，还是底层分布式系统，怎样才能走在用户的前面。这一点越往底层走重要性就越高。因为只有系统走在用户的前面，在用户需要的时候，才能直接用得上。尤其是对于设计一个系统，不可能说用户有什么需求都是现改现做，用户很多情况下是等不起的。一个系统没准备好，导致的后果要么就是用户走路，不使用这个系统；要么就是用户会在系统有限的功能上加上各种各样的hack，对你现在不成熟的接口绑定上强依赖。而这就可能导致系统的发展被捆上了手脚，因为系统的发展是需要有延续性的，不能说我今天升级系统，用户现有的功能就被break。要避免这种情况，就要求底层系统的设计，要有一定的先发性和预见性，这个除了需要长期积累经验，还需要主动去了解上层用户各种各样的使用模式，系统的开发和架构不能只局限在自己熟悉的领域，也不能只局限在单一用户场景上。我觉得系统开发中遇到一些比较开心的事情就是我们自己设计研发的一些新功能，刚刚上线还没有对外宣传的时候，用户就提出了这样的需求。这个时候我们就可以说“功能已经有了，直接用就完全满足你的需求” 。当然了，虽然这个时候会很有满足感，但是也往往意味要开始准备补文档了。

最后从另外一个角度来看，一个好的系统，也有引导用户正确使用的责任，让用户更高效的在系统平台上实现自己的处理逻辑。

云栖社区：你认为未来分布式系统架构还会有哪些变化或趋势？

 

应答：我觉得分布式系统架构在经历了一开始从无到有，从有到百花齐放的过程，现在在大数据分析处理上，正在逐渐进入下一个阶段：也就是从百花齐放再慢慢收敛。

之前一段时间有许多新的分布式系统框架被开发出来，而每一个新的系统，都往往会针对比较特殊场景。也一定程度上造成了用户如果要支持多样需求，可能要维护多个系统的问题。现在一个值得我们每个做分布式系统的同学考虑的问题，是我们怎样在一个统一的计算平台上，满足用户多种多样的计算需求。这里的计算需求包括两方面：一方面是多种的计算模式（比如离线大规模运算，流计算，图计算等），另一方面是处理多样的数据格式（比如关系式数据，文本数据，音视图数据，甚至是用户自定义特殊数据，比如基因，天气数据等等）。这些方面的统一，除了能让用户减小维护多系统的代价，也能带来多种数据在一个系统上真正的融合，让数据产生更大的价值。

系统架构的另外一个趋势就是多种硬件的使用以及统一。很长一段时间内，分布式集群通常以CPU为主，而现在随着包括GPU, FPGA等针对特定计算需求差生的新硬件的发展，由新硬件组成的集群也有很大的需求。现在的这个阶段可能CPU集群， GPU集群以及FPGA集群还处在一个分开部署的阶段，也就是还在“百花齐放”的过程中。但是接下来，怎样在一个集群上实现多种硬件的混部，来满足一个系统上的多种计算需求，也是一个很有意义的问题。而这样子的混部环境中，在系统层面将异构硬件的区别在分布式系统层面，做好向上层应用的屏蔽，都是很有意思的挑战。在这方面我们也已经在阿里开始一些尝试。

云栖社区：如果初学者想在大数据分布式系统领域扎根，你能给一些由浅入深的学习路径或建议吗？

 

应答：分布式系统的学习，我觉得在看看基本入门的书之余，去看代码具体实现是很重要的。当然如果能自己搭建一个环境来玩一玩，会有更深入的体会。最理想的是能有实战的环境，因为很多分布式系统的问题，在大的集群规模上才会遇到，也才会有更深刻的体验。

所以我们欢迎大家来投简历加入阿里的计算平台团队，在这里能看到在上万台机器的集群规模，以及在这个大型计算平台上解决的其他地方看不到的问题。我们杭州，北京，西雅图都在招人 。

云栖社区：最后请你聊聊，生活中都喜欢做什么事情、读什么书以及什么格言？为什么？

 

应答：我应该算是比较典型的技术男。业余也就喜欢看书，打篮球（其实现在打得也少了）。

书的话比较杂，武侠、科幻、传记、社会小说都会涉及。格言这种东西我其实是不太信的，因为我觉得大部分格言都必须在一定场景上才有适用性，有点假。如果一定要说的话，那就是我觉得这么一句话挺有道理的：people will choose to believe what he wants to believe，不知道怎么翻，大家意会一下就好。（文/我是主题曲哥哥）

原文链接：http://click.aliyun.com/m/26319/