汤子楠：飞天、ODPS经历了许多血淋淋教训

阿里云飞天系统之上，提供了离线的结构化数据存储和计算服务平台ODPS，半结构化数据的实时随机读写服务OTS（Open Table Service），实时流数据处理服务OSPS等等。通过这些服务，阿里巴巴内部或第三方都可以通过阿里云享受这些资源。InfoQ采访了阿里云事业部高级专家，云产品产品经理汤子楠，他介绍了阿里云飞天、ODPS的演进过程，以及ODPS、天池未来的发展和价值，以下为采访全文：

InfoQ：汤子楠你好，介绍一下自己吧。

汤子楠：大家好，我叫汤子楠，我是阿里云的一名产品经理。简单的介绍一下自己，我毕业后先在微软中国做了一段时间，做Program Manager，国内翻译成产品经理或项目经理，当时主要做前端产品。在2010年前后，我希望积累在后端的产品经验，当时正好阿里云刚刚成立，我蛮认可阿里云的这种公有云服务的模式，希望探索云计算未来的发展道路，就加入了阿里云。首先做飞天底层的产品经理，后来阿里巴巴成立大数据事业部后，我加入其中做了很多跟大数据相关的东西。最近回到阿里云开始负责云产品，像负载均衡，内容分发网络等产品。

InfoQ：阿里云在做ODPS这样一个开放数据平台，给第三方用户提供计算和数据服务，这个平台和飞天之间的关系是什么？我的理解是飞天更多是在基础架构层面做支持，ODPS在上层对用户的数据和计算提供服务的接口，是这样的吗？ 

汤子楠：你的理解非常对，实际上ODPS和飞天都是阿里云飞天团队研发的。飞天是一个类似操作系统的基础平台，它主要负责，在集群上将最基础的数据存储和计算的模型通过C++的接口对外暴露出来，让上层的应用基于飞天做更多的事情。阿里云在飞天上开发了很多产品，比如ODPS，它是一个离线的结构化数据存储和计算服务，主要是做海量的结构化数据的分析和挖掘。常见的使用场景，包括云端的数仓，云端的BI分析、日志分析等。除了ODPS，阿里云有其他基于飞天的产品，OTS（Open Table Service）是半结构化数据的实时随机读写服务；OSPS是实时流数据处理服务。总的来说，可以把飞天理解成操作系统，上面的ODPS、OTS就像操作系统上的各个应用，这些应用分别满足阿里云的客户对于不同的使用场景的需求。 

InfoQ：你刚才提到飞天用C++来写的。Hadoop这套生态系统，更多是用Java实现的，为什么飞天选择C++？ 

汤子楠：我们可以讨论很多C++和Java之间的区别，这两个编程语言都有很多拥趸。可能很多人觉得，C++对于系统资源的控制更精准，Java的编程模型可能更好实现。但在我看来，最直接的一个理由就是当年做飞天的创始人是一群C++的Programer，很自然的选择了自己最擅长的语言来写程序。 

InfoQ：我们知道互联网、云计算这几年的发展速度是非常快的，飞天、ODPS这样的产品，在整个开发迭代过程当中有没有遇到比较大的门槛，有没有重新推倒重做的状况？ 

汤子楠：这种情况在飞天和ODPS研发过程中是都有。阿里云刚刚成立时就在研发飞天，到现在四年多了，在这四年多走了很多弯路。我可以举几个小例子，实际都是蛮有意思的经历，现在回想起来很好玩儿，但当时真的是血淋淋的教训。

比如，当时飞天在做底层服务的时候，就已经考虑到未来上层肯定会出现很多像ODPS、OTS这样的应用，在底层基础存储层方面做一些附加的模块。对于结构化数据的存储，也已经在核心系统层考虑这个问题了。当时的想法是希望能够用一种存储格式同时解决在线和离线两种场景，那我们知道实际上在线的优化方向主要是低延迟，离线更多是高吞吐，数据量要大，所以说这两者的优化方向很难统一起来。但当时飞天的工程师花了大量的精力去研究，怎么样能够把这两者统一起来，这应该是研究性的命题了，设想了很多场景，怎样通过算法或统一架构的手段让两者的代码复用更高效，但是从工程的角度来讲，这件事情做的太早了。在产品发展的初期，可能更多应该考虑实际的用户需求，同时还需要考虑团队当时具有的工程能力。大概做了三、四个月，很快做了决定，把这个团队一拆为二，一部分人做离线，一部分人做在线。到今天为止，这两个团队已经是完全两个方向。现在又开始有一种思路，把两个团队合起来，原因是许多时候离线的场景需要去读在线的数据，同时还有很多产品在线的数据，希望能够沉淀到离线，做离线分析，所以说他们会有些交叉。但现在再来做这种统一，跟最早想做的统一完全不是一种心态了，现在这种统一更加实际，这是一个例子。

