什么是数据仓库
数据仓库,最先由比尔·恩门（Bill Inmon）于1990年提出,主要功能是将组织或企业里面的联机事务处理(OLTP)所累积的大量数据，透过数据仓库理论所特有的储存架构，进行系统的分析整理，以利于各类分析方法如联机分析处理(OLAP)、数据挖掘(Data Mining)的进行，并进而支持如决策支持系统(DSS)、主管信息系统(EIS)的建立, 帮助决策者能快速有效的从大量数据中分析出有价值的信息。前端
目前, 被普遍接受的数据仓库的定义是由Bill Inmon在1991年出版的 "Building the Data Warehouse"一书中所提出的，其定义以下: 数据仓库(Data Warehouse)是一个面向主题的(Subject Oriented)、集成的(Integrated)、反映历史变化(Time Variant)、相对稳定的(Non-Volatile)的数据集合，用于支持管理决策(Decision Making Support)。算法
其实，在大数据时代，随着机器学习和人工智能的兴起，这个定义须要作一些补充：数据仓库不仅是用于构建支持管理决策的商业智能BI的基础, 也是大量的机器学习和人工智能算法的底层基础之一。数据库
那么该如何理解上面的抽象定义呢？主要包括如下几个关键词：安全
- 面向主题
数据仓库是用来分析特定的主题域的，好比用户、交易、流量等等，主题域的划分也是构建数仓总线矩阵的基础。关于主题的划分，是创建在深刻理解业务的基础之上的，并无一个统一的标准，一个基本的原则是：主题域要尽可能涵盖全部的表。能够将主题理解为业务的概括，属于一个大的分类，有了明确的主题划分，数仓的建设才不至于混乱。 - 集成
咱们知道，数据仓库之因此称之为仓库，是由于其集成了多种OLTP的数据源，将不一样的数据源汇总至数仓的过程就是集成，数据源A和数据源B多是识别某个产品的不一样的方向，可是在数据仓库中，仅有一个方式来识别某个产品, 对于同一产品中分散在不一样的数据源中的不一样信息，数据仓库须要进行数据抽取、清洗、整合;对于分散在不一样的数据源中的同一冗余信息则须要消除不一样数据源的不一致性，以保证数据仓库内的信息是关于整个企业/业务/主题的一致的全局信息。 - 反应历史变化
这一点很好理解，简单讲就是包含历史的全部数据。这点是相对数据库而言, 由于后者一般保持是是最近一段时间的数据。例如:咱们能够从数据仓库中获取3个月, 6个月，12个月甚至10年的订单数据; 而数据库里可能只能获取最近3年的订单数据。 - 相对稳定
一个数据一旦进入数据仓库，则不可改变。数据仓库的历史数据是不该该被更新的。这里须要强调的是：一是历史一旦造成，不可更改。几乎全部的数据仓库产品都不支持更新修改操做，可是是支持重载操做，因此是相对的，而非绝对不可更改。
数据仓库不是什么
初学者对于数据仓库最多见的误解：网络
- 是一个产品
与不少产品提供商所声称的相反，你不能直接买到一个数据仓库，数据仓库包含了数据集成，数据ETL，维度模型、元数据管理、数据质量管理、数据的可视化等等，没有一个单一的产品能完成数据仓库的所有过程。另外，数仓的构建是强依赖与业务的，对于不一样的业务而言，其数仓的形态也是不尽相同的。值得注意的是，数仓是随着业务的变化而不断迭代的，因此没有毕其功于一役的方法，这也注定了数仓是在不断的变化中趋于完善的。 - 一个项目
成功的企业级数据仓库一般是以可管理的数据集市开始的，每一个数据集市均可当作是单独的项目，带有本身的项目周期和预算。关键因 素在于每一个数据集市带有一致的维度和标准的事实表，这样便于将单个的数据集市集成到一个紧密的单元——企业级数据仓库中。随着各个数据集市项目的完成，企业级数据仓库将最终发展起来。所以，思考数据仓库更好的方法是将它当作一个过程，而非一个项目。 - 一个数据模型
简单讲，数仓是由一堆数据模型和数据构成的，数据模型是数仓的基础。可是数仓是多个过程的集合，并不仅仅指数据模型，还包括上面提到的各个环节。 - oltp系统的一套备份
这是一个很常见的误解，认为将业务系统的数据备份一份并在此基础之上创建报表系统就算是构建了数仓，其实否则，只完成数据迁移过程而不重构数据模型也不能构成数据仓库。
数据仓库系统体系结构
数据源->ETL->数据仓库存储与管理->OLAP->BI工具。架构
- 数据源：一般包括各类业务系统数据、日志数据、外部数据；
- ETL（extract/transformation/load）:整合数据并将它们装入数据仓库的过程。将业务系统的数据通过抽取、清洗转换以后加载到数据仓库的过程，目的是将分散、零乱、标准不统一的数据整合到一块儿，为决策提供分析的依据；
- 数据的存储与管理：数据的存储和管理是整个数据仓库的关键。数据仓库的组织管理方式决定了它有别于传统数据库，同时也决定了其对外部数据的表现形式。数据仓库按照数据的覆盖范围能够分为企业级数据仓库和部门级数据仓库（一般称为数据集市）；
- OLAP（On-Line Analysis Processing）:从数据仓库中抽取详细数据的一个子集并通过必要的汇集存储到OLAP存储器中供前端分析工具读取。OLAP系统按照数据存储格式能够分为关系OLAP（RelationalOLAP，简称ROLAP）、多维OLAP（MultidimensionalOLAP，简称MOLAP）和混合型OLAP（HybridOLAP，简称HOLAP）三种类型；
- 前端工具:查询工具、数据分析工具、数据挖掘工具、种报表工具等。
数仓的必要性机器学习
- 数据孤岛
由于每一个人基于本身的业务场景建设数据，竖起了一根根的烟囱，相互之间数据不互通，致使不管是中间数据仍是结果数据，可能只能被本身使用。也不知作别的场景有哪些数据，有的数据是否适合本身的场景。 - 解决问题范围有限
由于数据不互通，对一个系统或业务的理解有限，没法最大化应用数据的价值。 - 效率不足
烟囱数据每次都穿透使用贴源数据，没有公共数据沉淀，没法高效复用。每次都要重复开发，费时费力。
成本不可控
由于大量重复建设，在计算和存储方面都有大量浪费。尤为在海量的监控数据，由于没有沉淀，不知道存储周期设定多久合适，“那就存越久越好，万一之后要用到呢”。价值发挥有限，反而花费大量实际成本。工具
数仓建模
维度建模5步骤
维度建模从分析决策的需求出发构建模型，为分析需求服务，所以 它重点关注用户如何更快速地完成需求分析，同时具备较好的大规模复 杂查询的响应性能。其典型的表明是星形模型，以及在一些特殊场景下 使用的雪花模型。其设计分为如下几个步骤。性能
- 选择须要进行分析决策的业务过程。
业务过程能够是单个业务事件，好比交易的支付、退款等;也能够是某个事件的状态，好比当前的帐户余额等;还能够是一系列相关业务事件组成的业务流程，具体须要看咱们分析的是某些事件发生状况，仍是当前状态， 或是事件流转效率。学习
- 选择粒度。
在事件分析中，咱们要预判全部分析须要细分的程度，从而决定选择的粒度。粒度是维度的 一个组合。值得注意的是，在一个事实表中不要混用多种不一样的粒度。
- 识别维表。
选择好粒度以后，就须要基于此粒度设计维表，包括维度属性，用于分析时进行分组和筛选。从who、what、when、where、why、how等方面描述。
选择事实。肯定分析须要衡量的指标 。好比子订单商品的数量、金额等等。
- 冗余维度
维度设计基础
维度基本概念
- 维度
维度是维度建模的基础和灵魂。在维度建模中，将度量称为“事实” ， 将环境描述为“维度”，维度是用于分析事实所须要的多样环境。例如， 在分析交易过程时，能够经过买家、卖家、商品和时间等维度描述交易 发生的环境。 - 维度属性
维度所包含的表示维度的列，称为维度属性。维度属性是查询约束 条件、分组和报表标签生成的基原本源，是数据易用性的关键。例如， 在查询请求中，获取某类目的商品、正常状态的商品等，是经过约束商品类目属性和商品状态属性来实现的，那么类目和商品状态就是维度属性。 - 如何获取
维度的做用通常是查询约束、分类汇总以及排序等。如何获取维度或维度属性?如上面所提到的，一方面，能够在报表 中获取;另外一方面，能够在和业务人员的交谈中发现维度或维度属性。由于它们常常出如今查询或报表请求中的“按照”( by)语句内。例如， 用户要“按照”月份和产品来查看销售状况，那么用来描述其业务的自 然方法应该做为维度或维度属性包括在维度模型中。 - 总线矩阵
用于设计并与企业数仓总线架构交互的基本工具，矩阵的行表明业务过程、矩阵的列表明维度，点表示维度于给定的业务过程是否存在关系。
维度建模的基本设计方法
方法
维度的设计过程就是肯定维度属性的过程，如何生成维度属性，以 及所生成的维度属性的优劣，决定了维度使用的方便性，成为数据仓库 易用性的关键。正如 Kimball 所说的，数据仓库的能力直接与维度属性 的质量和深度成正比。
- 第一步:选择维度或新建维度。做为维度建模的核心，在企业级数 据仓库中必须保证维度的惟一性
- 第二步:肯定主维表。此处的主维表通常是 ODS 表，直接与业务 系统同步。
- 第三步:肯定相关维表。数据仓库是业务源系统的数据整合，不一样业务系统或者同 一业务系统中的表之间存在 关联性。
- 第四步 :肯定维度属性 。本步骤主要 包括两个阶段，其中第 一 个阶 段是从主维表 中选择维度属性或生成新的维度属性;第 二个阶段是从相 关维表中选择维度属性或生成新 的维度属性。
注意点 - 尽量生成丰富的维度属性
尽量多地给出包括一些富有意义的文字性描述，通常是编码和文字同时存在，好比商品维度中的商品 ID 和商品标题、 类目 ID 和 类目名称等。ID 一 般用于不一样表之间的关联，而名称通常用 于报表标签。
- 区分数值型属性和事实
数值型宇段是做为事实仍是维度属性，能够参考字段的通常用途。若是一般用于查询约束条件或分组统计，则是做为维度属性;若是一般 用于参与度量的计算， 则是做为事实
- 尽可能沉淀出通用的维度属性
有些维度属性获取须要进行比较复杂的逻辑处理，有些须要经过多表关联获得，或者经过单表 的不一样宇段混合处理获得，或者经过对单表 的某个字段进行解析获得。此时，须要将尽量多的通用的维度属性进行沉淀。
事实表
事实表做为数据仓库维度建模的核心，牢牢围绕着业务过程来设 计，经过获取描述业务过程的度量来表达业务过程，包含了引用的维度 和与业务过程有关的度量。
事实表中一条记录所表达的业务细节程度被称为粒度。一般粒度可 以经过两种方式来表述:一种是维度属性组合所表示的细节程度:一种 是所表示的具体业务含义。
事实表有三种类型 : 事务事实表、周期 快照事实表和累积快照事实表。
数据模型设计
模型目标
- 口径一致
- 避免重复计算
- 易于数据服务
- 充分支持业务
数据模型涉及的几个方面 - 数仓分层
- 业务主题
- 维表/事实表
- 命名规范
如何规划数仓
良好的模型抽象和清晰的层次划分能保障支持各类复杂的数据业务接入并较好的支撑数据业务，这是大部分规划数仓时会重点关注的问题。其实，不一样时期来考衡标准是不同的，初期可能主要考虑的把业务支撑好，中后期可能主要重心在模型和数据治理上，经过不一样阶段将数据业务价值最大化同时保障数据建设健康发展。
初期
- 管理方便性：0
- 模型通用性：0.1
- 数据治理：0.1
- 安全保障：0.1
- 业务支持：0.7
中后期 - 管理方便性：0.1
- 模型通用性：0.2
- 数据治理：0.3
- 安全保障：0.2
- 业务支持：0.2
在数据仓库建设初期，因为仓库数据沉淀少，大量的业务数据须要处理，是暂缓业务数据需求开发待仓库建设好全力支撑业务？仍是全力保障业务支持逐步来建设数据仓库建设？这两个问题可能也困扰着不少人，我的以为仍是先run起来，先解决一些业务问题，即先产出一些价值，这样会更容易推动后面的工做。若是一上来就大而全，一方面产出价值少被老板挑战，另外一方面实施周期长，很容易成为一个较大的成本中心。在快速发展的互联网行业像这种建设方式显然不太合适，经过数据支持保障业务快速发展是咱们首要考虑的问题。值得注意的是：先run起来并非意味着不听从任何的规范，只不过首要的问题的支持业务。等到数仓建设到中后期，这个时候就须要考虑数据治理的问题，而不是一味的去知足需求，好比考虑主题数据的中间层数据资产沉淀、模型优化、任务优化、存储与计算成本优化等等，从而使得数仓逐渐趋于完善。
如何评价数仓
- 需求响应敏捷 数据仓库建设不是需求驱动的，可是数据仓库的根本目的仍是面向决策的。在现实中，数据仓库团队承担着不少数据查询分析的职责，常常会收到业务方的数据需求。一个好的数据仓库模型，能预知业务方的数据需求，足够灵活扩展。能作到这一点，首先须要创建元数据管理工具，从而能够方便快速查找数据的基本信息。其次，还须要有大量的数据中间层，有预先算好的数据指标。此外，数据自助提取工具也是快速响应数据需求的必备工具。
- 数据质量可靠 在数据开发过程当中，不少人可能会遇到这种状况，开发时间只用了1周，数据测试和校验用了2周甚至更长时间。测试校验时间长，每每不是因为计算逻辑复杂，而是上游数据不规范，不可靠，不可信，须要花很大的代价本身作校验和数据探查，这在必定层面上也反映出模型的设计有问题。
- 可扩展 数据仓库常常会面对业务的变化，好比业务方拿到一个结果后，常常会与更多的维度交叉分析，或者粒度上作上卷或下钻，还有对统计口径作特别的限定。数据仓库在要能覆盖这些不可预知的变化的需求。更麻烦的是，业务规则会发生变化。良好的数据仓库设计要能兼容这些变化，不然之前积累的数据都将变成垃圾。
- 稳定性 数据仓库还要稳定地保障数据的产出，服务于业务系统，不要常常掉链子。形成不稳定的因素每每是机器网络等硬件因素，可是良好的数据仓库设计能在硬件故障后快速恢复数据，不会形成连锁的灾难。