屡破记录！国产数据库何以后来居上？

资讯作者：CSDN 2021-10-18 15:55:07 阅读：482

【CSDN 编者按】近年来，国产数据库除了在各类排行榜上刷新纪录外，混合式HTAP数据库也逐渐迎来发展的春天。做出既能联机交易，又能作数据分析的混合式数据库，将是国产数据库由跟随潮流到引领时代迈出的重要一步。

作者 | 雷涛

出品 | 《新程序员》

直到21世纪初，我国数据库产业发展还比较缓慢，基本处在西方数据库博览会的状态，很少有拿得出手的国产数据库产品。1989年，Oracle决定进军中国，恰好赶上中国电信建设“九七工程”的风口，在顺利拿下东北三省邮电管理局的大单之后，Oracle在中国市场站稳了脚跟。后来Sybase于1991年进入大陆，IBM随后也带着Db2、Informix等数据库产品大举入华。在这之后的十几年时间里，中国数据库市场格局逐渐成形，金融行业中以Db2、Sybase为主，电信、电力行业中则基本由Oracle一统江湖。

然而，风云起，时代变，一切局势都在潜移默化中开始扭转。以十年前的开心农场偷菜场景为例，随着C端客户爆炸式增长，中国IT人瞬间意识到，传统西方的IOE（IBM小型机、Orcale数据库、EMC存储）技术架构根本无法支持如此海量的并发，而由IOE带来的高昂IT支出也令人瞠目结舌。正是在这样的大背景下，核心技术的自主掌控成了业界共识，打造自己的数据库成了中国程序员们的梦想。

雷涛对HTAP数据库的深入解读

近十年来，我国在数据库领域真正做到了厚积薄发。从单节点到分布式，从单一用途的TP、AP库到混合式HTAP，从独立的数据仓库、数据湖到湖仓一体，从SQL、NoSQL再到NewSQL……可以说，数据库的各方面都迎来了突破性进展。

下面，本文就HTAP数据库进行深入解读。

Google File System、Google BigTable、Google MapReduce——这三驾马车是现在大数据平台Hadoop技术的基石，不仅支撑了新一代分布式架构体系，而且实现了海量数据高效存储和快速计算。2012年，Google发表了一篇论文——Spanner: Google’s Globally-Distributed Database，将同时支持大数据量下做事务交易的数据库提取出来，既支持TP的操作，也可以在上面作一些分析类的操作。在Google提出Spanner架构的基础上，2014年，Gartner对HTAP进行了正式定义，这便是混布式数据库的产生缘起。

目前，数据库基本分为两大流派，一个是非关系型（NoSQL）数据库，一般使用KV技术，主要用于用户画像、业务报表等海量数据挖掘的AP场景。另一个是关系型数据库（SQL），针对个别记录增、删、改、查的速度很快，一般用于联机交易的TP场景。简而言之，TP库处理速度快，AP库处理数据量级高。

之前，AP与TP的应用场景井水不犯河水，相互之间没有太多交集，然而随着数字化转型的不断深入，直播带货这样的新场景不断涌现，在直播过程中既需要处理联机交易，又需要对客户进行实时画像，而传统单一TP或者AP数据库难以应对这样的混合式场景。近几年来，某些国产混合负载数据库以行列混存方式，打破了AP与TP两种场景之间的鸿沟。

数据的神奇旅行

在梳理数据存储模型演进历史后，明显可以发现这是一个随着数据量级不断扩大，数据模型在不断变换的过程。

目前我们提到的数据库一般都是指关系型数据库，从关系型的视角来看，数据库被定义为工厂的车间，数据则是原材料。车间为了进行原材料加工，部署大量的操作设备，原材料也会随时被重塑修改，从建模原理上可以看出TP数据库的数据加工车间适合快速零件加工，但不适合进行大量材料的储存。

而关系型TP数据库在大量数据存储方面的短板直接催生了Hadoop等大数据技术的革命。从大数据视角看，AP数据库自身就是储存仓库，而数据已经是加工完成的成品，没有被重塑、修改等的更新需求。比如在Hadoop技术栈中的HDFS存储实现，就是所有数据只能写入一次，无法修改，这其实是牺牲数据的写入和更新特性，以换取海量数据的储存与查询性能的做法。

而随着大数据应用的进一步拓展，业界发现价值密度更低的非结构化数据也有储存及挖掘的必要。比如客服的对话方式可能是语音、文字甚至是图像、视频，这都不是传统意义上数据库、数据仓库可以处理的结构化数据，因此用于储存非结构化的数据湖出现了，在数据湖中数据标准化、结构化的特性也退化了。从关系型数据库到数据湖，各种大数据技术栈相互独立，但随着移动互联网时代的到来，这种情况发生了改变。

联机性能和实时分析真的是“鱼与熊掌不可兼得”吗？

