DW的入门自白（一）

初入BI，就会撞上许许多多的术语。本节，我们将来捋清一些概念。

额，DW到底是个什么鬼？追溯某项未知事物的源头，往往是了解它最好的方式。DW的“前身”是DB。因而，我们需要先明白什么是DB？

（一）那么什么是DB呢？

DB（DataBase），即数据库之意，它通过表来有规则地存储数据和管理数据，它的发展与壮大完全是因为人们对日常手工表的不堪容忍。在设计上它采用了三范式，从而使存储的表达成“若离若即”状态。

① 那么什么是离？什么是即？通过有意地拆分，将原来的大表分离为许许多多的小表，但同时又在每个表中埋下一些“线索”，使之在必要的情况下能“合而为一”

② 为什么要离？当然是为了性能。比如在创建表的时候，一个表不会有很多很多的字段；在向表插入记录的时候，因为没有那么多字段，录入数据速度就提升了；在查询的时候，由于不是每次我们都需要全部字段，因此全表就十分冗余，且按需求发起查询，服务器由于无需搜索大表，就缩短了响应时间。（为什么支持与隔海相望的台一国两制？为了彼此的发展。）

③ 为什么要即？当需要查看的东西超过一个表所能呈现的范围时，那么只使用这一个表并不足以当前需求了，从而我们就得对“两个或两个以上的表”进行重组，使之成一个大表了。而发挥这种作用的就是先前埋下的“线索”，即表与表之间共同的列。通过它们，表与表之间的就有了“关系”，有了关系，自然好合并。（为什么与与隔海相望的台能一家亲？仰仗“血浓于水”的关系。）

总结一下：DB在设计上方便了我们对表的各种操作（增删改查），这些操作称为事务。因此DB是以事务为主的（记住它，后面有用）。

（二）好了，现在知道DB了，请告诉我什么是DW？

DW（DataWarehouse），即数据仓库之意。随着早先的DB事务操作的累积，我们就有了堆积成山的数据。那么我们就会思考了，这些数据要怎样才能发挥巨大作用？

分析这些数据为企业将来运作的方向带来启发，启发对了自然就带来利益，当然是分析！

① 既然我们的行为是分析，那分析的结果固然是对某一个方面做出结论。

WHAT：这里的某个方面就是某一个主题。所以只有先确定了主题，才能分析出个所以然来。--面向主题的

② 那么我们要用什么来分析？当然是数据。（前面高能，请记住，一切都是为了分析。）

WHERE：这些数据都放在哪些地方呀？这些数据来自企业中诸多数据库。（明白这一说法之后，我们要做的，就是先将这些数据处理一下再搞到同一处（保证数据齐全），为后续分析做准备。）--集成的

HOW：这些数据都是些怎样的数据呀？现在已有的，即基于过去的业务产生的那些事实。我们知道，有些数据在使用过程中并不是必须写死的（由于DB的构建往往是基于一项），比如个人信息就可以修改或注销。好在这些并不多见，但我们还是期望后续这些操作带来的影响能通过定时加载和刷新来更改下数据。（分析活动应当使用真实的数据）--相对稳定的

WHEN：用什么时候的数据呀？往后再次分析又要用哪些数据呀？分析的目的是为了基于过去做决策，所以对象当然是截止到日前的数据，以反应过去的经营活动。我们大费周章来做这件事，定然不希望只是做一次分析就废弃整个成果，而是多次循环利用——之前是基于哪个时间取的数据，自该时间点后到日前的就是后来产生的数据了。我们不过像砌墙一样，将数据堆积起来。  --反映历史变化的

至此，我们可以给数据仓库下定义了：面向主题的、集成的、相对稳定的、反映历史变化的。

ps：

顺便谈一下DM（DataMart），即数据集市。DM是面向部门级别的，且通常只有一个主题。

而从上面，我们便知道了DW是从多个异构数据库得来（“集成”特点），是面向企业级别的。因此，DW是多个DM的集合（一个企业可不是有多个部门嘛？），从而DW有多个主题。

关系链：DW > DM， > 为包含之意。

DW：面向企业级别的，有多个主题。

DM：面向门级别的，通常为单个主题。

（三）Why not DB？Why DW？

但是还存在一些问题：为什么不用DB，而要用DW？事出有因！

额，一次两此......百次，前面说到DB主事务，现在还要管分析了，先不说运行DB的那台服务器受不受得了，这简直是把DB往两个极端赶嘛？第三范式还怎么用？于是后续就蹦出来了DW呗，专门用于分析。那现在轮到我问您了，分析到底是为了是什么？请记住，DW不同于DB，它是面向分析型数据的处理，完全是为了支持决策用的。这就是创建它的目的。

