集成性数据仓库会将不同源数据库中的数据汇总到一起。有可能部分数据源并未发生变化，而有的数据源可能只是增加了少量的数据。存储各大业务型数据库ETL后的数据，是最接近数据源中数据的一层，主要目的是为了数据集中。但是不等同于原始数据，数据格式按照数仓要求统一，并经过简单的清洗。
数据仓库是存数据的，企业的各种数据往里面塞，主要目的是为了有效分析数据，后续会基于它产出供分析挖掘的数据，或者数据应用需要的数据，如企业的分析性报告和各类报表，为企业的决策提供支持。
数据仓库可以算是数据产品必须要了解的技术知识了， 在一年前的数据产品求职分析中，其中技能要求这一项中，数据仓库可是占了一席之地的。
但是，对于准备求职数据产品的童鞋来说，可能身边没有做数仓开发的朋友可以请教。自学吧，而那几本经典书籍里面又过于理论，看起真是生不如死，而且数据产品并不是数据开发，可能了解一些入门的常识，有个大概的概念就可以了。
我也一直零零散散的积累这方面的知识，这两天梳理了下，形成下文，希望对大家有所帮助，非专业数仓开发人员，如有不准确的地方，还望大家指正。
文章结构
- 一、数据仓库是什么
- 二、数据仓库有什么特点
- 三、为什么搭建数据仓库
- 四、数据仓库结构
- 五、ETL
- 六、数据集市
- 七、ODS
- 八、元数据
一、数据仓库是什么
可以理解为：面向分析的存储系统。
也就是说数仓是存数据的，企业的各种数据往里面塞，主要目的是为了有效分析数据，后续会基于它产出供分析挖掘的数据，或者数据应用需要的数据，如企业的分析性报告和各类报表，为企业的决策提供支持。
上面的意思先理解着，接下来从头讲起，先看关系型数据库，它可以被划分为两大基本类型：操作型数据库和分析型数据库。
1. 操作型数据库
主要面向应用，用于业务支撑，支持对实际业务的处理，也可以叫业务型数据库。
可以理解为通常意义上的数据库（后端开发同学口中的经常提到的就是这种）。
2. 分析型数据库
主要面向数据分析，侧重决策支持，作为公司的单独数据存储，负责利用历史数据对公司各主题域进行统计分析。
由于分析型数据库中的操作都是查询，因此也就不需要严格满足关系型数据库一些设计规范，这样的情况下再将它归为数据库不太合适，也容易不引起混淆，所以称之为数据仓库。
这里可以说一下，数据处理大致可以分成两大类：OLTP（联机事务处理）和OLAP（联机分析处理）。
- OLTP（联机事务处理）就是操作型数据库的主要应用，更侧重于基本的、日常的事务处理，包括数据的增删改查。
- OLAP（联机分析处理）就是分析型数据库的主要应用，以多维度的方式分析数据， 这个后续会整理。
二、数据仓库有什么特点
相对于数据库，数据仓库有以下特点
（1）面向主题
数据仓库通过一个个主题域将多个业务系统的数据加载到一起，为了各个主题（如：用户、订单、商品等）进行分析而建，操作型数据库是为了支撑各种业务而建立。
（2）集成性
数据仓库会将不同源数据库中的数据汇总到一起。
（3）历史性
较之操作型数据库，数据仓库的数据是为企业数据分析而建立，所以数据被加载后一般情况下将被长期保留，前者通常保存几个月，后者可能几年甚至几十年。
（4）时变性
是指数据仓库包含来自其时间范围不同时间段的数据快照，有了这些数据快照以后，用户便可将其汇总，生成各历史阶段的数据分析报告。
（5）稳定性
数据仓库中的数据一般仅执行查询操作，很少会有删除和更新。但是需定期加载和刷新数据。
三、为什么搭建数据仓库
简单来说，就是为了有效分析数据 。
你说直接从业务数据库中取数据来做分析？
也不是不可以，就是业务系统多，业务复杂时，会发现结构复杂，数据脏乱，难以理解，缺少历史，大规模查询缓慢这些问题。
业务到一定规模，大家需要面临的问题越来越复杂和深入，数据需求不再只是昨日的营收，上月的uv这些，而是“28到45岁女性在社区的活跃度与公司策划的专题内容活动的关系”这类精细化的分析，而从数据库是很难取出这类数据的。
毕竟业务型数据库是为了支撑业务设计的，不是为了查询和分析数据。
四、数据仓库结构
用AXURE画了个结构图，如下：简单来说，就是把各数据源的数据ETL到数仓中，数仓再对数据进行集成和统计，然后再输出给各数据应用，图中涉及的模块，接下来会分别介绍。
五、ETL
ETL分别代表：抽取extraction、转换transformation、加载load。
（1）抽取(Extract)
从数据来源提取指定数据，数据是需要指定的，不是所有的数据都要抽取过来， 某些源数据对于分析而言没有价值，或者其可能产生的价值，远低于储存这些数据所需要的数据仓库的实现和性能上的成本，就不会抽取了。
（2）转换(Transform)
将数据转换为指定格式并进行数据清洗保证数据质量。
数据转换，如包括编码转换(m/f->男/女)，字段转换(balance->bal)，度量单位的转换(cm->m)，数据粒度的转换。业务系统数据存储非常明细的数据，而数据仓库中数据是用分析的，不需要非常明细，会将业务系统数据按照数据仓库粒度进行聚合。
数据清洗，如会对不完整数据，错误数据和重复数据等脏数据进行清洗。
（3）加载(Load)
将转换过后的数据加载到目标数据仓库，加载可分为两种：
- 全量加载：一次对全部数据进行加载。
- 增量加载：一般首次需要全量加载，但是在第二次周期或者第三次周期的时候仍然全量加载的话，耗费了极大的物理和时间资源。有可能部分数据源并未发生变化，而有的数据源可能只是增加了少量的数据。 对数据源中的数据只考虑新修改的记录和新插入的记录就是增量加载。
ETL很可能是数据仓库开发中最耗时最耗资源的一个环节，因为该环节要整理各大业务系统中杂乱无章的数据，并协调元数据上的差别，工作量很大，但也是构建数据仓库的重要环节，对数据仓库的后续环节影响比较大。
六、数据集市
数据集市（DM）可以理解为是一种“小型数据仓库”，一般面向部门、单个主题或特定应用，且之间互不影响。
可以分为以下两种：
- 独立数据集市：有自己的源数据库和ETL架构；
- 非独立数据集市：没有自己的源数据，它的数据来自数据仓库。当用户或者应用程序不需要/不必要/不允许访问整个数仓数据时，就可以直接访问数据集市，为用户提供一个数据仓库的“子集”。
简单理解就是一个结构完全和数仓一样，有ETL，然后自己存储和计算；另一种就是直接用数仓处理过的数据，再次进行组合集成。可能后面结合数据分层更好理解。
七、ODS
ODS：全称是Operational Data Store，操作数据存储。
存储各大业务型数据库ETL后的数据，是最接近数据源中数据的一层，主要目的是为了数据集中。
总体上大多是按照源业务系统的分类方式而分类的，因此会具有鲜明的业务数据库的特征，甚至还具有一定的关系数据库中的数据范式的组织形式。
但是不等同于原始数据，数据格式按照数仓要求统一，并经过简单的清洗。
八、元数据
元数据（Meta Date），即数据的数据，元数据可分为技术元数据和业务元数据。
技术元数据为开发和管理数据仓库的IT 人员使用，描述了与数据仓库开发、管理和维护相关的数据，包括数据源信息、数据转换描述、数据仓库模型、数据清洗与更新规则、数据映射和访问权限等。
而业务元数据为管理层和业务分析人员服务，从业务角度描述数据，包括商务术语、数据仓库中有什么数据、数据的位置和数据的可用性等，帮助业务人员更好地理解数据仓库中哪些数据是可用的以及如何使用。
写到这里，发现内容已经很多了，像数仓建模、数据分层、olap、BI这些留到下篇再讲吧。
提一下数据分析报告，去年爬了3份数据，本来准备写三篇数据报告，结果写了一篇之后，就再也没有下文了，前段时间又重新爬了份，准备至少再写一篇，虽然现在还没开始动笔。
本文由 @ 苏徐 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自 Pexels，基于 CC0 协议
,
