数据仓库new一数据仓库概述_第1页
数据仓库new一数据仓库概述_第2页
数据仓库new一数据仓库概述_第3页
数据仓库new一数据仓库概述_第4页
数据仓库new一数据仓库概述_第5页
已阅读5页,还剩210页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、 数据仓库概述1.1 数据仓库的定义William H.Inmon(比尔·恩门):数据仓库(Data Warehouse)是一个面向主题的(Subject Oriented)、集成的(Integrated)、相对稳定的(Non-Volatile)、反映历史变化的(Time Variant)数据集合,用于支持管理决策(Decision Making Support)和信息的全局共享(Global Sharing ofInformation)。其主要功能是将组织透过资讯系统之联机事务处理(OLTP)经年累月所累积的大量资料, 透过数据仓库理论所特有的资料储存架构,作一有系统的分析整理,以

2、利各种分析方法如联机分析处理(OLAP)、数据挖掘(Data Mining)之进行,并进而支持如决策支持系统(DSS)、主管资讯系统(EIS)之创建,帮助决策者能快速有效的自大量资料中,分析出有价值的资讯,以利决策拟定及快速回应外在环境 变动,帮助建构商业智能(BI)。1.2 数据仓库的发展历程1. 萌芽阶段。数据仓库概念最早可追溯到20世纪70年代,MIT的研究员致力于研究一种优化的技术架构,该架构试图将业务处理系统和分析系统,即将业务处理和分析处理分为不同层次,各自的特点采取不同的架构设计原则,MIT的研究员认为这两种信息处理的方式具有显著差别,以 至于必须采取完全不同的架构和设计方法。但

3、受限于当时的信息处理能力,这个研究仅仅停留在理 论层面。2. 探索阶段。20世纪80年代中后期,DEC公司结合MIT的研究结论,建立了TA2(TechnicalArchitecture2)规范,该规范定义了分析系统的四个组成部分:数据获取、数据、目录和用户服务。这是系统架构的一次转变,第一次明确提出分析系统架构并将其运用于实践。3. 雏形阶段。1988年,为解决全企业集成问题,IBM公司第一次提出了信息仓库(InformationWarehouse)的概念,并称之为VITAL规范(VirtuallyIntegrated Technical Architecture Lifecycle)。VIT

4、AL定义了85种信息仓库组件,包括PC、图形化界面、面向对象的组件以及局域网等。至此,数据仓库的基本原理、技术架构以及分析系统的主要原则都已确定,数据 仓库初具雏形。4. 确立阶段。1991年Bill Inmon(比尔·恩门)了他的第一本关于数据仓库的书Building theData Warehouse,标志着数据仓库概念的确立。该书指出,数据仓库(DataWarehouse)是一个面向主题的(Subject Oriented)、集成的(Integrated)、相对稳定的(Non-Volatile)、反映历史变化的(Time Variant)数据集合,用于支持管理决策(Decisi

5、on-Making Support)。该书还提供了建立数据仓库的指导意见和基本原则。凭借着这本书,Bill Inmon被称为数据仓库之父。数据仓库的概念确立之后,有关数据仓库的实施方法、实施路径和架构等问题了诸多争议。1994年前后,实施数据仓库的公司大都以失败告终,导致数据集市的概念被提出并大范围运用,其代表 人物是Ralph Kimball。由于数据集市仅仅是数据仓库的某一部分,实施难度大大降低,并且能够满足公司内部部分业务部门的迫切需求,在初期获得了较大。但随着数据集市的不断增多,这种架构的缺陷也逐步显现。公司内部建设的数据集市由于遵循不同的标准和建设原则,以致多个数据集市的数据和不一致

6、。解决问题的方法只能是回归到数据仓库最初的基本建设原则上来。1998年,Inmon提出了新的BI架构CIF(CorporationInformation Factory,企业信息工厂),新架构在不同架构层次上采用不同的构件来满足不同的业务需求。1.3 数据仓库的四大特征1. 数据仓库的数据是面向主题的2. 数据仓库的数据是集成的3. 数据仓库的数据是非易失的4. 数据仓库的数据是随时间不断变化的1.3.1 面向主题主题(Subject):特定的数据分析领域与目标。主题是根据分析的要求来确定的。这与按照数据处理或应用的要求来组织数据是不同的。如在生产企业 中,同样是材料供应,在操作型数据库系统中

