写在阿里云宣布启动AliSQL开源项目之后

 

导读	昨天，阿里云在召开的2016 云栖大会·北京峰会上，宣布启动了 AliSQL 开源项目，将这个经过多年精心打造的、支撑了阿里巴巴和阿里云内部多项重大业务平台的数据库平台公开回馈给开源社区。

在此举措赢得一片赞誉之外，我们也和阿里云数据库团队的多位专家进行了一场面对面的访谈，深入聊了聊阿里云在数据库方面的一些研究和探索，以及在开源背后所折射出来的一些发展和思考。

莅临现场的专家有：

• 丁奇，阿里云关系数据库服务内核开发和运维团队负责人，活跃的 MySQL 社区贡献者。专注于数据存储系统、MySQL 源码研究和改进、MySQL 性能优化和功能改进。
• 子嘉，阿里云缓存数据库负责人，负责 Redis 和 Memcahce 的开发团队。Redis 中文社区的核心发起人。
• 叶翔，阿里云 MongoDB 数据库技术负责人，江浙地区 MongoDB 用户会主席。
• 萧少聪，阿里云数据库产品专家，PostgreSQL 中国社区主席。

（本文整理自现场采访稿，有删节和文字修改。）

 

问：2016年大家都说是大数据年，也有很多的服务商提供大数据的产品服务。结合大数据和人工智能这样一个打包性的服务，请问阿里这边在结构数据库和大数据，以及人工智能方面是如何推进的呢？产品的战略是什么样的？

答：现在我们在整个 ApsaraDB 这个大框架的下面推进这个方向，作为一个分析型数据库，现在已经在公测 GreenPlum 了；后面我们还有小数仓这样的项目，它的目标是希望用户用 OLTP 的形式把数据写入数据库以后，不再需要导出到另外一个系统里面，可以直接在里面进行计算，数据的流转在内部实现的。在我们的小数仓的这种思路里，数据就不再流转了，数据放进去只需要一份。当你是需要事务性的操作，直接使用原来数据接口；当你需要做分析的话，还可以做跨数据类型的分析，比如说你可以把一些数据放在 PostgreSQL 里面；而最终还有“数加”这个平台，它把跨数据模型的数据放到一起做计算，这个项目我们也在推进当中。再以后是我们以前叫 OLTP+AP，现在叫 HTAP 的一个平台，是我们现在正在做的一个大的方向。

问：您觉得这个未来是一个重点吗？

答：对，这个未来一定是重点！因为现在数据量越来越大，以前我们觉得说放点数据进去，回头把它导出来，放到别的地方去计算也行。但实际上随着现在数据量越来越大，导出的时间会越来越久。而从另外一个方向，从应用的角度，大家都希望有实时的分析能力，这两个就矛盾了。如果我们一直沿着导出、导入的思路，一个是成本高，另外一个是时间根本满足不了业务需求。所以后面的 HTAP 方向一定是一个趋势的，而且一定能做出来。按目前我们团队现在的实力配备，现在大家在做这个方向，而且这个项目已经在积极推进了。

问：我想问一下，数据库给客户提供哪些服务？数据库服务是不是只有备份服务？

答：数据库我们给用户看的感觉只是在使用这个数据库，甚至于只有一个连接，并不知道数据库在哪里，这个连接后面包含大量的服务。比如说我们有简单的一主一辅的高可用架构，数据高可靠的定期备份，可以由恢复到任意一个时间点。这些在用户正常使用的时候，他是关注不到的，但是当误删了库的时候，就开始来找我们的时候，才会知道，原来你点个按纽，就可以恢复到那个时候。像这些功能其实对于正常的用户，平时使用不知道，但是你要支持这些功能，就需要一些潜在的服务。还有用户说我数据有没有被脱库过，或者说真的已经有一条数据被误删了，我想找出到底是谁在什么时候做的等等这样功能，这些其实都是潜在的服务，当它需要的时候就冒出来了。所以数据库本身我们可以认为说，我们希望它做到像本地服务一样，但实际上它本身隐含的功能是远超于我自建一个库的。

