阿里云数据库产品总监何云飞：云服务是影响未来10～20年的事
在今年的社群大会上，笔者采访了阿里云数据库产品总监何云飞（花名何导）先生。何导在采访中表示，DBA最重要的是根据企业的业务发展需求，为未来3～5年选择一个合适的数据库；而不是根据自己的技术可控性来选择。在何导的未来蓝图里，将会构建这样一个技术平台，把BDA变成一个开放市场，让广大的DBA可以随时为中小企业提供服务。尽管现在大部分DBA并没有时间去做这些。何导坚信，在未来某一天，这个构想会变成现实。何导认为：
- 现在DBA应该去思考，不是说把数据库管理好就完了。不管是云也好、数据库也好，只是一个工具。应该去思考企业的数据是怎么发展的？企业的数据是否安全，企业的数据是不是要提前去扩展一下？应该思考怎么把数据管好，要从DBA转向DA。
- 一旦用户把数据放到云上来以后，必然会碰到各种各样的问题。而这些问题需要有人来解决，这个问题不是阿里巴巴来解决，而是希望通过生态来解决。
InfoQ：按惯例，首先想请您介绍一下自己。
何云飞：大家好，我是何云飞，花名何导。我是2008年5月进入阿里的，在阿里巴巴将近8年时间里其中7年在阿里云，主要负责数据库产品RDS，包括MySQL、MSSQL、PostGreSQL、PPAS等，以及Redis、MongoDB等主流NoSQL数据库的十几条产品线。感谢InfoQ社群提供这样的平台可以让技术变得透明、开放。
InfoQ：前几年阿里去IOE对业界影响破大，您能否从技术的角度谈谈去O的细节？您本人怎么看待去O对业界的影响？
何云飞：去IOE被故意放大了，但是大企业的发展收到了硬件的限制，需要软件在上层做更多的扩展。运营的角度成本和交付速度都跟不上。重资产企业，必须考虑架构。以前硬件用总线来管理和调度，现在用网络。
去IOE只是在内部的一个项目代号，其实公司里面并没有特别宣传去O，这不是为了去O而去O，是技术上的变革。但今天来看这已经被宣传成一种潮流和趋势，这显然是被放大了，当然这可能是一系列的厂商利益在里面。而由此产生的蝴蝶效应我觉得还是应该解读一下。阿里启动这个项目，本身不是为了去IOE而去IOE，而是基于公司本身的发展速度，在数据库层面硬件的发展速度已经远远落后于我们的业务需求。
在过去几十年中，随着数据和计算需求越来越旺盛，硬件的发展也紧跟其后。对于一般性企业来说，似乎没有感受到硬件带来的限制，但其实是金融、央企等公共服务行业早已经成为瓶颈，所以有小机、大机等产品的出现。但哪怕有小机，也还是需要Oracle-RAC来配合完成计算的需要——这已经说明硬件本身是追不上需求的发展速度；变成企业标准配置IOE产品在应对互联网的发展速度时，也已经心有余而力不足。
这中间有一系列的问题：
- 从运维角度来看：成本、硬件交付的速度、为这些产品准备的IDC环境的时间、资源的复用率等等都是巨大的挑战。特别是像阿里巴巴这样的重资产互联网企业必须考虑这一点。
- 从技术角度来看：对超大流量型应用，单机吞吐量无法突破（计算、存储、网络）总有一个会遇到瓶颈。上层的应用还要做分布式解决方案；对小流量又无法很好的多租户隔离，造成资源闲置。我们当时也做了一些前瞻性的调研，发现要依托硬件来支撑业务发展一定是不行的。
所以我们希望做一些基础性的变革——希望用软件去定义世界，硬件只是一个载体。我们还是希望回到技术本身，在软件之上做一次创新，这是背后的意义。“去IOE”存在一定的技术挑战，“去IOE”不是简单改变软件和硬件本身，不是用另一种软硬件简单地取代已有的软硬件，而是用新的互联网技术和架构取代传统的IT技术和架构。在硬件层面，我们统一使用X86服务器以达到快速扩展，灵活部署的能力；在应用层面，我们用分布式框架将用户、流量切分，做到网络并发能力、计算能力、存储能力的多维线性扩展；在数据存储层面，我们用低成本、高性能的开源数据库MySQL来代替Oracle工作。
去IOE对阿里巴巴本身来说是一次技术革命，其实我们是构建一个基于X86服务器的操作系统。原来计算机有硬件，CPU一个不够加两个，网卡一个不够再加两个；硬件是通过主板来集成的，再上一层由操作系统调度。你再把它放大一下，原来CPU一颗一颗是在主板上，现在的CPU一颗一颗在IDC里面，谁来调？是一个分布式操作系统在调。以前是用主板总线去集合，现在用网络来集合；我们把软硬件的范围放大了，需要有更大的操作系统来调度。我们在突破这个限制，这是一个大的跨越。这一革命背后有两个深远的意义：
- 这是第一次上层软件应用的扩展可以不用等待硬件的发展；这使得整个IT生态会发生变化，使得有更多人，有更多的时间和机会去尝试新技术和新业务；回到计算机的本质——软件定义未来。
- 技术革命沉淀下来的是云计算服务；这样的技术以云服务的方式，通过互联网以最快速的方式向全球中小企业提供服务，变成经济和商业的基础设施；这将是影响未来10～20年的事情。
InfoQ：去O的难点在哪里？您觉得阿里这一看似偶然的去IOE对行业的影响是什么？
何云飞：难不难关键要看企业的决心。首先一个企业要大发展，要做这么大的变更、非常大的重构，有谁愿意？今天好在阿里巴巴确实有一种文化，愿意去创业、愿意去变革、愿意去拥抱这个变化。我们不断地用双11来战斗、磨炼我们的技术。这件事情就变得非常有意义、非常有目标性，所以我们可以做。
首先，云计算本身就是一个产能过剩的产物。我们发现很多企业买了很多机器，但CPU的利用率极低，供应商想的只是卖掉它（机器），我们想做的是更好地把这些资源利用起来。第二，去IOE的过程让我们沉淀出了云平台，这是非常关键的。现在这个云平台还有一个深远的意义，我们希望通过这个平台可以让更多中小企业——那些没有技术专家的企业可以非常快地在云平台上使用顶级互联网厂商的技术架构。
InfoQ：自2008年进入阿里您一直在做数据库方面的工作。从DBA到RDS开发再到产品经理，您觉得有哪些挑战？
何云飞：刚进入阿里的时候，我拿着OCP干着Oracle DBA，觉得很自豪；那时候中国最顶尖的Oracle DBA都在阿里，在这样的环境下工作不但可以学到很多知识，也可以迅速成长。但在2009年我们随着去IOE的项目开始“拥报变化”——这是我遇到的第一次挑战。分布式框架的后面是MySQL的批量化管理，动扎几百台服务器，每天被日常的运维、监控工作折腾得够呛；在一年多坚持后觉得这已经不是一条可持续性的工作方式。为了解放自己，2010年底开始组织DBA团队构建数据库的自动化管理平台——这里碰到最大的挑战，一是日常工作压力与创新之间的调和；二是DBA与开发两个岗位的过渡。
说实话我是没有转型成功，虽然还有一些我写的代码，但经常被团队鄙视为最烂的；但不管怎么样，我们的第一个版本在3个月后就发布了——所有的开发可以自助在平台申请数据库了。在我们的构想里面，未来的云是不需要数据库的。以后的数据都是基于物联网、互联网，都是大数据计算的。事实上这个过程非常漫长，当时一开始我们升级项目的时候没有审批这一项，公司资源也有限。这时候我们就偷偷地干了，我们优势在于说我们还是DBA，手上有数据库资源、有开发资源，这事是一定要干的，就开始干了。产品出来以后有用户了，我们和一个一个用户去交流，有用户的时候老板也肯定了这件事。这是简单的创新，这是我的第一次跳跃。
2013年我又一次从开发转岗为产品经理，开始专注市场分析、产品规划、产品管理；在那个时候自己很纠结，或许有一些对未来无知的恐惧。不知道这次转型对我的未来代表着什么？这个选择从今天来看还不错， 至少对我的人生经历来说，让我有很多可以回忆的人和事。"一个好的球员，应该是哪个位置需要就在哪里，需要去积极补位"，当时需要产品经理，如果我的目标是让产品更好地服务客户，那么我不应该犹豫。
刚让自己从繁杂的工作中解脱出来，云计算慢慢兴起。有两个事情启发到我：
- 我们曾经的痛苦所有的中小企业也都普遍存在，但不是所有企业都有DBA。我们的技术是否能够快速复制出去？
- 基于MySQL的DBA团队如何创新？我们是否能够在公共云平台有更大的生存能力？经过团队的决策，3个兼职DBA负责后端、1个外包开发负责前端我们开始了基于云平台的“创业”。很快，我们的产品2011年6月在公共云平台对外提供服务。
InfoQ：这么说来，阿里云项目下最初并没有RDS的产品规划？
何云飞：最早的时候版图里面是没有的。这个其实我觉得我们所有的技术者也是可以去参考的。如果你真的去创业，你要不断去思考，我这个东西有没有可能做得更好，能不能赢得用户的认可——如果你把公司当做自己的公司，这和创业所做的事没什么大不同。
这6年一直陪我走来的是阿里创新文化和自己的信念，我总结为三个词：”目标、行动、坚持“。我们每个里程碑会为自己设定更高的目标，并且快速行动、快速试错，我更幸运的是能够在阿里专注做一个产品6年，这是一般人没有的待遇，也得益于自己的坚持；每个人都想成功，但是没那么容易。
InfoQ：RDS是阿里云上重量级的产品，同时也是对外的服务。阿里云Open API功能自2014年10月正式开放，您能否谈谈目前RDS API的主要特点？
何云飞：数据库有一套成熟的API，我们一般分类为：DML、DD、DAL。DML、DDL一般用于数据库实例内部的容器和数据管理，而DAL用于实例状态的管理。
RDS Open API是基于数据库实例级别一整套管理接口。Aliyun.com控制台的所有功能都基于这一套Open API向后端下达指令；内容包括生命周期管理、资源调度、数据备份与恢复，数据库安全、优化等整套功能；特别适合批量化实例的管理操作。
随着云服务的普及，单客户的实例保有量也越来越多，有的几十、有的几百甚至上千。所以一个企业的云资源管理器将是一个非常有价值的产品；阿里云一直倡导生态的建设，我们希望有更多的开发者可以基于阿里云平台去构建属于他们自己的云平台，向全球更多的企业提供更好的产品和服务。
InfoQ：对于使用RDS产品的用户，在同步数据方面，您有哪些建议？
何云飞：这个问题很好，是从真实用户角度出发的问题。
云计算在这几年的发展过程中，最初1～2年用户要上云第一个疑问是：云安全吗？这个问题今天已经很少听到。用户现在的第二个问题是我们怎么上云？对企业来说这是一次跨远程网络的系统搬家，而为了保证企业用户的体验，不能有过长的停机时间。在这个过程中，数据搬家是最关键的一环；最近我们发布的一款产品，数据传输服务已经具备这样的能力——目前支持MySQL的全量+增量的数据同步，这让整个系统迁移只需要10分钟的停机时间变得可能。SQL Server当前只能支持全量，马上也会支持增量迁移；另外我们还有一个高级功能，可以支持Oracle到MySQL的异构迁移。
刚才说的只是数据同步的第一种场景——数据迁移上云；在云上可能客户还会有两种业务需要用到数据同步：
- 数据库容灾：比如金融行业国家有要求，必须做到两地三中心；RDS的多可用区可以完成本地两中心，如果需要两地三中心，我们还需要将数据同步到300公里以外的中心里；
- 全球数据同步：有一些互联网应用已经将业务扩展到全球范围，他们的业务属性本来就是全球性质的，比如跨境物流——中国的订单需要与国外客户同步，并保证体验。一般企业的做法是在国外也搭一个系统，并把数据同步过去；目前在这个方案上我们做得不够好，还在进一步完善中，有兴趣的开发者也可以一起来完善。
InfoQ：阿里在数据库方面的探索比较多，每年都跟国际技术团队有较多的交流。您能否谈谈现在主流数据库技术的发展趋势？
何云飞：数据库的发展历史，从第一代数据库问世到现在已经超过50年，经过层次数据库、关系型数据库、分析数据库、NOSQL数据库各形态的演变；这个过程的演变是基于企业对数据的存取速度，计算要求越来越高发展过来的。这个过程也是软件与硬件相辅相成共同发展的过程。
MongoDB 应该是基于互联网应用的最成功的分布式数据库管理系统。其数据模型上是基于KV的JSON数据，不涉及ACID的事务能力、易扩展，深得开发者的喜爱。纯KV型分布式数据存储还有不少同类产品，比如AWS的DynamoDB、Google的Spanner，但由于协议兼容性和开发者生态，其发展速度都不够快。
像阿里巴巴的OceanBase，兼容最流行的MySQL协议，在金融的在线交易领域，基于分布式+ACID的在线关系型数据库，追求高可靠、一致性；而阿里云刚发布的PetaData，同样兼容的MySQL协议和90%的SQL语法，追求的是PB级数据分布式扩展、低成本，以及亿级别的数据聚合计算能力。
从项目实施的角度来看，企业更希望可以基于原来的系统平滑升级，而不是需要从应用层全面开发和切换。所以，还有一个方向是从应用的兼容性出发做底层的扩展性，但这种扩展性会受硬件的限制，需要做软硬件的深度融合。Oracle一直是在这个方向前进，包括其ExtraData，当然成本也不是一般企业可以承受的。
以前我们有一个谎言说硬件就这样子了，今天的互联网业务的发展速度已经远远超过摩尔定律。互联网业务的发展，使得我们的系统吞吐量、存储能力、计算能力都达到了基础硬件的瓶颈。我们希望通过将具备一定计算和存储能力的PC Server资源聚合成一台超级计算机，来完成网络、计算、存储的多维性能扩展。而数据库作为上层的一个基础软件，能够通过云操作系统去获得这些资源，向上层应用提供可扩展、高性能的数据库。五千台资源调度我们已经做完了，下一步就是一万台的集群调度。如果有可能，我们希望能够保持多种数据库原有的所有数据模型，让原有系统的迁移变得更简单更平滑；这就是数据库界最近提高的高频词——NewSQL，它是集可扩展、高性能的数据库的简称，既有分布式的数据存储能力，又能保持ACID和SQL的特性。
开发者并不想把数据问题搞得太复杂，因为数据不会独立存在，数据本身就是要融合在一起。最后不管它叫什么，数据库的存在一定是先去适配应用的需求，在某个特定场景下生存并发展下去，然后再进一步提高性能和通用性。未来的方向其实我想说，还是分布式的方向。
结语：何导曾经说过，DBA现在都不知道自己的价值，企业发展最重要的沉淀就是数据，而DBA保护的正是企业数据。阿里巴巴在教育员工时说要思考、要思考，而很多员工总是说我很忙、我很忙、我很忙，但真正让他忙起来他又非常害怕。人要在原有的基础上不断地去思考，有创新才会有竞争力，不然一定会死，只是时间长短的问题。
关于受访者
何云飞，阿里云数据库产品总监，阿里巴巴集团“双十一”项目云产品总负责人。2008年进入阿里巴巴任Oracle DBA；2009年底开始研究MySQL，任MySQL DBA，ITPUB MySQL版块版主；曾开发MySQL大规模备份系统、MySQL快速部署工具，以及MySQL高可用自动化工具；2011年在兼任DBA的同时，成立RDS项目组，开始部署和开发RDS；期间担任需求和架构设计，以及部分功能开发工作；至今仍担任RDS PD兼PM，继续为RDS护航。