01 数据仓库简介

对于每一种技术,先要理解相关的概念和它之所以出现的原因,这对于我们继续深入学习其技术细节大有裨益。本章将介绍数据仓库的定义,它和传统操作型数据库
应用的区别,以及为什么我们需要数据仓库。
在对数据仓库的概念有了一个基本的认识后,向读者介绍四种常见的数据仓库架构,然后说明 ETL 这个重要的数据仓库概念。本章最后概要介绍对于一个数据仓库的
基本需求和数据需求。

1.1 什么是数据仓库

数据仓库的概念可以追溯到 20 世纪 80 年代,当时 IBM 的研究人员开发出了 “ 商业数据仓库 ” 。本质上,数据仓库试图提供一种从操作型系统到决策支持环境的数据流架
构模型。数据仓库概念的提出,是为了解决和这个数据流相关的各种问题,主要是解决多重数据复制带来的高成本问题。在没有数据仓库的时代,需要大量的冗余数据来
支撑多个决策支持环境。在大组织里,多个决策支持环境独立运作是典型的情况。尽管每个环境服务于不同的用户,但这些环境经常需要大量相同的数据。处理过程收
集、清洗、整合来自多个数据源的数据,并为每个决策支持环境做部分数据复制。数据源通常是早已存在的操作型系统,很多是遗留系统。此外,当一个新的决策支持环
境形成时,操作型系统的数据经常被再次复用。用户访问这些处理后的数据。

1.1.1 数据仓库的定义

数据仓库之父 Bill Inmon 在 1991 年出版的 Building the Data Warehouse 一书中首次提出了被广为认可的数据仓库定义。 Inmon 将数据仓库描述为一个面向主题的、集成的、
随时间变化的、非易失的数据集合,用于支持管理者的决策过程。这个定义有些复杂并且难以理解。下面我们将它分解开来进行说明。

• 面向主题
• 集成
• 随时间变化
• 非易失

1.1.2 建立数据仓库的原因

• 某些业务数据由于安全或其他因素不能直接访问。
• 业务系统的版本变更很频繁,每次变更都需要重写分析系统并重新测试。
• 很难建立和维护汇总数据来源于多个业务系统版本的报表。
• 业务系统的列名通常是硬编码,有时仅仅是无意义的字符串,这让编写分析系统更加困难。
• 业务系统的数据格式,如日期、数字的格式不统一。
• 业务系统的表结构为事务处理性能而优化,有时并不适合查询与分析。
• 没有适当的方式将有价值的数据合并进特定应用的数据库。
• 没有适当的位置存储元数据。
• 用户需要看到的显示数据字段,有时在数据库中并不存在。
• 通常事务处理的优先级比分析系统高,所以如果分析系统和事务处理运行在同一硬件之上,分析系统往往性能很差。
• 有误用业务数据的风险。
• 极有可能影响业务系统的性能。

1.1.2 使用数据仓库的好处

• 将多个数据源集成到单一数据存储,因此可以使用单一数据查询引擎展示数据。
• 缓解在事务处理数据库上因执行大查询而产生的资源竞争问题。
• 维护历史数据。
• 通过对多个源系统的数据整合,使得在整个企业的角度存在统一的中心视图。
• 通过提供一致的编码和描述,减少或修正坏数据问题,提高数据质量。
• 一致性地表示组织信息。
• 提供所有数据的单一通用数据模型,而不用关心数据源。
• 重构数据,使数据对业务用户更有意义。
• 向复杂分析查询交付优秀的查询性能,同时不影响操作型系统。
• 开发决策型查询更简单。

1.2 操作型系统与分析型系统

1.2.1 操作型系统

1.2.1.1 操作型系统的数据库操作

在数据库使用上,操作型系统常用的操作是增、改、查,并且通常是插入与更新密集型的,同时会对数据库进行大量并发查询,而删除操作相对较少。操作型系统一
般都直接在数据库上修改数据,没有中间过渡区。

1.2.1.2 操作型系统的数据库设计

