数据旅程之数据仓库（一）

一、数据之路

二十一世纪是生物的世纪，这句话只要上过高中的小伙伴应该都知道，当初选择大学专业也是受其影响。大一、大二兴致勃勃，乖乖学习，成绩将就，到了大三逐渐发现这并非自己所喜欢的专业（生物医疗专业，但当时想研究基因，脑科学）。并且学校主要专业是通信、计算机等，教学重心根本不在生物医疗上，自己对着冷冰冰的医疗仪器没有什么兴趣，对此非常失望。

大三到来，面临着就业的压力，到底另谋出路还是坚持现在？结合自身特点，加之参加过几次数学建模比赛，发现数据是非常有意思的事物。网上各种调查，发现倒是有数据分析师的职位与数据挂钩，但是有技能要求，经验要求。无意之中，了解到一个在线教育平台（mooc，当时并不是非常流行）。这犹如给我带来了希望，无论逃课还是下课，都泡在图书馆，上Coursera，学习数据课程，才踏上数据道路。数据因业务而产生，不了解业务也就不了解数据，也就无法利用数据推动业务，因此自己也放弃考研，走上数据岗位获取业务经验，更好的学习数据。

二、数据仓库之旅

前言：数据数据，存储过去，预测未来

实习之初，由于部门人少，虽说岗位是数据开发但做的事情常常鱼龙混杂，了解运营需求、调取业务数据、开发日常报表、处理第三方产品数据，大大小小的事情都干过，也因此对业务有了不少了解。后来因公司业务快速发展，原有的数据仓库架构已不能正常支持日常需求，自己便转向数据仓库开发工作，提升公司数据质量。

数据仓库，顾名思义就是存放数据的仓库，英文名称Data Warehouse。

数据仓库之父比尔·恩门（Bill Inmon）在1991年出版的“Building the Data Warehouse”（《建立数据仓库》）一书中所提出的定义被广泛接受，数据仓库是一个面向主题的（Subject Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策。—— 来源于MBA智库文科

首先了解一下常用的数据架构，如下所示

来源于百度图片

可以看出数据仓库处于核心位置，多源数据集成、多维数据建模、数据清洗都在数据仓库内部完成，为后面报表展示、数据分析、数据挖掘打下坚实的基础，因此数据仓库至关重要。

圈子中的朋友应该都是抱着对大数据的兴趣而加入学习，其实我也不例外。但为了了解业务，从整体上把握数据，便踏入这条旅程。

（一）、大势所趋的数据仓库环境

数据仓库的起源可以追溯到计算机与信息系统初期，它是伴随着支持决策系统出现而出现。

• 传统数据仓库：数据仓库是存放超大数据量，传统数据仓库用Oracle、Informix等。多数公司在过去是使用Oracle。
• 现代数据仓库：近年来，随着大数据快速发展，非结构化数据越来越多，多源的数据需要处理，开源工具Hadoop＋hive已逐渐被越来越多企业作为数据仓库进行大数据项目。

这里主要指离线数据处理，并非实时数据。Hadoop＋hive工具相对于传统仓库，具有强大的存储能力、计算能力，并能够处理半结构化、非结构化数据采集，优点不言而喻。

（二）、耳熟能详的数据仓库特点

• 面向主题的：业务数据库中的数据都是面向事务处理进行组织的，但数据仓库是面向主题存放，其目的是为了更好的组织数据，方便数据查询分析。

例如电商公司中一般是是围绕订单、用户、产品、流量等构建主题，具体需要根据业务情况而定。

• 集成的：这是数据仓库最重要的特性。数据仓库的数据都是从不同的数据源抽取过来，这时就需要对数据进行清洗装换（编码统一、属性度量统一、描述统一、关键字统一），重新编排，得到原始表与数据仓库表的映射结果。

如在不同系统不同表中，订单号可能表示为task_id，也可能为order_id或者其他（可能是公司没有统一规范造成）。当需要订单主题进行集成时，就需要将订单号标准化。

