立下“去 O”Flag 的 AWS，悄悄修炼了哪些内功？

AWS re:Invent 2018 大会上，AWS 首席执行执行官 Andy Jassy 表示到 2019 年底，亚马逊将全面放弃使用 Oracle 数据库，97％的“关键任务数据库”将运行在亚马逊自己的数据库服务上。

如今，2019 年已经过去了四分之一，亚马逊的“去 O”进程如何了？近日，笔者有幸采访到了 AWS 数据库服务总经理和 AWS Amazon Redshift 总经理，并向他们进行了求证：亚马逊整个“去 O”进展顺利，可以如期完成。

据悉，亚马逊所有的这些数据库都将迁移到 Aurora、Redshift 和 DynamoDB 这三种类型的数据库上，其中 OLTP（交易型）迁移到 Aurora，数据仓库型迁移到 Redshift。

亚马逊去 Oracle 的想法可以追溯到 5 年前，当时亚马逊的部分核心购物业务还依赖 Oracle 技术，其自身的数据库技术暂时还无法规模化地满足亚马逊的性能需求。那么，时至今日，为了“去 O”，AWS 悄悄修炼了哪些内功呢？

AWS 的数据库服务

2015 年 AWS 数据服务的相关功能只有 100 个，2018 年攀升到 325 个。

据悉，从 2015 年开始算起，AWS 已经总计发布了 785 个新的数据相关服务，包括数据移动、数据分析等数据服务，关系型、键值型、文件型、内存型、图谱型、时间序列、总帐类型等数据库服务，以及类似于商业洞察、智能洞察等一系列服务。

以 Amazon Aurora 为例，Aurora 是 AWS 公司历史上增长速度最快的一款服务，是兼容 MySQL 和 PostgreSQL 的关系型数据库，其速度和可用性可与 Oracle 等商业数据库产品相媲美，而成本只有商业数据库的 1/10。

而 Redshift 是 AWS 2012 年推出的、业界第一款云端数据仓库的云服务，2018 年一年，AWS 围绕 Redshift 推出了 220 个新功能，其中 90%都是基于客户需求开发的。

为什么会推出这么多数据服务呢？AWS 表示是：“为了满足客户需求”。那么客户使用数据服务到底想要达到什么目的？

• 第一，希望能够从数据中获得洞见；

• 第二，希望能够快速打造云端的全新应用；

• 第三，希望能够把既有的应用直接搬运到云端。

AWS 的迁移服务

对于客户来说，数据库迁移服务也是很重要的功能。目前 AWS 的数据库迁移服务主要有两类：一是将本地数据库迁移到云端，二是实现将一种类型的数据库迁移到另一种数据库。无论是哪种迁移，整个过程中都可以达到零宕机时间。

据 AWS 方面介绍：“目前通过数据库迁移服务 DMS 已经完成了超十万个数据库的迁移”。

AWS 的通常做法是将关系型数据库迁移到 Auraro 和 RDS，而非关系型的数据库迁移到 DynamoDB，数据仓库迁移到 Redshift，Hadoop 和 Spark 集群可以迁移到 Amazon EMR，运营、分析的可以迁移到 Amazon Elasticsearch Service，BI 型的应用可以迁移到 Amazon QuickSight。

为什么我们要从本地数据库迁移到云数据库呢？一言以蔽之，传统数据库无法满足我们的需求了。

举个例子，之前企业如果要进行数据分析，通常做法是从传统的数据仓库厂商中购买大型的数据仓库，这类产品能够处理的数量级通常是 GB 级和 TB 级，PB 级数据无法处理，而 TB 级单位的分析成本要达到一万到五万美元。即使是付出了这样的成本投入，也不能支持所有数据的分析，可能只有 10%的数据才能得到分析。而 AWS 的做法是先将数据导入到数据湖中，然后在数据湖之上提供各式各样的数据库服务来进行数据分析。

除此之外，在传统的企业 IT 架构中无法弄明白企业内部的有用数据占比，而在云端可以很轻松的启动多项数据分析作业。另外，传统企业中要做数据分析，需要专门的数据库技术人才去做数据处理，而在云上，非数据库技术专业人员也可以使用数据库服务。

• 根据不同的使用场景提供定制化解决方案；

• 针对数据服务成本进行经济性的分析，实现成本优化；

• 实现所有数据服务的可伸缩性。

AWS 的云数据库关注点

无论是哪一种技术，在生产环境和落地应用中，其关注点都应该与客户的关注点保持一致。AWS 方表示：“我们得到的用户反馈是，他们最关心云数据库的安全性、灵活性和可扩展性。”

而 AWS 围绕用户需求在数据库方面做的创新主要有两点：

• 帮助客户以更容易的方式迁移到云端；

• 帮助客户以更好的方式开发现代化应用；

例如，汇总打包数据库支撑管理的服务，来完成数据库的自我调优和自我运维管理，以实现可扩展性和可伸缩性；当数据从数据库汇聚到数据湖时，治理、合规以及安全方面也需要作出一些创新。

去 Oracle 的难度到底在哪里？

很多人都将亚马逊去 Oracle 数据库冠以“商业博弈”的头衔，这里我们暂且不讨论商业方面的内容，只关注于去 Oracle 的技术。

从技术实施层面来讲，亚马逊去 Oracle 对 AWS 自身来说只是一个数据规模比较大的客户而已，与纳斯达克等客户无异，同样需要听取 CEO 和 CTO 的意见，在真正实施“去 O”之前，已经决定 Oracle 上的哪些应用应该如何解决。

整个“去 O”过程中，AWS 面临的最大困难是什么呢？AWS 专家称：“亚马逊数据库迁移的复杂程度在于不止需要做数据和数据库本身的迁移，同时还要做数据库上运行的应用迁移，而这些应用既有企业内部开发的也有 ISV 提供的，甚至有些应用的年代已经非常久远了，如何很好的支持它们，是我们面临的巨大挑战。”

以数据分析为例，该项目最大的难点在于亚马逊的要求不是简单的将原来 Oracle 上的数据分析功能搬到云上，他们要求更好的分析服务，且这种服务要能够顺应未来十年的技术发展变化。