含PPT下载 | 如何看待数据库的未来？

含PPT下载 | 如何看待数据库的未来？

阿里妹导读：在这个全国抗疫的特殊时刻，阿里CIO学院希望与更多企业的CIO、CTO、技术专家、程序员站在一起，因此举办攻“疫”技术公益培训，分享技术在人类灾难前能够呈现的价值。在阿里CIO学院攻“疫”技术公益培训的第一场直播中，达摩院数据库首席科学家，阿里巴巴副总裁，ACM杰出科学家李飞飞(花名：飞刀)为大家带来了企业级云原生分布式数据库系统的分享，以下内容由视频直播内容整理而成。

一、云原生分布式数据库系统的发展历程

数据库市场分析与预测

首先为大家将介绍整个数据库市场分析与预测。根据Gartner公司的分析报告，2018年全球基础软件如虚拟化软件、操作系统、存储等的市场规模大约为2000亿美金，其中数据库占20%，大约为461亿美金。而中国的数据库市场规模大概为161亿人民币，但这一数字实际上因为各种原因被远远低估了。2018年数据库市场的增长率是18%，其中云数据库占比达到了22.75%，而Gartner预测在未来的2到3年内云数据库的占比可能会达到75%。在世界范围内，云数据库的领袖毫无疑问当然是亚马逊。亚马逊是最早在云数据库市场发力的厂商，也是目前做的最好的一家云厂商。而在AWS做云数据库之前，这个市场处于“None-Player”的状态，传统数据库市场的巨头是Microsoft、IBM、***，而AWS未能跻身其中。但云数据库赛道为AWS带来了发展的机遇，其发展速度非常快，它的云原生数据库Aurora在2018年就达到了3亿美金的营收。

数据库系统演进

数据库已经发展了40年，可以说是一个传统又古老的领域。回顾数据库的发展历史，1980年到1990年属于商业起步阶段，此时***、IBM ***、Sybase以及***和Informix等开始出现。

1990年至2000年，开源数据库开始展露头角，出现了***和MySQL等。与此同时，出现了一些分析型数据库，因为之前出现的都是OLTP，而现在随着大量数据的出现，需要对于这些数据进行分析，因此出现了OLAP，而为了避免读写冲突，就需要建立分析型数据库系统，Teradata、Sybase IQ、Greenplum等就快速成长起来。

2000年到2010年期间，以谷歌为代表的互联网公司逐渐推出了NoSQL数据库。尤其是谷歌的GFS(Google File System)、Google Bigtable、Google MapReduce三大件。Google File System解决了分布式文件系统问题，Google Bigtable解决了分布式KV(Key-Value)存储的问题，Google MapReduce解决了在分布式文件系统和分布式KV存储上面如何做分布式计算和分析的问题。之所以产生了这三大件，是因为数据强一致性对系统的水平拓展以及海量数据爆发式增长的分析能力出现了断层。因此就需要解决这个问题，把这种数据的强一致性需求弱化，换来能够使用用分布式的集群做水平拓展处理。谷歌三大件在业界诞生以后，很快的衍生了一个新的领域叫NoSQL(Not Only SQL)，就是针对非结构化、半结构化的海量数据处理系统。现在也有很多很好的商业公司基于NoSQL发展，比如说文档数据(***)、缓存(Redis)等大家平常应用开发都会用到的NoSQL系统。

而在2010年以后，AWS Aurora、Redshift、Azure SQL Database、Google Spanner以及***的***和***等都发展起来了，它们的特点就是云原生、一体化分布式、多模和HTAP的能力。

总结而言，数据库的演进经历了从结构化数据在线处理到海量数据分析，从SQL+OLAP的RDBMS到ETL+OLAP的Data Warehouse和Data Cube，再到今天异构多源的数据类型的发展历程。

数据库：云上应用的关键一环

如今，上云已经成为一种趋势。而在上云的过程中，数据库则被认为是云上非常重要的一环。因为云最开始提供的是IaaS，而随着各种智能化应用的兴起，数据库就成为了从IaaS到智能化应用连接的重要一环。

