🏡 个人主页：IT贫道_大数据OLAP体系技术栈,Apache Doris,Clickhouse 技术-CSDN博客
🚩 私聊博主：加入大数据技术讨论群聊，获取更多大数据资料。
🔔 博主个人B栈地址：豹哥教你大数据的个人空间-豹哥教你大数据个人主页-哔哩哔哩视频
目录
1. 业务处理-单体架构
2. 业务处理-微服务架构
3. 数据分析-大数据Lambda架构
4. 有状态流计算架构
近年来随着越来越多的大数据技术被开源，例如：HDFS、Spark等，伴随这些技术的发展与普及，促使企业数据架构的演进——从传统的关系型数据存储架构逐步演化为分布式处理和存储的架构。我们通过数据架构的演变角度来了解下为什么今天Flink实时计算引擎会爆火起来。
1. 业务处理-单体架构
传统单体架构最大的特点是集中式数据存储，一个企业中可能有很多业务系统，例如：订单系统、CRM系统、ERP系统等，这些系统的数据一般存储在关系型数据库中，这些存储的数据一般反应当前的业务状态，也就是存储的是支撑业务正常运转的事务数据，例如：系统订单交易量、网站活跃用户数、每个用户在线的状态等，针对这些数据库的操作也主要是增删改查操作，单体架构如下：
单体架构初期的效率很高，但是随着时间的推移，业务越来越多，业务系统逐渐变得庞大，越来越难维护与升级，并且不同的业务系统之间可能有一些共同的业务模块，并且一单业务系统依赖的数据库有问题会导致整个业务系统变的不可用，为了解决以上问题，企业开始逐渐采用微服务架构作为企业业务系统的架构体系。
2. 业务处理-微服务架构
微服务架构的核心思想是一个应用由多个小的、相互独立的微服务组成，这些服务运行在自己的进程中，开发和发布都没有依赖，不同的服务能依据不同的业务需求，构建不同的技术架构之上，组成不同的业务系统应用。
微服务架构将系统拆解成不同独立的服务模块，每个模块分别使用各自独立的数据库，这种模式解决了业务系统的扩展问题，也带来了新的问题——业务交易数据过于分散在不同的系统中，很难将数据进行集中化管理。微服务架构如下：
无论是单体架构还是微服务架构主要针对的还是企业的业务系统，也就是业务平台，对应的数据库存储的数据也是增删改查的事务型数据，这些业务系统上主要进行的也是OLTP业务操作，对于企业内部进行数据分析(OLAP分析)或者数据挖掘之类的应用，则需要通过从不同的数据库中进行数据抽取，将数据从不同的数据库中进行周期性同步到数据仓库中，然后在数据仓库中进行统一规范的清洗分析处理，最终结果提供给不同的数据集市和应用。
3. 数据分析-大数据Lambda架构
最初很多公司构建分析系统对应的数据仓库都是基于关系型数据库之上，例如：MySQL、Oracle数据库，但是随着企业数据量的增长，关系型数据库已经无法支撑海量数据集的存储与分析，这时随着大数据相关技术的兴起，很多企业基于大数据相关技术构建数据分析对应的数据仓库，例如：Hadoop中的HDFS 、Hive。
基于大数据平台构建数据仓库的过程，数据往往都是周期性的从业务系统中同步到大数据平台，完成一系列ETL转换操作后，最终形成报表数据提供给数据集市展示使用，这就是通常我们说的离线数据分析。但是对于一些实时性要求比较高的应用，例如：实时报表系统，则必须有非常低的延时展示统计结果，这就是我们说的实时数据分析。企业中这个时期采用Lambda架构来处理离线数据和实时数据的分析，大数据Lambda架构如下：
Lambda架构在一定程度上解决了不同计算场景问题，但是带来的问题是框架太多导致平台复杂度过高、运维成本高，例如，在这个时期要完成离线计算需要使用Hive、MapReduce离线计算框架，完成实时计算需要使用Storm实时计算框架，对相应的开发和维度带来很高的成本。
后来随着Apache Spark分布式计算框架的出现，Spark可以处理离线数据，同时可以将实时数据作为微批处理来应对实时处理场景，总之，Spark可以让Lambda架构使用一套计算框架完成批处理和实时处理计算，但是Spark本身是基于批数据处理模式处理流式数据，并不能完美高效的处理实时要求非常高的场景。
关于大数据分析架构演变过程中在大数据中除了有Lambda架构之外，还有Kappa架构、混合架构及湖仓一体架构，以上各个架构都是在大数据不同时期针对公司业务数据分析场景提出的，都是解决企业数据分析过程中业务痛点问题的架构，关于其他架构更详细内容可以参照实时数仓相关课程。
4. 有状态流计算架构
Lambda架构中针对实时数据处理我们可以使用Spark计算框架进行分析，Spark针对实时数据进行分析本质是将实时流数据看成微批进行处理，数据产生的本质是一条条真实的事件，这种处理实际上针对实时流事件分析有一定的延迟，很难在实时计算过程中进行实时计算并直接产生统计结果，因为这需要计算框架满足高性能、高吞吐、低延时等目标。随着有状态流计算架构的提出，从一定程度上满足了企业对实时流数据处理的高性能、高吞吐、低延时目标，企业可以基于实时的流式数据，维护所有计算过程的状态，所谓状态就是计算过程中产生的中间计算结果，每次计算新的数据进入到流式系统中都是基于中间状态结果的基础上进行运算，最终产生正确的统计结果。
基于有状态计算的方式最大的优势是不需要将原始数据重新从外部存储中拿出来，从而进行全量计算，因为这种计算方式的代价可能是非常高的。从另一个角度讲，用户无须通过调度和协调各种批量计算工具，从数据仓库中获取数据统计结果，然后再落地存储，这些操作全部都可以基于流式计算完成，可以极大地减轻系统对其他框架的依赖，减少数据计算过程中的时间损耗以及硬件存储。有状态计算架构如下：
可以看出有状态流计算架构将会逐步成为企业作为构建数据平台的架构模式，Apache Flink就是有状态的流计算架构，通过实现Google Dataflow流式计算模型实现了高吞吐、低延迟、高性能兼具的实时流式计算框架，同时Flink支持高度容错的状态管理，防止状态在计算过程中因为系统异常而出现数据丢失，Flink周期性地通过分布式快照技术Checkpoints实现状态的持久化维护，即使在系统停机或者异常情况下都能正确的计算出来结果。