7、,人们所关心的是怎样更方便和更快捷地进行材料供应的业务处理;而在进行分析处理时,人们就应该关心材料的不同采购质量状况等。和材料供应是否及时,以及材料数据仓库是面向分析、决策的要求的,不同的用户有不同的要求,同一个用户的要求也会随时间而经常变化,因此,数据仓库中的主题有时会因用户面向主题划分如下:要求的变化而变化的。数据仓库面向在数据模型中已经定义好的公司的主要主题领域。典型的主题领域包括顾客、或是其他某项事务或活动。、订单和财务基本主题:教育机构:学生、讲师、班、课程等行业:运营、流量、价值、商品、市场、风控、销售等传统行业:供应商、商品、客户、仓库等主题示例比如,对于Adventure Wo

8、rks Cycle这种类型的公司管理层需要分析的主题一般包括供应商主题、商品主题、客户主题和仓库主题。其品主题的内容包括超市商品的采购情况、商品 的销售情况和商品的情况;客户主题包括的内容可能有客户商品的情况;仓库主题包括仓库品的情况和仓库的管理情况等,如下图所示。确定主题边界实际上需要进一步理解业务关系,因此在确定整个分析主题后,还需要对这些主题进行初 步的细化才便于获取每一个主题应该具有的边界。对于上图的4个主题及其在企业中的业务关系可以确 定边界如下图所示。主题虽然在信息包图中只占据标题的位置,但是却是信息打包方法中最重要的部分,当主题定义好之 后,数据仓库中的逻辑模型也就基本成形了。此

9、时,需要在主题 的逻辑关系模式中包含所有的属性及与系统相关的行为。数据仓库中的数据结构也需要在逻辑模型的设计阶段完成定义,需要向里面增加所需要的信息和能充分 代表主题的属性组。以Adventure Works Cycle这类公司数据仓库为例,如下表所示可以分别在“商品”、“销售”和“客户”主题上增加能够进一步说明主题的属性组。由于数据仓库的设计是一个螺旋发展的过程,在刚开始,没有必要在数据仓库的数据库中体现所有的主 题,选择最重要的主题作为数据仓库设计的试金石是很有必要的。因此使用主题首先是找到需要分析的 主题域。例如在AdventureWorksDW数据仓库的概念模型设计中,在对需求进行分析

10、后,认识到“商品”主题既是 一个销售型企业最基本的业务对象,又是进 行决策分析的最主要领域,因而把“销售分析”主题域定义为要首先建立的主题。通过“商品”主题的建立,经营者就可以对整个企业的经营状况有较全面的了解。 先实施“商品”主题可以尽快地满足企业管理施。建立数据仓库的最初要求,所以先选定“商品”主题进行实主题域主题域通常是较为紧密的数据主题的集合。可以根据业务的关注点,将这些数据主题划分到不同的主题域。主题域的确定必须由最终用户和数据仓库的设计共同完成。主题边界的划分应该按照以下规则来进行定义划分。首先数据仓库中逻辑模型根据业务划分为多个主题域,主题域下面会涉及具体的实体表,维表以及关系实

11、体,这 些划分可以按照下面规则来进行划分。a:每个主题域包含一个主要业务概念;b:每个主题域包含一个主要业务概念,用一个或几个实体来表述。c:主题域与主题域之间的实体不能重叠,实体间的关系实体则可以出现在两个主题域内;d:每个主题域中包含几个关键的实体,且这几个实体间具有直接的关联关系。主题域的另一种定义是:对某个主题进行分析后确定的主题的边界。分析主题域,确定要装载到数据仓库的主 题是信息打包技术的第一步。而在进行数据仓库设计时,一般是一次先建立一个主题或企业全部主题中的一部分,因此在大多数数据仓库的设计过程中都有一个主题域的选择过程。主题域的确定必须由最终用户和数据仓库的设计共同完成。主题