操作型系统的特征是大量短的事务,并强调快速处理查询。每秒事务数是操作型系统的一个有效度量指标。针对以上这些特点,数据库设计一定要满足系统的要求。
在数据库逻辑设计上,操作型系统的应用数据库大都使用规范化设计方法,通常要满足第三范式。这是因为规范化设计能最大限度地数据冗余,因而提供更快更高效
的方式执行数据库写操作。关于规范化设计概念及其相关内容,会在第 2 章 “ 数据仓库设计 ” 中做详细说明。
在数据库物理设计上,应该依据系统所使用的数据库管理系统的具体特点,做出相应的设计,毕竟每种数据库管理系统在实现细节上还是存在很大差异的。下面就以
Oracle 数据库为例,简要说明在设计操作型系统数据库时应该考虑的问题。

• 调整回滚段。回滚段是数据库的一部分,其中记录着最终被回滚的事务的行为。这些回滚段信息可以提供读一致性、回滚事务和数据库恢复。
• 合理使用聚簇。聚簇是一种数据库模式,其中包含有共用一列或多列的多个表。数据库中的聚簇表用于提高连接操作的性能。
• 适当调整数据块大小。数据块大小应该是操作系统块大小的倍数,并且设置上限以避免不必要的 I/O 。
• 设置缓冲区高速缓存大小。合理的缓存大小能够有效避免不必要的磁盘 I/O 。
• 动态分配表空间。
• 合理划分数据库分区。分区最大的作用是能在可用性和安全性维护期间保持事务处理的性能。
• SQL 优化。有效利用数据库管理系统的优化器,使用最佳的数据访问路径。
• 避免过度使用索引。大量的数据修改会给索引维护带来压力,从而对整个系统的性能产生负面影响。
  以上所讲的操作型系统都是以数据库系统为核心,而数据库系统为了保持 ACID 特性,本质上是单一集中式系统。在当今这个信息爆炸的时代,集中式数据库往往已无
  法支撑业务的需要(从某订票网站和某电商网站的超大瞬时并发量来看,这已是一个不争的事实)。这就给操作型系统带来新的挑战。分布式事务、去中心化、 CAP 与最
  终一致性等一系列新的理论和技术为解决系统扩展问题应运而生。

1.2.2 分析型系统

在计算机领域,分析型系统是一种快速回答多维分析查询的实现方式。它也是更广泛范畴的所谓商业智能的一部分(商业智能还包含数据库、报表系统、数据挖掘、
数据可视化等研究方向)。分析型系统的典型应用包括销售业务分析报告、市场管理报告、业务过程管理( BPM )、预算和预测、金融分析报告及其类似的应用。

1.2.2.1 分析型系统的数据库操作

在数据库层面,分析型系统操作被定义成少量的事务,复杂的查询,处理归档和历史数据。这些数据很少被修改,从数据库抽取数据是最多的操作,也是识别这种系
统的关键特征。分析型数据库基本上都是读操作。

1.2.2.2 分析型系统的数据库设计

分析型系统的特征是相对少量的事务,但查询通常非常复杂并且会包含聚合计算,例如今年和去年同时期的数据对比、百分比变化趋势等。分析型数据库中的数据一
般来自于一个企业级数据仓库,是整合过的历史数据。对于分析型系统,吞吐量是一个有效的性能度量指标。
在数据库逻辑设计上,分析型数据库使用多维数据模型,通常是设计成星型模式或雪花模式。关于多维数据模型的概念及其相关内容,会在第 2 章 “ 数据仓库设计 ” 中做详细说明。
在数据库物理设计上,依然以 Oracle 数据库为例,简要说明在设计分析型系统数据库时应该考虑的一些问题。