权威咨询公司IDC对于大数据的定义是：满足种类多（Variety）、流量大（Velocity）、容量大（Volume）、价值高（Value）等指标的数据称为大数据。从历史来看，在谷歌提出大数据三驾马车的论文时，当时的关系型数据库技术就难以处理大规模的数据。而在当下各行各业不断上云的大背景下，数据的量级必然还将不断创新高。从我了解到的情况，整个IT行业存储的数据量级正在以年化80%左右的速度增长，传统SQL数据库难以处理这样的数据量。

很多用户在实际工作中也会把大表关联的查询任务放在传统TP数据库上进行，这样的查询虽然效率很低，但考虑到从TP数据库导入AP数据仓库所需要的超长时间，直接在TP数据库上跑查询可以理解。其实，这个例子也深刻说明了目前大数据技术栈面临的窘境，各个TP与AP数据库像是一座座数据孤岛，打破孤岛之间的边界简直比登天还难。正如前文所说，SQL与NoSQL两种产品底层构建模型并不相同，彼此兼容性不佳。想保证联机交易处理时效，就要牺牲数据分析的性能，而想要实时数据分析，快速完成用户画像就不能再依靠原有技术栈。

处理时效与实时用户画像的平衡可能是数据库工程师与产品经理之间永远无法达成的协议。目前大多商业银行都使用以Oracle为代表的TP数据库作为核心系统，但Oracle只能处理流程性的交易数据，不能做数据挖掘。要想把数据价值做二次表达，就需要每天做ETL，跑批作业，存到数据仓库中。然后在数据仓库中建模、挖掘、数据集市、ODS，一层一层地构建起数据仓库报表。

如果还是回答不出更细节、隐含的问题，比如非线性问题，还要把数据复制到SAS中做机器学习，再做统计的指标体系，去进一步挖掘。数据要在这里搬动三次，复制三份冗余，还要管理数据一致性，每天数据中心运维的大量工作都在做数据迁移。而数据在这种低效的转运迁移过程中，很多价值就白白消耗了，且正如前文所说，TP与AP两套体系的组件兼容性很差，能让两大体系协同工作已属不易，如果再考虑灾备高可用方面的需求，则是难上加难。

行列混存—混合负载的正确打开方式

目前，各行业数据中心都迫切寻找一栈式解决方案，通过屏蔽大数据技术底层组件的差别，寻找“All Data In One”的解决方案，只有如此才能降本增效。

TP与AP的巨大差异，在于行存与列存在不同使用场景下的效能表现。在计算机世界中，数据吞吐速率往往受数据访问局部性原理支配。我们知道，现代硬盘、内存工作原理是当用户读某一区域的数据时，其邻接的数据也会被调入上一级高速缓存，读1KB数据和连续的64MB数据的代价基本相同，用户在读取连续的磁盘或者内存信息时，其速度往往比随机读取快一个数量级。因此，行存储大多用在SQL的TP场景，而列存储基本用在NoSQL的AP场景。

这背后的原因也很简单，还是以银行业作为案例，在联机交易的TP场景下，比如当客户取款时，会校验用户、账号、密码、余额等信息，这些信息都是以“行”为单位存储的，联机交易中的数据经常是以“行”为单位访问的，把数据放在一行就会有访问速度的优势。但在统计、分析营业报表，进行数据挖掘等AP场景下，往往只需要关注交易金额、账户余额等少量维度的信息，而不需要用户、账号、密码等数据，在这种场景下，将同一维度信息放在一起的列存储方案就有很大的速度优势了。

将行、列进行混存，综合两者的优势，这方面业界也有不少尝试，但往往都不是很成功，最大的问题还是在于性能。对于联机TP交易场景来说，列式存储的写入性能太低了。所以一般来说，传统的方案往往还是退化成为行式存储TP数据库，在交易量少的日终结算时刻，将数据吐给列式存储AP数据库进行数据挖掘。

如图1所示，逻辑上，业务场景主要分为两类：联机交易OLTP和数据分析OLAP。HTAP数据库不仅支持使用SQL进行传统的关系模型计算，更是将图计算和AI建模纳入了逻辑计划中，可进行高阶计算。在数据存储层，通过行列混合的方式，按需支持OLAP和OLTP场景，这样就做到了一种存储架构兼容所有场景。

图1 HTAP数据库架构图

这种逻辑计划及存储融合，也称“All Data In One”，是对数据库基础底座的重新定义。在资源调度层，通过AI-Native的方式探查出需要使用的调度引擎，并在实际计算时，做好资源隔离。这种架构可以更有效地支撑数据计算，最终实现一个数据库融合所有场景的终极目标。相信未来的国产HTAP数据库，还将继续朝着“All Data In One”的道路前进，发展特色不断创新，降低系统运维成本，发挥数据的最大价值。