数仓: 1- 数据仓库基础

1- 数据仓库基础

1.1 数据仓库概念和特点

1.1.1 数据仓库的概念

​ 数据仓库 ( Data Warehouse, 简称DW或DWH ) , 也称为企业数据仓库 ( EDW ) , 是一个用于报告和数据分析的系统, 被认为是商业智能的核心组成部分 ; 数据仓库是一个面向主题的、集成的、时变的、非易失的数据集合, 用于支持管理决策 ;

​ 它可以帮助企业整合来自不同数据源的数据, 并将其转换为易于理解和分析的格式 ;

1.1.2 数据仓库的主要特点

1.1.2.1 面向主题的(Subject-Oriented)

• 数据仓库围绕企业的重要主题(如客户、产品、销售等)进行组织 ;
• 不同于操作类型系统围绕应用程序或功能来组织数据 ;
• 提供对特定主题的全面分析视角 ;

1.1.2.2 集成的(Integrated)

• 整合来自多个异构数据源的数据 ;
• 解决数据不一致性问题, 如命名冲突、度量单位差异等 ;
• 提供统一的、一致的数据视图 ;

1.1.2.3 相对稳定的(Non-Volatile) 非易失

• 数据一旦进入数据仓库, 通常不会被修改或删除 ;
• 主要进行数据的加载和访问操作 ;
• 保证数据的一致性和可靠性 ;

1.1.2.4 反应历史变化的(Time-Variant) 时变的

• 存储历史数据, 通常跨越较长时间(如5-10年) ;
• 每条记录都有时间标记, 支持时间顺序分析 ;
• 能够追踪数据随时间的变化趋势 ;

1.1.3 数据仓库其它重要特征

1.1.3.1 支持决策

• 设计用于支持复杂查询和分析 ;
• 提供多维度的数据视图 ;
• 支持 OLAP(联机分析处理) 操作 ;

1.1.3.2 读取密集型

• 主要用于数据查询和分析, 而非事务处理 ;
• 针对大量数据的快速读取进行优化 ;

1.1.3.3 数据粒度

• 存储不同粒度级别的汇总数据 ;
• 支持从高层概况到细节数据的层次分析 ;

1.1.3.4 元数据管理

• 维护关于数据仓库中数据的详细信息 ;
• 包括数据来源、转换规则、数据模型等 ;

1.1.3.5 数据质量

• 强调数据的清洗和一致性 ;
• 实施数据质量管理流程 ;

1.1.4 数据仓库vs操作型数据库

1.1.4.1 数据仓库

• 面向分析和决策支持
• 历史数据和汇总数据
• 读取密集型
• 较低的并发用户数

1.1.4.2 操作型数据库

• 面向日常事务处理
• 当前数据
• 读写密集型
• 高并发用户数

1.1.5 数据仓库的挑战

• 大数据量管理
• 数据集成和清洗的复杂性
• 性能优化
• 数据安全和隐私保护
• 适应不断变化的业务需求

1.2 数据仓库架构

1.2.1 数据源层

• 包括内部外部数据源
• 可能的数据源
  • 运营数据库(如ERP、CRM系统)
  • 外部数据(如市场调研数据、社交媒体数据)
  • 平面文件、日志文件等

1.2.2 数据抽取和转换层(ETL层)

• 负责从源系统抽取数据
• 清洗、转换和集成数据
• 主要组件:
  • 数据抽取工具
  • 数据转换引擎
  • 数据质量工具
• 常用工具: Informatica, Talend, Apache NIFI

1.2.3 数据存储层

1.2.3.1 暂存层(Staging Area)

• 临时存储区域, 用于数据清洗和转换
• 通常不对最终用户开放

1.2.3.2 核心数据仓库

• 存储经过处理的、集成的企业级数据
• 通常采用星型或雪花型
• 可能包含:
  • 原子级数据(最细粒度)
  • 汇总数据

1.2.3.3 数据集市

• 面向特定业务部门或功能的子集
• 从核心数据仓库派生, 或独立建立
• 提供更快的查询性能和更高的灵活性

1.2.4 元数据层

