设为首页 - 加入收藏 辽源站长网 (http://www.0437zz.com)- 国内知名站长资讯网站,提供最新最全的站长资讯,创业经验,网站建设等!
热搜: 什么 2017 2015 模式
当前位置: 首页 > 运营中心 > 网站设计 > 教程 > 正文

从单体到Flink:一文读懂数据架构的演变

发布时间:2019-07-05 17:56 所属栏目:[教程] 来源:张利兵
导读:01 传统数据基础架构 如图1-1所示,传统单体数据架构(Monolithic Architecture)最大的特点便是集中式数据存储,企业内部可能有诸多的系统,例如Web业务系统、订单系统、CRM系统、ERP系统、监控系统等,这些系统的事务性数据主要基于集中式的关系性数据库(D

从单体到Flink:一文读懂数据架构的演变

01 传统数据基础架构

如图1-1所示,传统单体数据架构(Monolithic Architecture)最大的特点便是集中式数据存储,企业内部可能有诸多的系统,例如Web业务系统、订单系统、CRM系统、ERP系统、监控系统等,这些系统的事务性数据主要基于集中式的关系性数据库(DBMS)实现存储,大多数将架构分为计算层和存储层。

存储层负责企业内系统的数据访问,且具有最终数据一致性保障。这些数据反映了当前的业务状态,例如系统的订单交易量、网站的活跃用户数、每个用户的交易额变化等,所有的更新操作均需要借助于同一套数据库实现。

从单体到Flink:一文读懂数据架构的演变
▲图1-1 传统数据结构

单体架构的初期效率很高,但是随着时间的推移,业务越来越多,系统逐渐变得很大,越来越难以维护和升级,数据库是唯一的准确数据源,每个应用都需要访问数据库来获取对应的数据,如果数据库发生改变或者出现问题,则将对整个业务系统产生影响。

后来随着微服务架构(Microservices Architecture)的出现,企业开始逐渐采用微服务作为企业业务系统的架构体系。微服务架构的核心思想是,一个应用是由多个小的、相互独立的微服务组成,这些服务运行在自己的进程中,开发和发布都没有依赖。不同的服务能依据不同的业务需求,构建的不同的技术架构之上,能够聚焦在有限的业务功能。

从单体到Flink:一文读懂数据架构的演变
▲图1-2 微服务架构

如图1-2所示,微服务架构将系统拆解成不同的独立服务模块,每个模块分别使用各自独立的数据库,这种模式解决了业务系统拓展的问题,但是也带来了新的问题,那就是业务交易数据过于分散在不同的系统中,很难将数据进行集中化管理。

对于企业内部进行数据分析或者数据挖掘之类的应用,则需要通过从不同的数据库中进行数据抽取,将数据从数据库中周期性地同步到数据仓库中,然后在数据仓库中进行数据的抽取、转换、加载(ETL),从而构建成不同的数据集市和应用,提供给业务系统使用。

02 大数据数据架构

起初数据仓库主要还是构建在关系型数据库之上,例如Oracle、Mysql等数据库,但是随着企业数据量的增长,关系型数据库已经无法支撑大规模数据集的存储和分析,因此越来越多的企业开始选择基于Hadoop构建企业级大数据平台。

同时众多Sql-On-Hadoop技术方案的提出,也让企业在Hadoop上构建不同类型的数据应用变得简单而高效,例如通过使用Apache Hive进行数据ETL处理,通过使用Apache Impala进行实时交互性查询等。

大数据技术的兴起,让企业能够更加灵活高效地使用自己的业务数据,从数据中提取出更多重要的价值,并将数据分析和挖掘出来的结果应用在企业的决策、营销、管理等应用领域。但不可避免的是,随着越来越多新技术的引入与使用,企业内部一套大数据管理平台可能会借助众多开源技术组件实现。

例如在构建企业数据仓库的过程中,数据往往都是周期性的从业务系统中同步到大数据平台,完成一系列ETL转换动作之后,最终形成数据集市等应用。但是对于一些时间要求比较高的应用,例如实时报表统计,则必须有非常低的延时展示统计结果,为此业界提出一套Lambda架构方案来处理不同类型的数据。

例图1-3所示,大数据平台中包含批量计算的Batch Layer和实时计算的Speed Layer,通过在一套平台中将批计算和流计算整合在一起,例如使用Hadoop MapReduce进行批量数据的处理,使用Apache Storm进行实时数据的处理。

这种架构在一定程度上解决了不同计算类型的问题,但是带来的问题是框架太多会导致平台复杂度过高、运维成本高等。在一套资源管理平台中管理不同类型的计算框架使用也是非常困难的事情。总而言之,Lambda架构是构建大数据应用程序的一种很有效的解决方案,但是还不是最完美的方案。

从单体到Flink:一文读懂数据架构的演变
▲图1-3 大数据Lambada架构

后来随着Apache Spark的分布式内存处理框架的出现,提出了将数据切分成微批的处理模式进行流式数据处理,从而能够在一套计算框架内完成批量计算和流式计算。

但因为Spark本身是基于批处理模式的原因,并不能完美且高效地处理原生的数据流,因此对流式计算支持的相对较弱,可以说Spark的出现本质上是在一定程度上对Hadoop架构进行了一定的升级和优化。

03 有状态流计算架构

数据产生的本质,其实是一条条真实存在的事件,前面提到的不同的架构其实都是在一定程度违背了这种本质,需要通过在一定时延的情况下对业务数据进行处理,然后得到基于业务数据统计的准确结果。

实际上,基于流式计算技术局限性,我们很难在数据产生的过程中进行计算并直接产生统计结果,因为这不仅对系统有非常高的要求,还必须要满足高性能、高吞吐、低延时等众多目标。

而有状态流计算架构(如图1-4所示)的提出,从一定程度上满足了企业的这种需求,企业基于实时的流式数据,维护所有计算过程的状态,所谓状态就是计算过程中产生的中间计算结果,每次计算新的数据进入到流式系统中都是基于中间状态结果的基础上进行运算,最终产生正确的统计结果。

基于有状态计算的方式最大的优势是不需要将原始数据重新从外部存储中拿出来,从而进行全量计算,因为这种计算方式的代价可能是非常高的。从另一个角度讲,用户无须通过调度和协调各种批量计算工具,从数据仓库中获取数据统计结果,然后再落地存储,这些操作全部都可以基于流式计算完成,可以极大地减轻系统对其他框架的依赖,减少数据计算过程中的时间损耗以及硬件存储。

从单体到Flink:一文读懂数据架构的演变
▲图1-4 有状态计算架构

如果计算的结果能保持一致,实时计算在很短的时间内统计出结果,批量计算则需要等待一定时间才能得出,相信大多数用户会更加倾向于选择使用有状态流进行大数据处理。

04 为什么会是Flink

【免责声明】本站内容转载自互联网,其相关言论仅代表作者个人观点绝非权威,不代表本站立场。如您发现内容存在版权问题,请提交相关链接至邮箱:bqsm@foxmail.com,我们将及时予以处理。

网友评论
推荐文章