问：我想问一下业务架构问题，咱们和存储这边部门，分工是什么？数据库和存储的关系是什么？

我们数据库和存储之间的关系，在比较早之前，我们就是把存储当存储，数据库自己做数据库的事，确实存在一些浪费。也许存储已经做双份了，数据库为了安全又做双份，因为我当成单点在做。现在我们开始慢慢做融合，刚才提到过我们在做这种让数据库与操作系统、文件系统，甚至于跟底层的硬件之间全部做打通。现在我们可以在考虑的事情是，有一部分数据我们可以依赖于存储给我们提供高可靠，如果确定了这部分的产品可以高可靠，我数据库这层就可以以减少成本为目的，又保证了相同的可靠性。但是有一些数据并不是你提供一个高可靠我就要使用它，因为我们的数据库还要考虑到数据库的性能、数据库对客户提供的事务原子性、事务可见性功能等等。比如说我们现在在做的一套方案，应该是明年会推出来的共享存储方案。数据本身是共享存储的，但是日志不是，这样既能够充分发挥数据底层文件存储提供给我们的高性能，以及三个节点写入的高可靠的数据方案，同时我们的数据库的日志又是单独备份的，又能充分发挥数据库本地日志这样提供的高性能。

问：从过去两年历程来看，阿里云的数据库技术和产品的增速方面是很大的，在 2016 年，阿里云在数据库的产品和技术方面，还会有哪些提升。

答：我们也一直在想，去年已经 100%，今年还是 100%，今年出的跟去年有什么不一样，其实我们如果再往前看两三年，又不一样。第一年的时候大家一直在救火；第二年开始大火不用救，但是坐在那还是很慌，但是那年已经没什么事了；到了去年已经彻底没事，坐在那肯定没有问题，所有研发人员在那抢购东西。（笑~）所以我今年跟我们的团队里负责双十一稳定性的同事说，我们今年要做到什么？我们今年要做到不需要去值班了。我们要怎么做？我们是要把整个和交易相关的集群当作一个客户来对待，这个集群我们要有一个健康指标。原来我们是以每一个实例去诊断健康分数，今年我们要给健康指标。我今年先打一个分，现在就打肯定不是一百分，肯定会有一些比如说空间不够，或者是慢查询等等，我们会对它整体做出打分，算出集群的健康分数。我们用一个月的时间加机器，通过业务优化。等到下个月初再来一次，我们的目的是什么？如果十一月初的最后一次分数打分，已经达到我们的目标，比如 95分、96分。这样的话，到了那天我们是真的可以不上去值班了。我们双十一值班在七楼只有一个人需要值班，我们可以跟全体说不用上去了，我们就在下面，有事再上去，最好不上去，希望今年和去年不一样。

问：具体来说从哪几个层面做技术部署？

答：一是关于 buffer 预留，这是传统的；还有高峰期的业务预估，还有对每个业务的健康度的打分，比如说双十一大家都知道很多预案，会把预案自动化。还有甚至于都不要预案了，其实很多业务，比如聚石塔交易模型在这几年的护航里面我们都是比较清楚了。等于是说我们把它能够出现的异常都事先给出一些自动化的预案，提前开起来。以这种分数的机制，打分的机制去逐步的提高健康度，直到双十一之前我们不需要再去干预。

问：刚才我在想，咱们数据库边上紧挨着一个 E-mapReduce，即你所谓的融合。除了存储和数据库，数据分析里边也有一个融合，能讲讲这方面吗？另外可以通过举例帮我讲一下，在数据分析和数据库应用这块，有什么比较典型的应用场景吧。

