2014年1月，阿里云将其ODPS服务开放公测。2014年4月，阿里巴巴大数据竞赛的所有参赛者将在ODPS平台上进行算法的调试、测试；同月，ODPS也将开放更高级的功能进入公测。

　     下边是今日对ODPS平台的技术负责人徐常亮进行的采访，交流了有关ODPS的愿景、技术实现、实现难点等话题。

　　InfoQ：先介绍一下ODPS现在的情况吧。这个产品能做什么？

徐常亮：ODPS是2011年正式有的名称，全称叫做OpenDataProcessingService，简单来说就是数据处理的服务。它的定位是在飞天之上，提供数据仓库、数据挖掘和其他数据应用等功能。

　　2011年的时候我们尝试对外提供ODPS，当时有一些小试点，但是后来发现各方面条件没有完全成熟，不管是外部对云的了解还是内部对ODPS未来的预期都不是很清晰，所以一直到2012、2013年，它发展的节奏都比较慢。去年大概6、7月的时候有一些变化，因为飞天到了5K的里程碑，在技术能力方面的顾虑已经小了很多。因为飞天是分布式操作系统，它提供最基本的存储、CPU调度能力、内存使用、网络等功能，是最基本的资源包装整合，相当于是一台计算机，而我们是在它上面开发的应用，相当于是一个分布式的数据仓库，让用户可以在上面做基本的ETL处理、SQL查询、数据导入导出等，还有一些MATLAB、统计软件的功能。

　　除了这些基本功能之外，我们还提供了一整套数据挖掘算法Xlib（见http://102.alibaba.com/competition/addDiscovery/faq.htm的说明），让用户可以建模、做高级的数据分析。另外，我们还可能提供一些编程框架，让用户自己可以编写程序进行数据处理，比如单机上有Python、Java，我们就提供MapReduce编程框架、或者专门为了解决迭代问题的Graph编程框架（也叫做BSP，跟GooglePregel模型很类似）。我们会逐渐加入各种内容，凡是涉及数据处理的工具和编程框架我们都会想办法加进去，让开发者和用户可以对数据进行各方面的操作。

　　总而言之，ODPS就是基于飞天分布式系统提供的一套关于数据处理各方面工具和框架的服务。

　　InfoQ：对应AWS的话，相当于是RedShift和EMR吧？

徐常亮：可以这么去对应。纯粹从功能来讲，我们会提供类似EMR和RedShift的功能。但我们不仅于此，我们还有建模的库、机器学习的库，从编程框架的丰富性上面也不仅仅是MapReduce，还有迭代框架。暂时来看我们做的可能更多，当然AWS也在逐步提供更多的功能。

　　另外有一个很大的不同是，ODPS是作为一个有机的整体来提供这些服务的，不同的功能是服务的不同层面，而不是单卖的功能。比如在我同一个体系里面，我数据仓库类型的一个SQL处理好了，我紧接着一个MapReduce的作业就可以很好地关联起来，他们的物理存储数据，以及描述这些数据的元数据，都是在同一个体系里面。不像RedShift和EMR，它们是在一边处理完了之后，要把数据导出到另一套系统里面去处理，它们的元数据描述不是互相共享的，要有一个第三方来做对应，比如RedShift表结构是怎样的，EMR的结构要怎样相应的去设计。ODPS希望让对象都在一起，让要处理的对象和元数据都在一个ODPS体系里。在此之上，你要做授权也好，管理维护也好，都是同一个界面，对用户而言就是在一套系统里面做不同的处理，用户觉得我就是在一台机器里面，只不过在不同的文件夹。AWS的话，用户会感知这是两台计算机。

　　另一个区别是，ODPS希望做成服务：opendataprocessingservice，我们希望看到用户把数据往里灌，相当于是公有云的用法，总之数据都放在同一个系统里面。如果以后用户之间希望他们的数据之间发生一些作用，则能够非常容易的做到，只需做一些互相授权就可以。而AWS的RedShift和EMR对各自用户而言都相当于是私有云，它自己处理的东西只在它自己的空间里，如果要跟外部交互，可能必须要借助S3等外界方式。当然了，可能它原本的设计目标就是这样，这个也谈不上优劣，只是目标不同。

　　在我们这个体系里，因为用户的东西都在一个平台上，所以我们其实也可以像苹果那样开一个应用市场，用户把数据挖掘算法或者清理流程当做一个应用来发布，别人如果想用可以来买。当然这个可能之后有一系列的如何算钱之类的问题要处理，但平台在这儿，如果商业、产品愿意多考虑，这个事情也是水到渠成的。这个和整个阿里巴巴的愿景是相关的：阿里巴巴想成为数据分享的第一平台。这就真的要有这么大的一个地方做存储，要有那么大的计算能力，让用户有能力来处理大数据，还要保证安全。其实安全也是这次大赛我们比较紧张的地方：我们既要允许用户的代码跑上来，又要保障用户的数据安全，这是个非常大的挑战。

