本文内容根据演讲嘉宾视频以及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、IBM DB2、Sybase以及SQL Server和Informix等开始出现。
1990年至2000年，开源数据库开始展露头角，出现了PostgreSQL和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发展，比如说文档数据（MongoDB）、缓存（Redis）等大家平常应用开发都会用到的NoSQL系统。
而在2010年以后，AWS Aurora、Redshift、Azure SQL Database、Google Spanner以及阿里云的POLARDB和AnalyticDB等都发展起来了，它们的特点就是云原生、一体化分布式、多模和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 Parser进行处理，此时会有各种各样的执行方式，并生成Catalog和逻辑执行计划；之后对于逻辑执行计划进行优化，并生成物理执行计划；之后在借助系统的统计信息，如索引管理、内存管理来生成一个优化后的物理执行计划，再执行并生成最后结果或者RDD。
简单而言，数据库系统的架构就是持久化存储的数据按照Data Page的形式进行存储，这些数据块在查询访问的时候会被带到内存里面。系统中有内存池，每个内存池可以装载一个Page，此时的问题就是内存池的大小是有限的，如果数据存储非常大，需要进行优化。此外，还涉及到优化数据访问的问题，一般通过索引解决，主要是Hash索引和树形索引。
数据库系统挑战
数据库系统最关键的挑战就是并行访问时的写写冲突和数据一致性问题。此外，还有读和写的冲突问题，比如在数据库里做批量写入的时候系统宕机，应该考虑如何让系统自动恢复。
为解决以上的问题，数据库系统提出了一个核心概念——事务。简单而言，事务就是一系列动作可以被看作一个整体，从用户视角来看事务是隔离运行的，一个用户的事务和另一个用户没有关系。如果系统出现异常，事务要么全部执行完毕，要么一个也没有被执行。这样引申出来事务的核心概念：原子性、一致性、隔离性、持久性。
数据库系统的挑战
数据库系统与大数据系统非常相关，而在分析型数据库系统里面也会面临非常多的挑战，比如预测用户的退货率需要进行非常复杂的查询分析并且需要非常复杂的机器学习模型。
二、数据库系统架构的对比及趋势
云原生数据：要解决什么问题？
传统架构依赖于高端硬件，每套数据库系统服务器少，架构相对简单，但无法支持新业务的扩展需求。而云计算机构的核心逻辑就是通过虚拟化技术带来池化资源。云原生数据库采用分布式数据库架构，实现大规模扩展，每套数据库系统横跨多台服务器和虚拟机，带来了全新的系统管理挑战。其中最核心的挑战就是如何实现弹性以及高可用，实现按需按量使用，使得资源高效利用。
云原生数据库管控平台：DBaaS智能化简化管理维护
云原生数据希望管控平台能够实现多实例统一管理；全图形化，无需命令行；分钟级安装，集群部署；自动备份，时间点恢复；动态扩容和缩容；以及性能监控和优化调整。
阿里巴巴数据库发展历史
在2005到2009年，当时阿里巴巴拥有亚太最大规模的Oracle RAC集群；在2010年到2015年开始，使用开源数据库以及分库分表的技术来解决对于商业数据库的依赖；从2016年开始到现在，阿里巴巴都在自研数据库上发力，TP方面包括POLARDB和OceanBase，AP方面则有分析型数据库AnalyticDB。
灵活的部署形态
随着云计算的发展，数据库的部署形式也发生了很大的变化。传统的数据都是部署在客户机房里面，与客户的机器绑定。而在云环境下，希望数据库能够在多种形态下部署，比如公有云、专有/私有云、混合云以及软硬件一体化独立部署，以及纯软件输出。
Oracle等数据库厂商也正在向着AWS的部署方式转型。
多模数据库系统
数据库系统另外的一个趋势就是多模。数据库系统的演进经历了从最早的关系型数据库OLTP到半结构化，再到分析型数据库OLAP等非结构化的数据库，再发展到如今的多模数据库。对于多模数据库而言，主要有两种维度，南向维度是数据库可以有多种存储港方式，北向维度是可以有多种查询接口和标准，而希望由同一套数据库引擎来支撑。
数据库智能化+自动化管控平台
借助于机器学习、人工智能技术，希望能够与数据库内核进行结合，使得数据库能够更加自动化和智能化，实现自感知、自决策、自恢复和自优化。
新硬件: 软硬件一体化设计
未来，下一代的企业级数据库一定要结合软硬件一体化的设计理念，而不能把软件和硬件隔开，只有将软硬件结合在一起，才能把系统的优势发挥出来。
行存储VS.列存储
TP和AP的关键区别就是行存储和列存储，前者按照行将数据存储起来，其优点是能够高效简易访问一整条记录来处理更新，缺点是需要访问和读取不需要的数据信息；后者的优点是只需要读取所需数据，缺点是更新一条记录不同属性时需要多次访问。
HTAP：事务处理与分析处理一体化
HTAP希望能够将行存和列存结合起来，在一套系统里面实现行列混存，但是这样也会遇到很多挑战，最核心的就是数据一致性的挑战。
云原生架构: 弹性x高可用x企业实践x开放生态
传统数据库架构采用单节点架构，其有点是部署和开发简单，缺点就是非常难于做弹性缩扩容。云原生架构是基于RDMA等网路实现分布式共享存储，使得上层应用看起来存储是一份，在上层实现存储与计算分离，使得存储和计算可以实现独立的缩扩容，这就带来了极致的弹性，也为云原生带来了很好的管理方式，如阿里云的POLARDB、AWS的Aurora等都是基于这样架构。
还有另外一种就是分布式架构，其对于数据库进行分库分片，其特点是水平扩展能力特别强，当数据量变大、并发量变高的时候只需要增加节点即可，其缺点是如果要求不改动上层业务逻辑，就必须要有能力去处理分布式事务和分布式查询，典型的代表有蚂蚁的OceanBase、阿里的POLARDB-X、ADB、TDSQL等。
下一代企业级数据库：云原生+分布式+HTAP
下一代的企业级数据库架构应该是将云原生架构和分布式架构以及HTAP完美结合起来。上层是分库分表Shared-Nothing的架构，下层是存储与计算分离的云原生架构，这种架构的好处在于既能够水平扩展，又能够实现高可用的能力。而且面对高并发的情况时，所需要的分片数量会大大减小，因此分布式事务的复杂性也会大大降低。
分布式系统CAP理论
为了便于大家理解，这里为大家介绍一些分布式系统的理论，其中最核心的是CAP理论，即一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。解决上述问题存在不同的架构，包括单机单节点数据库架构、对数据进行分区分片、中间件架构，此外最好的方式就是一体化分布式，系统内部进行协调和处理并将最终结果返还给用户。
分布式数据库系统：高可用
这里涉及到高可用的问题，那就是分库分表之后数据库出现问题该怎么办。分布式高可用数据库可以通过数据一致性协议来确保分区数据一致性，业界提供了两个比较优秀的分布式数据一致性协议，即Paxos和Raft。协议的内容大致就是分区进程一定可以对一个数据的取值达成一致，对一个数据的取值一定可以有一个可取值被提议，一旦分区进程对一个数据的取值达成一致，那么所有的分区进程最终都可以得到这个取值。
三、云数据库技术高速发展的现状
数据库技术与产品是完整的生态系统
本部分结合阿里巴巴的数据库产品进行介绍。阿里云数据库不仅在云上提供服务，还会支撑整个阿里巴巴集团内部经济体的所有活动。2019年双11，在零点刚过的第一秒，阿里的数据库系统峰值增长了大概135倍，瞬间爆发，这就需要数据库具有较高的可扩展性、弹性以及高可用。数据库技术与产品必须是一个完整的生态系统，因此需要POLARDB、ADB等工具来支撑。
云原生数据库：POLARDB
POLARDB底层是基于RDMA的分布式共享存储，通过Parallel Raft协议在分布式共享存储里实现高可用，上层实现了多个计算节点，实现一写多读，因为底层看到的是一份逻辑数据，因此事务处理表现非常好，并且能够根据需求实现分钟级别的弹性缩扩容。此外，这种架构不涉及到分库分表的兼容性改造，因此能够供100%兼容MySQL、100%兼容PG和Oracle的版本。
POLARDB Box：高性能一体机
为了支持多种模式的数据库部署，阿里云在2019年也推出了一体机的产品解决方案。
POLARDB-X：分布式版本支持水平扩展+HTAP
阿里巴巴将XDB和POLARDB的能力以及DRDS的能力进行了融合，实现了分布式数据库POLARDB-X。其上层就是DRDS，主要做分布式的事务处理和查询处理，下面一层就是POLARDB层能够实现水平扩展和弹性扩展。POLARDB-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：AnalyticDB实时交互式数据仓库
举例而言，阿里云实现了智能化的OLAP，实时交互式数据仓库AnalyticDB，其也基于BSP模型，因此能够进行在线计算和分析处理。
AnalyticDB的另外一个优势就是将非结构化数据、半结构化数据有效地和结构化数据联合处理，这是因为其具有向量化计算引擎，能够对于非结构化数据实现向量化，进而实现联合处理。
Data Lake Analytics-数据湖：全域数据，全局开放分析
数据湖其与数据仓库的相同点是都是为了解决异构分析处理的本质问题，但是数据仓库里面有自己的源数据管理和存储引擎，而数据湖只做了源数据管理，而没有存储引擎。数据湖只是去连接不同的数据源，而不是将数据转化到自己的存储引擎，这是数据库服务与ADB的本质区别。在阿里云等主流的数据湖内核中一般都会结合Presto或者Spark的内核来做交互式计算，并将计算结果提供给BI工具。因为其没有自己的存储引擎，因此非常适合于做Serverless Computing的架构。
企业级NoSQL：非结构化和半结构化数据库套件
NoSQL要支持非结构化与半结构化数据的处理，阿里云基于Redis实现了支持KV缓存的Tair，处理文档数据的MongoDB，处理时序时空的TSDB（Time Series Database），处理图的GDB（Graph DataBase），处理宽表的Cassandra等。总而言之，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。阿里云对数据安全的几个维度进行了总结：如加密的数据访问和存储、减小内部攻击风险、日志数据一致性的可验证（例如结合区块链技术把数据和日志让用户做一致性的验证）等。
全程加密数据永不泄露
数据进入内核以后也是进行加密的，不需要解密，加密使用的是客户的密钥，其他人不可见。这样确保了即使在内部攻击的情况下，整个数据过程也是完全保密的。
Oracle迁移-数据库及应用迁移改造ADAM
把Oracle现有的数据迁移到云上，是一个从评估到决策、实施、优化的过程。使用自动化工具ADAM，能够通过自动化生成报表来告诉用户从Oracle迁移到目标数据库哪些应用是兼容的，哪些应用是不兼容的，这使做应用迁移决定的时候有一个清晰明了的过程，知道迁移改造的成本。
ADAM - ORACLE迁移全链路解决方案
有了如下流程体系：使用ADAM这种自动迁移评估工具去做应用兼容性、一致性的评估，之后做评估改造，再用DTS把数据库迁移到不同的目标库，这样就形成了一个标准化、流程化、产品化的Oracle迁移方案。
Oracle 迁移的科学方案选型
建议中小型业务系统要选择与Oracle高度兼容的目标库进行迁移，例如PolarDB。大型核心系统将来的发展方式很有可能是类似分布式的架构，分析型可以选择AnalyticDB，事务型可以选择PolarDB-X 分布式。
阿里云数据库总结
目前，阿里云在亚太市场排名第一，全球市场排名第三。从营收来讲，在全球市场仅仅落后于亚马逊和微软，在云数据库的市场上已经超过了许多传统型数据库，如Oracle、Google这种非常强劲的竞争对手。
应用案例
最后介绍一些基于阿里云的产品和技术做的一些解决方案和应用案例。首先阿里巴巴的数据库产品支撑了阿里巴巴集团内部所有复杂的业务，外部业务支撑了从国家重点项目的云上商业系统的应用，例如从制造业到国际客户、零售、金融、互娱。
阿里巴巴数据库应用的具体案例包括，帮助某东部银行基于PolarDB分布式版本快速构建新型业务与小微业务的互联网架构；帮助中国的某第三方跨境支付平台基于PolarDB分布式版构建高并发、低延时的支付系统，同时使用DTS、DLA做异构多元数据处理以及实时数据同步；使用AnalyticDB替换传统的“Sysbase IQ + Hadoop”解决方案，帮助某核心券商实现金融加速分析平台。
阿里巴巴还帮助天弘基金基于AnalyticDB构建了承载了500TB数据量和1亿用户的实时查询计算平台；帮助南区最大的银行之一构建基于DTS的“异地容灾”；帮助中国邮政利用AnalyticDB实现全国10万多机构寄报表平台；利用云原生的数据库技术帮助银泰百货改造数据库系统，实现了弹性高可用，使其能够支撑大促20倍峰值，并将成本减少60%以上；
总结
数据库的未来发展趋势可以总结为以下四点：
- 产品架构与技术创新：云原生 + 分布式 (弹性、高可用)。架构上分布式共享存储、存储计算分离，云原生架构+Shared Nothing分布式架构，满足弹性、高可用、水平拓展的能力。
- 数据挑战：多模，结构化与非结构化数据 (多源异构数据)。结构化与非结构化数据如何融合异构处理，比如数据湖的概念、ADB里面用向量处理引擎把非结构化数据变成结构化数据，高维向量、多源异构数据处理的技术。
- 数据处理与分析：海量数据分析在线化 (实时在线交互式分析)。如何对海量数据进行在线分析和计算，支持实时在线交互式分析，需要做并行处理（DSP模型、MPP模型等等），对并行调度计算进行优化。
- 系统能力提升：智能化 + 安全 (使用方便可靠、运维简易)。如在管控平台的层面如何做智能化的调度、监控以及自动修复，怎样去做数据的安全处理、隐私保护、加密处理等等，使得整个数据库的使用更加方便可靠、运维简易。
数据库上云/迁移是一个生态，而不是一个项目。回顾一下本文分享的所有技术，数据同步与传输技术来做数据库的同步迁移，需要分布式云原生的系统来做弹性高可用，也需要NoSQL做图、时序/时空等非结构化数据的处理，同时需要数据同步/分发到分析系统里面做实时计算分析，还要备份、混合云的管理，以及针对企业数据库研发的DevOps开发流程管理套件。总而言之，只有完整的生态体系才能支撑中国的数据库市场快速发展以及走向全球。
>>> 点此下载《李飞飞：企业及数据库的前世今生》PDF
直播答疑
问题1：企业级数据库与数据中台的关系？
李飞飞：业界现在流行的两个中台是业务中台和数据中台。数据中台它的逻辑就是说自己所在的一个企业，本身的应用可能非常复杂，有不同的App、有不同的用户，那我怎么解决数据孤岛和数据会被打散这个问题？比如说，阿里巴巴里面有不同的用户账号，像淘宝的账号、天猫的账号等等。我们如何通过一个中台把同一个用户在不同平台上的信息能够打通，这样我们能够更好地服务于我们的用户。那么这是一个非常简单的数据中台的概念。在阿里，我们做出来一个所谓的One ID，来支持用户在不同的平台上，它沉淀出来的不同的数据、不同的业务逻辑，它可以通过一个统一的数据处理的中台来进行分析、推荐、可视化等。这是数据中台的一个概念。
那数据中台和数据库是什么关系？数据库是数据中台下面一层的底座。大家可以这样理解：如果要做跨平台和跨应用支撑一个数据中台来处理和分析这些数据，在底部一定要有一个数据库系统。这个数据系统有两个重要的使命：第一个支持上面数据中台做各种各样的在线业务逻辑的处理，像数据可能有更新，可能需要事务的方式去更新数据和实时写入数据；另一个需要采用一个像今天课程中提到的OLAP在线数仓来做这种实时的交互式分析，来支持数据中台做复杂的数据分析。另外还有可能需要像数据湖这种产品和技术去支持数据中台去访问多元异构的数据。
再抽象一点，数据库系统实际上跟业务逻辑是没有关系的。因为它抽象到数据库里面就是读和写以及计算处理。但数据中台是有可能和业务逻辑是有紧密关系的，比如说One ID和用户ID肯定是和业务逻辑有很强的关系，这是从另外一个角度来看。
问题2：数据库和人工智能的方向怎么样？数据库与AI技术结合有哪些案例？哪些具体AI技术在数据库底层系统如何应用？
李飞飞：我觉得有三个维度，第一是说人工智能AI的技术来智能化的管控平台。我们现在数据库实例非常多，系统处理也变得越来越复杂。像NoSQL、OLTP、OLAP，要处理结构化数据，同时也要处理非结构化数据等等。在阿里，管理云上超过了几十万的实例数，集团内也有几十万的实例数，如何去高效和管理这么多的数据库实例？异常发现、异常检测、Slow SQL、MySQL、内存管理等这些都是依赖人工智能技术的。比如说在阿里巴巴集团内部用机器学习和人工智能技术实时去采集所有实例运行的状态，把它的IO/CPO的使用率和它的Workload的特点，去在线建模做8份大小的调整，每一个数据库的实例它是4G、8G、16G。为什么要做这件事？因为随着它一天Workload的变化，它实际上不需要在一天内的任何时候都需要一个非常大的Buffer，可能高峰Buffer要扩，等到峰值过去后Buffer可以缩下来，这样的话就可以把内存资源做一个动态调度。
第二是在内核里面。比如说做内存管理和做查询优化，现在业界也在开始使用一些机器学习的方法。传统使用一些简单的统计方法来做一些内存管理、做查询优化、Buffer Management，比如说LRU 或者 MRU这种非常简单的方式。现在可以看到有一些人工智能和机器学习的方法来做更复杂但是更智能化的、高效的智能化管理，以及CBO这是查询优化里很重要的一块。
第三个维度是说在数据库的应用层，需要对非结构化的数据进行处理，除了结构化的数据。比如说在ADB里面就把非结构化数据先做一个转换，把它从非结构化数据转化到高纬的向量，比如说用 embeddng把这种文档或者是图像甚至像视频都可以把他们映射到一个高维的空间里面，这样的话做一个向量处理引擎，就能把这种非结构化数据变成高维向量，再通过这些高维向量处理引擎把这些非结构化数据和结构化数据在一个数据库引擎里进行联合的查询和分析。这就是用数据库系统来支持AI机器学习和数据处理和 Workload。
总结来讲有两个维度AI或DB，就是机器学习和人工智能技术使得数据库系统更高效、更可靠、更好用。另外一个是DB或AI，就是用数据库的系统来支持机器学习和人工智能的处理。
问题3：网络同步数据库多终端操作不冲突？特别是地理数据库可实现网络同步操作协同编辑？
李飞飞：所谓地理数据库，我觉得提问的朋友指的是跨城或者跨DC、跨可用区域的实例部署。要同时在可用区域跨域、跨城上面同时对实例进行操作，但它有两个实例、两个区域这种。这个叫做异地多活，这确实是非常有挑战的一件事。举个例子来讲，通常不光是改数据还有可能修改表里面的Schema。比如说我这个表，有两个DC都同时它们在两个不同的城市。那么需要在两地都支持我的应用，首先能够动态的增加和删除数据我们的数据；第二我甚至可以允许两边的应用同时修改我的Schema做online DDL 这种事情。如果不做任何的数据库系统或应用改造的话那一定会出现数据冲突的问题。在阿里我们用这种情况用DTS (data transmition service) 至少可以做到异地灾备，一边可以编解一边可以做到实时的数据同步，比一般来说，先解析binlog ，然后把binlog解析过来把数据同步到另外里面的DC数据中心里面去。但这还没有做到多活，没有做到另外一个数据中心同步过去的数据和数据库实时修改然后实现双向同步。这是非常有挑战的一件事，光用DTS那种数据同步工具是做不到的，同时还需要应用对它的整个所有的应用，不论是对它DBA也好还是用户层的应用所有的这些跟数据库相关的操作改动一定要有一个统一的收口在这里一层。在阿里内部叫DMS (data management service) 也是我们云上的一个产品，所有的东西所有的操作都是通过它去做收敛，比如online DDL这种操作，可以确保自身这些变更能够做到同步而且两边没有冲突。这种方案加上DTS，再加上数据库内核本身，像今天分享时讲到的不管是云原生数据库、分布式数据库，它们现在也是大量的使用分布式的数据同步协议像Paxos、raft那它至少可以做在一个可容区里面三节点实时同步，再对跨区域实行在DTS上面DMS实行收口和所有的变更,以上为基本的逻辑和思路。
问题4：云数据的难点和痛点在哪里？
李飞飞：所谓的云数据库，那看它的关键词“云”和“数据库”。 “云”带来的挑战就是资源池化，以及海量的资源的智能化的应用和调度，这是两个最核心的逻辑。做了IaaS（Infrastructure as a Service）以后该资源进行了池化，如果用虚拟化的技术将原来的、割裂的应用资源变成一个很大的池子，怎么样更好的发挥池化资源的优势来做到弹性高可用，我觉得这就是云原生数据库最大的核心价值。所以，像PolarDB它们最核心的设计理念就是存储计算分离，存储计算分离以后，不像传统的数据库存储引擎和计算引擎都bundle在一起的，那在云原生的里面做一个解耦把存储和计算分离，这样可以很好地做到弹性的SQL，而且存储和计算是分开进行弹性收扩容的，最大化利用池化云资源。另外一个就是之前讲到了如何做云原生的管控，像利用K8s这种技术能够做到多元异构的统一管理，同时又用机器学习AI的技术能够尽可能地简化运维的成本，来支持我们资源的调度，这是我觉得云原生数据库最核心的技术和趋势。
“难点”和“痛点”是这个弹性做到弹性高可用里面有很多技术难点。当存储计算分离以后，所有的计算节点都看到的是从逻辑上来讲是一份数据。在写和读的时候还要保证他们看到的数据是一致的，这是一个挑战。还有一个分布式共享存储下存储计算分离以后，用分布式共享存储RDMA，怎么做到高可用？另外一个如果再想水平拓展，光存储阶段分离这里可能做到十几个节点、二十几个节点就差不多了。再往外肯定要将分布式和云原生的技术结合起来。
最后一点就是安全的问题，这里不做展开说明。首先要支持标准的安全协议，比如像BYOK、传输加密，除此之外甚至要考虑在内核处理的时候也要数据全能加密，像我们今天讲到的全加密数据库，还有和区块链的技术相结合。这样我的日志和进库的数据如果用户需要的话，我是可以去验证的，验证它是没有被恶意篡改过的。以上是这些趋势和发展。
问题5：数据库孤岛的问题，导致现在业务数据系统孤岛导致数据的拒通用怎么解决？
李飞飞：我觉得有两个层面：业务层面和系统层面。业务层面我不是很好回答，因为这个业务层面肯定是跟你的业务逻辑有关系的，比如说财务系统和工作流系统，这两个数据要怎么打通？数据打通之后要支持什么样的应用？这些一定是跟你的企业的业务逻辑有强相关性的，它不是一个跟业务逻辑解耦的一件事。所以我没有办法直接说明这个在业务层面怎么操作。
但在系统层面，不根据业务逻辑，一个统一的平台一个接口层可以把一个多元异构的数据。比如说财务系统和工作流系统，甚至可以将两个底层的数据库系统都不一样，财务系统可能用的是一个OLTP的数据库MySQL或者PG，但在工作流系统用的是MongoDB一样的东西，这里面有个解决方案是说可以考虑用数据湖的概念把他们打通，也是我们的一个核心产品，也是业界现在比较火的技术。可以把传统的数据仓库像ADB它是一个云原生的数据仓库和数据湖的概念叠加在一起，可以支持多元异构的建仓然后去做查询和分析。向我们是把ADB和DLA结合起来，像的云原生数据库和云原生数据湖两者结合起来，完美的解决这个问题。DLA可以支持多元异构的数据支持和数据访问，它的特点是数据就可以待在原来的地方，这个是可以考虑的一个方向。
问题6：我们希望投入到PolarDB来做整体去O，咨询现在去O怎么进行？
李飞飞：在课程里面有讲，我讲到亚当Adam。去O我讲了2个层次，第一个是数据库。数据库里面的数据要迁移到一个目标端的数据库，这里牵扯到如何做数据的迁移和同步，可以用DTS来解决，但是去O最关键的不是这个挑战。像DTS支持18种多元异构的数据库作为源，可以同步到十几种不同的数据库作为终端，支持他们的全容量和增量。最关键的挑战还是应用层面的兼容性，原来有很多应用写在Oracle上，现在把库迁走通过解析Oracle的log传输到另外一边，但像Oracle上的应用直接照搬过来会有些兼容性的问题。所以我们做了亚当Adam，这个是帮助企业的应用从Oracle上做迁移。首先，它会自动做一个Oracle扫描的代码生成一个报告，报告会告知用了哪些Oracle特有的存储过程中的语法、数据库现在的语法可能是什么、如果迁移到PolarDB会有哪些问题。有了这些东西来辅助做决策，同时可以节约人力和时间成本。亚当还有一个更高级的功能，对那些不兼容的地方，可以做自动的代码改造。DTS做数据迁移、亚当做应用评估改造，PolarDB来支持Oracle上事务处理的应用、ADB来做出仓整个形成了一个闭环。
问题7：HTAP未来的发展趋势，HTAP会为数据库发展带来哪些技术机遇。
李飞飞：传统的T和A是分开处理的，T和A有冲突。Transaction数据库里面尤其做简单的查询和处理是ok的，比如点查询和事务处理一般不会产生太大问题。原因是它读的数据范围非常小，那数据库里面可能会有几百万的数据库只读其中的几十个和几个，同时进行更新产生的概率非常小，所以TP可以做一些简单的查询和分析。Transaction为了支持更新一般是行存，分析的话可能不大有益。分析数据库一般都是用按列存，按列存好处是在分析的时候只需读需要的几列；第二是压缩带来的好处就是存储成本的降低和对整个IO读取和数据库的处理都会有明显的增强。HTAP在使用的时候，更新的时候用行分析的时候用列，行列转换做好就可以了。说起来简单，做起来难，我们也在思考如何操作。有一个逻辑用三副本的高可用里面的数据数据冗余去做去行业行列转换，这样就可能减少实时的冲突。HTAP我觉得将来一定会是一个热点，很多人认为TiDB是HTAP，但我觉得有待商榷，因为TiDB在实时更新是非常有挑战的。我们要一起努力去把这个问题解决，我觉得将来这一块会是一个机遇点。
问题8：云原生数据库会不会过分依赖某国厂商导致依旧被绑架？
李飞飞：我个人观点是这样的：云原生数据库反而有个优点，可能不像传统的数据库，上云以后反而不用被locking。因为大家看业界像主流的云原生数据库解决方案和产品像我们的PolarDB、ADB像友商推出的云原生数据库，这些数据库他们的架构都非常的相似；因为存储阶段分离它上面是多个计算节点，它底下是一个分布式的共享存储，虽然用了分布式的结构，但其实它是分布式的共享存储，实际上是一个单节点，这样导致它可以做完美的兼容性，去兼容现在完美的数据库生态系统。从用户应用的角度来看，实际上是不可能被绑架的。因为从应用的角度来看兼容度这么高，迁移相对成本是比较低的。
问题9：高并发怎么做？
李飞飞：像传统的数据库，让大家去排队，尽量利用性能，只能一定程度上缓解这个问题。业界上有2种操作，一个是采用云原生的架构，采用存储计算分离，像PolarDB可以做一写多读。现在PolarDB一个实例可以做一个大到接近100T的存储，上面可以做一写多读16个节点。按照当时并发的需求，尤其是对只读并发高的应用，就按量去弹出来的只读节点，一两分钟就弹出一个新的节点，峰值过去之后就可以释放了。
如果写的并发特别多可以采用PolarDB 2.0，所有的计算节点每一个计算节点都可以做写和读。
写和写的冲突问题可以在多写和多读的时候，就要想办法在共享状态这一层。
还有一种解决方法是用分布式，或者有些传统企业用的中间件分库分表或者分布式数据库。因为可以把并发并行的或者分布式放到多个节点上去。这里面也有挑战，挑战非常大，因为一旦对数据进行了分库以后，每个分区都非常容易被并行化。很多时候要做跨区域的查询，依赖两个或三个Partition或者Share上的数据，就需要做跨库的事务处理和查询，这个对系统性能影响非常非常大。但在很多应用场景上，可能并发是很高但做跨库的这种冲突事务的量可能不会太高。