• 相对稳定的：数据仓库的数据通常是批量的方式更新、访问（没有update操作），当数据抽取到操作环境中后，只要没有误操作，数据不会轻易丢失掩盖。

• 反映历史变化的：这也是数据仓库显著特点。业务系统的数据都是随着具体流程变化而实时更新，有的业务数据仅仅保留当前状态，数据进入数据仓库后，都会加上时间关键字加以标记，存储历史状态。当我们需要对数据进行历史变化分析时，这一特性价值就凸显出来。

（三）、绝不能少的数据仓库模型

这里的数据模型设计并不是数据挖掘中的数据建模，它是一种数据组织方式，将数据加以整理，便于管理使用。构建数据模型是为了抽象实体与实体之间联系关系，从而表示事务关系的一种映射。

• 星型模型：多维数据关系，由一个事实表和多个维度表构成。

雪花模型

• 雪花模型：当一个或者多个维表没有连接到事实表上时，是通过中间维表连接构成。雪花模型是星型模型的补充。

雪花模型
星型模型和雪花模型在数据仓库是同时存在的，在实际项目中，基本上都是雪花模型。例如构建订单主题库时，需要加订单事实、地区、类目等信息集成到一个表中，很多附加信息需要连接几个表才能集成，此时就使用的雪花模型。星型模型数据存在一定冗余，查询时候不需要再关联其他表，因此使用起来效率较高。雪花模型数据使用起来性能较低。

• 维度建模：顾名思义就是按照维度构建模型，实施简单，常常用在分析报表和BI中。

• 实体建模：此种建模方式是基于实体（组织、订单、用户）打通，构建过程较为复杂。

当我们在完善数据仓库时，需要根据业务选择合适的模型进行设计，以满足数据上的性能。当公司业务非常复杂时，需要联合使用多种模型方式处理数据。

对于数据模型设计后面单独写文章介绍。

（四）、不断完善的数据仓库架构

有了数据模型之后，需要将数据进行分层，如下图所示

数据仓库架构

• 数据分层之后更能将数据体系清晰化，数据仓库使用者能更快定位数据仓库表，减少数据仓库负荷（一般来说，明细数据应该减少访问，特定需求除外）

• 基础层主要做数据集成、数据清洗，将数据字段规范化；中间层做数据轻度汇总，此层数据是对数据应用的缓冲（当基础层数据错误时、可以在中间层进行拦截）；集市层数据是高度汇总数据，主要面向报表、数据数据、数据挖掘等等

（五）、不能忽视的数据仓库质量

数据仓库的数据质量既是数据使用的基础也是数据平台发展的前提，因而不能掉以轻心。数据质量的保障既需要保障数据准确，同时也要保障数据时效。那么集群资源充足、网络带宽高就是数据质量保障的基础条件之一。

从数据仓库架构来看，数据质量产生主要有三个方面：

• 源数据错误：业务数据常常存在字段更改、数据更改情况，变更时并未及时通知数据开发人员进行处理；
• 数据拉取错误：数据拉取是将数据进行转移，此时可能会受到网络、集群、调度工具影响，造成数据拉取失败；
• 数据加工错误：数据指标规则不统一，多个数据口径不一致或者数据加工语句产生错误，都会造成数据无法正确、及时使用。

那么对应解决方案也主要在这三个方向：

• 源数据变更（字段更改、新业务数据写入）及时通知，数据仓库及时调整（需要一种沟通协调机制）
• 数据拉取及时监控，短信、微信查收，及时安排人手处理。（有点耗人力）
• 数据加工细心，规则统一，及时沟通指标定义。

（六）、不可或缺的数据仓库元素

• 数据调度工具
• 数据抽取工具
• 元数据管理工具

下文详议数据仓库元素

数据仓库之旅，未完待续。。。。

近期也打算换换地方，重拾机器学习，真正挖掘数据价值，欢迎一起交流。文中若有描述不当之处，还请各位拍砖。。。。