第五章 数据仓库和技术

[TOC]

第五章 数据仓库和技术

5.0 概述

5.1 管理大量数据(的技术)

• 一句话，要同时满足容量和效率

5.2 管理多种介质(的技术)

• 一句话，由于数据仓库的数据量限制和数据访问率不同，所以数据仓库的数据应该存储在多种不同介质上

5.3 索引和监控数据(的技术)

• 一句话，数据仓库中的数据必须方便、有效的建立索引，否则就是失败
• 一句话，必须对仓库的数据进行方便、有效的监控，否则就是失败

5.4 多种技术的接口(的技术)

graph LR
A[操作型环境和ODS] --> |导入|B(数据仓库)
B --> C{导出}
C --> D[数据集市]
C --> E[DSS应用]
C --> F[探查和数据挖掘]
C --> G[备用存储]

• 一句话，导入和导出必须流畅且容易进行，否则失败

5.5 程序员/设计者对数据存放位置的控制

• 一句话，因费用等原因，数据的存放位置会经常改动

5.6 数据的并行存储和管理

• 一句话，并行存储和管理，提高性能，且容量没限制（技术上）

元数据管理（业务元数据，技术元数据）
报表工具、业务智能工具、ODS环境、ETL 等都要有元数据

• 表结构
• 表属性
• 源数据
• 源数据到仓库的映射
• 数据模型说明
• 抽取日志
• 访问数据的公用例行程序
• 数据的定义/描述
• 数据单元之间的关系

5.7 语言接口

一句话，只有程序员使用SQL，其他人要使用比SQL更简单的语言（那是什么呢？没说！！！）

5.8 数据的有效装载

单条载入：一次载入一条
批量载入：
并行装载：
缓冲处理

5.9 有效利用索引

高效索引访问技术

• 用位图
• 用多级索引
• 索引装入内存
• 压缩索引
• 创建选择索引和范围索引

5.10 数据压缩

• 数据应总是被压缩存储

5.11 符合主键

5.12 变长数据

5.13 加锁管理

5.14 只涉及索引的处理

5.15 快速恢复

一句话，数据需要从非直接存储快速恢复成仓库的表

5.16 其他的技术特征（不需要的技术）

• 事务完整性
• 高速缓存
• 行/页级的锁定
• 参照完整性
• 数据视图
• 部分块载入

5.17 DBMS类型和数据仓库

• DBMS和DW最重要的区别就是数据的更新
• 对基本数据的管理不同
• 对索引的限制

5.18 改变DBMS技术

--

5.19 多维DBMS和数据仓库（跟Kimball不太一样）

数仓	多维
大量数据	少一个数量级
适合少了灵活访问	适合大量非预知访问
很长时间范围的数据	短时间范围的数据
受限访问	自由访问
与多维互补	与仓库互补

5.20 在多种存储介质上构建数据仓库

• 一句话，高效环境和低效环境都是仓库的一部分

5.21 数据仓库环境中的元数据角色

5.22 上下文和内容

5.23 刷新数据仓库

• 第一种方式是直接读取源库（1影响业务库，2重复数据）
• 第二种方式是数据复制（有额外IO）
• 第三种方式是变化数据捕获（CDC，推荐使用）
  PS：总感觉跟之前讲的数据更新算一个事

5.24 测试问题

• 一句话，很多情况仓库不需要测试环境（OMG）

5.25 小结

• 再次看到跟多维相关的内容
• 再次感觉Inmon 跟 Kimball 的观点很相似
• 都是要求建立一个统一的数仓，然后把数仓作为OLAP的基础或补充
• 不同的地方时 Inmon 要求数仓是 规范化的（不一定是3NF哦），二Kimball要求是星型模型
• 因 Inmon 也没有要求一定是要3NF的，而且他还提出了很多优化，比如表合并，冗余，反规范化等，这些优化怎么看都跟维度建模很相似
• 他们最大的不同感觉应该是 Inmon 要求先有个企业级的ERD模型，这样就相当于有个总体的设计图，然后按照设计图的分块做，而Kimball貌似没有这样要求，而是建议按照业务过程进行分步设计，
• 然而Inmon 任务直接分步设计会出现板块不能拼接的情况，就是冲突、或者遗漏吧
• 哎，我觉得两种都还好，先整体设计固然好，有设计图了，干活就有战略指导了，但整体设计的工作较复杂不容易落地，分步设计就轻松些了，只要分步设计的冲突和遗漏影响不大还是可以使用的