另外，飞天的很多核心模块，比如它的存储模块叫盘古，计算模块叫伏羲，网络通信模块叫夸父，可能多的已经经过了三版左右的重构。在刚刚开始设计的时候，我们没有想到分布式的发展速度这么快，机群的规模增长这么多。记得我2010年加入阿里巴巴的时候，当时集群最大能力可以跑30台机器，无论存储、计算都运行的很好。但设计者并没有考虑到，如果30台变成3000台或30000台会发生什么，大概去年我们突破了单集群5000台的限制，相比之前有一百倍提升。当到了5000台的规模，就发现很多之前的设计这些假设已经完全不工作，被迫将一些核心技术模块重写。可能今天在单集群5000台规模运行的很好，谁也说不准明年到了20000台的时候，是不是还OK。所以我觉得核心系统一定不断的在迭代，不断在重写。现在很多飞天的创始人已经离开阿里云了，今天飞天的代码可能跟他们之前写的代码相比已经面目全非了，这应该是大规模分布式系统演变的必然趋势，不断重构，不断的代码重写，来适应更多的应用场景和更大规模的挑战。

InfoQ：阿里云提供很多不同类型的服务，包括服务于内部的业务和公有的服务，那如何做好系统平台和应用模块的测试，新业务不影响老业务，同时让新业务快速的上线？

汤子楠：分布式测试有个很大的挑战，你很难去模拟真实的情况。比如我们在单集群5000台上线的时候，要做压力测试，看一看当这个集群的资源利用率很高的时候，系统是不是工作正常，但这势必涉及到能够在把5000台机器跑满的测试场景。这样的场景很难设计且不谈，测试团队也很难有机会奢侈的找到5000台机器去真实的跑测试。所以要解决这个问题，大概是两条路：

首先，在小一到两个数量级的集群模拟更大的集群规模行为，是不是可以在500台机器上模拟5000台机器的行为。

第二，要求测试工程非常快速。比如，我们在5000台规模的集群交付的时候，让集群不歇，人歇。机器到位的时候，负责运维和采购同事，先给了测试的同事三周时间，他们可以在集群上把测试跑完。三周以后，集群正式上线。在这三周内，测试的同事要把所有要做的测试以及上线所做的验收全部做完。在这个过程中，如果发生了问题，开发团队要去解决，当时的团队采取三班倒的方式，有些人白天跑完了测试，就可以脱离集群做分析，然后晚上回去休息。另一波晚上上班，把集群晚上的时间利用起来，尽可能最大化集群的使用率来保证开发和测试团队复用。

另外，现在我们也在做一些探索，如何在5000台的分布式集群上，在线上跑一些测试，让测试任务跟生产任务同时跑在一个集群上，并且通过各种各样的技术来保证测试的任务不会影响到生产，在去年的几次发布中做了尝试，效果蛮好。我觉得这种方式未来可能也是一个思路，当找不到这么大规模的测试集群的时候，干脆就在现场跑一跑。

InfoQ：我记得以前你曾经分享过ODPS上的准时计算，你怎么看像Spark这样的内存计算框架。大家现在谈Spark，谈内存计算谈比较多，认为它是一个未来的一个方向，你怎么看？ 

汤子楠：我同意Spark是一个未来的方向，Hadoop这个技术发展非常迅速，现在的应用场景也非常多，这两年的Hadoop China Summit大会上看到越来越多的企业，甚至包括一些传统行业都开始尝试在使用Hadoop。这也说明，Map Reduce的这种离线的数据处理技术受欢迎的程度。但是，无论是软件技术，还是硬件技术，包括我们的业务场景都在往前走，在这个过程中发现Hadoop有一些不足，以及可改进的地方：