数据库发展：业务视角

大家知道，数据库可以分为几类：

最经典的是传统关系型OLTP数据库，其主要用于事务处理的结构化数据库，典型例子是银行的转账记账、淘宝下单、订单以及商品库存管理等。其面临的核心挑战是高并发、高可用以及高性能下的数据正确性和一致性。

其次是NoSQL数据库及专用型数据库，其主要用于存储和处理非结构化或半结构化数据(如文档，图，时序、时空，K-V)，不强制数据的一致性，以此换来系统的水平拓展、吞吐能力的提升。

再次是分析型数据库 (On-Line Analytic Processing， OLAP)，其应用场景就是海量的数据、数据类型复杂以及分析条件复杂的情况，能够支持深度智能化分析。其面临的挑战主要是高性能、分析深度、与TP数据库的联动，以及与NoSQL数据库的联动。

除了数据的核心引擎之外，还有数据库外围的服务和管理类工具，比如数据传输、数据备份以及数据管理等。

最后就是数据库的管控平台，无论是私有云、专有云、混合云还是自己的IDC机房内进行部署，总要有一套数据库管控系统来管理数据库实例的产生和消亡、实例的资源消费等，能够以简单的形式提供给DBA以及数据库开发者。

数据库系统DBMS的价值

如下图所示的是文件形式的数据存储系统和DBMS的区别。数据库系统的核心位置在操作系统和SQL的接口之间，简单而言就是在存储系统与上层抽象之间架起了一个系统来管理对于业务有用的数据，如果不这样设计则需要使用一些高级程序语言开发应用程序来与操作系统交互并管理这些数据。而数据库将对于数据的管理、存储以及消费抽象出来，这样一来不用每次都在应用程序里写相关的逻辑了，而可以专注于业务逻辑，数据管理相关的逻辑全部交给数据库系统实现，并且用Structured Query Language结构化查询语言对于数据访问接口进行抽象。

数据库系统的核心模块

将数据库系统拆开来看，其核心模块包括应用接口、SQL接口、查询执行引擎、数据访问模块和存储引擎。其中，查询执行引擎进一步可以拆分为计划生成器、计划优化器和计划执行器;数据访问模块则可以分为事务处理、内存处理、安全管理以及文件和索引管理等模块;并且事务处理是最核心的模块，其中包括了崩溃恢复和并发控制;最底层的存储引擎则包括数据文件、索引文件和系统及元数据文件。

查询分析处理过程

数据库查询分析处理过程是这样的：首先，通过SQL语句或者大数据系统的Dataframe API将查询任务提交上来，之后经过Simba PraserSimba Parser进行处理，此时会有各种各样的执行方式，并生成Catalog和逻辑执行计划;之后对于逻辑执行计划进行优化，并生成物理执行计划;之后在借助系统的统计信息，如索引管理、内存管理来生成一个优化后的物理执行计划，再执行并生成最后结果或者RDD。

简单而言，数据库系统的架构就是持久化存储的数据按照Data Page的形式进行存储，这些数据块在查询访问的时候会被带到内存里面。系统中有内存池，每个内存池可以装载一个Page，此时的问题就是内存池的大小是有限的，如果数据存储非常大，需要进行优化。此外，还涉及到优化数据访问的问题，一般通过索引解决，主要是Hash索引和树形索引。

数据库系统挑战

数据库系统最关键的挑战就是并行访问时的写写冲突和数据一致性问题。此外，还有读和写的冲突问题，比如在数据库里做批量写入的时候系统宕机，应该考虑如何让系统自动恢复。

为解决以上的问题，数据库系统提出了一个核心概念——事务。简单而言，事务就是一系列动作可以被看作一个整体，从用户视角来看事务是隔离运行的，一个用户的事务和另一个用户没有关系。如果系统出现异常，事务要么全部执行完毕，要么一个也没有被执行。这样引申出来事务的核心概念：原子性、一致性、隔离性、持久性。

数据库系统的挑战

数据库系统与大数据系统非常相关，而在分析型数据库系统里面也会面临非常多的挑战，比如预测用户的退货率需要进行非常复杂的查询分析并且需要非常复杂的机器学习模型。

