关于数仓基础知识的超全概括
编辑导语:数据仓库,是为企业所有级别的决策制定过程,提供所有类型数据支持的战略集合,它可以为需要业务智能的企业,提供指导业务流程改进、监视时间、成本、质量以及控制。在本篇文章中,作者就关于数仓的基础知识进行了超全概括。
面对大数据的多样性,在存储和处理这些大数据时,我们就必须要知道两个重要的技术,其分别是:数据仓库技术、Hadoop。当数据为结构化数据,来自传统的数据源,则采用数据仓库技术来存储和处理这些数据,如下图:
1. 什么是数据仓库
数据仓库之父 Bill Inmon 将数据仓库描述为一个面向主题的、集成的、随时间变化的、非易失的数据集合,用于支持管理者的决策过程。
数据仓库的目的是构建面向分析的集成化数据环境,为企业提供决策支持。
数据仓库本身并不 “生产” 任何数据;同时自身也不需要 “消费” 任何的数据,数据来源于外部,并且开放给外部应用,这也是为什么叫 “仓库” ,而不叫 “工厂” 的原因。
2. 数据仓库的基本概念
2.1 数据源
构建一个数据仓库,必然要有充足的数据源,从外部为数据仓库系统提供进行分析的 “原材料” ——数据,这些数据来源称为数据仓库的数据源。
数据源并不局限于传统数据库,可以是非结构化的信息,如爬取日志,也可以是埋点日志。
2.2 ETL
在 BI 项目中 ETL 会花掉整个项目至少 1/3 的时间,ETL 设计的好坏直接关系到 BI 项目的成败。其中,花费时间最长的是 “T”(Transform,清洗、转换)的部分,一般情况下这部分工作量是整个 ETL 的 2/3 。
ETL 是将业务系统中的数据经过抽取(Extract)、清洗转换(Transform)和加载(Load)到数据仓库的过程,目的是将企业中的分散、凌乱、标准不统一的数据整合到一起,为企业的决策提供分析依据。
ETL 处理分为五大模块,分别是:数据抽取、数据清洗、数据转换、规则检查、数据装载。各模块之间灵活组合,形成 ETL 处理流程。下面简单介绍一下各模块之间的功能。
2.2.1 数据抽取
在构建数据仓库过程中,数据源所提供的数据并不都是有用的,有些数据对决策并不能提供支持。
同时,外部数据源中数据冗余的现象也很普遍。数据仓库既然是面向主题的,那么在数据源中,只有那些与主题相关的内容才是必需的、有使用价值的。
因此,必须以主题的需求为依据,对数据源的内容进行有目的地选择,这一过程被称为“数据抽取”(Data Extraction)。对于数据的抽取,是从各个不同的数据源抽取到 ODS(Operational Data Store,操作型数据存储)中。
具体步骤为,首先要搞清楚数据是从哪几个业务系统中来,各个业务系统的数据库服务器运行什么 DBMS ,是否存在非结构化的数据等,当收集完这些信息后才可以进行数据抽取的设计。
1)对于与存放 DW 的数据库系统相同的数据源处理方法
这类数据源在设计上比较容易处理。一般情况下,DBMS(Mysql、SQLServer)都会提供数据库连接功能,在 DW 数据库服务器和原业务系统之间建立直接的连接关系,接下来就可以写查询语句直接访问。
2)对于与存放 DW 的数据库系统不同的数据源处理方法
对于这类数据源,一般情况下也可以通过 ODBC 的方式建立数据库连接。如果不能建立数据库连接,可以用两种方法完成,一种是通过工具将数据源导出成 .txt 或者 .xls 文件,然后再将这些源系统文件导入到 ODS 中。另一种方法是通过程序接口来完成。
3)对于文件类型数据源(.txt/.xls)
业务人员可以利用数据库工具将这些数据导入到指定的数据库,然后从指定的数据库中抽取。或者业务人员借助工具实现。
4)增量更新问题
对于数据量大的系统,必须考虑增量抽取。
一般情况,业务系统会记录业务发生的时间,可以用作增量的标志,每次抽取之前首先判断 ODS 中记录最大的时间,然后根据这个时间去业务系统取大于这个时间的所有记录。
2.2.2 数据清洗转换
一般情况下,数据仓库分为 ODS、DW 两部分。通过的做法是从业务系统到 ODS 做清洗,将脏数据和不完整数据过滤掉,再从 ODS 到 DW 的过程中转换,进行一些业务规则的计算和聚合。
1)数据清洗
数据仓库的数据源所提供的数据内容并不完美,存在着 “脏数据” ——即数据有缺省值、异常值等缺陷,而且在数据仓库的各数据源之间,其内容也存在着不一致的现象。
为了控制这些 “脏数据” 对数据仓库分析结果的影响程度,必须采取各种有效的措施,对其进行处理,这一处理过程称为 “数据清洗”(Data Transform)。
对于任何数据仓库而言,数据清洗过程都是不可缺少的。不同类型的 “脏数据” ,清洗处理的方法是不同的。
对于缺省值:产生的原因可能是,信息暂时无法获取、信息被遗漏、属性值不存在,比如一个儿童的固定收入等。
解决方法是,通过简单的统计分析,得到含有缺失值的属性个数,以及每个属性的未缺失数、缺失数和缺失率。删除含有缺失值的记录、对可能值进行插补和不处理三种情况。
对于异常值:产生的原因可能是:业务系统检查不充分。解决方法是,先对变量做一个描述性统计,进而查看哪些数据是不合理的。最常用的统计量是最大值和最小值,然后判断变量是否超过了合理的范围。
如果数据是符合正态分布,在原则下,异常值被定义为一组测定值中与平均值的偏差超过 3 倍标准的值,如果不符合正态分布,也可以用原理平均值的多少倍标准差来描述。
对于不一致值:产生的原因可能是:被挖掘的数据是来自不同的数据源、对于重复性存放的数据未能进行一致性更新造成。
例如:两张表中都存储了用户电话号码,但在用户的号码发生改变时只更新了一张表中的数据,那么两张表中就有了不一致的数据。
解决办法是,注意数据抽取的规则,对于业务数据变动的控制应该保证数据仓库中数据抽取是最新数据。
数据清洗是一个反复的过程,不可能在几天内完成,只有不断的发现问题,解决问题。
对于是否过滤、是否修正一般要求客户确认;对于过滤掉的数据,写入 Excel 文件或者将过滤数据写入数据表,在 ETL 开发的初期可以每天向业务单位发送过来数据的邮件,促使他们尽快的修正错误,同时也可以作为将来验证数据的依据。
数据清洗需要注意的是不要将有用的数据过滤掉了,对于每个过滤规则认真进行验证,并要用户确认才行。
2) 数据转换
数据转换的任务主要是进行不一致的数据转换、数据粒度的转换和一些商务规则的计算等。
- 不一致的数据转换:这个过程是一个整合的过程,将不同业务系统的相同类型的数据统一,比如同一个用户在用户管理系统的编码是 XX0001 ,而在订单系统的编码是 YY0001 ,这样在抽取过来之后统一转换成一个编码;
- 数据粒度的转换:业务系统一般存储粒度较小的数据,而数据仓库中的数据是用来分析的,不需要粒度很小的数据,一般情况下,会将业务系统数据按照数据仓库粒度进行聚合;
- 商务规则的计算:不同的企业有不同的业务规则,不同的数据指标,这些指标有时候不能简单的加加减减就能完成,这个时候需要在 ETL 中将这些数据指标计算好了之后存储在数据仓库中,供分析使用。
2.3 元数据
所谓 “元数据”(Meta Data),就是关于数据仓库中数据的数据。
它是关于数据仓库中数据、操作数据以及应用程序的结构和意义的描述信息。它的作用类似于数据库管理系统的数据字典,保存了逻辑数据结构、文件、地址和索引等信息。
广义上讲,在数据仓库中,元数据描述了数据仓库内数据的结构和建立方法的数据。
元数据是整个数据仓库的核心部件,元数据管理器是企业级数据仓库中的关键部件,贯穿数据仓库构建的整个过程,直接影响着数据仓库的构建、使用和维护。
将数据仓库功能区域包括数据获取、数据存储和信息传递三个部分,按照这三个功能区域可以相应地将元数据分为数据获取区域元数据、数据存储区域元数据和信息传递区域元数据。
2.3.1 数据获取区域元数据
在这个区域中,数据仓库的处理过程主要包括数据抽取、数据转换、数据清洗、数据集成、数据准备五项功能。
这些处理过程是通过相应的工具完成的,在这些处理过程进行时,相应的工具就记录下了与这些处理相关的元数据。在以后的数据仓库维护和管理过程中,技术人员也将使用这些已记录下来的元数据管理和监控正在运行的功能。
2.3.2 数据存储区域元数据
在这个区域中,数据仓库的处理过程主要包括数据装载、数据存储、数据管理三项功能。
这些处理过程同样是通过相应的工具完成的,在这些处理过程进行时,相应的工具就记录下了与这些处理相关的元数据。
数据仓库的管理员在进行完全数据刷新和数据增量装载中会用到这些元数据;在数据备份、恢复的处理中,以及对数据仓库的清理和数据定期归档中也需要用到这些元数据。对用户来说,也有可能用到这些元数据。
2.3.3 信息传递区域元数据
在这个区域中,数据仓库的处理过程主要包括报表生成、查询处理、复杂分析三项功能。
信息传递区域的处理过程主要是为最终用户服务的,所记录的元数据为用户提供预定义查询和预定义报表解疑,定义了用户查询和报表生成需要输入的相关参数,也包括与 OLAP 相关的元数据,系统的开发者和管理员都会参加这个区域的处理过程。
在该区域中,当用户在查询处理工具的辅助下构建一条查询时,也会引用数据获取区域和数据存储区域中记录的元数据。
元数据定义了数据仓库中的数据的模式、来源、抽取和转换规则等,而且是整个数据仓库系统运行的基础,元数据把数据仓库系统中各个松散的组件联系起来,组成了一个有机的整体。
2.4 数据集市
数据集市(Data Market,DM)是为企业特定部门的决策支持而组织起来的一批数据和业务规划。
它是一种小型的、部门级数据仓库,习惯上称之为 “主题域” ,企业的不同部门有不同的 “主题域” ,因而就有不同的数据集市。
数据集市有两种类型:独立型数据集市(Independent Data Mart)和从属型数据集市(Dependent Data Mart)。
独立型数据集市的实质,是为了满足企业内各部门的分析需求而建立的微型数据仓库。
有些企业在实施数据仓库项目时,为了节省投资,尽快见效,针对不同部门的需要,分布建立起这类数据集市,已解决一些较为迫切的问题。
但是,当多个独立的数据集市增长到一定规模后,由于没有统一的数据仓库协调,企业只会又增长出一些新的信息孤岛,仍然不能以整个企业的视角来分析数据。
从属型数据集市的内容并不直接来自外部数据源,而是从数据仓库中得到。在数据仓库内部,数据根据分析主题,划分成若干个子集,进行组织、存放。
这种面向某个具体的主题而在逻辑上或物理上进行划分所形成的数据子集,就是从属型数据集市。数据划分成集市之后,在进行某个确定主题的分析时,可以有效缩小数据的检索范围,明显提高工作效率。
3. 数据仓库的四个基本特征
3.1 面向主题
传统的操作型系统是围绕组织的功能性应用进行组织的,而数据仓库是面向主题的。
主题是一个抽象概念,简单地说就是与业务相关的数据的类别,每一个主题基本对应一个宏观的分析领域。数据仓库被设计成辅助人们分析数据。
比如,一个公司要分析销售数据,就可以建立一个专注于销售的数据仓库,使用这个数据仓库,就可以回答类似于 “上一季度谁是我们这款产品的最佳用户” 这样的问题。
这个场景下的销售,就是一个数据主题,而这种通过划分主题定义数据仓库的能力,就使得数据仓库是面向主题的。
主题域是对某个主题进行分析后确定的主题的边界,如客户、销售、产品都是主题域的例子。
3.2 集成
数据仓库的一个重要的功能,是把不同的数据源的数据汇总到一起(如上图)。
而集成是指把不同类型的数据源的数据进行整合,按照统一的形式进行集成。比如性别在一个数据源用男/女,另一个数据源用1/2,那么在数据仓库中,就需要对其进行统一。
3.3 非易失
传统的操作型环境中的数据一般是要周期性地更新的,且一般按一次一条记录的方式进行。但数据仓库中的数据通常以批量方式载入与访问(如上图),但在数据仓库环境中并不进行数据更新。
数据仓库中的数据在进行装载时是以静态快照的格式进行的。当产生后继变化时,一个新的快照记录就会写入数据仓库。这样,在数据仓库中就保存了数据的历史状况。
3.4 时变性
时变性指的是数据仓库中的每个数据单元只在某一时间是准确的,在一些情况下,记录中加有时间戳,而在另外一些情况下记录则包含一个事务的时间。
总之,任何情况下,记录都包含某种形式的时间标志用以说明数据在哪一时间是准确的。
除了以上四个特性外,数据仓库还有一个非常重要的概念就是粒度,粒度问题遍布于数据仓库体系结构的各个部分。粒度是指数据的细节或汇总程度,细节程度越高,粒度级别越低。
比如:单个事务是低粒度级别,而全部一个月事务的汇总就是高粒度级别(如下图)。
粒度之所以是数据仓库环境的关键设计问题,是因为它极大地影响数据仓库的数据量和可以进行的查询类型。粒度级别越低,数据量越大,查询的细节程度越高,查询范围越广泛,反之依然。
4. 数据库和数据仓库的区别
数据仓库是在传统数据库的基础之上发展起来的,但它并不是对传统数据库的彻底抛弃,而是旨在弥补传统数据库在数据分析能力方面的不足,以提供良好的大规模数据分析能力为己任,力图为决策提供有效的技术支持。
和传统数据库相比,数据仓库在总体特征、面向用户、存储内容等方面,都有着重大的差异(如下表)。
数据仓库是在数据库已经大量存在的情况下,为了进一步挖掘数据资源、为了决策需要而产生的,它绝不是所谓的“大型数据库”。
数据仓库的出现,并不是要取代数据库。目前,大部分数据仓库还是用关系数据库管理系统来管理的。可以说,数据库、数据仓库相辅相成、各有千秋。
本文由 @汪仔4623 原创发布于人人都是产品经理,未经许可,禁止转载
题图来自 Unsplash,基于 CC0 协议
关于数仓的数据源写的也比较狭隘,万物皆可数据,爬虫,埋点,采集,人工收集的数据都可以称为数仓的数据源。阿里云dataworks是国内典型的数仓产品,它可以读取主流的数据库从而获取数据,他同时也可以通过excel直接导入数据进行分析。另外关于数仓模型也是比较老的版本,但是大体没问题,新型的数仓包含除了文中所说的原始数据层ODS与数据应用层ADM,还包含中间层CDM–主题宽表(明细整合层DWD与高粒度汇总层DWS)
整片文章写的很好,但是对数仓的理解有误。对数据库和数据仓库的区分理解有误。可以先了解一下hadoop生态产生的原因再去理解数据仓库和数据库。数仓最早在世界范围内大型互联网公司产生,原因很简单,因为他们起步早,体量大,积累了大量的数据(可以用PB,ZB)计算,这些大量的数据是传统的数据库无法存储与处理的。因此这个时候为了解决千台甚至更多的计算机集群之间的数据存储与计算问题,数仓模型产生了,hadoop生态则是为大数据存储计算而生。可以想一下,一个初创互联网公司,与一个创办20年的互联网巨头哪个更需要DW?答案显而易见。
很不错!