1.为什么需要数据仓库？

在没有数仓之前我们做数据分析到报表展示，依赖的都是从业务数据库中取数据来做分析。业务数据库主要是为业务操作服务，虽然可以用于分析，但需要做很多额外的调整，会存在以下几个问题：

① 表结构关联关系错综复杂

业务数据库通常是根据业务操作需求进行设计的，遵循3NF范式，尽可能减少数据冗余节省存储空间。这就造成表与表之间关系错综复杂。在分析业务状况时，存储业务数据的表与存储待分析的角度表，很可能不会存在直接关联，而是需要通过多表关联来达到需求分析，很明显提高了需求分析的SQL复杂度及表关系梳理的难度。

举例：想从消费用户的地域维度分布来分析用户订单成交整体情况。基本的订单数据在订单细节事实表中，而订单事实表中却关联了其他维度表，例如：地域信息表、用户信息表、物流信息表、业务代码表，这就意味着我们需要把这五张表关联起来，才能进行订单成交整体情况分析，而现在我们将所有数据进行统一整合治理打通后，按照用户地域主题进行模型分析即可，大大降低了分析的难度，提升了分析的效率！

② 数据质量格式类型脏乱差

因为业务数据库会频繁地接受大量用户的输入信息，如果业务系统没有做好足够的数据校验或者存在部分人工数据录入，就必然会产生一些错误脏数据，比如不合法的身份证号、不合法的手机号、大量Null值、空字符串、地理位置信息格式错乱等情况。

③ 字段缺少代码值转换描述

业务数据库中为降低存储成本，方便业务和后端进行数据操作校验，会存在大量语义不明的字段代码值，例如：性别代码值，0(男)/1(女)，各种业务状态的代码值，地理位置的代码等值等，虽然这些情况都是为了方便业务操作和开发，但却给我们分析数据造成了很大负担。各种操作代码必须要查阅码值转换文档，如果操作代码较多，还需要了解储存它的表。来自不同业务数据源的同义异名的数据更是需要翻阅多份文档。

④ 事务性操作丢失历史明细

业务数据库经常会出现事务性操作增删改，但是出于节约空间的考虑，业务数据库通常不会记录数据状态变更历史信息，这就使得某些基于历史数据的分析无法进行。比如想要分析从用户上一季度或者上一年的订单交易信息及成交量，各商品类目的成交情况和转化率，没有历史交易记录数据就无法完成。

⑤ 数据源格式存储种类繁杂

随着各行各业数据量急剧膨胀，就会导致数据源存储方式也会丰富繁多，例如：有许多数据储存在诸如MongoDB等NoSQL数据库中或者对象型数据库，另外一些手工录入的数据，不是存在关系型数据库中，而是以文本文件或excel文档的形式存储。多种多样的数据储存方式，也给抽数带来了挑战，没法简单地用一条SQL完成数据查询。如果能把这些数据都整合抽取到一个数据库里，这样就能很方便地完成数据查询，从而提高分析效率。

⑥ 大规模分析查询效率太差

当业务数据量较大时，使用业务数据库查询就会变得十分缓慢。尤其需要同时关联好几张大表，比如订单表关联地域信息表再关联用户信息表，这个体量就非常巨大，导致查询速度非常慢，导致数据展示页面或报表数据加载延迟过高。还有一点我们需要注意，大批量的数据查询分析必然会消耗业务数据库的整体性能，造成数据库负荷过重或宕机，丢失数据或者影响业务的正常使用

2.什么是数据仓库？

数据仓库，英文名称为Data Warehouse，可简写为DW或DWH。数据仓库，是为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合。数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策(Decision Making Support)。

数据仓库的数据来源于分散、多样、杂乱的操作型数据，将所需数据从原来的数据中抽取出来，进行加工与集成，统一与标准化之后才能进入数据仓库。数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。

针对上面为什么需要数据仓库提出的六点问题，下面看数据仓库是如何解决这么问题的：

① 表结构关联关系错综复杂