二、数据库系统架构的对比及趋势

云原生数据：要解决什么问题?

传统架构依赖于高端硬件，每套数据库系统服务器少，架构相对简单，但无法支持新业务的扩展需求。而云计算机构的核心逻辑就是通过虚拟化技术带来池化资源。云原生数据库采用分布式数据库架构，实现大规模扩展，每套数据库系统横跨多台服务器和虚拟机，带来了全新的系统管理挑战。其中最核心的挑战就是如何实现弹性以及高可用，实现按需按量使用，使得资源高效利用。

云原生数据库管控平台：DBaaS智能化简化管理维护

云原生数据希望管控平台能够实现多实例统一管理;全图形化，无需命令行;分钟级安装，集群部署;自动备份，时间点恢复;动态扩容和缩容;以及性能监控和优化调整。

阿里巴巴数据库发展历史

在2005到2009年，当时阿里巴巴拥有亚太最大规模的*** RAC集群;在2010年到2015年开始，使用开源数据库以及分库分表的技术来解决对于商业数据库的依赖;从2016年开始到现在，阿里巴巴都在自研数据库上发力，TP方面包括***和***，AP方面则有分析型数据库***。

灵活的部署形态

随着云计算的发展，数据库的部署形式也发生了很大的变化。传统的数据都是部署在客户机房里面，与客户的机器绑定。而在云环境下，希望数据库能够在多种形态下部署，比如公有云、专有/私有云、混合云以及软硬件一体化独立部署，以及纯软件输出。

***等数据库厂商也正在向着AWS的部署方式转型。

多模数据库系统

数据库系统另外的一个趋势就是多模。数据库系统的演进经历了从最早的关系型数据库OLTP到半结构化，再到分析型数据库OLAP等非结构化的数据库，再发展到如今的多模数据库。对于多模数据库而言，主要有两种维度，南向维度是数据库可以有多种存储港方式，北向维度是可以有多种查询接口和标准，而希望由同一套数据库引擎来支撑。

数据库智能化+自动化管控平台

借助于机器学习、人工智能技术，希望能够与数据库内核进行结合，使得数据库能够更加自动化和智能化，实现自感知、自决策、自恢复和自优化。

新硬件: 软硬件一体化设计

未来，下一代的企业级数据库一定要结合软硬件一体化的设计理念，而不能把软件和硬件隔开，只有将软硬件结合在一起，才能把系统的优势发挥出来。

行存储VS.列存储

TP和AP的关键区别就是行存储和列存储，前者按照行将数据存储起来，其优点是能够高效简易访问一整条记录来处理更新，缺点是需要访问和读取不需要的数据信息;后者的优点是只需要读取所需数据，缺点是更新一条记录不同属性时需要多次访问。

HTAP：事务处理与分析处理一体化

HTAP希望能够将行存和列存结合起来，在一套系统里面实现行列混存，但是这样也会遇到很多挑战，最核心的就是数据一致性的挑战。

云原生架构: 弹性x高可用x企业实践x开放生态

传统数据库架构采用单节点架构，其有点是部署和开发简单，缺点就是非常难于做弹性缩扩容。云原生架构是基于RDMA等网路实现分布式共享存储，使得上层应用看起来存储是一份，在上层实现存储与计算分离，使得存储和计算可以实现独立的缩扩容，这就带来了极致的弹性，也为云原生带来了很好的管理方式，如***的***、AWS的Aurora等都是基于这样架构。

还有另外一种就是分布式架构，其对于数据库进行分库分片，其特点是水平扩展能力特别强，当数据量变大、并发量变高的时候只需要增加节点即可，其缺点是如果要求不改动上层业务逻辑，就必须要有能力去处理分布式事务和分布式查询，典型的代表有蚂蚁的***、阿里的***-X、ADB、***等。

下一代企业级数据库：云原生+分布式+HTAP

