数据仓库，英文名称为Data Warehouse，可简写为DW或DWH。数据仓库，是为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合。它出于分析性报告和决策支持目的而创建。1. 面向主题
普通的操作型数据库主要面向事务性处理，而数据仓库中的所有数据一般按照主题进行划分。主题是对业务数据的一种抽象，是从较高层次上对信息系统中的数据进行归纳和整理。
面向主题的数据可以划分成两部分----根据原系统业务数据的特点进行主题的抽取和确定每个主题所包含的数据内容。例如客户主题、产品主题、财务主题等；而客户主题包括客户基本信息、客户信用信息、客户资源信息等内容。分析数据仓库主题的时候，一般方法是先确定几个基本的 主题，然后再将范围扩大，最后再逐步求精
2. 集成性
面向操作型的数据库通常是异构的、并且相互独立，所以无法对信息进行概括和反映信息的本质。而数据仓库中的数据是经过数据的抽取、清洗、切换、加载得到的，所以为了保证数据不存在二义性，必须对数据进行编码统一和必要的汇总，以保证数据仓库内数据的一致性。数据仓库在经历数据集成阶段后，使数据仓库中的数据都遵守统一的编码规则，并且消除许多冗余数据。
3. 稳健性
数据仓库中的数据反映的都是一段历史时期的数据内容，它的主要操作是查询、分析而不进行一般意义上的更新（数据集成前的操作型数据库主要完成数据的增加、修改、删除、查询），一旦某个数据进入到数据仓库后，一般情况下数据会被长期保留，当超过规定的期限才会被删除。通常数据仓库需要做的工作就是加载、查询和分析，一般不进行任何修改操作，是为了企业高层 人员决策分析之用。
4. 反映历史变化
数据仓库不断从操作型数据库或其他数据源获取变化的数据，从而分析和预测需要的历史数据，所以一般数据仓库中数据表的键码（维度）都含有时间键，以表明数据的历史时期信息，然后不断增加新的数据内容。通过这些历史信息可以对企业的发展历程和趋势做出分析和预测。数据仓库的建设需要大量的业务数据作为积累，并将这些宝贵的历史信息经过加工、整理，最后提供给决策分析人员，这是数据仓库建设的根本目的。数据仓库的发展大致经历了这样的三个过程：
1. 简单报表阶段：这个阶段，系统的主要目标是解决一些日常的工作中业务人员需要的报表，以及生成一些简单的能够帮助领导进行决策所需要的汇总数据。这个阶段的大部分表现形式为数据库和前端报表工具。
2. 数据集市阶段：这个阶段，主要是根据某个业务部门的需要，进行一定的数据的采集，整理，按照业务人员的需要，进行多维报表的展现，能够提供对特定业务指导的数据，并且能够提供特定的领导决策数据。
3. 数据仓库阶段：这个阶段，主要是按照一定的数据模型，对整个企业的数据进行采集，整理，并且能够按照各个业务部门的需要，提供跨部门的，完全一致的业务报表数据，能够通过数据仓库生成对对业务具有指导性的数据，同时，为领导决策提供全面的数据支持。
通过数据仓库建设的发展阶段，我们能够看出，数据仓库的建设和数据集市的建设的重要区别就在于数据模型的支持。因此，数据模型的建设，对于我们数据仓库的建设，有着决定性的意义。
- 建立统一的数据中心
- 为运营人员提供BP级数据支持
- 为领导提供决策支持
数据库： 是一种逻辑概念，用来存放数据的仓库，通过数据库软件来实现，数据库由许多表组成，表是二维的，一张表里面可以有很多字段，数据库的表，在与能够用二维表现多维关系。
数据仓库： 是数据库概念的升级。从逻辑上理解，数据库和数据仓库没有区别，都是通过数据库软件实现的存放数据的地方，只不过从数据量来说，数据仓库要比数据库更庞大得多。数据仓库主要用于数据挖掘和数据分析，辅助领导做决策。
数据库与数据仓库的区别实际讲的是OLTP与OLAP的区别。
对比：
操作型处理，叫联机事务处理OLTP（On-Line Transaction Processing，），也可以称面向交易的处理系统，它是针对具体业务在数据库联机的日常操作，通常对少数记录进行查询、修改。用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数等问题。传统的数据库系统作为数据管理的主要手段，主要用于操作型处理。
分析型处理，叫联机分析处理OLAP（On-Line Analytical Processing）一般针对某些主题的历史数据进行分析，支持管理决策。| 属性 | 数据库 | 数据仓库 |
|---|---|---|
| 面向内容 | 事务型 | 主题、分析型 |
| 数据存储 | 当前最新数据 | 历史数据 |
| 模型建设 | 三范式3NF | 星型模型、雪花模型和星系模型 |
1. 业务调研：
数据仓库是要涵盖所有业务领域，还是各个业务领域独自建设，业务领域内的业务线也同样面临着这个问题。所以要构建大数据数据仓库，就需要了解各个业务领域、业务线的业务有什么共同点和不同点，以及各个业务线可以细分为哪几个业务模块，每个业务模块具体的业务流程又是怎样的。业务调研是否充分，将会直接决定数据仓库建设是否成功。
2. 需求调研：
了解业务系统的业务后不等于说就可以实施数仓建设了，还需要收集数据使用者的需求，及找分析师、运营人员、产品人员等了解他们对数据的诉求。通常需求调研分下面两种途径：
a) 根据与分析师、运营人员、产品人员的沟通获取需求。
b) 对现有报表、数据进行研究分析获取数据建设需求。
3. 数据调研
需要了解数据库类型，数据来源，全量数据情况及数据每年增长情况，更新机制；还需要了解数据是否结构化，是否清洗，是接口调用还是直接访问库，有哪些类型的数据，数据结构之怎样的。1. 日志数据
2. 业务数据
3. 爬虫数据
数据采集可以采用flume 或 netty读取。一般硬件上数据采集主要靠传感器的采集，通过标准的协议上传到服务器，一般是TCP/IP协议。 ETL是将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程，目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析依据。
常用的实现工具有kettle，sqoop，nifi。当然也可以使用程序直接迁移数据。数据存储在hdfs上，包含元数据和主数据的存储。
数据同步到mysql提供接口
数据同步到需求方mysql库直接调用
数据同步到kylin(olap)做预计算，为需求方提供数据做多维分析
数据同步到hbase提供接口服务
数据同步到pg提供数据
用户画像
推荐系统
运营系统
报表系统
业务系统
BI可视化
1. 什么是数据建模
数据建模简单来说就是基于对业务的理解，将各种数据进行整合和关联，并最终使得这些数据可用性，可读性增强，让使用方能快速的获取到自己关心的有价值的信息并且及时的作出响应，为公司带来效益。
2. 为什么要数据建模
数据建模是一套方法论，主要是对数据的整合和存储做一些指导，强调从各个角度合理的存储数据。
a) 进行全面的业务梳理，改进业务流程。
在业务模型建设的阶段，能够帮助我们的企业或者是管理机关对本单位的业务进行全面的梳理。通过业务模型的建设，我们应该能够全面了解该单位的业务架构图和整个业务的运行情况，能够将业务按照特定的规律进行分门别类和程序化，同时，帮助我们进一步的改进业务的流程，提高业务效率，指导我们的业务部门的生产。
b) 建立全方位的数据视角，消灭信息孤岛和数据差异。
通过数据仓库的模型建设，能够为企业提供一个整体的数据视角，不再是各个部门只是关注自己的数据，而且通过模型的建设，勾勒出了部门之间内在的联系，帮助消灭各个部门之间的信息孤岛的问题，更为重要的是，通过数据模型的建设，能够保证整个企业的数据的一致性，各个部门之间数据的差异将会得到有效解决。
c) 解决业务的变动和数据仓库的灵活性。
通过数据模型的建设，能够很好的分离出底层技术的实现和上层业务的展现。当上层业务发生变化时，通过数据模型，底层的技术实现可以非常轻松的完成业务的变动，从而达到整个数据仓库系统的灵活性。
d） 帮助数据仓库系统本身的建设。
通过数据仓库的模型建设，开发人员和业务人员能够很容易的达成系统建设范围的界定，以及长期目标的规划，从而能够使整个项目组明确当前的任务，加快整个系统建设的速度。
有了合适的数据模型，是会带来很多好处的：
查询使用性能提升
用户效率提高，改善用户体验
数据质量提升
降低企业成本
......
所以大数据系统需要数据模型方法来更好的组织和存储，以便在性能,成本，效率和质量之间取的平衡。Power Designer
Power Designer 是Sybase公司的CASE工具集，使用它可以方便地对管理信息系统进行分析设计，他几乎包括了数据库模型设计的全过程。利用Power Designer可以制作数据流程图、概念数据模型、物理数据模型，还可以为数据仓库制作结构模型，也能对团队设计模型进行控制。他可以与许多流行的软件开发工具，例如PowerBuilder、Delphi、VB等相配合使开发时间缩短和使系统设计更优化。
power designer是能进行数据库设计的强大的软件，是一款开发人员常用的数据库建模工具。使用它可以分别从概念数据模(Conceptual Data Model)和物理数据模型(Physical Data Model)两个层次对数据库进行设计。在这里，概念数据模型描述的是独立于数据库管理系统(DBMS)的实体定义和实体关系定义；物理数据模型是在概念数据模型的基础上针对目标数据库管理系统的具体化。chiner
CHINER元数建模工具https://gitee.com/robergroup/pdman
Inmon架构
Inmon企业信息化工厂
我们理解一下这个体系架构，左边是操作型系统或者事务系统，里面包括很多种系统，有数据库在线系统，有文本文件系统…等等。而这些系统的数据经过ETL的过程，加载数据到企业数据仓库中，ETL的过程是整合不同系统的数据，经过整合，清洗和统一，因此我们可以称之为数据集成。
企业数据仓库是企业信息化工厂的枢纽，是原子数据的集成仓库，但是由于企业数据仓库不是多维格式，因此不适合分析型应用程序，BI工具直接查询。他的目的是将附加的数据存储用于各种分析型系统。
数据集市，是针对不同的主题区域，从企业数据仓库中获取的信息，转换成多维格式，然后通过不同手段的聚集、计算，最后提供最终用户分析使用，因此Inmon把信息从企业数据仓库移动到数据集市的过程描述为“数据交付”。Kimball架构
Kimball的维度数据仓库是基于维度模型建立的企业级数据仓库，它的架构有的时候可以称之为“总线体系结构”，和inmon提出的企业信息化工厂有很多相似之处，都是考虑原子数据的集成仓库；我们来根据下面的架构来分析他的观点：
kimball则采用了多维模型–星型模型，并且还是最低粒度的数据存储。其次是，维度数据仓库可以被分析系统直接访问，当然这种访问方式毕竟在分析过程中很少使用。1.流程
Inmon架构: 自顶向下，即从数据抽取-->数据仓库-->数据集市，以数据源为导向，是一种瀑布流开发方法，模型偏向于3NF，
Kimball:架构是自下向上，即从数据集市(主题划分)-->数据仓库--> 数据抽取，是以需求为导向的，一般使用星型模型
2.维度
Inmon架构下不强调事实表和维表的概念，因为数据源变化可能会比较大，更加强调的是数据清洗的工作
kimball架构强调模型由事实表和维表组成，注重事实表与维表的设计
3.数据集市
Inmon架构中，数据集市有自己的物理存储，是真实存在的。
Kimball数据仓库架构中，数据集市是一个逻辑概念，只是多维数据仓库中的主题域划分，并没有自己的物理存储，也可以说是虚拟的数据集市。是数据仓库的一个访问层，是按主题域组织的数据集合，用于支持部门级的决策。
4.中心
Inmon架构是以部门为中心，而Kimball架构是以业务过程为中心
5.EDW的访问
Inmon架构中用户可以直接访问企业数据仓库(EDW)
Kimball架构中用户不可以直接访问企业数据仓库(EDW)，只能访问展现区数据
1.业务模型
生成业务模型，主要解决业务层面的分解和程序化
a) 划分整个单位的业务，一般按照业务部门的划分，进行各个部分之间业务工作的界定，理清各业务部门之间的关系。
b) 深入了解各个业务部门的内具体业务流程并将其程序化。
c) 提出修改和改进业务部门工作流程的方法并程序化。
d) 数据建模的范围界定，整个数据仓库项目的目标和阶段划分。
2. 领域模型
生成领域模型，主要是对业务模型进行抽象处理，生成领域概念模型。
a) 抽取关键业务概念，并将之抽象化。
b) 将业务概念分组，按照业务主线聚合类似的分组概念。
c) 细化分组概念，理清分组概念内的业务流程并抽象化。
d) 理清分组概念之间的关联，形成完整的领域概念模型。
3. 逻辑模型
生成逻辑模型，主要是将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化。
a) 业务概念实体化，并考虑其具体的属性
b) 事件实体化，并考虑其属性内容
c) 说明实体化，并考虑其属性内容
4.物理模型
生成物理模型，主要解决，逻辑模型针对不同关系型数据库的物理化以及性能等一些具体的技术问题。
a) 针对特定物理化平台，做出相应的技术调整
b) 针对模型的性能考虑，对特定平台作出相应的调整
c) 针对管理的需要，结合特定的平台，做出相应的调整
d) 生成最后的执行脚本并完善。ER模型是属于三范式的，是企业级的主题抽象而不是单独描述某个业务。
1NF(表中的每一列都是不可拆分的原子项)
2NF（满足1NF，没有部分依赖）
3NF（满足2NF，没有传递依赖）
在关系数据模型设计中，一般需要满足第三范式的要求。如果一个表有良好的主外键设计，就应该是满足3NF的表。规范化带来的好处是通过减少数据冗余提高更新数据的效率，同时保证数据完整性。然而，我们在实际应用中也要防止过度规范化的问题。规范化程度越高，划分的表就越多，在查询数据时越有可能使用表连接操作。 而如果连接的表过多，会影响查询的性能。关键的问题是要依据业务需求，仔细权衡数据查询和数据更新的关系，制定最适合的规范化程度。还有一点需要注意的是，不要为了遵循严格的规范化规则而修改业务需求。
维度建模是一种将大量数据结构化的逻辑设计手段，包含维度和指标，它不像ER模型目的是消除冗余数据，维度建模是
面向分析，最终目的是提高查询性能，所以会增加数据冗余，并且违反三范式。维度建模也是重点关注让用户快速完成需求分析且对于复杂查询及时响应，维度建模一般可以分为三种：
星型模型- 雪花模型
- 星座模型
其中最常用的其实是
星型模型
事实表（Fact Table）: 指存储有事实记录的表，如系统日志、销售记录等；事实表的记录在不断地动态增长，所以它的体积通常远大于其他表。事实表作为数据仓库建模的核心，需要根据业务过程来设计，包含了引用的维度和业务过程有关的度量。
维度表（Dimension Table）或维表：是与事实表相对应的一种表；它保存了维度的属性值，可以跟事实表做关联；相当于将事实表上经常重复出现的属性抽取、规范出来用一张表进行管理。常见的维度表有：日期表（存储与日期对应的周、月、季度等的属性）、地点表（包含国家、省／州、城市等属性）等。维度是维度建模的基础和灵魂。
星型模型：星形模型中有一张事实表，以及零个或多个维度表，事实表与维度表通过主键外键相关联，维度表之间没有关联，当所有维表都直接连接到“ 事实表”上时，整个图解就像星星一样，故将该模型称为星型模型。星形模型是最简单，也是最常用的模型。由于星形模型只有一张大表，因此它相比于其他模型更适合于大数据处理。其他模型可以通过一定的转换，变为星形模型。 星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余，如在地域维度表中，存在国家 A 省 B 的城市 C 以及国家 A 省 B 的城市 D 两条记录，那么国家 A 和省 B 的信息分别存储了两次，即存在冗余。
雪花模型：当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的维度表，形成一些局部的 " 层次 " 区域，这些被分解的表都连接到主维度表而不是事实表。如图，将地域维表又分解为国家，省份，城市等维表。它的优点是 : 通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余。
星座模型或星系模型：星座模型是由星型模型延伸而来，星型模型是基于一张事实表而星座模式是基于多张事实表，并且共享维度表信息，这种模型往往应用于数据关系比星型模型和雪花模型更复杂的场合。星座模型需要多个事实表共享维度表，因而可以视为星形模型的集合，故亦被称为星系模型
高内聚和低耦合
将业务相近或者相关、粒度相同的数据设计为一个逻辑或者物理模型：将高概率 同时访问的数据放一起，将低概率同时访问的数据分开存储。
核心模型与扩展模型分离
建立核心模型与扩展模型体系，核心模型包括的字段支持常用的核心业务，扩展模 型包括的字段支持个性化或少量应用的需要 ，不能让扩展模型的字段过度侵人核心模型，以免破坏核心模型的架构简洁性与可维护性。
- 公共处理逻辑下沉及单一
越是底层公用的处理逻辑越应该在数据调度依赖的底层进行封装与实现，不要让公用的处理逻辑暴露给应用层实现，不要让公共逻辑多处同时存在。
成本与性能平衡
适当的数据冗余可换取查询和刷新性能，不宜过度冗余与数据复制。
数据可回滚
不改变处理逻辑，不修改代码的情况下重跑任务结果不变
一致性
字段命名及定义必须一致
命名清晰、可理解
表命名需清晰、一致，表名需易于使用方理解
① 选择需要进行分析决策的业务过程,比如下单
② 选择粒度。在事件分析中，我们要预判所有分析需要细分的程度，从而决定选择的粒度。比如订单粒度，粒度是维度的一个组合。
③ 识别维表。选择好粒度之后，就需要基于此粒度设计维表，包括维度属性，用于分析时进行分组和筛选。
④ 选择事实。确定分析需要衡量的指标
- 需求分析调研(数据调研，需求调研，业务调研)：明确口径，评估排期，需求正规流程提交
- 指标管理：完善指标命名规范，指标同名同义，指标与业务强相关，明确指标构成要素
- 模型设计：完善开发流程规范，标准化业务调研，知识库文档集中管理，建立模型评审机制
- ETL开发：ODS->DWD->DWS->ADS
- 数据验证：制定数据测试标准
- 任务调度：规范化调度参数配置
- 上线管理
数据仓库一般分为三层，自上而下分别为数据贴源层（ODS，Operation Data Store）、数据公共层（CDM，Common Data Model）和数据应用层（ADS，Application Data Service）。
ODS层：贴源层，与业务库保持一致，不做任何处理
CDM层：数据公共层CDM（Common Data Model，又称通用数据模型层），包括DIM维度表、DWD,DW和DWS，由ODS层数据加工而成。主要完成数据加工与整合，建立一致性的维度，构建可复用的面向分析和统计的明细事实表，以及汇总公共粒度的指标
公共维度层（DIM）：基于维度建模理念思想，建立企业一致性维度。降低数据计算口径和算法不统一风险。公共维度层的表通常也被称为逻辑维度表，维度和维度逻辑表通常一一对应。
明细粒度事实层（DWD data warehouse detail）：对数据进行规范化编码转换，清洗，统一格式，脱敏等，不做横向整合
公共汇总粒度事实层（DWS）：以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段物理化模型。构建命名规范、口径一致的统计指标，为上层提供公共指标，建立汇总宽表、明细事实表。
公共汇总粒度事实层的表通常也被称为汇总逻辑表，用于存放派生指标数据。
ADS层：数据应用层ADS（Application Data Service）：面向业务需求定制开发，存放数据产品个性化的统计指标数据。
- 表名、字段名采用下划线分隔词根（consultorder->consult_order）
- 每部分使用小写英文单词，属于通用字段的必须满足通用字段信息的定义。
- 表名、字段名需以字母为开头。
- 表名、字段名最长不超过64个英文字符。
- 优先使用词根中已有关键字（数仓标准配置中的词根管理），定期Review新增命名的不合理性。
- 在表名自定义部分禁止采用非标准的缩写。