业界数据架构的演变
目录
一、概述
二、业务处理-单体架构
三、业务处理-微服务架构
四、数据分析-大数据Lambda架构
五、数据分析-Kappa架构
六、数据分析-Lambda+Kappa混合架构
七、湖仓一体架构
一、概述
近年来随着越来越多的大数据技术被开源，例如：HDFS、Spark等，伴随这些技术的发展与普及，促使企业数据架构的演进——从传统的关系型数据存储架构逐步演化为分布式处理和存储的架构。我们通过数据架构的演变角度来了解下为什么今天Flink实时计算引擎会爆火起来。
二、业务处理-单体架构
传统单体架构最大的特点是集中式数据存储，一个企业中可能有很多业务系统，例如：订单系统、CRM系统、ERP系统等，这些系统的数据一般存储在关系型数据库中，这些存储的数据一般反应当前的业务状态，也就是存储的是支撑业务正常运转的事务数据，例如：系统订单交易量、网站活跃用户数、每个用户在线的状态等，针对这些数据库的操作也主要是增删改查操作，单体架构如下：
单体架构初期的效率很高，但是随着时间的推移，业务越来越多，业务系统逐渐变得庞大，越来越难维护与升级，并且不同的业务系统之间可能有一些共同的业务模块，并且一单业务系统依赖的数据库有问题会导致整个业务系统变的不可用，为了解决以上问题，企业开始逐渐采用微服务架构作为企业业务系统的架构体系。
三、业务处理-微服务架构
微服务架构的核心思想是一个应用由多个小的、相互独立的微服务组成，这些服务运行在自己的进程中，开发和发布都没有依赖，不同的服务能依据不同的业务需求，构建不同的技术架构之上，组成不同的业务系统应用。
微服务架构将系统拆解成不同独立的服务模块，每个模块分别使用各自独立的数据库，这种模式解决了业务系统的扩展问题，也带来了新的问题——业务交易数据过于分散在不同的系统中，很难将数据进行集中化管理。微服务架构如下：
无论是单体架构还是微服务架构主要针对的还是企业的业务系统，也就是业务平台，对应的数据库存储的数据也是增删改查的事务型数据，这些业务系统上主要进行的也是OLTP业务操作，对于企业内部进行数据分析(OLAP分析)或者数据挖掘之类的应用，则需要通过从不同的数据库中进行数据抽取，将数据从不同的数据库中进行周期性同步到数据仓库中，然后在数据仓库中进行统一规范的清洗分析处理，最终结果提供给不同的数据集市和应用。
四、数据分析-大数据Lambda架构
最初很多公司构建分析系统对应的数据仓库都是基于关系型数据库之上，例如：MySQL、Oracle数据库，但是随着企业数据量的增长，关系型数据库已经无法支撑海量数据集的存储与分析，这时随着大数据相关技术的兴起，很多企业基于大数据相关技术构建数据分析对应的数据仓库，例如：Hadoop中的HDFS 、Hive。
基于大数据平台构建数据仓库的过程，数据往往都是周期性的从业务系统中同步到大数据平台，完成一系列ETL转换操作后，最终形成报表数据提供给数据集市展示使用，这就是通常我们说的离线数据分析。但是对于一些实时性要求比较高的应用，例如：实时报表系统，则必须有非常低的延时展示统计结果，这就是我们说的实时数据分析。企业中这个时期采用Lambda架构来处理离线数据和实时数据的分析，大数据Lambda架构如下：
Lambda架构在一定程度上解决了不同计算场景问题，但是带来的问题是框架太多导致平台复杂度过高、运维成本高，例如，在这个时期要完成离线计算需要使用Hive、MapReduce离线计算框架，完成实时计算需要使用Storm实时计算框架，对相应的开发和维度带来很高的成本。后来随着Apache Spark分布式计算框架的出现，Spark可以处理离线数据，同时可以将实时数据作为微批处理来应对实时处理场景，总之，Spark可以让Lambda架构使用一套计算框架完成批处理和实时处理计算，但是Spark本身是基于批数据处理模式处理流式数据，并不能完美高效的处理实时要求非常高的场景。
五、数据分析-Kappa架构
上面我们通过了解Lambada架构可以知道，Lambada架构的技术栈中，主要使用Spark框架实现分布式处理离线数据，但是Spark本身是基于批数据处理模式处理流式数据，并不能完美高效的处理实时要求非常高的场景。要解决这个问题，需要引入流处理架构。
Kappa 架构通过专注于流处理，提供了 Lambda 架构的简化替代方案。它包含不可变数据流的概念，无需维护单独的批处理层。在 Kappa 架构中，所有数据都作为无限的事件流引入和处理。数据流经系统并进行实时处理，从而实现近乎即时的洞察力。
Kappa架构的总体处理流程图：
基于Flink选型的Kappa实时数仓图：
虽然Kappa架构通过引入流处理框架，对数据流进行了实时处理，解决了数据实时分析的业务场景需求，但是对于批处理或历史数据分析等场景，Kappa架构缺乏固有的支持；在处理某些需要分析大型历史数据集的用例时，此限制可能会带来挑战。
六、数据分析-Lambda+Kappa混合架构
Lambda 架构通过融合批处理和实时处理提供了全面的数据视图，而 Kappa 架构通过简化实时处理流程降低了系统复杂性。所以在既需要实现数据实时和历史分析，又需要实现数据实时处理和低延迟见解的数据处理场景中，我们一般考虑使用Lambda+Kappa结合的混合数据架构。
基于Flink选型的Kappa实时数仓图+基于Spark+Hive选型的离线数仓图（混合架构）：
七、湖仓一体架构
数据架构演变到Lambda+Kappa混合架构，即满足了离线数据的处理，也满足了实时数据的处理，按道理说已经完成了产业界的数据处理需求了，怎么还会衍生出湖仓一体架构呢？要回答这个问题，我们还要从Kappa架构的缺点说起，Kappa架构缺陷如下：
- 基于Kafka构建的实时数仓无法支持海量数据存储。对于海量数据量的业务线来说，Kafka一般只能存储非常短时间的数据，比如最近一周，甚至最近一天。
- 基于Kafka构建的实时数仓无法支持高效的OLAP查询，大多数业务都希望能在DWD\DWS层支持即席查询的，但是Kafka无法非常友好地支持这样的需求。
- 基于Kafka构建的实时数仓无法复用目前已经非常成熟的基于离线数仓的数据血缘、数据质量管理体系。需要重新实现一套数据血缘、数据质量管理体系。
- Kafka不支持update/upsert，目前Kafka仅支持append。
为了解决Kappa架构的痛点问题，业界最主流是采用“批流一体”方式，这里批流一体可以理解为批和流使用SQL同一处理，也可以理解为处理框架的统一，例如：Spark、Flink，但这里更重要指的是存储层上的统一，只要存储层面上做到“批流一体”就可以解决以上Kappa遇到的各种问题。数据湖技术可以很好的实现存储层面上的“批流一体”，这就是为什么大数据中需要数据湖的原因。
基于Lceberg选型的批流一体实时数仓架构：
今天关于数据架构演变的内容就讲到这里，可以关注Flink专栏《Flink》，后续不定期分享相关技术文章。如果帮助到大家，欢迎大家点赞+关注+收藏，有疑问也欢迎大家评论留言！