首页 > 其他分享 >大数据架构(二)大数据发展史

大数据架构(二)大数据发展史

时间:2023-04-23 18:45:05浏览次数:49  
标签:数仓 发展史 架构 Kimball 数据仓库 集市 数据

1.传统数仓发展史

传统数据仓库的发展史这里不展开架构细讲,只需快速过一遍即可。了解这个历史发展过程即可。

1.1 传统数仓历史

1.1.1 5个时代

 传统数仓发展史可以称为5个时代的经典论证战。按照两位数据仓库大师 Ralph kilmball、Bill Innmon 在数据仓库建设理念上碰撞阶段来作为小的分界线:

  • 1970~1991 数据仓库概念萌芽到全企业集成。

  • 1991~1994 EDW企业数据集成时代。Bill Innmon 博士出版了《如何构建数据仓库》,范式建模。

  • 1994~1996 数据集市时代。 Ralph Kimball 博士出版了《数据仓库工具箱》,里面非常清晰的定义了数据集市、维度建模。

  • 1996~1997 神仙大战时代(维度建模与范式建模争论)

  • 1998~2001 合并时代,CIF架构。Bill Innmon推出了新的BI架构CIF(Corporation information factory),把Kimball的数据集市也包容进来了,第一次,Kimball承认了Inmon。

1.1.2 经典争论

如果说,Hans Peter Luhn和Howard Dresner,一个为了文本挖掘,一个为了企业管理中的信息民主,而定义了BI(智能商业)的话。那么Bill Inmon 和Ralph Kimball,这2位大师则通过不同理念,设计技术和实施策略使BI从定义落地为真实。两位大师在1991-2001,引领了传统数仓发展的一个时代。

 

 Bill Innmon和Ralph kilmball论证的核心在于EDW(企业级数据仓库)和数据集市的建立先后顺序(也可以理解为范式建模和维度建模的争论)。

  • Bill Inmon 提出自上而下的建设原则(EDW->DM):提倡先数据模型创建企业级数据仓库EDW(3NF范式建模)后,再建数据集市(DM)。
  • Ralph kilmball 提出自下而上的建设原则(DM->EDW):提倡先创建数据集市,认为数据仓库是数据集市的集合,信息总是被存储在多维模型(维度建模)中。后期可根据需要来合并数据集市,并逐步形成企业级的数据仓库(EDW)。

两种方法的明细区别如下表(摘自网络):

1.2 传统数据仓库架构史

  伴随着kilmball和Innmon的经典争论,诞生了三代典型数据仓库架构(网上有些文章把Opdm操作型数据集市架构定义为第四代数据仓库架构,笔者不认可这一架构能和另外3个并列,故删之),分别是:

  • 企业级数据仓库架构(Enterprise Data Warehouse,EDW)-BIll Inmon
  • Kilmball DW/BI(Multidimensional Architecture,MD)-Ralph kilmball
  • 企业信息工厂架构(Corporate Information Factory,CIF)-BIll Inmon

1.2.1 企业级数据仓库架构(Enterprise Data Warehouse,EDW)-BIll Inmon

  90 年代 BIll Inmon 出版《如何构建数据仓库》一书体系化的与明确定义了如何构建数据仓库,这套方法在落地上形成了第一代数据仓库架构。书中定义:数据仓库(Data Warehouse) 是一个面向主题的(Subject Oriented) 、集成的( Integrate ) 、相对稳定的(Non -Volatile ) 、反映历史变化( Time Variant) 的数据集合,用于支持管理决策( Decision Marking Support)。具体如下图所示:

从左至右依次是数据源、数据清洗、数仓、应用。

核心原理:

  • 数据仓库是面向主题的。
  • 数据仓库是集成的,数据仓库的数据有来自于分散的操作型数据,将所需数据从原来的数据中抽取出来,进行加工与集成,统一与综合之后才能进入数据仓库。
  • 数据仓库是不可更新的,数据仓库主要是为决策分析提供数据,所涉及的操作主要是数据的查询。
  • 数据仓库是随时间而变化的,传统的关系数据库系统比较适合处理格式化的数据,能够较好的满足商业商务处理的需求,它在商业领域取得了巨大的成功

 