答：刚才您看到的 EMR 服务，实际上是属于我们 ApsaraDB 一部分，但是从团队来讲我们是一个整体的。涉及到具体的案例，今年的时候我这边在做的 MongoDB 和 Spark 也是属于 EMR 的一部分，这两个是有很多的比较成熟的案例，尤其是现在在美国那边是蛮火的，在中国这边比较典型的案例是东方航空。他们利用了一个 spark 和 MongoDB 相结合的这种服务，来替代原来的 Oracle 架构。

问：替代 Oracle 架构的是关键业务吧？

答：是关键业务，我们每天的定单的查询，当然这只是在东方航空一个实践的案例。

问：咱们数据库从今年开始基本上做商用服务，我们整个的大概进展到什么程度？

答：如果这样算应该已经做了五六年了，并不是从去年开始做。阿里云的数据库对外我们就是提供给我们的客户使用，能够看到的话就是说以前大部分都是一些互联网端的用户会开始使用阿里云的服务，其实就是商家。其实我进阿里云时间不长，最近一年，也会看到有一些传统的企业或者行业，慢慢的愿意去把数据放到上面来。可能有很多人都在把数据放在云上觉得不安全，说句实话，哪怕你自己建 IDC，你的安全风险都是相同的。今天的话，他们要避免的就是他们建 IDC 的费用太高，他们真正把数据放到云上面来说，他们 IT 的管理会更好。现在双十一都自动化，运维的人员更轻松，传统企业也希望他们的 DBA 不是每天都在做备份、检查、复制、监控的工作。他们的 DBA 应该是把时间空余出来，更好的去优化他的 SQL，对他的企业负责，让他的企业运行得性能更好，去产生真正的业务上的价值，而不是天天只是盯着一块屏幕说，这个备份挂了，然后我去拿一些东西出来恢复。所以说最近一年我们应该看到越来越多传统的行业，包括有金融的，甚至制造业的都慢慢往云上来做，他们希望通过云的方式，解放他们 DBA 真正的价值。

问：我刚才问的问题是这样，咱们去年才开始正式提这事实，很多都是需要去救火，其实还没有真正到商用的感觉，去年底的时候，才开始确定了在这个范围做这个事。就这块行业案例大概是怎么来看，咱们现在的这个案例的规模，就是已经开始围绕咱们数据库做的这些。

答：您这么一问的话，我还并不能说一个具体的数字，但是你会看到现在阿里云的官网上针对数据库的方案，我们以前推广的方案更多是互联网怎么样，但是现在你会慢慢看到新的成功案例，你会发现更多是以企业为主。因为毕竟在中国的话，线下的企业市场应该算是占了更大的一笔江山，我们说这是大金主，而且他们对稳定和功能，其实需求更多。

去年年底这个时间我们最近在做的事情。一个是数据安全，我们刚才有提到问存储那边，数据库现在在银行业务里面，默认是加密的，你不用担心文件被别 DBA 拷走的，或者是说你磁盘销毁的时候人家拿走了，没关系，现在是写入磁盘都加密的。现在整个阿里云的数据库主流还是 MySQL。以前的 MySQLMySQL，社区版的 MySQL 我就知道有一个丢数据的问题，对于金融这种业务领域，其实是一条都不能丢的。去年年底我们上线一个功能，从那个功能以后，我们现在就敢给银行的核心业务使用，因为可以保证说你即使只有两个节点，在掉电的时候一定不会丢数据。其实银行可以接受一点不可用性，我确定地说我这个数据还能同步过去，可以慢一点。暂时不可用没关系，但是不能错。我们去年完成了这样一个方案，这个方案完成以后现在所有的像网商银行这种金融业的服务，我们是可以大胆的去推的，去使用的。

问：这个会造成存储的负担吗？

答：每一个实例都需要 500M 的空间，500M 对现在来说已经没关系了。

问：对传统的行业，有个迁移成本。可能他们在用 Oracle，也可能在用 db2 ，他们有一个习惯 MySQL 的过程，这个迁移工作怎么来协调做？