（四）分析需要数据源呀！怎么把数据从DB搬到DW?

数据全部照搬DB那还叫什么DW哇？况且，分析是讲究统计方法，那就需要把要用到的数据集合到一处，再把其中的一些数据按照一定的逻辑规则处理达到“理想状态”（要使一颗石头变成一块好玉总是需要打磨的，把数据的“棱角”去掉，使之“圆润”），最后再入库。这个过程就是抽取、转换、加载。我们称之为ETL（Extract Transform Loading）。

每次都要从数据库抽取全部数据是不是很麻烦，因为多做了一些无谓的工作量？因为实际上我们只需要将未加载的数据抽过来，然后把那些变更了的记录也更新一下即可。这就是增量抽取。而前者为全量抽取。

当然，考虑到服务器的负载，总是从数据库抽取也不是办法，我们会想——要是能把一些数据放在和数据仓库这边，既缓解了服务器的压力，因为无需响应抽取的速度不也更快了？但是这些数据我们也难保要什么样的，算了先把需要的那些字段直接拿过来呗。由此，为区分数据仓库里的数据，我们把这些从操作型业务数据库里面拿过来的这些称为操作数据存储，即ODS（Operation Data Storage）。

（五）ODS

ODS的具体定义是：面向主题的、集成的、可变的、反映当前数据值和保留详细的数据的集合，用来满足企业综合的、集成的以及操作型的处理要求。

可变的：ODS是可进行实时的或接近实时的更新。数据仓库是相对稳定的（里面存储的数据不进行更新，对于错误的处理通常是采用新快照来进行保存），且在正常时间或预定计划时间进行数据的收集。

反映当前数据值：这点表明ODS并不会长期的保留数据，一般为一个月或三个月。数据仓库是反映历史变化的，保存周期长达五年甚至更久。

详细的数据：ODS中只保留原子数据，而不保存汇总数据（这是由于ODS中可更新特性——随时可能将操作型系统的数据变化更新到ODS中，且数据的迁移时间间隔很短，原子数据一经改变，汇总数据也会跟着改变。耗费资源，且意义不大）。数据仓库通常会保存汇总数据。

根据数据到达ODS的时间间隔，可将ODS分为四种类型：

Class I：指时间间隔为“秒级”。操作型系统业务发生后，数据即可就可以在ODS部件中看到。缺点是：秒级意味着没有时间进行数据的整合，在技术和成本上不合算。

Class II：指时间间隔为“小时级”。操作型系统业务发生后，数据要经过几个小时才能出现在ODS部件中。

Class III：指时间间隔为“天级”。常见的数据仓库迁移频率，譬如每天晚上进行一次数据迁移。

Class IV：指时间间隔更长，可能为“月级”、甚至“年级”。这一类的数据源与其它三类不同，经常是数据仓库。

问题来了：

① “从数据库直接抽到数据仓库” 与 “先从数据库抽到ODS，再从ODS抽到数据仓库” 不都是会增加数据库负载么？怎么说缓解了服务器压力？

② 将来自OLTP系统的实时数据抽取到ODS层，若是其中并不发生任何转换，那我为什么还要用它，而不是直接对OLTP系统进行查询呢？

我们的典型模型是这样子的：OLTP  ->  ETL  ->  ODS  ->  ETL  ->  DW

这就是在变相地要求给出ODS的作用呀。单纯从起点和终点来说，我们可以概括为“和而不同”（将数据汇合，业务系统不同的还是不同）。记住下面这些很容易，可以这么想：之所以称它是中间部件，是因为它能承上启下，对“源头”和“目标”都有所帮助。

同时，我们可以认为，如果不需要

（1）在业务系统和数据仓库之间形成一个隔离层（数据源多样化的锅）

一般的数据仓库有多个数据来源，从这些业务系统中抽取数据并非易事。由于ODS是用于存放 “从业务系统直接抽取出来的” 数据，这些数据从数据结构、数据之间的逻辑关系上与业务系统的基本保持一致。因此，在抽取过程中，极大降低了数据转化的复杂性，从而把关注点放在 “数据抽取的接口、数据量大小、抽取方式” 等方面。

换句话说，ODS就是数据仓库的“数据准备层”。

（2）转移一部分业务系统细节查询的功能（业务系统不堪重负的锅）

