ToB企服应用市场:ToB评测及商务社交产业平台

标题: 数仓架构：离线数仓、实时数仓Lambda和Kappa、湖仓一体数据湖 [打印本页]

作者: 滴水恩情 时间: 昨天 19:33
标题: 数仓架构：离线数仓、实时数仓Lambda和Kappa、湖仓一体数据湖
往期推荐

  大数据HBase图文简介-CSDN博客
  数仓分层ODS、DWD、DWM、DWS、DIM、DM、ADS-CSDN博客
  数仓常见名词解析和名词之间的关系-CSDN博客
  =========================================================================
目次
往期推荐
1. 数仓架构
1.1 离线数仓架构
1.1.1 数据集市架构
1.1.1.2 独立数据集市
1.1.1.2 附属数据集市
1.1.2 Inmon企业信息工厂架构
1.1.3 Kimball数据堆栈架构
1.1.4 混合型数据堆栈架构
1.2 实时数仓架构
1.2.1 Lambda架构
1.2.1.1 传统的Lambda实时开发
1.2.1.2 升级的Lambda实时开发
1.2.1.3 为什么Lambda架构同时存在流处理和批处理？
1.2.1.4 Lambda架构缺点
1.2.2 Kappa架构
1.2.2.1 Kappa架构缺点
1.2.3 Kappa和Lambda对比
1.2.4 湖仓一体—数据湖
=========================================================================
1. 数仓架构

数仓架构大致分为离线数仓架构和实时数仓架构，数仓架构可以简单理解为构成数仓的各层关系，如ODS、DWM、DWD、DWS，具体分层这里不赘述。

1.1 离线数仓架构

显而易见，这种架构不能处理实时数据，那么必然会有数据的流失。
  任何事物都是随着时间的演进变得越来越完善，当然也是越来越复杂，数仓也不例外。
  离线数仓架构包括数据集市架构、Inmon企业信息工厂架构、Kimball数据堆栈架构、混合型数据堆栈架构，接下来就详细说说这几种架构。


1.1.1 数据集市架构

数据集市架构重点在于集市二字，数据集市是按主题域组织的数据聚集，用于支持部门级的决策。有两种范例的数据集市：独立数据集市和附属数据集市。

1.1.1.2 独立数据集市

  独立数据集市会合于部门所关心的单一主题域，数据以部门为底子，例如制造部门、人力资源部门和其他部门都各自有他们本身的数据集市。

优点：因为一个部门的业务相对于整个企业要简单，数据量也小得多，所以部门的独立数据集市周期短、见效快。
缺点：独立数据集市各自为政。从业务角度看，当部门的分析需求扩展或者跨部门跨主题域分析时，独立数据市场会力不从心。当数据存在歧义，好比同一个产物在A部门和B部门的定义不同，将无法在部门间进行信息比较。每个部门利用不同的技术，创建不同的ETL的过程，处理不同的事务系统，而在多个独立的数据集市之间还会存在数据的交织与重叠，甚至会有数据不一致的环境！

1.1.1.2 附属数据集市

  附属数据集市的数据泉源于数据堆栈，即附属于数据堆栈。

优点：

性能：当数据堆栈的查询性能出现问题，可以考虑创建几个附属数据集市，将查询从数据堆栈移出到数据集市。
安全：每个部门可以完全控制他们本身的数据。
数据一致：因为每个数据集市的数据泉源都是同一个数据堆栈，有用消除了数据不一致的环境。

1.1.2 Inmon企业信息工厂架构

Inmon架构是范式建模
企业级数据堆栈是企业级别的，正如Inmon数据堆栈所定义的，企业级数据堆栈是一个细节数据的集成资源库。此中的数据以最低粒度级别被捕获，存储在满足三范式设计的关系数据库中。
部门级数据集市是企业中部门级别的，是面向主题数据的部门级视图，数据从企业级数据堆栈获取。数据在进入部门数据集市时大概进行聚合。数据集市利用多维模型设计，用于数据分析。重要的一点是，所有的报表工具、BI 工具或其他数据分析应用都应该从数据集市查询数据，而不是直接查询企业级数据堆栈。

1.1.3 Kimball数据堆栈架构