答：是这样的，其实首先对于整个 ApsaraDB ，我们为什么有这么多的产品，其实我们是想让用户有更多选择，比如说 PostgreSQL，还有 PPAS。PPAS 跟 Oracle 的兼容性达到 99%以上，我们有用户直接迁移上来，直接拿代码，把 Oracle 迁成 PPAS。

问：数据类型也一样吧？

答：存储过程都可以直接用。对于这种用户，他就想减少改动量，我们会推荐他们使用 PPAS，现在我们已经有用户在用。

问：其实在像您说上云，数据库迁移上面，我们会提供一个阶梯型的结构给用户选择。举个例子，你刚才提到使用 Oracle 的是中国用户量最大的一些客户，它在进行上云迁移的时候，第一它可以直接把他的 Oracle 放在我们的 ECS 上面去运行，这也是没有问题，他一行代码都不用改，只是说我传统的云下的服务器变成云上的服务器，这是第一种，当然整个维护管理要按照 Oracle 的来。

第二如果你是希望让阿里云的整个数据库的团队帮助形成一个云的数据库运营的方式的话，也就是说备份、时间点恢复等等东西都通过云的平台点鼠标完成的话，你可以把 Oracle 迁移到 PPAS，因为我们本身的兼容性并不是说一点点东西都不用改，可能需要改一些东西，但是不用全改。简单的迁移过来以后，如果用户还需要采用未来云数据库方式的运行，可以再去考虑，也就是说他的 Oracle 可以先快速上到云上面来，解决的怎么样的一个运行的方式，再去考虑怎么进行互联网形式的或者是分布式的数据库的横向拆分。因为一旦做横向拆分，他的应用程序一定是要进行改变。但是对于用户来说，他更希望的是有一个阶梯过来，先知道，先感受到什么是云数据库，怎么可以方便他的运维，提高他的运维效率，然后再去考虑他整体的业务，怎么向互联网化，向分布式的架构去发展。所以我觉得数据库迁移，不是说今天是 Oracle，明天变成另外一个数据库这么简单的 0 和 1 的变化，实际上中间是需要有一个过程。没有可以从 0 到 1 突然间变化过来的过程，数据库迁移一定需要用户慢慢的去进行项目或者是业务的改造。

问：我还想了解一下云数据库，云数据库未来面向行业的问题，我刚才看到咱们基本上还是在自己的平台上进行一些应用是吧？而且您刚才说了银行行业，如果银行行业介入的话，它的安全性还有数据的加密的管理性还是比较看重的，我想了解咱们云数据库这块，如果想进入市场的话，会从哪些行业作为切入点呢？

问：我来回答一下，我们现在在很多行业同时切入，比如说现在比较火的视频或者是直播，或者是游戏。我们数据的整体方案不是一个产品出去，我们是整个云数据库形成一个合力。比如说在视频或者是直播领域，我们是以 Redis 打头阵，解决在直播领域解决一个网红的热点问题，后面的存储，我们用数据库，然后数据分析我们在用 EMR，然后有些存储还选择了 MongoDB，所以你会看到这是整体的生态，而这个生态也是我们云数据库围绕着去打造的。

问：你觉得对手是在学习阿里吗？

答：反过来说吧，阿里确实在做数据库，你会看我们推出的线上数据库基本上都是基于开源。你会看见有很多的厂商，把开源的版本上线给用户提供使用，然后提供一些管理就 OK 了。我们主要就是开源的东西进来，然后提供一个管理工具，在云数据库上用得更舒服一些，更简单一些。但是今天阿里在座几位，除我之外，这几位都是内核的专家，像子嘉在 redis 上面，其实我们都是打开了 redis 的原码，把原码吃透了，然后再提供服务。甚至我们有很多的一些核心的优化，并不是从简单的开源产品上做，而是从整个开源数据库的核心底层，跟我们的网络、跟阿里、跟其他一些云的这种运维的模型进行了深度优化，再提供用户使用。所以大家看到市场上有某些公司，在某个行业做得很好，但其实在阿里这边我们发挥本身技术上面的一些底蕴，你会看到阿里参加各种行业的这种会议，甚至是像我们到美国去跟美国的同行去分享开源的信息的时候，甚至美国的同行都会问，我们这个东西到底是怎么做的，他们还得再去学习。就是在很多数据库底层的领域，阿里是占先一步往前去走。我们相信通过技术是可以占领市场的，而不是通过一个资本运作的形式去维系一部分的产业和合作。

