数据仓库入门

发表于 | 分类于 |

1 概览

(1) 理解

  • 是与组织运营数据库隔离的数据库。

  • 更新频率不高

  • 处理聚合的历史数据，用于业务分析

  • 帮助组织、理解和使用数据，以便策略决策

  • 帮助聚合多种应用系统

(2) 与运营数据库隔离

  • 应用目的不同

    数据仓库用于执行复杂且通用格式的数据。运营数据库用于特定的任务和负载，如搜索特定记录和索引等。

  • 性能要求不同

    运营数据库需要支持事务、并发和恢复，而数据仓库不需要。

  • 数据操作不同

    数据仓库只能读，而运营数据库可以修改。

  • 管理对象不同

    数据仓库管理历史数据，运营数据库管理当前数据。

(3) 用途

  • 信息处理

    查询、简单统计和报表展示等

  • 分析处理

    简单OLAP操作，如slice-and-dice、drill down、drill up和pivoting等

  • 数据挖掘

    查找隐含模式和联系、构建分析模型、分类和预测等

(4) OLAP与OLTP

image-20200523233925606

2 概念

(1) 数据仓库技术

是构建和使用数据仓库的过程，包含数据清洗、数据整合和数据统一。整合多源异构数据，用于报表分析、结构和/或点对点查询，以及决策支持等。

(2) 整合异构数据库

1) 查询驱动方式

传统方式，在多源异构数据库上构建wrappers和integrators(mediators)。

1‘ 过程
  • 客户端发起查询 -> 元数据字典翻译查询到单独的节点
  • 查询被映射和发送到本地查询处理器
  • 查询结果整合到全局答案集中
2’ 缺点
  • 整合和过滤过程复杂
  • 低效
  • 频繁查询或聚合查询代价高

2) 更新驱动方式

当前数据仓库采用方式。提前整合数据并存储到仓库中，可以直接查询和分析。

优点
  • 不需要本地处理接口
  • 高效
  • 数据在语义数据存储中被提前拷贝、处理、整合、标记、概括和重构。

(3) 数据仓库功能

  • 数据提取：从多源异构数据源获取数据
  • 数据清洗：查找并纠正数据中错误
  • 数据转换：转化为仓库数据格式
  • 数据加载：排序、概括、统一、检查完整性、构建索引和分区
  • 刷新：从数据源更新

注意：数据清洗和数据转换是提高数据和挖掘结构质量的关键。

3 术语

(1) 元数据

关于数据的数据。是一种指向详细数据的概括数据。

在数据仓库中，主要用于：

  • 路标（road-map）
  • 定义仓库对象
  • 作为目录，用于定位数据内容

(2) 元数据仓库

是数据仓库系统的一部分，包括：

  • 业务元数据

    包括所有者、业务定义和变更策略。

  • 操作元数据

    包括当前数据和数据血缘。当前数据是正在激活的、归档的或清理的。数据血缘是数据转移和转换的历史。

  • 关于运营环境和数据仓库的映射数据

    包括源数据库及内容、数据提取、分区、清洗、转换规则、数据刷新和清理规则

  • 概括算法

    包括维度算法、粒度、聚合和概括等

(3) 数据立方体

数据立方体通过维度和事实帮助展现多维数据。维度作为保存记录的实体。

示例：

企业想跟踪关于时间、商品和位置的数据。

2D表(只有时间和商品)

data_cube2d

3D表(添加位置)

data_cube3d

数据立方体展示：

data_cube3d1

(4) 数据集市

限制在特定主题的数据仓库子集。

data_mart

注意：

  • 实现周期短，如按周
  • 部门定制，容量较小

(5) 虚拟仓库

运营数据仓库的视图。易于构建，但需要运营仓库数据库额外空间。

4 交付过程

数据仓库需求随着业务变化而变化。瀑布模型中严谨且有序的模式难以适应。多数情况下，需求并没有被完全理解，而架构、设计和构建组件只有在收集和理解了全部需求后才能完成。

交付方法

交付方式是多种软件开发方法的协作。阶段划分减少了项目和交付的风险。

delivery_method

1) IT策略

数据仓库依赖于业务过程来产生收益，需要采购和保证项目资金。

