一.数据仓库定义
数据仓库就是面向主题的、集成的、相对稳定的、随时间不断变化（不同时间）的数据集合，用以支持经营管理中的决策制定过程、数据仓库中的数据面向主题，与传统关系数据库面向应用相对应。
二.数据仓库与传统数据的区别
数据仓库是用于分析的数据库，传统的关系型数据库是面向业务的，为具体的业务提供支撑。
数据仓库是集成的，数据仓库的数据有来自于分散的操作型数据，将所需数据从原来的数据中抽取出进行加工与集成，统一与综合之后才能进入数据仓库.
数据仓库是不可更新的，数据仓库主要是为决策分析提供数据，所涉及的操作主要是数据的查询
随着时间的增长，数据仓库数据量会很大
与关系型数据库相比，数据仓库的设计允许冗余
为了更好的为业务决策服务，数据仓库的设计要求如下：
1.效率足够高，尽量的低延迟，隔天能看到历史的数据分析数据
2.数据质量，在ETL过程中，避免脏数据或者代码有误导致的数据不准确误导决策者
3.扩展性，考虑到随着时间的推移，以及业务的变动，数据量增大，数据仓库要合理建模，适度增加中间层（olap,cube），缓冲数据量增大带来的压力
4.根据决策者重点关心的方向，提取主题，排除无用的主题
三 数据仓库系统的组成
数据源，ETL，数据仓库，应用
四.数据仓库建模
维度建模(dimensional modeling)是数据仓库建设中的一种数据建模方法。
维度表：表示对分析主题所属类型的描述。就是你观察该事务的角度，是从哪个角度去观察这个内容的。
事实表：表示对分析主题的度量。
维度建模的模式：星形模式，雪花模式，星系模式（星座模式）
星形模式：维表只和事实表关联，维表之间没有关联；以事实表为核心，维表围绕核心呈星形分布；
雪花模式：是星形模式的扩展，每个维表可继续向外连接多个子维表
星形模式中的维表相对雪花模式来说要大，而且不满足规范化设计。雪花模型相当于将星形模式的大维表拆分成小维表，满足了规范化设计。然而这种模式在实际应用中很少见，因为这样做会导致开发难度增大，每次查询需要太多关联，而数据冗余问题在数据仓库里并不严重。
星座模式：一个维表也可能被多个事实表用到
在业务发展后期，绝大部分维度建模都采用的是星座模式。
共享维度
细节/聚集事实表
细节事实表(detailed fact tables)中每条记录表示单一事实，而聚集事实表(aggregated fact tables)中每条记录则聚合了多条事实。
两种事实表各有优缺点，细节事实表查询灵活但是响应速度相对慢，而聚集事实表虽然提高了查询速度，但使查询功能受到一定限制。
一个常见的做法是使用星座模型同时设置两种事实表(可含多个聚集事实表)。
缓慢变化维度
五 数据仓库系统的实现和使用
数据仓库系统以前通常是建在关系型数据库基础上，随着大数据的发展，使用SPARK SQL,hive创建数据仓库逐渐成为趋势，建模与实现分开，先用建模工具建模，然后用HIVE或者spark sql实现，ETL工作的实质就是从各个数据源提取数据，对数据进行转换，并最终加载填充数据到数据仓库维度建模后的表中。
抽取(Extract)：根据数据仓库的设计要求，从各个数据源搜集数据。
转换(Transform)：对提取好了的数据的结构进行转换清洗，以满足目标数据仓库模型的过程
加载(Load)：将转换好的数据加载的数据仓库
然后就是olap，维度建模，展示维度建模分析与SQL查询相比，设计好后简单但不够灵活
cube的架构模式通常有三种：MOLAP(Multidimensional Online Analytical Processing)，ROLAP(Relational Online Analytical Processing)，HOLAP(Hybrid Online Analytical Processing)
cube的常用操作：切片，切块，旋转，上卷，下钻
ETL通过清洗和转换最后将数据加载到数据模型中
ETL的主要任务是在交付过程中划分维度和事实
数据仓库，英文名称为Data Warehouse，可简写为DW或DWH，是一个面向主题的、集成的、随时间变化的、相对稳定的数据集合，用于对管理决策过程的支持。
数据集市
数据仓库只限于单个主题的区域，例如顾客、部门、地点等。数据集市在从数据仓库获取数据时可以依赖于数据仓库，或者当它们从操作系统中获取数据时就不依赖于数据仓库。
OLAP（联机分析处理）与OLTP（联机事务处理）
OLAP(Online Analytical Processing,联机分析处理)和OLTP(Online Transaction Processing,联机事务处理)
数据流向关系
OLTP → ETL → 数据仓库（OLAP）
即：业务系统产生数据 → 抽取清洗 → 加载至分析系统供决策使用 。
ODS DWD DWS ADS
数据仓库四层架构中，ODS、DWD、DWS、ADS层层递进，分工明确：ODS是原始数据入口，DWD实现明细清洗，DWS完成轻度汇总，ADS支撑应用输出。这四层共同构建了从源系统到业务价值的完整数据链路 。
🔹 各层核心功能详解
ODS 层（Operational Data Store，操作数据存储 / 贴源层）
功能定位：数据仓库的“第一站”，直接对接业务数据库、日志、接口等原始数据源。
核心作用：
原始数据快照：保持与源系统结构一致，不做复杂加工，仅做去重、字段映射等基础处理 。
风险隔离：避免源系统变更直接影响数仓内部逻辑。
历史回溯：通过全量或增量方式保留历史状态，弥补源系统数据覆盖更新的问题 。
数据特征：高冗余、细粒度、未清洗，数据量最大。
DWD 层（Data Warehouse Detail，数据仓库明细层）
功能定位：数据规范化的核心层，面向分析构建最细粒度的事实表和维度表 。
核心作用：
数据清洗：去噪、补缺失值、修异常、脱敏等。
维度退化：将分散的维度信息（如用户等级、商品分类）整合进宽表，减少后续JOIN操作。
标准化建模：统一字段口径（如“北京”与“北京市”统一为“北京市”），支撑上层复用 。
数据特征：干净、规范、原子级明细数据，是DWS和ADS的基础。
DWS 层（Data Warehouse Summary，数据仓库汇总层）
功能定位：面向主题的轻度汇总层，提升查询效率 。
核心作用：
按主题聚合：如按“用户”、“商品”、“时间”维度统计日活、销售额、转化率等通用指标。
支撑高频分析：沉淀80%的共性需求，避免重复扫描DWD亿级明细数据 。
数据特征：粒度较粗（通常按天），结构稳定，直接服务于ADS或BI报表。
ADS 层（Application Data Service，应用数据服务层）
功能定位：面向最终业务场景的数据出口，为报表、大屏、接口提供即查即用的结果数据 。
核心作用：
定制化输出：为特定应用定制宽表或指标集，如“地图销售可视化数据”、“用户画像标签表” 。
快速响应：采用OLAP技术优化查询性能，支持实时或准实时分析 。
数据共享：通过API或BI工具对外提供服务，是数据价值落地的关键环节。
数据特征：高度聚合、业务可读性强、更新频率高。
维度建模
维度建模是数据仓库设计中一种核心的逻辑建模方法，由Ralph Kimball提出，主要用于支持高效的数据分析与商业智能（BI）决策。其核心思想是将数据划分为事实（度量数据）和维度（上下文环境），通过星型模式或雪花模式组织数据，提升查询性能与业务可读性 。
核心组成
事实表（Fact Table）
存储业务过程中的度量值，如销售额、订单数量等数值型数据，包含指向维度表的外键 。
特点：数据粒度细、记录量大、以“可加性”为主。
示例：一次销售交易中的销售金额、数量。
维度表（Dimension Table）
提供事实发生的上下文信息，如时间、产品、客户、地理位置等描述性属性 。
特点：文本为主、行数较少、便于过滤和分组。
示例：时间维度表包含年、月、日；产品维度表包含品类、品牌、价格区间。
星型模式（Star Schema）
结构特点：以一个事实表为中心，多个维度表直接连接其上，形成星形拓扑结构 。
事实表：存储可度量的业务数据，如销售额、订单数量等 。
维度表：提供上下文信息，如时间、产品、客户等，不进行规范化，存在冗余但查询高效 。
优势：
结构简单直观，易于理解和设计
查询性能高，仅需少量表连接
适用场景：单业务过程、对查询速度要求高的数据集市
二、雪花模式（Snowflake Schema）
结构特点：在星型模式基础上对维度表进行规范化拆分，形成多层级的子维度表，结构形似雪花 。
示例：产品维度表可拆分为“产品→品类→类别→品牌”多个层级表 。
优势：
减少数据冗余，节省存储空间
提升数据一致性和治理能力
劣势：
查询需多层连接，性能较低
设计与维护复杂度高
适用场景：数据质量要求高、层级复杂的金融、医疗分析等场景
三、星座模式（Fact Constellation Schema）
结构特点：包含多个事实表，共享一组公共维度表（如时间、产品），也称“星系模型” 。
示例：销售事实表与库存事实表共享时间、产品、地区维度 。
优势：
支持跨业务主题的综合分析
维度表复用性强，提升模型一致性
劣势：
架构复杂，ETL维护成本高
查询优化难度大，性能不稳定
适用场景：大型企业级数据仓库，需整合销售、库存、财务等多个业务域
星型模式、雪花模式、星座模式的选型决策树，本质上是根据业务需求、性能要求与数据复杂度，在查询效率、存储成本和维护灵活性之间做出权衡。以下是基于实际项目经验提炼出的结构化决策路径：
✅ 星型模式（Star Schema）——“快而稳”的首选
适用条件 → 决策结果
条件1：分析场景聚焦单一业务过程（如销售、订单）
条件2：要求查询响应在秒级内完成（如BI仪表盘实时展示）
条件3：维度层级简单（≤2层，如产品→品类）
条件4：存储资源充足或数据量中等（<1亿条事实记录）
👉 结果：选择星型模式
✔ 查询性能最优 | ✔ 开发维护简单 | ✔ 业务可读性强
示例：零售门店日销分析，连接时间、产品、门店三张宽维表，直接聚合销售额。
✅ 雪花模式（Snowflake Schema）——“精而省”的治理之选
适用条件 → 决策结果
条件1：维度具有多层级结构（≥3层，如国家→省→市→区）
条件2：数据频繁更新（如客户标签、产品分类动态调整）
条件3：存储成本敏感（如日增千万级物联网数据）
条件4：对数据一致性与合规性要求高（如金融、医疗行业）
👉 结果：选择雪花模式
✔ 存储效率高 | ✔ 数据无冗余 | ✔ 支持精细化治理
示例：三甲医院诊疗数据仓库，患者维度拆分为基础信息、医保类型、就诊科室等子表，确保数据规范统一。
✅ 星座模式（Galaxy Schema）——“广而联”的集成之选
适用条件 → 决策结果
条件1：需整合多个业务主题（如销售 + 库存 + 会员积分）
条件2：多个事实表共享公共维度（如统一的时间、产品、客户维度）
条件3：企业级数据仓库建设，追求模型一致性
条件4：有成熟的ETL流程与元数据管理机制
👉 结果：选择星座模式
🔁 混合架构实践建议（真实场景推荐）
大多数企业并非“三选一”，而是采用分层混合策略：
层级 推荐模型 理由
ODS层（原始层） 雪花模型 保证数据规范化与一致性
DWD/DWS层（明细/汇总层） 星型模型 提升查询性能，支撑BI分析
ADS层（应用层） 星座模型 整合多主题，支持综合报表
浙公网安备 33010602011771号