• 表分区。可以独立定义表分区的物理存储属性,将不同分区的数据存放到多个物理文件上,这样做一方面可以分散 I/O ;另一方面,当数据量非常大时,方便数据维护;再有就是利用分区消除查询数据时,不用扫描整张表,从而提高查询性能。
• 位图索引。当查询条件中包含低基数(不同值很少,例如性别)的列,尤其是包含有这些列上的 or 、 and 或 not 这样的逻辑运算时,或者从有大量行的表中返回大量的行时,应考虑位图索引。
• 物化视图。物化视图物理存储查询所定义的数据,能够自动增量刷新数据,并且可以利用查询重写特性极大地提高查询速度,是分析型系统常用的技术。
• 并行化操作。可以在查询大量数据时执行并行化操作,这样会导致多个服务器进程为同一个查询语句工作,使用该查询可以快速完成,但是会耗费更多的资源。
  随着数据的大量积累和大数据时代的到来,人们对于数据分析的依赖性越来越强,而分析型系统也随之越来越显示出重要性。举一个简单的例子,在一家医院中,保存有 20 年的非常完整的病人信息。医院领导想看到关于最常见的疾病、成功治愈率、实习医生的实习天数等很多相关数据的详细报告。为了满足这个需求,应用分析型系统查询医院信息数据仓库,并通过复杂查询得到结果,然后将报告提交给领导做进一步分析。

1.2.3 操作型系统和分析型系统对比

操作型系统和分析型系统是两种不同种类的信息系统。它们都与数据库技术相关,数据库提供方法支持这两种系统的功能。操作型系统和分析型系统以完全不同的方
式使用数据库,不仅如此,分析型系统更加注重数据分析和报表,而操作型系统的目标是一个伴有大量数据改变的事务优化系统。
对于学习数据科学及其相关技术的读者,了解这两种信息处理方式的区别至关重要。这也是理解商业智能、数据挖掘、数据仓库、数据模型、 ETL 处理和大数据等系
统的基础。

选区_017.png

1.3 数据仓库架构

前面两个小节介绍了数据仓库、操作型系统、分析型系统等概念,也指出了分析型系统的数据源一般来自数据仓库,而数据仓库的数据来自于操作型系统。本小节从技术角度讨论数据仓库的组成和架构。

1.3.1 基本架构

“架构” 是什么?这个问题从来就没有一个准确的答案。在软件行业,一种被普遍接受的架构定义是指系统的一个或多个结构。结构中包括软件的构建(构建是指软件的设计与实现),构建的外部可以看到属性以及它们之间的相互关系。这里参考此定义,把数据仓库架构理解成构成数据仓库的组件及其之间的关系,那么就有了如图

选区_018.png

1.3.2 主要数据仓库架构

在数据仓库技术演化过程中,产生了几种主要的架构方法,包括数据集市架构、 Inmon 企业信息工厂架构、 Kimball 数据仓库架构和混合型数据仓库架构。

1.3.2.1 数据集市架构

数据集市是按主题域组织的数据集合,用于支持部门级的决策。有两种类型的数据集市:独立数据集市和从属数据集市。
独立数据集市集中于部门所关心的单一主题域,数据以部门为基础部署,无须考虑企业级别的信息共享与集成。例如,制造部门、人力资源部门和其他部门都各自有他们自己的数据集市。独立数据集市从一个主题域或一个部门的多个事务系统获取数据,用以支持特定部门的业务分析需要。一个独立数据集市的设计既可以使用实体关系模型,也可以使用多维模型。数据分析或商业智能工具直接从数据集市查询数据,并将查询结果显示给用户。一个典型的独立数据集市架构如图 1-2 所示。
因为一个部门的业务相对于整个企业要简单,数据量也小得多,所以部门的独立数据集市具有周期短、见效快的特点。如果从企业整体的视角来观察这些数据集市,
你会看到每个部门使用不同的技术,建立不同的 ETL 的过程,处理不同的事务系统,而在多个独立的数据集市之间还会存在数据的交叉与重叠,甚至会有数据不一致的情况。从业务角度看,当部门的分析需求扩展,或者需要分析跨部门或跨主题域的数据时,独立数据市场会显得力不从心。而当数据存在歧义,比如同一个产品,在 A 部门和 B 部门的定义不同时,将无法在部门间进行信息比较。

选区_019.png

1.3.2.2 Kimball 数据仓库架构

选区_020.png