12、域、主题、实体间关系主题设计是对主题域进一步分解,细化的过程。主题域下面可以有多个主题,主题还可以划分成更多的子主题,而实体则是不可划分的最小。主题域、主题、实体的关系如下图所示:主题域的划分主题域的确定必须由最终用户和数据仓库的设计共同完成的, 而在划分主题域时,大家的切入点不同可能会造成一些争论、重构等的现象,考虑的点可能会是下方的某些方面:1、按照业务或业务过程划分:比如一个靠销售位置的门户主题域可能会有域,客户域等,而域可能就会有的库存,销售分析、内部投放分析等主题;2、根据需求方划分:比如需求方为财务部,就可以设定对应的财务主题域,而财务主题域里面可能就 会有员工工资分析,投资回报比

13、分析等主题;3、按照功能或应用划分:比如中的数据域、群聊数据域等,而数据域可能就会有用户动态信息主题、主题等;4、按照部门划分:比如可能会有运营域、技术域等,运营域中可能会有工资分析等主题;分析、活动宣传效果主题域:1.3.2 集成集是指数据仓库中数据必须是一致的。数据仓库的数据是从原有的分散的多个数据库、数据文件和数据段中抽取来的,数据来源可能既有内部数据又有外部数据。数据仓库中的数据是为分析服务的,而分析需要多种广泛的不同数据源以便进行比较、鉴别,因此 数据仓库中的数据必须从多个数据源中获取,这些数据源包括多种类型数据库、文件系统以及Internet网上数据等,它们通过数据集成而形成数据仓

14、库中的数据。集成的方法:统一:消除不一致的现象综合:对原有数据进行综合和计算集成需要考虑的问题:数据格式计量数据代码含义数据名称1.3.3 非易失数据仓库中的数据是经过抽取而形成的分析型数据,不具有原始性,主要供企业决策分析之用,执行的主要是操作,一般情况下不执行更新操作。同时,一个稳定的数据环境也有利于数据分析操作和决策的制订。面向应用的事务数据库需要对数据进行频繁的、更新操作,而对于数据仓库中数据的操作仅限于数据的初始导入和。1.3.4 随时间不断变化数据仓库以维的形式对数据进行组织,时间维是数据仓库中很重要的一个维度。并且数据仓库中的 数据时间跨度大,从几年甚至到几十年,称为历史数据。数

15、据仓库中的数据必须以一定时间段为数据变化方式:不断增加新的数据内容不断删去旧的数据内容更新与时间有关的综合数据进行统一更新。数据的生命周期与行业、本身的需求有关,比如金融业“在设计数据保存周期策略时,最常用的经验法则是7年和13规则”基础数据区里面通过历史表(拉链表)来保存重要信息的历史数据,一般客户类、账户类等信息要保留7年, 史。类流水类信息要保留至少13以上。除此之外,重要代码、主数据也要通过历史表保存历根据业务决定数据的生命周期,比如数据对于数据分析没多大作用,你想10年前的品、用户都已经完全不同了如果数据仓库是仅用于分析的话(我看好多地方建立的数据仓库仅用于统计分析,对于数据挖掘基本

16、都 没有用),如果有大量的数据挖掘的话,那么数据多些对于结果越精确。(当然,前提是你的历史数据 质量不太差的情况下)现在设备越来越便宜,如果不是数据量很惊人的话,一般是不用删除或导出的,因为导出后是需要管理的。1.4 数据仓库的用途整合业务数据,建立统一的数据中心产生业务报表,用于作出决策为运营提供运营上的数据支持可以作为各个业务的数据源,形成业务数据互相反馈的良性循环分析用户行为数据,通过数据挖掘来降低投入成本,提高投入效果开发数据,直接或间接地为公司1.5 OLAP VS. OLTP1.5.1 数据仓库和数据库关系1. 数仓主要用于解决企业级的数据分析问题。2. 数据库是为捕获和数据而设计

17、,数据仓库是为分析数据而设计。3. 数据库是面向事务设计的,属于操作型。数据仓库是面向分析,面向主题设计的,即信息是按主题 进行组织的,属于分析型。4. 数据库设计是尽量避免冗余,一般采用符合范式的规则来设计,数据仓库在设计是有意引入冗余, 采用反范式的方式来设计。5. 数据库是数据仓库的基础,数据库较小,而数据仓库较大,通常一个数据仓库中的数据来源于多个 数据库的异构。6. 数据不一样。对比如下:1.5.2 OLAP VS. OLTP联机事务处理OLTP(on-line transaction processing) 主要是执行基本日常的事务处理,比如数据库的增删查改。比如在的一笔联机分析处