每个行业有它的诉求，比如说银行类、金融类，首先要求可靠性非常高，比如说我找个 ATM 刷卡，刷不出来没关系，查一下机器坏了没关系，查一下钱没了不行。然后游戏可能要秒开服务，要符合这样的需求。其实每一个垂直行业，都有一个定制化需求，而这种定制化需求是现有的开源产品无法支持，因为开源给的一般是通用化的功能，所以这就要求你要针对一个垂直行业，你要能够解决这个垂直行业最痛的那个点。其实到这个点的，大家拼技术，并不是他们拼关系，你提供不了这个方案就用不了，银行的没有我们这个高可靠的数据方案，MySQL 就不敢用，这个时候就是我们的机会。

所以我相信阿里更多的是从技术上在领先，你会发现我们每一款产品并不单纯是提供产品的模型，甚至会看到阿里已经在向开源进行付出，进行回馈，让整个业界的技术慢慢得到很好的发展。

另外大家有误解，认为上述提到金融领域指的支付宝，物流指的是菜鸟，其实并不是这样的，像支付宝的可能是金融中的一部分，像我们服务的正通也是属于我们金融的一个比较大的客户，像电商云有网聚宝，有很多其他第三方用户。并不是说我们这些金融还有物流就是指阿里自嗨的，其实很多第三方的客户，阿里反而是占了很小的一部分。

问：您刚才谈到取代 Oracle 您觉得这个过程还需要多长时间？

答：这个过程不取决于我们。我举几个例子，我们在刚才提到金融云是吧？其实我们在金融云里面有很多 Oracle 迁移的例子，并不是我们公司，而是一些像保险这样的行业的项目。人寿的核心系统或者是财险的核心系统，在我自己经历的几个案例里面，他们里面的产品从 Oracle，变成在阿里云上面运行，大概花费的时间，从技术开发来说，大概会用一个月到两个月的时间，这是一个迁移的时间。人力的话一般会在三到六个人之间，就是三到六个人的两个月，他们完成了一个核心的寿险系统，或者核心的财险系统从 Oracle 到阿里云的迁移。但是这只是技术上完成，然后他们会拿着这个方案去售卖给他的最终用户，因为这些是我们所谓的 ISV 开发商，他们完成这个迁移之后，他们就会推广这个产品。实际上我们更多的现在就在做这样的方法，我们去支持我们的 ISV，去完成这样一个迁移，迁移完以后就可以覆盖这个 ISV 更多的用户。用户可以有很多选择，今天他说我一定要用 Oracle，没关系，我们的 ISV 依然可以提供 Oracle 方案，同时的话，如果用户说我希望去 O，阿里云的整体方案就可以符合用户的使用。所以今天并不是说我昨天在用 Oracle，今天就切过来，不现实。而你上到阿里云以后有一个特别好的好处是说，你原来的 Oracle 是由一堆 DBA 在运维的，今天你换到一个新的数据库，你的 DBA 需要很长时间需要重新学习。而在阿里云里面，因为我们有 RDS 的整个管理体系，就像刚才丁奇所说的，我们有整套的运维自动化的管理体系，所以说 DBA 从传统的数据库切换到阿里云的时候，他不需要这么多时间去学习，去关注这个新的数据库的一些管理的细节，可以把所有的精力投入到该怎么利用 SQL 去提高他的生产力这一方面。这样可以让整个的 Oracle 迁移会更加的顺畅，但是千万别想着一天就结束掉了，这个一定是，如果有谁说我迁移叫做零成本，这肯定是骗你的。