对比上一张图可以看到, Kimball 与 Inmon 两种架构的主要区别在于核心数据仓库的设计和建立。 Kimball 的数据仓库包含高粒度的企业数据,使用多维模型设计,这也意味着数据仓库由星型模式的维度表和事实表构成。分析系统或报表工具可以直接访问多维数据仓库里的数据。在此架构中的数据集市也与 Inmon 中的不同。这里的数据集市是一个逻辑概念,只是多维数据仓库中的主题域划分,并没有自己的物理存储,也可以说是虚拟的数据集市。

1.3.2.3 混合型数据仓库架构

选区_021.png

所谓的混合型结构,指的是在一个数据仓库环境中,联合使用 Inmon 和 Kimball 两种架构。从架构图可以看到,这种架构将 Inmon 方法中的数据集市部分替换成了一个多维数据仓库,而数据集市则是多维数据仓库上的逻辑视图。使用这种架构的好处是,既可以利用规范化设计消除数据冗余,保证数据的粒度足够细;又可以利用多维结构更灵活地在企业级实现报表和分析。

1.3.3 操作数据存储

操作数据存储又称为 ODS ,是 Operational DataStore 的简写,其定义是这样的:一个面向主题的、集成的、可变的、当前的细节数据集合,用于支持企业对于即时性的、操作性的、集成的全体信息的需求。对比 1.1 节中数据仓库的定义不难看出,操作型数据存储在某些方面具有类似于数据仓库的特点,但在另一些方面又显著不同于数据仓库。

• 像数据仓库一样,是面向主题的。
• 像数据仓库一样,其数据是完全集成的。
• 数据是当前的,这与数据仓库存储历史数据的性质明显不同。 ODS 具有最少的历史数据(一般是 30 天到 60 ),而尽可能接近实时地展示数据的状态。
• 数据是可更新的,这是与静态数据仓库又一个很大的区别。 ODS 就如同一个事务处理系统,当新的数据流进 ODS 时,受其影响的字段被新信息覆盖。
• 数据几乎完全是细节数据,仅具有少量的动态聚集或汇总数据。通常将 ODS 设计成包含事务级的数据,即包含该主题域中最低粒度级别的数据。
• 在数据仓库中,几乎没有针对其本身的报表,报表均放到数据集市中完成;与此不同,在 ODS 中,业务用户频繁地直接访问 ODS 。
  在一个数据仓库环境中, ODS 具有如下几个作用:

1. 充当业务系统与数据仓库之间的过渡区。数据仓库的数据来源复杂,可能分布在不同的数据库,不同的地理位置,不同的应用系统之中,而且由于数据形式的多样性,数据转换的规则往往极为复杂。如果直接从业务系统抽取数据并做转换,不可避免地会对业务系统造成影响。而 ODS 中存放的数据从数据结构、数据粒度、数据之间的逻辑关系上都与业务系统基本保持一致,因此抽取过程只需简单的数据复制而基本不再需要做数据转换,大大降低了复杂性,同时最小化对业务系统的侵入。
2. 转移部分业务系统细节查询的功能。某些原来由业务系统产生的报表、细节数据的查询能够在 ODS 中进行,从而降低业务系统的查询压力。
3. 完成数据仓库中不能完成的一些功能。用户有时会要求数据仓库查询最低粒度级别的细节数据,而数据仓库中存储的数据一般都是聚合或汇总过的数据,并不存储每笔交易产生的细节数据。这时就需要把细节数据查询的功能转移到 ODS 来完成,而且 ODS 的数据模型是按照面向主题的方式组织的,可以方便地支持多维分析。
   即数据仓库从宏观角度满足企业的决策支持要求,而 ODS 层则从微观角度反映细节交易数据或者低粒度的数据查询要求。

1.4 抽取 - 转换 - 装载

前面已经多次提到了 ETL 一词,它是 Extract 、 Transform 、 Load 三个英文单词首字母的简写,中文意为抽取、转换、装载。 ETL 是建立数据仓库最重要的处理过程,也是最体现工作量的环节,一般会占到整个数据仓库项目工作量的一半以上。