下一代的企业级数据库架构应该是将云原生架构和分布式架构以及HTAP完美结合起来。上层是分库分表Shared-Nothing的架构，下层是存储与计算分离的云原生架构，这种架构的好处在于既能够水平扩展，又能够实现高可用的能力。而且面对高并发的情况时，所需要的分片数量会大大减小，因此分布式事务的复杂性也会大大降低。

分布式系统CAP理论

为了便于大家理解，这里为大家介绍一些分布式系统的理论，其中最核心的是CAP理论，即一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)。解决上述问题存在不同的架构，包括单机单节点数据库架构、对数据进行分区分片、中间件架构，此外最好的方式就是一体化分布式，系统内部进行协调和处理并将最终结果返还给用户。

分布式数据库系统：高可用

这里涉及到高可用的问题，那就是分库分表之后数据库出现问题该怎么办。分布式高可用数据库可以通过数据一致性协议来确保分区数据一致性，业界提供了两个比较优秀的分布式数据一致性协议，即Paxos和Raft。协议的内容大致就是分区进程一定可以对一个数据的取值达成一致，对一个数据的取值一定可以有一个可取值被提议，一旦分区进程对一个数据的取值达成一致，那么所有的分区进程最终都可以得到这个取值。

三、云数据库技术高速发展的现状

数据库技术与产品是完整的生态系统

本部分结合阿里巴巴的数据库产品进行介绍。***不仅在云上提供服务，还会支撑整个阿里巴巴集团内部经济体的所有活动。2019年双11，在零点刚过的第一秒，阿里的数据库系统峰值增长了大概135倍，瞬间爆发，这就需要数据库具有较高的可扩展性、弹性以及高可用。数据库技术与产品必须是一个完整的生态系统，因此需要***、ADB等工具来支撑。

云原生数据库：***

***底层是基于RDMA的分布式共享存储，通过Parallel Raft协议在分布式共享存储里实现高可用，上层实现了多个计算节点，实现一写多读，因为底层看到的是一份逻辑数据，因此事务处理表现非常好，并且能够根据需求实现分钟级别的弹性缩扩容。此外，这种架构不涉及到分库分表的兼容性改造，因此能够供100%兼容MySQL、100%兼容PG和***的版本。

*** Box：高性能一体机

为了支持多种模式的数据库部署，***在2019年也推出了一体机的产品解决方案。

***-X：分布式版本支持水平扩展+HTAP

阿里巴巴将XDB和***的能力以及DRDS的能力进行了融合，实现了分布式数据库***-X。其上层就是DRDS，主要做分布式的事务处理和查询处理，下面一层就是***层能够实现水平扩展和弹性扩展。***-X的存储引擎使用了X-Engine。

三节点金融级可用集群

在一个AZ里面想要实现三节点的金融级高可用，则使用Raft协议保证三副本之间的数据尺度一致，保证高可用、高可用以及性能。

两地多中心

跨AZ的部署存在较大的挑战，一般而言是在同城的三副本之间跑AZ的Raft协议，而跨城或者跨域则使用日志的同步技术实现，比如通过DTS实现，基本上就是通过解析Binlog的方式将源端的日志解析出来同步到远端再Replay。

Big Data + Fast Data：将海量数据转化在线实时可用

目前业界的趋势是将大数据和FastData结合起来，也就是在线分析和交互计算在线化和实时化。

基于分布式集群的大数据计算与分析系统：由数据库系统演而来

无论是MapReduce还是Spark等大数据系统，其模式都是由数据库系统演进而来的，只不过Spark的处理都是在内存中进行的，这样可以大大降低系统的开销。

Spark SQL：大数据和数据库技术在快速融合

Spark SQL是目前非常流行的使用SQL处理数据和分析的结构化模块，Spark SQL的模式和数据库内核的模式非常相似，只不过是将SQL的输入转化为Spark的Job去执行。

大数据系统的核心：并行处理方式

基于BSP模型的大数据系统面临的最核心挑战就是并行处理时任务执行进度不一致而导致的同步问题，而现在希望大数据系统能够和数据库系统一样能够实现并行的同步。

基于DAG的调度和计划器