对比上一张图可以看到，Kimball与Inmon两种架构的主要区别在于数据堆栈的设计和创建。 Kimball的数据堆栈包含高粒度的企业数据，利用多维模型设计，是维度建模，这也意味着数据堆栈由星型模式的维度表和究竟表构成。分析系统或报表工具可以直接访问多维数据堆栈里的数据。
在此架构中的数据集市也与Inmon中的不同。这里的数据集市是一个逻辑概念，只是多维数据堆栈中的主题域划分，并没有本身的物理存储，也可以说是虚拟的数据集市。

1.1.4 混合型数据堆栈架构

所谓的混合型结构，指的是在一个数据堆栈环境中，联合利用Inmon和Kimball两种架构。
从架构图可以看到，这种架构将Inmon方法中的数据集市替换成了一个多维数据堆栈，而数据集市则是多维数据堆栈上的逻辑视图。
利用这种架构的利益是：既可以利用规范化设计消除数据冗余，包管数据的粒度足够细；又可以利用多维结构更灵活地在企业级实现报表和分析。

1.2 实时数仓架构

在某些场景中，数据的代价随着时间的推移而逐渐淘汰。所以在传统大数据离线数仓的底子上，逐渐对数据的实时性提出了更高的要求。

1.2.1 Lambda架构

1.2.1.1 传统的Lambda实时开发

上述架构，在实时计算链路中，假如存在多个实时业务，每个业务都要对本身的数据进行数据洗濯等操作，而数据洗濯这操作是重复的。所以对其进行了如下优化，进步数据复用

1.2.1.2 升级的Lambda实时开发

对实时链路进行数据分层，改成实时数仓，办理了数据复用的问题，可以对数据进行统一洗濯等操作。

1.2.1.3 为什么Lambda架构同时存在流处理和批处理？

假如整个系统只有一个批处理层，会导致用户必须等待很久才能获取计算结果，一般有时间延迟。电商数据分析部门只能检察前一天的统计分析结果，无法获取当前的结果，这对于实时决策来说有一个巨大的时间鸿沟，很大概导致管理者错过最佳决策时机。
Lambda架构属于较早的一种架构方式，早期的流处理不如现在这样成熟，在准确性、扩展性和容错性上，流处理层无法直接取代批处理层，只能给用户提供一个近似结果，还不能为用户提供一个一致准确的结果。因此Lambda架构中，出现了批处理和流处理并存的现象。

1.2.1.4 Lambda架构缺点

不管是传统的照旧升级后的Lambda架构，严格来说并不是纯正的实时数仓，而是离线+实时！这就导致Lambda有如下缺点：

同样的需求要开发两套一样的代码，好比批处理要统计昨天一天的人数，流处理要统计实时在线人数，都是统计人数，却要开发两套代码。
跑两套雷同的代码，集群资源利用增多
离线结果和实时结果大概不一致，当然以离线为主
离线批量计算T+1大概算不完，数据量大
服务器存储压力大

既然离线数仓占用计算压力大，存储压力大，那就不利用离线，利用纯实时的kappa架构

1.2.2 Kappa架构

1.2.2.1 Kappa架构缺点

只支持流处理，没有批处理
利用kafka进行消息缓存，kafka不支撑海量数据存储，数据存储也有时间限定
kafka不支持OLAP，即无法用SQL语句进行简单的数据校验
无法复用数据血缘管理体系（数据治理），因为kafka没有schema那种字段
kafka中的数据是append追加，不支持数据的更新、插入

1.2.3 Kappa和Lambda对比

1.2.4 湖仓一体—数据湖

基于Lambda和Kappa架构的缺点，出现了批流一体

从架构角度来看类似Lambda架构，批流一体既可以处理批数据，又可以处理流数据；
从计算框架角度来看，就是flink、spark框架，既支持批处理，又支持流处理；
从SQL角度来看，就是数仓各层统一支持SQL，这就弥补了kappa中kafka不支持SQL的缺点；
从存储层面来看，能做到海量数据的存储，而不是像kappa一样存储在kafka缓存中；

Kafka 换成了 Iceberg，IceBerg就是数据湖技术的一种，介于上层计算引擎和底层存储格式之间的一个中间层，我们可以把它定义成一种“数据组织格式”，底层存储照旧 HDFS。除此之外数据湖另有Hudi（发展最完善）这里不具体论述。
数据湖支持SQL查询，办理了如下问题：

存储统一
底层存储是HDFS，办理了kafka存储量小，数据有时间限定的问题
恣意分层都可以OLAP（支持SQL查询）
Iceberg有Schema概念，可以追踪数据的血缘关系（数据治理）
支持数据实时更新，数据可以update/insert

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)