2) 业务用例

用于评估数据仓库带来的业务收益。可以非量化，但需要明确。没有Business Case将导致可信性问题。

3) 原型和培训

在着手之前，组织需要体验数据分析并自我宣导数据仓库收益。可以通过原型来理解可行性和收益。

小范围原型系统需要满足：

  • 着重一个已定义的技术目标
  • 可行性展示后可丢弃
  • 着重最终数据内容的一个小子集
  • 时间周期不重要

早期版本要点：

  • 架构能够应变
  • 着重业务需求和技术蓝图
  • 最小化第一个构建阶段范围
  • 理解短期和中期数据仓库需求

4) 业务需求

此阶段需要确定：

  • 应用于数据的业务规则
  • 数据仓库中信息的逻辑模型
  • 即时需求的查询配置文件
  • 提供数据的源系统

5) 技术蓝图

交付满足长期需求的总体架构，以及实现短期必备的组件。需要确定：

  • 总体架构
  • 数据保留策略
  • 备份和恢复策略
  • 服务器和数据集市架构
  • 硬件和基础设施容量计划
  • 数据库设计组件

6) 建立版本

在此阶段，生产第一个交付产品，是数据仓库的最小组件。

7) 历史加载

加载历史记录数据。在此阶段，不会添加新实体，但可能创建物理表来存储新加数据。

8) ad hoc查询

配置工具用于操作数据仓库。工具可更新数据库查询。

建议不要在数据库大量改动时使用工具

9) 自动化

在此阶段，自动化操作管理过程。

  • 转换数据为适宜分析的格式
  • 监控查询配置文件和决定适宜的聚合方式，以维护系统性能
  • 提取并加载数据
  • 根据数据仓库中预先定义更新聚合
  • 备份、还原和归档数据

10) 扩展范围

新需求的扩展方式：

  • 加载额外的数据
  • 引入新的数据集市

注意：此阶段由于包含大量工作和复杂度，需要单独执行

11) 需求变更

需求不断变更，交付过程必须对此提供支持，并允许这些更改反映在系统中。因此，设计数据仓库应该围绕业务数据的使用，与现有查询的数据需求相反。

体系结构旨在更改和发展，这个过程作为伪程序开发过程运作。新需求不断反馈到开发活动中，产生部分可交付产品。部分可交付产品反馈给用户，经重新修改后确保整体系统满足业务需求并持续更新。

5 系统流程

如何在开源技术上构建数据仓库。

(1) 处理流

process_flow

构建数据仓库包含4个流程：

  • 提取、加载
  • 清洗、转换
  • 备份、归档
  • 管理查询并指向合适的数据来源

(2) 提取、加载

注意：加载数据前，外部数据需要重新组织结构。

1) 控制流程

包括决定加载时机和检查数据一致性。保证工具、逻辑模型和程序正确有序执行。

2) 提取操作初始化时间

数据提取时需要保证一致性。

3) 加载数据

提取后，数据被加载到临时数据存储中进行清洗和一致性检查。

注意：只有在所有数据都被加载后才进行一致性检查。

(3) 清洗、转换

清洗和转换步骤：

  • 清洗并加载到结构数据中
  • 数据分区
  • 聚合

1) 清洗并加载到结构数据中

清洗和加载有助于提高查询效率。主要是保持数据一致性，可以依据：

  • 与自身
  • 与来源系统
  • 与其他来源
  • 与数据仓库

转换还包括结构化数据，需要满足数据仓库的性能要求和控制操作代价。

2) 数据分区

将事实表划分为多个独立的分区，可以优化硬件性能，简化管理。

3) 聚合

依赖于大多数查询依赖的事实子集，可以加速查询。

(4) 备份、归档

备份用于预防数据丢失和软硬件故障。

归档从系统中移除数据，并以能够快速回复的数据格式保存。

(5) 查询管理过程

提供以下功能：

  • 管理查询
  • 加速执行
  • 引导查询到最高效的数据源
  • 高效利用所有数据源
  • 监控实际查询配置文件，用于决定采用的聚合方式。

通常普通数据加载时不执行。？

6 架构

讨论商业分析框架的设计和架构。

