海山数据库（He3DB）数据仓库发展历史与架构演进：（一）传统数仓

从1990年代Bill Inmon提出数据仓库概念后经过四十多的发展，经历了早期的PC时代、互联网时代、移动互联网时代再到当前的云计算时代，但是数据仓库的构建目标基本没有变化，都是为了支持企业或者用户的决策分析，包括运营报表、企业营销、用户画像、BI分析等。

广义上看数据库仓库并不是一项技术或者产品而是数据处理过程，从不同的数据源进行数据汇合，然后经过数据的统一建模成适合于分析的数据模型，最终辅助企业的决策分析。这个过程涉及到ETL、数据建模及数据可视化等一系列实现，这也是与数据库的本质区别。

随着计算机科学技术发展与产业变革，数据仓库在应对从数据特征呈现多样化、海量化到业务特征复杂化、智能化及实时化等，再到基础设施(存储、网络及计算资源)能力的提升、云计算技术的发展等变化，数仓的整个体系也在持续演进中，这里从数据仓库的系统架构及内核引擎的实现角度去分析数据仓库的发展过程，基本上如下图所示：

从数仓的核心能力去分析各个阶段实现的变化，我将重点分析以下几个方面：

存储引擎：主要是数据的组织方式，定义了数据如何存储及压缩、索引的创建和更新、锁机制、事务及缓存管理等。在数仓中数据是面向主题的将数据进行整理归纳和重组，这是提高数据分析性能的核心，在分析过程只需要处理部分维度的数据，并且大量的统计任务需要进行数据的扫描或者精确检索，因此存储引擎的合理设计是数仓架构发展的重要部分。
计算引擎：分析型任务涉及到大量的计算，计算效率往往会成为数据库系统的瓶颈，计算模型（框架）、优化技术、和运行中间数据的处理等都是数仓演进的突破点。MPP计算、分布式流计算、分布式批计算等都有相应的使用场景，在具体的算子执行过程中向量计算、编译执行及硬件加速技术等都是近年有效的提升性能的方法。
技术实现架构，数据库可以基于功能分为存储、计算及管理等层次，这些功能的运行机制影响着系统的灵活性、可运维性、成本及分析的性能等。云计算的出现为数仓架构的演进提供了新的方向，赋予数仓获得自服务、弹性等能力，同时目前企业将基础系统、平台部署到云端降低信息化建设成本及优化运行管理流程等成为趋势。

数据仓库的演进变革的因素有很多，例如快速的业务模式与群体规模的数据量带来的大数据处理技术、互联网的发展带来的数据源及数据类型的增多、人工智能的发展带来数智的融合、云计算交付模式的出现需要的细粒度的资源管理与隔离等，业务实时性的要求等都会带来数据仓库架构的变化。本文将分三章分析不同阶段数据仓库的核心特性的变化，包括传统数仓、大数据数仓、云数仓，并逐一进行讲解，本章主要介绍传统数仓。

初代数仓(单体分析型数据库)

这个阶段是数据仓库概念提出后，数据库厂商传统数据库的基础上结合数仓方法论提供的数仓产品。在这个阶段数仓的数据来自于CRM、ERP等业务数据，数据量小多GB级别，数据类型基本上是结构化数据，而且产生的周期按天或者周为单位，因此对数据仓库的要求不高，基本上是单机（性能较高的商用主机，例如中小型机器）分析型数据库，以Oracle、DB2、SQL Server、SybaseIQ等为代表。

这些数据仓库产品从本质上是关系型数据库，使用ETL工具实现多种异构数据源的有效集成与处理，并按照主题的方式进行数据进行重新整合，即按照数仓的维度模型进行归一化构建。这些数据库的设计是为了决策分析而进行的，例如使用位图化索引、按列存储、数据压缩及与众不同的锁机制，这些特性都极大提高了查询引擎的性能。这个阶段的数据仓库主要集中在金融、电信、大型零食及制造等行业。

传统MPP数据仓库

随着业务的发展，单机数据仓库的数据存储和计算模式不能满足大量数据处理的需求，在这个背景下基于MPP架构的数据仓库成为主流的解决方案，这阶段的数仓产品以在2000年代后出现的Teradata、Greenplum、Vertica等为代表。MPP(Massively Parallel Processing)，大规模并行处理架构，更适合于复杂的数据处理和综合分析，典型实现如下图所示：

这种架构主要的特征如下：

Shared Nothing，节点之间不共享存储、计算资源和磁盘，节点之间仅通过网络通信。
数据按照特定的规则进行本地化存储，例如基于特定分布式键上按照Hash规则分布到全部节点上。
完全对称的并行执行策略，每个节点都参与计算，并且节点上执行的任务逻辑完全一致。
任务按照流水线的方式进行组织执行，任务之间数据的传递以流水线的方式来进行，数据的流转在内存中进行，避免了数据积压的时间开销。任务的流水线执行使得MPP数据库具有优异的性能。

这种架构可以实现横向扩展的方式，使用普通主机就可以构建较大规模的集群系统，通过并行化来实现快速的分析任务的快速执行，同时更具有成本优势。

在这个阶段的MPP架构在技术实现基于传统数据库实例进行扩展，例如Greenplum、ADB for PG等都是基于PostgreSQL内核进行开发，在集群中每个节点都是一个独立的数据库实例，具有独立的系统表、用户表等，数据是按照某种策略分布到不同的实例中。客户端在发起请求后由管理节点生成查询计划并进行并行化调度，当涉及到多个节点的数据交换时，例如HashJoin的执行，引入数据交换算子，如下图所示：

管理节点分布到每个节点的查询计划是相同的，在执行时如果需要每个节点扫描自己所在节点的数据，当需要进行数据交换时调用Motion算子发送到其他节点，例如Join计算中符合过滤条件的右表数据，最后在管理节点上通过GatherMotion进行查询结果的汇总。

MPP数仓它是整体向外提供服务，每台节点无法单独运行局部数据，数据在存储时通过一定的策略进行分布，存储位置是不透明的，因此在执行任务时由于无法断定数据的位置，导致任务会在所有节点上执行，同时在计算过程中涉及到锁、事务、内外存交互等问题，所以当数据达到一定规模后就会出现性能的瓶颈问题。当集群或者数据量达到一定程度后，节点的故障成本较高，查询任务在某个节点故障时需要重启整个任务。

另一个缺点是存算耦合的架构，节点进行扩缩容时需要进行数据的重新分布，整个操作的过程会由于耗费大量IO请求引起业务处理速度的下降，影响客户的正常查询需求，最后是无法动态适应业务的发展。对于不同的请求，例如导入类任务耗费大量IO、网络带宽，但是CPU的使用率较低。复杂的查询任务CPU的资源消耗非常大，因此资源规格的需求是不同的，但是MPP架构很难满足这些需求。因此这种架构的数仓集群的规模不能太大，适用于中等规模的企业数据处理场景，通常不超过数百级别，因此支持的数据体量很少超过PB级别。