　　InfoQ：你们组是怎样分工的？

徐常亮：大致有三个方向：数据仓库场景，数据挖掘场景，编程框架场景。其中编程框架不仅是SDK，还会有一些重新定义，会引入一些新的框架。比如Hadoop上有Hive这样用SQL做的，还有Yahoo的Pig——完全是另外一种语言，还有现在很火的Spark，虽说是基于Scala，但数据处理那一层又是抽象了一层出来，提供了groupby、filter这些算子。我们也会提供类似的东西，或者让用户根据我们提供的基础编程能力来定义自己的框架。也可以说我们今后可能会自己再造一套分布式系统的处理语言，或者让用户来创造也有可能。

　　面向数据仓库的SQL，和数据挖掘有一个Xlab让用户能像写R或者Madlib、MATLAB一样建模，这些是基本算法的包装，都是用户可见的。还有很多模块，大家不一定看得见比如SQL的执行引擎怎么做，数据的存储怎么做。去年我们做了一个比较大的事情，我觉得跟飞天5K可以媲美：飞天5K是单集群5000台，但今天5000台当然也是不够的，你需要有多个5000台。ODPS就有一套系统能够管理多个集群，同时让用户觉得自己只是面对一个集群。这里涉及很多策略，决定你的计算到底在哪个集群上跑，数据在哪个集群的哪台机器上存放，是否在多个集群上都有存放，多个集群间数据的平衡复制怎么做等等。这个东西管的事情是比较多的，我们对外希望做到比较透明化。

　　InfoQ：你个人主要关注的方向是什么？

徐常亮：和计算相关的我都关注。比如数据仓库SQL这块，从解析到执行计划到执行引擎、存储，我都会看。这块是我直接负责。另外还有编程框架这块也是我这边会看的。这两块的同学直接汇报给我。另外，整体ODPS的架构怎么做、上面的控制集群怎么做的，我也会参与。

　　InfoQ：你们做过的这些东西当中，你觉得最值得跟我们分享的一件事是什么？

徐常亮：可能有一点是比较有难度的，就是怎么做开放。今天我们看Hadoop社区，因为它是开源的，大家对它各方面都有所了解，所以可以基于它的架构出很多新的东西。新东西都是有迹可循的，不是突然就冒出来的，Hadoop上的很多新东西都是基于单机时代的理论，比如数据库上的理论，这些东西都是有一定基础的，可能今天是有人把它们应用到了分布式环境下就成了新东西。

　　ODPS是开放数据处理服务，而开放不一定是开源，目前飞天和ODPS的代码都还没有公开的计划，即使现在公开出去你也用不了，因为要依赖很多配套设施。所以，在不开源的情况下做开放，这里面需要很好的平衡。

　　开放，意味着让用户自由、方便的使用我们的计算能力，充分挖掘数据的价值。对ODPS而言，要做到开放，让用户的想象力充分激发，取决于我们能把编程框架做得多漂亮。编程框架很重要。SQL、算法库这些可能更多面向BI的人员，他们可以拿相对现成的东西来用；开放数据处理服务在编程框架上做的事情更多是面向开发者，让他们根据我们开放的引擎、构造通过接口暴露出去，让他们能够用，又不至于把下面的运作模式都暴露出来，既要让用户有很高的定制权，又不违背我们的安全原则和我们对分布式和单机的平衡选择。

　　MapReduce就是一个很好的方式，因为有人给我们领过这条路，大家觉得这个方法比多线程处理锁的关系要容易很多，仿佛在写一个单机程序，只不过步骤不同。所以，我们提供的MapReduce可以照抄已有的东西。但是今后很多东西可能不是两个步骤就能处理完的，我们想用DAG——就是有向无环图，用比如现在的YARN或者MapReduce2.0来支持这样的理念，像Hortonworks那个Tez框架就能支持一连串的、若干个task相继的关系，只要你不要成环，能描述依赖关系为有向无环图，我们都能把它分解出来，让用户在各个阶段做什么操作，这样来定制。这个东西我们会拿出来给用户用。当然对开发者来说，DAG就比MapReduce复杂一些，但它的处理能力和自由度更高。