问：你刚才说三个人两个月是多大的规模？

答：这种规模的话，应该都是一些寿险行业的核心的系统，可能牵涉到的话是超过十万行的代码的存储过程。就具体你说分行等等，这个我觉得很难按照这种角度去看。我见过很多银行系统，虽然说是省级的，其实里面很简单，但是你直接去看他的代码量，我们之前迁移的合作伙伴大概在十万行的这种量级，我说的迁移成功是说整个前端运维程序和数据库联合运营可以最终达到交付的角度。

问：您提到了 DBA 的职业转换的成功，我想知道，因为现在云端是一个趋势，DBA 面临职业转型。在过去或者是在未来，我们 DBA 面临职业转型的时候，您给出哪些建议？

答：这个问题跟前段时间虚拟化会把多少运维人员给干掉是一个问题，就是今天所有的东西一定是越来越自动化，包括今天我们说 SQL 要优化，我们已经提供很好的报告，说这个 SQL 应该加什么索引，我觉得未来的 DBA 更加要了解他们所在公司的业务，从业务的角度怎么去更好的优化他的 SQL，和优化他的整个数据库的表结构，真正为他的公司带来价值。而并不是说我今天把数据库的底层管理得多好。因为这件事情会越来越自动化。我们今天开一个云上面的服务器，你点一下按纽，五分钟之内什么 HA、数据备份所有东西全搭好了，而且你不用担心像以前某个 DBA 搭了一个集群说，我写错了一个参数，到我系统真正出问题的时候，根本切换都切换不过去，然后我停了一天的业务。不会！这件事情我们自动化通过模板全部包装好了。所以我觉得 DBA 未来应该更贴近业务，做真正有价值的事情，而不只是停留在点几个按纽，写几个命令做备份。

而实际上阿里巴巴自己本身在践行这套思路，以前我们把 DBA 分为运维 DBA 和业务 DBA，其实现在也没有了这种区分，就是基础这层已经都被云的功能替代掉了。而实际上我们知道即使 Oracle 时代，包括现在也是，那些能在业务里强势的 DBA，并不是基础做得好，并不是扩容加机器加得特别快，而是他最了解业务，他能够去以一个数据架构师的方案推动业务的改造，这才是他们核心价值目前能够持续增长的价值。绝大部分的工作是系统来做，人应该是靠系统来推动，现在阿里云内部的云数据库，有三百多个业务，只有一个 DBA 在管。

但是 DBA 这种职业是永远存在下去的，并不是被取代，只是原来可能很多是劳动型转向架构或者是脑力运行的形式。

刚才你们问到 DBA 的问题，我们之前也跟很多 DBA 讨论过，现在我们觉得 DBA 应该向数据库管理员向数据管理 DA 去转型，他应该把自己数据存储的东西生产上，在大数据的业务分析上，这才是个 DBA 以后应该做的行业的职业发展的选择。这个可能是我们在 DBA 界讨论出来的大家觉得比较好的方向和趋势。

另外我们 AliSQL 数据库明天宣布马上开源了，丁奇这边也会对这部分内容进行一个介绍。

答：我刚才讲了一下，我们做生态，我们怎么走在更前面，阿里尤其是在 MySQL 积累了至少8年以上，中间有很多像高并发、秒杀服务的能力，线上高并发的交易能力等等，还有数据安全，我们希望把这些能力除了放在云上面以外，我们希望把它开源出去，开源出去有几个好处，我们可以让更多人一起来参与，这个生态其实是非常有意义的。可能有的公司说，其实比如说阿里云提供的功能，大多数能解决，但是就是有一个痛点我解决不了，很可能因为这个事情影响上云的节奏。或者还有另外一个，发现了一个什么 bug，在官方的响应速度比较慢，一般半年才会回复，在我们团队每个月有一个迭代版本，所以我们可以把社区促进起来，让更多人来参与到这个事情里面，生态就起来了。也许不一定说像刚才提到的，甚至我连上云都不一定是一步到位的，我有开源版本，我可以在本地试用一下，先看看阿里云提供的这个开源版本，跟我们自己的有什么区别，我们就先试用。慢慢用户在本地使用的也是 AliSQL 这个分支，跟 RDS 是同一的版本，那么他的上云的过程，不管是上云还是下云，还是做备份，它会更加流畅，中间会给我们提需求，我觉得这个生态是另外一个方面的核心竞争力吧。

