[TOC]
第六章 分布式数据仓库(相对集中式数据仓库)
6.0 概述
- 大部分企业使用集中式数仓，但某些特殊场景需要建立分布式数仓
- 数据体系结构
设计者需清楚以下问题
6.1 分布式数据仓库的类型（3种）
- 局部数据仓库和全局数据仓库
-
适用范围
- 拥有许多不同业务（如阿里的淘宝与支付宝）
- 业务遍布世界各地（如KFC在世界各地餐饮）
- 分部拥有大量业务处理
- 大部分操作在分部进行，少量或特定操作发布到总部进行
-
局部数据仓库
- 仅包含局部站点上的数据
- 有各自的技术、数据和处理器
- 局部数仓间的数据和数据结构不需要协调一致(无论是数据、处理过程或定义都不需要)
-
全局数据仓库
- 范围涉及整个企业或组织
- 数据来源通常是局部数仓
- 包括需要全局管理的信息（如
财务、客户、产品等） - 自然重叠的数据最好放到全局数仓
-
局部到全局
- 局部数仓--
简单转换-->全局数仓 （如单位、货币） - 分布式仓库成功的关键--
局部-->全局的映射
- 局部数仓--
-
数据冗余
- 大部分数据都是经过转换和汇总的，这些不算冗余
- 少量不经过变化算冗余，但少量不影响，多了就容易出现蜘蛛网
-
数据查询
- 原则上局部数据应局部使用，全局数据应全局使用（因为局部人员无法进行
全局决策）
- 原则上局部数据应局部使用，全局数据应全局使用（因为局部人员无法进行
局部数据至全局数据间的映射必须由分部参与，总部无法集中建设
分部的数据尽可能灵活，即低粒度，及关系模型（不能使星型模型？）
-
graph TB
A[全局仓库] -->|发送模型| B(局部仓库1)
A[全局仓库] -->|发送模型| C(局部仓库2)
A[全局仓库] -->|发送模型| D(局部仓库3)
B -->|转换汇总返回| A
C -->|转换汇总返回| A
D -->|转换汇总返回| A
- 技术上分布的数据仓库
- 逻辑上还是一个数仓，只是物理上分布在多个处理器上（现在有点规模的都这样了）
- 必然的结果（个人加的）
- 独立演进的分布式数据仓库
- 数仓以一种不协调的方式建立，首先建立一个数仓，然后又建立另一个
- 如先建立财务的仓库，后来做市场的，但没有统一进行定义及设计
6.2 开发项目的本质特征（多个数仓开发）
- 设计者需了解数仓项目的类型及与体系结构的关系，才能更好的管理及协调
- 多个数仓项目同时出现的4种情况
- 业务完全分离，不需要集成
- 不常见
- 不同小组，负责不同业务的数仓的建立
- 很少或不需要进行协调和管理
- 财务数据总应是集成的
- 多个小组，负责同一数仓的不同部分
- 较常见，
特别关注 - 同一细节数据由不同小组开发，因分散在地理位置（分布式）
- 必须进行有效协调和管理
- 较常见，
- 不同小组，负责仓库的不同级的数据
- 较常见
- 如一个小组处理最低级细节层，另一个处理汇总数据
- 最容易管理
- 不同小组，负责同一粒度的数据
- 不常见，
特别关注 - 同一细节数据由不同小组开发，但非分布式
- 必须进行有效协调和管理
- 不常见，
- 业务完全分离，不需要集成