• 存储关于数据仓库的数据
• 包括:
  • 业务元数据(业务术语、指标定义等)
  • 技术元数据(数据模型、ETL映射等)
  • 运营元数据(作业运行动态、数据血缘等)

1.2.5 数据访问

• 提供工具和接口, 用于查询和分析数据
• 主要组件 :
  • OLAP工具(如Cognos, MicroStrategy)
  • 报表工具
  • 数据挖掘工具
  • 自助式BI工具(如Tableau, Power BI)

1.2.6 数据展现层

• 为最终用户提供可视化界面
• 包括 :
  • 仪表盘
  • 交互式报表
  • 数据可视化

1.2.7 数据管理和监控层

• 负责整个数据仓库的管理和监控
• 主要功能 :
  • 性能监控
  • 安全管理
  • 备份和恢复
  • 任务调度

1.2.8 几种常见的数据仓库架构模式

1.2.8.1 独立数据集市架构

• 各部门独立构建数据集市
• 优点: 快速实施
• 缺点: 数据孤岛

1.2.8.2 总线架构(Bus Architecture)

• 使用一致性维度和实事来构建的数据集市
• 优点: 灵活性高
• 缺点: 需要严格的标准

1.2.8.3 中心仓库架构(Hub and Spoke)

• 先建立企业级数据仓库, 再派生数据集市
• 优点: 数据一致性高
• 缺点: 初期投入大

1.2.8.4 联邦架构(Federated Architecture)

• virtual层整合多个数据源和数据集市
• 优点: 利用现有资源
• 缺点: 复杂度高

1.2.9 现代趋势

• 运数据仓库(如 Amazon Redshift, Google BigQuery, 阿里云, 腾讯云等)
• 实时数据仓库
• 大数据技术集成(如hadoop, Spark)
• 数据湖与数据仓库的融合

每个组织可能根据自身需求和资源采用不同的架构 ; 选择合适的架构需要考虑数据量、查询复杂度、预算、现有技术栈等多个因素 .

1.3 OLTP vs OLAP

OLTP (联机事务处理, Online Transaction Processing) 和 OLAP (联机分析处理, Online Analytical Processing) 是两种不同的数据处理方式, 他们的设计目标和应用场景有所区别 .

1.3.1 定义

• OLTP: 面向日常交易的处理系统, 其主要功能是进行高并发、低延迟的事务处理, 例如银行交易、电商下单、库存管理等 ;
• OLAP: 面向分析的处理系统, 其主要功能是对大量历史数据进行复杂查询和分析, 为决策提供支持, 例如销售分析、市场趋势预测、客户行为分析等 ;

1.3.2 主要区别

特性	OLTP	OLAP
目的	处理日常交易, 强调事务的实时性和可靠性	分析历史数据, 强调查询效率和多为分析
数据源	业务系统产生的交易数据	来自多个数据源的数据, 包括OLTP系统、历史数据等
数据结构	通常采用关系型数据库, 数据规范化程度高	通常采用星型模式或雪花模式, 数据冗余度较高
查询类型	简单查询, 例如插入、更新、删除	复杂查询, 例如聚合、联机分析处理(OLAP) 操作
数据更新	实时更新, 每次交易都会更新数据库	定期更新, 例如每天或每周更新一次
用户	大量用户: 业务人员、客户, 高并发	少量用户: 数据分析师、决策者, 低并发
响应时间	毫秒级	秒级甚至更久, 取决于数据量和查询复杂度
数据特征	当前的、最新的详细数据: 规范化的数据结构, 数据量相对较小(GB级别)	历史的、汇总的数据: 反规范化的数据结构(如星型或雪花模型), 数据量大(TB或PB级别)
查询特征	简单、标准化的查询, 通常涉及少量记录, 读写操作频繁	复杂的、即席查询, 通常涉及大量记录, 以读操作为主, 写操作较少
备份和恢复	需要频繁备份, 恢复时间要求短(分钟级)	备份频率较低, 可接受较长时间的恢复
数据保留期	通常只保留当前数据	保留大量历史数据(通常是多年)
系统设计重点	数据一致性和完整性, 避免冗余, 事务处理效率	复杂查询性能, 数据聚合和汇总, 多维度数据视图
典型应用场景	银行交易系统, 航空订票系统, 零售销售系统	销售趋势分析, 财务报告和预测, 客户细分分析
技术实现	关系型数据库(如: Oracle, MySQL), 事务处理监控器	数仓技术, OLAP服务器, 列式数据库(如Vertical, Redshift)

