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.4.2 Kimball 方法论 (自下而上)
Ralph Kimball 提出了以维度建模为核心的方法论 ;
主要特点 :
- 自下而上的设计方法
- 强调业务需求驱动
- 使用维度模型 (星型模型或雪花模型)
设计步骤:
- 选择业务流程
- 声明粒度
- 确定维度
- 确定事实
核心概念:
- 一致性维度 (Conformed Dimensions)
- 总线架构 (Bus Architecture)
优点:
- 快速交付
- 易于理解和使用
- 灵活性高
缺点:
- 可能产生数据孤岛
- 跨业务过程的分析可能复杂
1.4.3 Data Vault 方法论
Dan Linstedt 提出的一种混合方法, 旨在提供更高效的灵活性和可扩展性 ;
主要特点:
- 结合了3NF和星型模型的优点
- 核心概念: Hub(实体)、Link(关系)、Satellite(属性)
设计步骤:
- 识别业务键和核心实体 (Hubs)
- 定义实体间关系 (Links)
- 添加描述性和上下文信息 (Satellites)
优点:
- 高度灵活和可拓展
- 支持历史追踪
- 适合处理快速变化的数据
缺点:
- 学习曲线陡峭
- 查询性能可能受影响
1.4.4 Anchor 建模
Lars Ronnback 提出的一种高度规范化的建模技术 ;
主要特点:
- 将每个属性都建模为单独的表
- 支持时态数据和高度可扩展性
设计步骤:
- 识别锚点 (核心业务概念)
- 定义属性
- 建立关系
- 添加时态支持
优点:
- 极高的灵活性
- 优秀的时态数据处理能力
- 方便增加新属性
缺点:
- 表数量多, 管理复杂
- 查询可能需要大量连接操作
1.4.5 敏捷数据库方法论
结合敏捷开发原则的数仓设计方法 ;
主要特点:
- 迭代和增量开发
- 持续交付价值
- 密切的业务参与
设计步骤:
- 确定高优先级的业务需求
- 快速原型设计
- 迭代开发和测试
- 持续集成和部署
优点:
- 快速交付业务价值
- 适应变化的能力强
- 提高用户满意度
缺点:
- 可能需要更多重构
- 需要高度协作的团队
1.4.6 总结
选择合适的数仓设计方法论时, 需要考虑一下因素:
- 组织规模和文化
- 现有数据架构
- 业务需求的稳定性
- 可用资源和时间限制
- 团队技能和经验