标签：table 仓库 图片 统计 image 方向 proc 效率 xxx
传统的数据库中，存放的数据都是一些定制性数据较多，表是二维的，一张表可以有很多字段，字段一字排开，对应的数据就一行一行写入表中，特点就是利用二维表表现多维关系。
但这种表现关系的上限和下限就定死了，比如QQ的用户信息，直接通过查询info表，对应的username、introduce等信息即可，而此时我想知道这个用户在哪个时间段购买了什么？修改信息的次数？诸如此类的指标时，就要重新设计数据库的表结构，因此无法满足我们的分析需求。
在产品脑图中可以很清晰的看到根据业务需求设计所需的字段，因此也导致数据库是根据业务需求进行设计。
那么有的会问，为什么一开始就不考虑好这个扩展性呢？为什么数据库一开始就不以数据仓库的形式设计？
首先数据仓库，从字面上理解就可以感受到这是一个很大的空间，而且存储的物品很杂，里面会存放酱油、沐浴露、洗发精等物品，而数据库是存放酱油、盐等厨房用品，洗浴又是一个数据库。
另外一个就是，国内互联网的发展，一开始大家都是做个软件出来，大家一起用，这个时候只要满足的了需求即可，现今不止是需求还有用户的体验等各种方面，需要根据这些分析指标做调整。
数据库是跟业务挂钩的，而数据库不可能装下一个公司的所有数据，因此数据库的设计通常是针对一个应用进行设计的。
数据仓库是依照分析需求、分析维度、分析指标进行设计的。
数据仓库（Data Warehouse）简称DW或DWH，是数据库的一种概念上的升级，可以说是为满足新需求设计的一种新数据库，而这个数据库是需容纳更多的数据，更加庞大的数据集，从逻辑上讲数据仓库和数据库是没有什么区别的。
为企业所有级别的决策制定过程，提供所有类型数据支撑的战略集合，主要是用于数据挖掘和数据分析，以建立数据沙盘为基础，为消灭消息孤岛和支持决策为目的而创建的。
2000年初，国内是简单的报表阶段，这个阶段主要是汇总一些数据，解决业务人员想要的报表。
如：销售额：xxx万元、销售量：20000件
2010年，数据集市阶段，进行一定的数据采集、整理，按照某业务部门的需求进行采集、整理，按照业务人员需要，进行多维度报表的展现，能够提供特定的领导决策数据。
如：1月~3月销售额：xxx万元、4月~6月销售额：xxx万元
2015年，各大公司开始注重用户体验，物流效率等问题，这个时候进入数据仓库阶段，主要按照数据模型，对整个企业的数据进行采集、整理，提供跨部门，完整一致性的业务报表数据，能够通过数据仓库生成对业务具有指导性的数据，为决策者提供更全面的数据。
如：某个月某个地区的用户数量下降，某个月某个地区的用户数量上升。
是企业系统信息中的数据综合、归类并进行分析的一个抽象，对应企业中某一个宏观分析领域所涉及的分析对象。
比如购物是一个主题，那么购物里面包含用户、订单、支付、物流等数据综合，对这些数据要进行归类并分析，分析这个对象数据的一个完整性、一致性的描述，能完整、统一的划分对象所设计的各项数据。
如果此时要统计一个用户从浏览到支付完成的时间时，在购物主题中缺少了支付数据或订单数据，那么这个对象数据的完整性和一致性就可能无法保证了。
数据仓库的数据是从原有分散的数据库中的数据抽取而来的。
操作型数据和支持决策分析型（DSS）数据差别甚大，这里需要做大量的数据清洗与数据整理的工作。
第一：每一个主题的源数据在原有分散数据库中的有许多重复和不一致，且不同数据库的数据是和不同的应用逻辑捆绑的。
第二：数据仓库中的综合性数据不能从原有的数据库系统直接得到，因此在数据进入数据仓库之前要进过统一和综合。（字段同名异意，异名同义，长度等）
数据仓库的数据主要是提供决策分析用，设计的数据主要是数据查询，一般情况下不做修改，这些数据反映的是一段较长时间内历史数据的内容，有一块修改了影响的是整个历史数据的过程数据。
数据仓库的查询量往往很大，所以对数据查询提出了更高的要求，要求采用各种复杂的索引技术，并对数据查询的界面友好性和数据凸显性提出更高的要求。
数据仓库中的数据不可更新是针对应用来说，从数据的进入到删除的整个生命周期中，数据仓库的数据是永远不变的。
数据仓库的数据是随着时间变化而不断增加新的数据。
数据仓库随着时间变化不断删去久的数据内容，数据仓库的数据也有时限的，数据库的数据时限一般是60 ~ 90天，而数据仓库的数据一般是5年~10年。
数据仓库中包含大量的综合性数据，这些数据很多是跟时间有关的，这些数据特征都包含时间项，以标明数据的历史时期。
数据库的操作：一般称为联机事务处理OLAP（On-Line Transaction Processing），是针对具体的业务在数据库中的联机操作，具有数据量较少的特点，通常对少量的数据记录进行查询、修改。
数据仓库的操作：一般称为联机分析处理OLAP（On-Line Analytical Processing），是针对某些主题（综合数据）的历史数据进行分析，支持管理决策。
|
比较项 |
操作型（OLTP） |
分析性（OLAP） |
|
关注 |
细节 |
综合或提炼 |
|
模型 |
实体 – 关系（E-R） |
星型或雪花 |
|
操作 |
可更新 |
只读，只追加 |
|
操作粒度 |
操作一个单元 |
操作一个集合 |
|
场景 |
面向事务 |
面向分析 |
|
数据量 |
小 |
大 |
|
需求 |
日常操作 |
决策需求 |
|
业务方向 |
客户信息、订单等查询 |
客户登录间隔时间，市场细分等 |
ODS层（临时存储层）：这一层做的工作是贴源，而这些数据和源系统的数据是同构，一般对这些数据分为全量更新和增量更新，通常在贴源的过程中会做一些简单的清洗，
DW层（数据仓库层）：将一些数据关联的日期进行拆分，使得其更具体的分类，一般拆分成年、月、日，而ODS层到DW层的ETL脚本会根据业务需求对数据进行清洗、设计，如果没有业务需求，则根据源系统的数据结构和未来的规划去做处理，对这层的数据要求是一致、准确、尽量建立数据的完整性。
APP层（引用层）：提供报表和数据沙盘展示所需的数据。
在未分层的情况下，数据之间的耦合性与业务耦合性是不可避免的，当源业务系统的业务规则发生变化时，可能影响整个数据的清洗过程。
数据分层简化了数据清洗的过程，每一层的逻辑变得更加简单和易于理解，当发生错误或规则变化时，只需要进行局部调整。
通过大量的预处理来提升应用系统查询速度，进而提升的用户体验，因此数据仓库会冗余大量的数据，是典型的空间换时间的策略。
在操作数据仓库时，操作的都是元数据，而元数据分为技术元数据和业务元数据。
技术元数据：是指数据仓库开发、管理、维护相关的数据，描述了数据的原信息，转换描述、数据映射、访问权限等。
业务元数据：为管理层和业务分析人员服务，从业务的角度描述数据，包括行业术语、数据的可用性、数据的意义等。
元数据的存储有常用的两种，一种是以数据集为基础，每一个数据集有对应的元数据文件，每一个元数据文件对应数据集的元数据内容，另一种是以数据库为基础，由若干项组成，每一项标识元数据的一个元素。
进行全面的业务梳理时，我们可以通过业务模型，全面了解业务结构及运行情况，按照业务特定的规律分门别类和程序化，改进业务的流程。
通过模型的建设，我们可以很清晰的看到数据之间内在的关联关系，从而建立起全方位的数据视角，并消灭信息孤岛和数据差异化的问题，进而保证数据的一致性。
模型可以很好的帮助我们分离出底层技术的实现和上层业务的展现，当上层业务发生变化时，通过数据模型，底层的技术实现可以适应的了业务的变动，进而解决数据库的灵活性。
在模型中可以很好的看出开发人员和业务人员之间的系统建设范围的界定，及未来的规划。
数据模型是数据关系的一种映射， 就是将业务之间的关系，用模型图形化的描绘出来，而不再是脑海的一个模糊的关系。
在设计数据仓库模型和架构时，我们需要懂具体的技术，也需要了解行业的知识和经验来帮助我们对业务进行抽象、处理，进而生成各个阶段的模型。
在大体上，我们将数据模型分为5大块。
系统记录域：数据仓库业务数据存储区，保证数据的一致性。
内部管理域：用于内部管理的元数据，统一的元数据管理。
汇总域：这里的数据来自系统记录域的汇总，保证分析域的主题分析性能，满足部分报表查询。
分析域：各个业务部分的具体主题业务分析，可以单独存储在相应的数据集市中。
反馈域：用于相应的前端的反馈数据，视业务的需要设置这个域。
维度和指标时数据分析领域常用的概念，亦是在设计数据仓库过程中需要考虑的。
维度就是数据的观察角度，即从哪个角度去分析问题，看待问题。
指标（度量）就是从维度的基础上去衡算这个结果的值。
比如银行采集数据：
|
时间（维度） |
分行（维度） |
存款额（指标） |
|
1999年 |
A分行 |
1000W |
|
2000年 |
A分行 |
2000W |
|
2001年 |
A分行 |
3000W |
|
1999年 |
B分行 |
500W |
|
2000年 |
B分行 |
1600W |
|
2001年 |
B分行 |
3300W |
维度一般是一个离散的值，比如时间维度上每一个独立的日期或地域，因此统计时，可以把维度相同记录的聚合在一起，应用聚合函数做累加、均值、最大值、最小值等聚合计算。
指标（度量）就是被聚合的通计算，即聚合运算的结果，一般是一个连续的值。
比如我们可以从银行的存款额和企业的贷款额之间的计算，推算出目前的市场状况是如何，如果企业的贷款额高，银行的存款额也高，说明人们不愿意消费了，都把钱存起来，企业产品卖不出去，要发工资，那么自然要贷款了，这只是一个例子，具体还需要结合很多数据做分析。
事实表和维度表是在设计数据仓库过程中需要考虑的。
事实表（Fact Table）是指存储有事实记录的表，如系统的日志、销售记录、用户访问日志等信息，事实表的记录是动态的增长的，所以体积是大于维度表。
用户访问日志（事实表）：用户名、url、时间…
维度表（Dimension Table）也称为查找表（Lookup Table）是与事实表相对应的表，这个表保存了维度的属性值，可以跟事实表做关联，相当于是将事实表中经常重复的数据抽取、规范出来用一张表管理，常见的有日期（日、周、月、季度等属性）、地区表等，所以维度表的变化通常不会太大。
维度表的存在缩小了事实表的大小，便于维度的管理和CURD维度的属性，不必对事实表的大量记录进行改动，并且可以给多个事实表重用。
省份表（维度表）：北京市、广东省、上海市…
业务模型：业务分解和程序化，确定好业务的边界及业务流程，如订单、支付都是一个单独的业务模块
领域模型：业务概念的抽象、分组，整理分组之间的关联，比如用户购物的业务，抽成一个更大的模型，这个模型一般相对于行业。
逻辑建模：领域模型中的业务概念实体化，并考虑实体的具体属性及实体与实体之间的关系，比如订单（订单号、付款人…）和支付（金额、支付时间…）的关系。
物理模型：解决实际应用的落地开发、上线等问题，及性能等一些具体的技术问题。
数据仓库的概念模型（域模型）应该包含企业数据模型的概念模型（域模型）之间的关系，以及各主题域的定义。
数据仓库的概念模型（域模型）应该比业务系统的主题域模型范围更加广。
在数据仓库的逻辑模型需要从业务系统的数据模型中的逻辑模型中抽象实体，实体的属性，实体的子类、关系等，在某些时候反而限制了数据仓库模型的灵活性，在底层数据向数据集市汇总时，需要进行一定的变通。
维度建模法的特点在于需要进行大量的数据预处理、预计算，因此会导致大量的数据处理工作，而且业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理、预计算，使用时直接调用计算好的结果，进而导致大量的数据冗余，最大的作用就是解决了性能的问题。
实体建模法是一种抽象客观世界的方法，细分为一个个实体，以及实体之间的关系，将一个业务划分为3个过程，因此只能局限在业务建模和领域建模的阶段，因此到了逻辑建模阶段和物理建模阶段，则是范式和维度建模的发挥了。
当设计好概念模型时，就要根据概念模型设计逻辑模型，而在设计逻辑模型是，通常根据事实表和维度表的关系，将常见的模型架构分为星型模型和雪花型模型。
星型模型架构是一种非正规化的结构，特点是有一张事实表，多张维度表，是不存在渐变维度的，事实表和维度表通过主外键相关联，维度表之间是没有关联，因为维度表的数据冗余，所以统计查询时不需要做过多外部连接。
雪花模型架构就是将星型模型中的某些维度表抽取成更细粒度的维度表，然后让维度表之间也进行关联，通过最大限度的减少数据存储量以及联合较小的维度表来改善查询性能。
标签：table 仓库 图片 统计 image 方向 proc 效率 xxx
原文地址：https://www.cnblogs.com/-levi/p/11401848.html