　　我们还在想一些能帮用户做包装的东西，比如写一个wordcount：可能用户写一个MapReduce也很简单，但如果在SQL里面写就只要一个select和groupby就完成了，一句话就覆盖了wordcount的东西。所以，我们能不能给用户再包装一些语义？我们提供一个groupby的算子，用户就可以用。SQL虽然也被称为一门编程语言，但是它毕竟不像我们一般语言的逻辑，你可以写for循环，if之类的，控制能力很强，而SQL就感觉你只能表述一下自己想干什么，后面的细节很难控制，所以开发人员会感觉受局限。提供类似于SQL的基本算子——groupby、filter这种想法，在Spark里面也有类似的体现，我们可能也会做类似的事情。我们会考虑是否有一些东西能沉的更底层一些，或者有些东西可以拔高一些，以此来做一些设计或权衡。

　　当然这个思路可能有很多，我只是提出几个点，如MapReduce、DAG、结合SQL算子来提供高层功能，让用户跟写程序一样。我觉得写一个SQL可能还不是写程序，写程序还是有变量赋值、关系等更多操作。今后我也不知道会不会有别的，但这几个地方我们会下很大的力气，希望在整个大体系下做到安全并提供关键功能，在里面能做迭代、广播等MapReduce不提供的东西，让这些都能通过编程框架放出去，外面的人就能更好的控制分布式系统所具有的能力。如果真能做到的话，我觉得就能把开放做的很好。

　　InfoQ：所以从某种程度上而言，Hadoop下面出来这么多子项目，也是因为MapReduce的局限性？

徐常亮：某些方面是这样。你看Hadoop2.0，或者说YARN调度器的出现，很大的原因就是Hadoop1.0的jobtracker只支持MapReduce和maponly这两种简单的调度模型。在YARN上你就可以做MPI或者迭代等各方面事情，Spark也可以在YARN上跑，各方面的事情都相对容易。对ODPS而言，因为基于飞天，而飞天的调度——伏羲——从第一天开始就支持YARN今天能支持的模式。从这点也可以看到飞天的发展历程，一开始很多想法还是比Hadoop好的。

　　InfoQ：如果想提供这些比较丰富的模式，也是可以直接复制现成的子项目的吧？

徐常亮：这是一个做法。比如SQL，因为有标准的定义，我们就可以很容易的复制，只要你写出这个SQL，我的解析器就能按你想的那样解析它，你也想不出别的花招来。这方面已有的理论和体系都比较成熟了。但是Spark你拿出来，虽然这套东西我觉得也很不错，但是毕竟还没有像数据库理论那么定型，或者说自成体系，它有一些缺点。

　　我们是拿来主义，它好的地方我们就拿过来。Spark基于Scala写的，对于很多同学还是比较陌生的，如果我们把它移植成Java或者Python，这两个语言的社区更大，可能会更容易做。其实Spark这个东西在今天的ODPS上也可以跑起来，但我们这上面跑起来的Spark可能执行体系是完全不一样的。这块也是开放编程框架未来的一个方向，以后比如你可以把Pig也搬上来，都是有可能的。Spark有十几二十个算子，现在已经差不多都能在我们上面跑起来了。

　　今天我们做飞天也好，ODPS也好，我们做这些自主研发的东西并不意味着我们在闭门造车，我们一定会看外面好的东西，有些东西我们会结合我们自己的场景做整合或者微创新、创新。

　　InfoQ：对于ODPS，目前业务部门来提需求的多吗？

徐常亮：有一些业务部门的需求很明确，比如业务部门可能做一些数据分析，说我想更快，或者要处理更大的数据，以前支持TB级，现在可能要PB级。有些需求很明确，这些我们就想办法去解决，而且这些在分布式系统下，数据量变大本身就是线性扩展必须解决的问题，否则分布式系统就没有意义了。而处理速度更快这方面，我们也在做一些自己的探索，比如刚才我提到我们在里面做迭代很容易，有一些数据不落地，在实时化处理上，今天我们内部的SQL跑的速度非常快了，比Hive这些都要快。今后感兴趣的话我们可以公布一些benchmark的数据。

　　另外一些方面，比如编程接口，这些用户都是开发人员，他们的品味都会不一样，所以这就是为什么我们希望把底层包装好、放出来，让开发人员可以自己定制。这样每个人都会高兴。当然今天可能就是只能有一部分人高兴，毕竟把Java、C、PHP、Python的同学放在一起肯定是会意见不同的，我们希望还是把底层的算子、我们定义的一些东西拿出来，这样以后定制能力更高。如果每个人的需求都一个一个去搞，我觉得很难实现。

　　InfoQ：你觉得实现过的最有挑战的东西是什么？
　

徐常亮：我觉得那些学术性的、理论性的东西其实都解掉了，也看得到别人已经做好的产品，这方面没什么特别的难题。一路走来，我觉得还是工程问题居多。比如分布式系统里面本来是小概率的事件变成常态，而且因为不断地交互会放大，解决这些小概率事件变成了挺难的事情，因为这些问题往往在你的防范之外，你要怎么定位、解决，是非常有挑战的事情。

