数据仓库_数据仓库建模 - CSDN
数据仓库 订阅
数据仓库,英文名称为Data Warehouse,可简写为DW或DWH。数据仓库,是为企业所有级别的决策制定过程,提供所有类型数据支持的战略集合。它是单个数据存储,出于分析性报告和决策支持目的而创建。 为需要业务智能的企业,提供指导业务流程改进、监视时间、成本、质量以及控制。 [1] 展开全文
数据仓库,英文名称为Data Warehouse,可简写为DW或DWH。数据仓库,是为企业所有级别的决策制定过程,提供所有类型数据支持的战略集合。它是单个数据存储,出于分析性报告和决策支持目的而创建。 为需要业务智能的企业,提供指导业务流程改进、监视时间、成本、质量以及控制。 [1]
信息
缩    写
DW
提出者
比尔·恩门(Bill Inmon)
中文名
数据仓库
外文名
Data Warehouse
数据仓库发展历程
数据仓库是决策支持系统(dss)和联机分析应用数据源的结构化数据环境。数据仓库研究和解决从数据库中获取信息的问题。数据仓库的特征在于面向主题、集成性、稳定性和时变性。数据仓库 ,由数据仓库之父比尔·恩门(Bill Inmon)于1990年提出,主要功能仍是将组织透过资讯系统之联机事务处理(OLTP)经年累月所累积的大量资料,透过数据仓库理论所特有的资料储存架构,做有系统的分析整理,以利各种分析方法如联机分析处理(OLAP)、数据挖掘(Data Mining)之进行,并进而支持如决策支持系统(DSS)、主管资讯系统(EIS)之创建,帮助决策者能快速有效的自大量资料中,分析出有价值的资讯,以利决策拟定及快速回应外在环境变动,帮助建构商业智能(BI)。数据仓库之父比尔·恩门(Bill Inmon)在1991年出版的“Building the Data Warehouse”(《建立数据仓库》)一书中所提出的定义被广泛接受——数据仓库(Data Warehouse)是一个面向主题的(Subject Oriented)、集成的(Integrated)、相对稳定的(Non-Volatile)、反映历史变化(Time Variant)的数据集合,用于支持管理决策(Decision Making Support)。
收起全文
精华内容
参与话题
  • 采用阿里云ECS服务器作为数据平台,搭建高可用的、高可靠的Flume数据采集通道,运用阿里云DateHub构建中间缓冲队列并担任数据分发枢纽将数据推送至阿里自主研发的DataWorks对数据进行分层处理,采用MaxCompute作为...
  • 数据仓库基本知识

    万次阅读 多人点赞 2018-11-12 10:27:39
    数据仓库是什么 根据统计,每个企业的数据量每2~3年时间就会成倍增长,这些数据蕴含着巨大的商业价值,而企业所关注的通常只占在总数据量的2%~4%左右。 因此,企业仍然没有最大化地利用已存在的数据资源,以...
    
    

    数据仓库是什么

    根据统计,每个企业的数据量每2~3年时间就会成倍增长,这些数据蕴含着巨大的商业价值,而企业所关注的通常只占在总数据量的2%~4%左右。
    因此,企业仍然没有最大化地利用已存在的数据资源,以至于浪费了更多的时间和资金,也失去制定关键商业决策的最佳契机。
    于是,企业如何通过各种技术手段,并把数据转换为信息、知识避免各种无知状态和瞎猜行为,已经成了提高其核心竞争力的主要瓶颈。
    数据仓库是把数据转换为信息、知识的一种主要技术手段。
    数据仓库是面向分析的存储系统
    数据仓库,是为企业所有级别的决策制定过程,提供所有类型数据支持的数据集合。
    这些数据集合出于分析性报告和决策支持目的而创建,用于支持研究管理决策。
    一是为调查研究作数据支撑,二是为实现需要业务智能的企业,提供指导业务流程改进、监视时间、成本、量以及控制。
    数据仓库是一个过程而不是一个项目;数据仓库是一个环境,而不是一件产品。
    数据仓库提供用户用于决策支持的当前和历史数据,这些数据在传统的操作型数据库中很难或不能得到。

    [903014-20160322154102745-1726255952.jpg]


    目标和DEMO

    将联机事务处理(OLTP)经年累月所累积的大量数据资料,透过数据仓库理论所特有的资料储存架构,做数据的清理保存,提供给各种分析方法使用,如联机分析处理(OLAP)、数据挖掘(Data Mining),并进而创建 决策支持系统(DSS)、主管资讯系统(EIS)、研究支持系统,帮助决策者研究者快速有效的自大量资料中,分析出有价值的资讯,能够快速回应外在环境变动,帮助建构商业智能(BI),挖掘内部数据价值,产生更多高质量的内容。

    数据仓库给组织带来了巨大的变化。数据仓库的建立给企业带来了一些新的工作流程,其他的流程也因此而改变。

    数据仓库为企业带来了一些“以数据为基础的知识”,它们主要应用于对市场战略的评价,和为企业发现新的市场商机,同时,也用来控制库存、检查生产方法和定义客户群。

    通过数据仓库,可以建立企业的数据模型,这对于企业的生产与销售、成本控制与收支分配有着重要的意义,极大的节约了企业的成本,提高了经济效益,同时,用数据仓库可以分析企业人力资源与基础数据之间的关系,可以用于返回分析,保障人力资源的最大化利用,亦可以进行人力资源绩效评估,使得企业管理更加科学合理。数据仓库将企业的数据按照特定的方式组织,从而产生新的商业知识,并为企业的运作带来新的视角。

    国外知名的Garnter关于数据集市产品报告中,位于第一象限的敏捷商业智能产品有QlikView, Tableau和SpotView,都是全内存计算的数据集市产品,在大数据方面对传统商业智能产品巨头形成了挑战。

    国内BI产品起步较晚,知名的敏捷型商业智能产品有PowerBI, 永洪科技的Z-Suite,SmartBI,FineBI商业智能软件等,其中永洪科技的Z-Data Mart是一款热内存计算的数据集市产品。

    国内的德昂信息也是一家数据集市产品的系统集成商。

    [v2-da8260eae1a66096e3b61cd598b06596_hd.png]

    [v2-da8260eae1a66096e3b61cd598b06596_hd.png]

    阿里数加
    https://data.aliyun.com/


    数据仓库的特点

    数据仓库是一个面向主题的(Subject Oriented)、集成的(Integrate)、相对稳定的(Non-Volatile)、反映历史变化(Time Variant)的数据集合

    1、面向主题

    操作型数据库的数据组织面向事务处理任务,各个业务系统之间各自分离,而数据仓库中的数据是按照一定的主题域进行组织的。

    2、集成的

    数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的,必须消除源数据中的不一致性,以保证数据仓库内的信息是关于整个企业的一致的全局信息。

    3、相对稳定的

    数据仓库的数据主要供企业决策分析之用,所涉及的数据操作主要是数据查询,一旦某个数据进入数据仓库以后,一般情况下将被长期保留,也就是数据仓库中一般有大量的查询操作,但修改和删除操作很少,通常只需要定期的加载、刷新。

    4、反映历史变化

    数据仓库中的数据通常包含历史信息,系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到目前的各个阶段的信息,通过这些信息,可以对企业的发展历程和未来趋势做出定量分析和预测。

    5、效率足够高
    数据仓库的分析数据一般分为日、周、月、季、年等,可以看出,日为周期的数据要求的效率最高,要求24小时甚至12小时内,客户能看到昨天的数据分析。由于有的企业每日的数据量很大,设计不好的数据仓库经常会出问题,延迟1-3日才能给出数据,显然不行的。


    数据仓库技术

    数据仓库技术是为了有效的把操作形数据集成到统一的环境中以提供决策型数据访问的各种技术和模块的总称。所做的一切都是为了让用户更快更方便查询所需要的信息,提供决策支持。

    从功能结构划分,数据仓库系统至少应该包含数据获取(Data Acquisition)、数据存储(Data Storage)、数据访问(Data Access)三个关键部分。

    数据获取

    数据源

    数据源是数据仓库系统的基础,是整个系统的数据源泉。通常包括企业内部信息和外部信息。内部信息包括存放于RDBMS中的各种业务处理数据和各类文档数据。外部信息包括各类法律法规、市场信息和竞争对手的信息等等;

    元数据

    对业务数据本身及其运行环境的描述与定义的数据,称之为元数据(metadata)。 元数据是描述数据的数据。 元数据的典型表现为对象的描述,即对数据库、表、列、列属性(类型、格式、约束等)以及主键/外部键关联等等的描述。 特别是现行应用的异构性与分布性越来越普遍的情况下,统一的元数据就愈发重要了。“信息孤岛”曾经是很多企业对其应用现状的一种抱怨和概括,而合理的元数据则会有效地描绘出信息的关联性。 而元数据对于ETL的集中表现为:定义数据源的位置及数据源的属性、确定从源数据到目标数据的对应规则、确定相关的业务逻辑、在数据实际加载前的其他必要的准备工作,等等,它一般贯穿整个数据仓库项目,而ETL的所有过程必须最大化地参照元数据,这样才能快速实现ETL。

    数据转换工具

    1)数据转换工具要能从各种不同的数据源中读取数据。 2)支持平面文件、索引文件、和legacyDBMS。 3)能以不同类型数据源为输入整合数据。 4)具有规范的数据访问接口 5)最好具有从数据字典中读取数据的能力 6)工具生成的代码必须是在开发环境中可维护的 7)能只抽取满足指定条件的数据,和源数据的指定部分 8)能在抽取中进行数据类型转换和字符集转换 9)能在抽取的过程中计算生成衍生字段 10)能让数据仓库管理系统自动调用以定期进行数据抽取工作,或能将结果生成平面文件 11)必须对软件供应商的生命力和产品支持能力进行仔细评估 主要数据抽取工具供应商:Prismsolutions. Carleton'sPASSPORT. InformationBuildersInc.'s EDA/SQL. SASInstituteInc.

    数据清洗ETL

    ETL分别代表:提取extraction、转换transformation、加载load。

    其中提取过程表示操作型数据库搜集指定数据,转换过程表示将数据转化为指定格式并进行数据清洗保证数据质量,加载过程表示将转换过后满足指定格式的数据加载进数据仓库。

    数据仓库会周期不断地从源数据库提取清洗好了的数据,因此也被称为"目标系统";

    实现ETL,首先要实现ETL转换的过程。体现为以下几个方面:
    1、空值处理:可捕获字段空值,进行加载或替换为其他含义数据,并可根据字段空值实现分流加载到不同目标库。
    2、规范化数据格式:可实现字段格式约束定义,对于数据源中时间、数值、字符等数据,可自定义加载格式。
    3、拆分数据:依据业务需求对字段可进行分解。例,主叫号 861082585313-8148,可进行区域码和电话号码分解。
    4、验证数据正确性:可利用Lookup及拆分功能进行数据验证。例如,主叫号861082585313-8148,进行区域码和电话号码分解后,可利用Lookup返回主叫网关或交换机记载的主叫地区,进行数据验证。
    5、数据替换:对于因业务因素,可实现无效数据、缺失数据的替换。
    6、Lookup:查获丢失数据 Lookup实现子查询,并返回用其他手段获取的缺失字段,保证字段完整性。
    7、建立ETL过程的主外键约束:对无依赖性的非法数据,可替换或导出到错误数据文件中,保证主键唯一记录的加载。

    根据以往数据仓库项目的经验,在一个数据仓库项目中,ETL设计和实施的工作量一般要占总项目工作量的40%-60%,而且数据仓库项目一般会存在二次需求的问题,客户在项目的实施过程中或者使用过程中会提出新的业务需求,而任何前端业务模型的改变都会涉及到ETL设计,因此ETL工具的选择对于整个数据仓库项目的成功是非常重要的。

    选型

    ETL工具的典型代表有:Informatica powercenter、Datastage、Oracle OWB(oracle warehouse builder)、ODI、微软DTS、Beeload、Kettle、Talend 、DataSprider、Spark、等等……

    开源的工具有eclipse的etl插件:CloverETL和Octupus

    在购买现成的工具之外,还有自己从头开发ETL程序的。

    ETL工作看起来并不复杂,特别是在数据量小、没有什么转换逻辑的时候,自己开发似乎非常节省成本。的确,主流的ETL工具价格不菲,动辄几十万;而从头开发无非就是费点人力而已,可以控制。至于性能,人大多是相信自己的,认为自己开发出来的东西知根知底,至少这些程序可以完全由自己控制。

    就目前自主开发的ETL程序而言,有人用c语言编写,有人用存储过程,还有人用各种语言混杂开发,程序之间各自独立。这很危险,虽然能够让开发者过足编码的瘾,却根本不存在架构。

    有位银行的朋友,他们几年前上的数据仓库系统,就是集成商自己用c语言专门为他们的项目开发的。单从性能上看似乎还不赖,然而一两年下来,项目组成员风雨飘零,早已物是人非,只有那套程序还在那里;而且,按照国内目前的软件工程惯例,程序注释和文档是不全或者是不一致的,这样的程序已经对日常业务造成很大阻碍。最近,他们已经开始考虑使用ETL工具重新改造了。

    扩展阅读

    数据仓库项目应该如何选择ETL工具:ETL or E-LT? http://blog.csdn.net/mengdebin/article/details/41151533

    ETL构建企业级数据仓库五步法
    http://blog.csdn.net/xcbsdu/article/details/6637775

    数据存储

    数据集市(Data Marts)

    为了特定的应用目的或应用范围,而从数据仓库中独立出来的一部分数据,也可称为部门数据或主题数据(subjectarea)。在数据仓库的实施过程中往往可以从一个部门的数据集市着手,以后再用几个数据集市组成一个完整的数据仓库。需要注意的就是再实施不同的数据集市时,同一含义的字段定义一定要相容,这样再以后实施数据仓库时才不会造成大麻烦。

    数据仓库管理

    安全和特权管理;跟踪数据的更新;数据质量检查;管理和更新元数据;审计和报告数据仓库的使用和状态;删除数据;复制、分割和分发数据;备份和恢复;存储管理。

    选型

    在大数据时代,数据仓库的重要性更胜以往。Hadoop平台下的Hive,Spark平台下的Spark SQL都是各自生态圈内应用最热门的配套工具,而它们的本质就是开源分布式数据仓库。

    在国内最优秀的互联网公司里(如阿里、腾讯),很多数据引擎是架构在数据仓库之上的(如数据分析引擎、数据挖掘引擎、推荐引擎、可视化引擎等等)。不少员工认为,开发成本应更多集中在数据仓库层,不断加大数据建设的投入。因为一旦规范、标准、高性能的数据仓库建立好了,在之上进行数据分析、数据挖掘、跑推荐算法等都是轻松惬意的事情。
    反之如果业务数据没梳理好,各种脏乱数据会搞得人焦头烂额,苦不堪言。

    数据访问

    数据仓库通常需要提供具有直接访问数据仓库功能的前端应用,这些应用也被称为BI(商务智能)应用

    有数据查询和报表工具

    应用开发工具

    经理信息系统(EIS)工具

    联机分析处理(OLAP)工具

    数据仓库建设好以后,用户就可以编写SQL语句对其进行访问并对其中数据进行分析。但每次查询都要编写SQL语句的话,未免太麻烦,而且对维度建模数据进行分析的SQL代码套路比较固定。

    于是,便有了OLAP工具,它专用于维度建模数据的分析。而BI工具则是能够将OLAP的结果以图表的方式展现出来,它和OLAP通常出现在一起。(注:本文所指的OLAP工具均指代这两者。)

    这种情况下,OLAP不允许访问中心数据库。一方面中心数据库是采取规范化建模的,而OLAP只支持对维度建模数据的分析;另一方面规范化数据仓库的中心数据库本身就不允许上层开发人员访问。而在维度建模数据仓库中,OLAP/BI工具和数据仓库的关系则是这样的:

    在维度建模数据仓库中,OLAP不但可以从数据仓库中直接取数进行分析,还能对架构在其上的数据集市群做同样工作。

    数据挖掘工具。

    信息发布系统

    把数据仓库中的数据或其他相关的数据发送给不同的地点或用户。基于Web的信息发布系统是对付多用户访问的最有效方法。

    数据可视化选型

    你想知道的经典图表全在这
    https://zhuanlan.zhihu.com/p/24168144

    R语言
    http://www.cnblogs.com/muchen/p/5332359.html

    pentaho

    FineBI

    PowerBI
    http://www.cnblogs.com/muchen/p/5389960.html

    http://www.cnblogs.com/muchen/p/5391101.html

    深入浅出BI
    https://zhuanlan.zhihu.com/p/24573880

    [903014-20160328190120316-616433149.jpg]

    [903014-20160328185819613-1426949688.jpg]


    案例

    facebook的ppt上了解到的是他们在hive上做大数据量的分析,计算结果放到oracle上做BI展示和计算 hadoop MR or hive上ETL计算完的结果表,同步到oracle中,连接传统BI工具,呈现报表,阿里、腾讯、盛大都是这样的

    [v2-3e6958278b96043f5a2379778054deae_hd.png]


    与传统数据库的对比

    企业的数据处理大致分为两类:
    一类是操作型处理,也称为联机事务处理,它是针对具体业务在数据库联机的日常操作,通常对少数记录进行查询、修改。
    另一类是分析型处理,一般针对某些主题的历史数据进行分析,支持管理决策。

    数据库:传统的关系型数据库的主要应用,主要是基本的、日常的事务处理,例如银行交易。

    数据仓库:数据仓库系统的主要应用主要是OLAP(On-Line Analytical Processing),支持复杂的分析操作,侧重决策支持,并且提供直观易懂的查询结果。

    举个最常见的例子,拿电商行业来说好了。基本每家电商公司都会经历,从只需要业务数据库到要数据仓库的阶段。

    电商早期启动非常容易,入行门槛低。找个外包团队,做了一个可以下单的网页前端 + 几台服务器 + 一个MySQL,就能开门迎客了。这好比手工作坊时期。

    第二阶段,流量来了,客户和订单都多起来了,普通查询已经有压力了,这个时候就需要升级架构变成多台服务器和多个业务数据库(量大+分库分表),这个阶段的业务数字和指标还可以勉强从业务数据库里查询。初步进入工业化。

    第三个阶段,一般需要 3-5 年左右的时间,随着业务指数级的增长,数据量的会陡增,公司角色也开始多了起来,开始有了 CEO、CMO、CIO,大家需要面临的问题越来越复杂,越来越深入。

    高管们关心的问题,从最初非常粗放的:“昨天的收入是多少”、“上个月的 PV、UV 是多少”,逐渐演化到非常精细化和具体的用户的集群分析,特定用户在某种使用场景中,例如“20~30岁女性用户在过去五年的第一季度化妆品类商品的购买行为与公司进行的促销活动方案之间的关系”。这类非常具体,且能够对公司决策起到关键性作用的问题,基本很难从业务数据库从调取出来。

    原因在于:业务数据库中的数据结构是为了完成交易而设计的,不是为了而查询和分析的便利设计的。

    业务数据库大多是读写优化的,即又要读(查看商品信息),也要写(产生订单,完成支付)。

    因此对于大量数据的读(查询指标,一般是复杂的只读类型查询)是支持不足的。而怎么解决这个问题,此时我们就需要建立一个数据仓库了,公司也算开始进入信息化阶段了。

    数据仓库的作用在于:数据结构为了分析和查询的便利;只读优化的数据库,即不需要它写入速度多么快,只要做大量数据的复杂查询的速度足够快就行了。

    那么在这里前一种业务数据库(读写都优化)的是业务性数据库,后一种是分析性数据库,即数据仓库。

    最后总结一下:
    数据库 比较流行的有:MySQL, Oracle, SqlServer等
    数据仓库 比较流行的有:AWS Redshift, Greenplum, Hive等。
    这样把数据从业务性的数据库中提取、加工、导入分析性的数据库就是传统的 ETL 工作。

    数据仓库的方案建设的目的,是为前端查询和分析作为基础,由于有较大的冗余,所以需要的存储也较大。
    为了更好地为前端应用服务,数据仓库必须有如下几点优点,否则是失败的数据仓库方案。
    1.效率足够高。
    2.数据质量。
    3.扩展性。

    两类数据库的不同点:

    1.数据组成差别 - 数据时间范围差别

    一般来讲,操作型数据库只会存放90天以内的数据,而分析型数据库存放的则是数年内的数据。这点也是将操作型数据和分析型数据进行物理分离的主要原因。

    2.数据组成差别 - 数据细节层次差别

    操作型数据库存放的主要是细节数据,而分析型数据库中虽然既有细节数据,又有汇总数据,但对于用户来说,重点关注的是汇总数据部分。

    操作型数据库中自然也有汇总需求,但汇总数据本身不存储而只存储其生成公式。这是因为操作型数据是动态变化的,因此汇总数据会在每次查询时动态生成。

    而对于分析型数据库来说,因为汇总数据比较稳定不会发生改变,而且其计算量也比较大(因为时间跨度大),因此它的汇总数据可考虑事先计算好,以避免重复计算。

    3.数据组成差别 - 数据时间表示差别

    操作型数据通常反映的是现实世界的当前状态;而分析型数据库既有当前状态,还有过去各时刻的快照,分析型数据库的使用者可以综合所有快照对各个历史阶段进行统计分析。

    4.技术差别 - 查询数据总量和查询频度差别

    操作型查询的数据量少而频率多,分析型查询则反过来,数据量大而频率少。要想同时实现这两种情况的配置优化是不可能的,这也是将两类数据库物理分隔的原因之一。

    5.技术差别 - 数据更新差别

    操作型数据库允许用户进行增,删,改,查;分析型数据库用户则只能进行查询。

    6.技术差别 - 数据冗余差别

    数据的意义是什么?就是减少数据冗余,避免更新异常。而如5所述,分析型数据库中没有更新操作。因此,减少数据冗余也就没那么重要了。

    例如Hive是一种数据仓库,而数据仓库和分析型数据库的关系非常紧密。它只提供查询接口,不提供更新接口,这就使得消除冗余的诸多措施不需要被特别严格地执行了,可以保留冗余。

    7.功能差别 - 数据读者差别

    操作型数据库的使用者是业务环境内的各个角色,如用户,商家,进货商等;分析型数据库则只被少量用户用来做综合性决策。

    8.功能差别 - 数据定位差别

    这里说的定位,主要是指以何种目的组织起来。操作型数据库是为了支撑具体业务的,因此也被称为"面向应用型数据库";分析型数据库则是针对各特定业务主题域的分析任务创建的,因此也被称为"面向主题型数据库"。
    [4abe15bd7b3bcbc10f6b3846951b16d9_hd.jpg]


    怎么做

    1)收集和分析业务需求 确定指标

    基础数据的架构

    关键问题
    一般问题 (不完全是技术或文化,但很重要) 包括但不限于以下几点:
    业务用户想要执行什么样的分析?
    你现在收集的数据需要支持那些分析吗?
    数据在哪儿?
    数据清洗范围
    数据的清洁度如何?
    相似的数据有多个数据源吗?
    什么样的结构最适合核心数据仓库 (例如维度或关系型)?
    技术问题包括但不限于以下几点:
    在你的网络中要流通多少数据?它能处理吗?
    需要多少硬盘空间?
    硬盘存储需要多快?
    你会使用固态还是虚拟化的存储?

    2)建立数据模型和数据仓库的物理设计
    3)定义数据源
    4)选择数据仓库技术和平台
    5)从操作型数据库中抽取、净化、和转换数据到数据仓库–ETL依照模型进行初始加载、增量加载、缓慢增长维、慢速变化维、事实表加载等数据集成
    6)选择访问和报表工具
    7)选择数据库连接软件
    8)选择数据分析和数据展示软件
    9)更新数据仓库–并根据业务需求制定相应的加载策略、刷新策略、汇总策略、维护策略。

    较之数据库系统开发,数据仓库开发只多出ETL工程部分。然而这一部分极有可能是整个数据仓库开发流程中最为耗时耗资源的一个环节。
    因为该环节要整理各大业务系统中杂乱无章的数据并协调元数据上的差别,所以工作量很大。在很多公司都专门设有ETL工程师这样的岗位,大的公司甚至专门聘请ETL专家。

    [903014-20160322160747995-1497680833.jpg]

    展开全文
  • 数据仓库的架构与设计

    万次阅读 多人点赞 2017-04-01 18:03:33
    公司之前的数据都是直接传到Hdfs上进行操作,没有一个数据仓库,趁着最近空出几台服务器,搭了个简陋的数据仓库,这里记录一下数据仓库的一些知识。涉及的主要内容有: 什么是数据仓库数据仓库的架构 数据...

    公司之前的数据都是直接传到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

    展开全文
  • 大数据与数据仓库入门到精通

    千人学习 2019-10-14 13:04:25
    希望学习者最好从事过数据库相关工作,有一些 JAVA开发基础,或者有其他工作经验,想学习大数据及数据仓库的同学,对于没有工作经验,或者对开发,数据完全小白的同学,建议先了解相关知识再学习。 本课程的宗旨...
  • 数据仓库

    千次阅读 2018-08-28 16:10:00
    1. 什么是数据仓库 1.1 数据仓库的概念 官方定义 数据仓库是一个面向主题的、集成的、随时间变化的、但信息本身相对稳定的数据集合,用于对管理决策过程的支持。 这个定义的确官方,但是却指出了数据仓库的四个...

    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、创建事实表

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

    展开全文
  • 面试问题准备-数据仓库建模篇

    万次阅读 多人点赞 2019-04-06 23:26:51
    1. 什么叫数据仓库数据仓库的特点? (相信inmon的数据仓库概念的四个特点是最基本的吧,当然需要加上自己的理解) 首先,用于支持决策,面向分析型数据处理,它不同于企业现有的操作型数据库; 其次,对多个异构...

    1. 什么叫数据仓库?数据仓库的特点?
    (相信inmon的数据仓库概念的四个特点是最基本的吧,当然需要加上自己的理解)
    首先,用于支持决策,面向分析型数据处理,它不同于企业现有的操作型数据库;
    其次,对多个异构的数据源有效集成,集成后按照主题进行了重组,并包含历史数据,而且存放在数据仓库中的数据一般不再修改。
    数据仓库是一个面向主题的(Subject Oriented)、集成的(Integrate)、相对稳定的(Non-Volatile)、反映历史变化(Time Variant)的数据集合,它用于支持企业或组织的决策分析处理。
    2. 什么叫OLAP?用途是什么?
    (OLAP指多维数据库了,主要用于多维分析了;包括三种实现方式)
    3. 数据仓库和数据库有什么区别?
    (事务性数据库和决策支持数据库的区别,当然包括目标、用途、设计等等)
    (1)数据是面向事务处的,数据是由日常的业务产生的,常更新;数据仓库是面向主题的,数据来源于数据库或文件,经过一定的规则转换得到,用来分析的。
    (2)数据库一般是用来存储当前交易数据;数据仓库存储一般存储的是历史数据。
    (3)数据库的设计一般是符合三范式的,有最大的精确度和最小的冗余度,有利于数据的插入;数据仓库的设计一般是星型的,有利于查询。

    4. 数据仓库的基本架构是什么?
    (数据源,ETL,data stage,ODS,data warehouse,datamart,OLAP等等,可能为针对每一个结构进行发问啊)
    【1】.数据源->【2】.ETL ->【3】.数据仓库存储与管理->【4】.OLAP ->【5】.BI工具
    数据源:是数据仓库系统的数据源泉,通常包括企业各类信息,包括存放于RDBMS中的各种业务处理数据和各类文档数据;各类法律法规、市场信息和竞争对手的信息等等;
    数据的存储与管理:数据的存储和管理是整个数据仓库的核心,是关键。数据仓库的组织管理方式决定了它有别于传统数据库,同时也决定了其对外部数据的表现形式。从数据仓库的技术特点着手分析,来决定采用什么产品和技术来建立数据仓库,然后针对现有各业务系统的数据,进行抽取、清理,并有效集成,按照主题进行组织。数据仓库按照数据的覆盖范围可以分为企业级数据仓库和部门级数据仓库(通常称为数据集市)。
    OLAP服务器:对需要的数据进行有效集成,按多维模型予以组织,以便进行多角度、多层次的分析,并发现趋势。其具体实现可以分为:ROLAP(关系型在线分析处理)、MOLAP(多维在线分析处理)和HOLAP(混合型线上分析处理)。ROLAP基本数据和聚合数据均存放在RDBMS之中;MOLAP基本数据和聚合数据均存放于多维数据库中;HOLAP基本数据存放于RDBMS之中,聚合数据存放于多维数据库中。
    前端工具:主要包括各查询工具、数据分析工具、数据挖掘工具、种报表工具以及各种基于数据仓库或数据集市的应用开发工具。
    数据分析工具主要针对OLAP服务器。报表工具、数据挖掘工具主要针对数据仓库。
    5. 有哪几种模型设计方法?特点分别是什么?

    大千世界,表面看五彩缤纷,实质上,万物都遵循其自有的法则。数据仓库的建模方法同样也有很多种,每一种建模方法其实代表了哲学上的一个观点,代表了一种归纳,概括世界的一种方法。目前业界较为流行的数据仓库的建模方法非常多,这里主要介绍范式建模法,维度建模法,实体建模法等几种方法,每种方法其实从本质上讲就是从不同的角度看我们业务中的问题,不管从技术层面还是业务层面,其实代表的是哲学上的一种世界观。我们下面给大家详细介绍一下这些建模方法。

    范式建模法(Third Normal Form,3NF)
    范式建模法其实是我们在构建数据模型常用的一个方法,该方法的主要由 Inmon 所提倡,主要解决关系型数据库得数据存储,利用的一种技术层面上的方法。目前,我们在关系型数据库中的建模方法,大部分采用的是三范式建模法。
    范式是数据库逻辑模型设计的基本理论,一个关系模型可以从第一范式到第五范式进行无损分解,这个过程也可称为规范化。在数据仓库的模型设计中目前一般采用第三范式,它有着严格的数学定义。从其表达的含义来看,一个符合第三范式的关系必须具有以下三个条件 :
    每个属性值唯一,不具有多义性 ;
    每个非主属性必须完全依赖于整个主键,而非主键的一部分 ;
    每个非主属性不能依赖于其他关系中的属性,因为这样的话,这种属性应该归到其他关系中去。
    由于范式是基于整个关系型数据库的理论基础之上发展而来的,因此,本人在这里不多做介绍,有兴趣的读者可以通过阅读相应的材料来获得这方面的知识。

    根据 Inmon 的观点,数据仓库模型得建设方法和业务系统的企业数据模型类似。在业务系统中,企业数据模型决定了数据的来源,而企业数据模型也分为两个层次,即主题域模型和逻辑模型。同样,主题域模型可以看成是业务模型的概念模型,而逻辑模型则是域模型在关系型数据库上的实例。在这里插入图片描述
    图 5. 范式建模法

    从业务数据模型转向数据仓库模型时,同样也需要有数据仓库的域模型,即概念模型,同时也存在域模型的逻辑模型。这里,业务模型中的数据模型和数据仓库的模型稍微有一些不同。主要区别在于:
    数据仓库的域模型应该包含企业数据模型的域模型之间的关系,以及各主题域定义。数据仓库的域模型的概念应该比业务系统的主题域模型范围更加广。
    在数据仓库的逻辑模型需要从业务系统的数据模型中的逻辑模型中抽象实体,实体的属性,实体的子类,以及实体的关系等。
    以笔者的观点来看,Inmon 的范式建模法的最大优点就是从关系型数据库的角度出发,结合了业务系统的数据模型,能够比较方便的实现数据仓库的建模。但其缺点也是明显的,由于建模方法限定在关系型数据库之上,在某些时候反而限制了整个数据仓库模型的灵活性,性能等,特别是考虑到数据仓库的底层数据向数据集市的数据进行汇总时,需要进行一定的变通才能满足相应的需求。因此,笔者建议读者们在实际的使用中,参考使用这一建模方式。

    维度建模法
    维度建模法,Kimball 最先提出这一概念。其最简单的描述就是,按照事实表,维表来构建数据仓库,数据集市。这种方法的最被人广泛知晓的名字就是星型模式(Star-schema)。
    在这里插入图片描述
    图 6. 维度建模法

    上图的这个架构中是典型的星型架构。星型模式之所以广泛被使用,在于针对各个维作了大量的预处理,如按照维进行预先的统计、分类、排序等。通过这些预处理,能够极大的提升数据仓库的处理能力。特别是针对 3NF 的建模方法,星型模式在性能上占据明显的优势。

    雪花模型也是维度建模中的一种选择。雪花模型的维度表可以拥有其他维度表的,虽然这种模型相比星型模型更规范一些,但是由于这种模型不太容易理解,维护成本比较高,而且性能方面需要关联多层维表,性能也比星型模型要低。所以一般不是很常用。雪花模型如下图

    在这里插入图片描述

    同时,维度建模法的另外一个优点是,维度建模非常直观,紧紧围绕着业务模型,可以直观的反映出业务模型中的业务问题。不需要经过特别的抽象处理,即可以完成维度建模。这一点也是维度建模的优势。

    但是,维度建模法的缺点也是非常明显的,由于在构建星型模式之前需要进行大量的数据预处理,因此会导致大量的数据处理工作。而且,当业务发生变化,需要重新进行维度的定义时,往往需要重新进行维度数据的预处理。而在这些与处理过程中,往往会导致大量的数据冗余。

    另外一个维度建模法的缺点就是,如果只是依靠单纯的维度建模,不能保证数据来源的一致性和准确性,而且在数据仓库的底层,不是特别适用于维度建模的方法。

    因此以笔者的观点看,维度建模的领域主要适用与数据集市层,它的最大的作用其实是为了解决数据仓库建模中的性能问题。维度建模很难能够提供一个完整地描述真实业务实体之间的复杂关系的抽象方法。

    实体建模法
    实体建模法并不是数据仓库建模中常见的一个方法,它来源于哲学的一个流派。从哲学的意义上说,客观世界应该是可以细分的,客观世界应该可以分成由一个个实体,以及实体与实体之间的关系组成。那么我们在数据仓库的建模过程中完全可以引入这个抽象的方法,将整个业务也可以划分成一个个的实体,而每个实体之间的关系,以及针对这些关系的说明就是我们数据建模需要做的工作。

    虽然实体法粗看起来好像有一些抽象,其实理解起来很容易。即我们可以将任何一个业务过程划分成 3 个部分,实体,事件和说明,如下图所示:

    图 7. 实体建模法

    在这里插入图片描述

    上图表述的是一个抽象的含义,如果我们描述一个简单的事实:“小明开车去学校上学”。以这个业务事实为例,我们可以把“小明”,“学校”看成是一个实体,“上学”描述的是一个业务过程,我们在这里可以抽象为一个具体“事件”,而“开车去”则可以看成是事件“上学”的一个说明。

    从上面的举例我们可以了解,我们使用的抽象归纳方法其实很简单,任何业务可以看成 3 个部分:

    实体,主要指领域模型中特定的概念主体,指发生业务关系的对象。
    事件,主要指概念主体之间完成一次业务流程的过程,特指特定的业务过程。
    说明,主要是针对实体和事件的特殊说明。
    由于实体建模法,能够很轻松的实现业务模型的划分,因此,在业务建模阶段和领域概念建模阶段,实体建模法有着广泛的应用。从笔者的经验来看,再没有现成的行业模型的情况下,我们可以采用实体建模的方法,和客户一起理清整个业务的模型,进行领域概念模型的划分,抽象出具体的业务概念,结合客户的使用特点,完全可以创建出一个符合自己需要的数据仓库模型来。

    但是,实体建模法也有着自己先天的缺陷,由于实体说明法只是一种抽象客观世界的方法,因此,注定了该建模方法只能局限在业务建模和领域概念建模阶段。因此,到了逻辑建模阶段和物理建模阶段,则是范式建模和维度建模发挥长处的阶段。

    因此,笔者建议读者在创建自己的数据仓库模型的时候,可以参考使用上述的三种数据仓库得建模方法,在各个不同阶段采用不同的方法,从而能够保证整个数据仓库建模的质量。
    6. 模型设计的思路?业务需求驱动?数据驱动?
    构造数据仓库有两种方式:一是自上而下,一是自下而上。
    Bill Inmon先生推崇“自上而下”的方式,即一个企业建立唯一的数据中心,就像一个数据的仓库,其中数据是经过整合、经过清洗、去掉脏数据的、标准的,能够提供统一的视图。要建立这样的数据仓库,并不从它需要支持哪些应用入手,而是要从整个企业的环境入手,分析其中的概念,应该有什么样的数据,达成概念完成整;(会考虑到很全面的设计)
    Ralph Kimball先生推崇“自下而上”的方式,他认为建设数据仓库应该按照实际的应用需求,加载需要的数据,不需要的数据不要加载到数据仓库中。这种方式建设周期较短,客户能够很快看到结果。(针对客户的需求,需求要什么就做什么)
    二者都要达到同一个目标:企业级数据仓库。实际上在建设数据仓库的时候,一般都参照这两种方式结合使用没有硬性规定。
    7. 模型设计的步骤?
    构建企业级数据仓库五步法:
    一、 确定主题
    即确定数据分析或前端展现的主题(例:某年某月某地区的啤酒销售情况)。主题要体现出某一方面的各分析角度(维度)和统计数值型数据(量度)之间的关系,确定主题时要综合考虑.
    二、 确定量度
    确定主题后,需要考虑分析的技术指标(例:年销售额等等)。它们一般为数据值型数据,其中有些度量值不可以汇总;些可以汇总起来,以便为分析者提供有用的信息。量度是要统计的指标,必须事先选择恰当,基于不同的量度可以进行复杂关键性指标(KPI)的设计和计算。
    三、 确定事实数据粒度
    确定量度之后,需要考虑该量度的汇总情况和不同维度下量度的聚合情况.例如在业务系统中数据最小记录到秒,而在将来分析需求中,时间只要精确到天就可以了,在ETL处理过程中,按天来汇总数据,些时数据仓库中量度的粒度就是”天”。如果不能确认将来的分析需求中是否要精确的秒,那么,我们要遵循”最小粒度原则”,在数据仓库中的事实表中保留每一秒的数据,从而在后续建立多维分析模型(CUBE)的时候,会对数据提前进行汇总,保障产生分析结果的效率。
    四、 确定维度
    维度是分析的各个角度.例:我们希望按照时间,或者按照地区,或者按照产品进行分析。那么这里的时间,地区,产品就是相应的维度。基于不同的维度,可以看到各个量度汇总的情况,也可以基于所有的维度进行交叉分析。
    维度的层次(Hierarchy)和级别(Level)。例:在时间维度上,按照”度-季度-月”形成了一个层次,其中”年” ,”季度” ,”月”成为了这个层次的3个级别。我们可以将“产品大类-产品子类-产品”划为一个层次,其中包含“产品大类”、“产品子类”、“产品”三个级别。
    我们可以将3个级别设置成一张数据表中的3个字段,比如时间维度;我们也可以使用三张表,分别保存产品大类,产品子类,产品三部分数据,比如产品维度。
    建立维度表时要充分使用代理键.代理键是数据值型的ID号码(每张表的第一个字段),它唯一标识了第一维度成员。在聚合时,数值型字段的匹配和比较,join效率高。同时代理键在缓慢变化维中,起到了对新数据与历史数据的标识作用。
    五、 创建事实表
    在确定好事实数据和维度后,将考虑加载事实表。业务系统的的一笔笔生产,交易记录就是将要建立的事实表的原始数据.
    我们的做法是将原始表与维度表进行关联,生成事实表。关联时有为空的数据时(数据源脏),需要使用外连接,连接后将各维度的代理键取出放于事实表中,事实表除了各维度代理键外,还有各度量数据,不应该存在描述性信息。
    事实表中的记录条数据都比较多,要为其设置复合主键各蛇引,以实现数据的完整性和基于数据仓库的查询性能优化。

    8. 谈你对星形模型和雪花模型理解和认识?
    星型模型
    核心是一个事实表及多个非正规化描述的维度表组成。
    雪花模型
    它是星型模型的扩展,不同的是维度表被规范化,进一步分解到附加表中。
    星座模型
    由多个事实表组合,维表是公共的,可以被多个事实表共享。星座模型是数据仓库最常使用的模型。
    数据仓库建模 — 星型模式
    Example of Star Schema

    在这里插入图片描述
    在这里插入图片描述

    数据仓库建模 — 雪片模式
    Example of Snowflake Schema

    节省存储空间
    一定程度上的范式

    在这里插入图片描述

    星形 vs.雪花型

    Which one is better?
    长期以来的争论
    两种观点各有支持者
    争论在继续……
    目前看来,大部分更加倾向于星型
    支持星形维度的论点

    事实表总会是很大的,在维度表上节省的空间相对来说是很小的
    增加了数据模型的复杂度
    查询操作概念上更复杂了
    从数据仓库到多维数据库的加载时间会更长
    因此,只有当维度表极大,存储空间是个问题时,才考虑雪花型维度
    简而言之,最好就用星型维度即可
    支持雪花型维度的论点

    从数据仓库到多维数据库的加载过程中,雪花型维度的效率更高;
    雪花型维度描述了更清晰的层次概念;
    只有当最终用户可能直接访问数据仓库时才考虑星形(而这是不被建议的);
    我的个人经验

    星形结构效率上优于雪花型;
    多数情况下,我会选择星型,但是不排除使用雪花型的情况;
    9. 什么叫维度和度量值?(一个是出发点,一个是观察值)
    事实表
    在多维数据仓库中,保存度量值的详细值或事实的表称为“事实表”。一个按照州、产品和月份划分的销售量和销售额存储的事实表有5个列,概念上与下面的示例类似。

    在这里插入图片描述

    在这些事实表的示例数据行中,前3个列——州、产品和月份——为键值列。剩下的两个列——销售额和销售量——为度量值。事实表中的每个列通常要么是键值列,要么是度量值列,但也可能包含其他参考目的的列——例如采购订单号或者发票号。

    事实表中,每个度量值都有一个列。不同事实表将有不同的度量值。一个销售数据仓库可能含有这两个度量值列:销售额和销售量。一个现场信息数据仓库可能包含3个度量值列:总量、分钟数和瑕疵数。创建报表时,可以认为度量值形成了一个额外的维度。即可以把销售额和销售量作为并列的列标题,或者也可以把它们作为行标题。然而在事实表中,每个度量值都作为一个单独的列显示。

    事实表数据行中包含了您想从中获取度量值信息的最底层级别的明细。换句话说,事实表中对每个维度的最详细的项目成员都有数据行。如果有使用其他维度的度量,只要为那些度量和维度创建另一个事实表即可。数据仓库中可能包含拥有不同度量值和维度的不同事实表。

    前面表格中的示例数据行显示了事实表的概念布局。事实是事实表几乎总会使用一个整数值来表示(维度)成员,而不使用描述性的名称。因为事实表往往会包含数量多得无法想象的数据行——在一个中等大小的数据仓库中,事实表动辄包含上百万行数据——使用整数键值可以有效地减小事实表的大小。事实表真正的布局如下所示。

    在这里插入图片描述

    在事实表中使用整数键值时,维度成员的名称需要放到另一种表中——也就是维度表。通常,事实表中的每个维度都有一个维度表。

    事实表前缀为Fact。

    归纳:

    每个数据仓库都包含一个或者多个事实数据表。事实数据表可能包含业务销售数据,如现金登记事务。

    所产生的数据,事实数据表通常包含大量的行。事实数据表的主要特点是包含数字数据(事实),并且这些数字信息可以汇总,以提供有关单位作为历史的数据,每个事实数据表包含一个由多个部分组成的索引,该索引包含作为外键的相关性纬度表的主键,而维度表包含事实记录的特性。事实数据表不应该包含描述性的信息,也不应该包含除数字度量字段及使事实与纬度表中对应项的相关索引字段之外的任何数据。

    包含在事实数据表中的“度量值”有两中:一种是可以累计的度量值,另一种是非累计的度量值。最有用的度量值是可累计的度量值,其累计起来的数字是非常有意义的。用户可以通过累计度量值获得汇总信息,例如。可以汇总具体时间段内一组商店的特定商品的销售情况。非累计的度量值也可以用于事实数据表,单汇总结果一般是没有意义的,例如,在一座大厦的不同位置测量温度时,如果将大厦中所有不同位置的温度累加是没有意义的,但是求平均值是有意义的。

    一般来说,一个事实数据表都要和一个或多个纬度表相关联,用户在利用事实数据表创建多维数据集时,可以使用一个或多个维度表。

    维度表
    维度表包含了维度的每个成员的特定名称。维度成员的名称称为“属性”(Attribute)。假设Product维度中有3种产品,那么维度表将如下所示。

    在这里插入图片描述

    产品名称是产品成员的一个属性。因为维度表中的Product ID与事实表中的Product ID相匹配,称为“键属性”。因为每个Product ID只有一个Product Name,显示时用名称来替代整数值,所以它仍然被认为是键属性的一部分。

    在数据仓库中,维度表中的键属性必须为维度的每个成员包含一个对应的唯一值。用关系型数据库术语描述就是,键属性称为主键列。每个维度表中的主键值都与任何相关的事实表中的键值相关。在维度表中出现一次的每个键值都会在事实表中出现多次。例如Mountain-100的Product ID 347只在一个维度表数据行中出现,但它会出现在多个事实表数据行中。这称为一对多关系。在事实表中,键值列(它是一对多关系的“多”的一方)称为外键列。关系型数据库使用匹配的主键列(在维度表中)和外键列(在事实表中)值来联接维度表到事实表。

    把维度信息移动到一个单独的表中,除了使得事实表更小外,还有额外的优点——可以为每个维度成员添加额外的信息。例如,维度表可能为每个产品添加种类(Category)信息,如下所示。

    在这里插入图片描述

    现在种类是产品的另一个属性。如果知道Product ID,不但可以推断出Product Name,而且可以推断出Category。键属性的名称可能是唯一的——因为每个键只有一个名称,但其他属性不需要是唯一的,例如Category属性可能会出现好几次。这样一来,便可以创建按照产品和类别对事实表信息进行分组的报表。

    除了名称外,维度表可以包含许多其他的属性。本质上,每个属性都对应于维度表中的一个列。下面是带有其他额外属性的只有3个成员的Product维度表的示例。

    在这里插入图片描述
    维度属性可以是可分组的,也可以是不可分组的。换句话就是,您是否见过按照哪个属性来分组度量值的报表?在我们的示例中,Category、Size和Color全都是可分组的属性。由此自然会联想到可能在某个报表中按照颜色、大小或种类来分组销售额。但Price看起来不像是可分组的属性——至少它本身不是。在报表中可能会有一个更有意义的其他属性——例如Price Group,但价格本身变化太大,导致在报表上分组意义不大。同样地,按照Product Description属性在报表上进行分组意义也不大。在一个Customer维度中,City、Country、Gender和Marital Status都是可以在报表上按照它们进行有意义分组的属性,但Street Address或Nickname都应当是不可分组的。不可分组的属性通常称为成员属性(member property)。
    某些可分组的属性可以组合起来创建一个自然层次结构(natural hierarchy)。例如假设Product有Category和Subcategory属性,在多数情况下,单个产品只会属于单个Subcategory,并且单个Subcategory只会属于单个Category。这将形成一个自然层次结构。在报表中,可能会显示Categories,然后允许用户从某个Category钻取到Subcategories,以及最终钻取到Products。
    层次结构——或者说钻取路径——不一定要是自然的(例如,每个低层次的成员会决定下一个高层次的成员)。例如,您可能会创建一个按照Color分组产品的报表,但允许用户根据每个Color钻取到每个不同的Size。因为报表的钻取能力,Color和Size形成了一个层次结构,但是根据Size却没有任何信息可以用来断定产品的Color将是什么。这是一个层次结构,但不是一个自然层次结构——但也不是说它是个非自然层次结构。Color和Size形成一个层次结构并没有什么不对,它只是这样一个简单的事实:相同的Size可以出现在多个Color中。
    维度表前缀为Dim。
    归纳:
    维度表可以看作是用户来分析数据的窗口,纬度表中包含事实数据表中事实记录的特性,有些特性提供描述性信息,有些特性指定如何汇总事实数据表数据,以便为分析者提供有用的信息,维度表包含帮助汇总数据的特性的层次结构。例如,包含产品信息的维度表通常包含将产品分为食品、饮料、非消费品等若干类的层次结构,这些产品中的每一类进一步多次细分,直到各产品达到最低级别。
    在维度表中,每个表都包含独立于其他维度表的事实 特性,例如,客户维度表包含有关客户的数据。维度表中的列字段可以将信息分为不同层次的结构级。
    结论:
    [1]事实表就是你要关注的内容;
    [2]维度表就是你观察该事务的角度,是从哪个角度去观察这个内容的。
    例如,某地区商品的销量,是从地区这个角度观察商品销量的。事实表就是销量表,维度表就是地区表。

    聚合表
    数据是按照最详细的格式存储在事实表中,各种报表可以充分利用这些数据。一般的查询语句在查询事实表时,一次操作经常涉及成千上万条记录,但是通过使用汇总、平均、极值等聚合技术可以大大降低数据的查询数量。因此,来自事实表中的底层数据应该事先经过聚合存储在中间表中。中间表存储了聚合信息,所以被称为聚合表,这种处理过程被称为聚合过程。

    模型设计经验说明。在概念模型设计、逻辑模型设计以及物理模型设计几个阶段主要的工作是什么?

    展开全文
  • 数据仓库的四个层次设计

    千次阅读 2019-06-04 16:05:03
    数据仓库数据仓库全面接收源系统数据,ETL进程对数据进行规范化、验证、清洗,并最终装载进入数据集市,通过数据集市支持系统进行数据查询、分析,整个数据仓库包含四大层次。 1.数据仓库的四个操作    ...
  • 1.6 监控数据仓库环境 1.7 小结 第2章 数据仓库环境 2.1 数据仓库的结构 2.2 面向主题 2.3 第1天到第n天的现象 2.4 粒度 2.5 探查与数据挖掘 2.6 活样本数据库 2.7 分区设计方法 2.8 数据仓库中的数据组织 2.9 审计...
  • 在上一期的专栏文章中,我们曾经提到:数据分析系统的总体架构分为四个部分 —— 源系统、数据仓库、多维数据库、客户端(图一:pic1.bmp) 其中,数据仓库(DW)起到了数据大集中的作用。通过数据抽取,把数据从源...
  • 数据仓库进行数据建模

    千次阅读 2019-04-07 19:43:57
    数据仓库术语表 数据仓库引入了新的术语,扩展了数据建模的术语表。为使本文的阐述能够完备,下面我介绍一下最常用的术语。 数据仓库 数据仓库是一个支持管理决策的数据集合。数据是面向主题的、集成的、不易丢失...
  • 什么是数据仓库

    万次阅读 多人点赞 2020-01-01 17:51:14
    为什么需要数据仓库? 传统的数据库中,存放的数据都是一些定制性数据较多,表是二维的,一张表可以有很多字段,字段一字排开,对应的数据就一行一行写入表中,特点就是利用二维表表现多维关系。 但这种表现关系...
  • 数据仓库相关知识

    千次阅读 2020-05-27 17:46:21
    数据仓库(Data Warehouse) 一、概念 数据仓库是这么定义的:数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的、不可修改的数据集合。 这个定义中有一个定义比较容易含混,那就是“面向主题”。...
  • 数据仓库之OLAP与OLTP区别

    万次阅读 2020-06-29 22:41:04
    关于数据仓库 数据仓库的定义 一个面向主题,集成的,稳定,随时间变化的数据集合,以用于支持管理的决策过程。 数据仓库的目的 通过集成不同的系统信息为企业提供统一的决策分析平台,帮助企业解决实际的业务问题。...
  • 数据仓库的架构以及数据分层

    万次阅读 2016-09-26 14:37:18
    数据仓库分层的原因 1通过数据预处理提高效率,因为预处理,所以会存在冗余数据 2如果不分层而业务系统的业务规则发生变化,就会影响整个数据清洗过程,工作量巨大 3通过分层管理来实现分步完成工作,这样每一层的...
  • 详解数据仓库和数据库的区别

    万次阅读 多人点赞 2018-05-19 08:50:20
    一、数据仓库 什么是数据仓库数据仓库(Data Warehouse),可简写为DW或DWH,数据仓库,是为了企业所有级别的决策制定计划过程,提供所有类型数据类型的战略集合。它出于分析性报告和决策支持的目的而创建。为...
  • 数据仓库和数据集市的区别

    万次阅读 多人点赞 2014-11-15 00:17:30
    数据仓库与数据集市 看了很多数据仓库方面的资料,都涉及到了“数据集市”这一说法,刚开始对数据仓库和数据集市的区别也理解得比较肤浅,现在做个深入的归纳和总结,主要从如下几个方面进行阐述: (1) 基本...
  • 4.数据挖掘概念笔记——数据仓库与OLAP 欢迎转载,转载请标明出处: 数据仓库提供联机分析处理工具,用于各种粒度的多维数据的交互分析,有利于有效的数据泛化和数据挖掘。 什么是数据仓库? 答:数据仓库有多种...
  • 数据仓库具有四个主要特性

    万次阅读 2018-07-21 10:23:02
    数据仓库是一般从用户实际需求出发,将不同平台的数据源按设定主题进行划分整合,与传统的面向事务的操作型数据库不同,具有较高的抽象性。面向主题的数据组织方式,就是在较高层次对分析对象数据的一个完整、统一并...
  • 深刻理解数据仓库

    万次阅读 2019-11-27 13:36:28
    讨论的问题 什么是数据仓库?... 数据仓库之父比尔·恩门(Bill Inmon)在1991年出版的“Building the Data Warehouse”(《建立数据仓库》)一书中所提出的定义被广泛接受——数据仓库(Data War
  • Hive开发要知道数据仓库的四个层次设计

    万次阅读 多人点赞 2018-12-29 17:47:17
    数据仓库数据仓库全面接收源系统数据,ETL进程对数据进行规范化、验证、清洗,并最终装载进入数据集市,通过数据集市支持系统进行数据查询、分析,整个数据仓库包含四大层次。 1.数据仓库的四个操作  ETL...
1 2 3 4 5 ... 20
收藏数 294,582
精华内容 117,832
关键字:

数据仓库