我想这也是一种勇气。我进来的时间不长，我在传统企业也尝试过做开源的事情，你可以想象的事情是我今天开源了，明天我们的竞争对手就过来抄，我们怎么保证，就要靠这个团队，不停的在自己的版本上持续的更新，持续领导整个行业。因为今天开源这件事情，一旦开源出来，相当于大家都可以使用，对吧？那我们需要的是有足够的勇气和足够的团队去保持我们整体的竞争力，才会实现到这样一个步骤，所以说这也是我们技术团队的底蕴。

问：我想问一下，为什么我们开源 AliSQL，而不是像之前，继续把补丁推回到 MySQL？

答：这个我来回答，是这样，比如说官方的数据库版本，它是一个比较通用的版本。有些云上面需要的功能，从功能角度来说是不够通用的。比如说官方默认的功能里面，就可以支持各种引擎，但是有些引擎是不安全的。对于普通的用户来说，我继续用不安全的引擎是容易出事的，但是一旦出了事情，他不会去找官方有问题，他一定说阿里云数据不安全，所以我们要替用户多考虑一些，把不安全的用法去掉，把不安全的引擎用安全的引擎替换掉。但这些功能官方不会接受，而我们觉得是非常重要的。当然同时我们现在在开源这部分里面，我们会尽量把足够通用的回推给 MongoDB，回推给 Oracle，像 bugfix 修复这种都是直接提的，我们自己修复，但是一般我们会更快，因为我们要解决用户问题，我们会先上线，同时把 bug 修复贡献给社区，让社区合并。中间一定会有一些不一样，我们要做好多，比如说数据加密这个功能，我们如果提给官方，官方说 ok，这可能 5.8 版才能支持，得要明年才能支持。我们承诺给用户需要的是非常重要的功能，所以我们一定要有自己的分支。

问：会不会有一个问题， AliSQL 离官方版本越来越远？

答：这在公有云上不太容易出现这种现象，因为我们一定要一直保持着跟官方相同的使用习惯，因为我们不是自己在玩，因为我做完以后可以要求内部的 DBA 说你按照我的方法来做，但是现在在云服务上是不行的，它同时要服务给外部的客户，外部客户比如说我出现这种语法不兼容，我根本上不了，因为我本地就是这么用的，所以我们要保持兼容性。我们可以做到每个月都频繁的迭代，为什么这么小步快走，是因为我们能保证每个版本都是跟向后兼容的。我们是做的加法的，减法不做。刚才说的影响安全的去掉，但是这种做法往往对用户是透明的，比如说一个原来的引擎换成一个更安全的引擎，对用户来说使用是一模一样的。兼容性是我们重点保障的，我们要保障用户能够随时很方便的同时，线下的用户可以快速的上云，所以它的兼容性需要保证。

问：阿里提供很多种数据库服务，我想会不会有综合性的产品，比如说作为企业来说我有没有一种功能，内部集成好各种数据库功能，打通底层数据库，甚至是一些 nosql 数据库的功能打通到一起？

答：这其实跟我们第一个问题很接近，就是一样的。比如说现在 MySQL 是没有搜索能力的，虽然提供检索，但是检索能力很弱，还有压缩功能，其实压缩功能不太好，其实现在我们已经推出了压缩的 InnoDB 引擎，它已经进入到 MySQL 里面去了，用户可以自己选了。我如果这个业务是压缩率不需要那么高，但是速度很快是这种用原来的。如果我是日志型的，我要求它压缩率特别高，平时不怎么读，比如像帐单这种，可以选择另外一种支持压缩的。接下来后面我们会突出这点，数据库里面自带搜索功能，数据库里面自带数据分析的功能，自带缓存的功能，自带文档的功能，其实都在这个框架里面。