(1) 商业分析框架

具有数据仓库的优势：

  • 提高生产率，因为数据仓库能够快速高效收集信息
  • 提供一致性视图
  • 降低长时间跟踪趋势、模式的耗费

构建数据仓库的观点：

  • 自上而下：允许选择相关信息
  • 数据源：展示操作型系统信息
  • 数据仓库：包含事实表和维度表
  • 业务查询：用户视角

(2) 三层架构

dwh_architecture

  • 底层(数据库层)

    由数据库组成，负责从外部导入数据，并进行提取、清洗、加载和刷新等。

  • 中间层(OLAP层)

    由OLAP服务器组成，使用ROLAP(关系型数据库管理系统扩展，将多维数据操作转换为标准关系型操作)，或MOLAP（直接实现多维数据操作）。

  • 顶层（用户层）：包含查询、报表、分析和挖掘工具。

(3) 数据仓库模型

以下为数据仓库模型：虚拟仓库、数据集市和企业仓库

1) 虚拟仓库

构建在操作型数据仓库上，简单，但需要操作型数据库服务器上的额外空间

2) 数据集市

企业仓库的子集，通常是部门自定义的，生命周期与主题相关。

3) 企业仓库

数据仓库

(4) 加载管理

负责数据提取和加载过程。

1) 加载管理架构

load_manager

职责：

  • 从数据源提取数据
  • 快速加载到临时数据存储
  • 简单转换数据结构

2) 数据提取

由底层DBMS支持，并允许客户端生成并执行SQL。如ODBC和JDBC。

3) 快速加载

为了缩小数据加载时间窗口

转换操作影响效率

在转换和检查前，先加载进数据库更加高效

通常ODBC、JDBC无法应对海量数据

4) 简单转换

数据加载时通常需要进行简单转换。如筛除不需要的数据和转换为所需的数据类型。

(5) 仓库管理

用于管理仓库，包含三方软件、程序和脚本等。

1) 仓库管理结构

包含以下组成：

  • 控制进程
  • 存储过程
  • 备份、恢复工具
  • SQL脚本

warehouse_manager

2) 仓库管理操作

操作包括：

  • 数据检查：一致性和完整性
  • 辅助数据：创建索引、业务视图和分区视图等
  • 数据入库：转换和合并数据到数据仓库中
  • 数据备份：备份、归档
  • 性能监测：分析查询配置文件，调整索引和聚合方式

(6) 查询管理

负责调度查询任务到特定表中，为了提高效率

查询管理架构

架构包括：

  • 查询重定向
  • 存储过程
  • 查询管理工具
  • 查询调度

query_manager

(7) 细节信息

细节信息被综合后，归档到大容量存储中。细节信息被保持在星片模型（starflake schema）中，作为概括数据的补充，需要时再加载。

detailed_information

(8) 概括信息

是预定义聚合的数据，有仓库管理负责更新。随着查询配置文件的变化而不断变化。

  • 用于加速普通查询
  • 会增加操作型耗费
  • 数据加载时需要更新
  • 可能没有备份

7 OLAP

(1) 类型

  • Relational OLAP (ROLAP): 使用或者扩展RDBMS
  • Multidimensional OLAP (MOLAP)：使用基于数组的多维存储引擎。通常使用两种存储等级避免稀疏数据导致的空间利用率低。
  • Hybrid OLAP (HOLAP)：结合ROLAP和MOLAP。提供ROLAP的高弹性和MOLAP的快速计算。
  • Specialized SQL Servers：在只读环境中的星型或雪花模型上支持SQL查询。

(2) 操作

  • Roll-up
  • Drill-down
  • Slice and dice
  • Pivot (rotate)

1) 上卷

通过以下方式：

  • 概念粗化（基于高层概念汇总？）
  • 降维

rollup

原有数据是按照城市分组的，通过国家层次汇总，减少了位置的维度数量，细节更加模糊。

2) 下钻

下钻是上卷的反向操作。通过以下方式实现：

  • 概念细化
  • 升维

drill_down

原有数据是按照季度分组，通过细化时间为月度，增加了时间上的维度数量，细节更加明显。

3) 切片、切块

切片

