《数据虚拟化:商务智能系统的数据架构与管理》一 2.5 商务智能系统的数据存储

本文涉及的产品
阿里云百炼推荐规格 ADB PostgreSQL,4核16GB 100GB 1个月
简介: 本节书摘来自华章出版社《数据虚拟化:商务智能系统的数据架构与管理》一 书中的第2章,第2.5节,作者:[荷]里克 F. 范德兰斯(Rick F. van der Lans),更多章节内容可以访问云栖社区“华章计算机”公众号查看。

2.5 商务智能系统的数据存储

在商务智能系统中可以找到下列形式的数据存储:
数据仓库
数据集市
数据中转区
可操作数据存储
个人数据存储

2.5.1 数据仓库

就像引擎需要汽油来驱动,报表工具和分析工具也需要数据来操作。没有数据,这些产品就没有价值。所以这些工具需要访问将数据收集起来的生产数据库,因为大多数用户需要的可用数据都在数据库中。从技术上说,报表工具可以直接连接到生产数据库中(如图2-3所示)。这些方式简单且看起来十分吸引人,但是在大多数机构中因为一些原因并不能使用。以下是一些最主要的原因:
数据集成:报表需要的数据需要存储在多个生产数据库中。例如,所有与一个客户有关的数据很可能扩散到多个系统。这意味着报表工具需要访问所有这些系统并且有责任整合这些数据。整个的整合过程使报告变得更加复杂,并且整合逻辑在许多报表中重复出现,这可能导致前后不一致的结果。
缺陷数据:存储在生产系统中的数据可能出现错误或者丢失。如果报表直接来源于这些存储数据,就会面临处理错误数据的问题。这很困难,因为大多数工具不能完善地支持这个功能。除此之外,如果这是可行的,我们如何保证所有的报告(可能由不同的工具生成)以相同的方式将这些错误数据转换成正确的?
数据一致性:如果不同的报表工具使用不同的技术解决多个生产数据库数据整合问题,我们如何保证他们使用的是相同的整合逻辑?换言之,我们如何保证报表的一致性?两个报表很可能使用两个截然不同的转换法则。
历史数据:不是所有的生产数据库都保留历史资料。例如,在很多系统中,如果一位顾客的地址发生改变,那么旧地址就会被覆盖。对于特定的报表和分析形式,是需要历史数据的。例如,你需要历史数据进行回归分析从而做出销售预测,因此如果生产系统不能追踪历史数据,那么报表和分析需要额外的存储设备来存储历史数据。
干扰:报表工具在生产数据库中执行查询功能可能对生产系统产生过大的干扰。数据库查询可能是I/O敏感的,这样会使用户输入新数据到产品环境中时产生性能下降的感觉。换言之,企业用户将会阻塞生产系统的用户从而干扰生产本身,这对于任何生产环境都是不允许的。
查询性能:生产数据库的主要功能是支持生产应用。报告工具执行查询可能很复杂。在生产数据库中运行这些功能会导致性能降低。事实上,性能可以低到需要用户等多个小时才得到结果。同时,查询会产生很多干扰。
外部数据:在这一类解决方案中,并没有用来分析外部数据的实际空间。假设有一个报告想要分析天气状况对特定商品销量的影响,对于大多数组织来说,天气相关数据是外部数据且并不存储在生产数据库中,它必须从一个外部源中获得。但是,图2-3描绘的解决方案中把它存储在哪里呢?
为了克服这些问题,商务智能系统通常围绕着数据仓库进行开发。数据仓库是一个被设计用来报告和分析的独立数据存储,数据定期从生产数据库拷贝到这样一个数据仓库中(如图2-4所示)。在大多数情况下,选择一个基于ETL的解决方案来实现一体化进程,这意味着数据仓库中的数据被定期刷新。

52ed204c0a681cd372847c44b64c5e4e3d88e2a8