　　再一方面就是早期，不管飞天还是ODPS在人员配备上，人数和工作进度的压力都很大，有一些工程、项目管理上的问题。当然这个不是技术上的挑战了。挑战都是有的，但是一定会解决。

　　最常见的小概率事件就是设备坏掉。硬盘坏掉大家听到很多，另外网卡也会坏掉。虽然理论上盘古团队会处理硬盘坏掉的问题，但早期不管是调度还是存储都是坐在一起的，所以大家一起处理，更何况我们这儿有真实的场景，有大数据量，可以发现很多问题。

　　我们之前碰到一个网卡的问题：一台机器大概有千分之一的几率网卡坏了，它坏了又不是全坏，大概是万分之五的机会会把一个数据传错，一个bit会翻转——比如1变成0。总的来说是将近亿分之一的机会出一个错误。但是因为交互的数据量大，就给撞上了。

　　这个问题怎么发现的呢，刚才提到ODPS的几个特点，其实有一点很重要但是我没说，就是正确性。我们对正确性的要求很高，因为我们的第一个正式的商业客户是小微金服，就是阿里小贷。他们的业务关系到钱，直接关系到你能否把这个钱贷出去，所以我们要对他们的坏账率负责。在这个层面上，我们对准确性要求很高，所以每一次发布之前，我们都会做全批量的验证。这个过程我们需要比对各版本的数据，确保他们都是对的。这个过程，因为我们有数据做对比，所以发现有这么一个问题。这个用户都不一定能发现，他可能某一次跑发现某个数据不能解释，但是跑下一次又ok了，这个事情可能就过去了，因为亿分之一的几率几乎肯定不会再次发生在他头上，可能就换一个人。

　　发现问题后跟飞天的同学沟通，飞天网络层的同学可能会觉得是不是你们上层逻辑写错了，造成这种随机性，我们就要想办法证明我们上层逻辑没错。后来我们专门做了一个端到端的数据校验checksum。之前我们可能就是像HDFS那样对存储的数据做一个checksum，网络传输过程中做因为会带来一些额外的开销所以以前是没有全做的，但因为发生了这件事就不得不做了。所以我们必须对自己每一次的版本发布做一个很严谨的回归，有任何错误都不能放它过去。这也是我们的一大特色。

　　InfoQ：最后谈谈你对天池算法竞赛的期待吧？

徐常亮：ODPS是今年1月24日开始商用，开始邀请一些用户进来。我们希望在这次大赛开始的时候，也就是4月底，将整个ODPS正式对外商用。到时候我觉得外面的用户也会反馈很多，借助天池大赛也是看一看我们的竞赛选手对ODPS的反馈。

　　首先，我们毕竟是做平台出身，在用户体验方面可能做的不太好。我们在平台底层投入很大，但是对交互式的使用、API可能并不是定义的很好。这方面用户如果有反馈，对我们来说是很大的帮助。商业化以后，我们要对外部的方方面面要投入更多。所以希望借着大赛做出相应的改进。

　　另外，我们这次提供给用户的东西还是比较多。1月我们只有SQL，4月我们会开放Xlib机器算法平台帮助用户建模，这个我们觉得还是很有威力的。去年我们内部做了一次大赛，类似这次的，得奖的前几名基本都用了这个超级武器，这个在今天同类产品里面基本上是没有的。我们也是希望借这次大赛把招牌打响，当然也是看看用户的反馈，让它不仅是威力很大，也要让用户的整个建模流程比较流畅。

　　另外，我们会把一些用户可自定义编程的东西放出来。当然我们也不希望一次开放太多，前期有MapReduce框架和结合SQL的udf，让用户可以自定义一些函数。这块我们也希望看一下用户的体验。这一块4月不会商用，但是会开放出来做一个测试，可能就是以大赛的用户为主。

　　最后，我们也在探索这个“数据分享第一平台”该怎么做。今天天猫把数据分享出来让大家建模，如果能达到很好的推荐效果，我们阿里巴巴也会受益很大。因为有几千支队伍，大家会有不同的想法，也许也会有新的东西。在我看来我们要做数据分享，就是要让大家能看到数据的价值。这就要看大家的想象力了。

　　徐常亮（@常亮姓徐），北京大学双学士（主修化学，转入IT行业纯属兴趣），普林斯顿大学博士（计算化学方向），曾在纽约时报网络部任职搜索组组长，开发、维护自主开发的搜索引擎，最早期的Amazonec2、s3和Hadoop用户。2009年加入阿里云，曾负责阿里云分布式平台--飞天--底层基础维护，现在主要负责ODPS平台的架构和开发，产品主要满足数据仓库、分布式编程框架、数据交互等各种场景。