在一个维度上选择值的子集作为标准，获取符合标准的数据。

slice

以上选取了第一季度的数据。

切块

在多个维度上选择值的子集作为标准，获取符合标准的数据。

dice

以上在位置、时间和产品维度选择子集。

4) 旋转

基于坐标轴旋转数据，为了提供另外的数据展示。

pivot

(3) OLAP vs OLTP

序号 数据仓库（OLAP） 操作型数据库（OLTP）
1 涉及信息的历史处理。 涉及日常处理。
2 OLAP系统由高管，经理和分析师等知识工作者使用。 职员，DBA或数据库专业人员使用OLTP系统。
3 在分析业务时很有用。 在经营业务中很有用。
4 它专注于信息输出。 它专注于数据输入。
5 基于星型模式，雪花模式和Schema and Fact Constellation Schema。 基于实体关系模型。
6 包含历史数据。 包含当前数据。
7 提供汇总和合并的数据。 提供原始和高度详细的数据。
8 提供数据的摘要和多维视图。 提供详细而平坦的数据关系视图。
9 人数或用户数以百计。 用户数以千计。
10 访问的记录数以百万计。 访问的记录数以十为单位。
11 数据库大小从100 GB到1 TB 数据库大小从100 MB到1 GB。
12 高度灵活。 提供高性能。

(4) ROLAP

ROLAP包括：

  • 聚合定位逻辑
  • 后端DBMS优化
  • 其他工具和服务

注意：

  • ROLAP是高度伸缩的
  • ROLAP工具在多个维度间分析大量数据
  • ROLAP工具存储和分析大量变化数据

1) 架构

组成：

  • 数据库
  • ROLAP服务器
  • 前端工具

rolap_architecture

2） 优点

  • 方便使用已有的DBMS
  • 高效存储，因为没有零事实？
  • 不使用预先计算的数据立方体
  • 能够适应DSS Server的micro-strategy

3) 缺点

  • 查询性能差
  • 技术架构限制了伸缩性

(5) MOLAP

  • 不论综合和计算等级，响应时间一致
  • 需要避免创建关系型数据库类存储分析数据的复杂性
  • 需要尽可能快的性能
  • 使用两次存储来处理密集和稀疏数据
  • 密集子立方体以数组结构识别和存储
  • 稀疏子立方体应用压缩技术

1) 架构

组成：

  • 数据库
  • MOLAP服务器
  • 前端工具

molap_architecture

2) 优点

  • 可对预先计算的综合数据快速索引
  • 帮助需要分析大量缺乏定义数据的用户连接到网络
  • 易用，尤其对没有经验的用户

3) 缺点

  • 无法包含详细数据
  • 稀疏数据的存储空间利用不足

4) MOLAP vs ROLAP

序号 MOLAP ROLAP
1 信息检索速度很快。 信息检索相对较慢。
2 使用稀疏数组存储数据集。 使用关系表。
3 MOLAP非常易于使用，因此最适合没有经验的用户。 ROLAP最适合经验丰富的用户。
4 为数据多维数据集维护一个单独的数据库。 它可能不需要数据仓库中可用的空间。
5 DBMS功能弱。 DBMS功能强大。

8 模式

模式是整个数据库的逻辑描述。包括所有类型所有记录的名称和描述，以及相关的数据项和集合。数据库只用实体关系模型，而数据仓库使用星型、雪花和事实星座模式。

(1) 星型

  • 每个维度只用一个表表示。
  • 每个表包含一系列的属性。
  • 事实表在模型中间，包含了到维度的键和一些属性。

注意：由于每个维度只有一张表，每个表都有一些属性。对于多条记录而言，某些属性会出现冗余。

start_schema

(2) 雪花

  • 与星型不同的是，维度表被规范化。分离易变和不变的属性，将维度表查分为多个个维度表，item和supplier。
  • item与supplier通过外键和主键连接。

注意：由于进行了规范化，减少了星型模型的数据冗余。

snowflake

(3) 事实星座

  • 事实星座（也叫，银河）具有多个事实表。
  • 事实表间共享维度表。

fact_constellation

(4) 模式定义

使用DMQL定义模式。

主要包括：立方体定义和维度定义