数据仓库的数据通常是一天变动一次，由ETL系统完成批量更新。在这种情况下，数据的输入是高度可控的，所以不需要像业务数据库那样尽可能地减少数据冗余。自然地，数据模型就可以不遵循3NF范式，而是以方便分析为目的。数据仓库是面向主题的，所以多数以维度建模建立星型模型为主，星型模型表分为事实表和维度表，事实表处于星型的中心，储存能描述业务状况的各种度量数据，可以通过事实表了解业务情况，而维度表则围绕着事实表，以一对一的方式通过外键相关联，提供看待业务状况的不同角度，这些维度就构成了所有可以分析的角度。不会再有长长的联结了，你想要哪个观察角度，只需要联结相应的维度表就行了。相比业务数据库常用的E-R模型，星形结构更容易理解和进行分析

② 数据质量格式类型脏乱差

首先业务数据库会频繁地接收用户或业务产生的原生数据，并不会进行数据质量及格式类型的校验和治理，而数据仓库是将其他各个业务系统中已经存在的离线业务数据拉取集中存放在一起，建立数据标准规范进行数据治理标准化，例如：手机号校验、身份证号码15位转18位、字符串空值转NULL、全半角转换、日期类型格式标准化等动作，将各个来源的数据质量打通统一化，当然实时数据仓库也会有数据校验治理的动作，然后在ETL过程中会去掉不干净的数据，或者打上脏数据标签

③ 字段缺少代码值转换描述

数据仓库数据体量大，一般都是建立分布式数据仓库，不像业务数据库不用过度考虑存储成本，对于业务数据库中的代码值业务含义不明确的字段，在数据仓库对应的模型中会保留原有的代码值字段，根据国标代码表或者业务代码表关联解析转换，相邻位置新增代码值语义化统一描述字段

④ 事务性操作丢失历史明细

业务数据库经常会出现事务性操作增删改，而数据仓库的作用是进行OLAP联机分析，不存在事务性操作，数据仓库可通过拉链表的形式来记录业务状态变化，甚至可以设计专门的事实表来记录。只要有历史分析的需要，就可以去查询对应的历史数据信息。比如，用户的手机号可能会发生变化，我们通过缓慢变化维(缓慢变化维是指：维度的属性并不是始终不变的，它会随着时间的流逝发生缓慢的变化，这种随时间发生变化的维度我们一般称之为缓慢变化维（SCD），缓慢变化维我们可以通过增加维度行，在为维度成员增加新行时，需为其分配新的主代理键。并且至少需要在维度行再增加三列：有效日期、截止日期、行标识状态(old或者new标识)。这个地方可联想拉链表设计)类型的设计，可以记录他完成同一类业务操作，比如申请贷款的操作时不同的手机号

⑤ 数据源格式存储种类繁杂

数据仓库的建立必然伴随着数据接入操作，而数据仓库的数据源多种多样，可能来源于不同的业务库或者数据存储格式，例如：NOSQL数据库、文本文件或者excel文档等，数据仓库的第一步就是通过ETL操作将不同数据来源的数据集成落地到数据仓库中，然后再进行数据的清洗、治理标准化，再根据业务数据域或者主题域进行模型设计，既然企业分析所需数据已经全部落地到数据仓库中，自然也就不存在像业务数据库因为数据源繁杂不统一而无法进行业务分析的问题了

⑥ 大规模分析查询效率太差

数据仓库本身并不提供高速查询功能。只是由于其简单的星形结构及面向主题设计，比业务数据库的复杂查询在速度上更有优势。如果在数据量上规模之后，同样可能会遇到查询缓慢的问题。但是通过构建分布式数据仓库，使用Hive或者分布式数据库HBase来储存数据，再使用基于Hive构建的多维查询引擎Kylin或基于Hive的大数据实时分析查询引擎Impala进行交互式查询分析，HBase则可以通过使用支持二级索引和标准化SQL的Phoenix中间件，利用大数据技术可以横向扩展，以空间换时间，就可以做到高速查询，对大规模查询的耗时可以缩短到次秒级，大大提高分析查询工作效率

数据仓库的目的是构建面向分析的集成化数据环境，消灭信息孤岛，为企业提供决策支持（Decision Support）。其实数据仓库本身并不“生产”任何数据，同时自身也不需要“消费”任何的数据，数据来源于外部，并且开放给外部应用，这也是为什么叫“仓库”，而不叫“工厂”的原因。因此数据仓库的基本架构主要包含的是数据流入流出的过程，可以分为三层——源数据、数据仓库、数据应用。

 3.数据仓库的特点

