数据仓库的架构与设计

标签: 数据仓库 架构 设计 | 发表时间:2017-04-01 10:44 | 作者:Trigl
出处:http://blog.csdn.net

公司之前的数据都是直接传到Hdfs上进行操作,没有一个数据仓库,趁着最近空出几台服务器,搭了个简陋的数据仓库,这里记录一下数据仓库的一些知识。涉及的主要内容有:

  1. 什么是数据仓库?
  2. 数据仓库的架构
  3. 数据仓库多维数据模型的设计

1. 什么是数据仓库

1.1 数据仓库的概念

官方定义

数据仓库是一个面向主题的、集成的、随时间变化的、但信息本身相对稳定的数据集合,用于对管理决策过程的支持。

这个定义的确官方,但是却指出了数据仓库的四个特点。

特点

面向主题:数据仓库都是基于某个明确主题,仅需要与该主题相关的数据,其他的无关细节数据将被排除掉
集成的:从不同的数据源采集数据到同一个数据源,此过程会有一些ETL操作
随时间变化:关键数据隐式或显式的基于时间变化
信息本身相对稳定:数据装入以后一般只进行查询操作,没有传统数据库的增删改操作

个人理解

数据仓库就是整合多个数据源的历史数据进行细粒度的、多维的分析,帮助高层管理者或者业务分析人员做出商业战略决策或商业报表。

1.2 数据仓库的用途

  • 整合公司所有业务数据,建立统一的数据中心
  • 产生业务报表,用于作出决策
  • 为网站运营提供运营上的数据支持
  • 可以作为各个业务的数据源,形成业务数据互相反馈的良性循环
  • 分析用户行为数据,通过数据挖掘来降低投入成本,提高投入效果
  • 开发数据产品,直接或间接地为公司盈利

1.3 数据库和数据仓库的区别

差异项 数据库 数据仓库
特征 操作处理 信息处理
面向 事务 分析
用户 DBA、开发 经理、主管、分析人员
功能 日常操作 长期信息需求、决策支持
DB设计 基于ER模型,面向应用 星形/雪花模型,面向主题
数据 当前的、最新的 历史的、跨时间维护
汇总 原始的、高度详细 汇总的、统一的
视图 详细、一般关系 汇总的、多维的
工作单元 短的、简单事务 复杂查询
访问 读/写 大多为读
关注 数据进入 信息输出
操作 主键索引操作 大量的磁盘扫描
用户数 数百到数亿 数百
DB规模 GB到TB >=TB
优先 高性能、高可用性 高灵活性
度量 事务吞吐量 查询吞吐量、响应时间

2. 数据仓库的架构

2.1 当前架构

当前我们的数据仓库架构很low,但是能实现基本功能,如下:
这里写图片描述

数据采集

数据采集层的任务就是把数据从各种数据源中采集和存储到数据存储上,期间有可能会做一些ETL操作。

数据源种类可以有多种:

  • 日志:所占份额最大,存储在备份服务器上
  • 业务数据库:如Mysql、Oracle
  • 来自HTTP/FTP的数据:合作伙伴提供的接口
  • 其他数据源:如Excel等需要手工录入的数据

数据存储与分析

HDFS是大数据环境下数据仓库/数据平台最完美的数据存储解决方案。

离线数据分析与计算,也就是对实时性要求不高的部分,Hive是不错的选择。

使用Hadoop框架自然而然也提供了MapReduce接口,如果真的很乐意开发Java,或者对SQL不熟,那么也可以使用MapReduce来做分析与计算。

Spark性能比MapReduce好很多,同时使用SparkSQL操作Hive。

数据共享

前面使用Hive、MR、Spark、SparkSQL分析和计算的结果,还是在HDFS上,但大多业务和应用不可能直接从HDFS上获取数据,那么就需要一个数据共享的地方,使得各业务和产品能方便的获取数据。
这里的数据共享,其实指的是前面数据分析与计算后的结果存放的地方,其实就是关系型数据库和NOSQL数据库。

数据应用

报表:报表所使用的数据,一般也是已经统计汇总好的,存放于数据共享层。

接口:接口的数据都是直接查询数据共享层即可得到。

即席查询:即席查询通常是现有的报表和数据共享层的数据并不能满足需求,需要从数据存储层直接查询。一般都是通过直接操作SQL得到。

2.2 理想架构

自己的架构这么低级不能误导了读者,所以给出主流公司会用到的一个架构图:
这里写图片描述

增加了以下内容:

数据采集:采用Flume收集日志,采用Sqoop将RDBMS以及NoSQL中的数据同步到HDFS上

消息系统:可以加入Kafka防止数据丢失