• 抽取:从操作型数据源获取数据。
• 转换:转换数据,使之转变为适用于查询和分析的形式和结构。
• 装载:将转换后的数据导入到最终的目标数据仓库。
  建立一个数据仓库,就是要把来自于多个异构的源系统的数据集成在一起,放置于一个集中的位置用于数据分析。如果一开始这些源系统数据就是兼容的当然最好,但情况往往不是这样。 ETL 系统的工作就是要把异构的数据转换成同构的。如果没有 ETL ,不可能对异构的数据进行程序化的分析。

1.4.1 数据抽取

1.4.1.1 逻辑抽取

• 全量抽取
• 增量抽取

1.4.1.2 物理抽取

1. 联机抽取
2. 脱机抽取
   数据不从源系统直接抽取,而是从一个源系统以外的过渡区抽取。过渡区可能已经存在(例如数据库备份文件、关系数据库系统的重做日志、归档日志等),或者抽取程序自己建立。应该考虑以下的存储结构:

• 数据库备份文件。一般需要数据还原操作才能使用。
• 备用数据库。如 Oracle 的 DataGuard 和 MySQL 的数据复制等技术。
• 平面文件。数据定义成普通格式,关于源对象的附加信息(列名、数据类型等)需要另外处理。
• 导出文件。关系数据库大都自带数据导出功能,如 Oracle 的 exp/expdp 程序和 MySQL 的mysqldump 程序,都 可以用于生成导出数据文件。
• 重做日志和归档日志。每种数据库系统都有自己的日志格式和解析工具。

3. 变化数据捕获
   抽取处理需要重点考虑增量抽取,也被称为变化数据捕获,简称 CDC 。假设一个数据仓库系统,在每天夜里的业务低峰时间从操作型源系统抽取数据,那么增量抽取只需要过去 24 小时内发生变化的数据。变化数据捕获也是建立准实时数据仓库的关键技术。
   当你能够识别并获得最近发生变化的数据时,抽取及其后面的转换、装载操作显然都会变得更高效,因为要处理的数据量会小很多。遗憾的是,很多源系统很难识别出最近变化的数据,或者必须侵入源系统才能做到。变化数据捕获是数据抽取中典型的技术挑战。
   常用的变化数据捕获方法有时间戳、快照、触发器和日志四种。相信熟悉数据库的读者对这些方法都不会陌生。时间戳方法需要源系统有相应的数据列表示最后的数据变化。快照方法可以使用数据库系统自带的机制实现,如 Oracle 的物化视图技术,也可以自己实现相关逻辑,但会比较复杂。触发器是关系数据库系统具有的特性,源表上建立的触发器会在对该表执行 insert 、 update 、 delete 等语句时被触发,触发器中的逻辑用于捕获数据的变化。日志可以使用应用日志或系统日志,这种方式对源系统不具有侵入性,但需要额外的日志解析工作。

1.4.2 数据转换

数据从操作型源系统获取后,需要进行多种转换操作。如统一数据类型、处理拼写错误、消除数据歧义、解析为标准格式等。数据转换通常是最复杂的部分,也是ETL 开发中用时最长的一步。数据转换的范围极广,从单纯的数据类型转化到极为复杂的数据清洗技术。
在数据转换阶段,为了能够最终将数据装载到数据仓库中,需要在已经抽取来的数据上应用一系列的规则和函数。有些数据可能不需要转换就能直接导入到数据仓库。
数据转换一个最重要的功能是清洗数据,目的是只有 “ 合规 ” 的数据才能进入目标数据仓库。这步操作在不同系统间交互和通信时尤其必要,例如,一个系统的字符集在另一个系统中可能是无效的。另一方面,由于某些业务和技术的需要,也需要进行多种数据转换,例如下面的情况:

