数据仓库 订阅
数据仓库,英文名称为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)。
收起全文
精华内容
参与话题
问答
  • 数据仓库基本知识

    万次阅读 多人点赞 2017-10-31 17:35:04
    数据仓库是什么 根据统计,每个企业的数据量每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 17:52:19
    公司之前的数据都是直接传到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-04-24 19:44:14
    为什么需要数据仓库? 传统的数据库中,存放的数据都是一些定制性数据较多,表是二维的,一张表可以有很多字段,字段一字排开,对应的数据就一行一行写入表中,特点就是利用二维表表现多维关系。 但这种表现关系...

    为什么需要数据仓库?

           传统的数据库中,存放的数据都是一些定制性数据较多,表是二维的,一张表可以有很多字段,字段一字排开,对应的数据就一行一行写入表中,特点就是利用二维表表现多维关系。

           但这种表现关系的上限和下限就定死了,比如QQ的用户信息,直接通过查询info表,对应的username、introduce等信息即可,而此时我想知道这个用户在哪个时间段购买了什么?修改信息的次数?诸如此类的指标时,就要重新设计数据库的表结构,因此无法满足我们的分析需求。

           在产品脑图中可以很清晰的看到根据业务需求设计所需的字段,因此也导致数据库是根据业务需求进行设计

           那么有的会问,为什么一开始就不考虑好这个扩展性呢?为什么数据库一开始就不以数据仓库的形式设计?

           首先数据仓库,从字面上理解就可以感受到这是一个很大的空间,而且存储的物品很杂,里面会存放酱油、沐浴露、洗发精等物品,而数据库是存放酱油、盐等厨房用品,洗浴又是一个数据库。

           另外一个就是,国内互联网的发展,一开始大家都是做个软件出来,大家一起用,这个时候只要满足的了需求即可,现今不止是需求还有用户的体验等各种方面,需要根据这些分析指标做调整。

    小结:

           数据库是跟业务挂钩的,而数据库不可能装下一个公司的所有数据,因此数据库的设计通常是针对一个应用进行设计的。

           数据仓库是依照分析需求、分析维度、分析指标进行设计的。

     

    什么是数据仓库?

           数据仓库(Data Warehouse)简称DW或DWH,是数据库的一种概念上的升级,可以说是为满足新需求设计的一种新数据库,而这个数据库是需容纳更多的数据,更加庞大的数据集,从逻辑上讲数据仓库和数据库是没有什么区别的。

           为企业所有级别的决策制定过程,提供所有类型数据支撑的战略集合,主要是用于数据挖掘和数据分析,以建立数据沙盘为基础,为消灭消息孤岛和支持决策为目的而创建的。

    数据仓库发展过程

           2000年初,国内是简单的报表阶段,这个阶段主要是汇总一些数据,解决业务人员想要的报表。

           如:销售额:xxx万元、销售量:20000件

     

           2010年,数据集市阶段,进行一定的数据采集、整理,按照某业务部门的需求进行采集、整理,按照业务人员需要,进行多维度报表的展现,能够提供特定的领导决策数据。

           如:1月~3月销售额:xxx万元、4月~6月销售额:xxx万元

          

           2015年,各大公司开始注重用户体验,物流效率等问题,这个时候进入数据仓库阶段,主要按照数据模型,对整个企业的数据进行采集、整理,提供跨部门,完整一致性的业务报表数据,能够通过数据仓库生成对业务具有指导性的数据,为决策者提供更全面的数据。

           如:某个月某个地区的用户数量下降,某个月某个地区的用户数量上升。

     

    数据仓库特点

    面向主题

           是企业系统信息中的数据综合、归类并进行分析的一个抽象,对应企业中某一个宏观分析领域所涉及的分析对象。

           比如购物是一个主题,那么购物里面包含用户、订单、支付、物流等数据综合,对这些数据要进行归类并分析,分析这个对象数据的一个完整性、一致性的描述,能完整、统一的划分对象所设计的各项数据。

           如果此时要统计一个用户从浏览到支付完成的时间时,在购物主题中缺少了支付数据或订单数据,那么这个对象数据的完整性和一致性就可能无法保证了。

     

    数据集成

           数据仓库的数据是从原有分散的数据库中的数据抽取而来的。

           操作型数据和支持决策分析型(DSS)数据差别甚大,这里需要做大量的数据清洗与数据整理的工作。

           第一:每一个主题的源数据在原有分散数据库中的有许多重复和不一致,且不同数据库的数据是和不同的应用逻辑捆绑的。

           第二:数据仓库中的综合性数据不能从原有的数据库系统直接得到,因此在数据进入数据仓库之前要进过统一和综合。(字段同名异意,异名同义,长度等)

     

    不可更新

           数据仓库的数据主要是提供决策分析用,设计的数据主要是数据查询,一般情况下不做修改,这些数据反映的是一段较长时间内历史数据的内容,有一块修改了影响的是整个历史数据的过程数据。

           数据仓库的查询量往往很大,所以对数据查询提出了更高的要求,要求采用各种复杂的索引技术,并对数据查询的界面友好性和数据凸显性提出更高的要求。

     

    随时间不断变化

           数据仓库中的数据不可更新是针对应用来说,从数据的进入到删除的整个生命周期中,数据仓库的数据是永远不变的。

           数据仓库的数据是随着时间变化而不断增加新的数据。

           数据仓库随着时间变化不断删去久的数据内容,数据仓库的数据也有时限的,数据库的数据时限一般是60 ~ 90天,而数据仓库的数据一般是5年~10年。

           数据仓库中包含大量的综合性数据,这些数据很多是跟时间有关的,这些数据特征都包含时间项,以标明数据的历史时期。

     

    数据仓库和数据库的区别

           数据库的操作:一般称为联机事务处理OLTP(On-Line Transaction Processing),是针对具体的业务在数据库中的联机操作,具有数据量较少的特点,通常对少量的数据记录进行查询、修改。

           数据仓库的操作:一般称为联机分析处理OLAP(On-Line Analytical Processing),是针对某些主题(综合数据)的历史数据进行分析,支持管理决策

    比较项

    操作型(OLTP)

    分析性(OLAP)

    关注

    细节

    综合或提炼

    模型

    实体 – 关系(E-R)

    星型或雪花

    操作

    可更新

    只读,只追加

    操作粒度

    操作一个单元

    操作一个集合

    场景

    面向事务

    面向分析

    数据量

    需求

    日常操作

    决策需求

    业务方向

    客户信息、订单等查询

    客户登录间隔时间,市场细分等

     

    数据仓库常用系统架构

     

           ODS层(临时存储层):这一层做的工作是贴源,而这些数据和源系统的数据是同构,一般对这些数据分为全量更新和增量更新,通常在贴源的过程中会做一些简单的清洗,

           DW层(数据仓库层):将一些数据关联的日期进行拆分,使得其更具体的分类,一般拆分成年、月、日,而ODS层到DW层的ETL脚本会根据业务需求对数据进行清洗、设计,如果没有业务需求,则根据源系统的数据结构和未来的规划去做处理,对这层的数据要求是一致、准确、尽量建立数据的完整性。

           APP层(引用层):提供报表和数据沙盘展示所需的数据。

     

    为什么要分层?

           在未分层的情况下,数据之间的耦合性与业务耦合性是不可避免的,当源业务系统的业务规则发生变化时,可能影响整个数据的清洗过程。

           数据分层简化了数据清洗的过程,每一层的逻辑变得更加简单和易于理解,当发生错误或规则变化时,只需要进行局部调整。

    通过大量的预处理来提升应用系统查询速度,进而提升的用户体验,因此数据仓库会冗余大量的数据,是典型的空间换时间的策略。

     

    元数据

           在操作数据仓库时,操作的都是元数据,而元数据分为技术元数据和业务元数据。

           技术元数据:是指数据仓库开发、管理、维护相关的数据,描述了数据的原信息,转换描述、数据映射、访问权限等。

           业务元数据:为管理层和业务分析人员服务,从业务的角度描述数据,包括行业术语、数据的可用性、数据的意义等。

           元数据的存储有常用的两种,一种是以数据集为基础,每一个数据集有对应的元数据文件,每一个元数据文件对应数据集的元数据内容,另一种是以数据库为基础,由若干项组成,每一项标识元数据的一个元素。

     

     

    为什么需要为数据仓库建模?

           进行全面的业务梳理时,我们可以通过业务模型,全面了解业务结构及运行情况,按照业务特定的规律分门别类和程序化,改进业务的流程

           通过模型的建设,我们可以很清晰的看到数据之间内在的关联关系,从而建立起全方位的数据视角,并消灭信息孤岛数据差异化的问题,进而保证数据的一致性。

           模型可以很好的帮助我们分离出底层技术的实现和上层业务的展现,当上层业务发生变化时,通过数据模型,底层的技术实现可以适应的了业务的变动,进而解决数据库的灵活性

           在模型中可以很好的看出开发人员和业务人员之间的系统建设范围的界定,及未来的规划

     

    什么是数据模型?

           数据模型是数据关系的一种映射, 就是将业务之间的关系,用模型图形化的描绘出来,而不再是脑海的一个模糊的关系。

           在设计数据仓库模型和架构时,我们需要懂具体的技术,也需要了解行业的知识和经验来帮助我们对业务进行抽象、处理,进而生成各个阶段的模型。

     

    数据模型架构

     

           在大体上,我们将数据模型分为5大块。

           系统记录域:数据仓库业务数据存储区,保证数据的一致性。

           内部管理域:用于内部管理的元数据,统一的元数据管理。

           汇总域:这里的数据来自系统记录域的汇总,保证分析域的主题分析性能,满足部分报表查询。

           分析域:各个业务部分的具体主题业务分析,可以单独存储在相应的数据集市中。

           反馈域:用于相应的前端的反馈数据,视业务的需要设置这个域。

     

    维度和指标(度量)

           维度和指标时数据分析领域常用的概念,亦是在设计数据仓库过程中需要考虑的。

           维度就是数据的观察角度,即从哪个角度去分析问题,看待问题。

           指标(度量)就是从维度的基础上去衡算这个结果的值。

           比如银行采集数据:

    时间(维度)

    分行(维度)

    存款额(指标)

    1999年

    A分行

    1000W

    2000年

    A分行

    2000W

    2001年

    A分行

    3000W

    1999年

    B分行

    500W

    2000年

    B分行

    1600W

    2001年

    B分行

    3300W

           维度一般是一个离散的值,比如时间维度上每一个独立的日期或地域,因此统计时,可以把维度相同记录的聚合在一起,应用聚合函数做累加、均值、最大值、最小值等聚合计算。

           指标(度量)就是被聚合的通计算,即聚合运算的结果,一般是一个连续的值。

           比如我们可以从银行的存款额和企业的贷款额之间的计算,推算出目前的市场状况是如何,如果企业的贷款额高,银行的存款额也高,说明人们不愿意消费了,都把钱存起来,企业产品卖不出去,要发工资,那么自然要贷款了,这只是一个例子,具体还需要结合很多数据做分析。

     

    事实表和维度表

           事实表和维度表是在设计数据仓库过程中需要考虑的。

           事实表(Fact Table)是指存储有事实记录的表,如系统的日志、销售记录、用户访问日志等信息,事实表的记录是动态的增长的,所以体积是大于维度表。

           用户访问日志(事实表):用户名、url、时间…

           维度表(Dimension Table)也称为查找表(Lookup Table)是与事实表相对应的表,这个表保存了维度的属性值,可以跟事实表做关联,相当于是将事实表中经常重复的数据抽取、规范出来用一张表管理,常见的有日期(日、周、月、季度等属性)、地区表等,所以维度表的变化通常不会太大。

           维度表的存在缩小了事实表的大小,便于维度的管理和CURD维度的属性,不必对事实表的大量记录进行改动,并且可以给多个事实表重用。

           省份表(维度表):北京市、广东省、上海市…

     

    数据模型建立过程

     

           业务模型:业务分解和程序化,确定好业务的边界及业务流程,如订单、支付都是一个单独的业务模块

           领域模型:业务概念的抽象、分组,整理分组之间的关联,比如用户购物的业务,抽成一个更大的模型,这个模型一般相对于行业。

           逻辑建模:领域模型中的业务概念实体化,并考虑实体的具体属性及实体与实体之间的关系,比如订单(订单号、付款人…)和支付(金额、支付时间…)的关系。

           物理模型:解决实际应用的落地开发、上线等问题,及性能等一些具体的技术问题。

     

    范式建模法

           数据仓库的概念模型(域模型)应该包含企业数据模型的概念模型(域模型)之间的关系,以及各主题域的定义。

           数据仓库的概念模型(域模型)应该比业务系统的主题域模型范围更加广。

           在数据仓库的逻辑模型需要从业务系统的数据模型中的逻辑模型中抽象实体,实体的属性,实体的子类、关系等,在某些时候反而限制了数据仓库模型的灵活性,在底层数据向数据集市汇总时,需要进行一定的变通。

     

    维度建模法

           维度建模法的特点在于需要进行大量的数据预处理、预计算,因此会导致大量的数据处理工作,而且业务发生变化,需要重新进行维度的定义时,往往需要重新进行维度数据的预处理、预计算,使用时直接调用计算好的结果,进而导致大量的数据冗余,最大的作用就是解决了性能的问题。

     

    实体建模法

           实体建模法是一种抽象客观世界的方法,细分为一个个实体,以及实体之间的关系,将一个业务划分为3个过程,因此只能局限在业务建模和领域建模的阶段,因此到了逻辑建模阶段和物理建模阶段,则是范式和维度建模的发挥了。

     

    星型模型架构 VS 雪花模型架构

           当设计好概念模型时,就要根据概念模型设计逻辑模型,而在设计逻辑模型是,通常根据事实表和维度表的关系,将常见的模型架构分为星型模型和雪花型模型。

           星型模型架构是一种非正规化的结构,特点是有一张事实表,多张维度表,是不存在渐变维度的,事实表和维度表通过主外键相关联,维度表之间是没有关联,因为维度表的数据冗余,所以统计查询时不需要做过多外部连接。

            雪花模型架构就是将星型模型中的某些维度表抽取成更细粒度的维度表,然后让维度表之间也进行关联,通过最大限度的减少数据存储量以及联合较小的维度表来改善查询性能。

     

     

          《怎样分析数据致提高产出?》https://blog.csdn.net/Su_Levi_Wei/article/details/103794163

     

    展开全文
  • 数据仓库

    千次阅读 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的数据仓库概念的四个特点是最基本的吧,当然需要加上自己的理解) 首先,用于支持决策,面向分析型数据处理,它不同于企业现有的操作型数据库; 其次,对多个异构...
  • 数据仓库基本特征

    千次阅读 2019-12-04 23:01:45
    数据仓库 基本概念 数据仓库,简称数仓,英文名称为Data Warehouse,可简写为DW或DWH。数据仓库的目的是构建面向分析的集成化数据环境,为企业提供决策支持(Decision Support)。只有一个存在的必要:分析。 数据...
  • 数据仓库

    万次阅读 2019-04-15 11:57:54
    数据仓库(Data Warehouse)是一个面向主题的、集成的、相对稳定的、且随时间变化的数据集合,用于支持管理决策。 主题是一个抽象的概念,是指用户使用数据仓库进行决策时所关心的重点方面,一个主题通常与多个操作...
  • 数据仓库相关知识

    千次阅读 2018-08-28 17:08:19
    数据仓库(Data Warehouse) 一、概念 数据仓库是这么定义的:数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的、不可修改的数据集合。 这个定义中有一个定义比较容易含混,那就是“面向主题”。...
  • oracle数据仓库国宝级资料(全套)

    千次下载 热门讨论 2014-09-19 23:10:09
    oracle数据仓库国宝级资料(全套) 1、Oracle+10g数据仓库实践--数据仓库基础.pdf 2、Oracle+10g数据仓库实践--总体方案.pdf 3、Oracle+10g数据仓库实践--方案的总体优势.pdf 4、Oracle+10g据仓库实践--数据仓库工具的...
  • 数据仓库

    千次阅读 2019-03-06 12:24:41
    数据库是面向事务的设计,数据仓库是面向主题设计的。 数据库一般存储在线交易数据,数据仓库存储的一般是历史数据。 > 数据库设计是尽量避免冗余,一般采用符合范式的规则来设计,数据仓库在设计是有意引入...
  • 数据仓库多维数据模型设计

    万次阅读 2017-11-09 18:14:59
    建设数据模型既然是整个数据仓库建设中一个非常重要的关键部分,那么,怎么建设我们的数据仓库模型就是我们需要解决的一个问题。这里我们将要详细介绍如何创建适合自己的数据模型。 数据仓库建模方法 大千世界,...
  • 数据仓库建设

    千次阅读 2018-07-18 23:31:52
    1.数据仓库概要 1.1.数据仓库起因  在建设数据仓库之前,数据散落在企业各部门应用的数据存储中,它们之间有着复杂的业务连接关系,从整体上看就如一张巨大的蜘蛛网:结构上错综复杂,却又四通八达。在企业级数据...
  • 大数据与数据仓库入门到精通

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

    万次阅读 2020-06-29 17:18:36
    关于数据仓库 数据仓库的定义 一个面向主题,集成的,稳定,随时间变化的数据集合,以用于支持管理的决策过程。 数据仓库的目的 通过集成不同的系统信息为企业提供统一的决策分析平台,帮助企业解决实际的业务问题。...
  • 1.为什么要设计数据分层? * 数据建设刚起步,大部分的数据经过粗暴的数据接入后就直接对接业务。 * 数据建设发展到一定阶段,发现数据的使用杂乱无章,各种业务都是从原始数据直接计算而得。 * 各种重复计算,严重...
  • 数据库, 数据仓库, 数据集市,数据湖,数据中台

    千次阅读 多人点赞 2019-02-22 16:21:47
    数据仓库和数据集市的区别 作者:修鹏李 出处:CSDN 大数据:数据仓库和数据库的区别 作者:南宫蓉 出处:简书 第一篇:数据仓库概述 第二篇:数据库关系建模 作者:穆晨 出处:CNBLOS 摘要 本文简要介绍...
  • 数据仓库学习(二)——数据仓库建模

    万次阅读 多人点赞 2018-07-10 23:02:40
    笔者是一个痴迷于挖掘数据中的价值的学习人,希望在平日的工作学习中,挖掘数据的价值,找寻数据的秘密,笔者认为,数据的价值不仅仅只体现在企业中,个人也可以体会到数据的魅力,用技术力量探索行为密码,让大数据...
  • 医疗数据之医院管理型数据仓库解决方案

    千次阅读 多人点赞 2020-04-04 23:34:58
    数据仓库:将现有HIS、LIS、PACS、OA、病案系统、资产管理系统等多种业务和管理系统的数据应用联机业务、数据的清洗,转换,数据仓库、多维数据、数理统计和数据挖掘等技术,以生动友好的界面形式展现数据分布特征,...
  • 数据仓库与元数据

    万次阅读 2012-02-17 14:42:53
    随着数据仓库(DW)技术的不断成熟,企业的数据逐渐变成了决策的主要依据。数据仓库是一种面向决策主题、由多数据源集成、拥有当前及历史总结数据、以读为主的数据库系统,其目的是支持决策。数据仓库要根据决策的...
  • 银行数据仓库体系实践(1)--银行数据仓库简介

    千次阅读 多人点赞 2019-05-19 21:53:14
    银行在日常生活中大家经常接触,但在柜台、ATM、手机银行等后面是一个庞大的系统在支持着银行的各项业务,那数据仓库作为银行的数据中心,具有什么样的作用和功能呢?

空空如也

1 2 3 4 5 ... 20
收藏数 306,637
精华内容 122,654
关键字:

数据仓库