数仓
事实表：
指向各个维度的外键，和一些相应的测量数据，事实表中数据很多，维表记录这一维的属性
维度表
每一个维度表利用维度关键字通过事实表中的外键 约束于事实表中的某一行，实现与事实表的关联， 这就要求事实表中的外键不能为空，这与一般数据库中外键允许为空是不同的。
雪花模型与星型模型不同地方：
雪花模型是对星形模型的扩展，每一个维 度都可以向外连接多个详细类别表。
在这种模式中，维度表除了具有星形模型 中维度表的功能外，还连接对事实表进行
详细描述的详细类别表，详细类别表通过对事实表在有关维上的详细描述达到了缩小事实表和提高查询效率的目的。
粒度
是指保存数据的细化或综合程度的级别
根据业务处理流程来确定粒度，粒度影响数据仓库中的数据量大小
粒度可以分为两种形式：
1.按时间段综合数据的粒度
2.按采样率高低划分的样本数据库
建模过程
inmon架构和kimball架构
1.外部数据,业务数据库,文档组成操作型数据库
2.抽取数据到数据过滤区,对数据进行处理清洗,去重重构;
3.经过处理后的数据装载到数据仓库
4.数据仓库会装载到数据集市中(inmon架构的数据仓库是三范式企业级的数据仓库,kimball的数据库是多维企业级的数据仓库) 这一步kimball没有
5.最终提供给最总用户接口(数据挖掘,可视化等)
多维数据模型及建模过程
选择业务流程: 确认哪些业务处理流程是数据仓库应该覆盖的,是维度的基础
声明粒度: 确定事实中表示的是什么
确认维度: 说明了事实表的数据是从哪里采集来的,是实施表的基础
确认事实: 识别数字化的度量，构成事实表的记录
Data Vault模型及建模过程
综合了第三范式（3NF）和星型模型优点的建模方法,设计理念是要满足企业对灵活性、可扩展性、一致性和对需求的适应性要求，是一种专为企业级数据仓库量身定制的建模方式。
1．设计中心表: 企业级数据仓库要涵盖的业务范围,将各个业务主体中抽象出能够唯一标识实体的主键,该主键不变化 例:客户,产品
2．设计链接表: 体现中心表之间的业务联系
3．设计附属表: 各个业务实体和业务之间关联的详细信息 例:客户住址,产品价格
4．设计必要的PIT表 (point-In-Time) 为了访问数据方便
建立Data Vault模型时应该参照如下的原则：
（1）关于中心表的原则
中心表的主键不能够直接“伸入”到其他中心表里面。就是说，不存在父子关系的中心表。各个中心表之间的关系是平等的，这也正是Data Vault模型灵活性与扩展性
之所在。
中心表之间必须通过链接表相关联，通过链接表可以连接两个以上的中心表。
必须至少有两个中心表才能产生一个有意义的链接表。
中心表的主键总是“伸出去”的（到链接表或者附属表）。
（2）关于链接表的原则
链接表可以跟其他链接表相连。
中心表和链接表都可以使用代理键。
业务主键从来不会改变，就是说中心表的主键也即链接表的外键不会改变。
（3）关于附属表的原则
附属表必须是连接到中心表或者链接表上才会有确定的含义。
附属表总是包含装载时间和失效时间，从而包含历史数据，并且没有重复的数据。
由于数据信息的类型或者变化频率快慢的差别，描述信息的数据可能会被分隔到多个附属表中去。
项目的开发流程
需求分析 参见《数据仓库项目需求分析.doc》
开发计划: 设置进度节点,制定项目计划–>更详细规划《数据仓库项目计划.xls》
概念模型设计
逻辑设计: 概念模型就是在了解了用户的需求，用户的业务领域工作情况以后，经过分析和总结，提炼出来的用以描述用户业务需求的一些概念的东西。如销售业务中的“客户”和“定单”，还有就是“商品”，“业务员”。
物理设计: 物理模型就可以直接生成数据库的创建脚本，以及数据库设计文档
详细设计: 见《数据仓库系统设计文档.doc》和《ETL设计说明书.doc》
项目管理:
部署实施: 见《数据仓库建设项目实施方案建议书.doc》
数仓的概念
数仓是建立在hive上，有两层（ODS层rds库）和DW层（tds库），存储格式日期维度textfile，其他orc。
是一个面向主题的、集成的、非易失的和时变的数据集合，用于支持管理者的决策过程
数据的四大特性
面向主题的：为特定的数据分析领域提供数据支持。
集成的： 集成性是指数据仓库中数据必须是一致的
非易失的，时变
数据仓库和数据库关系
数据库面向事务属于操作型，数据仓库面向分析，属于分析型
数据库是数据仓库的基础，数据库较小，而数据仓库较大
数据不一样
数仓的分层
ODS: Operate data store，操作数据存储
存储源数据
DW: Data warehouse，数据仓库层
数据建模，存储历史数据，冗余数据
DM:数据集市 分析统计
ETL过程
1.Extract数据抽取
建立逻辑映射的步骤
抽取方式2种
从源数据拉取数据（pull）和请求源数据推送到数据仓库（push）
导出为文本方式
使用sqoop抽取数据
抽取类型类型2种
全量抽取还是增量抽取
2.Transform数据转换
数据转换是将数据进行重构以及标准化，消除数据的不一致，处理缺失数据，转换最主要的任务就是数据清洗。
预处理 - 标准化处理 - 去重处理 - 错误值 - 缺失值 - 格式内容清洗 - 逻辑错误清洗 - 修正矛盾内容 - 非需求数据清洗 - 关联性验证
3.Load 数据装载
预加载
不会改变的维度数据
初始装载
历史数据的加载
定期装载
增量数据
ETL自动化
逻辑数据映射
1 识别数据源，有时候业务系统会经过很多次的迭代，有很多遗留系统，标识数据源就会变的非常复杂，需要去找各个系统的接口人共同确定。
2 收集源系统的文档，从文档中找所需的列含义说明，确保数据源正确无误
3 建立源系统跟踪报告，报告应显示每个数据源的负责人、开发人员和使用者。还要包含数据源的特性：所属主题域，接口名称，业务名称，业务部门，接口人，数据库管理系统，生产服务器，数据大小，数据复杂度，每天事务数，优先级，日常使用数量，使用情况，系统平台和其他说明等。
4 建立目标数据仓库的实体关系图。实体关系统表示实体（表）之间的相互关系，通过连线表示，每个实体应有唯一标识，每个列的数据类型，实体之间的关系，这是非常重要的，会影响的数据抽取的顺序，也就是数据流转的过程。
5 建立模型映射，不同的映射类型所做的处理不一样。
数据清洗的一般流程
预处理 - 标准化处理 - 去重处理 - 错误值 - 缺失值 - 格式内容清洗 - 逻辑错误清洗 - 修正矛盾内容 - 非需求数据清洗 - 关联性验证
预处理：对于大的数据文件的加载，特别是新的文件，要进行预先诊断，不能直接加载。
标准化处理：建立标准化对照表，将不一致的数据进行统一，一般需要建立标准码表，建立与标准值转化有关的函数和子程序，建立标准值与非标准值对照的映像表
去重处理：一种是整行数据完全重复，这种可以通过SQL语句达到去重，使用distinct或者group by 进行处理，还有一种是有重复的字段，这种一般需要子查询来进行处理，但是需要跟业务方进行确认如何保留去重数据的规则,在ETL开发的初期可以每天向业务单位发送过滤数据的邮件，促使他们尽快地修正错误,同时也可以做为将来验证数据的依据。数据清洗需要注意的是不要将有用的数据过滤掉，对于每个过滤规则认真进行验证，并要业务方确认。
错误值：错误值产生的原因是业务系统不够健全，在接收输入后没有进行判断直接写入后台数据库造成的，比如数值数据输成全角数字字符、字符串数据后面有一个回车操作、日期格式不正确、日期越界等。这一类数据也要分类，对于类似于全角字符、数据前后有不可见字符的问题，通过转换进行处理，对于值的格式不正确或n
1、确定缺失值范围：对每个字段都计算其缺失值比例，然后按照缺失比例和字段重要性，分别制定策略，可用下图表示：
2、去除不需要的字段：这一步很简单，直接删掉即可，但强烈建议清洗每做一步都备份一下，或者在小规模数据上试验成功再处理全量数据，不然删错了会追悔莫及(多说一句，写SQL的时候delete一定要配where!)。
3、填充缺失内容：某些缺失值可以进行填充，方法有以下三种：
以业务知识或经验推测填充缺失值
以同一指标的计算结果(均值、中位数、众数等)填充缺失值
以不同指标的计算结果填充缺失值
前两种方法比较好理解。关于第三种方法，举个最简单的例子：年龄字段缺失，但是有身份证号，可以通过截取身份证号来获取年龄
4、重新取数：如果某些指标非常重要又缺失率高，那就需要和取数人员或业务人员了解，是否有其他渠道可以取到相关数据。
格式内容清洗
如果数据是由系统日志而来，那么通常在格式和内容方面，会与元数据的描述一致。而如果数据是由人工收集或用户填写而来，则有很大可能性在格式和内容上存在一些问题，简单来说，格式内容问题有以下几类：
1、时间、日期、数值、全半角等显示格式不一致
这种问题通常与输入端有关，在整合多来源数据时也有可能遇到，将其处理成一致的某种格式即可。
2、内容中有不该存在的字符
某些内容可能只包括一部分字符，比如身份证号是数字+字母，中国人姓名是汉字(赵C这种情况还是少数)。最典型的就是头、尾、中间的空格，也可能出现姓名中存在数字符号、身份证号中出现汉字等问题。这种情况下，需要以半自动校验半人工方式来找出可能存在的问题，并去除不需要的字符。
3、内容与该字段应有内容不符
姓名写了性别，身份证号写了手机号等等，均属这种问题。 但该问题特殊性在于：并不能简单的以删除来处理，因为成因有可能是人工填写错误，也有可能是前端没有校验，还有可能是导入数据时部分或全部存在列没有对齐的问题，因此要详细识别问题类型。
格式内容问题是比较细节的问题，比如同一个值，有空格和没空格统计出来结果就不正确了、统计值不全(数字里掺个字母当然求和时结果有问题)、模型输出失败或效果不好(数据对错列了，把日期和年龄混了等)。因此，在处理的数据是人工收集而来，或者产品前端校验设计不太好的时候，就需要找数据的特征，针对性的进行处理
逻辑错误清洗
这部分的工作是去掉一些使用简单逻辑推理就可以直接发现问题的数据，防止分析结果走偏。主要包含以下几个步骤：
去除不合理值，比如年龄超过200岁，日期越界，这种的就要么删掉，要么按缺失值处理。
修正矛盾内容
有些字段是可以互相验证的，比如身份证号和年龄，当年龄跟身份证号上的出生日期不匹配的时候，在这种时候，需要根据字段的数据来源，来判定哪个字段提供的信息更为可靠，去除或重构不可靠的字段。逻辑错误除了以上列举的情况，还有很多未列举的情况，在实际操作中要酌情处理。另外，这一步骤在之后的数据分析建模过程中有可能重复，因为即使问题很简单，也并非所有问题都能够一次找出，我们能做的是使用工具和方法，尽量减少问题出现的可能性，使分析过程更为高效。
非需求数据清洗
这一步说起来非常简单：把不要的字段删了。但实际操作起来，有很多问题，把看上去不需要但实际上对业务很重要的字段删了;某个字段觉得有用，但又没想好怎么用，不知道是否该删; 如果数据量没有大到不删字段就没办法处理的程度，那么能不删的字段尽量不删，另外必须要删的时候，一定要做好数据的备份。
关联性验证
如果你的数据有多个来源，那么有必要进行关联性验证。发现这种不一致，需要跟业务方确认，如何需要调整或去除数据。多个来源的数据整合是非常复杂的工作，一定要注意数据之间的关联性，尽量在分析过程中不要出现数据之间互相矛盾，而你却毫无察觉的情况，数据是数据仓库的基础，如果数据不准确，最后数据仓库中建立的数据模型也是无效的，这个数据仓库的项目就失败了，所以数据清洗特别重要，要反复验证。