实时计算数据架构的演变

传统数据基础架构
传统单体数据架构最大的特点便是集中式数据存储，大多数分为计算层和存储层。

存储层，主要是负责存储企业各种系统产生的数据，如 Web 业务系统、订单系统、CRM 系统，ERP 系统、监控系统，数据比如系统的订单交易量，网站的活跃用户数，每个用户的交易额。
所有的操作均需要借助于同一套数据库实现。
单体架构初期效率很高，但是随着时间的推移，业务越来越多，上线迭代很快。
但随着后期业务越来越多，系统逐渐变的臃肿。数据库变成了唯一准确的数据源，每个应用都需要访问数据库来获取对应的数据，如果数据库发生改变或者出现问题，整个业务系统都会受到影响。
图片: https://uploader.shimo.im/f/KpvJzffqToIJjaPQ.jpg

微服务架构
微服务将系统拆分成不同的独立服务模块，每个模块有自己独立的数据库，不同的业务之间互相不干扰，微服务架构解决了业务系统拓展性的问题，但是随之也带来了新的问题。
就是业务数据过于分散在不同的系统中，很难将数据集中化管理。对于企业内部数据仓库，数据挖掘之类的应用，需要把各个业务系统数据库数据抽取到数据仓库之中，在数据仓库中进行数据的抽取、转换、加载（ETL），从而构建不同的数据集市应用，提供给业务系统用。

图片: https://uploader.shimo.im/f/vYGHwKFRIEwVvq67.jpg

大数据数据架构
起初，数据是构建在关系型数据库之上，但随着企业数据量的暴增，关系型数据库已经无法支撑起大规模数据集的存储和分析，于是基于HADOOP构建企业级大数据平台便成为了共识。
后来，离线的高延迟渐渐的无法满足企业需求，例如一些时间要求比较高的应用，实时报表统计，需要非常低的延时展示结果。为此业界提出一套lambda架构方案来处理不同类型的数据。

图片: https://uploader.shimo.im/f/CC7vgvWICS4ESbAs.jpg

包含了批量计算的 Batch Layer和实时计算的 Speed Layer，通过在一套平台中，将批计算和流计算结合在一起。
lambda 架构是构建大数据应用程序的一种很有效的解决方案，但还不是最完美的方案

有状态流式架构
数据产生的本质，其实是一条条真实存在的事件，而前面讲的不同的架构所用到的技术，如hadoop，spark，多少都在一定程度上违背了这种本质，需要在一定延时的情况下对业务数据进行处理。
而有状态的流计算架构，基于实时的流式数据，维护所有计算过程的状态，所谓状态就是计算过程中产生的所有中间计算结果，每次计算新的数据进入到流式系统中都是基于中间状态结果的基础上进行计算，最终产生正确的统计结果。

图片: https://uploader.shimo.im/f/PsOVoxq9knocqvWo.jpg

这种架构好处是，不需要从原始数据重新从外部存储中拿出来，从而进行全量计算；另外用户也无需协调各种批量计算工具，从数据仓库中获取统计结果，然后再落地存储，这些操作全部都可以基于流式操作来完成