第一，硬件成本大幅下降，我记得10年的时候，我们的机器的主流内存配置大概是24G，现在大概涨到了128G，翻了5倍。有更低廉的内存可以使用的时候，是不是很多计算可以把它从硬盘把它迁移到内存当中去，因而获取到性能的收益是非常客观的。

第二，从业务场景来讲，很多的业务场景已经不接受Hadoop这种分钟级或小时级的离线统计，他希望能够实时或准实时的看到统计结果。我举几个简单的例子，比如淘宝的数仓每天担负着对淘宝交易记录做离线统计的职责，统计出来的BI报表，第二天会供高管或运营人员来做运营决策。但像双十一当天，一整天运营的同学都在密集的工作，他们需要实时的了解交易情况，包括在各个类目的分布。大家都有印象，双十一当天天猫的微博上会放出照片，一个很大的屏幕上面数字不断的往上涨，这就是纯粹的内存计算。所有前端数据来了之后，在内存中做汇总后直接输出结果，这种计算相比Map Reduce延迟大大缩短了，类似这样的业务场景会越来越多。这就逼迫我们去思考，怎样缩短数据采集、数据运行的时间，Spark从出现到今天发展速度非常快，在阿里巴巴集团内部也开始有团队去探索Spark可以怎么用，如何基于内存做计算，或者把内存当成文件存储架构，ODPS这个准时计算已经有一点点这样的味道，但基本上没有完全脱离Hadoop架构。

我们现在有一个团队专门在做内存计算平台的调研，希望未来完全脱离Hadoop架构，单独设计一套纯粹基于内存和网络的计算模式，这样的话，可能把这个海量数据分析的时间下降一到两个数量级。

InfoQ：阿里会自己来做一套，还是直接用Spark？ 

汤子楠：我们自己在做，同时我知道内部也有团队在Spark上做技术调研和探索，因为自己研发的时间非常漫长，有时很多的业务团队在技术选型的时候，会考虑业务要求的时间点，内部有合适的技术用当然更好，如果没有，开源如果能满足要求，也是OK的。今天在阿里巴巴集团内部有ODPS这样的自己开发的离线处理的平台，同时也有一个很大的Hadoop集群支持了各种各样的集团离线处理业务。在一段时间里面可能是百花齐放的状态。 

InfoQ：我们知道阿里现在有一个天池的项目，就是一个开放数据的接口，第三方可以通过这个接口访问阿里内部的一些数据，做一些算法或者推荐系统。从国外来看，像Twitter、Netflix都有类似的针对第三方的接口。现在问题是，把数据开放给第三方，数据的审计怎么来做？对于一个普通用户来讲，我关心在淘宝、支付宝上的数据是不是会被拿去他用，就是用户隐私的问题。第二，从生态系统上来讲，如何吸引第三方把他的数据上传到这个平台上去，让天池的数据量更大，阿里巴巴也能够获益。

汤子楠：天池项目是技术发展部启动的一个创新项目，最早的想法实际蛮简单，希望集团内部的数据有更多的人来去挖掘价值，可以应用于商业、科研很多方面，在科研、经济学、心理学、数据挖掘领域可以有一些样本数据做一些测试。因此，最开始设计天池的时候，希望面向高校做数据方面的合作，实际上天池基于ODPS搭建，即底层是ODPS的计算平台， ODPS上提供存储计算能力，并开放API和客户端工具。在建设天池过程中有一个插曲，天猫想在内部搞一次算法比赛，起源是因为天猫对于线上的一些数据预测算法不是特别满意，所以想看看有没有可以优化的空间。后来他们找到天池团队，在天池平台上做了这个比赛。天猫算法大赛动员了大概阿里巴巴内部几百名算法工程师，组了一百多个队PK。他们拿到的是天猫内部的真实数据，预测的是线上真实场景，比赛持续了大概两个月，最后的结果蛮鼓舞人心的。我们发现，排名前几名算法的效果，可能比天猫线上算法的效果还要更好。我们看到，当我们把数据开放出去，吸引那些懂数据，并乐意分析数据的人去对数据加工，就可以创造出很大很大的价值。因此，我们希望把这种模式推广出去，现在天池平台就是在做两件事情：

