🌷大家好久不见了,最近实习比较忙,但也在实习过程中发现了自己的不足,今天我们就来讲一讲数据仓库的建设(大厂数据开发实习)有很完整的数仓体系,所以这方面的知识是需要进行系统学习的。有必要说明,本文是在流行的大数据分布式存储和计算平台Hadoop上设计实现数据仓库。
数据仓库的概念可以追溯到20世纪80年代,当时IBM的研究人员开发出了“商业数据仓库”。本质上,数据仓库试图提供一种从操作型系统到决策支持环境的数据流架构模型。数据仓库概念的提出,是为了解决和这个数据流相关的各种问题,主要是解决多重数据复制带来的高成本问题。在没有数据仓库的时代,需要大量的冗余数据来支撑多个决策支持环境。在大组织里,多个决策支持环境独立运作是典型的情况。尽管每个环境服务于不同的用户,但这些环境经常需要大量相同的数据。处理过程收集、清洗、整合来自多个数据源的数据,并为每个决策支持环境做部分数据复制。数据源通常是早已存在的操作型系统,很多是遗留系统。此外,当一个新的决策支持环境形成时,操作型系统的数据经常被再次复用。用户访问这些处理后的数据。
数据仓库之父Bill Inmon在1991年出版的Building the Data Warehouse 一书中首次提出了被广为认可的数据仓库定义。Inmon将数据仓库描述为一个面向主题的、集成的、随时间变化的、非易失的数据集合,用于支持管理者的决策过程。特点如下:
传统的操作型系统是围绕组织的功能性应用进行组织的,而数据仓库是面向主题的。主题是一个抽象概念,简单地说就是与业务相关的数据的类别,每一个主题基本对应一个宏观的分析领域。数据仓库被设计成辅助人们分析数据。例如,一个公司要分析销售数据,就可以建立一个专注于销售的数据仓库,使用这个数据仓库,就可以回答类似于“去年谁是我们这款产品的最佳用户”这样的问题。这个场景下的销售,就是一个数据主题,而这种通过划分主题定义数据仓库的能力,就使得数据仓库是面向主题的。主题域是对某个主题进行分析后确定的主题的边界,如客户、销售、产品都是主题域的例子。
集成的概念与面向主题是密切相关的。还用销售的例子,假设公司有多条产品线和多种产品销售渠道,而每个产品线都有自己独立的销售数据库。此时要想从公司层面整体分析销售数据,必须将多个分散的数据源统一成一致的、无歧义的数据格式后,再放置到数据仓库中。因此数据仓库必须能够解决诸如产品命名冲突、计量单位不一致等问题。当完成了这些数据整合工作后,该数据仓库就可称为是集成的。
为了发现业务变化的趋势、存在的问题,或者新的机会,需要分析大量的历史数据。这与联机事务处理(OLTP)系统形成鲜明的对比。联机事务处理反应的是当前时间点的数据情况,要求高性能、高并发和极短的响应时间,出于这样的需求考虑,联机事务处理系统中一般都将数据依照活跃程度分级,把历史数据迁移到归档数据库中。而数据仓库关注的是数据随时间变化的情况,并且能反映在过去某个时间点的数据是怎样的。换句话说,数据仓库中的数据是反映了某一历史时间点的数据快照,这也就是术语“随时间变化”的含义。当然,任何一个存储结构都不可能无限扩展,数据也不可能只入不出地永久驻留在数据仓库中,它在数据仓库中也有自己的生命周期。到了一定时候,数据会从数据仓库中移除。移除的方式可能是将细节数据汇总后删除、将老的数据转储到大容量介质后删除和直接物理删除等。
非易失指的是,一旦进入到数据仓库中,数据就不应该再有改变。操作型环境中的数据一般都会频繁更新,而在数据仓库环境中一般并不进行数据更新。当改变的操作型数据进入数据仓库时会产生新的记录,这样就保留了数据变化的历史轨迹。也就是说,数据仓库中的数据基本是静态的。这是一个不难理解的逻辑概念。数据仓库的目的就是要根据曾经发生的事件进行分析,如果数据是可修改的,将使历史分析变得没有意义。
除了以上四个特性外,数据仓库还有一个非常重要的概念就是粒度。粒度问题遍布于数据仓库体系结构的各个部分。粒度是指数据的细节或汇总程度,细节程度越高,粒度级别越低。例如,单个事务是低粒度级别,而全部一个月事务的汇总就是高粒度级别。大多数情况下,数据会以很低的粒度级别进入数据仓库,如日志类型的数据或单击流数据,此时应该对数据进行编辑、过滤和汇总,使其适应数据仓库环境的粒度级别。如果得到的数据粒度级别比数据仓库的高,那将意味着在数据存入数据仓库前,开发人员必须花费大量设计和资源来对数据进行拆分。
数仓的数据来源自各个业务应用系统。业务系统中的数据形式多种多样,可能是Oracle、MySQL、SQL Server等关系数据库里的结构化数据,可能是文本、CSV等平面文件或Word、Excel文档中的非结构化数据,还可能是HTML、XML等自描述的半结构化数据。这些业务数据经过一系列的==数据抽取、转换、清洗(ETL操作)==最终以一种统一的格式装载进数据仓库。数据仓库里的数据作为分析用的数据源,提供给后面的即席查询、分析系统、数据集市、报表系统、数据挖掘系统等。
到这里有人就会问,我们数仓的数据本来就来源于业务,为什么不能直接拿业务中的数据直接分析,而需要使用数据仓库呢?这是一个很好的问题,我举一些例子大家就知道了:
尽管需要增加软硬件的投入,但建立独立数据仓库与直接访问业务数据相比,无论是成本还是带来的好处,这样做都是值得的。随着处理器和存储成本的逐年降低,数据仓库方案的优势更加明显,在经济上也更具可行性。(这里说明一下,不知道一些数据量不大的公司有没有数据仓库,或者说实现的方式和标准的数仓有没有差异,但一些大型的互联网企业肯定是有自己的数据仓库)
在数据仓库技术演化过程中,产生了几种主要的架构方法,包括数据集市架构、Inmon企业信息工厂架构、Kimball数据仓库架构和混合型数据仓库架构。
数据集市是按主题域组织的数据集合,用于支持部门级的决策。有两种类型的数据集市:独立数据集市和从属数据集市。
独立数据集市集中于部门所关心的单一主题域,数据以部门为基础部署,无须考虑企业级别的信息共享与集成。例如,制造部门、人力资源部门和其他部门都各自有他们自己的数据集市。独立数据集市从一个主题域或一个部门的多个事务系统获取数据,用以支持特定部门的业务分析需要。一个独立数据集市的设计既可以使用实体关系模型,也可以使用多维模型。数据分析或商业智能工具直接从数据集市查询数据,并将查询结果显示给用户。特点是: 因为一个部门的业务相对于整个企业要简单,数据量也小得多,所以部门的独立数据集市具有周期短、见效快的特点。如果从企业整体的视角来观察这些数据集市,你会看到每个部门使用不同的技术,建立不同的ETL的过程,处理不同的事务系统,而在多个独立的数据集市之间还会存在数据的交叉与重叠,甚至会有数据不一致的情况。从业务角度看,当部门的分析需求扩展,或者需要分析跨部门或跨主题域的数据时,独立数据市场会显得力不从心。
从属数据集市的数据来源于数据仓库。数据仓库里的数据经过整合、重构、汇总后传递给从属数据集市。主要有以下特点: 1.性能:当数据仓库的查询性能出现问题,可以考虑建立几个从属数据集市,将查询从数据仓库移出到数据集市。2.安全:每个部门可以完全控制他们自己的数据。3.数据一致:因为每个数据集市的数据来源都是同一个数据仓库,有效消除了数据不一致的情况。
Kimball与Inmon两种架构的主要区别在于核心数据仓库的设计和建立。Kimball的数据仓库包含高粒度的企业数据,使用多维模型设计,这也意味着数据仓库由星型模式的维度表和事实表构成。分析系统或报表工具可以直接访问多维数据仓库里的数据。在此架构中的数据集市也与Inmon中的不同。这里的数据集市是一个逻辑概念,只是多维数据仓库中的主题域划分,并没有自己的物理存储,也可以说是虚拟的数据集市。
所谓的混合型结构,指的是在一个数据仓库环境中,联合使用Inmon和Kimball两种架构。从架构图可以看到,这种架构将Inmon方法中的数据集市部分替换成了一个多维数据仓库,而数据集市则是多维数据仓库上的逻辑视图。使用这种架构的好处是,既可以利用规范化设计消除数据冗余,保证数据的粒度足够细;又可以利用多维结构更灵活地在企业级实现报表和分析。
给大家看看某大型公司的数仓建设流程图:红框的是数仓的核心
和大家简单介绍一下这几个部分吧:
《大数据之路 某某公司大数据平台建设》
《hadoop构建数据仓库》
版权说明 : 本文为转载文章, 版权归原作者所有 版权申明
原文链接 : https://blog.csdn.net/weixin_48077303/article/details/118629232
内容来源于网络,如有侵权,请联系作者删除!