18、理OLAP(On-Line Analytical Processing) 是数据仓库系统的主要应用,支持复杂的分析操作,侧重决策支持,并且提供直观易懂的OLTP的特点一般有:结果。典型的应用就是复杂的动态的报表系统。1.实时性要求高。我记得之前上大学的时候,异地汇款,要隔天才能到账,而现在是分分钟到账的节奏,说明现在的实时处理能力大大增强。2.数据量不是很大,生产库上的数据量一般太大,而且会及时做相应的数据处理与转移。3.一般是确定的,比如存取款的金额肯定是确定的,所以OLTP是对确定性的数据进行存取4.高并发,并且要求满足ACID原则。比如两人同时操作一个万的QPS请求。账户,比如大型的购物

19、秒杀活动时上OLAP的特点一般有:1.实时性要求不是很高,比如最常见的应用就是天级更新数据,然后出对应的数据报表。2.数据量大,因为OLAP支持的是动态,所以用户也许要通过将很多数据的统计后才能得到想要知道的信息,例如时间序列分析等等,所以处理的数据量很大;3.OLAP系统的重点是通过数据提供决策支持,所以一般都是动态,自定义的。所以在OLAP中,维度的概念特别重要。一般会将用户所有关心的维度数据,存入对应数据平台。总结:OLTP即联机事务处理,就是我们经常说的关系数据库,增删查改就是我们经常应用的东西,这是数据库的基础;TPCC(Transaction Processing Performa

20、nce Council)属于此类。OLAP即联机分析处理,是数据仓库的部心,所谓数据仓库是对于大量已经由OLTP形成的数据的一种分析型的数据库,用于处理商业智能、决策支持等重要的决策信息;数据仓库是在数据库应用到一定程序之后而对历史数据的与分析,较多,更新较少,TPCH属于此类。模式或者说nosql模式比传统意义的行随着大数据势。的到来,对于OLAP,列模式可能更具优联机事务处理【OLTP Online Transaction Processing】联机事务处理,表示事务性非常高的系统,一般都是高可用的系统,以小的事务以及小的为主,以传统的关系型数据库为主要应用,主要是基本的、日常的事务处理,

21、主要为业务数据,例如OLTP系统最容易出现瓶颈的地方就是CPU与磁盘子系统。 OLTP比较常用的设计与优化方式为Cache技术与B-tree索引技术.OLTP 系统是一个数据块变化非常频繁,SQL 语句提交非常频繁的系统.联机分析处理【OLAP Online Analytical Processing】:联机分析处理,有的时候也叫DSS决策支持系统,就是我们说的数据仓库,重点主要是面向分析,支持复杂的分析操作,侧重决策支持,并且提供直观易懂的结果。典型的应用就是复杂的动态的报表系统。会产生大量的,一般很少涉及增删改。在这样的系统中,语句的执行量不是标准,因为一条语句的执行时间可能会非常长,的数

22、据也非常多。所以,在这样的系统中,的标准往往是磁盘子系统的吞吐量(带宽),如能达到多少MB/s的流量。在OLAP系统中,常使用分区技术、并行技术。 分区技术在OLAP系统中的重要性主要体现在数据库管理上,分区技术对性能上的影响,它可以使得一些大表的扫描变得很快(只扫描单个分区)。另外,如果分区结 合并行的话,也可以使得整个表的扫描会变得很快。总之,分区主要的功能是管理上的方便性,它并不能绝对保证性能的提高,有时候分区会带来性能上的提高,有时候会降低二 数据集市概述2.1 数据集市概念建立数据集市的数据仓库是一种反映主题的全局性数据组织。但是,全局性数据仓库往往太大,在实际应用中将它 们按部门或

23、个人分别建立反映各个子主题的局部性数据组织,它们即是数据集市。因此,有时我们 也称它为部门数据仓库。数据集市:是按照主题域组织的数据集合,用于支持部门级的决策。例:在有关商品销售的数据仓库中可以建立多个不同主题的数据集市:商品采购数据集市库房使用数据集市商品销售数据集市2.2 集市分类按照数据获取来源:型:直接从操作型环境获取数据从属型:从企业级数据仓库获取数据从属集市和集市如下图:集市建设途径分为如下两种:从 全局数据仓库 到 数据集市从 数据集市 到 全局数据仓库2.3 集市和主题的区别数据仓库与数据集市的关系类似于传统关系数据库系统中的基表与视图的关系。数据集市的数据来自数据仓库,它是数