无论是数据库系统还是大数据系统，其调度方式都是基于DAG的调度和计划器。也就是将执行计划看做一个有向无环图，进行分组执行，每一轮执行完成之后进行同步，再进行到下一轮。

技术趋势：Serverless Storage + Serverless Compute

大数据和数据库系统正在进行融合，向着在线实时化发展。而在线实时化中最为核心的挑战就是要处理多个数据源和要进行Serverless Computing。

四、***总结

智能化OLAP：***实时交互式数据仓库

举例而言，***实现了智能化的OLAP，实时交互式数据仓库***，其也基于BSP模型，因此能够进行在线计算和分析处理。

***的另外一个优势就是将非结构化数据、半结构化数据有效地和结构化数据联合处理，这是因为其具有向量化计算引擎，能够对于非结构化数据实现向量化，进而实现联合处理。

Data Lake Analytics-数据湖：全域数据，全局开放分析

数据湖其与数据仓库的相同点是都是为了解决异构分析处理的本质问题，但是数据仓库里面有自己的源数据管理和存储引擎，而数据湖只做了源数据管理，而没有存储引擎。数据湖只是去连接不同的数据源，而不是将数据转化到自己的存储引擎，这是数据库服务与ADB的本质区别。在***等主流的数据湖内核中一般都会结合Presto或者Spark的内核来做交互式计算，并将计算结果提供给BI工具。因为其没有自己的存储引擎，因此非常适合于做Serverless Computing的架构。

企业级NoSQL：非结构化和半结构化数据库套件

NoSQL要支持非结构化与半结构化数据的处理，***基于Redis实现了支持KV缓存的Tair，处理文档数据的***，处理时序时空的TSDB(Time Series Database)，处理图的GDB(Graph DataBase)，处理宽表的***等。总而言之，NoSQL放弃了传统关系型数据库对ACID数据一致性的要求，换取了对非结构化、半结构化数据这种复杂数据水平拓展的能力。

企业数据管理功能矩阵

阿里巴巴的企业数据管理功能矩阵提供了面向研发、DBA、内审、运营决策的数据操作统一入口和业务报表服务。对于企业级数据库而言，存在安全管控、变更稳定、数据分析的需求，这里面涉及SQL任务执行引擎、逻辑库执行引擎、安全规则引擎、数据脱敏引擎等。

数据安全保障

***上的数据库管理产品叫做DMS，它除了提供上述服务，还提供了数据安全保障。从“审计”到“主动拦截”再到数据脱敏的整个流程都由DMS完成。DMS内置了安全规则库、规则执行器以及动作Action(类似Trigger)，这样当业务主系统出现问题时，数据不会丢失。

数据库备份DBS

将备份数据变废为宝，对备份数据进行分析和查询甚至是BI的决策，这是现在CDM的趋势。

企业级云原生管控平台

管控平台的一个趋势，希望在公有云中提供“专有云”的能力。公有云管控虽然提供了实例管理的能力，但很多应用的时候需要自己去直接管理的能力。例如在公有云上能够拿到自己机房root、admin的权限，因此***就做了大客户的专享集群，利用了云原生的管控能力如K8S的方式，能够尽可能的把管控透明化，把权限开放给客户和应用。

AI for DB- DAS: 智能化数据库管控与内核

在业界，大量集成智能化和机器学习成为管控的趋势。下图是***管控的整体架构，它做了一个SDDP(Self-Driving Database Platform)，对每一个实例去采集性能数据(在用户许可的前提下采集访问一些用户的性能数据，非业务数据，如CPU使用率、磁盘使用率)，进行建模分析，实时的进行监控。在这样的优化下，***慢SQL的数量大幅度减少，内存的使用率大幅度提高。

数据安全

标准的云上数据安全包括传输过程、存储过程等，例如引用TDE(Transparent Data Encryption)、Data at Rest Encryption。***对数据安全的几个维度进行了总结：如加密的数据访问和存储、减小内部攻击风险、日志数据一致性的可验证(例如结合区块链技术把数据和日志让用户做一致性的验证)等。

全程加密数据永不泄露

