2021 DTC大会已结束数周，近期忙里偷闲学习下开放的材料。作为年度数据库领域的盛会，可以从中了解到很多行业、厂商、技术等多方面变化。本文从个人比较感兴趣的几个点，谈谈我对此次大会的几点观感。个人观点，仅供参考！
从大趋势来看，数据扮演着愈发重要的作用。无论是从数据规模，还是数据场景上，数据正经历巨大的变化之中，其重要性不言而喻。如上图中描述，将数据提升到战略资源侧面，成为关键生产要素之一。如何更好地获取数据、使用数据、展示数据，进而挖掘数据价值、指导企业发展，成为各企业追求的目标。
面对数字化转型深化，数据使用更加深化和多元。作为数据的主要载体，数据库技术也经历了多阶段变化。如上图左侧显示，一方面架构发展呈现多元化趋势，从单一架构支持多类应用到多类架构支持多类应用。数据使用场景催生架构不断进化演进，从左上图中可以明显看到按照时间线技术架构的阶段性标志。从产品发展来看，如右图所示也经历了从商业、到开源、再到所谓NewSQL的变化。当然，这些产品并不是替代关系，而是相互共存、共同发展，这也导致数据库进入所谓百花齐放的状态。
上述数据库发展多元化的背景，正是来自于对底层数据技术的使用要求不断提高。上图列举了常见的几类问题。如海量数据规模的承载问题，如何满足数据量爆炸式的增长？这一诉求也催生了分布式、云原生技术在数据库领域的实践。如对数据时效性更高的要求，催生了诸如HTAP、流式计算等技术的实践。第三如多源异构技术栈的问题，天然带来的复杂性阻碍了数据使用，这也促进了数据湖、HTAP、数仓升级等技术革新。也正是上述对数据使用诉求的变化，催生了大量新兴技术的发展演进，促进新产品不断涌现，整个行业也呈现百花齐放的发展态势。
上面谈到对数据使用上的诸多来自场景的变化，催进技术演进发展。与此同时，作为数据库的使用者来说，也呈现出较为分化的特征。上图是非常好的一个总结，从数据库市场角度细分出典型客户，下面简述下各类用户的特点。
第一类客户是“互联网中小客户、开发者”，这类客户对数据库的整体要求是最低的，能满足基本数据库使用即可。其通常不具备或只具备少量专职运维人员，核心诉求是提供免运维、可快速支撑业务发展的系统。这部分是属于所谓长尾类的用户，客单价不高且数量众多，通过标准化的公有云形态交付是比较合适的选择。
第二类客户是“泛互联网、中小型企业”，相较于前者来说，这类用户对数据库的要求更高，但自有技术能力又有所不足。其通常是通过ISV提供数据应用、通过IPV提供基础运维能力。核心诉求是性价比和通用性，通过借用外部力量满足发展诉求即可。这类用户数量也非常巨大，且具备一定行业属性。从承接方式来看，未来通过标准化公有云是较为合适的，但目前自建（采购）与上云共存居多。
第三类客户是“互联网大客户”，这类客户是往往大家感受最多的用户，都是头部互联网企业和部分互联网化较为彻底的行业头部用户。这类用户的数据库使用要求很高，在数据规模、吞吐量、弹性、性价比、自主可控上均有自己的要求。其通常具备一定规模的自有运维、甚至代码研发能力。从承接方式来看，公有云甚至自建都是可选的方案，从技术本身来看多为开源或自研数据库产品。
第四类客户是“传统大型政企客户”，即所谓的大B、大G端客户，覆盖面非常广泛。这类客户对数据库的要求最高，不仅表现在于互联网用户类似的诉求外，还包括在数据安全、自主可控、高可用性等特殊要求。这类用户体量巨大，且数量众多，可以说是各厂商争夺的优质来源。从承接方式来看，受到诸多因素限制，专有云成为其重点考虑方式。
作为越来越多用户的选择，云已经成为主流的部署方式。作为一种新的资源供给方式，其颠覆之前方式的种种弊端，带来标准、灵活、低成本、高弹性的诸多优点。然而用户在选择时，受限于资源、安全、监管、成本等因素，选择公有云存在一定困难，于是专有云、混合云成为有益的补充。上图将这三种云形态做了总结，为用户选择提供一种参考。其通过统一技术、统一体验、统一管理的原则，提供灵活的云端组合方案。
作为现有产品交付方式的补充，上文提出所谓第四种形态（即开箱即⽤的开源数据库发⾏版）。相较于其他三种方式，购买商业版本（或开源数据库+商业管控）、自建运维+开源数据库、云数据库之外，这种方式通过对开源数据库的封装，提供简运维、低成本、全功能、优体验的产品定位。其针对广大互联网客户、中小规模传统企业、ISV及个人用户等均具备不小吸引力。
❖ 数据虚拟化
如上面所讲，数据技术呈现多元化的趋势，人们不得不通过引入多个技术栈解决数据问题。从应用角度来看，就不得不面对上述复杂的情况。如何能简化构建应用，打破数据和应用壁垒，快速实现数据价值，数据虚拟化技术应运而生。这一技术通过标准统一入口，简化应用使用数据方式，通过协同调度下层异构存储和计算引擎实现数据协同计算，避免数据搬迁带来的高成本和低时效问题。
在具体实现上面，上面给出一个参考示例。上层通过标准SQL接口，屏蔽异构数据源的访问差异，简化应用开发难度，提升效率；下层则通过统一高性能MPP处理引擎，提供高效能的计算能力。针对这一技术，个人还是比较看好的。虽然当前有很多融合类技术方案/产品出现，希望通过all in one的方式解决所有问题，但在全场景、复杂多变、高性能等诉求下，独立产品解决某一场景问题还是大量出现。此时，数据虚拟化带来的便捷、标准等优势仍大有市场。
❖ 运维自动化
作为数据库领域标杆性企业，Oracle一直是各家学习模仿的目标。我们看看Oracle在近些年来的发展历程，不禁发现其在近些年的重点正是自动化特性能力。从早期的9i、10g到最新的21c版本，Oracle在全方位地提升数据库自动化能力，其倡导的自治化、无人驾驶数据库正是上述体现。其背后深层次的原因，是随着数据库的功能日益强大、架构体系复杂，对管理、使用提出更高的要求。如何降低这一门槛，自动化无疑是有利抓手之一。
从上图可见，在自动化领域的功能侧重，重点在性能、运维相关领域投入很多。
❖ 数据智能化
AI与数据库结合，能产生怎样的火花呢？上图给出了两类方向：一种是AI4DB，即通过AI手段，提升数据库在管理、性能等方面的能力，实现自动化管理；一种是DB4AI，即通过数据库之一数据存储与计算平台，提供增强的AI计算能力，满足对数据更多计算需求。
这里以openGauss为例，看看其在AI4DB方面的能力，重点在信息收集、异常检测、诊断自愈、智能推荐等方面。国内有很多产品都在加强这方面的能力建设。
上面描述openGauss在DB4AI方面的实践，从整个数据加工过程描述这一过程。针对用户，对外提供SQL语法，易学易用；还内置了全流程AI框架，数据库不出库，安全高效。
❖ 数据安全
数据安全，是近年来热门话题。上图描述数据全生命周期内，如何做到数据安全。从数据传输、数据计算、数据存储三个角度谈到加密问题，其中重点提到了数据计算的加密问题。相较于数据传输、数据存储，数据计算部分的安全相对是个短板。这也就引出后面的密态计算问题。
这里解释了密态计算的原理，在底层数据库提供的数据加密和密态计算能力。从应用角度来看，应用与数据库之间的数据交互有都是加密状态。在内部实现上，有软件密态内核REE和硬件可信执行环境TEE方式。
这里有个示例，说明其工作原理如何。业务方提交明文的查询语句，在客户端通过KMS加密，传输加密后的请求到数据库；后台数据库通过REE和TEE完成密态计算，并将加密后的结果返回前端后解密。整个访问过程，均实现了加密处理。
上图谈到另一种数据安全解决的方式。当面对多种数据源，复杂权限控制场景下，通过权限中间件模式，收敛统一标准化权限管理，对内提供一致性的全局安全视图。并可在这一基础上叠加更多安全能力，如访问审计、安全脱敏、敏感阻断等，进而提供统一的安全交互界面。
❖ dbPaaS
dbPaaS，旨在解决面对众多数据库产品统一交付问题。对于云上用户来说，云很好地完成了从资源交付、运维管控、诊断优化、故障处理、高可用等问题；而对于云下用户来说，是需要自建这一能力。dbPaaS的出现就是满足这类用户的诉求。其屏蔽不同数据库的差异，通过图形化、标准化的交互界面。重点发力方向，在于自动化、智能化、敏捷化方向。
❖ DBaaS
DBaaS，Database as a Service，其将数据库能力抽象成服务提供出来。上图判断出其发展历程，可以说走过了从云托管、云服务、云原生之路。
云托管，是最接近传统数据库系统的部署模式。本质是将原本部署于IDC机房内物理服务器上的传统数据库软件部署在了云主机上。这种模式下，云平台提供诸如高可用、异地灾备、备份恢复、数据安全、SQL审计、性能优化和状态监测等企业级数据库管理能力，用户可减少运维投入即可享受之前同等的服务水平。
云服务，之前的托管架构中，受限于传统数据库架构的局限，未能完全发挥云计算的优势。在诸如弹性扩展、高性能、高可用等方面，均有不足。到了云服务时代，充分利用云基础设施的底层能力，提供定制化的数据库产品。
云原生，与之前的云服务架构不同，这一阶段产品将更为充分地利用云基础设施的能力，通过多层资源解耦，可享受云带来的弹性扩展、按需供给、超大规模能力。真正做到了数据库与云的深度结合。
❖ 湖仓一体
湖仓一体，是近年很火热的一个词。数据仓库与数据湖的融合是大数据技术发展的必然趋势；对象存储、计算存储分离和云原生架构在湖仓一体演进中扮演着重要角色；基于云原生湖仓一体构建的数据共享、融合、流通和交易平台将重构企业数据分析的基础。上图中给我们对了传统数仓与数据湖的区别。这两项技术正在逐步融合。
❖ HTAP
上述描述了，我们对数据业务负载处理技术的演进。从早期的只关注OLTP数据，到通过ETL过程做数据迁移，在独立两套技术栈OLTP和OLAP解决问题；再到数据规模增大，通过拆分多组OLTP保证性能，然后汇聚到底层统一OLAP；最终到all in的HTAP方案中。当然，这是一种较为理想的方式，数据无需移动，所有数据都是鲜活的原始数据，无需多副本拷贝，时效性高。
从HTAP实现技术来说，分为多种类别。如果采用不同技术栈，即为最左侧的这种方式，这一方式最为成熟，但需要用户自己构建多技术栈及数据复制。当然有些可优化之处，例如提供统一的应用接入，屏蔽底层TP与AP的区别并将数据复制自动化，对外保证复制的延时可控，也不失为一种好的方式。通过在同一技术栈解决HTAP问题，又分为两种：一是不同存储结构，内部实现复制，这种方式较为主流；另一种是统一存储引擎，实现不同计算能力，这部分还属于较为前沿领域，尚待突破。
韩锋频道：
关注技术、管理、随想。
长按扫码可关注
