编辑导语:作为一名数据小白,在日常学习和工作中经常会接触到数据。随着用户数据与业务数据的不断累加,数据管理与处理愈发重要。本篇文章中,作者将一文说明数据库、数据仓库、数据湖、数据中台的区别与联系。
作为数据相关的产品小白,在日常学习工作中经常能看到或者听到大家在讨论数据库,数据仓库,数据集市,数据湖还有最近比较火的数据中台,似乎这些名词都与数据存在着联系,查看各类相关书籍,大部分书籍中的内容过于专业晦涩难懂。
那么这篇文章结合我积累的相关方面知识,向大家介绍一下上述这些名词的区别与联系,以及在各类企业及业务上的适用范围,如有不准确的地方,希望大家进行指正。
相信大部分有些许技术背景的同学们都对数据库有一定的了解,数据库是“按照数据结构来组织、存储和管理数据的仓库”,一般分为“关系型数据库”与“非关系型数据库”。
实际上过去的数据库一共有三种模型,即层次模型,网状模型,关系模型。
(1)首先层次模型的数据结构为树状结构,即是一种上下级的层级关系组织数据的一种方式:
(2)网状模型的数据结构为网状结构,即将每个数据节点与其他很多节点都连接起来:
(3)关系模型的数据结构可以看做是一个二维表格,任何数据都可以通过行号与列号来唯一确定:
由于相比于层次模型和网状模型,关系模型理解和使用最简单,最终基于关系型数据库在各行各业应用了起来。
关系模型的数学原理涉及到关系,元组,属性,笛卡尔积,域等等令人头秃的数学术语,这里大家如果感兴趣可以看看相关的文献,我就不放出来催眠大家了,尽管数学原理非常复杂,但如果用日常学习工作的具体事务举例,就相对容易理解。
我们以某公司的员工信息表为例,该公司的员工信息可以用一个表格存起来。并且定义如下:
同时部门ID对应这另一个部门表:
我们可以通过给定一个部门名称,查到一条部门的记录,根据部门ID,又可以查到该部门下的员工记录,这样二维的表格就通过ID映射建立了“一对多”的关系。
常用的关系型数据库有Oracle,Microsoft SQL Sever,MySQL,DB2。数据库的语言基本上围绕着“增删改查”来进行的,语法相对简单,大家有兴趣可以下载MySQL自学,网上有很多免费的资料。
非关系型数据库是以对象为单位的数据结构,非关系型数据库通常指数据以对象的形式存储在数据库中,而对象之间的关系通过每个对象自身的属性来决定。
简单来说非关系型数据库与传统的关系型数据库的区别在于非关系型数据库主要存储没有固定格式的超大规模数据,例如键值对型,文档型,列存储类数据,常见的非关系型数据库有Hbase,Redis,MongoDB,Neo4j等。现在我们通常所说的数据库指的是关系型数据库,非关系型数据库大家了解即可。
随着企业的发展,线上的业务系统随着业务进行会源源不断的产生数据,一般这些数据会存储在我们企业的业务数据库中,也就是上面讲到的关系型数据库,当然不同的企业使用的数据库可能不尽相同例如上述的Oracle,Microsoft SQL Sever,MySQL等,但是底层的技术逻辑都大同小异,这些业务数据库支撑着我们业务系统的正常运行。
但是当我们线上的业务系统运行超过一定时间后,内部积压的数据会越来越多,对我们的业务数据库会产生一定的负载,导致我们业务系统的运行速度较慢,这些数据中有很大一部分是冷数据,因为业务系统一般对我们近期的一些数据比如当天或一周内这些数据调用比较频繁,对比较早的数据调用的频率就会很低。
同时呢目前由于数据驱动业务概念的兴起,各业务部门需要将业务系统的业务数据提取出来进行分析以便更好地进行辅助决策,但各部门需求的数据种类千差万别,接口错综复杂,过多的数据查询脚本以及接口的接入导致业务数据库的稳定性降低。
为了避免冷数据与历史数据收集对我们业务数据库产生的影响,妨碍我们业务的正常运行,企业需要定期将我们冷数据从业务数据库中转移出来存储到一个专门存放历史数据的仓库里面,各部门可以根据自身业务需要进行数据抽取,这个仓库就是数据仓库。
结合上述例子,我们得出数据仓库的以下特性:
再深入一些,我们此时要引入两个新的名词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的过程,主要进行不同维度的数据转换、数据颗粒度的转换,以及一些业务规则的计算。
(3)Load(加载)
将清洗及转换过的数据加载到数据仓库,一般分为全量加载及增量加载。
小结:ETL是数据仓库开发中最耗资源的一环,因此该环节要整理各业务系统中杂乱无章的数据,工作量很大,但也是搭建数据仓库的最重要的环节。
ODS(Operation Data Store)操作数据存储在业务数据库与数据仓库之间形成一个隔离,其存在可以避免数据仓库直接调用业务数据库的数据,保持数据在结构上与业务数据库一致,起到提高业务数据库稳定性,降低数据抽取复杂性的作用。
鉴于ODS上述特点,数据会按照特定时间源源不断地写入ODS中,且一经写入的数据不能被删除,修改。所以为了提高ODS的运行效率,一般ODS会考虑使用分布式文件存储系统。
DM(Data Market)数据集市是以某个业务应用为出发点而建设的局部的数据仓库,所以DM数据集市的特点在于结构清晰,针对性强且扩展性良好,由于仅仅对某一个领域建立,容易维护修改。
数据集市分为独立数据集市与非独立数据集市,其中独立数据集市有独有的源数据库与ETL架构。而非独立数据集市则没有自己的源数据,全部数据位于数据仓库,开发人员通过权限的设置,为用户提供面向其业务的数据,该数据为数据仓库的子集。
对于管理企业的人员一般来说有两种特征,开放性与有序性,创业公司的人思想往往比较开放,但管理大型公司的人更注重秩序,同理这个概念可以使用在如今的数据结构中,开放意味着容易接受新信息以及接纳新的观点,创业公司拥抱开放的原因他们必须学会打破常规,在市场中创造新的价值。
有序则指的是采取已证明是成功的模式,这通常意味着排除那些不太可能成功的想法和信息。
开放性的特征直接指向数据湖的概念,数据湖是新数据可以不受任何限制地进入的地方,在这里,任何数据都可以存在,因此这里是发现新想法,用数据实验绝妙来源,但同时因为其对任何数据的开放性,使得其缺乏有意义的结构,对于数据量较大时,就显得有些混乱了。
有序性直接指向数据仓库,在数据仓库中,我们将维度和指标视为可查询的,这是可以统一管理,且更容易被不断扩大的受众消费。
由于篇幅所限,本篇文章为《10分钟带你了解数据库、数据仓库、数据湖、数据中台的区别与联系》的第一部分,第二部分会为大家介绍湖仓一体,数据中台的相关知识以及数据库、数据仓库、数据湖与数据中台在各类企业及业务上的适用范围。
本文由 @快乐的给予 原创发布于人人都是产品经理,未经许可,禁止转载
题图来自 Unsplash,基于 CC0 协议