独家 | 一文盘点数据集市和数据仓库的差异(附链接)

简介:

当一家企业开始应用商业智能(Business Intelligence,BI)的战略和技术时,首先需要明确数据集市和数据仓库的区别。理解这种差异将决定你采用何种BI架构和数据驱动决策。

商业智能的目标是运用技术将数据转化为可执行的想法,并帮助终端用户在信息更完备的情况下做出商业决定,不论是理论战略还是实际战略。在阐述各自的实例和结构特点前,本文将先对各自的重要概念进行定义。

数据集市定义

数据集市是一个面向主题的数据存储库,其服务于特定的业务领域,如金融或销售。以下是数据集市的一些重要的典型特征。

 ●  仅包含与特定业务或功能单元相关的源数据。
 ●  数据集市的规模通常是几十GB的数量级。
 ●  通常只保存汇总数据,一些数据集市可能会包含完整的细节。
 ●  数据集市的搭建要花费不少于一万美元,以及3-6个月的时间。
 ●  基于数据集市工具得到的决策是影响特定部门运营方式的战术决策。

数据仓库定义

数据仓库是用于一个企业内的存储库,包含来自不同业务、系统和部门的集成数据。关于数据仓库类型,请参照如下文章。

附链接:

https://blog.panoply.io/i-choose-you-criteria-for-selecting-a-data-warehouse-platform

以下是数据仓库的特征:

 ●  包含来自业务中的多个单元/主题区域的数据。
 ●  数据仓库的大小通常为TB量级,至少也要超过100GB。
 ●  存储的详细信息级别很高,包括原始数据、汇总数据和元数据。
 ●  然而,搭建内部系统的成本通常要超过10万美元,而随着数据仓库服务的普及,云计算模式降低了成本。
 ●  特定工具的业务用户想通过数据仓库信息来做出更明智的战略业务决策,这会影响整个公司。

经典的Inmon 和 Kimball争论

区分数据集市和数据仓库是非常重要的,这源于数据仓库先驱Bill Inmon和Ralph Kimball提出的两种截然不同的数据建模方法之间的争论。

Ralph Kimball认为,最好的方法是从最重要的业务方面或部门入手,从这些方面可以产生面向特定业务线的数据集市。随着时间的推移,企业可以根据需要合并其数据集市以形成数据仓库。Kimball的方法被称为自下而上(bottom-up)。

Bill Inmon认为仅仅将数据集市结合起来是不够的。他提倡创建数据仓库,作为企业数据模型的物理表示,可以根据需要为特定的业务单元创建数据集市。

每种方法都有各自的优点,许多因素会影响你的决定。应该从数据集市入手,还是从数据仓库入手,要基于你从事的行业考虑。

例如,保险公司显然需要从一开始就有一个高层次的概述,包括所有影响其业务模型和战略选择的因素,包括人口统计数据、股票市场趋势、索赔历史、统计概率等,因此采用Inmon方法并从数据仓库开始是最有意义的。

对于中小型营销企业来说,从数据集市入手更合适。如果该业务扩展,未来会包括多个子部门和业务线,可以在以后将每个业务线的数据集市合并到数据仓库中,就像Kimball方法一样。

结构化细节

大多数数据库都是规范化的,这样优化可以使事务处理的速度更快,比如添加或删除数据。规范化的工作方式是重新组织数据,使其不包含冗余数据,并将相关数据分离到表中,在指定关系的表之间使用连接。

数据仓库/市场通常使用非规范化的数据结构,其中管理员通过向规范化数据添加冗余数据来减少分析查询的运行时间,从而提高查询性能。

一个重要的概念是提取、转换和加载(ETL)。ETL从多个数据源提取数据,基于特定的规则对数据进行转换以满足业务需求,最后将数据加载(写入)到目标系统中。

如果从数据仓库入手,通常使用ETL将数据直接从源系统获取到数据仓库,然后根据需要从数据仓库获取到数据集市。如果采用Kimball方法并从数据集市入手,只需将相关源系统中的数据写入适当的数据集市,然后再执行ETL过程,以便从数据集市创建数据仓库。

小结

由于时间限制和资源限制,除了最成熟的企业之外,所有企业都应该从数据集市开始,并随着时间的推移逐步开发数据仓库。然而,云计算缩短了时间并降低了构建企业数据仓库的成本,企业数据仓库可以提供对组织数据的单一视图的访问。


原文发布时间为:2018-11-9

本文作者:By Gilad David Maayan

本文来自云栖社区合作伙伴“数据派THU”,了解相关信息可以关注“数据派THU”。

相关实践学习
使用CLup和iSCSI共享盘快速体验PolarDB for PostgtreSQL
在Clup云管控平台中快速体验创建与管理在iSCSI共享盘上的PolarDB for PostgtreSQL。
AnalyticDB PostgreSQL 企业智能数据中台:一站式管理数据服务资产
企业在数据仓库之上可构建丰富的数据服务用以支持数据应用及业务场景;ADB PG推出全新企业智能数据平台,用以帮助用户一站式的管理企业数据服务资产,包括创建, 管理,探索, 监控等; 助力企业在现有平台之上快速构建起数据服务资产体系
相关文章
|
3月前
|
SQL 关系型数据库 MySQL
在云数据仓库AnalyticDB MySQL版中,有几个参数可能影响SELECT查询的执行及其稳定性
在云数据仓库AnalyticDB MySQL版中,有几个参数可能影响SELECT查询的执行及其稳定性【1月更文挑战第16天】【1月更文挑战第80篇】
290 4
|
1月前
|
SQL Cloud Native 关系型数据库
AnalyticDB MySQL湖仓版是一个云原生数据仓库
【2月更文挑战第15天】AnalyticDB MySQL湖仓版是一个云原生数据仓库
24 2
|
3月前
|
分布式计算 DataWorks 关系型数据库
在云数据仓库AnalyticDB MySQL版中,LIMIT的大小是由系统参数max_limit控制的
【1月更文挑战第7天】【1月更文挑战第31篇】在云数据仓库AnalyticDB MySQL版中,LIMIT的大小是由系统参数max_limit控制的
30 1
|
4月前
|
存储 分布式计算 关系型数据库
云原生数据仓库AnalyticDB MySQL湖仓版架构升级,持续释放技术红利!
云原生数据仓库AnalyticDB MySQL湖仓版架降价23%!持续提供高性价比的产品服务
|
4月前
|
存储 分布式计算 关系型数据库
|
7月前
|
Cloud Native OLAP 关系型数据库
云原生数据仓库AnalyticDB MySQL版/PostgreSQL版(二)
云原生数据仓库AnalyticDB MySQL版/PostgreSQL版(二)
162 0
|
11月前
|
Cloud Native OLAP
《阿里云产品手册2022-2023 版》——云原生数据仓库 AnalyticDB
《阿里云产品手册2022-2023 版》——云原生数据仓库 AnalyticDB
201 0
|
11月前
|
存储 SQL 弹性计算
《云原生一站式数据库技术与实践》——二、云原生数据仓库AnalyticDB MySQL高性能存储引擎(1)
《云原生一站式数据库技术与实践》——二、云原生数据仓库AnalyticDB MySQL高性能存储引擎(1)
545 1
|
11月前
|
存储 Cloud Native 前端开发
《云原生一站式数据库技术与实践》——二、云原生数据仓库AnalyticDB MySQL高性能存储引擎(2)
《云原生一站式数据库技术与实践》——二、云原生数据仓库AnalyticDB MySQL高性能存储引擎(2)
494 1