1
2
3
4
# 立方体定义
define cube < cube_name > [ < dimension-list > }: < measure_list >
# 维度定义                          
define dimension < dimension_name > as ( < attribute_or_dimension_list > )

星型模式：

1
2
3
4
5
6
7
8
define cube sales star [time, item, branch, location]:   
    	   
dollars sold = sum(sales in dollars), units sold = count(*)    	  

define dimension time as (time key, day, day of week, month, quarter, year)
define dimension item as (item key, item name, brand, type, supplier type)        	
define dimension branch as (branch key, branch name, branch type)              	
define dimension location as (location key, street, city, province or state, country)

雪花模式：

1
2
3
4
5
6
7
8
define cube sales snowflake [time, item, branch, location]:

dollars sold = sum(sales in dollars), units sold = count(*)

define dimension time as (time key, day, day of week, month, quarter, year)
define dimension item as (item key, item name, brand, type, supplier (supplier key, supplier type))
define dimension branch as (branch key, branch name, branch type)
define dimension location as (location key, street, city (city key, city, province or state, country))

事实星座模式：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
define cube sales [time, item, branch, location]:

dollars sold = sum(sales in dollars), units sold = count(*)

define dimension time as (time key, day, day of week, month, quarter, year)
define dimension item as (item key, item name, brand, type, supplier type)
define dimension branch as (branch key, branch name, branch type)
define dimension location as (location key, street, city, province or state,country)
define cube shipping [time, item, shipper, from location, to location]:

dollars cost = sum(cost in dollars), units shipped = count(*)

define dimension time as time in cube sales
define dimension item as item in cube sales
define dimension shipper as (shipper key, shipper name, location as location in cube sales, shipper type)
define dimension from location as location in cube sales
define dimension to location as location in cube sales

9 分区策略

(1) 作用

由于数据量巨大，分区有助于简化管理、帮助备份恢复，以及增强查询性能等。

(2) 水平分区

1) 按时间

1’ 均分

根据业务情况，按照时间段均分为多个分区。

2‘ 非均分

按照访问频率，分为多个不同长度的时间段。

注意：

  • 细节数据需要线上可用
  • 物理表尽量小，以减少操作代价
  • 适合近期记录需要下钻，长期记录需要挖掘的场景
  • 不适合分区配置经常变的场景

partition

2) 按其他维度

需要保证依据的维度不会变动，否则将导致重新分区

3) 按容量

需要设置阈值，超出则新建分区。

注意：

  • 难以管理
  • 需要元数据标识所在的分区

4) 拆分维度

当一个维度过大时，将影响响应时间。需要进行拆分

5) 循环分区

当需要新分区时，老分区被归档。允许使用元数据引用分区。

思考：循环分区是一种技术，而不是分区标准？

(3) 垂直分区

需要确保不会在分区间连接。

1) 规范化

根据属性将关系将行进行分组。

image-20200623224711981

2) 行拆分

倾向于分区间一对一的映射，为了减少单个表大小。

注意：根据业务情况，选择合适的分区关键字。

10 元数据概念

(1) 定义

关于数据的数据。是一种指向细节数据的已综合数据。

定义了数据仓库中数据的名称和定义、时间戳、来源和处理过程等信息。

(2) 分类

  • 业务元数据

    包括数据归属、业务定义和变更策略等

  • 技术元数据

    包含数据库名称、表名称和容量、数据类型和合法值、主键、外键和索引。

  • 操作元数据

    数据当前状态（活跃、归档或清除）和数据血缘（来源和操作）

metadata_categories

(3) 角色

  • 目录作用
  • 定位数据仓库中数据
  • 数据血缘追溯
  • 用于数据提取、清洗、加载、转换、查询和报表过程。

metadata_role

(4) 元数据仓库

包含：

  • 元数据

  • 操作型环境与数据仓库映射

    来源数据库和内容，数据提取、分区、清洗、转换、刷新和清除规则

  • 综合算法

    维度算法、粒度数据、聚合和综合

(5) 元数据管理挑战

  • 大型组织元数据分散
  • 可能以文本或多媒体形式展现，需要正确定义
  • 行业内没有标准
  • 没有简单合适的传递方法