实时计算:实时计算使用Spark Streaming消费Kafka中收集的日志数据,实时计算结果大多保存在Redis中

机器学习:使用了Spark MLlib提供的机器学习算法

多维分析OLAP:使用Kylin作为OLAP引擎

数据可视化:提供可视化前端页面,方便运营等非开发人员直接查询

3. 数据仓库多维数据模型的设计

3.1 基本概念

主题(Subject)

主题就是指我们所要分析的具体方面。例如:某年某月某地区某机型某款App的安装情况。主题有两个元素:一是各个分析角度(维度),如时间位置;二是要分析的具体量度,该量度一般通过数值体现,如App安装量。

维(Dimension)

维是用于从不同角度描述事物特征的,一般维都会有多层(Level:级别),每个Level都会包含一些共有的或特有的属性(Attribute),可以用下图来展示下维的结构和组成:

这里写图片描述

以时间维为例,时间维一般会包含年、季、月、日这几个Level,每个Level一般都会有ID、NAME、DESCRIPTION这几个公共属性,这几个公共属性不仅适用于时间维,也同样表现在其它各种不同类型的维。

分层(Hierarchy)

OLAP需要基于有层级的自上而下的钻取,或者自下而上地聚合。所以我们一般会在维的基础上再次进行分层,维、分层、层级的关系如下图:

这里写图片描述

每一级之间可能是附属关系(如市属于省、省属于国家),也可能是顺序关系(如天周年),如下图所示:

这里写图片描述

这里写图片描述

量度

量度就是我们要分析的具体的技术指标,诸如年销售额之类。它们一般为数值型数据。我们或者将该数据汇总,或者将该数据取次数、独立次数或取最大最小值等,这样的数据称为量度。

粒度
数据的细分层度,例如按天分按小时分。

事实表和维表

事实表是用来记录分析的内容的全量信息的,包含了每个事件的具体要素,以及具体发生的事情。事实表中存储数字型ID以及度量信息。

维表则是对事实表中事件的要素的描述信息,就是你观察该事务的角度,是从哪个角度去观察这个内容的。

事实表和维表通过ID相关联,如图所示:

这里写图片描述

星形/雪花形/事实星座

这三者就是数据仓库多维数据模型建模的模式

上图所示就是一个标准的星形模型。

雪花形就是在维度下面又细分出维度,这样切分是为了使表结构更加规范化。雪花模式可以减少冗余,但是减少的那点空间和事实表的容量相比实在是微不足道,而且多个表联结操作会降低性能,所以一般不用雪花模式设计数据仓库。

事实星座模式就是星形模式的集合,包含星形模式,也就包含多个事实表。

企业级数据仓库/数据集市

企业级数据仓库:突出大而全,不论是细致数据和聚合数据它全都有,设计时使用事实星座模式

数据集市:可以看做是企业级数据仓库的一个子集,它是针对某一方面的数据设计的数据仓库,例如为公司的支付业务设计一个单独的数据集市。由于数据集市没有进行企业级的设计和规划,所以长期来看,它本身的集成将会极其复杂。其数据来源有两种,一种是直接从原生数据源得到,另一种是从企业数据仓库得到。设计时使用星形模型

3.2 数据仓库设计步骤

1、确定主题

主题与业务密切相关,所以设计数仓之前应当充分了解业务有哪些方面的需求,据此确定主题

2、确定量度

在确定了主题以后,我们将考虑要分析的技术指标,诸如年销售额之类。量度是要统计的指标,必须事先选
择恰当,基于不同的量度将直接产生不同的决策结果。

3、确定数据粒度

考虑到量度的聚合程度不同,我们将采用“最小粒度原则”,即将量度的粒度设置到最小。例如如果知道某些数据细分到天就好了,那么设置其粒度到天;但是如果不确定的话,就将粒度设置为最小,即毫秒级别的。

4、确定维度

设计各个维度的主键、层次、层级,尽量减少冗余。

5、创建事实表

事实表中将存在维度代理键和各量度,而不应该存在描述性信息,即符合“瘦高原则”,即要求事实表数据条数尽量多(粒度最小),而描述性信息尽量少。


Refer

http://lxw1234.com/

https://my.oschina.net/leejun2005/blog/188770

作者:Trigl 发表于2017/4/1 17:52:19 原文链接
阅读:2 评论:0 查看评论

相关 [数据仓库 架构 设计] 推荐:

数据仓库的架构与设计

- - CSDN博客推荐文章
公司之前的数据都是直接传到Hdfs上进行操作,没有一个数据仓库,趁着最近空出几台服务器,搭了个简陋的数据仓库,这里记录一下数据仓库的一些知识. 数据仓库多维数据模型的设计. 数据仓库是一个面向主题的、集成的、随时间变化的、但信息本身相对稳定的数据集合,用于对管理决策过程的支持. 这个定义的确官方,但是却指出了数据仓库的四个特点.