如果我们重新考虑分析工具对生产数据库直接报告的缺点,一个能够克服这些缺点的基于数据仓库的解决方案应该满足以下条件。
数据集成:来自不同系统的数据进行一次集成,并以整合的方式存储。因此,报告工具不必处理数据的集成。
缺陷数据:在一个ETL脚本中,缺陷数据可以被清洗,这会使数据仓库包含缺陷较少的数据。结果使得报告不必处理缺陷数据,并且所有的报告共享相同清洗操作的结果。
数据一致性:因为所有报告从数据仓库中提取数据,并且这些仓库里面的数据已经被集成,报告的一致性将减少问题发生的可能性。
历史数据:即使生产数据库不能追踪历史,设计数据仓库成为可以追溯历史数据、储存所有“旧”数据的场所。
干扰:报告和分析工具生成的查询不会直接在生产数据库运行,所以这些查询不会成为干扰。然而,数据必须要定期地从生产数据库拷贝到数据仓库,这似乎是个复杂的查询过程。但是,这个过程能在生产系统没有使用或者使用较少的晚上或周末内完成。
查询性能:数据仓库只为了报告查询而特意设计和优化,这将提升查询性能。
外部数据:如果报告需要外部数据,这些数据就能存储在数据仓库并和内部数据一样容易访问到。
数据仓库有几种定义,我们采用Bill Inmon的定义,因为他的定义在工业领域广泛使用。这个定义在他出版于20世纪90年代的关于数据仓库的题为《Building the Data Warehouse》的著作中首次被提出(见文献[23]):
数据仓库是一个支持管理决策进程的面向主题的、集成的、随时间变化的、永久保存的数据集合。
注意:在他最近的书《DW 2.0—The Architecture for the Next Generation of Data Warehousing》中,他将定义的结尾“管理决策进程”稍作修改成“管理层的决定”(见文献[24])。但是这一更改并没有改变定义的一般意义,所以我们仍然使用他的原始定义。
此定义使用了4个重要的概念:面向主题意思是关于各具体主题的所有数据存储在一起。例如,所有的顾客数据存储在一起,所有的产品数据存储在一起。面向主题的对立面是面向应用,在面向应用中一个数据库包含只与一个特定应用有关的数据,因而导致顾客数据被分散到多个数据库的情况。由于针对一个特定报告的数据会被多个数据库检索,这将使得报告严重复杂化。集成意味着一个一致的数据编码,因此数据能在一个集成方法中被检索和组合。
数据仓库是非易失数据库。当一个数据库主要用于生成报告,报告中的数据不断改变给用户带来不便。假设两个用户要一起去开会,为了准备这场会议,他们都需要查询数据库来获得一个指定区域的销售记录。假设在两个查询之间有十分钟间隔,在这十分钟内数据库可能已经改变,所以会议中用户可能得到不一致的数据。为了避免这种情况,数据仓库应该定期更新而不是持续更新,新的数据元素应该在每晚或周末添加。
注意非易失的概念对于那些不需要访问操作数据的决策有意义。正如1.2节所述,访问操作数据的需要正在扩大,我们将在这本书的不同章节重新讨论这个问题。
时变性是数据仓库的另一个重要特点。通常,生产数据库要尽可能小,因为数据库越小,查询越快。保证数据库小的一个普遍方法就是删除旧数据,旧数据能存储在磁带或DVD中以备未来使用。然而,数据仓库的用户期望能够访问历史数据,他们想要找出例如近10年来去伦敦的船票总数是否改变,或者他们想要知道天气如何影响啤酒的销量,出于这个原因,他们想要使用近5年的数据。这意味着相当大量的历史数据都要包括在内,并且基本上所有的数据都是时变的,这是为什么一些数据仓库庞大的原因之一。
如果我们构造一个遵守以上定义的数据仓库系统,那么这个系统不是一个完全的解决方案,也不是一个完全的商务智能系统。一个数据仓库本身不会在正确的时间以正确的形式供给用户正确的数据来改善他们的决策。我们需要额外的模块来构造一个能工作的商务智能系统,例如分析和报告工具、ETL工具、中转区和数据集市。换句话说,为了构造一个商务智能系统,我们需要的不仅仅是一个数据仓库。但是尽管数据仓库只是模块之一,它仍是至关重要的:它是网上的蜘蛛。
数据仓库的定义也包含数据收集方面,这意味着什么呢?它意味着数据仓库里的数据应该物理存储在一个集合里,或者说数据作为集合的形式足够吗?基于它自身的定义,这很难表述。但是如果我们阅读Bill Inmon的其他书籍和文章,我们可以总结出他强烈支持一个数据的存储集合。此外,通过免费词典(www.thefreedictionary.com)可得,术语仓库(不是数据仓库)的定义是“存储货物或商品的地方”,这个定义也把术语存储和仓库联系起来。因此,在本书中我们假定一个数据仓库是一个数据的存储集合。
定义以“支持管理决策进程”结束,这是为了强调要发展数据仓库的原因是支持组织决策过程,不是为了支持生产系统,也不是为了能够追踪历史数据。它可以追踪历史数据等,但不是开发数据仓库的主要目的。
偶然地,遇到一个术语企业数据仓库。把术语企业加进的原因是为了强调数据仓库不是为了一个或两个部门或部分企业,而是为了整个企业的数据存储。在本书中,我们把这些术语视为同义词。