　　2014年1月，阿里云将其ODPS服务开放公测。2014年4月，阿里巴巴大数据竞赛的所有参赛者将在ODPS平台上进行算法的调试、测试；同月，ODPS也将开放更高级的功能进入公测。

　     下边是今日对ODPS平台的技术负责人徐常亮进行的采访，交流了有关ODPS的愿景、技术实现、实现难点等话题。

　　InfoQ：先介绍一下ODPS现在的情况吧。这个产品能做什么？

徐常亮：ODPS是2011年正式有的名称，全称叫做OpenDataProcessingService，简单来说就是数据处理的服务。它的定位是在飞天之上，提供数据仓库、数据挖掘和其他数据应用等功能。

　　2011年的时候我们尝试对外提供ODPS，当时有一些小试点，但是后来发现各方面条件没有完全成熟，不管是外部对云的了解还是内部对ODPS未来的预期都不是很清晰，所以一直到2012、2013年，它发展的节奏都比较慢。去年大概6、7月的时候有一些变化，因为飞天到了5K的里程碑，在技术能力方面的顾虑已经小了很多。因为飞天是分布式操作系统，它提供最基本的存储、CPU调度能力、内存使用、网络等功能，是最基本的资源包装整合，相当于是一台计算机，而我们是在它上面开发的应用，相当于是一个分布式的数据仓库，让用户可以在上面做基本的ETL处理、SQL查询、数据导入导出等，还有一些MATLAB、统计软件的功能。

　　除了这些基本功能之外，我们还提供了一整套数据挖掘算法Xlib（见http://102.alibaba.com/competition/addDiscovery/faq.htm的说明），让用户可以建模、做高级的数据分析。另外，我们还可能提供一些编程框架，让用户自己可以编写程序进行数据处理，比如单机上有Python、Java，我们就提供MapReduce编程框架、或者专门为了解决迭代问题的Graph编程框架（也叫做BSP，跟GooglePregel模型很类似）。我们会逐渐加入各种内容，凡是涉及数据处理的工具和编程框架我们都会想办法加进去，让开发者和用户可以对数据进行各方面的操作。

　　总而言之，ODPS就是基于飞天分布式系统提供的一套关于数据处理各方面工具和框架的服务。

　　InfoQ：对应AWS的话，相当于是RedShift和EMR吧？

徐常亮：可以这么去对应。纯粹从功能来讲，我们会提供类似EMR和RedShift的功能。但我们不仅于此，我们还有建模的库、机器学习的库，从编程框架的丰富性上面也不仅仅是MapReduce，还有迭代框架。暂时来看我们做的可能更多，当然AWS也在逐步提供更多的功能。

　　另外有一个很大的不同是，ODPS是作为一个有机的整体来提供这些服务的，不同的功能是服务的不同层面，而不是单卖的功能。比如在我同一个体系里面，我数据仓库类型的一个SQL处理好了，我紧接着一个MapReduce的作业就可以很好地关联起来，他们的物理存储数据，以及描述这些数据的元数据，都是在同一个体系里面。不像RedShift和EMR，它们是在一边处理完了之后，要把数据导出到另一套系统里面去处理，它们的元数据描述不是互相共享的，要有一个第三方来做对应，比如RedShift表结构是怎样的，EMR的结构要怎样相应的去设计。ODPS希望让对象都在一起，让要处理的对象和元数据都在一个ODPS体系里。在此之上，你要做授权也好，管理维护也好，都是同一个界面，对用户而言就是在一套系统里面做不同的处理，用户觉得我就是在一台机器里面，只不过在不同的文件夹。AWS的话，用户会感知这是两台计算机。

　　另一个区别是，ODPS希望做成服务：opendataprocessingservice，我们希望看到用户把数据往里灌，相当于是公有云的用法，总之数据都放在同一个系统里面。如果以后用户之间希望他们的数据之间发生一些作用，则能够非常容易的做到，只需做一些互相授权就可以。而AWS的RedShift和EMR对各自用户而言都相当于是私有云，它自己处理的东西只在它自己的空间里，如果要跟外部交互，可能必须要借助S3等外界方式。当然了，可能它原本的设计目标就是这样，这个也谈不上优劣，只是目标不同。

　　在我们这个体系里，因为用户的东西都在一个平台上，所以我们其实也可以像苹果那样开一个应用市场，用户把数据挖掘算法或者清理流程当做一个应用来发布，别人如果想用可以来买。当然这个可能之后有一系列的如何算钱之类的问题要处理，但平台在这儿，如果商业、产品愿意多考虑，这个事情也是水到渠成的。这个和整个阿里巴巴的愿景是相关的：阿里巴巴想成为数据分享的第一平台。这就真的要有这么大的一个地方做存储，要有那么大的计算能力，让用户有能力来处理大数据，还要保证安全。其实安全也是这次大赛我们比较紧张的地方：我们既要允许用户的代码跑上来，又要保障用户的数据安全，这是个非常大的挑战。

