大数据架构体系演进

传统离线大数据架构

21世纪初随着互联网时代的到来，数据量暴增，大数据时代到来。Hadoop生态群及衍生技术慢慢走向“舞台”，Hadoop是以HDFS为核心存储，以MapReduce（简称MR）为基本计算模型的批量数据处理基础设施，围绕HDFS和MR，产生了一系列的组件，不断完善整个大数据平台的数据处理能力，例如面向KV操作的HBase、面向SQL分析的Hive、面向工作流的PIG等。以Hadoop为核心的数据存储及数据处理技术逐渐成为数据处理中的“中流砥柱”

在这里插入图片描述

这个时期，在企业信息化的过程中，随着信息化工具的升级和新工具的应用，数据量变的越来越大，数据格式越来越多，决策要求越来越苛刻，数据仓库技术在大数据场景中被广泛使用。大数据中的数据仓库构建就是基于经典数仓架构而来，使用大数据中的工具来替代经典数仓中的传统工具，架构建设上没有根本区别。在离线大数据架构中离线数仓结构如下
在这里插入图片描述

传统离线大数据架构【早期比较多】

增加离线：

Spring boot + Flink 任务量大，JOB多

HDFS+MR；Hive传统分层分析【可增加标签层】

Hive+Spark[推荐]

Hive+Tez

随着数据处理能力和处理需求的不断变化，越来越多的用户发现，批处理模式无论如何提升性能，也无法满足一些实时性要求高的处理场景，流式计算引擎应运而生，例如Storm、Spark Streaming、Flink等。

以上离线大数据架构不能够处理实时性业务，早期，很过公司都是基于Storm来处理处理实时性比较强的业务场景，随着越来越多的应用上线，大家发现，其实批处理和流计算配合使用，才能满足大部分应用需求。而对于用户而言，其实他们并不关心底层的计算模型是什么，用户希望无论是批处理还是流计算，都能基于统一的数据模型来返回处理结果，于是Lambda架构被提出。

Lambda架构

在Lambda架构中，为了计算一些实时指标，就在原来的离线数仓基础之上增加了一个实时计算的链路，并对数据源做流式改造：把消息发送到消息队列中（大数据中常用Kafka），实时计算去消费消息队列中的数据，完成实时指标计算，推送到下游的数据服务中去，由数据服务层完成离线与实时结果的合并。

Lambda架构中数据从底层的数据源开始，经过各种各样的格式进入大数据平台，在大数据平台中经过Kafka、Flume等数据组件进行收集，然后分成两条线进行计算。一条线是进入流式计算平台（例如 Storm、Flink或者Spark Streaming），去计算实时的一些指标，保证数据实时性；另一条线进入批量数据处理离线计算平台（例如Mapreduce、Hive，Spark SQL），去计算T+1的相关业务指标，这些指标需要隔日才能看见，保证数据有效、准确性。

根据实时业务统计的复杂程度Lambda架构也分为以下两种情况。

离线数据+实时处理链路(传统实时开发)

在这里插入图片描述

注意：“烟囱式”开发：在一个有一定规模的企业中，通常都会存在各种各样的应用系统，它们分别由企业的各个不同部门、在各种不同历史时期、为满足各种不同业务目的而开发。由于数据格式没有统一规范，相互之间没有联通、数据更没有整合，像一个个烟囱，因此称其为“烟囱式系统”。同样，在数据处理过程中，各个数据处理程序之间不能很好做到数据规范统一、处理数据流程统一、数据复用，各自独立，叫做“烟囱式”开发

离线数仓+实时数仓

随着企业实时业务增多，统计的实时指标越来越多，复杂程度也越来越高，为了在实时链路中更好的复用数据，这是就有必要在实时链路中加入数据分层设计，构建真正的实时数仓。这种场景下Lambda架构中是由离线数仓和实时数仓两部分组成

实时数仓:HBase+phoenix+Redis 作为主题，事实，维度表等存储
在这里插入图片描述

可能重复消费，数据丢失，延迟过大等等

T+1计算

24h

离线：100G*1

实时：100Gx1024x1024/(24x60x60) 耗时

Kappa架构

Kappa架构【】几乎没有离线数据

随着Flink等流式处理引擎的不断完善，流处理技术相关的技术成熟发展（例如：Kafka、ClickHouse），针对Lambda架构的需要维护两套程序等以上缺点，LinkedIn的Jay Kreps结合实际经验和个人体会提出了Kappa架构。

Kappa架构的核心思想是通过改进流计算系统来解决数据全量处理的问题，使得实时计算和批处理过程使用同一套代码。此外Kappa架构认为只有在有必要的时候才会对历史数据进行重复计算，而如果需要重复计算时，Kappa架构下可以启动很多个实例进行重复计算,方式是通过上游重放完成(从数据源拉取数据重新计算)。

Kappa架构就是基于流来处理所有数据，流计算天然的分布式特征，注定了他的扩展性更好，通过加大流计算的并发性，加大流式数据的“时间窗口”，来统一批处理与流式处理两种计算模式。其架构如下

在这里插入图片描述

离线：重复消费kafka【或其他消息队列等中间件】。存储Hive。辅助于数据挖掘【每月，每季度等计算一次】

数据发布or展示，需求变动。可用读取kafka主题信息数据。重新整理

Doris【OLAP工具】；如果作为实时数仓，数据量小可以，数据量过多。关联性非常差不作为推荐——doris实时数据仓库理论与实战作者：吴百豹

kafka不可计算SQL（可选用KSQL），puslar可操作SQL【来自官网描述】

实时数仓逻辑走向

在这里插入图片描述

湖仓一体

