~~

数据仓库概述

~~
数据仓库，英文名称为Data Warehouse，可简写为DW或DWH。数据仓库，是为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合。它是单个数据存储，出于分析性报告和决策支持目的而创建。 为需要业务智能的企业，提供指导业务流程改进、监视时间、成本、质量以及控制

数据仓库的特点

1.面向主题
主题域：
每一个主题对应一个宏观的分析领域主题域，是围绕企业某一类核心业务过程或业务对象组织起来的逻辑数据集合，
业务指的是企业为了达成其目标而进行的一系列有组织的活动、流程和操作。例如，电商公司的“交易业务”就包含了从 用户浏览商品、下单、支付到售后 等一系列连贯的过程。
业务 (Business) 与主题域的关系
数据仓库的“面向主题”特性，正是为了服务于这些业务的分析需求。一个“主题域”就是围绕一个核心业务领域（如交易、客户、营销）组织起来的数据集合。
因此：
业务是源头和目的：企业的各项业务活动产生了原始数据，而数据仓库建设的最终目的是为了分析和优化这些业务。
主题域是组织和呈现方式：数据仓库将分散在不同业务系统中的数据，按照业务主题（如交易域、客户域）进行整合、清洗和建模，形成易于分析的数据结构。
业务过程是构成单元：一个主题域由多个具体的“业务过程”组成。例如，“交易域”这个主题就包含了“下单”、“支付”、“退款”等多个业务过程。每个业务过程通常对应一张或多张事实表或维度表。
通过这种映射，数据仓库能够将原始的、面向事务的业务数据，转化为面向分析的、集成的信息，直接支撑如“分析本月各渠道的销售趋势”、“评估营销活动 ROI”等业务决策。
注：一个主题域包含多个业务过程,一个业务需要多张表来表示
比如 交易域 包含 订单、支付、退款、优惠券使用、售后 这些业务过程
2.集成的
在某一个主题下，需要将数据进行提取、清洗、转换和装载等集成操作。数据类型统一 , 数据标准化 ,数据去重
相对稳定的
数据仓库中的数据是相对稳定的，不会因为日常业务操作而频繁更新。数据一旦加载到数据仓库中，通常只会被查询和分析，而不是频繁修改。这种特性使得数据仓库能够支持历史数据分析和趋势预测。
特点：数据仓库中的数据是历史性的、不可变的，适合进行长期的数据分析。
例如，销售数据在数据仓库中会保留多年，用于分析销售趋势、季节性变化等。
反映历史变化
数据仓库中的数据是随时间变化的，能够反映历史数据的变化趋势。数据仓库通常会保留多个时间点的数据，
以便分析数据随时间的变化情况。这种特性使得数据仓库能够支持趋势分析、时间序列分析等。
特点：数据仓库中的数据是带有时间戳的，能够反映数据在不同时间点的状态。
例如，企业可以分析过去几年的销售数据，了解哪些产品在哪些时间段表现最好，从而制定未来的销售策略。
数据仓库 VS 数据库

• 事物的特点
  数据仓库 VS 数据库

• 事务 (Transaction) 的特点
  事务是数据库管理系统（DBMS）中一个核心概念，它代表一个不可分割的工作逻辑单元。一个事务内的所有操作，要么全部成功执行，要么全部不执行，以确保数据从一种一致性状态转换到另一种一致性状态。事务通常具有以下四个特性，合称为 ACID 特性：
  原子性 (Atomicity)
  事务被视为一个不可分割的“原子”操作。事务中的所有操作要么全部完成，要么全部不完成，不会停留在中间某个状态。如果事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从未执行过一样。
  一致性 (Consistency)*
  事务执行的结果必须使数据库从一个一致性状态转变到另一个一致性状态。这意味着事务必须遵守数据库的所有预定义规则（如约束、触发器、级联等），不会破坏数据的业务逻辑完整性。一致性是事务的最终目标，原子性、隔离性和持久性都是为了保障一致性而存在的。
  隔离性 (Isolation)
  数据库系统允许多个事务并发执行。隔离性确保并发执行的事务相互隔离，一个事务的执行不能被其他事务干扰。事务内部的操作及使用的数据对其他并发事务是隔离的，防止出现脏读、不可重复读、幻读等问题。数据库通过不同的隔离级别（如读未提交、读已提交、可重复读、串行化）来实现不同程度的隔离。
  持久性 (Durability)
  一旦事务被提交（Commit），它对数据库中数据的改变就是永久性的。即使后续系统发生故障（如断电、崩溃），已提交事务的结果也不会丢失。数据库通常通过将事务日志写入非易失性存储（如硬盘）来保证持久性。

• ---

数据库的三范式(数据库建模规范)

