深刻理解数据仓库

欢迎关注鄙人公众号,技术干货随时看!
深刻理解数据仓库_第1张图片

鄙人的新书,欢迎订阅!

《elasticsearch7完全开发指南》
https://wenku.baidu.com/view/8ff2ce94591b6bd97f192279168884868762b8e7

《kibana权威指南》
https://wenku.baidu.com/view/24cfee1ce43a580216fc700abb68a98270feac21

什么是数据仓库?

业内普遍接受的定义:
  数据仓库之父比尔·恩门(Bill Inmon)在1991年出版的“Building the Data Warehouse”(《建立数据仓库》)一书中所提出的定义被广泛接受——数据仓库(Data Warehouse)是一个面向主题的(Subject Oriented)、集成的(Integrated)、相对稳定的(Non-Volatile)、反映历史变化(Time Variant)的数据集合,用于支持管理决策(Decision Making Support)。

数据仓库的特征

  1. 数据仓库是面向主题的;操作型数据库的数据组织面向事务处理任务,而数据仓库中的数据是按照一定的主题域进行组织。主题是指用户使用数据仓库进行决策时所关心的重点方面,一个主题通常与多个操作型信息系统相关。
  2. 数据仓库是集成的,数据仓库的数据有来自于分散的操作型数据,将所需数据从原来的数据中抽取出来,进行加工与集成,统一与综合之后才能进入数据仓库。
  3. 数据仓库是不可实时更新的,数据仓库主要是为决策分析提供数据,所涉及的操作主要是数据的查询。
  4. 数据仓库是随时间而变化的,传统的关系数据库系统比较适合处理格式化的数据,能够较好的满足商业商务处理的需求。稳定的数据以只读格式保存,且不随时间改变。
  5. 汇总的。操作性数据映射成决策可用的格式。
  6. 大容量。时间序列数据集合通常都非常大。
  7. 非规范化的。Dw数据可以是而且经常是冗余的。
  8. 元数据。将描述数据的数据保存起来。
  9. 数据源。数据来自内部的和外部的非集成操作系统。

什么是数据仓库?我的理解

  数据仓库就是数据的仓库!

与建筑行业对比,深刻理解数据仓库相关概念

团队构成及其作用
深刻理解数据仓库_第2张图片
使用方与建设方的对比
深刻理解数据仓库_第3张图片
建筑设计师和模型设计师对比
深刻理解数据仓库_第4张图片
搬砖工和ETL工程师对比
深刻理解数据仓库_第5张图片
室内装修工和报表工程师对比
深刻理解数据仓库_第6张图片

与建筑行业对比,释疑数据仓库建设和管理中的疑惑

模型设计的疑惑
问题:建设数据仓库能不能没有模型设计?
联想:造一栋大厦能不能没有建筑设计?
答案:NO!

报表考核的疑惑
问题:能不能简单地以完成报表的数量考核报表开发的工作?
联想:能不能简单地以完成装修的房间数量来考核室内装修师的工作?
答案:NO!

数据质量的疑惑
问题:数据仓库部门该不该向应用系统反映源数据质量问题?
联想:建筑施工方该不该向砖头厂反映砖头质量问题?
答案:YES!

为什么数据仓库一定要有建模?

  目前国内数据仓库建设的两条路:

  1. 需求驱动
  2. 设计驱动

从数据准确性的角度考虑

需求驱动
深刻理解数据仓库_第7张图片
设计驱动
深刻理解数据仓库_第8张图片

从工作量角度考虑
深刻理解数据仓库_第9张图片
需求驱动和设计驱动对比
深刻理解数据仓库_第10张图片

数据仓库怎么建模

考虑的因素

  1. 了解各部门业务
  2. 探查多个源数据
  3. 将通过筛查的源数据导入数据登台层( Operational Data Store,ODS)
  4. 以业务为驱动,按范式规范,在数据仓库层(Enterprise DataWarehouse,EDW)依次进行概念建模、逻辑建模、物理建模
  5. 以需求为驱动,在数据集市层(Department DataWarehouse,DDW)依次进行概念建模、逻辑建模、物理建模
  6. 根据前端报表显示效率,酌情考虑是否需要报表应用层(Report Application Layer, RAL)

数据仓库架构
在这里插入图片描述
ODS层建模
深刻理解数据仓库_第11张图片
EDW层建模
深刻理解数据仓库_第12张图片
DDW层建模
深刻理解数据仓库_第13张图片
星型和雪花型结构
深刻理解数据仓库_第14张图片

国内数据仓库常见的失败原因

  1. 不重视数据仓库
  2. 不重视数据仓库模型设计
  3. 过度追求报表展现效果
  4. 简单粗暴的绩效考核体系
  5. 缺少文档和培训
  6. 数据仓库部门缺少话语权
  7. 尝试以技术解决一切问题
  8. 数据仓库模型设计得太复杂,和开发能力、维护能力脱节

常见的部分问题

行政协调方面

  1. 应用部门没有全面系统地向数据仓库部门说明数据结构
  2. 应用系统数据结构变动前后不通知数据仓库部门
  3. 各业务部门、应用部门没有设置统一的接口人

数据规范方面

  1. 数据字典信息滞后、不全
  2. 不符合范式要求
  3. 源数据中脏数据太多
  4. 无用/备用字段太多
  5. 字段类型不合理
  6. 维度成员不具备排他性
  7. 字段杂用

应用系统间标准方面

  1. 各业务部门、应用部门间的业务理解不统一
  2. 各源数据的信息分类编码标准、共享数据集标准不统一
  3. 各源数据间表、字段命名不统一
  4. 各源数据间字段类型不统一
  5. 各源数据间数据字典格式和存放路径不统一

笔者给出的经验性建议

  1. 增设数据仓库需求总控角色
  2. 增设数据仓库数据测试角色
  3. 增设数据标准团队
  4. 每个部门设置接口人

数据仓库需求总控职责

  1. 作为数据仓库团队对外接口人
  2. 跨部门、跨时间的需求采集和分析
  3. 将需求分成分析型需求、周期型需求、临时型需求、不合理需求,并分发给对应的同事以恰当的技术来实现
  4. 整理成需求文档以供数据仓库模型设计团队、数据标准团队使用

需求总控及分发
深刻理解数据仓库_第15张图片
数据流自动校对
深刻理解数据仓库_第16张图片
数据标准团队职责

  1. 管理业务解释和算法
  2. 管理各应用系统数据结构规范
  3. 管理信息分类编码标准、共享数据集标准
  4. 管理数据字典
  5. 管理数据交换格式标准、文档格式标准等

数据标准团队需具备的能力

  1. 了解各种业务
  2. 了解各应用系统源数据
  3. 精通数据结构规范

你可能感兴趣的:(大数据,系统架构,数据仓库,数据中心,大数据,商业智能,数据建模)