OLAP

在数据仓库一章中我们讨论了数据仓库及其模型的概念,而数据库与数据仓库的区别实际讲的是 OLTP 与 OLAP 的区别。操作型处理,叫联机事务处理 OLTP(On-Line Transaction Processing),也可以称面向交易的处理系统,它是针对具体业务在数据库联机的日常操作,通常对少数记录进行查询、修改。用户较为关心操作的响应时间、数据的安全性、完整性和并发的支持用户数等问题。传统的数据库系统作为数据管理的主要手段,主要用于操作型处理。分析型处理,叫联机分析处理 OLAP(On-Line Analytical Processing)一般针对某些主题历史数据进行分析,支持管理决策。

OLAP 与 OLTP

在互联网浪潮出现之前,企业的数据量普遍不大,特别是核心的业务数据,通常一个单机的数据库就可以保存。那时候的存储并不需要复杂的架构,所有的线上请求(OLTP, Online Transactional Processing) 和后台分析 (OLAP, Online Analytical Processing) 都跑在同一个数据库实例上。后来渐渐的业务越来越复杂,数据量越来越大,DBA 们再也优化不动 SQL 了。其中一个显著问题是:单机数据库支持线上的 TP 请求已经非常吃力,没办法再跑比较重的 AP 分析型任务。跑起来要么 OOM,要么影响线上业务,要么做了主从分离、分库分表之后很难实现业务需求。

在这样的背景下,以 Hadoop 为代表的大数据技术开始蓬勃发展,它用许多相对廉价的 x86 机器构建了一个数据分析平台,用并行的能力破解大数据集的计算问题。所以从某种程度上说,大数据技术可以算是传统关系型数据库技术发展过程的一个分支。当然在过程中大数据领域也发展出了属于自己的全新场景,诞生了许多新的技术,这个不深入提了。

由此,架构师把存储划分成线上业务和数据分析两个模块。如下图所示,业务库的数据通过 ETL 工具抽取出来,导入专用的分析平台。业务数据库专注提供 TP 能力,分析平台提供 AP 能力,各施其职,看起来已经很完美了。但其实这个架构也有自己的不足。

HTAP

首先是复杂性问题。本身 ETL 过程就是一个很繁琐的过程,一个例证是 ETL 做的好,可以成为一个商业模式。因为是两个系统,必然带来更高的学习成本、维护成本和整合成本。如果你使用的是开源的大数据工具搭建的分析平台,那么肯定会遇到各种工具之间的磨合的问题,还有由于各种工具良莠不齐所导致的质量问题。

其次是实时性问题。通常我们认为越接近实时的数据,它的价值越大。很多业务场景,对实时性有很高的要求,比如风控系统,它需要对数据不停的分析,并且在险情出现之后尽快响应。而通常的 ETL 是一个周期性的操作,比如一天或者一个小时导一次数据,数据实时性是没有办法保证的。最后是一致性问题。一致性在数据库里面是很重要的概念,数据库的事务就是用来保证一致性的。如果把数据分表存储在两个不同的系统内,那么很难保证一致性,即 AP 系统的查询结果没有办法与线上业务正确对应。那么这两个系统的联动效应就会受到限制,比如用户没办法在一个事务里面,同时访问两个系统的数据。

由于现有的数据平台存在的以上局限性,我们认为开发一个HTAP(Hybrid Transactional/Analytical Processing)融合型数据库产品可以缓解大家在 TP or AP 抉择上的焦虑,或者说,让数据库的使用者不用考虑过度复杂的架构,在一套数据库中既能满足 OLTP 类需求,也能满足 OLAP 类需求。