24、据仓库中数据的一个部分与局部,是一个数据的再抽取与组 织的过程。具体区别如下:由于数据集市仅仅是数据仓库的某一部分,实施难度大大降低,并且能够满足公司内部部分业务部门的迫切需求,在初期获得了较大。但随着数据集市的不断增多,这种架构的缺陷也逐步显现。公司内部建设的数据集市由于遵循不同的标准和建设原则,以致多个数据集市的数据和不一致。这就是数据孤岛(百科),也叫信息孤岛。“企业发展到一定阶段,出现多个事业部,每个事业部都有各自数据,事业部之间的数据往往都各自,各自定义。每个事业部的数据就像一个个孤岛一样无法(或者极其)和企业内部的其他数据进行连接互动。”我们把这样的情况称为数据孤岛。简单说就是数据

25、间缺乏关联性,数据库彼此无法兼 容。专业储,把数据孤岛分为物理性和逻辑性两种。物理性的数据孤岛指的是,数据在不同部门相互存维护,彼此间相互孤立,形成了物理上的孤岛。逻辑性的数据孤岛指的是,不同部门站在的角度对数据进行理解和定义,使得一些相同的数据被赋予了不同的含义,无形中加大了跨部门数据合作的成本。解决问题的方法只能是回归到数据仓库最初的基本建设原则上来。1998年,Inmon提出了新的BI架构CIF(CorporationInformation Factory,企业信息工厂),新架构在不同架构层次上采用不同的构件来满足不同的业务需求。2.4 数据仓库架构inmon架构kimball架构inm

26、on架构和kimball架构的区别就是inmon的数据仓库是三范式企业级数据仓库,kimball的数据库时企业级数据仓库。架构优缺点2.5 数仓架构演变史对应时间编年史数据仓库第一代架构(开发时间 2001-2002 年)海尔的一个 BI 项目,架构的 ETL 使用的是 微软的数据抽取知道有哪些弊端,后便给出了几个 DTS 的截图。工具 DTS,老人使用过微软的 DTS功能:进销存分析、闭环分析、工贸分析等硬件环境:业务系统数据库:DB2 for Windows,SQL SERVER2000,ORACLE8I数据库服务器:4EXON,2G,480GSCSI OLAP 服务器:2PIV1GHZ,

27、2G,240GSCSI开发环境:VISUAL BASIC,ASP,SQL SERVER 2000数据仓库第二代架构这是上海通用汽车的一个数据平台,别看复杂,严格意义上来讲这是一套 EDW 的架构、在 EDS 数据仓库中采用的是准三范式的建模方式去构建的、大约涉及到十几种数据源,建模中按照某一条主线把数据 都集成起来这个数据仓库平台计划三年的时间构建完毕,第一阶段计划构建统统一生性周期视图、客户统一视图的 数据,完成对数据质量的摸底与部分实施为业务分析与信息共享提供基础平台。第二阶段是完成主要业务数据集成与视图统一,初步实现企业绩效管理。第三阶段全面完善企业级数据仓库,实现 数据统一。业务的在第

28、一阶段数据仓库中的数据再次通过阶梯型高度聚合进入到数据集市 DM(非挖掘集市)中,完成对业务的支撑。数据的 ETL 采用 datastage 工具开发。数据集市架构这个是国内某析。的一套数据集市,这是一个典型数据集市的架构模式、面向客户经理部门的分数据仓库混合性架构 (Cif)这是太平洋保险的数据平台。该平台架构显然是一个混合型的数据仓库架构。它有混合数据仓库的经典结构,每一个层次功能定义的 非常明确。ODS 层 支撑单一的客户视图,是一个偏操作行的做唯一客户识别的,同时提供高可用户性客户主信息。EDW 层基于 IIW(IBM 的通用模型去整理与实施)最细粒度、原子、含历史的数据,也支持各业务