在数据仓库建立之前，大量报表、分析都是由业务系统直接支持的，若它们比较复杂，则业务系统的运行压力随之增大（涉及数据量达千百万级别）。从（1）可知，ODS的数据从粒度、组织方式等各个方面都保持了与业务系统的一致，那么原先从业务系统才能获得的数据便可以从ODS中取得，从而降低了业务系统的查询压力。

（3）完成数据仓库中不能完成的一些功能（数据仓库缺陷的锅）

数据仓库倾向于提供战略性的分析，而ODS则提供实时的数据支持。比如说，以前只有公司大佬才会要数据，他们关注的为一般结果，所以我们给出汇总数据就了事了。现在产品和运营也都来要数据了，他们关注的是用户行为数据、个体订单等“明细数据”，一般上午提出，下午就要拿到。而数据仓库只有历史数据，且数据迁移频率大都在午夜，这显然不可能做到嘛。

（六）ETL的三部曲

从ODS左右逢“ETL”，可见其重要性。实际上，将数据源抽取到ODS这个过程中我们也是可以做一些数据清洗和转换的。唯一需要注意的是，我们需要挑选不同的抽取方法，从而尽可能的提高ETL的运行效率。

ETL的设计分为三部分：

（1）数据抽取

通常的做法是：

① 首先是对于数据来源的调研——是否自于多个业务系统？是否来自异构业务系统？是否存在手工数据？

② 然后才进行抽取的设计：

若数据来源，与存放DW的数据库系统相同：在DW数据库服务器和源业务系统之间建立直接的链接关系，之后就可以写SELECT语句直接访问了。

若数据来源，与存放DW的数据库系统不同：对于这类数据源，一般需要通过ODBC的方式建立数据库链接。在上步骤无法作用的情况下，则有另外两个选择——要么通过程序接口来完成，要么通过工具将源数据导出称.txt 或 .xls文件，然后在将这些源系统文件导入到ODS中。

若数据来源为文本文件或电子表（.txt或.xls），则有两个选择：要么利用数据库工具将这些数据先导入到指定的数据库，再从指定的数据库中抽取；要么借助kettle等ETL工具的平面数据源和平面目标等组件导入到ODS中。

③ 对于数据量较小的系统，使用全量抽取即可。对于数据量大的系统，必须考虑增量抽取。

（2）数据的清洗转换

通常的做法是：从业务系统到ODS做清洗，将脏数据和不完整的数据过滤掉；再从ODS到DW做转换，进行一些业务规则的计算和聚合。

数据清洗的任务是：过滤掉那些“不符合要求的数据”，将过滤的结果交给业务主管部门，确认是否过滤掉还是由业务单位修正之后再进行抽取。

不符合的数据主要有三大类：

① 不完整数据：这类数据主要是一些本应该有的信息缺失。

② 错误的数据：这类数据主要是一些类型不正确、格式不规范、取值范围多大或多小的信息。

③ 重复的数据。

数据转换的任务是：使数据类型一致、粒度聚合、指标受业务规则指导。

① 不一致的数据转换：将不同业务系统的相同类型的数据统一。

② 数据粒度的转换：一般会将业务系统数据按照数据仓库粒度进行聚合。（业务系统存储明细数据，数据仓库由于是用于分析，是不可能存储太细的数据。）

③ 一些商务规则的计算：根据企业的业务规则，计算数据指标。

（3）数据加载

数据加载的任务是：以OLTP系统为源系统，并进行ETL数据加载到数据仓库系统中。

但这其中涉及一般数据加载策略，主要分为四种：

① 时间戳方式（增加字段）：在OLTP系统中业务表统一添加时间字段作为时间戳。只要OLTP系统更新修改业务数据时，时间戳字段值也会同时修改。当ETL加载时，通过系统时间与时间戳字段的比较，就可以决定进行何种数据抽取。

② 日志表方式（增加表）：在OLTP系统中添加系统日志表。当业务数据发生变化时，更新维护日志表内容。当ETL加载时，通过读日志表数据决定加载哪些数据及如何加载。

③ 全表比对方式（update and insert）：在ETL过程中，抽取所有源数据，并进行相应规则转换，完成后先不插入目标，而是对每条数据进行目标表比对。根据主键值进行“插入”与“更新”的判定——如果目标表已存在该主键值，说明该记录已存在，存在就可能会发生修改，因此我们还需要拿“其余字段”进行比对，一旦发现有字段不同就UPDATE；如果目标表不存在该主键值，表示该记录还没有→→直接INSERT。

④ 全表删除再插入方式（truncate and insert）：每次ETL操作均删除目标表数据，然后再从OLTP系统抽取全部数据并加载。