实时计算数据架构的演变

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

存储层，主要是负责存储企业各类系统产生的数据，如 Web 业务系统、订单系统、CRM 系统，ERP 系统、监控系统，数据好比系统的订单交易量，网站的活跃用户数，每一个用户的交易额。
全部的操做均须要借助于同一套数据库实现。
单体架构初期效率很高，可是随着时间的推移，业务愈来愈多，上线迭代很快。
但随着后期业务愈来愈多，系统逐渐变的臃肿。数据库变成了惟一准确的数据源，每一个应用都须要访问数据库来获取对应的数据，若是数据库发生改变或者出现问题，整个业务系统都会受到影响。

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

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

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

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

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