　　InfoQ：你们组是怎样分工的？

徐常亮：大致有三个方向：数据仓库场景，数据挖掘场景，编程框架场景。其中编程框架不仅是SDK，还会有一些重新定义，会引入一些新的框架。比如Hadoop上有Hive这样用SQL做的，还有Yahoo的Pig——完全是另外一种语言，还有现在很火的Spark，虽说是基于Scala，但数据处理那一层又是抽象了一层出来，提供了groupby、filter这些算子。我们也会提供类似的东西，或者让用户根据我们提供的基础编程能力来定义自己的框架。也可以说我们今后可能会自己再造一套分布式系统的处理语言，或者让用户来创造也有可能。

　　面向数据仓库的SQL，和数据挖掘有一个Xlab让用户能像写R或者Madlib、MATLAB一样建模，这些是基本算法的包装，都是用户可见的。还有很多模块，大家不一定看得见比如SQL的执行引擎怎么做，数据的存储怎么做。去年我们做了一个比较大的事情，我觉得跟飞天5K可以媲美：飞天5K是单集群5000台，但今天5000台当然也是不够的，你需要有多个5000台。ODPS就有一套系统能够管理多个集群，同时让用户觉得自己只是面对一个集群。这里涉及很多策略，决定你的计算到底在哪个集群上跑，数据在哪个集群的哪台机器上存放，是否在多个集群上都有存放，多个集群间数据的平衡复制怎么做等等。这个东西管的事情是比较多的，我们对外希望做到比较透明化。

　　InfoQ：你个人主要关注的方向是什么？

徐常亮：和计算相关的我都关注。比如数据仓库SQL这块，从解析到执行计划到执行引擎、存储，我都会看。这块是我直接负责。另外还有编程框架这块也是我这边会看的。这两块的同学直接汇报给我。另外，整体ODPS的架构怎么做、上面的控制集群怎么做的，我也会参与。

　　InfoQ：你们做过的这些东西当中，你觉得最值得跟我们分享的一件事是什么？

徐常亮：可能有一点是比较有难度的，就是怎么做开放。今天我们看Hadoop社区，因为它是开源的，大家对它各方面都有所了解，所以可以基于它的架构出很多新的东西。新东西都是有迹可循的，不是突然就冒出来的，Hadoop上的很多新东西都是基于单机时代的理论，比如数据库上的理论，这些东西都是有一定基础的，可能今天是有人把它们应用到了分布式环境下就成了新东西。

　　ODPS是开放数据处理服务，而开放不一定是开源，目前飞天和ODPS的代码都还没有公开的计划，即使现在公开出去你也用不了，因为要依赖很多配套设施。所以，在不开源的情况下做开放，这里面需要很好的平衡。

　　开放，意味着让用户自由、方便的使用我们的计算能力，充分挖掘数据的价值。对ODPS而言，要做到开放，让用户的想象力充分激发，取决于我们能把编程框架做得多漂亮。编程框架很重要。SQL、算法库这些可能更多面向BI的人员，他们可以拿相对现成的东西来用；开放数据处理服务在编程框架上做的事情更多是面向开发者，让他们根据我们开放的引擎、构造通过接口暴露出去，让他们能够用，又不至于把下面的运作模式都暴露出来，既要让用户有很高的定制权，又不违背我们的安全原则和我们对分布式和单机的平衡选择。

　　MapReduce就是一个很好的方式，因为有人给我们领过这条路，大家觉得这个方法比多线程处理锁的关系要容易很多，仿佛在写一个单机程序，只不过步骤不同。所以，我们提供的MapReduce可以照抄已有的东西。但是今后很多东西可能不是两个步骤就能处理完的，我们想用DAG——就是有向无环图，用比如现在的YARN或者MapReduce2.0来支持这样的理念，像Hortonworks那个Tez框架就能支持一连串的、若干个task相继的关系，只要你不要成环，能描述依赖关系为有向无环图，我们都能把它分解出来，让用户在各个阶段做什么操作，这样来定制。这个东西我们会拿出来给用户用。当然对开发者来说，DAG就比MapReduce复杂一些，但它的处理能力和自由度更高。

