日前Google云服务负责人称 “云 1.0 时代”已结束，由机器学习驱动的“云 2.0” 正向我们走来。在云市场只能算新玩家的谷歌，真能凭其领先的机器学习技术在智能云市场脱颖而出吗？机器学习能让云端大数据升值，它正在改变企业使用云的方式，也刷新了企业对云的预期，接下来智能云服务无疑将成为主流。但谷歌能否领跑市场，还是个问题。
日前，谷歌云业务高级副总裁 Diane Greene 接受采访时指出，云 1.0 时代已经结束，云 2.0 时代正向我们走来。
谷歌在云市场并不占有显著优势，为何能够发表“更新换代”这等高度的宣言？
谷歌认为，人工智能或者说机器学习，将是区分谷歌云和其他云服务的关键。
谷歌为何现在进军云市场？
看完 Greene 的发言，可以这样总结：云 1.0 时代，企业在云上储存数据、运行 App 和服务，主要是为了节省时间和本地工作量，从而降低成本、提高工作效率；而到了云 2.0 时代，企业不仅要使用云，还希望从云中获取更有价值的信息。
用 Greene 的话说，“云 2.0 意味着拥有数据并且理解数据——既然你已经使用了云服务，就应该尽可能利用云，让你的业务提升到一个新的高度”。
谷歌方面称，谷歌机器学习云能够分析大数据，为企业提供改善服务或产品的建议。例如，通过分析云数据知道为什么某款产品在欧洲和北美畅销，却在亚洲遇冷，进而推出一款迎合亚洲用户偏好的改良版。
据悉，2015 年全球云市场 230 亿美元，相比 2014 年增长了 52%。根据最新发布的 Cisco Global Cloud Index，未来４年全球云流量将是现在的５倍还要多。
是的，云是个大市场，但为何谷歌决定现在加入游戏？
简单看，原因主要有３：
回答 2016 年 Q1 投资人提问时，谷歌 CEO Pichai 表示，谷歌在内部使用云的多年积累，让公司已经具备对外提供云服务的能力；
谷歌推出了 TPU，专用于加速 TensorFlow 等机器学习应用；不仅如此，谷歌还将 TensorFlow 开源，将自然语言解析器 Syntaxnet 开源，这都有助于其收集数据，完善算法，而这些都将增强谷歌机器学习云的性能和盈利能力；
要实现 Pichai“以 AI 为先”的世界，需要通过云让谷歌的人工智能技术到达企业用户。
谷歌表示，谷歌云已经与 Spotify、可口可乐等企业达成合作，并且实现良好运营。
谷歌确实拥有强大的机器学习能力，但这真能为谷歌在云市场带来优势吗？
亚马逊：通过云渗入其他市场
据调查公司 Synergy Research Group 数据，谷歌云服务 2015 Q4 财报中排名第 4，前三名分别是亚马逊、微软和 IBM。来源：marketrealist.com
在谷歌杀入云市场的同时，亚马逊当然也没闲着。去年，亚马逊为 AWS 增添了 722 项新功能，还发布了大数据分析视觉处理工具 Amazon QuickSight。
此外，与举着机器学习大旗进军云市场的谷歌恰好相反，亚马逊则通过在云端运行其智能语音助理 Alexa，将触角伸到了更大的市场——谷歌也在的智能语音助理领域。
5 月 28 日，亚马逊将其智能语音助理 Alexa 放到了云端并开始测试。用户不用购买实体扬声器 Echo，只要用亚马逊账户登录 Echoism.io，就能与云端的 Alexa 对话，实现与 Echo 同样的功能。
亚马逊还成立了 1 亿美元的基金 Alexa Fund，鼓励开发人员、硬件制造商、初创企业等等都围绕 Alexa 研发技术和产品。亚马逊为此发布了两款独立工具包 Alexa Voice Service 和 Alexa Skills Kit，让企业能把像扫地机器人这样的智能设备整合进 Alexa 系统。
有外媒评论称，“Alexa 或将走出 9 英寸的扬声器 Echo，在与 Alexa Fund 合作的各种公司帮助下进入新的设备”。
这样看，除了云之外，亚马逊接下来还将与谷歌、微软在智能语音助理市场形成更加直接的竞争关系。
微软：也在增强机器学习云
从云市场发展看，微软的 Azure 势头或许还要强劲，2015 年实现年增长率 140%。微软 Azure 也使用了机器学习，还有 Azure platform、Office 365、Dynamics CRM 等云端解决方案。
值得一提的是，昨天，微软正式启动了投资基金 Microsoft Ventures，计划投资与公司利益相符的项目，其中就包括云计算和机器学习。
Microsoft Ventures 负责人 Nagraj Kashyap（此前是高通公司 Qualcomm Ventures 负责人，2016 年初加入微软）在公开博客中写道，微软建立 Microsoft Ventures 就是想要增强自身的产品和技术，在颠覆性技术出现早期就介入，抢占市场话语权。
此前的 Microsoft Ventures 改名叫 Microsoft Accelerator，将继续资助初创企业并提供技术资讯和支持，其重点关注的，第一个就是开发增强微软云 Azure 产品或服务的公司。
６月２日，也就是明天，Microsoft Accelerator 就将听取一批机器学习新创企业的展示。
可以预见，微软 Azure 机器学习相关服务将进一步加强。
机器学习开启“云 2.0”时代？
当然，也有不同的声音。独立产业分析师 Jeff Kagn 认为，“云 1.0 时代已经结束” 这样的说法可能为时尚早。他说，“过去几年中，云的增长比我们想象的还快。但这并不意味着我们几年前担忧的那些问题都得到了解决”。取决于企业对大规模的数据信息整理排序的能力，“大数据既是一座金矿，也可以是挡在你面前的一堵高墙”。
2016 年 Q1，市场份额第一的亚马逊云年增长率为 57%，接下来的三巨头微软、IBM 和谷歌，同期分别实现年增长率 93%。但从第 5 名开始到第 20 名，这个数字就成了 41%，其中包括阿里巴巴、CenturyLink、HPE 和 Oracle。全球云市场 Q1 平均年增长率为 52%，这说明排在前面的４家公司扩大了市场份额。接下来，云市场由前４家主导的形势或将加剧。来源：marketrealist.com
根据 451 Research 的调研，云 1.0 时代，只有大约 15% 的企业——那些相对热衷尝试前沿新锐技术的公司——把自己的应用或服务在云端运行。因此，要让剩下偏保守的企业使用云，就必须要让云能够为其提供更多的价值。
机器学习能让云端的数据产生更大的价值，但使用机器学习的云服务并非只有谷歌一家而已。
不论云 2.0 时代是否正向我们走来，可以肯定的是，机器学习正在改变企业使用云的方式，也刷新了企业对云的预期，智能云服务将成为主流。至于谷歌是否能在其自己揭幕的时代里成为第一，还有待时间证明。
【文/ 闻菲 新智元（微信号：AI_era）】
·氧分子网（http://www.yangfenzi.com）延伸阅读：
➤ 微软两大现金牛业务显疲态，云计算服务欲起势
➤ 李玮：云计算崛起，阿里是否会成中国版Alphabet
➤ 甲骨文联席CEO：公司拟将所有产品放入云系统
➤ 阿里副总裁徐子沛：普及云计算，建设指挥互联生活
➤ 微软和亚马逊传出的信息：云统治时代来了
➤ 巨头接连入场 ROM大战2.0即将开打？
➤ 和阿里云成立合资企业的迪拜企业Meraas是什么来头？
➤ 腾讯副总裁邱跃鹏：用云技术推进互联网+战略落地
➤ 经济学人：云服务价格持续走低，IT行业迎来变革
Zdnet 网站推出机器学习平台横向比较系列文章，以下内容分析谷歌、百度和 IBM 三家大公司 AI 实力，以及是否适合作为你的机器学习平台。谷歌的机器学习平台的优势在于构建更广泛的研究社区，围绕机器学习和民主化机器学习工具和服务的业务。作为在中国对标谷歌的百度，其 AI 平台是百度大脑，并开源机器学习平台 PaddlePaddle，在语音识别和深度学习知识经验方面占有优势。IBM的机器学习平台则以Watson解决方案为核心，实力来自三个关键因素：IBM研究、收购实力及其咨询顾问能力。
选择谷歌作为你的机器学习平台
（文／Natalie Gagliordi）谷歌的机器学习产品包括一系列的云服务和工具。2015年，谷歌通过开源其机器学习库 TensorFlow，进一步扩大了其产品的市场占有率。TensorFlow 现在已经是 GitHub 上最受欢迎的机器学习项目，贡献者大部分来自谷歌公司之外。
TensorFlow 之后，谷歌云平台发布了一套基于谷歌预训练机器学习模型的专门的机器学习 API，谷歌云机器学习产品经理 Rob Craft 称这套 API 旨在为开发人员提供高质量的认知服务接口。这套 API 集包含机器翻译、云视觉、自然语言、语音以及工作API。
谷歌云机器学习服务允许用户创建神经网络和算法模型，且可以运行大规模的预测，而不必担心基础架构的限制。该服务使用了多个谷歌云的数据分析工具，例如 BigQuery、DataFlow 和 Datalab。
谷歌也利用机器学习来为自己的基础架构提供支持。Craft 说：“例如，我们使用机器学习使我们的数据中心冷却所需的用电量减少了 40%，这位我们的用户带来了成本效益，以及为地球带来环保效益。”
使用谷歌机器学习平台获益的企业之一是 Evernote。这家笔记服务公司9月份宣布将它的基础架构转移到谷歌云平台，根据其 CTO Anirban Kundu 的说法，效果远超预期。Kundu 说，Evernote 现在使用了谷歌的语音-文本转换服务、翻译API、自然语言API和机器学习托管服务。
挑战与伦理
虽然大多数机器学习企业都会遇到 AI 和机器学习系统开发中的技术障碍，但谷歌面对的挑战更微妙。以谷歌的搜索团队为例，该团队发现机器学习系统只需几个月的工作就能显著提高搜索效果。Craft 说：“难点在于说服这个团队去和机器学习的专家商讨，这是有关文化的问题。技术本身只是一个方面，但搜索是谷歌的一项重要服务，要考虑文化的因素。”
在伦理道德方面，谷歌是 AI 安全研究和道德讨论的积极推动者。谷歌与亚马逊、Facebook、IBM以及微软建立了合作伙伴关系，以向公众普及 AI 知识。谷歌还与 OpenAI、斯坦福大学以及伯克利大学合作，进行 AI 安全方面的研究。
优势与远见
根据 Craft 的说法，谷歌的机器学习平台的优势有两部分：围绕机器学习构建更大的研究社区，以及使机器学习工具和服务民主化。“谷歌对机器学习方面的研究团队进行了大量投资，”Craft 说，“培育更广泛的机器学习社区有利于加速技术的普及和突破，提高其改变世界的潜力。”
这种开源策略与谷歌决定使用其公共云基础架构进行机器学习密切相关，使用公共云有助于降低成本和对架构专业知识的需求，同时提高可及性。Craft 说：“使用公共云使我们能为用户提供最新的服务和技术的最新进展，例如无障碍改进现有产品，以更快的速度提供新服务，并且无需用户付出额外成本去支持必要的基础架构。”
谷歌机器学习的另一强项是大量的数据和强大的计算能力。Gartner 机器学习和数据科学研究副总裁 Alexander Linden 说：“数据和计算架构是机器学习和AI的关键，谷歌的强项也正在于此。”
展望未来，谷歌对机器学习和人工智能的远见在于，随着技术的普及，社会和经济都将发生积极的变化。“机器学习推动云计算的下一波浪潮，”Craft 说，“我们相信未来机器学习将为许多不同的行业带来好处。我们的下一步是为特定行业的使用案例创建更深入的、定制化的深度学习模型，我们期望继续为每个人提供产品和服务。”
选择百度作为你的机器学习平台
（文／Teena Maddox）百度经常被称为“中国的Google”，但在美国，技术界之外鲜有人知。百度是一家搜索巨头公司，2015年收入达到102亿美元。百度在2015年的研发投资达到16亿美元，比2014年增长46%，其中增加投资的重头是人工智能。
百度副总裁兼首席科学家吴恩达（Andrew Ng）说：“AI 是百度的 DNA。AI 的最新进展加速了我们的研究进展，扩大了 AI 的影响力。”吴恩达是百度研究院硅谷实验室的负责人，负责该公司的研发工作。百度研究院下有三个研究实验室，专注于 AI、大数据和深度学习。百度 AI 团队有 1300 多名研究员，其 AI 平台是百度大脑（Baidu Brain），并开源了机器学习平台 PaddlePaddle。百度的开源基准测试工具 DeepBench 可用于评估跨平台的深度学习性能。
百度的优势
吴恩达说，百度的优势之一是其在深度学习和语音识别方面的经验，以及百度搜索引擎带来的巨大的数据量。吴恩达解释说：“百度是世界上少数几家能够得到大量数据的公司，现在 AI 的领先优势转向了高性能的计算。”称百度是世界上最先建立深度学习处理器的公司之一。
分析公司 Forrester 认为百度是 AI 市场不容忽视的强大参与者，特别是其公共云平台具有强大的竞争力。Forrester 分析师 Charlie Dai 说：“作为中国 PaaS（Platform As A Service） 的最先参与者，百度云扩展了许多应用服务以支持更多语言，提供多种基础架构服务。百度云也具有基本的存储服务，提供BI分析服务和具有设备认证等功能的loT服务。百度云在机器学习方面的产品路线图相当强大，也有为优化其大数据服务组合的数据分析服务和其他loT服务。”
百度的潜在劣势
虽然百度在中国是领先的科技公司，但在美国，除了技术界人士，很少人知道百度。分析公司 Moor Insights & Strategy 的首席分析师 Patrick Moorhead 认为，百度在中国之外的低存在感是其最大劣势之一。
Forrester 的 Dai 补充道：“百度在机器学习领域拥有相当深厚的知识、经验和人才储备，但该公司需要更好的市场战略来加速其生态系统的扩张，特别是在企业空间里的扩张。”最近有关百度的负面新闻使该公司形象受损，也是潜在的劣势。
自动驾驶汽车
2015年12月，百度成立了自动驾驶汽车研发部，使用自己的深度学习算法 Baidu AutoBrain。该公司在今年1月开始内部测试自动驾驶汽车，10月份进行了一次公开测试，用一支18辆全电动无人车组成的车队运载200多名乘客行驶了3.16公里。该公司计划在2018年公开推出自动驾驶汽车，到2021年实现批量生产。
此外，百度还与英伟达合作，为其他汽车制造商创建基于AI的自动化汽车平台。英伟达汽车业务高级总监 Danny Shapiro 说：“英伟达和百度在AI领域已有悠久的合作历史，百度吴恩达等研究人员已使用GPU取得了一些关键的突破，使得现在AI成为热潮。在利用AI使社会更美好方面，百度和英伟达的目标一致，我认为我们的合作能实现更多的未来图景。”
安全和伦理
吴恩达说，AI和机器学习的安全和伦理问题是百度重视的问题，因为未来将没有哪个行业完全与AI无关。“我认为AI是新的超级力量，”吴恩达说：“AI是新的电力。两百年前还没有电这样的东西，没有电话，没有电灯，也没有冰箱。大约100年前电开始出现，就像我们今天看到的一样，电不止改变一个行业，而是颠覆了几乎所有行业。我们认为AI也将如此重塑一个又一个行业。在这个意义上，AI就是超级力量。我们的团队对我们利用AI所做的事情，以及所不做的事情都是深思熟虑过的，我认为一些对人工智能的恐惧、对毁灭性机器人的想象都是过于夸张的。”
吴恩达说他相信AI能够解决世界上现存的一些问题。例如，自动驾驶汽车将能够拯救数百万人的生命，AI支持的更准确的医疗数据分析同样能够拯救数百万人的生命，而语音识别的应用将使人们的生活更轻松。
吴恩达对AI的未来相当乐观。他说：“我们很多人仍然不得不做一些毫无挑战性的重复工作，我认为AI将从心理上减轻人们的痛苦，就像工业革命把我们从繁重的体力劳动中解放了出来。”
选择 IBM 作为你的机器学习平台
（文／Conner Forrest）以下讲述的是IBM 如何在人工智能上开始的，他们如何把这一技术带到了你的业务或者组织台面上。
虽然几乎所有的科技巨头都在人工智能和机器学习上下了很大的力气，但是几乎没有哪家公司能够获得像IBM一样的关注度。2011年赢得Jeopardy 比赛后，IBM Watson就已经成为了认知计算和 AI 的代名词。
在输给Watson后，Jeopardy 前冠军 Ken Jennnings 曾写过一句著名的话：”我，作为个人，欢迎我们的新计算机统治者“。忽然之间，Watson变成了一个王者的名字，关于AI 能做什么，激起了大量的讨论。
虽然Watson 是 IBM AI 道路上的一个重要组成部分，但它其实只是整盘棋的一颗棋子。下面是关于IBM AI 更广泛图景的一次深入介绍，如果 IBM 可以成为正确的AI方案提供商，那么他们也许可以重新定义商业。
历史
IBM 研究院作为整个公司的研究部门，最早要追溯到1945年，当时，IBM 在哥伦比亚大学建立了Watson 科学计算实验室。根据其官网的介绍，IBM 从20世纪50年代年开始研究AI。当时，IBM 一位名叫Arthur Samuel 的雇员写了一个自学习的程序，用来下西洋棋。这可能是AI 和机器学习的先锋之作。
20世纪70年代，IBM 开发了公司的第一个机器人，并在80年代凭借 IBM RS1 进一步深入这一领域。20世界90年代，IBM 研究员 Gerry Tesauro 使用强化学习（RL）开发了一个可以自学习的西洋双陆棋戏程序。随后，1997年，IBM 的深蓝击败了国际象棋世界冠军Garry Kasparov，一战成名。
IBM 真正的人工智能产品研发更多是最近才开始的。Forrester Research 的 Mike Gualtieri 说，IBM 的人工智能解决方案之路开启于2009年，当年，IBM 收购了两家公司 ILOG 和 SPSS。Gualtieri 说， ILOG 是一个业务规则引擎，也就是曾经的专家系统，而SPSS提供的是高级的数据分析。这两比收购都为 IBM的商业AI 解决方案开发提供了帮助。今天，IBM的AI创新主要都围绕Watson 平台在进行。数据分析、机器学习、数据搜索和发现以及对话工具比如聊天机器人都有相应的Watson解决方案。
愿景
IBM把AI看成是“增强智能”，IBM研究院认知计算副总裁兼首席科学官Guru Banavar说。为了进一步理解这个概念，451 Research 分析师尼克·帕特森（Nick Patience）将增强的智力解释为“人工智能 ——特别是机器学习——是人类的力量乘数”。
Banavar表示，目前，有数以千计的工程师在Watson平台上工作。在较高水平的层次上，团队分成两个非常独特的阵营。其中一个着眼于“非常具体，商业开发和部署”，周期通常是周，月或季度。
“然后，另一方面，我们有许多人正在研究先进的新技术，甚至一些数学家也正在为这些发明开发潜在的技术，” Banavar 说。 在Watson赢得Jeopardy之后，Banavar说，IBM的团队专注于为特定客户或行业利基构建定制系统。然而，他们最近不得不做出一个目的明确的战略决定，从这个模型转向聚焦API。
Banavar说，IBM意识到，既有的战略不可能让他们构建想要的所有应用程序。因此，他们将一些功能转变为一个带有开放API的平台，“其目的是吸引和培养一个更大的开发者生态系统，进而构建许多IBM不能自己构建的应用程序，”Banavar说。 这些API正被用于零售，金融，法律，甚至虚拟足球游戏等领域。但医疗保健是沃森解决方案的主要焦点之一。 “我可以看到一个愿景：每个医院，每个临床组，都有这个Watson服务。它变得与X射线一样重要，和核磁共振成像一样是必不可少的，”Gualtieri说。 “所以，我认为这是他们的愿景，他们投入了很多。
优势
要了解IBM是否适合您的组织，你必须权衡公司的需求与IBM的优势。在技术方面，Banavar说，这些优势从Watson的语言能力开始。 “Watson有图像处理能力，语音处理能力，定期数值数据分析能力等等 ，我们有全面的覆盖，”Banavar说。 “但是，如果你问我什么是真正独特的，也许是最先进的。是语言处理。 谈到业务时，IBM的AI实力来自三个关键要素：IBM研究，收购实力和顾问。
IBM 研究院可能不会总是产生突破，但它确实给公司带来了独特的优势，Gualtieri说。 “这样做的优势是，世界上最大的公司 ，也就是IBM的目标客户，都想要这个优势，”他补充说。
收购合适的公司以扩大IBM的产品组合的能力是关键， Banavar指出，该公司还利用开源库和工具包来利用神经网络，字嵌入等新技术。 除了研究实力和收购预算之外，IBM还有一个庞大的顾问网络。据Patience说，这是关键，“因为很多早期的机器学习机会都涉及采用把技术，例如机器学习算法，转变为增强的业务流程和应用程序。在这些方面， IBM的理解很好。
挑战
IBM面临的最大挑战之一是处理好人们对认知计算和AI等术语的期望。由于Watson面向公众的性质，特别是在它在Jeopardy获胜之后，这种情况更加复杂。 “每个人都认为我们正处在星际迷航的边缘，就像下周就会实现一样，”Gualtieri说。所以，IBM必须对AI的未来有一个宏伟和变革性的愿景，同时他们还必须保持消费者的期望，以便客户不后悔前进，Gualtieri指出。
关于安全和伦理问题，许多人都会同意Gualtieri的观点，那就是：技术“甚至还没有法子到安全和伦理问题值得人担心的地步“。然而，Banavar说，道德挑战仍然是IBM团队必须考虑的问题。
巴纳瓦尔说，必须解决的第一个关键问题是可解释性。例如，如果医生或财务顾问使用Watson做出决定，他们必须能够理解为什么Watson选择了一个特定的解决方案或一组选项。 另一个伦理考虑是偏见。使用机器学习系统，模型是用训练数据构建的，但是数据必须忠实地代表你想要建模的东西，它可能有偏见，Banavar说。因此，选择适当的训练数据集是最重要的伦理决定。
作者丨黄东旭
编辑丨Tina
“
「一切都会运行在云端」。云时代早已来临，本文着眼于顶级云服务商云服务商的云数据库方案背后的架构，以及笔者最近观察到的一些对于云数据库有意义的工业界的相关技术的进展，希望读者能有所收获。
现在越来越多的业务从自己维护基础设施转移到公有（或者私有）云上， 带来的好处也是无需赘述的，极大降低了 IaaS 层的运维成本，对于数据库层面来说的，以往需要很强的 DBA 背景才能搞定弹性扩容高可用什么的高级动作，现在大多数云服务基本都或多或少提供了类似的服务。
Amazon RDS
其实说到公有云上的云数据库，应该最早 Amazon 的 RDS，最早应该是在 2009 年发布的，Amazon RDS 的架构类似在底层的数据库上构建了一个中间层（从架构上来看，阿里云 RDS，UCloud RDS 等其他云的 RDS 服务基本是大同小异，比拼的是功能多样性和实现的细节）。
这个中间层负责路由客户端的 SQL 请求发往实际的数据库存储节点，因为将业务端的请求通过中间层代理，所以可以对底层的数据库实例进行很多运维工作，比如备份，迁移到磁盘更大或者 IO 更空闲的物理机等。这些工作因为隐藏在中间层后边，业务层可以做到基本没有感知，另外这个中间路由层基本只是简单的转发请求，所以底层可以连接各种类型的数据库。
所以一般来说，RDS 基本都会支持 MySQL / SQLServer / MariaDB / PostgreSQL 等流行的数据库，对兼容性基本没有损失，而且在这个 Proxy 层设计良好的情况下，对性能的损失是比较小的。另外有一层中间层隔离底层的资源池，对于资源的利用和调度上可以做不少事情。
简单举个例子，比如有一些不那么活跃的 RDS 实例可以调度在一起共用物理机，比如需要在线扩容只需要将副本建立在更大磁盘的机器上，在 Proxy 层将请求重新定向即可，比如定期的数据备份可以放到 S3 上，这些一切都对用户可以做到透明。
但是这样的架构缺点也同样明显：本质上还是一个单机主从的架构，对于超过最大配置物理机的容量，CPU 负载，IO 的场景就束手无策了。随着很多业务的数据量并发量的增长，尤其是移动互联网的发展，无限的可扩展性成为了一个很重要需求。当然对于绝大多数数据量要求没那么大，单实例没有高并发访问的库来说，RDS 仍然是很适合的。
Amazon DynamoDB
对于刚才提到的水平扩展问题，一些用户实在痛的不行，甚至能接受放弃掉关系模型和 SQL。比如一些互联网应用业务模型比较简单，但是并发量和数据量巨大，应对这种情况，Amazon 开发了 DynamoDB，并于 2012 年初发布 DynamoDB 的云服务。其实 Dynamo 的论文早在 2007 年就在 SOSP 发表，这篇有历史意义的论文直接引爆了 NoSQL 运动，让大家觉得原来数据库还能这么搞。
Dynamo 对外主打的特点是水平扩展能力和通过多副本实现（3副本）的高可用，另外在 API 的设计上可以支持最终一致性读取和强一致性读取，最终一致性读取能提升读的吞吐量。
但是请注意，DynamoDB 虽然有强一致读，但是这里的强一致性并不是传统我们在数据库里说的 ACID 的 C，而且由于没有时序的概念（只有 vector clock），对于冲突的处理只能交给客户端，Dynamo 并不支持事务。不过对于一些特定的业务场景来说，扩展能力和可用性是最重要的，不仅仅是容量，还有集群的吞吐。
阿里云 DRDS
但是那些 RDS 用户的数据量也是在持续增长的，对于云服务提供商来说不能眼睁睁的看着这些 RDS 用户数据量一大就走掉或者自己维护数据库集群。因为也不是谁都能彻底重构代码到 NoSQL 之上，并且分库分表其实对于业务开发者来说是一个很痛苦的事情，在痛苦中往往是蕴含着商业机会的。
比如对于 RDS 的扩展方案，我介绍两个比较典型的：第一个是阿里云的 DRDS （不过现在好像从阿里云的产品列表里拿掉了？），DRDS 其实思路很简单，就是比 RDS 多一小步，在刚才提到的 RDS 的中间层中加入用户配置的路由策略，比如用户可以指定某个表的某些列作为 sharding key 根据一定规则路由到特定的实例，也可以垂直的配置分库的策略。
其实 DRDS 的前身就是淘宝的 TDDL，只不过原来 TDDL 是做在 JDBC 层，现在将 TDDL 做进了 Proxy 层（有点像把 TDDL 塞到 Cobar 的感觉）。这样的好处是，将应用层分库分表的工作封装起来了，但是本质上仍然是一个中间件的方案，尽管能对简单的业务做到一定程度的 SQL 兼容。
对于一些复杂查询，多维度查询，跨 Shard 事务支持都是有限了。毕竟中间路由层对 SQL 的理解有限，至于更换 Sharding key 、DDL、备份也是很麻烦的事情。从 Youtube 开源的中间件 Vitess 的实现和复杂程度来看甚至并不比实现一个数据库简单，但是兼容性却并没有重新写一个数据库来得好。
Amazon Aurora
后来时间来到了 2015 年，Amazon 走了另外一条路。在 2015 年，Amazon Aurora 发布。Aurora 的资料在公网上并不多，Aurora 提供了 5x 于单机 MySQL 5.6 的读吞吐能力，不过最大也就扩展到 15 个副本，副本越多对写吞吐影响越大，因为只有一个 Primary Instance 能提供写入服务，单个副本最大支持容量 64T，而且支持高可用以及弹性的扩展。
值得一提的是 Aurora 的兼容性。其实做数据库的都知道，兼容性是一个很难解决的问题，可能实现上很小的差异就会让用户的迁移成本变得很大，这也是为什么中间件和分库分表的方案如此反人类的原因，我们大多都在追求用户平滑的迁移体验。
Aurora 另辟蹊径，由于公开的资料不多，我猜想 Aurora 在 MySQL 前端之下实现了一个基于 InnoDB 的分布式共享存储层（https://www.percona.com/blog/2015/11/16/amazon-aurora-looking-deeper/）。对于读实例来说是很好水平扩展的，这样就将 workload 均摊在前端的各个 MySQL 实例上，有点类似 Oracle RAC 那样的 Share everything 的架构。
这个架构的好处相对中间件的方案很明显，兼容性更强，因为还是复用了 MySQL 的 SQL 解析器。优化器，业务层即使有复杂查询也没关系，因为连接的就是 MySQL。
但是也正是由于这个原因，在节点更多，数据量更大的情况下，查询并不能利用集群的计算能力（对于很多复杂查询来说，瓶颈出现在 CPU 上），而且 MySQL 的 SQL 优化器能力一直是 MySQL 的弱项，而且对于大数据量的查询的 SQL 引擎的设计是和单机有天壤之别的。一个简单的例子，分布式 Query Engine 比如 SparkSQL / Presto / Impala 的设计肯定和单机的 SQL 优化器完全不同，更像是一个分布式计算框架。
所以我认为 Aurora 是一个在数据量不太大的情况下（有容量上限），对简单查询的读性能优化的方案，另外兼容性比中间件的方案好得多。但是缺点是对于大数据量，复杂查询的支持还是比较弱，另外对于写入性能 Aurora 其实没有做太多优化（单点写入），如果写入上出现瓶颈，仍然需要在业务层做水平或者竖直拆分。
Google Cloud BigTable
Google 作为大数据的祖宗一样的存在，对于云真是错过了一波又一波：虚拟化错过一波让 VMWare 和 Docker 抢先了（Google 早在十年前就开始容器的方案，要知道容器赖以生存的 cgroups 的 patch 就是 Google 提交的）；云服务错过一波让 Amazon 抢先了（Google App Engine 真是可惜）：大数据存储错过一波让开源的 Hadoop 拿下了事实标准，以至于我觉得 Google Cloud BigTable 服务中兼容 Hadoop HBase API 的决定，当时实现这些 Hadoop API for BigTable 的工程师心中应该是滴血的
不过在被 Amazon / Docker / Hadoop 刺激到以后，Google 终于意识到社区和云化的力量，开始对 Google Cloud 输出 Google 内部各种牛逼的基础设施，2015 年终于在 Google Cloud Platform 上正式亮相。对于 BigTable 的架构相信大多数分布式存储系统工程师都比较了解，毕竟 BigTable 的论文也是和 Amazon Dynamo 一样是必读的经典，我就不赘述了。
BigTable 云服务的 API 和 HBase 兼容，所以也是 {Key : 二维表格结构}，由于在 Tablet Server 这个层次还是一个主从的结构，对一个 Tablet 的读写默认都只能通过 Tablet Master 进行，这样使得 BigTable 是一个强一致的系统。这里的强一致指的是对于单 Key 的写入，如果服务端返回成功，接下来发生的读取，都能是最新的值。
由于 BigTable 仍然不支持 ACID 事务，所以这里的强一致只是对于单 Key 的操作而言的。对于水平扩展能力来说， BigTable 其实并没有什么限制，文档里很嚣张的号称 Incredible scalability，但是 BigTable 并没有提供跨数据中心（Zone）高可用和跨 Zone 访问的能力。
也就是说，一个 BigTable 集群只能部署在一个数据中心内部。这其实看得出 BigTable 在 Google 内部的定位，就是一个高性能低延迟的分布式存储服务，如果需要做跨 Zone 高可用需要业务层自己做复制在两个 Zone 之间同步，构建一个镜像的 BigTable 集群。
其实 Google 很多业务在 MegaStore 和 Spanner 出来之前，就是这么搞的。对于 BigTable 来说，如果需要搞跨数据中心高可用，强一致，还要保证低延迟那是不太可能的，也不符合 BigTable 的定位。另外值得吐槽的是 BigTable 团队发过一个 Blog ：
（https://cloudplatform.googleblog.com/2015/05/introducing-Google-Cloud-Bigtable.html）
里面把 HBase 的延迟黑得够呛，一个 .99 的响应延迟 6 ms, HBase 280ms。其实看平均响应延迟的差距不会那么大….BigTable 由于是 C++ 写的，优势就是延迟是相当平稳的。但是据我所知 HBase 社区也在做很多工作将 GC 带来的影响降到最小，比如 off-heap 等优化做完以后，HBase 的延迟表现会好一些。
Google Cloud Datastore
在 2011 年，Google 发表了 Megastore 的论文，第一次描述了一个支持跨数据中心高可用 + 可以水平扩展 + 支持 ACID 事务语义的分布式存储系统。 Google Megastore 构建在 BigTable 之上，不同数据中心之间通过 Paxos 同步，数据按照 Entity Group 来进行分片。Entity Group 本身跨数据中心使用 Paxos 复制，跨 Entity Group 的 ACID 事务需要走两阶段的提交，实现了 Timestamp-based 的 MVCC。
不过也正是因为 Timstamp 的分配需要走一遍 Paxos，另外不同 Entity Groups 之间的 2PC 通信需要通过一个队列来进行异步的通信，所以实际的 Megastore 的 2PC 的延迟是比较大的，论文也提到大多数的写请求的平均响应延迟是 100~400ms 左右。据 Google 内部的朋友提到过，Megastore 用起来是挺慢的，秒级别的延迟也是常有的事情…
作为应该是 Google 内部第一个支持 ACID 事务和 SQL 的分布式数据库，还是有大量的应用跑在 Megastore 上，主要是用 SQL 和事务写程序确实能轻松得多。为什么说那么多 Megastore 的事情呢？因为 Google Cloud Datastore 的后端就是 Megastore…
其实 Cloud Datastore 在 2011 年就已经在 Google App Engine 中上线，也就是当年的 Data Engine 的 High Replication Datastore，现在改了个名字叫 Cloud Datastore，当时不知道背后原来就是大名鼎鼎的 Megastore 实在是失敬。
虽然功能看上去很牛，又是支持高可用，又支持 ACID，还支持 SQL（只不过是 Google 精简版的 GQL）但是从 Megastore 的原理上来看延迟是非常大的，另外 Cloud Datastore 提供的接口是一套类似的 ORM 的 SDK，对业务仍然是有一定的侵入性。
Google Spanner
虽然 Megastore 慢，但是架不住好用。在 Spanner 论文中提到，2012 年大概已经有 300+ 的业务跑在 Megastore 上，在越来越多的业务在 BigTable 上造 ACID Transaction 实现的轮子后，Google 实在受不了了，开始造一个大轮子 Spanner，项目的野心巨大，和 Megastore 一样，ACID 事务 + 水平扩展 + SQL 支持。
但是和 Megastore 不一样的是，Spanner 没有选择在 BigTable 之上构建事务层，而是直接在 Google 的第二代分布式文件系统 Colossus 之上开始构建 Paxos-replicated tablet。
另外不像 Megastore 实现事务那样通过各个协调者通过 Paxos 来决定事务的 timestamp，而是引入了硬件，也就是 GPS 时钟和原子钟组成的 TrueTime API 来实现事务。这样一来，不同数据中心发起的事务就不需要跨数据中心协调时间戳，而是直接通过本地数据中心的 TrueTime API 来分配，这样延迟就降低了很多。
Spanner 近乎完美的一个分布式存储，在 Google 内部也是的 BigTable 的互补，想做跨数据中心高可用和强一致和事务的话，用 Spanner，代价是可能牺牲一点延迟，但是并没有Megastore 牺牲那么多；想高性能（低延迟）的话，用 BigTable。
Google Spanner 目前没有在 Google Cloud Platform 中提供服务，但是看趋势简直是一定的事情，至少作为 Cloud Datastore 的下一代是一定的。另外一方面来看 Google 仍然没有办法将 Spanner 开源，原因和 BigTable 一样，底层依赖了 Colossus 和一堆 Google 内部的组件，另外比 BigTable 更困难的是，TrueTime 是一套硬件…
所以在 12 年底发布 Spanner 的论文后，社区也有开源的实现，比如目前比较成熟的 TiDB 和 CockroachDB，一会提到社区的云数据库实现的时候会介绍。Spanner 的接口比 BigTable 稍微丰富一些，支持了它称之为 Semi-relational 的表结构，可以像关系型数据库那样进行 DDL，虽然仍然要指定每行的 primary key，但是比简单的 kv 还是好太多。
Google F1
在 Spanner 项目开始的同时，Google 启动了另外一个和 Spanner 配套使用的分布式 SQL 引擎的项目 F1，底层有那么一个强一致高性能的 Spanner，那么就可以在上层尝试将 OLTP 和部分的 OLAP 打通。F1 其实论文题目说是一个数据库，但是它并不存储数据，数据都在 Spanner 上，它只是一个分布式查询引擎，底层依赖 Spanner 提供的事务接口，将用户的 SQL 请求翻译成分布式执行计划。
Google F1 提供了一种可能性，这是在其他的数据库中一直没有实现过的：OLTP 与 OLAP 融合的可能性。因为 Google F1 设计目标是给 Google 的广告系统使用，广告投放系统这类系统一是对于一致性要求很高，压力也很大，是典型的 OLTP 场景；第二是可能会有很多复杂的广告投放效果评估的查询，而且这类的查询越是实时越好，这又有点实时 OLAP 的意思。
传统的做法是 OLTP 的数据库将数据每隔一段时间同步一份到数据仓库中，在数据仓库中离线的进行计算，稍微好点的使用一些流式计算框架进行实时计算。第一种使用数据仓库的方案，实时性是比较差的，倒腾数据是很麻烦的事情；至于使用流式计算框架的方案，一是灵活性不好，很多查询逻辑需要提前写好，没法做很多 Ad-hoc 的事情，另外因为两边是异构的存储，导致 ETL 也是很麻烦的工作。
F1 其实依靠 Spanner 的 ACID 事务和 MVCC 的特性实现了 100% 的 OLTP，并且自身作为一个分布式 SQL 引擎，可以利用集群的计算资源实现分布式的 OLAP 查询。这带来的好处就是并不需要额外在设置一个数据仓库进行数据分析，而是直接在同一个数据库里实时分析，另外由于 Spanner 的 MVCC 和多副本带来的 Lock-free snapshot read 的特性，这类 OLAP 查询并不会影响正常 OLTP 的操作。
对于 OLTP 来说，瓶颈经常出现在 IO 上。对于 OLAP 来说，瓶颈反而经常出现在 CPU 也就是计算上。其实看上去是能融合起来，提升整个集群的资源利用率，这也是我看好 Google F1 + Spanner 这个组合的原因，未来的数据库可能会融合数据仓库，提供更完整且更实时的体验。
(其实这个下面的 GFS 不太准确，现在应该是 Colossus)
Open source cloud-native database
2016 年在硅谷突然有个新词火了起来 GIFEE，Google Infrastructure For Everyone Else，大家意识到好像随着新一代的开源基础软件的繁荣发展，原来在 Google 内部的基础设施已经有很多高质量的开源实现。
比如容器方面有 Docker，调度器方面 Google 主动开源的 Borg 的第二代 Kubernetes，传统的 BigTable 和 GFS 社区还有虽然屎但是还是能凑合用的 Hadoop，而且很多大厂觉得 Hadoop 屎的都基本自己都造了类似的轮子……
更别说最近 Google 开源上瘾，Kubernetes 就不提了，从大热的 Tensorflow 到相对冷门但是我个人认为意义重大的 Apache Beam（Google Cloud Dataflow 的基础），基本能独立开源的都在积极的拥抱社区。
这就造成了社区与 Google 内部差距正在缩小，但是目前来说，Spanner 和 F1 并不是那么容易造的。就算抛开 TrueTime 的硬件不提，实现一个稳定的 Multi-Paxos 都不是容易的事情，另外分布式 SQL 优化器这种事情也是有很高技术门槛的，另外就算造出来了，测试的复杂度也一点不比实现的复杂度低（可以参考 PingCAP 的分布式测试哲学的几篇分享）。
目前从全球范围内来看，我认为开源世界只有两个团队：一个 PingCAP 的 TiDB，一个 CockroachLabs 的 CockroachDB 是有足够的技术能力和视野能将 Spanner 的开源实现造出来的。目前 TiDB 已经 RC1 并有不少使用者在生产环境使用，比 CockroachDB 的成熟度稍好，架构上更接近正统的 F1 above Spanner 的架构。CockroachDB 的成熟度稍微落后一些，并且协议选择 PostgreSQL，TiDB 选择的是 MySQL 的协议兼容。
而且从 TiDB 的子项目 TiKV 中，我们看到了新一代分布式 KV 的雏形，RocksDB + Multi-Raft 不依赖第三方分布式文件系统（DFS）提供水平扩展能力，正在成为新一代分布式 KV 存储标准架构。另外也很欣喜的看到竟然是由一个国内团队发起并维护的这样级别的开源项目，即使放到硅谷也是顶级的设计和实现，从 Github 的活跃度和使用的工具及运营社区的流程上来看，很难看出是一个国内团队。
Kubernetes + Operator
刚才提到了一个词 Cloud-Native，其实这个词还没有准确的定义，不过我的理解是应用开发者和物理设施隔离，也就是业务层不需要再去关心存储的容量性能等等一切都可以透明水平扩展，集群高度自动化乃至支持自我修复。
对于一个大规模的分布式存储系统来说人工是很难介入其中的，比如一个上千个节点的分布式系统，几乎每天都可能有各种各样的节点故障，瞬时网络抖动甚至整个数据中心直接挂掉，人工去做数据迁移，数据恢复几乎是不可能的事情。
很多人非常看好 Docker，认为它改变了运维和软件部署方式，但是我认为更有意义的是 Kubernetes。调度器才是 Cloud-native 架构的核心，容器只是一个载体而已并不重要，Kubernetes 相当于是一个分布式的操作系统，物理层是整个数据中心，也就是 DCOS，这也是我们在 Kubernetes 上下重注的原因，我认为大规模分布式数据库未来不可能脱离 DCOS。
不过 Kubernetes 上对于有状态的服务编排是一件比较头疼的事情。而一般的分布式系统的特点，他不仅每个节点都有存储的数据，而且他还要根据用户需要做扩容，缩容。
当程序更新时要可以做到不停服务的滚动升级，当遇到数据负载不均衡情况下系统要做 Rebalance，同时为了保证高可用性，每个节点的数据会有多个副本，当单个节点遇到故障，还需要自动恢复总的副本数。而这些对于 Kubernetes 上的编排一个分布式系统来说都是非常有挑战的。
Kubernetes 在 1.3 版本推出了 Petset ，现在已经改名叫 StatefulSet， 核心思想是给 Pod 赋予身份，并且建立和维护 Pod 和 存储之间的联系。当 Pod 可能被调度的时候，对应的 Persistent Volume 能够跟随他绑定。但是它并没有完全解决我们的问题，PS 仍然需要依赖于 Persistent Volume。
目前 Kubernetes 的 Persistent Volume 只提供了基于共享存储，分布式文件系统或者 NFS 的实现，还没有提供 Local Storage 的支持，而且 Petset 本身还处于 Alpha 版本阶段，我们还在观望。
不过除了 Kubernetes 官方社区还是有其他人在尝试，我们欣喜的看到，就在不久之前，CoreOS 提出了一个新的扩展 Kubernetes 的新方法和思路。CoreOS 为 Kubernetes 增加了一个新成员，叫作 Operator。
Operator 其实是一种对 Controller 的扩展，具体的实现由于篇幅的原因我就不罗嗦了，简单来说是一个让 Kubernetes 调度带状态的存储服务的方案，CoreOS 官方给出了一个 Etcd-cluster 的备份和滚动升级的 operator 实现，我们也在开发 TiDB 的 operator，感兴趣的可以关注我们的 Github 了解最新的进展。
黄东旭，PingCAP 联合创始人/CTO，资深 infrastructure 工程师，擅长分布式存储系统的设计与实现，开源狂热分子，著名的开源分布式缓存服务 Codis 的作者，对于开源文化和技术社区建设有独到的理解。