数据仓库系列总结
一、数据仓库架构
1、数据仓库的概念
数据仓库（Data Warehouse）是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。
数据仓库通常包含多个来源的数据，这些数据按照主题进行组织和存储，以便于分析和报告。数据仓库中的数据一般不再进行更新或删除操作，而是存储历史数据，以便进行历史趋势分析或进行数据挖掘。数据仓库的设计和实施需要考虑数据的安全性、完整性和准确性，以及如何有效地检索和呈现数据。数据仓库是BI（商业智能）系统的核心，它不仅存储数据，还提供数据管理、分析和报告的功能。
2、关系性数据库和数据仓库
OLTP:OLTP系统通常面向的主要数据操作是随机读写，主要采用满足3NF的实体关系模型存储数据，从而在事务处理中解决数据冗余和一致性问题；主要适用于传统关系型数据库；
OLAP:OLAP系统面向的主要的操作是数据的批量读写，事务处理过程中的一致性不是OLAP关注的，其主要关注数据的整合，以及在一次性的复杂大数据查询中和处理中的性能，因此会采用一些不同的建模方法。
注：3NF 三范式
第一范式：原子性，确保数据库表的每一列都是不可分割的原子数据项，即列中的数据要么是一个整体，要么是单独的元素
第二范式：唯一性，在满足第一范式的基础上，消除非主键列对主键的部分依赖。即非主键列必须直接依赖于主键，不能间接依赖于主键。
第三范式：传递性，在满足第二范式的基础上，消除非主键列之间的传递依赖。即如果非主键列依赖于其他非主键列，则必须将这些非主键列移至新的表中。
3、数据仓库架构
3.1数仓基本架构
3.2数据仓库分层的好处
1. 清晰数据结构：每一个数据分层都有它的作用域，在使用表的时候能更方便地定位和理解。
2. 统一数据口径：通过数据分层，提供统一的数据出口，统一对外输出的数据口径。
3. 减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。
4. 把复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，而且便于维护数据的准确性。且以空间换时间；
4、数据仓库规范
可参考MaxCompute数据仓库的公共规范_云原生大数据计算服务 MaxCompute(MaxCompute)-阿里云帮助中心
二、数据采集
1、同步方式
1.1 批量同步
1.2 实时同步
2、数据同步解决方案
2.1分库分表的处理
2.2 高效同步和批量同步
2.3 增量同步和全量同步的合并
2.4 同步性能的处理
2.5 数据漂移的处理
数据漂移通常是指ODS表在同一个业务日期数据中包含前一天或后一天凌晨附近的数据或者丢失当天变更的数据，也称作零点漂移。
2.5.1数据漂移的原因
由于ODS需要承接面向历史的细节数据查询需求，这就需要物理落地到数据仓库ods层的表按照时间段来切分分区进行存储，通常做法事按照某些时间戳字段进行切分，而实际上由于时间戳字段的准确性问题导致了数据发生漂移。一般来说数据库会有以下时间戳字段：
数据创建时间 create_time
数据更新时间 modified_time
数据日志时间 log_time
业务时间 process_time
数据抽取时间 extract_time
理论上这几个时间是同一天是一致的，但是实际生产中，这几个时间往往存在差异，主要原因可能是：
①由于数据抽取是需要时间的，extract_time往往会晚于其他时间；
②前台业务系统手工订正数据时未更新modified_time;
③由于网络或者系统压力问题，log_time或者modified_time晚于process_time
2.5.2数据漂移的场景
①
2.5.3数据漂移的处理方法
①
3、数据同步工具的使用
三、离线开发
thread.sleep(9)
四、实时开发
thread.sleep(8)
五、数据建模
1、数据模型设计原则
（1) 高内聚、低耦合
即主题内部高内聚、 不同主题间低耦合。明细层按照业务过程划分主题，汇总层 按照“实体+ 活动”划分不同分析主题，应用层根据应用需求划分不同应用主题。
（2) 核心模型和扩展模型要分离
建立核心模型与扩展模型体系，核心模型包括的字段支持常用的核心业务，扩展 模型包括的字段支持个性化或少量应用的需要，不能让扩展模型的字段过度侵入
核心模型，以免破坏核心模型的架构简洁性与可维护性。
（3) 公共处理逻辑下沉及单一
越是底层公用的处理逻辑越应该在数据调度依赖的底层进行封装与实现，不要让 公用的处理逻辑暴露给应用实现，不要让公共逻辑多处同时存在。
（4) 成本与性能平衡
适当的数据冗余可换取查询和刷新性能，不宜过度冗余与数据复制。
（5) 数据可回滚
处理逻辑不变，在不同时间多次运行数据结果确定不变。
2、星型模型与雪花模型
数仓的维度建模是一种将数据结构化的逻辑设计方法，也是一种广泛应用的数仓建模方式，它将客观世界划分为度量和上下文。度量是常常是以数值形式出现，事实周围有上下文包围着，这种上下文被直观地分成独立的逻辑块，称之为维度。它与实体-关系建模有很大的区别，实体-关系建模是面向应用，遵循第三范式，以消除数据冗余为目标的设计技术。维度建模是面向分析，为了提高查询性能可以增加数据冗余，反规范化的设计技术。
上面的解释看起来是比较抽象，一下子可能不是很容易懂。我们先来了解一下事实和维度，基于上面再来分析一下。
事实，表示的是某一个业务度量。比如说订单的金额，订单中出售商品的数量。维度模型中的事实表存放的就是这些业务度量，也就是业务过程中事件的性能度量结果。《数据仓库工具箱》中有这样一段描述:
物理世界的每一个度量事件与对应的事实表行具有一对一的关系，这思想是维度建模的基本原则，其他的工作都是以此为基础建立的。
事实就是一个具体发生的业务过程的状态，以及用来描述该具体的业务过程的指标构成的一行记录，多行记录就构成一张事实表。比如一个订单就是一个事实，而多个事实聚集而成的一张二维表就是事实表。
维度，维度是事实不可或缺的组成部分，维度就是事实的上下文，也就是用来描述事实发生时某个方面对应的状态。像是何时、何地、何人、发生了什么、怎么做、为什么这么做等。举个具体的例子，比如在18点，小明下了一个苹果的订单，那么在这里下了订单是事实，18点是时间维度，小明是用户维度，苹果是商品维度，通过这些谓词，我们就可以了解具体发生了什么，这个也是我们多为分析的一个基本朴素的思想。这些一个一个具体的维度聚集而成的二维表就是维度表，一般维度都是有限的。
下面是一个具体的维度建模的例子，以订单为例。
基于上面的理解，我们就可以比较好的了解我们的维度建模了。这里我给出我个人的描述，这样会比较好理解一些。
维度建模,就是将我们的每一个业务过程，拆分为事实表和维度表，事实表对应着具体的指标度量，维度表对应着事实的描述，状态，也就事实对应的环境。
这种结构，将事实表置于中心，多个维度围绕着事实，如上图，这种结构呈现星状，所以这种模型，就叫星型模型。多个星型模型聚集在一起就叫星座模型。
从多个维度分析数据，也就叫做多维立方体分析，这里就不做过多介绍，后续在其他文章中介绍。
下面这个图可以用于理解星型模型与多维立方体分析。
3、数据建模的优劣有哪些？
参考链接：https://www.zhihu.com/question/641112810/answer/3375544328
优势：
- 促进数据共享和协作，共享应该是建模最重要的作用了：数据模型可以作为组织内不同部门之间共享数据的共同语言，促进数据的共享和协作。
- 更好的理解数据，更好的贴近业务：通过创建数据模型，人们可以更清晰地了解数据的结构、关系和约束，从而更好地理解数据，同时也能更具象的理解业务过程；
- 提高数据质量，保障指标一致性：数据建模可以帮助发现和纠正数据中的错误、冗余和不一致，从而提高数据质量，进一步作用可以提高报表、应用数据的一致性；
- 提高数据处理效率：良好的数据模型可以优化数据的存储和检索方式，从而提高数据处理的效率。
- 支持数据分析和可视化：数据模型可以为数据分析和可视化工具提供基础，使其更容易理解和解释数据。
- 支持决策制定：数据模型可以提供有关数据的关键信息，帮助决策者做出更明智的决策。
局限性：
肯定是利大于弊的，不然每个公司不停的建模就没有意义了~~
- 复杂性：数据建模可能非常复杂，需要专业的知识和技能。对于大型和复杂的数据集，建模过程可能非常耗时。
- 数据变更的敏感性：数据模型依赖于数据的结构和关系，如果数据发生变化，可能需要对模型进行相应的调整。
- 过度抽象：有时候，为了追求模型的简洁和一般性，可能会导致模型过于抽象，从而失去对具体数据的一些细节和特征的捕捉。
- 模型误差：无论如何努力，数据模型都无法完全代表现实世界，因此可能存在模型误差。
- 限制灵活性：一旦建立了数据模型，它可能会限制对数据的某些操作和分析方式，从而降低了灵活性。
六、维度建模
1、缓慢变化维的处理
数据仓库（数仓）的重要特点之一是反映历史变化，所以如何处理维度的变化是维度设计的重要工作之一。缓慢变化维的提出是因为在现实世界 中，维度的属性并不是静态的，它会随着时间的流逝发生缓慢的变化，与数据增长较为快速的事实表相比，维度变化相对缓慢。阴齿这个就叫做缓慢变化维。
目前主流的缓慢变化维的处理方式：
- 原样保留或者重写，这种方式理论上都是取最新的值作为维度的最终的取值，每个维度保留一条数据。这种处理方式是最简单的，直接将原系统的维度同步过来使用就可以，不用做过多的处理。
- 插人新的维度行，每当维度发生变化的时候，插入新增的一行。采用此种方式，保留历史数据， 维度值变化前的事实和过去的维度值关联，维度值变化后的事实和当前的维度值关联。也就是一个维度会存在多行的数据，按时时间范围将维度与事实表关联。
- 添加维度列，采用这种方式，主要是为了将变化前后记录的事实归为变化前的维度或者归为变化后的维度。也就是将产生变化的维度，可以在汇总的时候按照统一分组处理。
- 快照存储,这种方式就是每一个周期定时保存一份数据，与第二点有点想，不过这里会产生很多冗余的数据，当维度里大部分行在周期内，变动频繁的时候，可以采用。不过按照个人的开发经验，不恨很建议采用，具体要根据业务实际情况来选择。
- 极限存储历史拉链表，这种方式是方式2的优化版，就是当新的维度行与旧的维度行变化前后一致的时候，会合并一条。还有一点一般拉链表的时间粒度可能知道天，但是方式2，一般到秒，拉链表也是到秒。其他的与方式2一致。历史拉链表既能满足对历史数据的需求，又能很大程度的节省存储资源。什么是历史拉链表？历史拉链表是维护了历史状态，以及最新状态数据的一种表。 拉链表存储的数据实际上相当于快照，只不过做了优化，去除了一部分不变的记录而已,通过拉链表可以很方便的还原出拉链时点的客户记录。 拉链表既能满足反应数据的历史状态，又可以最大程度的节省存储，提高查询效率。
2、一致性维度
什么是一致性维度？
维度一直是大家所熟知的，但是前面加上了“一致性”之后便成了数据仓库特有的一类维度表，其实一致性维度在表结构和属性都没有本质的区别，有一点的差异是数据仓库的星型模型会使得维度表有一定的冗余。那么一致性体现在哪里呢： 维度共享性。共享性体现在整个平台或整个部门共用维度，而不仅仅只是单纯某个业务单独使用。 一般的维度并没有把共享性作为一个共性的标准。然而在维度建模中，一致性维度将作为重心来做。数据仓库70%的工作量和复杂度是用在构建一致性维度。一致性维度将作用于数据仓库和数据集市甚至是OLAP。
合适会用到一致性维度？
一致性维度的构建是先于事实表的构建的，但又不是在构建完成一致性维度之后才开始构建事实表，在构建的过程中肯定会有一定的调整。当在构建事实表的时候如果遇到了比较复杂和困难的问题的时候，也要考虑一致性维度构建的是不是合理。一致性维度在生成数据仓库中的Oneid时有重要的作用；
哪些地方可以用到一致性维度？
90%+的维度表是直接从ODS层进行ETL建设成的，一般都是业务的基本描述信息，这一过程是在数据缓冲区来做，输出在数据仓库DW层的最底部。还有一些维度的信息或者属性需要建立在数据集市的基础上，一般是用来做分析的指标或者标签，这个时候需要用集市层的汇总数据来打维度的标签，比如商户的标签。这样的维度信息需要回传到原有的维度表。
如何构建一致性维度？
首先用过对业务过程进行梳理，将业务过程所携带的维度信息整理出来生成总线矩阵。一般情况同属一个价值链的业务过程的维度信息大致相同。然后是针对每个维度逐一审核相关的业务过程，对各个业务过程的维度值进行标准化。之后是对不同的业务的维度信息进行汇总，选择或者生成主键。最后设计维度表，并进行适当的迭代更新。
为什么使用一致性维度？
容易管理，一致性维度不仅规范化，而且大大减少维度表的数量。
容易使用，同一主题或者实体的维度表单一，容易获取和使用。所有的事实共享同样的维度，容易进行交叉计算。
七、事实表设计
thread.sleep(5)
八、数据管理
thread.sleep(4)
九、数据治理
thread.sleep(3)
十、数据服务
thread.sleep(2)