　　我们还在想一些能帮用户做包装的东西，比如写一个wordcount：可能用户写一个MapReduce也很简单，但如果在SQL里面写就只要一个select和groupby就完成了，一句话就覆盖了wordcount的东西。所以，我们能不能给用户再包装一些语义？我们提供一个groupby的算子，用户就可以用。SQL虽然也被称为一门编程语言，但是它毕竟不像我们一般语言的逻辑，你可以写for循环，if之类的，控制能力很强，而SQL就感觉你只能表述一下自己想干什么，后面的细节很难控制，所以开发人员会感觉受局限。提供类似于SQL的基本算子——groupby、filter这种想法，在Spark里面也有类似的体现，我们可能也会做类似的事情。我们会考虑是否有一些东西能沉的更底层一些，或者有些东西可以拔高一些，以此来做一些设计或权衡。

　　当然这个思路可能有很多，我只是提出几个点，如MapReduce、DAG、结合SQL算子来提供高层功能，让用户跟写程序一样。我觉得写一个SQL可能还不是写程序，写程序还是有变量赋值、关系等更多操作。今后我也不知道会不会有别的，但这几个地方我们会下很大的力气，希望在整个大体系下做到安全并提供关键功能，在里面能做迭代、广播等MapReduce不提供的东西，让这些都能通过编程框架放出去，外面的人就能更好的控制分布式系统所具有的能力。如果真能做到的话，我觉得就能把开放做的很好。

　　InfoQ：所以从某种程度上而言，Hadoop下面出来这么多子项目，也是因为MapReduce的局限性？

徐常亮：某些方面是这样。你看Hadoop2.0，或者说YARN调度器的出现，很大的原因就是Hadoop1.0的jobtracker只支持MapReduce和maponly这两种简单的调度模型。在YARN上你就可以做MPI或者迭代等各方面事情，Spark也可以在YARN上跑，各方面的事情都相对容易。对ODPS而言，因为基于飞天，而飞天的调度——伏羲——从第一天开始就支持YARN今天能支持的模式。从这点也可以看到飞天的发展历程，一开始很多想法还是比Hadoop好的。

　　InfoQ：如果想提供这些比较丰富的模式，也是可以直接复制现成的子项目的吧？

徐常亮：这是一个做法。比如SQL，因为有标准的定义，我们就可以很容易的复制，只要你写出这个SQL，我的解析器就能按你想的那样解析它，你也想不出别的花招来。这方面已有的理论和体系都比较成熟了。但是Spark你拿出来，虽然这套东西我觉得也很不错，但是毕竟还没有像数据库理论那么定型，或者说自成体系，它有一些缺点。

　　我们是拿来主义，它好的地方我们就拿过来。Spark基于Scala写的，对于很多同学还是比较陌生的，如果我们把它移植成Java或者Python，这两个语言的社区更大，可能会更容易做。其实Spark这个东西在今天的ODPS上也可以跑起来，但我们这上面跑起来的Spark可能执行体系是完全不一样的。这块也是开放编程框架未来的一个方向，以后比如你可以把Pig也搬上来，都是有可能的。Spark有十几二十个算子，现在已经差不多都能在我们上面跑起来了。

　　今天我们做飞天也好，ODPS也好，我们做这些自主研发的东西并不意味着我们在闭门造车，我们一定会看外面好的东西，有些东西我们会结合我们自己的场景做整合或者微创新、创新。

　　InfoQ：对于ODPS，目前业务部门来提需求的多吗？

徐常亮：有一些业务部门的需求很明确，比如业务部门可能做一些数据分析，说我想更快，或者要处理更大的数据，以前支持TB级，现在可能要PB级。有些需求很明确，这些我们就想办法去解决，而且这些在分布式系统下，数据量变大本身就是线性扩展必须解决的问题，否则分布式系统就没有意义了。而处理速度更快这方面，我们也在做一些自己的探索，比如刚才我提到我们在里面做迭代很容易，有一些数据不落地，在实时化处理上，今天我们内部的SQL跑的速度非常快了，比Hive这些都要快。今后感兴趣的话我们可以公布一些benchmark的数据。

　　另外一些方面，比如编程接口，这些用户都是开发人员，他们的品味都会不一样，所以这就是为什么我们希望把底层包装好、放出来，让开发人员可以自己定制。这样每个人都会高兴。当然今天可能就是只能有一部分人高兴，毕竟把Java、C、PHP、Python的同学放在一起肯定是会意见不同的，我们希望还是把底层的算子、我们定义的一些东西拿出来，这样以后定制能力更高。如果每个人的需求都一个一个去搞，我觉得很难实现。

　　InfoQ：你觉得实现过的最有挑战的东西是什么？
　

徐常亮：我觉得那些学术性的、理论性的东西其实都解掉了，也看得到别人已经做好的产品，这方面没什么特别的难题。一路走来，我觉得还是工程问题居多。比如分布式系统里面本来是小概率的事件变成常态，而且因为不断地交互会放大，解决这些小概率事件变成了挺难的事情，因为这些问题往往在你的防范之外，你要怎么定位、解决，是非常有挑战的事情。

