阿里云 ODPS 的愿景、技术实现与难点

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

InfoQ 中文站近日跟 ODPS 平台的技术负责人徐常亮进行了采访，交流了有关 ODPS 的愿景、技术实现、实现难点等话题。

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

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

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，跟 Google Pregel 模型很类似）。我们会逐渐加入各种内容，凡是涉及数据处理的工具和编程框架我们都会想办法加进去，让开发者和用户可以对数据进行各方面的操作。

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

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

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

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

另一个区别是，ODPS 希望做成服务：open data processing service，我们希望看到用户把数据往里灌，相当于是公有云的用法，总之数据都放在同一个系统里面。如果以后用户之间希望他们的数据之间发生一些作用，则能够非常容易的做到，只需做一些互相授权就可以。而 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 或者 MapReduce 2.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 的局限性？

徐常亮：某些方面是这样。你看 Hadoop 2.0，或者说 YARN 调度器的出现，很大的原因就是 Hadoop 1.0 的 job tracker 只支持 MapReduce 和 map only 这两种简单的调度模型。在 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 行业纯属兴趣），普林斯顿大学博士（计算化学方向），曾在纽约时报网络部任职搜索组组长，开发、维护自主开发 的搜索引擎，最早期的 Amazon ec2、s3 和 Hadoop 用户。2009 年加入阿里云，曾负责阿里云分布式平台–飞天–底层基础维护，现在主要负责 ODPS 平台的架构和开发，产品主要满足数据仓库、分布式编程框架、数据交互等各种场景。