1.3.3 关系

• OLTP 系统是数据的来源, OLAP 系统是数据的使用者;
• 通常情况下, 会将 OLTP系统中的数据定期抽取、清洗、转换后加载到 OLAP系统中, 用于分析和决策 ;

1.3.4 总结

• OLTP 和 OLAP 是两种不同类型的系统, 他们的设计目标和应用场景不同 ;
• OLTP 关注于高并发、低延迟的事务处理, 而 OLAP关注于大量历史数据的复杂查询和分析 ;
• 在实际应用中, 这两种系统通常会结合使用, 以满足企业不同的数据处理需求 ;

1.4 数据仓库设计方法论

1.4.1 Inmon方法论 (自上而下法)

William H. Inmon 被称为 ‘数据仓库之父’, 他提出了企业级数据仓库 (EDW) 的概念 ;

主要特点:

• 自上而下的设计方法
• 强调企业范围的数据集成
• 使用实体关系 (ER) 模型进行设计

设计步骤:

1. 企业数据模型设计
2. 数据仓库物理设计
3. 数据集市设计
4. 实施和部署

优点:

• 数据一致性高
• 适合大型企业
• 全企业范围的数据视图

缺点:

• 初期投入大
• 实施周期长

1.4.2 Kimball 方法论 (自下而上)

Ralph Kimball 提出了以维度建模为核心的方法论 ;

主要特点 :

• 自下而上的设计方法
• 强调业务需求驱动
• 使用维度模型 (星型模型或雪花模型)

设计步骤:

1. 选择业务流程
2. 声明粒度
3. 确定维度
4. 确定事实

核心概念:

• 一致性维度 (Conformed Dimensions)
• 总线架构 (Bus Architecture)

优点:

• 快速交付
• 易于理解和使用
• 灵活性高

缺点:

• 可能产生数据孤岛
• 跨业务过程的分析可能复杂

1.4.3 Data Vault 方法论

Dan Linstedt 提出的一种混合方法, 旨在提供更高效的灵活性和可扩展性 ;

主要特点:

• 结合了3NF和星型模型的优点
• 核心概念: Hub(实体)、Link(关系)、Satellite(属性)

设计步骤:

1. 识别业务键和核心实体 (Hubs)
2. 定义实体间关系 (Links)
3. 添加描述性和上下文信息 (Satellites)

优点:

• 高度灵活和可拓展
• 支持历史追踪
• 适合处理快速变化的数据

缺点:

• 学习曲线陡峭
• 查询性能可能受影响

1.4.4 Anchor 建模

Lars Ronnback 提出的一种高度规范化的建模技术 ;

主要特点:

• 将每个属性都建模为单独的表
• 支持时态数据和高度可扩展性

设计步骤:

1. 识别锚点 (核心业务概念)
2. 定义属性
3. 建立关系
4. 添加时态支持

优点:

• 极高的灵活性
• 优秀的时态数据处理能力
• 方便增加新属性

缺点:

• 表数量多, 管理复杂
• 查询可能需要大量连接操作

1.4.5 敏捷数据库方法论

结合敏捷开发原则的数仓设计方法 ;

主要特点:

• 迭代和增量开发
• 持续交付价值
• 密切的业务参与

设计步骤:

1. 确定高优先级的业务需求
2. 快速原型设计
3. 迭代开发和测试
4. 持续集成和部署

优点:

• 快速交付业务价值
• 适应变化的能力强
• 提高用户满意度

缺点:

• 可能需要更多重构
• 需要高度协作的团队

1.4.6 总结

选择合适的数仓设计方法论时, 需要考虑一下因素:

• 组织规模和文化
• 现有数据架构
• 业务需求的稳定性
• 可用资源和时间限制
• 团队技能和经验

end