数据进入内核以后也是进行加密的，不需要解密，加密使用的是客户的密钥，其他人不可见。这样确保了即使在内部攻击的情况下，整个数据过程也是完全保密的。

***迁移-数据库及应用迁移改造ADAM

把***现有的数据迁移到云上，是一个从评估到决策、实施、优化的过程。使用自动化工具ADAM，能够通过自动化生成报表来告诉用户从***迁移到目标数据库哪些应用是兼容的，哪些应用是不兼容的，这使做应用迁移决定的时候有一个清晰明了的过程，知道迁移改造的成本。

ADAM - ORACLE迁移全链路解决方案

有了如下流程体系：使用ADAM这种自动迁移评估工具去做应用兼容性、一致性的评估，之后做评估改造，再用DTS把数据库迁移到不同的目标库，这样就形成了一个标准化、流程化、产品化的***迁移方案。

*** 迁移的科学方案选型

建议中小型业务系统要选择与***高度兼容的目标库进行迁移，例如***。大型核心系统将来的发展方式很有可能是类似分布式的架构，分析型可以选择***，事务型可以选择***-X 分布式。

***总结

目前，***在亚太市场排名第一，全球市场排名第三。从营收来讲，在全球市场仅仅落后于亚马逊和微软，在云数据库的市场上已经超过了许多传统型数据库，如***、Google这种非常强劲的竞争对手。

应用案例

最后介绍一些基于***的产品和技术做的一些解决方案和应用案例。首先阿里巴巴的数据库产品支撑了阿里巴巴集团内部所有复杂的业务，外部业务支撑了从国家重点项目的云上商业系统的应用，例如从制造业到国际客户、零售、金融、互娱。

阿里巴巴数据库应用的具体案例包括，帮助某东部银行基于***分布式版本快速构建新型业务与小微业务的互联网架构;帮助中国的某第三方跨境支付平台基于***分布式版构建高并发、低延时的支付系统，同时使用DTS、DLA做异构多元数据处理以及实时数据同步;使用***替换传统的“Sysbase IQ + Hadoop”解决方案，帮助某核心券商实现金融加速分析平台。

阿里巴巴还帮助天弘基金基于***构建了承载了500TB数据量和1亿用户的实时查询计算平台;帮助南区最大的银行之一构建基于DTS的“异地容灾”;帮助中国邮政利用***实现全国10万多机构寄报表平台;利用云原生的数据库技术帮助银泰百货改造数据库系统，实现了弹性高可用，使其能够支撑大促20倍峰值，并将成本减少60%以上;

总结

数据库的未来发展趋势可以总结为以下四点：

产品架构与技术创新：云原生 + 分布式 (弹性、高可用)。架构上分布式共享存储、存储计算分离，云原生架构+Shared Nothing分布式架构，满足弹性、高可用、水平拓展的能力。

数据挑战：多模，结构化与非结构化数据 (多源异构数据)。结构化与非结构化数据如何融合异构处理，比如数据湖的概念、ADB里面用向量处理引擎把非结构化数据变成结构化数据，高维向量、多源异构数据处理的技术。

数据处理与分析：海量数据分析在线化 (实时在线交互式分析)。如何对海量数据进行在线分析和计算，支持实时在线交互式分析，需要做并行处理(DSP模型、MPP模型等等)，对并行调度计算进行优化。

系统能力提升：智能化 + 安全 (使用方便可靠、运维简易)。如在管控平台的层面如何做智能化的调度、监控以及自动修复，怎样去做数据的安全处理、隐私保护、加密处理等等，使得整个数据库的使用更加方便可靠、运维简易。

数据库上云/迁移是一个生态，而不是一个项目。回顾一下本文分享的所有技术，数据同步与传输技术来做数据库的同步迁移，需要分布式云原生的系统来做弹性高可用，也需要NoSQL做图、时序/时空等非结构化数据的处理，同时需要数据同步/分发到分析系统里面做实时计算分析，还要备份、混合云的管理，以及针对企业数据库研发的DevOps开发流程管理套件。总而言之，只有完整的生态体系才能支撑中国的数据库市场快速发展以及走向全球。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。