• 只装载特定的数据列。例如,某列为空的数据不装载。
• 统一数据编码。例如,性别字段,有些系统使用的是 1 和 0 ,有些是 ‘M’ 和 ‘F’ ,有些是 ‘ 男 ’ 和 ‘ 女 ’ ,统一成 ‘M’ 和 ‘F’ 。
• 自由值编码。例如,将 ‘Male’ 改成 ‘M’ 。
• 预计算。例如,产品单价 * 购买数量=金额。
• 基于某些规则重新排序以提高查询性能。
• 合并多个数据源的数据并去重。
• 预聚合。例如,汇总销售数据。
• 行列转置。
• 将一列转为多列。例如,某列存储的数据是以逗号作为分隔符的字符串,将其分割成多列的单个值。
• 合并重复列。
• 预连接。例如,查询多个关联表的数据。
• 数据验证。针对验证的结果采取不同的处理,通过验证的数据交给装载步骤,验证失败的数据或直接丢弃,或记录下来做进一步检查。

1.4.3 数据装载

ETL 的最后步骤是把转换后的数据装载进目标数据仓库。这步操作需要重点考虑两个问题,一是数据装载的效率问题,二是一旦装载过程中途失败了,如何再次重复执行装载过程。
即使经过了转换、过滤和清洗,去掉了部分噪声数据,但需要装载的数据量还是很大的。执行一次数据装载可能需要几个小时的时间,同时需要占用大量的系统资源。要提高装载的效率,加快装载速度,可以从以下几方面入手。首先保证足够的系统资源。数据仓库存储的都是海量数据,所以要配置高性能的服务器,并且要独占资源,不要与别的系统共用。在进行数据装载时,要禁用数据库约束(唯一性、非空性,检查约束等)和索引,当装载过程完全结束后,再启用这些约束,重建索引,这种方法会很大的提高装载速度。在数据仓库环境中,一般不使用数据库来保证数据的参考完整性,即不使用数据库的外键约束,它应该由 ETL 工具或程序来维护。
数据装载过程可能由于多种原因而失败,比如装载过程中某些源表和目标表的结构不一致而导致失败,而这时已经有部分表装载成功了。在数据量很大的情况下,如何能在重新执行装载过程时只装载失败的部分是一个不小的挑战。对于这种情况,实现可重复装载的关键是要记录下失败点,并在装载程序中处理相关的逻辑。还有一种情况,就是装载成功后,数据又发生了改变(比如有些滞后的数据在 ETL 执行完才进入系统,就会带来数据的更新或新增),这时需要重新再执行一遍装载过程,已经正确装载的数据可以被覆盖,但相同数据不能重复新增。简单的实现方式是先删除再插入,或者用 replace into 、 merge into 等类似功能的操作。
装载到数据仓库里的数据,经过汇总、聚合等处理后交付给多维立方体或数据可视化、仪表盘等报表工具、 BI 工具做进一步的数据分析。

1.4.4 开发 ETL 系统的方法

ETL 系统一般都会从多个应用系统整合数据,典型的情况是这些应用系统运行在不同的软硬件平台上,由不同的厂商所支持,各个系统的开发团队也是彼此独立的,随之而来的数据多样性增加了 ETL 系统的复杂性。
开发一个 ETL 系统,常用的方式是使用数据库标准的 SQL 及其程序化语言,如 Oracle 的 PL/SQL 和 MySQL 的存储过程、用户自定义函数( UDF )等。还可以使用 Kettle 这样的 ETL 工具,这些工具都提供多种数据库连接器和多种文件格式的处理能力,并且对 ETL 处理进行了优化。使用工具的最大好处是减少编程工作量,提高工作效率。如果遇到特殊需求或特别复杂的情况,可能还是需要使用 Shell 、 Java 、 Python 等编程语言开发自己的应用程序。
ETL 过程要面对大量的数据,因此需要较长的处理时间。为了提高ETL的效率,通常这三步操作会并行执行。当数据被抽取时,转换进程同时处理已经收到的数据。一旦某些数据被转换过程处理完,装载进程就会将这些数据导入目标数据仓库,而不会等到前一步工作执行完才开始。

1.4.5 常见 ETL 工具