11 数据集市

(1) 目的

  • 应用不同的访问控制策略
  • 加速查询，因为避免了全部扫描
  • 分离到不同硬件平台
  • 重新组织数据，以适配用户访问工具

注意：由于划分数据集市操作代价高，需要确保收益大于损耗。

(2) 高效划分数据集市

1) 职能划分

确定是否具有自然的职能部门，并确定部门间是都相互分离。需要根据业务收益和技术可行性决定。

考虑因素：

  • 部门是否会变化
  • 职能是否会转移
  • 是否可以部门间协同

2) 访问工具

需要支持要求中间数据结构的访问工具。这种中间数据结构在数据仓库控制之外，需要定期填充和更新。

注意：为了保证所有工具间的数据一致性，不应从数据仓库填充数据，而是每个工具具有自己的数据集市。

3) 访问控制

应该具有隐私规则。

(3) 设计数据集市

数据集市应该是数据仓库中一个小型的星片模式（starflake）。雪花模式？

designing_datamart

(4) 数据集市耗费

  • 软硬件

    数据冗余导致。

  • 网络

    分布式数据集市数据加载导致。

  • 时间窗口限制

    程度取决于转换复杂度和传输数据量。

12 系统管理

(1) 配置

  • 因软硬件平台而异
  • 单一的用户接口
  • 控制系统的方方面面
  • 最重要的是IO配置

(2) 调度

  • 在集群或大规模并行处理内工作
  • 处理时区差异
  • 处理作业失败与重试
  • 处理多个查询
  • 处理作业优先级
  • 队列开关
  • 日志
  • 日常和临时查询
  • 日常报表需求
  • 数据加载、处理和转换
  • 索引创建
  • 恢复
  • 聚合

(3) 事件

自动处理预先定义的事件。

事件是预先定义的，由用户或系统产生的动作。

以下为常见的事件：

  • 硬件

    硬件失效、CPU超载

  • 磁盘

    缓存超出上限、内存交换频繁、临时空间超出上限

  • 进程

    进程崩溃或返回错误

  • 数据库

    序列化点的内部争夺、表容量达到最大、

(4) 数据库

image-20200626223436269

(5) 恢复

  • 了解何时何处数据被备份
  • 有客户端工具
  • 能感知数据库，以便备份

13 过程管理

负责数据仓库数据流的进出，分为加载、数据仓库和查询管理。

(1) 加载

主要功能：

  • 从源系统提取
  • 快速加载到临时存储
  • 简单转换

load_manager

(2) 仓库

主要包括：

  • 控制进程
  • 存储流程
  • 备份、恢复
  • SQL脚本

warehouse_manager

功能包括：

  • 分析数据以执行一致性和参照完整性检查。
  • 根据基础数据创建索引，业务视图，分区视图。
  • 生成新的聚合并更新现有的聚合。
  • 生成规范化。
  • 将临时存储的源数据转换并合并到已发布的数据仓库中。
  • 备份数据仓库中的数据。
  • 存档已达到其使用期限的数据。

(3) 查询

负责调度查询到响应的表。

包括：

  • 查询重定向
  • 存储过程
  • 查询管理
  • 查询调度

query_manager

功能：

  • 返回用户理解的数据
  • 调度执行用户查询
  • 存储配置文件，用于判断索引和聚合是否合适

14 安全

(1) 安全需求

在设计数据仓库时，应该考虑以下问题：

  • 新的数据源是否需要新建或更改限制
  • 新的用户是否需要对已有数据进行受限访问

(2) 用户访问

  • 对数据分类
  • 对用户分类
    • 按照部门，适合独立的数据集市
    • 按照角色，适合共享数据

user_access_hierarchy

role_access_hierarchy

(3) 审计和网络需求

审计是安全的一部分，是一个高代价的行为。应该尽可能关闭。

审计分类：

  • 连接
  • 断开连接
  • 数据访问
  • 数据更改

网络需求需要考虑：

  • 是否传输前加密

    加密会增加硬件和时间消耗

    来自源系统加密的数据会增加已有系统的负担

  • 是否网络路由限制

(4) 数据转移