• 面向主题的

数据仓库是一般从用户实际需求出发，将不同平台的数据源按设定主题进行划分整合，与传统的面向事务的操作型数据库不同，具有较高的抽象性。面向主题的数据组织方式，就是在较高层次对分析对象数据的一个完整、统一并一致的描述，能完整及统一地刻画各个分析对象所涉及的有关企业的各项数据，以及数据之间的联系

• 集成的

数据仓库中存储的数据大部分来源于传统的数据库，但并不是将原有数据简单的直接导入，而是需要进行预处理。这是因为事务型数据中的数据一般都是存在不完整和数据形式不统一。这些“脏数据”的直接导入将对在数据仓库基础上进行的数据挖掘造成混乱，必须消除源数据库中的不一致。“脏数据”在进入数据仓库之前必须经过抽取、清洗、转换才能生成从面向事务转而面向主题的数据集合。数据集成是数据仓库建设中最重要，也是最为复杂的一步

• 相对稳定的

数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询。一旦某个数据进入数据仓库以后，一般情况下将被长期保留。也就是说数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新

• 反应时间变化的

数据仓库中的数据通常包括历史和实时数据。通过这些信息，可以对企业业务的运营现状、未来趋势等做出定量分析和预测

• 支持管理决策

数据仓库一般不是面向最终客户，而是面向企业领导、业务部门和内部分析人员，用于决策分析等场景

4.数据仓库架构演进

• 传统数仓架构 

这是比较传统的一种方式，结构或半结构化数据通过离线ETL定期加载到离线数仓，之后通过计算引擎取得结果，供前端使用。这里的离线数仓+计算引擎，通常是使用大型商业数据库来承担，例如Oracle、DB2、Teradata等

• 离线大数据架构

随着数据规模的不断增大，传统数仓方式难以承载海量数据。随着大数据技术的普及，采用大数据技术来承载存储与计算任务。当然，也可以使用传统数据库集群或MPP架构数据库来完成。例如Hadoop+Hive/Spark、Oracle RAC、GreenPlum等

MPP (Massively Parallel Processing)架构，即大规模并行处理，在数据库非共享集群中，每个节点都有独立的磁盘存储系统和内存系统，业务数据根据数据库模型和应用特点划分到各个节点上，每台数据节点通过专用网络或者商业通用网络互相连接，彼此协同计算，作为整体提供数据库服务。简单来说，MPP是将任务并行的分散到多个服务器和节点上，在每个节点上计算完成后，将各自部分的结果汇总在一起得到最终的结果(与Hadoop相似)。

Hadoop在处理非结构化和半结构化数据上具备优势，尤其适合海量数据批处理等应用要求。MPP适合替代现有关系数据结构下的大数据处理，具有较高的效率，且对SQL的支持比Hadoop生态要高。MPP适合多维度数据自助分析、数据集市等，Hadoop适合海量数据存储查询、批量数据ETL、非结构化数据分析(日志分析、文本分析)等。

• Lambda架构 

随着业务的发展，随着业务的发展，人们对数据实时性提出了更高的要求。此时，出现了Lambda架构，其将对实时性要求高的部分拆分出来，增加条实时计算链路。从源头开始做流式改造，将数据发送到消息队列中，实时计算引擎消费队列数据，完成实时数据的增量计算。与此同时，批量处理部分依然存在，实时与批量并行运行。最终由统一的数据服务层合并结果给于前端。一般是以批量处理结果为准，实时结果主要为快速响应

• Kappa架构

Lambda架构，一个比较严重的问题就是需要维护两套逻辑。一部分在批量引擎实现，一部分在流式引擎实现，维护成本很高。此外，对资源消耗也较大。而后面诞生的Kappa架构，正是为了解决上述问题。其在数据需要重新处理或数据变更时，可通过历史数据重新处理来完成。方式是通过上游重放完成(从数据源拉取数据重新计算)。Kappa架构最大的问题是流式重新处理历史的吞吐能力会低于批处理，但这个可以通过增加计算资源来弥补