传统大的软件厂商一般都提供 ETL 工具软件,如 Oracle 的 OWB 和 ODI 、微软的 SQL Server Integration Services 、 SAP 的 Data Integrator 、 IBM 的 InfoSphere DataStage 、
Informatica 等。这里简单介绍另外一种开源的 ETL 工具 ——Kettle 。
Kettle 是 Pentaho 公司的数据整合产品,它可能是现在世界上最流行的开源 ETL 工具,经常被用于数据仓库环境。 Kettle 的使用场景包括:在应用或数据库间迁移数据、把数据库中的数据导出成平面文件、向数据库大批量导入数据、数据转换和清洗、应用整合等。
Kettle 里主要有 “ 转换 ” 和 “ 作业 ” 两个功能模块。转换是 ETL 解决方案中最主要的部分,它处理 ETL 各阶段各种对数据的操作。转换有输入、输出、检验、映射、加密、脚本等很多分类,每个分类中包括多个步骤,如输入转换中就有表输入、 CSV 文件输入、文本文件输入等很多步骤。转换里的步骤通过跳( hop )来连接,跳定义了一个单向通道,允许数据从一个步骤流向另外一个步骤。在 Kettle 里,数据的单位是行,数据流就是数据行从一个步骤到另一个步骤的移动。
转换是以并行方式执行的,而作业则是以串行方式处理的,验证数据表是否存在这样的操作就需要作业来完成。一个作业包括一个或多个作业项,作业项是以某种顺序来执行的,作业执行顺序由作业项之间的跳( hop )和每个作业项的执行结果决定。和转换一样,作业也有很多分类,每个分类中包括多个作业项,如转换就是一个通用分类里的作业项。作业项也可以是一个作业,此时称该作业为子作业。
Kettle 非常容易使用,其所有的功能都通过用户界面完成,不需要任何编码工作。你只需要告诉它做什么,而不用指示它怎么做,这大大提高了 ETL 过程的开发效率。

1.5 数据仓库需求

1.5.1 基本需求

• 安全性
• 可访问性
• 自动化

1.5.2 数据需求

1. 准确性
   想要数据仓库实施成功,业务用户必须信任其中的数据。这就意味着他们应该能知道数据从哪来,何时抽取,怎么转换的。更重要的是,他们需要访问原始数据来确
   定如何解决数据差异问题。实际上 ETL 过程应该总是在数据仓库的某个地方(如 ODS )保留一份原始数据的复制。
2. 时效性
   用户的时效性要求差异很大。有些用户需要数据精确到毫秒级,而有些用户只需要几分钟、几小时甚至几天前的数据就可以了。数据仓库是分析型系统,用于决策支
   持,所以实践中一般不需要很强的实时性,以一天作为时间粒度是比较常见的。
3. 历史可追溯性
   数据仓库更多的价值体现在它能够辅助随时间变化的趋势分析,并帮助理解业务事件(如特殊节日促销等)与经营绩效之间的关系。

1.6 小结

• 数据仓库是一个面向主题的、集成的、随时间变化的、非易失的数据集合,用于支持管理者的决策过程。
• 数据仓库中的粒度是指数据的细节或汇总程度,细节程度越高,粒度级别越低。
• 数据仓库的数据来自各个业务应用系统。
• 很多因素导致直接访问业务系统无法进行全局数据分析的工作,这也是需要一个数据仓库的原因所在。
• 操作型系统是一类专门用于管理面向事务的应用信息系统,而分析型系统是一种快速回答多维分析查询的实现方式,两者在很多方面存在差异。
• 构成数据仓库系统的主要组成部分有数据源、 ODS 、中心数据仓库、分析查询引擎、 ETL 、元数据管理和自动化调度。
• 主要的数据仓库架构有独立数据集市、从属数据集市、 Inmon 企业信息工厂、 Kimball 多维数据仓库、混合型数据仓库。
• ETL 是建立数据仓库最重要的处理过程,也是最体现工作量的环节。
• Kettle 是常用的开源 ETL 工具。
• 数据仓库的基本需求是安全性、可访问性、自动化,对数据的要求是准确性、时效性、历史可追溯性。