欧易

欧易(OKX)

国内用户最喜爱的合约交易所

火币

火币(HTX )

全球知名的比特币交易所

币安

币安(Binance)

全球用户最多的交易所

10分钟带你了解数据库、数据仓库、数据湖、数据中台的区别与联系(一)

时间:2022-10-09 14:44:56 | 浏览:2850

作为数据相关的产品小白,在日常学习工作中经常能看到或者听到大家在讨论数据库,数据仓库,数据集市,数据湖还有最近比较火的数据中台,似乎这些名词都与数据存在着联系,查看各类相关书籍,大部分书籍中的内容过于专业晦涩难懂。那么这篇文章结合我积累的相

作为数据相关的产品小白,在日常学习工作中经常能看到或者听到大家在讨论数据库,数据仓库,数据集市,数据湖还有最近比较火的数据中台,似乎这些名词都与数据存在着联系,查看各类相关书籍,大部分书籍中的内容过于专业晦涩难懂。

那么这篇文章结合我积累的相关方面知识,向大家介绍一下上述这些名词的区别与联系,以及在各类企业及业务上的适用范围,如有不准确的地方,希望大家进行指正。

一、何为数据库

相信大部分有些许技术背景的同学们都对数据库有一定的了解,数据库是“按照数据结构来组织、存储和管理数据的仓库”,一般分为“关系型数据库”与“非关系型数据库”。

1. 关系型数据库

实际上过去的数据库一共有三种模型,即层次模型,网状模型,关系模型

(1)首先层次模型的数据结构为树状结构,即是一种上下级的层级关系组织数据的一种方式:

(2)网状模型的数据结构为网状结构,即将每个数据节点与其他很多节点都连接起来:

(3)关系模型的数据结构可以看做是一个二维表格,任何数据都可以通过行号与列号来唯一确定:

由于相比于层次模型和网状模型,关系模型理解和使用最简单,最终基于关系型数据库在各行各业应用了起来。

关系模型的数学原理涉及到关系,元组,属性,笛卡尔积,域等等令人头秃的数学术语,这里大家如果感兴趣可以看看相关的文献,我就不放出来催眠大家了,尽管数学原理非常复杂,但如果用日常学习工作的具体事务举例,就相对容易理解。

我们以某公司的员工信息表为例,该公司的员工信息可以用一个表格存起来。并且定义如下:

同时部门ID对应这另一个部门表:

我们可以通过给定一个部门名称,查到一条部门的记录,根据部门ID,又可以查到该部门下的员工记录,这样二维的表格就通过ID映射建立了“一对多”的关系。

常用的关系型数据库有Oracle,Microsoft SQL Sever,MySQL,DB2。数据库的语言基本上围绕着“增删改查”来进行的,语法相对简单,大家有兴趣可以下载MySQL自学,网上有很多免费的资料。

2. 非关系型数据库

非关系型数据库是以对象为单位的数据结构,非关系型数据库通常指数据以对象的形式存储在数据库中,而对象之间的关系通过每个对象自身的属性来决定。

简单来说非关系型数据库与传统的关系型数据库的区别在于非关系型数据库主要存储没有固定格式的超大规模数据,例如键值对型,文档型,列存储类数据,常见的非关系型数据库有Hbase,Redis,MongoDB,Neo4j等。现在我们通常所说的数据库指的是关系型数据库,非关系型数据库大家了解即可。

二、数据库→数据仓库

1. 例子

随着企业的发展,线上的业务系统随着业务进行会源源不断的产生数据,一般这些数据会存储在我们企业的业务数据库中,也就是上面讲到的关系型数据库,当然不同的企业使用的数据库可能不尽相同例如上述的Oracle,Microsoft SQL Sever,MySQL等,但是底层的技术逻辑都大同小异,这些业务数据库支撑着我们业务系统的正常运行。

但是当我们线上的业务系统运行超过一定时间后,内部积压的数据会越来越多,对我们的业务数据库会产生一定的负载,导致我们业务系统的运行速度较慢,这些数据中有很大一部分是冷数据,因为业务系统一般对我们近期的一些数据比如当天或一周内这些数据调用比较频繁,对比较早的数据调用的频率就会很低。