- 1NF : 列不可再分 - 2NF : 非主键字段完全依赖主键(必须依赖主键的全部字段) - 3NF : 不能存在传递依赖

• 数据库(OLTP)在线事物处理
  数据库主要是处理事物的,属于 OLTP类型
  数据仓库(OLAP)
  数据仓库主要是存储分析数据,属于 OLAP 类型
  核心功能是 分析数据
  数据仓库的设计规范
  优秀可靠的数仓体系，往往需要清晰的数据分层结构，即要保证数据层的稳定又要屏蔽对下游的影响，并且要避免链路过长。那么问题来了，一直在讲数仓要分层，那数仓分几层最好？
  目前市场上主流的分层方式眼花缭乱，不过看事情不能只看表面，还要看到内在的规律，不能为了分层而分层，没有最好的，只有适合的
  数据仓库分层优点
  1.清晰数据结构(明确责任)；
  3.数据血缘追踪；
  4.减少重复开发；
  5.统一加工口径；

6. 屏蔽原始数据的影响
   数据仓库的分层架构

基于业务的建模设计

数据仓库的建模设计必须紧密围绕业务需求展开，其核心目标是构建一个能够准确反映业务、高效支持分析的数据模型。
步骤：

1. 业务调研与需求分析
   建模的第一步是深入理解业务。
   ①识别关键业务过程：与业务部门沟通，明确核心业务流程，如"用户下单"、“商品支付”、“客户服务"等。
   ②定义业务指标：确定需要度量的关键绩效指标（KPIs），如"销售额”、“用户留存率”、“订单转化率”。
   ③明确分析维度：确定分析的角度，如按时间（年、月、日）、地区、产品类别、客户等级等。
2. 概念模型设计
   基于业务调研，划分主题域，这是连接业务与数据的桥梁。
   ①划分原则：将紧密相关的业务过程和数据划分到同一主题域。例如，电商场景可划分为：
   ②交易域：涵盖下单、支付、退款、售后等过程。
   ③用户域：涵盖注册、登录、画像、行为等过程。
   ④商品域：涵盖商品上架、库存、类目等过程。
   ⑤营销域：涵盖活动、优惠券、广告投放等过程。
   ⑥输出物：主题域矩阵图，明确各主题域包含的业务过程和主要数据实体。
3. 逻辑模型设计（维度建模）
   核心步骤，采用维度建模方法，构建事实表和维度表。

• 选择业务过程：从主题域中确定要建模的具体业务过程（如"下单"）。
• 声明粒度：明确事实表中每一行数据所代表的业务含义，如"一个订单项"、“一次支付事件”。粒度是设计的基础。
• 确定维度：描述业务过程的上下文，即"谁、什么、何时、何地、如何"。例如，订单事实表的维度可能包括：时间、商品、用户、渠道等。
• 确定事实：定义可度量的业务数值，通常是可加性指标，如"订单金额"、“商品数量”、“支付金额”。
• 模型类型选择：
  • 星型模型：一个事实表关联多个维度表，结构简单，查询性能高，是最常用的模型。
  • 雪花模型：维度表本身又关联其他维度表，规范化程度高，但查询复杂度增加。

示例：交易域下单业务逻辑模型

• 事实表：fact_order（订单事实表）
  • 粒度：一个订单项（order_item）
  • 维度：dim_time（时间）、dim_product（商品）、dim_user（用户）、dim_store（店铺）
  • 事实：order_amount（金额）、quantity（数量）、discount_amount（折扣金额）
• 维度表：dim_user（用户维度表），包含用户ID、姓名、等级、注册时间等属性。

物理模型设计与实施

① 操作系统：linux 、Windows Server、Unix、IBM AIX、HP-UX
②存储技术： 关系型数据库 ORACLE IBM DB2 SQLServer MySql
国产数据库 阿里云（dataworks） 华为高斯 、达梦、人大金仓 …GP…
分布式大数据技术：Hadoop —HDFS—HIVESQL
③ETL技术：kettle（PDI） ODI informatica IBM datastage ，国产ETL工具 datax 。。。。。
④数据开发工具：PLSQL …
⑤BI工具：Cognos 、Tableau 、Power BI 、 、FineReport FineBI 、永洪BI …
⑥web中间件：Tomcat \ WebLogic \ JBoss

处理多系统数据：订单要区分不同系统吗

在实际企业中，同一个业务实体（如“订单”）的数据可能来自多个独立的业务系统。例如：

• 电商系统：处理线上零售订单。
• 门店POS系统：处理线下门店订单。
• 批发ERP系统：处理B2B大客户订单。
• 移动端小程序：处理社交电商订单。
  答案是：在数据仓库中，通常需要区分不同系统的订单，但最终目标是实现数据的整合与统一分析。
  具体处理方式如下：

