《Hadoop构建数据仓库实践》
Posted 宫享天地
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了《Hadoop构建数据仓库实践》相关的知识,希望对你有一定的参考价值。
王雪迎 著
前言
似乎所有人嘴边都挂着“大数据”这个词,已经完全压倒了传统数据仓库的风头。某些大数据狂热者甚至大胆预测,在不久的将来,所有企业数据都将由一个基于Hadoop的系统托管,企业数据仓库(EDW)终将消亡。
无论如何,传统数据仓库架构仍在不断发展演化,这一点不容置疑,但它真的会消亡吗?我认为几率很小。
实际上,尽管某种技术或者架构可能会胜过另一种技术或架构,IBM有着不同的观点,他们更倾向于从“Hadoop与数据仓库密切结合”这个角度来探讨问题,两者可以说是天作之合。
宫:之前我也觉得Hadoop必将很快取代传统数仓,但通过近几年在明略的实践,发现“替代成本”这个公式确实无法绕开,参见《》:
上一次有个老师给我们讲过产品经理的一个重要的公式,产品价值 = 新体验 - 旧体验 - 替代成本,这个公式是写得非常深刻。
◄Hadoop生态圈与数据仓库►
传统数据仓库一般建立在Oracle这样的关系数据库系统之上。关系数据库主要的问题是不好扩展,面对当前4Vs的大数据问题时显得能力不足,而这时就显示出Hadoop的威力。
在大多数情况下,Hadoop生态圈的工具能够比关系数据库处理更多的数据,因为数据和计算都是分布式的。
Hadoop数据仓库工具
当数据仓库应用的规模和数据量大到一定程度,关系数据库已经不再适用,此时Hadoop是开发数据仓库项目的可选方案之一。
一个常规数据仓库由2类存储和6个主要功能模块组成,下面我们就介绍与这8个部分对应的Hadoop相关组件或产品。
1.RDS和TDS
RDS是原始数据存储,其数据是从操作型系统抽取而来。
它有两个作用:
一是充当操作型系统和数据仓库之间的过渡区;
二是作为细节数据查询的数据源。
TDS是转换后的数据存储,也就是数据仓库,用于后续的多维分析或即席查询。
这两类数据逻辑上分开,物理上可以通过在Hive上建立两个不同的数据库来实现,最终所有数据都被分布存储到HDFS上。
2.抽取过程
这里的抽取过程指的是把数据从操作型数据源抽取到RDS的过程,这个过程可能会有一些数据集成的操作,但不会做数据转换、清洗、格式化等工作。
Hadoop生态圈中的主要数据摄取工具是Sqoop和Flume。
Sqoop被设计成支持在关系数据库和Hadoop之间传输数据。
而Flume被设计成基于流的数据捕获,主要是从日志文件中获取数据。
使用这两个工具可以完成数据仓库的抽取。
如果数据源是普通的文本和CSV文件,抽取过程将更加简单,只需用操作系统的scp或ftp命令将文件拉取到Hadoop集群的任一节点,然后使用HDFS的put命令将已在本地的文件上传到HDFS,或者使用Hive的load data将文件装载进表里就可以了。
3.转换与装载过程
转换与装载过程是将数据从RDS迁移到TDS的过程,期间会对数据进行一系列的转换和处理。经过了数据抽取步骤,此时数据已经在Hive表中了,因此Hive可以用于转换和装载。
Hive实际上是在MapReduce之上封装了一层SQL解释器,这样可以用类SQL语言书写复杂的MapReduce作业。Hive不但提供了丰富的数据查询功能和分析函数,还可以在某些限制下进行数据的行级更新,因此支持SCD1(渐变维的一种处理类型)。
4.过程管理和自动化调度
ETL过程自动化是数据仓库成功的重要衡量标准,也是系统易用性的关键。
Hadoop生态圈中的主要管理工具是Falcon。Falcon把自己看作是数据治理工具,能让用户建立定义好的ETL流水线。除Falcon外,还有一个叫做Oozie的工具,它是一个Hadoop的工作流调度系统,可以使用它将ETL过程封装进工作流自动执行。
5.数据目录
数据目录存储的是数据仓库的元数据,主要是描述数据属性的信息,用来支持如指示存储位置、历史数据、资源查找、文件记录等功能。
Hadoop生态圈中主要的数据目录工具是HCatalog。
HCatalog是Hadoop上的一个表和存储管理层。使用不同数据处理工具(如Pig、MapReduce)的用户,通过HCatalog可以更加容易地读写集群中的数据。HCatalog的抽象,把文件看做数据集。它展现给用户的是一个HDFS上数据的关系视图,这样用户不必关心数据存放在哪里或者数据格式是什么等问题,就可以轻松知道系统中有哪些表,表中都包含什么。
6.查询引擎和SQL层
查询引擎和SQL层主要的职责是查询和分析数据仓库里的数据。由于最终用户经常需要进行交互式的即席查询,并随时动态改变和组合他们的查询条件,因此要求查询引擎具有很高的查询性能和较短的响应时间。
Hadoop生态圈中的主要SQL查询引擎有基于MapReduce的Hive、基于RDD的SparkSQL和Cloudera公司的Impala。
Hive可以在四种主流计算框架的三种,分别是Tez、MapReduce和Spark(还有一种是Storm)上执行类SQL查询。
SparkSQL是Hadoop中另一个著名的SQL引擎,它实际上是一个Scala程序语言的子集。正如SparkSQL这个名字所暗示的,它以Spark作为底层计算框架。
Impala是Cloudera公司的查询系统,它提供SQL语义,最大特点是速度快,主要用于OLAP。
除此之外,还有一款名为Kylin的OLAP系统,它是首个中国团队开发的Apache顶级项目,其查询性能表现优异。
7.用户界面
数据分析的结果最终要以业务语言和形象化的方式展现给用户,只有这样才能取得用户对数据仓库的认可和信任。因此具有良好体验的用户界面是必不可少的。数据仓库的最终用户界面通常是一个BI仪表盘或类似的一个数据可视化工具提供的浏览器页面。
Hadoop生态圈中比较知名的数据可视化工具是Hue和Zeppelin。
Hue是一个开源的Hadoop UI系统,最早是由Cloudera Desktop演化而来,它是基于Python Web框架Django实现的。通过使用Hue我们可以在浏览器端的Web控制台上与Hadoop集群进行交互来分析处理数据,还可以用图形化的方式定义工作流。
Zeppelin提供了Web版的notebook,用于做数据分析和可视化。
可以看到,普通数据仓库的8个组成部分都有相对应的Hadoop组件作为支撑。Hadoop生态圈中众多工具提供的功能,完全可以满足创建传统数据仓库的需要。
◄Kettle与Hadoop►
在一个数据仓库项目中,开发阶段最关键的是ETL过程。大致有三种ETL的实现途径:
使用ETL工具
使用特定数据库的SQL
使用程序语言开发自己的ETL应用。
Kettle概述
Kettle的设计原则之一,就是尽量减少编程,几乎所有工作都可以通过简单拖曳来完成。它通过工作流和数据转换两种不同的模式进行数据操作,分别被称为作业和转换。
一个Kettle转换由若干步骤组成,这些步骤并行执行,以一种数据流的方式操作数据列。数据列通常从一个系统流入,经过Kettle引擎的转换形成新的数据列,转换过程中可以对流入的数据列进行计算和筛选,还可以向数据流中加入新的列。流出的数据被发送到一个接收系统,如Hadoop集群、数据库或Pentaho的报表引擎等。
◄数据抽取►
本章介绍如何利用Hadoop提供的工具实现数据仓库中的数据抽取,即ETL过程中的Extract部分。
业务系统可能同时使用多种数据库系统,这些系统在物理上彼此独立,在逻辑上又互相联系。如果能够在一种数据库中访问其他数据库,将会给数据集成带来极大的便利。这种情况下就会用到本章介绍的分布式查询技术。Hadoop生态圈中的Sqoop工具可以直接在关系数据库和HDFS或Hive之间互导数据。
逻辑数据映射
设计ETL过程的首要步骤是建立一个有效的逻辑数据映射。逻辑数据映射有时也叫做血统报告,是整个ETL过程实现的基础。
简单说逻辑数据映射就是指源系统中的对象和目标数据仓库中的对象之间的对应关系,通常用一个表或者电子表格的形式来表示。
一般按如下步骤建立逻辑数据映射。
(1)识别数据源。
(2)收集源系统文档。
(3)建立源系统跟踪报告。
(4)建立目标数据仓库实体关系图。
(5)建立模型映射。
(6)建立属性映射。
数据抽取方式
从源抽取数据导入数据仓库或过渡区有两种方式,可以从源把数据抓取出来(拉),也可以请求源把数据发送(推)到数据仓库。
影响选择数据抽取方式的一个重要因素是操作型系统的可用性和数据量,这是抽取整个数据还是仅仅抽取变化数据的基础。我们考虑以下两个问题:
需要抽取哪部分源数据加载到数据仓库?
有两种可选方式,完全抽取和变化数据捕获。数据抽取的方向是什么?
有两种方式,拉模式,即数据仓库主动去源系统拉取数据;推模式,由源系统将自己的数据推送给数据仓库。
变化数据捕获
如果源数据量很大,抽取全部数据是不可行的,那么只能抽取变化的源数据,即最后一次抽取以来发生了变化的数据。这种数据抽取模式称为变化数据捕获,简称CDC。
CDC大体可以分为两种,一种是侵入式的,另一种是非侵入式的。
所谓侵入式的是指CDC操作会给源系统带来性能的影响。只要CDC操作以任何一种方式对源库执行了SQL语句,就可以认为是侵入式的CDC。
常用的四种CDC方法是:
基于时间戳的CDC
基于触发器的CDC
基于快照的CDC
基于日志的CDC
其中前三种是侵入性的。
导出成文本文件
要回答如何抽取数据的问题,最直接的想法是,ETL系统直连源数据库,然后编写应用程序或者使用某种工具,如第5章介绍的Kettle,或后面即将介绍的Sqoop等,将数据抽取到HDFS或Hive表中。
这种方法的一个主要好处是可以有效利用工具本身提供的特性,提高ETL的性能。比如Kettle可以多线程执行一个步骤,并且多个步骤也是以数据流的方式并行执行的,这种方式会大大加快数据操作执行的速度,其效果用SQL是难以实现的。
数据仓库中的数据基本都能表示成纯文本的形式。因此,下面我们重点讨论将关系数据库中的数据导出成文本文件的方法。
如果源系统是Oracle数据库,可以使用SQL*Plus中的spool命令完成数据导出。SQL*Plus是Oracle的命令行工具,在SQL*Plus中不仅能执行SQL命令,还可以执行SQL*Plus自己的命令,spool就是其中之一。通过spool命令可以将select查询的结果保存到文件中。
这种抽取技术的好处在于能够抽取任意SQL查询语句的输出,并且只要写SQL查询语句就行了,不需要任何编程工作。但它的缺点也很明显,如果表的数据量很大,导出过程将慢到无法容忍的程度。此时就得采用其它的数据导出方式,比如使用Oracle的UTL_FILE系统包,就可以实现快速导出,当数据量巨大并要求在一个较短的时间内导出数据时,推荐使用这种方案。
分布式查询
源系统可能会使用了多种关系数据库系统,它们往往是独立的,并处于远程系统中。如果能够从一个单一数据库访问其它的数据库系统,比如从Oracle访问SQLServer和mysql,或者从SQLServer访问Oracle和MySQL,无疑会最小化编程需要,给数据抽取的开发带来极大的便利。
Oracle和SQLServer都提供分布式查询功能。
Oracle通过透明网关和数据库链(Database Link)实现分布式查询。
SQLServer则使用链接服务器。
它们可以建立不同的数据库系统之间的联系,并可作为数据集成的重要工具之一。
使用Sqoop抽取数据
Sqoop是一个在Hadoop与结构化数据存储(如关系数据库)之间高效传输大批量数据的工具。
Sqoop有Sqoop1和Sqoop2两代,Sqoop1有许多简单易用的特性,如可以在命令行指定直接导入至Hive或HDFS。连接器可以连接大部分流行的数据库:Oracle、SQLServer、MySQL、Teradata、PostgreSQL等。
Sqoop1的主要问题包括:繁多的命令行参数;不安全的连接方式,如直接在命令行写密码等;没有元数据存储,只能本地配置和管理,使复用受到限制。
Sqoop2体系结构比Sqoop1复杂得多,它被设计用来解决Sqoop1的问题,主要体现在易用性、可扩展性和安全性三个方面:
1.易用性
Sqoop1需要客户端的安装和配置,而Sqoop2是在服务器端安装和配置。这意味着连接器只在一个地方统一配置,由管理员角色管理,操作员角色使用。
Sqoop2还有一个基于Web的服务:前端是命令行接口(CLI)和浏览器,后端是一个元数据知识库。用户可以通过交互式的Web接口进行导入导出,避免了错误选项和繁冗步骤。
Sqoop2还在服务器端整合了Hive和HBase。Oozie通过RESTAPI管理Sqoop任务,这样当安装一个新的Sqoop连接器后,无须在Oozie中安装它。
2.可扩展性
在Sqoop2中,连接器不再受限于JDBC的SQL语法,如不必指定database、table等,甚至可以定义自己使用的SQL方言。例如,Couchbase不需要指定表名,只需在填充或卸载操作时重载它。通用的功能将从连接器中抽取出来,使之只负责数据传输。
3.安全性
Sqoop1用户是通过执行sqoop命令运行Sqoop。Sqoop作业的安全性主要由是否对执行Sqoop的用户信任所决定。
◄数据转换与装载►
数据清洗
对大多数用户来说,ETL的核心价值在“T”所代表的转换部分。这个阶段要做很多工作,数据清洗就是其中一项重点任务。数据清洗是对数据进行重新审查和校验的过程,目的在于删除重复信息、纠正存在的错误,并提供数据一致性。
1.处理“脏数据”
数据仓库中的数据是面向某一主题数据的集合,这些数据从多个业务系统中抽取而来,并且包含历史数据,因此就不可避免地出现某些数据是错误的,或者数据相互之间存在冲突的情况。
这些错误的或有冲突的数据显然不是我们想要的,被称为“脏数据”。我们要按照一定的规则处理脏数据,这个过程就是数据清洗。数据清洗的任务是过滤那些不符合要求的数据,将过滤的结果交给业务主管部门,确认是直接删除掉,还是修正之后再进行抽取。
不符合要求的数据主要是残缺的数据、错误的数据、重复的数据、差异的数据四大类。
2.数据清洗原则
保障数据清洗处理顺利进行的原则是优先对数据清洗处理流程进行分析和系统化的设计,针对数据的主要问题和特征,设计一系列数据对照表和数据清洗程序库的有效组合,以便面对不断变化的、形形色色的数据清洗问题。
数据清洗流程通常包括如下内容。
预处理
对于大的数据加载文件,特别是新的文件和数据集合,要进行预先诊断和检测,不能贸然加载。有时需要临时编写程序进行数据清洁检查。标准化处理
应用建于数据仓库内部的标准字典,对于地区名、人名、公司名、产品名、分类名以及各种编码信息进行标准化处理。查重
应用各种数据库查询技术和手段,避免引入重复数据。出错处理和修正
将出错的记录和数据写入到日志文件,留待进一步处理。
◄定期自动执行ETL作业►
一旦数据仓库开始使用,就需要不断从源系统给数据仓库提供新数据。为了确保数据流的稳定,需要使用所在平台上可用的任务调度器来调度ETL定期执行。
操作系统一般都为用户提供调度作业的功能,如Windows的“计划任务”和UNIX/Linux的cron系统服务。绝大多数Hadoop系统都运行在Linux之上,因此有两种Linux上定时自动执行ETL作业的方案:
一种是经典的crontab,这是操作系统自带的功能。
二是Hadoop生态圈中的Oozie组件。
crontab
提供cron服务的进程名为crond,这是Linux下一个用来周期性执行某种任务或处理某些事件的守护进程。当安装完操作系统后,会自动启动crond进程,它每分钟会定期检查是否有要执行的任务,如果有则自动执行该任务。
Oozie简介
Oozie是一个管理Hadoop作业、可伸缩、可扩展、可靠的工作流调度系统,它内部定义了三种作业:
工作流作业
工作流作业是由一系列动作构成的有向无环图(DAGs)。协调器作业
协调器作业是按时间频率周期性触发Oozie工作流的作业。Bundle作业
Bundle管理协调器作业。
使用Oozie主要基于以下两点原因:
在Hadoop中执行的任务有时候需要把多个MapReduce作业连接到一起执行,或者需要多个作业并行处理。Oozie可以把多个MapReduce作业组合到一个逻辑工作单元中,从而完成更大型的任务。
从调度的角度看,如果使用crontab的方式调用多个工作流作业,可能需要编写大量的脚本,还要通过脚本来控制好各个工作流作业的执行时序问题,不但不好维护,而且监控也不方便。基于这样的背景,Oozie提出了Coordinator的概念,它能够将每个工作流作业作为一个动作来运行,相当于工作流定义中的一个执行节点,这样就能够将多个工作流作业组成一个称为CoordinatorJob的作业,并指定触发时间和频率,还可以配置数据集、并发数等。
◄联机分析处理►
OLAP由三个基本的分析操作构成:
合并(上卷)
下钻
切片
合并是指数据的聚合,即数据可以在一个或多个维度上进行累积和计算。例如,所有的营业部数据被上卷到销售部门以分析销售趋势。
下钻是一种由汇总数据向下浏览细节数据的技术。比如用户可以从产品分类的销售数据下钻查看单个产品的销售情况。
切片则是这样一种特性,通过它用户可以获取OLAP立方体中的特定数据集合,并从不同的视角观察这些数据。这些观察数据的视角就是我们所说的维度。例如通过经销商、日期、客户、产品或区域等,查看同一销售事实。
OLAP系统的核心是OLAP立方体,或称为多维立方体或超立方体。它由被称为度量的数值事实组成,这些度量被维度划分归类。
一个OLAP立方体的例子如图12-1所示,数据单元位于立方体的交叉点上,每个数据单元跨越产品、时间、地区等多个维度。通常使用一个矩阵接口操作OLAP立方体,例如电子表格程序的数据透视表,可以按维度分组执行聚合或求平均值等操作。立方体的元数据一般由关系数据库中的星型模式或雪花模式生成,度量来自事实表的记录,维度来自维度表。
◄数据可视化►
数据仓库的用户大部分是业务或管理人员,对他们来说,图形化的表示往往比满屏枯燥的数字更加容易接受。有些时候,可能希望得到的仅是某种粗略的趋势或比例,而不需要具体的数字值,此时类似饼图、柱状图、折线图等图形能够更加简明清晰地显示出业务含义,因此相对于数字报表,此时图形是更好的选择。
Hue简介
Hue是Hadoop User Experience的缩写,是一个开源的Apache Hadoop UI系统,最早是由Cloudera Desktop演化而来的,由Cloudera贡献给开源社区。
通过使用CDH的HueWeb应用,可以与Hadoop集群进行交互。在Hue中可以浏览HDFS和作业,管理Hive元数据,运行Hive、Impala查询或Pig脚本,浏览HBase,使用Sqoop导出数据,提交MapReduce程序,使用Solr建立定制的搜索引擎,调度重复执行的Oozie工作流等。
- 完 -
“小人书”形式分享自己的读书内容
以上是关于《Hadoop构建数据仓库实践》的主要内容,如果未能解决你的问题,请参考以下文章