丰富的线上&线下活动，深入探索云世界
做任务，得社区积分和周边
最真实的开发者用云体验
让每位学生受益于普惠算力
让创作激发创新
资深技术专家手把手带教
遇见技术追梦人
技术交流，直击现场
海量开发者使用工具、手册，免费下载
极速、全面、稳定、安全的开源镜像
开发手册、白皮书、案例集等实战精华
为开发者定制的Chrome浏览器插件
本文内容根据演讲嘉宾视频以及PPT整理而成，文末有直播全程的PDF下载链接。
首先为大家将介绍整个数据库市场分析与预测。根据Gartner公司的分析报告，2018年全球基础软件如虚拟化软件、操作系统、存储等的市场规模大约为2000亿美金，其中数据库占20%，大约为461亿美金。而中国的数据库市场规模大概为161亿人民币，但这一数字实际上因为各种原因被远远低估了。2018年数据库市场的增长率是18%，其中云数据库占比达到了22.75%，而Gartner预测在未来的2到3年内云数据库的占比可能会达到75%。在世界范围内，云数据库的领袖毫无疑问当然是亚马逊。亚马逊是最早在云数据库市场发力的厂商，也是目前做的最好的一家云厂商。而在AWS做云数据库之前，这个市场处于“None-Player”的状态，传统数据库市场的巨头是Microsoft、IBM、Oracle，而AWS未能跻身其中。但云数据库赛道为AWS带来了发展的机遇，其发展速度非常快，它的云原生数据库Aurora在2018年就达到了3亿美金的营收。
数据库已经发展了40年，可以说是一个传统又古老的领域。回顾数据库的发展历史，1980年到1990年属于商业起步阶段，此时Oracle、IBMDB2、Sybase以及SQLServer和Informix等开始出现。
1990年至2000年，开源数据库开始展露头角，出现了PostgreSQL和MySQL等。与此同时，出现了一些分析型数据库，因为之前出现的都是OLTP，而现在随着大量数据的出现，需要对于这些数据进行分析，因此出现了OLAP，而为了避免读写冲突，就需要建立分析型数据库系统，Teradata、SybaseIQ、Greenplum等就快速成长起来。
2000年到2010年期间，以谷歌为代表的互联网公司逐渐推出了NoSQL数据库。尤其是谷歌的GFS（GoogleFileSystem）、GoogleBigtable、GoogleMapReduce三大件。GoogleFileSystem解决了分布式文件系统问题，GoogleBigtable解决了分布式KV（Key-Value）存储的问题，GoogleMapReduce解决了在分布式文件系统和分布式KV存储上面如何做分布式计算和分析的问题。之所以产生了这三大件，是因为数据强一致性对系统的水平拓展以及海量数据爆发式增长的分析能力出现了断层。因此就需要解决这个问题，把这种数据的强一致性需求弱化，换来能够使用用分布式的集群做水平拓展处理。谷歌三大件在业界诞生以后，很快的衍生了一个新的领域叫NoSQL（NotOnlySQL），就是针对非结构化、半结构化的海量数据处理系统。现在也有很多很好的商业公司基于NoSQL发展，比如说文档数据（MongoDB）、缓存（Redis）等大家平常应用开发都会用到的NoSQL系统。
而在2010年以后，AWSAurora、Redshift、AzureSQLDatabase、GoogleSpanner以及阿里云的POLARDB和AnalyticDB等都发展起来了，它们的特点就是云原生、一体化分布式、多模和HTAP的能力。
总结而言，数据库的演进经历了从结构化数据在线处理到海量数据分析，从SQL+OLAP的RDBMS到ETL+OLAP的DataWarehouse和DataCube，再到今天异构多源的数据类型的发展历程。
如今，上云已经成为一种趋势。而在上云的过程中，数据库则被认为是云上非常重要的一环。因为云最开始提供的是IaaS，而随着各种智能化应用的兴起，数据库就成为了从IaaS到智能化应用连接的重要一环。
大家知道，数据库可以分为几类：
将数据库系统拆开来看，其核心模块包括应用接口、SQL接口、查询执行引擎、数据访问模块和存储引擎。其中，查询执行引擎进一步可以拆分为计划生成器、计划优化器和计划执行器；数据访问模块则可以分为事务处理、内存处理、安全管理以及文件和索引管理等模块；并且事务处理是最核心的模块，其中包括了崩溃恢复和并发控制；最底层的存储引擎则包括数据文件、索引文件和系统及元数据文件。
数据库查询分析处理过程是这样的：首先，通过SQL语句或者大数据系统的DataframeAPI将查询任务提交上来，之后经过SimbaParser进行处理，此时会有各种各样的执行方式，并生成Catalog和逻辑执行计划；之后对于逻辑执行计划进行优化，并生成物理执行计划；之后在借助系统的统计信息，如索引管理、内存管理来生成一个优化后的物理执行计划，再执行并生成最后结果或者RDD。
简单而言，数据库系统的架构就是持久化存储的数据按照DataPage的形式进行存储，这些数据块在查询访问的时候会被带到内存里面。系统中有内存池，每个内存池可以装载一个Page，此时的问题就是内存池的大小是有限的，如果数据存储非常大，需要进行优化。此外，还涉及到优化数据访问的问题，一般通过索引解决，主要是Hash索引和树形索引。
数据库系统最关键的挑战就是并行访问时的写写冲突和数据一致性问题。此外，还有读和写的冲突问题，比如在数据库里做批量写入的时候系统宕机，应该考虑如何让系统自动恢复。
为解决以上的问题，数据库系统提出了一个核心概念——事务。简单而言，事务就是一系列动作可以被看作一个整体，从用户视角来看事务是隔离运行的，一个用户的事务和另一个用户没有关系。如果系统出现异常，事务要么全部执行完毕，要么一个也没有被执行。这样引申出来事务的核心概念：原子性、一致性、隔离性、持久性。
传统架构依赖于高端硬件，每套数据库系统服务器少，架构相对简单，但无法支持新业务的扩展需求。而云计算机构的核心逻辑就是通过虚拟化技术带来池化资源。云原生数据库采用分布式数据库架构，实现大规模扩展，每套数据库系统横跨多台服务器和虚拟机，带来了全新的系统管理挑战。其中最核心的挑战就是如何实现弹性以及高可用，实现按需按量使用，使得资源高效利用。
在2005到2009年，当时阿里巴巴拥有亚太最大规模的OracleRAC集群；在2010年到2015年开始，使用开源数据库以及分库分表的技术来解决对于商业数据库的依赖；从2016年开始到现在，阿里巴巴都在自研数据库上发力，TP方面包括POLARDB和OceanBase，AP方面则有分析型数据库AnalyticDB。
随着云计算的发展，数据库的部署形式也发生了很大的变化。传统的数据都是部署在客户机房里面，与客户的机器绑定。而在云环境下，希望数据库能够在多种形态下部署，比如公有云、专有/私有云、混合云以及软硬件一体化独立部署，以及纯软件输出。
Oracle等数据库厂商也正在向着AWS的部署方式转型。
数据库系统另外的一个趋势就是多模。数据库系统的演进经历了从最早的关系型数据库OLTP到半结构化，再到分析型数据库OLAP等非结构化的数据库，再发展到如今的多模数据库。对于多模数据库而言，主要有两种维度，南向维度是数据库可以有多种存储港方式，北向维度是可以有多种查询接口和标准，而希望由同一套数据库引擎来支撑。
借助于机器学习、人工智能技术，希望能够与数据库内核进行结合，使得数据库能够更加自动化和智能化，实现自感知、自决策、自恢复和自优化。
未来，下一代的企业级数据库一定要结合软硬件一体化的设计理念，而不能把软件和硬件隔开，只有将软硬件结合在一起，才能把系统的优势发挥出来。
TP和AP的关键区别就是行存储和列存储，前者按照行将数据存储起来，其优点是能够高效简易访问一整条记录来处理更新，缺点是需要访问和读取不需要的数据信息；后者的优点是只需要读取所需数据，缺点是更新一条记录不同属性时需要多次访问。
HTAP希望能够将行存和列存结合起来，在一套系统里面实现行列混存，但是这样也会遇到很多挑战，最核心的就是数据一致性的挑战。
传统数据库架构采用单节点架构，其有点是部署和开发简单，缺点就是非常难于做弹性缩扩容。云原生架构是基于RDMA等网路实现分布式共享存储，使得上层应用看起来存储是一份，在上层实现存储与计算分离，使得存储和计算可以实现独立的缩扩容，这就带来了极致的弹性，也为云原生带来了很好的管理方式，如阿里云的POLARDB、AWS的Aurora等都是基于这样架构。
还有另外一种就是分布式架构，其对于数据库进行分库分片，其特点是水平扩展能力特别强，当数据量变大、并发量变高的时候只需要增加节点即可，其缺点是如果要求不改动上层业务逻辑，就必须要有能力去处理分布式事务和分布式查询，典型的代表有蚂蚁的OceanBase、阿里的POLARDB-X、ADB、TDSQL等。
下一代的企业级数据库架构应该是将云原生架构和分布式架构以及HTAP完美结合起来。上层是分库分表Shared-Nothing的架构，下层是存储与计算分离的云原生架构，这种架构的好处在于既能够水平扩展，又能够实现高可用的能力。而且面对高并发的情况时，所需要的分片数量会大大减小，因此分布式事务的复杂性也会大大降低。
为了便于大家理解，这里为大家介绍一些分布式系统的理论，其中最核心的是CAP理论，即一致性（Consistency）、可用性（Availability）、分区容错性（Partitiontolerance）。解决上述问题存在不同的架构，包括单机单节点数据库架构、对数据进行分区分片、中间件架构，此外最好的方式就是一体化分布式，系统内部进行协调和处理并将最终结果返还给用户。
这里涉及到高可用的问题，那就是分库分表之后数据库出现问题该怎么办。分布式高可用数据库可以通过数据一致性协议来确保分区数据一致性，业界提供了两个比较优秀的分布式数据一致性协议，即Paxos和Raft。协议的内容大致就是分区进程一定可以对一个数据的取值达成一致，对一个数据的取值一定可以有一个可取值被提议，一旦分区进程对一个数据的取值达成一致，那么所有的分区进程最终都可以得到这个取值。
本部分结合阿里巴巴的数据库产品进行介绍。阿里云数据库不仅在云上提供服务，还会支撑整个阿里巴巴集团内部经济体的所有活动。2019年双11，在零点刚过的第一秒，阿里的数据库系统峰值增长了大概135倍，瞬间爆发，这就需要数据库具有较高的可扩展性、弹性以及高可用。数据库技术与产品必须是一个完整的生态系统，因此需要POLARDB、ADB等工具来支撑。
POLARDB底层是基于RDMA的分布式共享存储，通过ParallelRaft协议在分布式共享存储里实现高可用，上层实现了多个计算节点，实现一写多读，因为底层看到的是一份逻辑数据，因此事务处理表现非常好，并且能够根据需求实现分钟级别的弹性缩扩容。此外，这种架构不涉及到分库分表的兼容性改造，因此能够供100%兼容MySQL、100%兼容PG和Oracle的版本。
为了支持多种模式的数据库部署，阿里云在2019年也推出了一体机的产品解决方案。
POLARDB-X：分布式版本支持水平扩展+HTAP阿里巴巴将XDB和POLARDB的能力以及DRDS的能力进行了融合，实现了分布式数据库POLARDB-X。其上层就是DRDS，主要做分布式的事务处理和查询处理，下面一层就是POLARDB层能够实现水平扩展和弹性扩展。POLARDB-X的存储引擎使用了X-Engine。
在一个AZ里面想要实现三节点的金融级高可用，则使用Raft协议保证三副本之间的数据尺度一致，保证高可用、高可用以及性能。
跨AZ的部署存在较大的挑战，一般而言是在同城的三副本之间跑AZ的Raft协议，而跨城或者跨域则使用日志的同步技术实现，比如通过DTS实现，基本上就是通过解析Binlog的方式将源端的日志解析出来同步到远端再Replay。
目前业界的趋势是将大数据和FastData结合起来，也就是在线分析和交互计算在线化和实时化。
无论是MapReduce还是Spark等大数据系统，其模式都是由数据库系统演进而来的，只不过Spark的处理都是在内存中进行的，这样可以大大降低系统的开销。
SparkSQL是目前非常流行的使用SQL处理数据和分析的结构化模块，SparkSQL的模式和数据库内核的模式非常相似，只不过是将SQL的输入转化为Spark的Job去执行。
基于BSP模型的大数据系统面临的最核心挑战就是并行处理时任务执行进度不一致而导致的同步问题，而现在希望大数据系统能够和数据库系统一样能够实现并行的同步。
无论是数据库系统还是大数据系统，其调度方式都是基于DAG的调度和计划器。也就是将执行计划看做一个有向无环图，进行分组执行，每一轮执行完成之后进行同步，再进行到下一轮。
大数据和数据库系统正在进行融合，向着在线实时化发展。而在线实时化中最为核心的挑战就是要处理多个数据源和要进行ServerlessComputing。
智能化OLAP：AnalyticDB实时交互式数据仓库举例而言，阿里云实现了智能化的OLAP，实时交互式数据仓库AnalyticDB，其也基于BSP模型，因此能够进行在线计算和分析处理。
AnalyticDB的另外一个优势就是将非结构化数据、半结构化数据有效地和结构化数据联合处理，这是因为其具有向量化计算引擎，能够对于非结构化数据实现向量化，进而实现联合处理。
数据湖其与数据仓库的相同点是都是为了解决异构分析处理的本质问题，但是数据仓库里面有自己的源数据管理和存储引擎，而数据湖只做了源数据管理，而没有存储引擎。数据湖只是去连接不同的数据源，而不是将数据转化到自己的存储引擎，这是数据库服务与ADB的本质区别。在阿里云等主流的数据湖内核中一般都会结合Presto或者Spark的内核来做交互式计算，并将计算结果提供给BI工具。因为其没有自己的存储引擎，因此非常适合于做ServerlessComputing的架构。
NoSQL要支持非结构化与半结构化数据的处理，阿里云基于Redis实现了支持KV缓存的Tair，处理文档数据的MongoDB，处理时序时空的TSDB（TimeSeriesDatabase），处理图的GDB（GraphDataBase），处理宽表的Cassandra等。总而言之，NoSQL放弃了传统关系型数据库对ACID数据一致性的要求，换取了对非结构化、半结构化数据这种复杂数据水平拓展的能力。
阿里巴巴的企业数据管理功能矩阵提供了面向研发、DBA、内审、运营决策的数据操作统一入口和业务报表服务。对于企业级数据库而言，存在安全管控、变更稳定、数据分析的需求，这里面涉及SQL任务执行引擎、逻辑库执行引擎、安全规则引擎、数据脱敏引擎等。
阿里云上的数据库管理产品叫做DMS，它除了提供上述服务，还提供了数据安全保障。从“审计”到“主动拦截”再到数据脱敏的整个流程都由DMS完成。DMS内置了安全规则库、规则执行器以及动作Action（类似Trigger），这样当业务主系统出现问题时，数据不会丢失。
将备份数据变废为宝，对备份数据进行分析和查询甚至是BI的决策，这是现在CDM的趋势。
管控平台的一个趋势，希望在公有云中提供“专有云”的能力。公有云管控虽然提供了实例管理的能力，但很多应用的时候需要自己去直接管理的能力。例如在公有云上能够拿到自己机房root、admin的权限，因此阿里云就做了大客户的专享集群，利用了云原生的管控能力如K8S的方式，能够尽可能的把管控透明化，把权限开放给客户和应用。
在业界，大量集成智能化和机器学习成为管控的趋势。下图是阿里云管控的整体架构，它做了一个SDDP（Self-DrivingDatabasePlatform），对每一个实例去采集性能数据（在用户许可的前提下采集访问一些用户的性能数据，非业务数据，如CPU使用率、磁盘使用率），进行建模分析，实时的进行监控。在这样的优化下，阿里云慢SQL的数量大幅度减少，内存的使用率大幅度提高。
标准的云上数据安全包括传输过程、存储过程等，例如引用TDE（TransparentDataEncryption）、DataatRestEncryption。阿里云对数据安全的几个维度进行了总结：如加密的数据访问和存储、减小内部攻击风险、日志数据一致性的可验证（例如结合区块链技术把数据和日志让用户做一致性的验证）等。
数据进入内核以后也是进行加密的，不需要解密，加密使用的是客户的密钥，其他人不可见。这样确保了即使在内部攻击的情况下，整个数据过程也是完全保密的。
把Oracle现有的数据迁移到云上，是一个从评估到决策、实施、优化的过程。使用自动化工具ADAM，能够通过自动化生成报表来告诉用户从Oracle迁移到目标数据库哪些应用是兼容的，哪些应用是不兼容的，这使做应用迁移决定的时候有一个清晰明了的过程，知道迁移改造的成本。
有了如下流程体系：使用ADAM这种自动迁移评估工具去做应用兼容性、一致性的评估，之后做评估改造，再用DTS把数据库迁移到不同的目标库，这样就形成了一个标准化、流程化、产品化的Oracle迁移方案。
建议中小型业务系统要选择与Oracle高度兼容的目标库进行迁移，例如PolarDB。大型核心系统将来的发展方式很有可能是类似分布式的架构，分析型可以选择AnalyticDB，事务型可以选择PolarDB-X分布式。
目前，阿里云在亚太市场排名第一，全球市场排名第三。从营收来讲，在全球市场仅仅落后于亚马逊和微软，在云数据库的市场上已经超过了许多传统型数据库，如Oracle、Google这种非常强劲的竞争对手。
最后介绍一些基于阿里云的产品和技术做的一些解决方案和应用案例。首先阿里巴巴的数据库产品支撑了阿里巴巴集团内部所有复杂的业务，外部业务支撑了从国家重点项目的云上商业系统的应用，例如从制造业到国际客户、零售、金融、互娱。
阿里巴巴数据库应用的具体案例包括，帮助某东部银行基于PolarDB分布式版本快速构建新型业务与小微业务的互联网架构；帮助中国的某第三方跨境支付平台基于PolarDB分布式版构建高并发、低延时的支付系统，同时使用DTS、DLA做异构多元数据处理以及实时数据同步；使用AnalyticDB替换传统的“SysbaseIQ+Hadoop”解决方案，帮助某核心券商实现金融加速分析平台。
阿里巴巴还帮助天弘基金基于AnalyticDB构建了承载了500TB数据量和1亿用户的实时查询计算平台；帮助南区最大的银行之一构建基于DTS的“异地容灾”；帮助中国邮政利用AnalyticDB实现全国10万多机构寄报表平台；利用云原生的数据库技术帮助银泰百货改造数据库系统，实现了弹性高可用，使其能够支撑大促20倍峰值，并将成本减少60%以上；
数据库的未来发展趋势可以总结为以下四点：
李飞飞：传统的T和A是分开处理的，T和A有冲突。Transaction数据库里面尤其做简单的查询和处理是ok的，比如点查询和事务处理一般不会产生太大问题。原因是它读的数据范围非常小，那数据库里面可能会有几百万的数据库只读其中的几十个和几个，同时进行更新产生的概率非常小，所以TP可以做一些简单的查询和分析。Transaction为了支持更新一般是行存，分析的话可能不大有益。分析数据库一般都是用按列存，按列存好处是在分析的时候只需读需要的几列；第二是压缩带来的好处就是存储成本的降低和对整个IO读取和数据库的处理都会有明显的增强。HTAP在使用的时候，更新的时候用行分析的时候用列，行列转换做好就可以了。说起来简单，做起来难，我们也在思考如何操作。有一个逻辑用三副本的高可用里面的数据数据冗余去做去行业行列转换，这样就可能减少实时的冲突。HTAP我觉得将来一定会是一个热点，很多人认为TiDB是HTAP，但我觉得有待商榷，因为TiDB在实时更新是非常有挑战的。我们要一起努力去把这个问题解决，我觉得将来这一块会是一个机遇点。
李飞飞：我个人观点是这样的：云原生数据库反而有个优点，可能不像传统的数据库，上云以后反而不用被locking。因为大家看业界像主流的云原生数据库解决方案和产品像我们的PolarDB、ADB像友商推出的云原生数据库，这些数据库他们的架构都非常的相似；因为存储阶段分离它上面是多个计算节点，它底下是一个分布式的共享存储，虽然用了分布式的结构，但其实它是分布式的共享存储，实际上是一个单节点，这样导致它可以做完美的兼容性，去兼容现在完美的数据库生态系统。从用户应用的角度来看，实际上是不可能被绑架的。因为从应用的角度来看兼容度这么高，迁移相对成本是比较低的。
李飞飞：像传统的数据库，让大家去排队，尽量利用性能，只能一定程度上缓解这个问题。业界上有2种操作，一个是采用云原生的架构，采用存储计算分离，像PolarDB可以做一写多读。现在PolarDB一个实例可以做一个大到接近100T的存储，上面可以做一写多读16个节点。按照当时并发的需求，尤其是对只读并发高的应用，就按量去弹出来的只读节点，一两分钟就弹出一个新的节点，峰值过去之后就可以释放了。如果写的并发特别多可以采用PolarDB2.0，所有的计算节点每一个计算节点都可以做写和读。写和写的冲突问题可以在多写和多读的时候，就要想办法在共享状态这一层。还有一种解决方法是用分布式，或者有些传统企业用的中间件分库分表或者分布式数据库。因为可以把并发并行的或者分布式放到多个节点上去。这里面也有挑战，挑战非常大，因为一旦对数据进行了分库以后，每个分区都非常容易被并行化。很多时候要做跨区域的查询，依赖两个或三个Partition或者Share上的数据，就需要做跨库的事务处理和查询，这个对系统性能影响非常非常大。但在很多应用场景上，可能并发是很高但做跨库的这种冲突事务的量可能不会太高。