　　再一方面就是早期，不管飞天还是ODPS在人员配备上，人数和工作进度的压力都很大，有一些工程、项目管理上的问题。当然这个不是技术上的挑战了。挑战都是有的，但是一定会解决。

　　最常见的小概率事件就是设备坏掉。硬盘坏掉大家听到很多，另外网卡也会坏掉。虽然理论上盘古团队会处理硬盘坏掉的问题，但早期不管是调度还是存储都是坐在一起的，所以大家一起处理，更何况我们这儿有真实的场景，有大数据量，可以发现很多问题。

　　我们之前碰到一个网卡的问题：一台机器大概有千分之一的几率网卡坏了，它坏了又不是全坏，大概是万分之五的机会会把一个数据传错，一个bit会翻转——比如1变成0。总的来说是将近亿分之一的机会出一个错误。但是因为交互的数据量大，就给撞上了。

　　这个问题怎么发现的呢，刚才提到ODPS的几个特点，其实有一点很重要但是我没说，就是正确性。我们对正确性的要求很高，因为我们的第一个正式的商业客户是小微金服，就是阿里小贷。他们的业务关系到钱，直接关系到你能否把这个钱贷出去，所以我们要对他们的坏账率负责。在这个层面上，我们对准确性要求很高，所以每一次发布之前，我们都会做全批量的验证。这个过程我们需要比对各版本的数据，确保他们都是对的。这个过程，因为我们有数据做对比，所以发现有这么一个问题。这个用户都不一定能发现，他可能某一次跑发现某个数据不能解释，但是跑下一次又ok了，这个事情可能就过去了，因为亿分之一的几率几乎肯定不会再次发生在他头上，可能就换一个人。

　　发现问题后跟飞天的同学沟通，飞天网络层的同学可能会觉得是不是你们上层逻辑写错了，造成这种随机性，我们就要想办法证明我们上层逻辑没错。后来我们专门做了一个端到端的数据校验checksum。之前我们可能就是像HDFS那样对存储的数据做一个checksum，网络传输过程中做因为会带来一些额外的开销所以以前是没有全做的，但因为发生了这件事就不得不做了。所以我们必须对自己每一次的版本发布做一个很严谨的回归，有任何错误都不能放它过去。这也是我们的一大特色。

　　InfoQ：最后谈谈你对天池算法竞赛的期待吧？

徐常亮：ODPS是今年1月24日开始商用，开始邀请一些用户进来。我们希望在这次大赛开始的时候，也就是4月底，将整个ODPS正式对外商用。到时候我觉得外面的用户也会反馈很多，借助天池大赛也是看一看我们的竞赛选手对ODPS的反馈。

　　首先，我们毕竟是做平台出身，在用户体验方面可能做的不太好。我们在平台底层投入很大，但是对交互式的使用、API可能并不是定义的很好。这方面用户如果有反馈，对我们来说是很大的帮助。商业化以后，我们要对外部的方方面面要投入更多。所以希望借着大赛做出相应的改进。

　　另外，我们这次提供给用户的东西还是比较多。1月我们只有SQL，4月我们会开放Xlib机器算法平台帮助用户建模，这个我们觉得还是很有威力的。去年我们内部做了一次大赛，类似这次的，得奖的前几名基本都用了这个超级武器，这个在今天同类产品里面基本上是没有的。我们也是希望借这次大赛把招牌打响，当然也是看看用户的反馈，让它不仅是威力很大，也要让用户的整个建模流程比较流畅。

　　另外，我们会把一些用户可自定义编程的东西放出来。当然我们也不希望一次开放太多，前期有MapReduce框架和结合SQL的udf，让用户可以自定义一些函数。这块我们也希望看一下用户的体验。这一块4月不会商用，但是会开放出来做一个测试，可能就是以大赛的用户为主。

　　最后，我们也在探索这个“数据分享第一平台”该怎么做。今天天猫把数据分享出来让大家建模，如果能达到很好的推荐效果，我们阿里巴巴也会受益很大。因为有几千支队伍，大家会有不同的想法，也许也会有新的东西。在我看来我们要做数据分享，就是要让大家能看到数据的价值。这就要看大家的想象力了。

　　徐常亮（@常亮姓徐），北京大学双学士（主修化学，转入IT行业纯属兴趣），普林斯顿大学博士（计算化学方向），曾在纽约时报网络部任职搜索组组长，开发、维护自主开发的搜索引擎，最早期的Amazonec2、s3和Hadoop用户。2009年加入阿里云，曾负责阿里云分布式平台--飞天--底层基础维护，现在主要负责ODPS平台的架构和开发，产品主要满足数据仓库、分布式编程框架、数据交互等各种场景。