数据仓库概述

最近开始接触数据仓库，要了解一项技术或者一个工具，就得先去了解它在某个链路中所处的位置，以及它的出现是为了解决什么问题，那么就有了这篇文章，从数据仓库的诞生环境、所能解决的问题以及主流的上层架构，简单介绍了数据仓库这项技术。

产生背景

数据仓库的诞生离不开环境的因素，在数据量加剧的当今社会和数据分析挖掘需求日益增加的环境下，传统面向业务的MySQL、Oracle等OLTP型数据库已经不能满足当下一些特殊的需求。OLTP型数据库主要是解决业务需求，构造也具有遵循3NF范式，避免冗余等特点，但这些特点在面向分析的时候却成了导致效率低下和诸多限制的瓶颈。那么数据仓库这种OLAP型数据库就应运而生了，它不同于传统OLTP数据库，构造思想是反范式并且有冗余的，并且是一个面向主题的、集成的、非易失的且随时间变化的数据集合，目的是为了在面向分析或者数据挖掘的场景下提高效率或者简单易操作。

数据仓库概述

既然数据仓库诞生的目的是为了解决主题分析或者数据挖掘这类问题，那么分析或是挖掘就是数据仓库的终点，起点则是所需要的各种数据，这些数据可能来自不同的地方，有 MySQL、Oracle 等结构化数据，也可能有 ES、MongoDB 等非结构化数据，也有可能是文件等等。数据经过起点，通过抽取、清洗转换、加载（ ETL ）之后进入数据仓库，最后再由分析或是挖掘需求进行消费，形成了数据产出、存储、加工、消费的一条链路。

数据库是面向事务的，属于 OLTP（在线事务处理），主要操作是随机读写以及事务支持，在设计时尽量避免冗余，常采用符合范式的规范来设计；而数据仓库是面向主题的，属于 OLAP (在线分析处理），主要操作是批量读写，关注数据整合，以及分析、处理性能，会有意引入冗余，采用反范式设计。关于数据库和数据仓库的比较如下表所示：

	数据库	数据仓库
面向	事务	分析
数据类型	细节、业务	综合、处理过的数据
数据特点	当前的、最新的	历史的、跨时间维度
目的	日常操作	长期信息需求、决策支持
设计模型	基于ER模型、面向对象	星型/雪花模型，面向主题
操作	读/写	大多为读
数据规模	GB 到 TB	>= TB

数据仓库技术实现

对于数据仓库的选型一般得考虑适用环境、数据规模、数据来源、吞吐量和数据消费者的类型等，这些都是决定选取哪种架构的数据仓库的因素。一般从数据规模来分有两种技术实现方法，一种是传统数据仓库-- MPP（大规模并行处理）集群，一种是大数据数据仓库。

MPP数据库

MPP数据库是一款 Shared Nothing 架构的分布式并行结构化数据库集群，具备高性能、高可用、高扩展特性，可以为超大规模数据管理提供高性价比的通用计算平台，并广泛地用于支撑各类数据仓库系统、BI 系统和决策支持系统。

MPP数据库有对SQL的完整兼容和一些事务的处理能力，对于用户来说，在实际的使用场景中，如果数据扩展需求不是特别大，需要的处理节点不多，数据都是结构化的数据，习惯使用传统的RDBMS的很多特性的场景，可以考虑MPP。常见产品有： Oracle RAC、DB2、Teradata 和 Greenplum 等。

实现原理

MPP 数据库是将单机数据库中的业务数据同步到其他节点，一个节点数据达到一定阈值继续往下一个节点传输，这样就形成了一个由多个独立的数据节点组成的集群，客户端的查询操作也是由各个数据节点完成，并且最后统一汇总。

优劣势

优势是数据迁移成本小，对于业务上使用的 RDBMS 数据库来说不需要进行大规模的数据迁移；对于小规模数据既可以满足业务需求又可以满足分析需求。

劣势是可扩展性有限，当集群达到一定规模的时候，集群中单个节点出现故障的概率就会越大，而且数据没有备份，若是单个节点宕机将会导致整个集群瘫痪；还有一个就是热点问题，数据是顺序性的存入一个个节点之中的，可能某个查询任务都会落在某一个节点上，而其他节点都在空闲状态，虽然有一个解决方案是数据加盐，打乱数据同步到各节点，但这样就会导致查询语句需要在多个节点执行，在没有元数据得知哪些数据被存入哪个节点的前提下，只能在所有节点执行查询语句并把结果汇总，效率会大大降低。

大数据仓库

大数据仓库实际上是依托于大数据技术而产生的一种数仓，底层的数据传输、存储和计算利用大数据技术，在上面加一层 SQL 支持，即可实现对数据的查询。在实现层面为了避免数据的移动而产生的网络和磁盘开销，一般是移动计算，将任务分发到数据所在的节点完成查询操作。常见产品有： Hive、Spark SQL、HBase、Impala、HAWQ 和 TIDB 等。

实现原理

这里就用HIVE来介绍，技术实现方法是将数据从数据源写入文件之中，并将文件按指定大小（一般是128M）分片，再将这些分片按照一定的规则分发到不同的节点当中，并且每个分片有至少三个备份文件分别存储在不同的节点当中，需要查询的时候将 SQL 语句转换成大数据计算引擎识别的程序，然后根据元数据去数据所在的节点执行操作完成数据的查询工作，最后再将结果汇总返回。

优劣势

优势是扩展性高，横向添加廉价的机器即可，计算的时候也会根据各个节点的资源情况选择较为空闲的机器执行操作；安全性高，多个副本的机制保障了数据的可靠性。

劣势是 SQL 支持率有待提升，这个问题在技术的进步下也在慢慢解决，例如 Hive 的 HQL 和 Spark SQL ；缺少事务支持，数据量庞大加上数据存储在不同的节点让支持事务变的比较困难，但对于面向分析的数仓来说支持事务显得并不是那么重要；在数据量未达到一定量级的时候效率反而不如单机或是 MMP 数据库，这是因为数据的转换、任务的调度、数据的汇总耗费了很多的时间和资源，在数据量不足的情况下这反而是一种劣势。