数据仓库的设计与开发

- - 数据库 - ITeye博客
     数据仓库系统的设计与开发. 1)       收集和分析业务需求.   用户需求,管理人员需求. 2)       建立数据模型和数据仓库的物理设计.   概念模型,逻辑模型,物理模型. 3)       定义数据源. 数据源面向应用,不是面向主题,而且数据源之间存在多个不一致的情况,所以必须在已有的系统中定义记录系统(内容正确,在多个数据源间起决定作用的操作型数据源).

oracle数据仓库设计指南

- - 数据库 - ITeye博客
ODS(Operational Data Store)是数据仓库体系结构中的一个可选部分,ODS具备数据仓库的部分特征和OLTP系统的部分特征,它是“面向主题的、集成的、当前或接近当前的、不断变化的”数据.     一般在带有ODS的系统体系结构中,ODS都设计为如下几个作用:. 1 )    在业务系统和数据仓库之间形成一个隔离层.

【漫谈数据仓库】 如何优雅地设计数据分层

- -
本文主要讲解数据仓库的一个重要环节:如何设计数据分层. 其它关于数据仓库的内容可参考之前的文章. 本文对数据分层的讨论适合下面一些场景,超过该范围场景or数据仓库经验丰富的大神就不必浪费时间看了. 数据建设刚起步,大部分的数据经过粗暴的数据接入后就直接对接业务. 数据建设发展到一定阶段,发现数据的使用杂乱无章,各种业务都是从原始数据直接计算而得.

数据仓库

- Ran - Linux@SOHU
翻译:马少兵、曾怀东、朱翊然、林业. 尽管服务器存储、处理能力得到有效的提高,以及服务器价格的降低,让人们能够负担起大量的服务器,但是商业软件应用和监控工具快速的增加,还是使得人们被大量的数据所困扰. 在数据仓库领域中的许多系统管理员、应用开发者,以及初级数据库管理员发现,他们正在处理“海量数据”-不管你准备与否-都会有好多不熟悉的术语,概念或工具.

漫谈数据仓库之拉链表(原理、设计以及在Hive中的实现)

- - IT瘾-bigdata
本文将会谈一谈在数据仓库中拉链表相关的内容,包括它的原理、设计、以及在我们大数据场景下的实现方式. 先分享一下拉链表的用途、什么是拉链表. 通过一些小的使用场景来对拉链表做近一步的阐释,以及拉链表和常用的切片表的区别. 举一个具体的应用场景,来设计并实现一份拉链表,最后并通过一些例子说明如何使用我们设计的这张表(因为现在Hive的大规模使用, 我们会以Hive场景下的设计为例).

数据仓库概念

- - 互联网 - ITeye博客
数据仓库:是一个数据库环境,它提供用户用于决策支持的当前和历史数据,这些数据在传统的数据库中不方便得到. 特点:面向主题,集成的,相对稳定的,反应历史变化的. 组成:数据仓库的数据库,数据抽取工具,元数据,访问工具,数据集市,数据仓库管理,信息发布系统. 数据挖掘:就是从大量数据中获取有效的,新颖的,潜在有用的,最终可理解的模式的过程.

大数据仓库-kudu

- - 数据库 - ITeye博客
数据仓库里面存储引擎是非常重要的,存储引擎的好坏,基本决定了整个数仓的基础. cloudera公司最近发布了一个kudu存储引擎. 按照cloudera的想法,kudu的出现是为了解决,hbase,parquet不能兼顾分析和更新的需求,所以需要一个新的存储引擎可以同时支持高吞吐的分析应用以及少量更新的应用.

[原]数据仓库元数据管理

- - oycn2010的专栏
元数据管理, 简单的做就是EXCEL结合版本管理等传统工具管理, 专业点就用专门的元数据管理工具;. 数据字典--> 数据知识库. 业务元数据,技术元数据,管理元数据. 参照:SAP元数据管理平台:按业务(角色)分类,按技术类型分类(特征,关键值,DSO,InfoCube),数据流程图. 按照传统的定义,元数据(Metadata)是关于数据的数据.

[原]数据仓库构建步骤

- - oycn2010的专栏
 即确定数据分析或前端展现的主题(例:某年某月某地区的啤酒销售情况). 主题要体现出某一方面的各分析角度(维度)和统计数值型数据(量度)之间的关系,确定主题时要综合考虑..  确定主题后,需要考虑分析的技术指标(例:年销售额等等). 它们一般为数据值型数据,其中有些度量值不可以汇总;些可以汇总起来,以便为分析者提供有用的信息.