需要考虑：

  • 数据来源
  • 授权用户
  • 是否加密
  • 存储位置

(5) 文档

审计和安全需求需要文档记录。包括：

  • 数据分类
  • 用户分类
  • 网络需求
  • 数据转移和存储需求
  • 审计行为

(6) 安全影响

  • 应用开发

    增加合法性检查代码

  • 数据库设计

    增加视图、表、备份和恢复工作

  • 测试

    增加待测试的功能及时间

15 备份

(1) 术语

  • 完全备份

    一次性备份整个数据库

  • 部分备份

    通常采用循环方式逐步备份

  • 冷备份

    备份时停止工作

  • 热备份

  • 在线备份

    类似于热备份

(2) 硬件备份

备份恢复的速率取决于硬件。

需要考虑：

  • 可靠性
  • 单位存储费用
  • 弹性
  • 升级费用
  • 使用寿命

(3) 软件备份

考虑因素：

  • 弹性
  • 运行模式（Client/Server或ServerOnly）
  • 部署平台（含是否支持集群或大规模并行处理MPP）
  • 并行程度
  • 数据库感知
  • 数据访问是否方便

16 调优

(1) 难点

数据仓库是动态的。业务希求、用户和配置、用户查询和数据加载都是动态变化的。

需要对数据仓库有完全的认识。

(2) 性能评估

项目：

  • 平均查询响应时间
  • 扫描速率
  • 每日查询时间
  • 过程内存占用
  • IO吞吐速率

(3) 数据加载优化

数据加载是快速处理的关键。

常见方法：

  • SQL层插入。

    需要执行常规检查和约束，耗时且占用CPU。

  • 数据放入预先格式化块中，随后写入数据库

    避免常规检查和约束，但只能以块单位操作，浪费空间

  • 数据加载到已包含数据的表，同时维护索引

    适合已经加载有大量数据的场景

  • 数据加载到已包含数据的表，删除索引，加载完成后重新创建

    适合索引重建简便的场景

(4) 一致性检查

一致性检查需要大量处理资源。

  • 限制一致性检查
  • 应用到数据源系统中，避免因数据加载导致性能降级

(5) 查询优化

1) 固定查询

包括日常报表和普通聚合等。

类似于关系型数据库优化，区别是数据量不同。

测试固定查询时保存最高效的执行计划，聚焦数据量变化和数据倾斜。

2) 临时查询

收集信息：

  • 用户数量
  • 临时查询频率、最大和平均数据量
  • 是否有下钻操作
  • 每日用户运行时间
  • 日常使用高峰时间和查询数量

注意：

  • 跟踪用户配置和识别日常查询
  • 根据信息变更数据库和索引

17 测试

(1) 测试级别

  • 单元测试

    分别测试每个组件、模型，如过程、程序、脚本等

    由开发者执行

  • 集成测试

    测试多个输入下组件协作能力

  • 系统测试

    测试整个数据仓库系统是否运行正常

    由测试团队执行

    在制定测试计划前，通常尽可能最小化系统测试

(2) 测试

  • 时间评估

    为了预防意料外和人为原因，建议设置为两倍测试时间。

  • 备份恢复测试

    硬件或实例失效、数据文件或恢复文件丢失等

  • 操作环境测试

    • 安全

      需要单独的文档

    • 调度

    • 磁盘配置

      用于检测瓶颈

    • 管理工具

  • 数据库测试

    • 管理和监控工具
    • 数据库特性，如并行处理等
    • 性能测试

  • 应用测试

    • 管理
    • 功能
    • 长时间运行
    • 定时任务

(3) 测试逻辑

  • 调度
  • 管理
  • 日常流程
  • 备份恢复
  • 长时间运行
  • 性能
  • 弹性

18 问答

  • 什么是虚拟仓库

    数据仓库上的视图。

    The view over an operational data warehouse is known as virtual warehouse.

  • 数据仓库交付流程

    IT策略、培训、业务案例分析、技术蓝图、构建版本、历史数据加载、临时查询、变更需求、自动化和扩展范围。

  • 多维OLAP比关系型OLAP快

  • Data Mining Query Language (DMQL)用于模式定义

参考资料

Data Warehousing - Overview