实时数仓发展到现在的架构，一定程度上解决了数据报表时效性问题，但是这样的架构依然存在不少问题，随着技术的发展，基于Kafka+Flink的实时数仓架构也会进一步往前发展，

那么到底往哪些方向发展，我们可以结合大公司中技术选型可以推测实时数仓的发展大致会走向“批流一体”

最近一两年中和实时数仓一样火的概念是“批流一体”，那么到底什么是“批流一体”？在业界中很多人认为批和流在开发层面上都统一到相同的SQL上处理是批流一体，也有一些人认为在计算引擎层面上批和流可以集成在同一个计算引擎是批流一体，比如：Spark/SparkStreaming/Structured Streaming/Flink框架在计算引擎层面上实现了批处理和流处理集成。

以上无论是在业务SQL使用上统一还是计算引擎上的统一，都是批流一体的一个方面，除此之外，批流一体还有一个最核心的方面就是存储层面上的统一。这个方面上也有一些流行的技术：delta/hudi/iceberg,存储一旦能够做到统一，例如：一些大型公司使用Iceberg作为存储，那么Kappa架构中很多问题都可以得到解决，Kappa架构将变成个如下模样：
在这里插入图片描述

这条架构中无论是流处理还是批处理，数据存储都统一到数据湖Iceberg上，这一套结构将存储统一后，解决了Kappa架构很多痛点，解决方面如下：

可以解决Kafka存储数据量少的问题。目前所有数据湖基本思路都是基于HDFS之上实现的一个文件管理系统，所以数据体量可以很大。
DW层数据依然可以支持OLAP查询。同样数据湖基于HDFS之上实现，只需要当前的OLAP查询引擎做一些适配就可以进行OLAP查询。
批流存储都基于Iceberg/HDFS存储之后，就完全可以复用一套相同的数据血缘、数据质量管理体系。
实时数据的更新。

上述架构也可以认为是Kappa架构的变种，也有两条数据链路，一条是基于Spark的离线数据链路，一条是基于Flink的实时数据链路，通常数据都是直接走实时链路处理，而离线链路则更多的应用于数据修正等非常规场景。

组件

大数据相关生态几乎都是Apache基金会。

lambda架构可数据中台

数据中台

企业对应部门，业务，构建多个数仓【数据分散未被整合】

可对应【机构信息、部门信息。一些约定俗称字典（专业术语）】

在这里插入图片描述

各分公司、部门、组、单元、都有自己内部的标准或规范。整体规范尚待统一。

一份数据，一份服务

业务数据整合闭环数据中台；双向循环共性成长
在这里插入图片描述

全景图

https://mad.firstmark.com/

https://landscape.cncf.io/?group=projects-and-products

企划

数据相当庞大。获取已知可用数据，探求未知隐藏数据。

合理对其挖掘探索分析

本质：统计、归纳、总结

探索、挖掘、发现、预测、求未来

云计算资源共享

OpenStack高可用集群
在这里插入图片描述

IAAS的应用场景

开发和测试环境：IAAS模型为开发团队提供了灵活、可扩展的基础设施资源，可以快速搭建和部署开发和测试环境。
高性能计算：对于需要大规模计算能力的科学计算、数据分析和机器学习等任务，IAAS模型提供了强大的计算和存储资源，可以快速满足需求。
灾备和容灾：通过租用IAAS提供的基础设施资源，组建灾备和容灾解决方案，确保业务的连续性和可用性。

PAAS（平台即服务）

什么是PAAS

PAAS，即平台即服务，是一种云计算模型，提供了一整套开发和运行应用程序所需的平台环境。在PAAS模型中，云服务提供商负责提供和管理硬件设施、操作系统、数据库和开发工具等基础平台，使开发人员可以专注于应用程序的开发和部署。

PAAS的特点和优势

简化开发过程：PAAS模型提供了开发所需的基础平台，包括操作系统、数据库、开发工具和运行环境等。开发人员可以更专注于应用程序的开发，无需关注底层基础设施的管理和维护。
快速部署和扩展：PAAS模型提供了自动化的应用程序部署和扩展机制，开发人员可以通过简单的操作实现快速部署和横向扩展。这使得应用程序的交付速度更快，能够迅速响应业务需求。
多租户架构：PAAS模型通常采用多租户架构，多个用户可以共享相同的平台环境，提高资源利用率。同时，用户之间相互隔离，保证了安全性和稳定性。

PAAS的应用场景

Web应用开发：对于Web应用开发，PAAS模型提供了丰富的开发框架、工具和服务，可以快速构建和部署Web应用程序。
移动应用开发：PAAS模型为移动应用开发提供了适配的开发工具和平台环境，支持移动应用程序的构建、测试和发布。
数据分析和大数据处理：PAAS模型提供了强大的计算和存储资源，适用于数据分析和大数据处理任务，帮助用户快速处理和分析海量数据。

SAAS，即软件即服务，是一种云计算模型，通过云平台提供软件应用程序给终端用户。在SAAS模型中，用户无需购买和安装软件，而是通过订阅方式使用云服务商提供的应用程序。

SAAS的特点和优势

零部署和维护成本：在SAAS模型中，用户无需购买、安装和维护软件，只需通过云平台订阅和使用。这降低了用户的部署和维护成本，同时减轻了IT团队的负担。
灵活的订阅模式：SAAS模型通常采用按需订阅的模式，用户可以根据实际需求选择合适的订阅计划。用户可以根据业务需求进行灵活的订阅调整，避免了不必要的资源浪费。
快速升级和更新：SAAS模型使得软件的升级和更新变得简单和快速。云服务提供商可以在后台进行软件的更新和升级，用户无需手动操作，即可获得最新版本的功能和修复。