我觉得您这个问题应该更多是形成组合、几个方案。在阿里云的一个好处，今天我可能要用 redis，以前的方案是我要买一台服务器去做 redis，但实际上我用不了这么多的缓存；再话说回来，我可能未来要扩充怎么办，你现在刚刚建的时候，你都不知道有这个方法，可能你的配置都没有管理这一点，你未来扩充很麻烦。而今天在阿里云里面，你再选择的时候，我已经有这么多的产品放在这了，按照你不同的需求，你可以先选择这个产品，当这个产品线有的容量不足的时候，你随时可以进行扩充，你可以只扩充 redis，不扩充 rds，也可以只扩充 MongoDB，不扩充 rds，或者是反过来同样的操作，这会变成一个方案，而不能变成一个把用户框得很死的产品，因为用户的业务也在变化，让用户业务变化过程中，更加方便的选择不同的产品，迎合他不同的需求，这样更好，而不是整合产品的形态。所以我们在团队里面会做很多的沟通，怎么去让这些方案使用的时候更加方便。包括我们也会有数据传输的这样一些服务，可以实现数据库之间的这种数据打通。

其实阿里云在对外客户的叫 CA（架构师），他们其实就是按行业，可以看物流行业，游戏行业，他们给出架构图，其实就是很相似的，就是统一的解决方案的标本，然后每个不同的公司，在下面做不同的修改。在底层基础上，我们要做的是让我们数据逐渐流通起来，各个产品逐渐去打通。

而且大而全的那种，比如说像整体打包一个方案出来，效果有时候不一定好。比如说新浪的 SAE，还有谷歌的 GAE 看似解决了所有问题，但是最终都放弃了，其实真正客户的痛点你还是没有碰到去解决。

问：未来的数据库和容器技术是怎么考虑的？

答：容器的话，阿里云今天在逐步尝试。因为之前阿里云确实没有 docker 化的服务，我们也会近期去推出。包括数据库层面其实也是，其实容器更多对数据库来讲是资源隔离，一个资源管理的单位，我们也会逐渐去向 docker 或者其他的容器发展。

问：数据库还有一个常做的工作是做 BI 工作，咱们这块怎么考虑的？

答：我来说一下吧，因为刚好在7月11号，我们发布了 greenplum 产品。在我这边，其实更多的跟行业的 BI 厂商去做整合。其实两个方向，第一个方向就像大家已经看到的阿里的数加平台，其实它也会进行跟像我们这条线上面的 OLAP 的数据库进行整合，就像你所说的我拖拽就可以形成我们的结构，这是第一块；第二块的话，其实我们引入 greenplum 产品，也是为了去接入本身市场已经有的生态。

两种方式都可以，其实还是回到那个问题，今天我们希望用户用云更方便，他有两种选择，第一种选择我还是用原来我们公司已经习惯的 BI 软件，因为这个 BI 软件，天生就可以支持 greenplum，所以直接就可以用了，他原有习惯都不用改。第二种情况，我原来可能没有 BI 软件，我想直接在云上面使用，这个时候的话，我们其实会跟数加这样的平台进行整合，通过他们的平台直接在云上提供 BI 的拖拽工具，所以两个方向都可以实现。

并不是说我们做数据库是想取代哪个数据库，我们更希望是一种融合，像原来一些公司用 BI 的服务，我们也要保证我们自己的兼容性，原来在自己公司能用，到我这里肯定也能用的，因为兼容性是一样的。甚至我们现在有 PostgreSQL、有 FDW 技术，这是保证了一个 SQL 的一个入口，后面甚至可以放 MySQL 都可以。