2.5.2 数据集市

如果数据仓库是一个真的大数据存储,所有的报告和分析工具访问数据存储,这将给管理数据仓库的数据库服务器带来高负荷的查询工作量。由于这个原因,许多组织已经开发了数据集市来减轻查询的工作量(也可能有其他理由;如图2-5所示)。数据集市在Kimball的书中被推广(见文献[25])。

screenshot

每个数据集市都是为了一组专门的用户开发,通常来说是所有有数据需求的用户。这意味着一个数据集市包含数据仓库数据的子集,而一个数据仓库包含最低级的数据,一个数据集市包含所有数据的轻量聚集体。如果有数据集市,大多数报告运行于数据集市而不是数据仓库,因此减轻了查询的工作量。
另一个开发数据集市的原因是它允许使用面向报告和报告工具的存储技术和存储体系。例如,对于某些报告,如果数据以立方形式存储在一个多维数据库服务器中,查询性能会更好。
如果一个组织结构需要数据集市,那么它不必要拥有一个数据仓库(如图2-6所示)。在这种情况下,不是一个数据库拥有所有的数据,而是数据被分布在一系列数据集市中。如果用户需要运行分布于多个数据集市数据的报告,报告工具自身就要集成这些数据集市。

screenshot

使用数据集市—仅是体系—的主要优点是提高速度。一个组织体系从头开始运行,为小组用户开发的数据集市比为大组用户开发的数据仓库需要更少的时间。
此体系也有一些不利:首先,图2-3中显示的解决方法的缺陷也适用于此,比如数据集成、缺陷数据和数据一致性;其次,很难保证更新数据集市的ETL脚本以相同的方式把相同的数据转换展示出来。

2.5.3 数据中转区

由于技术和概念性原因,在某些环境下把数据从生产系统直接拷贝到数据仓库可能太过复杂。因此,在许多商务智能系统中,数据在到达数据仓库之前首先被拷贝入数据中转区(如图2-7所示)。如果开发了一个数据中转区,它的作用相当于是一个着陆区。在生产系统中已经被插入、更改或删除的数据会尽可能快地拷贝到此区域。在拷贝进程中,应该对数据的内容和结构进行少量的更改。在一个理想的环境下,中转区中表格的结构和生产系统的表格相同,这意味着不需要改变,而是一对一的数据拷贝。所有的转换和清洗操作将被应用在拷贝过程的第二步:从中转区到数据仓库。
当拷贝数据到数据仓库后,从中转区删除该数据。因此中转区的大小通常比生产数据库和数据仓库小,它只包含被提取的但没有被数据仓库处理的数据。我们使用以下定义:
数据中转区是一个存储来自生产系统数据的暂时中间存储器。

6ac82c550cb0d811091f639eb168510854cfeb08