一方面，他们跟全国各地的高校合作，通过科研手段把阿里的数据利用起来。如果哪一天能够有中国的科学家通过分析阿里巴巴的数据得一次诺贝尔经济学奖，那算是阿里巴巴为中国社会做出很大的贡献，我们相信以阿里巴巴数据的含金量，这是完全可能的一件事，因为他解释了很多在社会行为和商业购买上的规律。

另一方面，由于天猫算法大赛非常成功，技术发展部希望面向全国所有高校来搞一次大数据的竞赛，现在已经进入到了预热的阶段，在4月到7月会正式开始。

回到刚才你谈到的，数据开放面临两个非常大的挑战，第一个是数据的隐私和安全问题，这是全世界所有做数据生意的公司都躲不过的一道砍。国外很多做大数据的公司都非常重视这件事，包括Google，Facebook。在国内，随着各个公司社会责任感的提高，以及消费者的隐私意识慢慢觉醒，国内的公司也开始慢慢的在重视这件事情。对于我们而言，数据隐私和安全通过以下两个方面保证：

第一，技术层面。我们要最大化的保证用户数据在平台上是安全的，所有的数据存储是加密的，数据流通过程中是加密的，数据不能够越权访问，数据是不能丢失的，不能够泄露，不能篡改，也不能越权访问。所有的这些都可以通过技术手段解决，这是一个很难的问题，如何在大数据的场景下解决安全问题，但这是可解的。ODPS在这方面也做了相当多的探索，目前ODPS上已经在跑支付宝的业务，支付宝是按照银行的数据保密标准要求底层技术架构，这说明ODPS的安全水平已经达到了一个高度。

第二，数据流转的商业模式，怎样保证数据既能够发挥它的价值，又不至于泄露，又不至于让用户觉得自己的隐私受到危害，这是相当难的问题。这也就是为什么在2012年年底，阿里巴巴成立了大数据部门。但我们在探索数据交换业务是非常谨慎的，没有像Twitter、Netflix做的直接，他们通过签属授权协议后就把数据开放出去，让第三方公司在上面直接做分析和挖掘。我们希望找到一条合适的道路，跟第三方数据公司和第三方数据分析公司一起把数据利用起来，可能这个模式比较困难，我相信未来可能有更好的有商业价值的模式。

至于怎样让其他人把数据搬到阿里巴巴的平台上来，这也是蛮有意思的一件事，阿里巴巴在谈大数据的时候，经常把自己定义为数据交换平台，我们更希望的不是把我们的数据分散出去来挣钱，而是希望把我们的数据拿给需要数据的人去使用，并且把有数据的人也吸引到这个平台上，让数据变成一件流通的产品，方便更多的人。今天在做这件事情的时候，一方面我们跟懂数据分析的人去谈，让他们基于阿里巴巴的平台上构建更丰富的数据分析应用，提供更多的数据使用场景，这样可以吸引有数据的人来。另一方面，我们也在设计一些新的业务模式，让第三方公司在满足安全的前提下，让他的数据在阿里巴巴的平台上发挥价值。

这里举一个例子，大概在去年，阿里巴巴的广告部门做了一个叫做DMP的新业务，这个业务在美国已经有很多的公司在探索，比如像BlueKai这样的公司，在国内还处在刚起步的阶段。DMP主要的使用场景是这样的，今天的互联网广告大部分都是数据驱动，每当来一个客户的时候，通过实时竞价的模式把用户的属性告诉广告主，估计用户的年龄，性别，来自什么地方，有什么喜好，广告主决定是否把广告投给这个客户，这种时时竞价的广告模式的根本是基于用户属性的大量原始数据，很多人没有这些数据，但是他在做广告的生意，也有很多人有数据，但并不擅长做广告，DMP构建平台，让那些有数据但不会做广告的人，把数据拿给想做广告的人使用，当数据的流转产生了价值后，广告主会对结果付钱，由数据的所有者和广告方共同分享数据的价值。

我们正在跟国内的第三方数据持有者谈合作，现在已经应用到淘宝直通车广告平台里，这是商业模式上的探索，通过这种模式可以让更多的人愿意把他的数据搬到这个平台上面来。