Hello大家好,我是人月聊IT,今天准备简单跟大家聊一下数据存储架构里面的TP/AP一体化问题。
在聊这个之前,我们首先还是要谈一下OLTP和OLAP。
OLTP叫联机事务处理,而OLAP则是联机数据分析。联机事务处理更多针对的是业务事务操作,业务处理的系统,比如采购系统、库存系统、营销销售系统;而OLAP更多偏联机数据分析,它对应的类似于数据中台或者是传统的BI系统、大数据分析系统。
那么为什么原来TP和AP的数据存储没有一体化?
简单来讲,就是原来通过烟囱式的方式建设了多个业务系统,每个业务系统都有自己的数据库。然后需要通过ETL或其它数据采集集成工具,将这些数据进一步采集汇聚到分析型数据库里,再基于这个分析型数据库进行数据建模。在这种情况下,TP的数据库和AP的数据库完全是独立两套数据库,而是是分开进行规划和建设。
那么为什么要这样做?其中有三个关键原因。
其一是AP的数据库往往涉及多个业务数据库的数据关联和整合。比如我现在要输出一个合同执行的数据,往往需要关联整合来自合同,采购,库存,财务多个业务系统的数据才能够最终得出。
其二是AP的数据库为了分析方便往往涉及到横向数据分层并进行冗余。类似我们常说的数据仓库模型中有底层的贴源层和ODS库,也有上层的宽表层,再上层的数据分析层和维度建模层(维度表和事实表)等。
其三是AP数据分析往往涉及到批量和大数据,对底层数据存储架构要求不同。比如对于分析型数据库往往涉及分布式存储、MPP列式数据库等,这些都是AP数据库的关键特点。
现在回到TP/AP一体化是否可行的问题。
我们来看阿里近几年强调的OceanBase数据库,它强调基于HTAP(混合事务分析处理存储架构)实现了TP/AP一体化。这个数据库一体化后,做数据分析时不用再做额外的数据采集集成操作。
虽然这种一体化数据库本身有用,但是作用更多局限在单个业务应用系统里。
举个简单的例子,我们自己做的集成平台,每天接口调用日志3000万条,一年数据量上百亿。查这些历史日志,对日志做分类统计,传统结构化数据库很难做。原来需要把数据采集集成出来,放到HBase数据库或ClickHouse的MPP数据库后再进行统计分析。那么现在类似OceanBase这种一体化数据库可能就解决了这个问题。
对于OceanBase的技术文档提到两种模式:轻量级数据分析,存储架构是传统的横向存储;重数据分析模式则底层存储架构同时存在行存储和列存储两种方式。行存储转列存储是基于数据库内部底层数据同步复制完成的,对开发者和用户透明。面对大数据分析时,仍然采用分布式存储列式存储架构模式。
所以,不要简单理解TPAP一体化只有一种存储架构,它底层是混合存储,对用户透明。这是我们讲的一体化存储架构。
再讲一个关键点,对整个企业的数据中台、大数据分析平台或企业级BI建设,这不是单个应用能涵盖的,涉及多个应用的数据采集汇聚、整合关联。这种情况下,如何做TPAP一体化也是一直困扰我的问题。
最近一两个月在微信群交流时,总有人提到有产品成功实践案例解决了这个问题。我其实很系统大家能够分享企业整体应用和数据架构级的一体化解决方案。因为至少到现在为止,我没有看到实际解决这个问题的案例。
具体原因主要体现在以下几个方面。
第一个关键点:跨库数据整合问题
首先企业级分析型应用涉及跨库数据整合时,如果没有通过ETL进行数据二次落地,那必须在内存中进行数据流处理和编排,这个复杂度相当大。其次数据没有二次落地,如何基于底层共享数据存储进行数据维度建模,这也没办法做。
所以,跨库的TPAP一体化,我理解是一种折中方式,即虽然也会做数据采集整合或内存中的数据流编排,但整合加工完的汇总数据统计数据需要二次落地,对于追溯的源数据,没必要再采集落地。(也就是我强调的在这种一体化架构下,底层的贴源层是否没有存在的必要以增加二次采集集成)
这是实现TPAP一体化的一个关键点,并不是完全没有数据采集和集成,而是基于AP数据分析要求,对数据进行了分层。在数据分析型库中,只从上层宽表数据或维度表建模数据,而不从最底层原数据。
第二个关键点:统一DaaS层进行数据转发路由
由于数据存储本身分开了,但对上层分析应用来讲,也是透明不可见的。所以,这种架构下,上层还会建一个大的数据总线,类似于数据路由,基于数据分析需求将请求路由到不同数据存储库,间接实现底层数据存储的逻辑统一。
这也是在做TPAP一体化时,经常考虑的一个关键点。即虽然底层的数据是分布式的,但是数据暴露给上层的访问变成了统一出口。
基于以上讨论,简单总结就是对单个应用,可以谈TPAP完全一体化,因为单个应用可能涉及数据分析、加工统计;但从企业级来讲,很难实现完整的TPAP一体化。很多时候在线事务处理数据库和分析型数据库仍然同时存在,只是在上面增加了相关的数据访问层。
好了,今天关于数据存储架构里TPAP一体化的思考就到这里。