有多个解释用中转区扩展商务智能系统的原因:
通常来说,来自生产系统的数据以一个合适的方式存储到数据仓库之前需要经过很多处理,如错误的值需要转换,遗漏的值需要找出,等等。如果数据直接从生产系统拷贝到数据仓库,所有的进程都能导致这些系统的严重干扰。尽可能小的干扰生产系统、仅仅采取一对一的数据快照并在之后做处理是个好主意。
如果数据仓库中的某些表格仅仅一周或一月更新一次,数据可能遗失。例如,假设在生产系统的一些数据在两次更新期间改变了两次,或者在两次更新中数据已经被插入或删除,此时更新数据仓库,第一次输入数据的旧值和删除的数据就会遗失。为了确保没有插入、删除和更新的数据丢失,所有对数据的改变都应该拷贝到数据中转区。
数据中转区也能用来追踪那些不被数据仓库使用的数据。我们也可能追踪那些想要却还不知道未来怎么在数据仓库环境中使用的数据。换句话说,我们唯一知道的就是未来会对这些数据进行处理,但是还不知道是什么。通过把数据拷贝到中转区中,我们就确保了数据不会丢失。
当中转区中的数据已经转换并拷贝到仓库,它就能被删除了。但是也有理由保存它,在这种情况下,它通常指的是持久中转区。数据中转区通过保存所有的数据,在数据要重新输入到数据仓库时可以使用。注意,一个数据中转区也可能与一个不使用数据仓库只使用数据集市的商务智能系统相关。在这种情况下,数据集市会被来自数据中转区的新数据填补。

2.5.4 可操作数据存储

不管是来自于生产系统还是来自于数据中转区的数据,在它们被存入数据仓库(或者数据集市)之前都需要被预处理(集成、转换、清洗)。可能有其他的IT系统对集成、转换、清洗之后的数据感兴趣。例如,网站的组织可能想以集成的方式访问数据,对于数据管理系统和客户关系系统来说也需要同样的功能。
集成数据的需要贯穿整个IT系统中,有必要使用一个操作数据存储(ODS;如图2-8所示)。操作数据存储可以呈现一个可操作的数据集成视图,现在在生产系统中已经是可用的。

screenshot

Bill Inmon定义了操作数据存储如下(见文献[26]):
操作数据存储是一种集成的可操作数据存储的架构。
操作数据存储是面向主题的,逻辑相符的数据被存储在一起。例如,如果用户的数据被存储在多种系统中,它会一起在操作数据存储中被带来。操作数据存储是被集成的;所有的转换都被应用于使数据之间相符。操作数据存储是不稳定的,当数据被添加到一个产品数据库,或者当它被删除或更新之后,很快就会反映到操作数据存储中。所以操作数据存储应该可以展现一个相对较新的关于操作数据的表述。操作数据存储不是像数据仓库一样是时变的,通常没有历史记录被保留在操作数据存储中。
如果是可利用的,操作数据存储能够从生产系统或者数据中转区中加载。在一些系统中,数据中转区和操作数据存储是合并的。在大多数情况下意味着操作数据存储接管数据中转区的角色。
在合适的位置拥有操作数据存储的这个数据仓库的优点对于已经发生的数据集成和数据转换是很有意义的,可以简化取得数据仓库中数据的工作。

2.5.5 个人数据存储

到目前为止所有被描述的数据存储都为了一群用户在改进。在一些商务智能系统中,数据存储为了个人的使用而被改进。个人数据存储是为了个别用户的需要而特别设计的(如图2-9所示)。个人数据存储可以简单到像一个电子表格一样,由用户设计,存储一些在其他表中用到的代码,或者用来存储一些在数据仓库中不可获得的销售数据等。它也是一个可以包含外部组织数据的简单文件。在大多数情况下,用户想要分析这些数据或者想要将这些数据与内部的数据结合。一些报告和分析工具在用户的机器上创建了一个小型数据库,这也可以被看作个人数据存储。
有时个人数据存储是由于性能原因而创建的,另外一个原因是用户连接不上系统中其他数据。如果个人数据存储被存储在用户的计算机中,即使用户与系统其他部分数据是断开连接的,个人数据存储也能让报告工具工作。
虽然这类数据存储已经部署在很多商务智能系统中,它仍然没有普遍可接受的术语。有些人把个人数据存储视为“个人数据仓库”,或者简称为“立方体”。后面的这个术语来源于一些部署工具的存储技术,也就是基于所谓的多维立方体。在这本书中,我们称它为“个人数据存储”。

screenshot

2.5.6 不同类型数据存储的对比