同时呢目前由于数据驱动业务概念的兴起,各业务部门需要将业务系统的业务数据提取出来进行分析以便更好地进行辅助决策,但各部门需求的数据种类千差万别,接口错综复杂,过多的数据查询脚本以及接口的接入导致业务数据库的稳定性降低。

为了避免冷数据与历史数据收集对我们业务数据库产生的影响,妨碍我们业务的正常运行,企业需要定期将我们冷数据从业务数据库中转移出来存储到一个专门存放历史数据的仓库里面,各部门可以根据自身业务需要进行数据抽取,这个仓库就是数据仓库。

2. 数据仓库的特性

结合上述例子,我们得出数据仓库的以下特性:

  • 解耦:数据仓库的诞生,本质是将数据的收集与分析进行解耦。

  • 整合:数据仓库起到了对不同平台,不同来源的数据的集成整合作用,通过抽取,清洗,转换生成由面向事务转化为面向主体的数据集合。

  • 稳定:数据仓库的数据主要为决策者分析提供数据,一般仅允许查询,不允许修改删除,数据仓库的数据仅定期需要由业务数据库转移,加载,刷新。

  • 历史滞后:数据仓库的数据会定期更新,每隔固定的时间间隔后,抽取业务数据库系统中产生的数据通过数据的转换集成,进入到数据仓库中,所以数据仓库的数据产出具有T+1的特性(离线数据仓库)。

3. 数据库VS数据仓库

再深入一些,我们此时要引入两个新的名词OLTP(On-Line Transaction Processing)联机事务处理与OLAP(On-Line Analytical Processing)联机分析处理,乍听两个名词感觉很高大上,我们此时要关注两个单词的区别,“Transaction”为事务,业务。

所以业务数据库也就是我们之前讲的关系型数据库属于OLTP类型,该类型侧重于基本的,日常的事务处理,是业务系统的“压舱石”,维持正常运行,而“Analytical”则为分析,数据仓库就属于OLAP类型,该类型侧重于复杂的分析,查询操作,是业务系统的“船帆”,提供决策支撑。

三、数据仓库

相信通过上述的案例,我们对数据仓库有了大致的认识,一个简单的数据仓库结构如下图所示,那么接下来我们讲讲数据仓库的相关知识点:

1. ETL(
extraction-transformation-load)抽取-转换-加载

(1)extraction(抽取)

不是所有出现在业务数据库中的数据都需要抽取,抽取需要在调研阶段做大量的工作,首先要搞清楚数据是从几个业务系统中来,各个业务系统的数据库服务器运行什么,是否存在手工数据且手工数据量有多大,是否存在非结构化的数据,某些数据对于分析没有任何价值,这类数据是否需要剔除,当收集完这些信息之后才可以进行数据抽取的设计。

(2)Transformer(转换)

也就是数据的清洗,数据仓库分为两部分,ODS(操作数据存储)及DS(数据仓库),通常的做法是从业务系统到ODS做清洗,将脏数据与不完整数据过滤掉,在从ODS到OW的过程中转换,进行一些业务规则的计算,聚合及数据转换。

a. 数据清洗:业务系统→ODS的过程,过滤那些不符合要求的数据,将过滤的结果交给业务主管部门,确认是否过滤掉还是由业务单位修正之后再进行抽取。

b. 数据转换:ODS→DS的过程,主要进行不同维度的数据转换、数据颗粒度的转换,以及一些业务规则的计算。

  • 不同维度数据转换:将不同业务系统的相同类型的数据进行统一,例如编码转化:不同供应商在不同业务系统的编码不同;字段转换;度量单位的转换等。

  • 数据颗粒度的转换:业务系统存储着颗粒度较细的数据,而数据仓库的数据时用来分析的,不需要颗粒度很细的数据,所以会将业务系统数据按照数据仓库的颗粒度进行转换。

  • 业务规则的计算:企业有不同的数据指