1. ODS层：保留来源标识
   在数据接入层（ODS），原样接入各系统数据，但必须为每张表或每条记录增加明确的数据来源系统标识（如source_system字段，值可为'ec_online'、'pos_store'、'erp_wholesale'等）。这是数据血缘追溯的基础。
2. DWD层：清洗、整合与标准化
   这是处理多系统数据的关键层。目标是为“订单”建立一个统一的、干净的、粒度一致的明细事实表（例如dwd_order_detail）
   数据清洗与转换：针对每个来源系统，根据其数据格式和业务规则进行清洗（如状态码映射、金额单位统一、时间格式标准化）。
   业务逻辑统一*：将不同系统中业务含义相同但字段名或值不同的数据对齐。例如，将各系统的“订单状态”映射到一套统一的枚举值（如'待支付'、'已支付'、'已发货'、'已完成'、'已取消'）。
   保留来源信息：在整合后的宽表中，保留source_system字段，甚至可能保留原始订单ID（如original_order_id）和原始系统的一些关键上下文字段（如original_channel）。这便于问题排查和特定场景下的细分分析。
   生成代理键：为整合后的订单生成数据仓库内部的唯一主键（如order_sk），用于关联其他维度。
3. 维度建模中的体现
   • 方案一（推荐）：将“来源系统”作为一个维度。创建dim_source_system维度表，包含系统代码、系统名称、业务类型等属性。在订单事实表中，source_system_sk作为外键关联到此维度表。这样，分析时可以轻松地按系统、按业务类型进行筛选、分组和对比。
   • 方案二：作为事实表的退化维度。如果来源系统属性很少且稳定，也可以直接将source_system_code和source_system_name作为字段冗余在事实表中，避免关联查询。
     总结
     通过上述处理，数据仓库既保留了各系统数据的来源特征（满足溯源和细分分析需求），又将它们整合到统一的模型和口径下。最终，业务用户可以在一个报表中同时查看来自线上、线下、批发等所有渠道的订单总额、趋势和对比，实现真正的全域业务洞察。
     即在接入和清洗阶段要区分（记录来源），在整合和建模阶段要统一（建立一致的事实和维度），在分析阶段可以灵活选择（既可以看整体，也可以下钻看特定系统）。
     将逻辑模型转化为在特定数据仓库中实现的物理结构。
     表命名规范：制定统一的命名规则，如dwd_{业务过程}_{数据粒度}、dim_{维度主题}。
     字段类型与长度：根据数据特性选择合适的数据类型。
     分区与分桶：对大数据量表（如事实表）按时间（dt）进行分区，提升查询效率。
     索引策略：在维度表的关联键、常用过滤条件字段上建立索引。
     核心原则
     业务为核心，始终从业务问题和分析需求出发，避免为技术而技术；始终保持一致性，相同的业务术语和指标在整个仓库中定义必须唯一；在模型复杂度与查询性能之间取得平衡；完善的数据字典和血缘文档是模型可持续维护的保障。
     通过以上步骤，可以将模糊的业务需求，转化为清晰、稳定、高效的数据仓库模型，真正发挥数据驱动决策的价值。

注：
①ODS：ODS 层，是最接近数据源中数据的一层，为了考虑后续可能需要追溯数据问题，因此对于这一层就不建议做过多的数据清洗工作，原封不动地接入原始数据即可，至于数据的去噪、去重、异常值处理等过程可以放在后面的 DWD 层来做。
②DWD：DWD 是数据仓库的主要存储层，用于存放经过清洗、整合、加工后的详细数据。DWD 层主要完成了数据的清洗、去重、数据格式转换等工作，确保数据质量和一致性，并且保留了数据的详细信息。支持数据的历史追溯，提供了基础数据的单一版本，适合进行数据挖掘、分析和报表等操作该层一般保持和 ODS 层一样的数据粒度，并且提供一定的数据质量保证。DWD层要做的就是将数据清理、整合、规范化，把脏数据、垃圾数据、规范不一致的、状态定义不一致的、命名不规范的数据处理掉。
同时，为了提高数据明细层的易用性，该层会采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联。另外，在该层也会做一部分的数据聚合，将相同主题的数据汇集到一张表中，提高数据的可用性
③DWS：则基于DWD层数据，按主题进行轻度或中度汇总。比如生成产品销售汇总、用户每日行为统计等。这些数据通常以宽表形式存储，目的是提高后续分析的效率。
④ADS：这一层是面向业务需求定制的。它从DWS或DWD中取数，进一步汇总成适合特定部门或场景使用的数据集。比如，市场团队可能需要广告效果分析表，财务团队则需要收支报表。DM层就是为他们准备的，结构简洁、查询高效，更贴近业务用语。