表2-2对比了前面章节提到所有的不同类型的数据存储。下面是每一类数据的含义:
易变数据表明在数据存储中的数据是否是不断更新的。数据的状态与原始资料数据是同步或者几乎同步的。
详细数据意味着数据存储是否仅仅包括最低水平的细节。
集成数据表明逻辑相符的数据是否存储在一起。
时变的或者历史数据指的是数据存储是否也包括历史数据,即数据较旧的版本。
概括的、聚合的和衍生的数据意味着数据不是粗略地存储,而是以某种方式通过应用聚合从最初原始资料数据中衍生的。
企业级数据意味着数据存储是为了组织的大部分用户而优化的,与此相反的是为了小部分用户而优化的数据存储。
screenshot

注意:在前一节的图中,一个独立的数据库标志用来表示每个数据存储。通过设定名称引入它们,它可以在技术上呈现出这些不同的数据存储被不同的数据库服务器管理的情况,然而,这里不是这种情况。存储所有中转区、数据仓库和数据集市的表在一个大型的服务器管理的数据库中是可能的。是否这么做纯粹是一个技术问题,取决于性能、可拓展性、有效性和安全因素。

相关文章
|
11天前
|
监控 数据可视化 数据挖掘
干货|FESCO Adecco外企德科:Quick BI打造战略管理“观数台”(1)
干货|FESCO Adecco外企德科:Quick BI打造战略管理“观数台”
|
1月前
|
前端开发 Java 开发工具
Java医院绩效考核系统源码:关于医院绩效考核系统的技术架构、系统功能、如何选择医院绩效考核管理系统
系统开发环境 开发语言:java 技术架构:B/S架构 开发工具:maven、Visual Studio Code 前端框架:avue 后端框架:springboot、mybaits 数 据 库:MySQL
35 4
Java医院绩效考核系统源码:关于医院绩效考核系统的技术架构、系统功能、如何选择医院绩效考核管理系统
|
25天前
|
消息中间件 Java API
解析Java微服务架构:从零构建高性能系统
解析Java微服务架构:从零构建高性能系统
|
5天前
|
存储 搜索推荐 API
在单系统内架构形态中,什么是起步时的domain设计
在单系统内架构形态中,什么是起步时的domain设计
|
1月前
|
Kubernetes 测试技术 持续交付
深入理解微服务架构及其在现代后端系统中的应用
本文将深入探讨微服务架构的核心概念、设计原则以及如何在现代后端系统中实现和优化它。我们将从微服务的定义开始,逐步展开讨论其优势、面临的挑战,以及如何克服这些挑战。同时,文章还会涉及微服务与容器化技术、持续集成/持续部署(CI/CD)的协同作用,以及微服务架构的未来发展趋势。读者将获得对微服务架构全面而深刻的理解,并能够识别在实施过程中可能遇到的陷阱和解决方案。
68 1
|
15天前
|
前端开发 Linux Shell
技术心得:基于AR9331(MIPS架构)分析系统启动过程(uboot)
技术心得:基于AR9331(MIPS架构)分析系统启动过程(uboot)
|
1月前
|
设计模式 运维 供应链
探讨微服务架构如何降低系统复杂度
探讨微服务架构如何降低系统复杂度
36 1
|
25天前
|
存储 SQL 网络协议
什么是PACS系统?一套C语言C/S架构PACS影像归档和通信系统源码
PACS系统是基于C/S架构的医学影像归档和通信系统,遵循IHE和DICOM3.0标准,采用Wintel平台与品牌服务器,配备SQL Server数据库,支持双机热备。它确保图像质量和高效传输,兼容多种医学设备,允许历史胶片扫描存储,并有严格的权限管理与安全机制,包括数据备份和故障恢复功能,旨在实现资源共享和效率提升。系统设计考虑了与医院HIS集成及未来扩展。
17 0
|
26天前
|
缓存 前端开发 NoSQL
设计与实现个人博客系统的技术架构与最佳实践
设计与实现个人博客系统的技术架构与最佳实践
|
29天前
|
Linux Perl
如何在Linux系统中确定CPU架构
如何在Linux系统中确定CPU架构
21 0