[目录]
- 第一章：概述
- 第二章：整体数据分层
- 第三章：整体实现框架
- 第四章：元数据
- 第五章：ETL
- 第六章：数据校验
- 第七章：数据标准化
- 第八章：去重
- 第九章：增量/全量
- 第十章：拉链处理
- 第十一章：分布式处理增量
- 第十二章：列式存储
- 第十三章：逻辑数据模型（数仓模型）
- 第十四章：数据模型参考
- 第十五章：维模型
- 第十六章：渐变维
- 第十七章：数据回滚
- 第十八章：关于报表
- 第十九章：数据挖掘
数据仓库实践杂谈-（二）-整体数据分层
对于数据仓库的整体框架，我们用一种称作“从端到端”的流程框架描述，即从数据源头到用户使用的全流程。
上图是一种典型的基于数据整合、加工，并为客户提供数据服务的场景。简单来说，就是用户到平台来查询某些数据，而这些数据从多个源头聚集在一起，并且经过了整合加工。用户的查询一般来说有两种方式：
- 查询明细。这种服务就是把来自数据源的数据直接提供给客户即可，基本不需要对数据做加工处理。从对数据源整合的角度，这种可以叫数据聚合。从用户查询的角度，可以叫明细查询，比如查询张三的交通违法信息。
- 查询汇总结果。根据这三个数据源，通过数据建模及综合的分析——比如给出某个客户的综合评分。这需要对数据进行综合的处理，设计相应的模型和算法。比如查询张三信用评分是多少(交通违法，纳税等等指标进行评分)。
简单举个例子。某个平台对接了3个数据源，分别是：工商数据、司法数据以及税务数据，我们假设每个数据源都只有一个表，分别是A、B、C。根据上面所述，可以提供两种服务：
- 查询某特定企业的工商基本数据：直接查询A表即可返回结果。
- 获得某特定企业的综合信用评分：需要经过模型的预处理，为每个企业进行信用评分，用户查询的时候，实际上查询的是计算结果的表（如信用评分表），而不是明细表。
以征信为例。征信应该算是偏向第一种，就是基于明细的查询，或者说明细查询是最基础的功能。征信报告需要把多个数据源中针对同一查询对象的多个明细数据合并形成结果。可以看做多次单数据源查询的结果合并。
当然，征信平台也开始做自己的信用评分体系，但目前看起来，作用还不是很大，不讨论。
对于另外的场景，比如银行，存在如图所示的数据应用模式。源自多个业务系统的数据经收集整理之后形成业务决策支持系统，如经营管理报表以及各种专业应用系统，如管理会计、信用风险管理以及监管报送等。
这两种场景，都需要建立一个完整的数据仓库系统，也有地方叫数据平台，数据分析平台等。本质都一样，就是对业务数据进行存储、整合，使得数据标准化、保留历史痕迹保证业务连续性，支持各种统计分析挖掘等需求。
经典数据仓库建设的数据流程框架采用分层设计。插一句题外话，分层是一个良好的设计习惯，在任何大型系统的设计中，都应该遵循分层、分子系统的模式去设计。很难说具体什么样的设计叫好，但好的系统的架构图一定看起来显得很优雅。
从数据的完整生命周期来看，一般会分成如下几个环节：
- 临时数据层：一般会把从数据源拿到的数据文件直接保存起来，一般存放3-5天，以防数据处理出现问题。
- 脏数据区：原始数据加载到平台之前，需要对数据进行核验，有可能发现部分数据不符合数据质量的要求，此部分数据会被临时保存在“脏数据区”，等待后续处理。脏数据一般都需要人工介入处理。
- 全量数据层：把每天的业务数据都保存起来，并且可以反映历史变化。也称为ODS（Operational Data
Store，操作数据存储），或者贴源数据层/基础数据平台，传统意义上，只保存短时间数据，比如三个月甚至更短；然后在低成本的存储介质（如磁带）上存储全量历史数据。但应用了大数据技术之后，我更建议这里直接作为全量明细数据存储层。 - 整合层：建立数仓模型，一般根据NCR（后来叫Teradata）或者IBM的逻辑数据模型的指导设计自己的数仓模型。把不同系统、来源的数据进行统一的业务整合并重新建模。
- 汇总层：建立全局的、基于共享维的星系模型。虽然基于数仓模型能做的事情很多，但现实中，大多数都是基于统计的应用，尤其在经典数据仓库系统中。
- 应用集市层：针对特定的业务主题，从汇总层抽取单个多维模型，也就是所谓的星型模型或者叫Cube（立方体）。这部分往往会使用专门的多维分析工具中实现和使用。
这里只考虑批量数据处理情况，不考虑流式处理或者实时数据处理。
未完待续。