29、数据集市面向详细业务,采用雪花 / 星型模型去做设计的支撑 OLAP、Report、现方式。三 数据仓库案例。等数据展3.1 环境准备源系统是mysql库,数据模型如下建表语句如下:/*=*/* DBMS name:/* Created on:MySQL 5.02018/11/23 1:09:10*/*/*=*/CREATE DATABASE IF NOT EXISTS sales_source DEFAULT CHARSET utf8 COLLATEutf8_general_ci;USE sales_source;DROPTABLEIFEXISTScustomer;DROPTABLEIFEX

30、ISTSproduct;DROPTABLEIFEXISTSsales_order;/*=*/* Table: customer*/*=*/CREATE TABLE customer (customer_numbercustomer_nameINT(11) NOT NULL AUTO_INCREMENT,VARCHAR(128) NOT NULL,customer_street_address VARCHAR(256) NOT NULL,customer_zip_code customer_citycustomer_stateINT(11) NOT VARCHAR(32)VARCHAR(32)N

31、ULL,NOT NULL, NOT NULL,PRIMARY KEY (customer_number);/*=*/* Table: product*/*=*/CREATE TABLE product (product_code product_nameproduct_categoryINT(11) NOT NULL VARCHAR(128) NOTVARCHAR(256) NOTAUTO_INCREMENT, NULL,NULL,PRIMARY KEY (product_code);/*=*/* Table: sales_order*/*=*/CREATE TABLE sales_order

32、 (order_number customer_number product_code order_date entry_dateorder_amountINT(11)INT(11) INT(11)NOTNOT NOTNULL AUTO_INCREMENT, NULL,NULL,DATETIME NOT NULL, DATETIME NOT NULL,DECIMAL(18,2) NOT NULL,PRIMARY KEY (order_number);/*=*/* insert data*/*=*/INSERT INTO customer(,customer_name customer_stre

33、et_address customer_zip_code customer_citycustomer_state) VALUES('Big Customers', '7500 Louise Dr.', '17050','Mechanicsburg', 'PA'),( 'Small Stores', '2500 Woodland St.', '17055', 'Pittsburgh', 'PA')('Medium Retailer

34、s', '1111 Ritter Rd.', '17055','Pittsburgh', 'PA',),('Good Companies', '9500 Scott St.', '17050', 'Mechanicsburg', 'PA')('Wonderful Shops', '3333 Rossmoyne Rd.', '17050', 'Mechanicsburg', '

35、;PA')('Loyal Clients', '7070 Ritter Rd.', '17055','Pittsburgh', 'PA'),;INSERT INTO product(product_name,product_category) VALUES ('Hard Disk','Storage'),('Floppy Drive','Storage'),('lcd panel','monitor');DROP

36、 PROCEDURE IF EXISTS usp_generate_order_data; DELIMITER /CREATE PROCEDURE usp_generate_order_data()BEGINDROP TABLE IF EXISTS tmp_sales_order;CREATE TABLE tmp_sales_order AS SELECT * FROM sales_orderWHERE 1=0;SET SETSETstart_date := UNIX_TIMESTAMP('2020-1-1'); end_date := UNIX_TIMESTAMP('

37、2020-1-31');i := 1;WHILE i<=10000 DOSETSET SETcustomer_number := FLOOR(1+RAND()*6); product_code := FLOOR(1+RAND()* 3);order_date := FROM_UNIXTIME(start_date+RAND()*(end_date-start_date);SET amount := FLOOR(1000+RAND()*9000);INSERT INTO tmp_sales_order VALUES (i,customer_number,product_code,o

38、rder_date,order_date,amount);SET i := i +1; END WHILE;TRUNCATE TABLE sales_order; INSERT INTO sales_orderSELECT NULL,customer_number,product_code,order_date,entry_date,order_amount FROM tmp_sales_order;COMMIT;DROP TABLE tmp_sales_order; END /建完库后的表和数据如下3.2 数仓分层3.2.1 分层概念CALL usp_generate_order_data(

39、);数据仓库代表的是一种对数据的管理和使用的方式,它是一整套包括了etl、调度、建模在内的完整的理论体系流程。数据仓库在构建过程中通常都需要进行分层处理。业务不同,分层的技术处理 也不同。分层的主要:是在管理数据的时候,能对数据有一个更加清晰的掌控。详细来讲,主要有下面几个清晰数据结构每一个数据分层都有它的作用域,这样我们在使用表的时候能更方便地数据血缘追踪和理解。简单来说,我们最终给业务呈现的是一个能直接使用业务表,但是它的来源有很多,如果有一张来源表出问题了,我们希望能够快速准确地减少重复开发到问题,并清楚它的危害范围。规范数据分层,开发一些通用的中间层数据,能够减少极大的重复计算。把复杂

40、问题简单化将一个复杂的任务分解成多个步骤来完成,每一层只处理单一的步骤,比较简单和容易理解。而且 便于维护数据的准确性,当数据出现问题之后,可以不用修复所有的数据,只需要从有问题的步骤 开始修复。原始数据的异常业务的影响,不必改一次业务就需要重新接入数据3.2.2 分层的价值1.高效的数据组织形式【易维护】面向主题的特性决定了数据仓库拥有业务数据库所无法拥有的高效的数据组织形式,更加完 整的数据体系,清晰的数据分类和分层机制。因为所有数据在进入数据仓库之前都经过和过滤,使原始数据不再杂乱无章,基于优化分析的效率。时间价值【高性能】的组织形式,有效提高数据获取、统计和数据仓库的构建将大大缩短获取

41、信息的时间,数据仓库作为数据的集合,所有的信息都可以 从数据仓库直接获取,数据仓库的最大优势在于一旦底层从各类数据源到数据仓库的ETL流程构建成型,那么每天就会有来自各方面的信息通过自动任务调度的形式流入数据仓库,从而 使一切基于这些底层信息的数据获取的效率达到迅速提升。从应用来看,使用数据仓库可以大大提高数据的效率,尤其对于海量数据的关联和复杂,所以数据仓库有利于实现复杂的统计需求,提高数据统计的效率。集成价值【简单化】数据仓库是所有数据的集合,包括日志信息、数据库数据、文本数据、外部数据等都集成在数据仓库中,对于应用来说,实现各种不同数据的关联并使分析更加方便,为从多角度多层次地数据分析和

42、历史数据【历史性】提供的可能。历史是数据仓库的特性之一,数据仓库能够还原历史时间点上的状态、用户状态、用户行为等,以便于能更好的回溯历史,分析历史,跟踪用户的历史行为,更好地比较历史和总结历史,同时根据历史3.2.3 常见分层未来。数仓的常见分层一般为3层,分别为:数据操作层、数据仓库层和数据集市层。当然根据研发经验或者业务,可以分为不同的层,只要能达到流程清晰、方便查数即可。ODS:Operate data store,操作数据,是最接近数据源中数据的一层,数据源中的数据,经过抽取、洗净、传输,也就说类方式而分类的。中的ETL之后,装入本层。本层的数据,总体上大多是按照业务系统的分例如这一层

43、可能包含的数据表可为:人口表(包含每个人的号、姓名、住址等)、机场登机(包含乘机人号、航班号、乘机日期、起飞城市等)、银联的刷卡信息表(包含号、刷卡地点、刷卡时间、刷卡金额等)、账户表(包含号、持卡人号等)等等一系列原始的业务数据。这里我们可以看到,这一层面的数据还具有鲜明的业务数据库的特征,甚至还具有一定的关系数据库中的数据范式的组织形式。但是,这一层面的数据却全等同于原始数据。在源数据装入这一层时,根据业务不同,可能会进行诸如去噪(例如去掉明显偏离正常水平的刷卡信息)、去重(例如账户信息、局人口信息中均含有人的姓名,但是只保留一份即可)、提脏(例的人的刷,在十分钟内同时有统一、砍字段(例如

44、用于支撑前两笔分别在中国和的刷卡信息,这便是脏数据)、业务提取、端系统工作,但是在数据挖掘中不需要的字段)、业务判别等多项工作。ODS层数据的来源方式: 业务库经常会使用sqoop来抽取,比如我们每天定时抽取一次。在实时方面,可以考虑用canalmysql的binlog,实时接入即可。埋点日志线上系统会打入各种日志,这些日志一般以文件的形式保存,我们可以选择用ume定时抽取,也可以用用spark streaming或者storm来实时接入,当然,kafka也会是一个关键的其它数据源。不同的业务其它数据源不一样,比如第数据。DW:Data warehouse,数据仓库层。在这里,从ODS层中获得

45、的数据按照主题建立各种数据模型。例如以研究人的旅游消费为主题的数据集中,便可以结合航空公司的登机出行信息,以及银统的刷卡记录,进行结合分析,产生数据集。在这里,我们需要了解四个概念:维(dimension)、事实(Fact)、指标(Index)和粒度( Granularity)。DM:该层主要是提供数据和数据分析使用的数据,一般会存放在es、mysql等系统中供线上系统使用,也可能会存在Hive或者Druid中供数据分析和数据挖掘使用。 比如我们经常说的报表数据,或者说那种大宽表,一般就放在这里。注意:每个分层不是必须要用ODS、DW、DM等字样来标识,可以随便起名字,只要统一这一层是什么类型

46、 数据,名字符合知名知意即可。分层协作层次图分层协作案例3.2.4 维度层DIM存在度量值的表创建维度表,来从各个角度描述事实表。而一个项目中可能有很多张维度表,那 我们可以选择将这些维度表放到单独的一个库中,形成维度库,即可看成是维度层,意在让数仓数据清 晰明了。3.3 数仓开发规范1 数据库命名数据命名规则:数仓层_业务方式 如 ods_release/sda_release2 数仓各层对应数据库ods/sda层 -> sda/ods_业务(原始数据) dw层 -> dw_业务 (主题库)dim层 -> dim_维度 (维表库) dm层 -> dm_业务(集市库)

47、middle层 -> mid_业务(中间库)临时数据 -> temp(临时库)3 表命名(3-1) 数据库表命名规则:原始层表:数仓层_来源类型_业务 如 ods_01_其他表:数仓层_业务 如 dw_如果业务名称较长可以简写 如 ods_01_xx_xx ods_01_xx(3-2) 数据来源代码(sda层)01 -> hdfs数据3.4 数仓模型星型模式是维度模型最简单的形式,也是比较常用的模型,我们的案例采用星型模型。所谓星型模型就是以一个事实表为中心,周围星型模型将业务分为事实和维度。多个维度表。事实是业务数据的度量值,比如销售额、销售数量等,它了特定的量化指标,一般

48、是度量值和指向维表的外键组成。事实表的粒度级别通常会设计的比较低。事实表有三种类型:事务事实表:最低粒度级别的事实表,原始的操作型.快照事实表:累积事实表:给定时间点的事实,如月底账户余额给定时间点的聚合事实,如当月的销售金额.维度是对事实数据属性的描述,如日期,省份,地区等,维度表的数据量通常不大。常用的维度表有:日期维度表,每个数据仓库都需要一个日期维度表。地理维度表:描述位置信息的数据,如,省份,城市,区县,等维度表:描述维度表:描述及其属性相关信息,部门员工表等范围维度表:描述分段数据的信息等,比如信用等级3.5 项目物理模型02 -> mysql数据03 -> redis

49、数据04 -> mongodb数据05 -> tidb数据如ods_release.ods_01_release 投放数据ods_release.ods_02_user用户表(业务表:存于MYSQL)dw_release.dw_customer 目标客户主题表dm_release.dm_customer_stat 目标客户统计表3.6 建库、装载数据连接hive创建rds库创建表,如下create database sales_rds;/*=*/* Table: customer*/*=*/CREATE TABLE sales_rds.customer (customer_numb

50、ercustomer_nameINT ,VARCHAR(128) ,customer_street_address VARCHAR(256) ,customer_zip_code customer_citycustomer_stateINT , VARCHAR(32) ,VARCHAR(32);/*=*/* Table: product*/*=*/CREATE TABLE sales_duct (product_code product_nameproduct_categoryINT, VARCHAR(128) ,VARCHAR(256);/*=*/* Table: sales_

51、order*/*=*/CREATE TABLE sales_rds.sales_order (order_number customer_number product_code order_date entry_dateorder_amountINT , INT, INT ,timestamp , timestamp ,DECIMAL(18,2)row format delimitedfields terminated by 't'create database if not exists dw;use dw;create table dim_Product (product_sk product_code product_name product_category version effective_date expiry_date)int, int ,varchar(128), varchar(256), varchar(32), date,dateclus

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论