1.2.2 Kimball DW/BI架构(Multidimensional Architecture,MD)-Ralph kimball

  第二代就是 Kimball DW/BI架构。又称Multidimensional Architecture(MD)多维架构,或Bus Architecture总线架构。即从业务或部门入手,设计面向业务或部门主题数据集市。(网上大部分都说Kimball的数据集市架构,笔者不赞同。Kimball提倡的是维度建模、总线架构思想。Kimball架构甚至都不包含物理的数据集市,而是逻辑概念上的)Kimball DW/BI架构从流程上看是是自底向上的,即从数据集市到数据仓库(DM->DW)的一种敏捷开发方法。这种构建方式可以不用考虑其它正在进行的数据类项目实施,只要快速满足当前部门的需求即可,这种实施的好处是阻力较小且路径很短

  核心原理:一致性维度建模(总线型架构)+ 基于企业总线的数据仓库

  但是考虑到在实施中可能会存在多个并行的项目,是需要在数据标准化、模型阶段是需要进行维度归一化处理,需要有一套标准来定义公共维度,让不同的数据集市项目都遵守相同的标准,在后面的多个数据集市做合并时可以平滑处理。比如业务中相似的名词、不同系统的枚举值、相似的业务规则都需要做统一命名,这里在现在的中台就是全域统一ID之类的东西。具体如下图所示:

注意:kimball架构的数据仓库是没有实际存在数据集市的,如果非要区分,可以通过主题域划分获取自己的数据集市。(比如上图的维度数仓下的交易域数仓,可以理解为逻辑上的数据集市。预留数据集市飞机票//TODO)


1.2.3 企业信息工厂架构(Corporate Information Factory,CIF)-BIll Inmon

  第三代架构就是CIF架构,CIF强制引入了一层规范化的、原子的(满足第三范式)企业数据仓库EDW。这一层承担了数据协调和集成的职责。Inmon 模式从流程上看是自顶向下的,即从数据仓库再到数据集市的(DW->DM)。

  核心原理:Inmon EDW企业数仓(遵循3NF)+ 数据集市。具体如下图所示:

 

混合架构(CIF+Kimball,CIF2.0)

  混合架构是CIF架构的变种,可以认为是CIF2.0架构。BIll Inmon把Kimball的多维架构融入进来(据说Inmon很生气,没能说服Kimball,一气之下把Kimball架构也融进去了...)。并限定EDW不对外提供查询能力,其中的数据是维度的、原子的、以过程为中心的。这种架构主要适用于前期已经购入建设了原子级的EDW,但尚无法满足用户的灵活的分析需求,在这种情况下可以采用这种架构,算是一种无奈之举。 缺点很明显,EDW和维度数仓数据冗余造成资源浪费,架构复杂导致人力成本较高。

  核心原理:Inmon EDW企业数仓(遵循3NF)+ Kimball 维度数仓(一致性维度)

 

2. 大数据架构发展史

 根据大数据架构发展史,总结出历史发展如下图:

最终都会走向批流一体、湖仓一体的架构。

2.1 第一代:离线统计分析技术架构

特点:

1、数据源通过离线的方式导入到离线数仓中;
2、数据处理采用MapReduce、Hive、SparkSQL 等离线计算引擎。 架构及数据处理流程如下;

 

 

2.2 第二代:Lambda架构(离线+实时结合)--2011

  随着大数据应用的发展,人们逐渐对系统的实时性提出了要求,为了计算一些实施指标,就在原来离线数仓的基础上增加了一个实时计算的链路,并对数据源做流式改造(即把数据发送到消息队列),实时计算去订阅消息队列,直接完成指标做增量的计算,推送到下游的数据服务中去,由数据服务层完成离线&实时结果的合并。Lambda架构如下图所示:

 

2.3 第三代:Kappa架构(批流一体)--2014

  Lambda 架构虽然满足了实时的需求,但带来了更多的开发与运维工作,其架构背景是流处理引擎还不完善,流处理的结果只作为临时的、近似的值提供参考。 后来随着Flink等流处理引擎的出现,流处理技术很成熟了,这时为了解决两套代码的问题。 Linkedln 的 Jay Kreps 提出了 Kappa 架构,在实时计算中可以直接完成计算,也可以跟离线数仓一 样分层,取决于指标的复杂度,各层之间通过消息队列交互(多半是不分层的),Kappa 架构可以认为是 Lambda 架构的简化版(只要移除 Lambda 架构中的批处理部分即可)。Kappa 架构如下图所示:

 

2.4 第四代:基于MPP数据库的实时统一数仓架构---数仓增强-2017

  面对越来越强的OLAP数据分析需求,新一代高性能MPP数据库高速发展:2016年Clickhouse、2017年Doris相继面世。Flink(同步+计算)+Doris(同步+存储)的实时数仓架构流行起来。架构如下图所示:

 

2.5 第五代:基于数据湖实时数仓架构-数据湖增强(湖仓一体)-2019

数据湖最早是由Pentaho的创始人兼CTO, 詹姆斯·迪克森(James Dixon),在2010年10月纽约Hadoop World大会上提出来的。但再国内一直到19年三大数据湖开源后,才真正火起来。其中又以Flink+Iceberg应用范围最广。实现了计算的批流一体、存储的湖仓一体。架构如下图所示:

 

 

 

 

 

 

 

 

 

=====================================

透过数字化转型再谈数据中台(三):一文遍历大数据架构变迁史  松子(李博源)

Greenplum 实时数据仓库实践(1)——数据仓库简介

第一章 数据仓库和商业智能(二)

kimballgroup官网:The Kimball bus architecture and the Corporate Information Factory: What are the fundamental differences?

标签:数仓,发展史,架构,Kimball,数据仓库,集市,数据
From: https://www.cnblogs.com/dennyzhangdd/p/17262204.html

相关文章

  • C++数据结构(栈)
    栈是一种受限的线性表,将允许插入和删除的操作的一端称为栈顶,另一端称之为栈底,向栈中插入元素叫入栈,删除元素叫出栈。栈被称为是后进先出的线性表(LIFO)顺序栈顺序存储,即使用一段连续内存空间依次存储栈中数据。这里通过一维数组动态分配内存的方式保存数据定义代码如下:#defi......
  • docker 的数据、资源管理
    一、CPU控制cgroups,是一个非常强大的linux内核工具,他不仅可以限制被namespace隔离起来的资源,还可以为资源设置权重、计算使用量、操控进程启停等等。所以cgroups(Controlgroups)实现了对资源的配额和度量。cgroups有四大功能:资源限制:可以对任务使用的资源总额进行限制;......
  • 当⻉借⼒阿⾥云落地云原⽣架构转型,运维降本、效率稳定性双升
    作者:当贝技术团队随着业务飞速发展,当贝的传统IT资产也渐显臃肿,为了避免制约发展的瓶颈,痛定思痛,技术团队果断变革:核心业务云原生化之后,运维效率、整体稳定性和研发效率均得到了全面提升。本文主要简述当贝技术团队云原生之路的背景诉求、落地方法和收获成果。前言当贝成立于......
  • docker的数据管理
    一、如何管理docker容器中的数据管理Docker容器中数据主要有两种方式:数据卷(DataVolumes)和数据卷容器(DataVolumesContainers)。二、数据卷2.1原理将容器内部的配置文件目录,挂载到宿主机指定目录下数据卷默认会一直存在,即使容器被删除宿主机和容器是两个......
  • 实验三 控制语句与组合数据类型应用编程
    task1源代码1importrandom23print('用列表存储随机整数:')4lst=[random.randint(0,100)foriinrange(5)]5print(lst)67print('\n用集合存储随机整数:')8s1={random.randint(0,100)foriinrange(5)}9print(s1)1011print('......
  • PageView与数据库 分页
    <?xmlversion="1.0"encoding="UTF-8"?><%@pagelanguage="java"contentType="text/html;charset=UTF-8" pageEncoding="UTF-8"%><%@includefile="/inc/incTagLib.jsp"%><%@tagli......
  • 直播预告 | 字节跳动云原生大数据分析引擎 ByConity 与 ClickHouse 有何差异?
    ByContiy是字节跳动开源的一款云原生的大数据分析引擎,擅长交互式查询和即席查询,具有支持多表关联复杂查询、集群扩容无感、离线批数据和实时数据流统一汇总等特点。ByConity从1月份发布开源beta版本之后,陆续收到社区询问ByConity和ClickHouse差异的反馈:“ByConity有没......
  • MySQL日期字符串转日期格式,日期格式数据转为字符串
    如下:1、日期字符串转换为日期格式数据SELECTDATE('2017-02-11');SELECTDATE('2017/02/11');SELECTSTR_TO_DATE('2015/02/25','%Y/%m/%d');SELECTSTR_TO_DATE('2015-02-25','%Y-%m-%d');返回日期格式数据 2、DATE_FORMAT......
  • mysql select for update + 事务处理数据一致性
    如果SELECT后面若要UPDATE同一个表数据的相关操作,最好使用SELECT...FORUPDATE。一:举例说明假设商品表单test_leyangjun 内有一个存放商品库存的num字段,一个id主键 ,在生成订单前须先确定num>0 ,然后才把数量更新。代码如下(比如现在的库存:num=3对应的id=3,现在生成一个订单......
  • 数据库和缓存数据一致性
    不好的方案1.先写MySQL,再写Redis图解说明:这是一副时序图,描述请求的先后调用顺序;橘黄色的线是请求A,黑色的线是请求B;橘黄色的文字,是MySQL和Redis最终不一致的数据;数据是从10更新为11;后面所有的图,都是这个含义,不再赘述。请求A、B都是先写MySQL,然后再写......