数据架构的演变

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

01 传统数据基础架构

如图1-1所示，传统单体数据架构(Monolithic Architecture)最大的特色即是集中式数据存储，企业内部可能有诸多的系统，例如Web业务系统、订单系统、CRM系统、ERP系统、监控系统等，这些系统的事务性数据主要基于集中式的关系性数据库(DBMS)实现存储，大多数将架构分为计算层和存储层。
存储层负责企业内系统的数据访问，且具备最终数据一致性保障。这些数据反映了当前的业务状态，例如系统的订单交易量、网站的活跃用户数、每一个用户的交易额变化等，全部的更新操做均须要借助于同一套数据库实现。

▲图1-1 传统数据结构
单体架构的初期效率很高，可是随着时间的推移，业务愈来愈多，系统逐渐变得很大，愈来愈难以维护和升级，数据库是惟一的准确数据源，每一个应用都须要访问数据库来获取对应的数据，若是数据库发生改变或者出现问题，则将对整个业务系统产生影响。
后来随着微服务架构(Microservices Architecture)的出现，企业开始逐渐采用微服务做为企业业务系统的架构体系。微服务架构的核心思想是，一个应用是由多个小的、相互独立的微服务组成，这些服务运行在本身的进程中，开发和发布都没有依赖。不一样的服务能依据不一样的业务需求，构建的不一样的技术架构之上，可以聚焦在有限的业务功能。

▲图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架构是构建大数据应用程序的一种颇有效的解决方案，可是还不是最完美的方案。

▲图1-3 大数据Lambada架构
后来随着Apache Spark的分布式内存处理框架的出现，提出了将数据切分红微批的处理模式进行流式数据处理，从而可以在一套计算框架内完成批量计算和流式计算。
但由于Spark自己是基于批处理模式的缘由，并不能完美且高效地处理原生的数据流，所以对流式计算支持的相对较弱，能够说Spark的出现本质上是在必定程度上对Hadoop架构进行了必定的升级和优化。

03 有状态流计算架构

数据产生的本质，实际上是一条条真实存在的事件，前面提到的不一样的架构其实都是在必定程度违背了这种本质，须要经过在必定时延的状况下对业务数据进行处理，而后获得基于业务数据统计的准确结果。
实际上，基于流式计算技术局限性，咱们很难在数据产生的过程当中进行计算并直接产生统计结果，由于这不只对系统有很是高的要求，还必需要知足高性能、高吞吐、低延时等众多目标。
而有状态流计算架构(如图1-4所示)的提出，从必定程度上知足了企业的这种需求，企业基于实时的流式数据，维护全部计算过程的状态，所谓状态就是计算过程当中产生的中间计算结果，每次计算新的数据进入到流式系统中都是基于中间状态结果的基础上进行运算，最终产生正确的统计结果。
基于有状态计算的方式最大的优点是不须要将原始数据从新从外部存储中拿出来，从而进行全量计算，由于这种计算方式的代价多是很是高的。从另外一个角度讲，用户无须经过调度和协调各类批量计算工具，从数据仓库中获取数据统计结果，而后再落地存储，这些操做所有均可以基于流式计算完成，能够极大地减轻系统对其余框架的依赖，减小数据计算过程当中的时间损耗以及硬件存储。

▲图1-4 有状态计算架构
若是计算的结果能保持一致，实时计算在很短的时间内统计出结果，批量计算则须要等待必定时间才能得出，相信大多数用户会更加倾向于选择使用有状态流进行大数据处理。

04 为何会是Flink

能够看出有状态流计算将会逐步成为企业做为构建数据平台的架构模式，而目前从社区来看，可以知足的只有Apache Flink。Flink经过实现Google Dataflow流式计算模型实现了高吞吐、低延迟、高性能兼具实时流式计算框架。
同时Flink支持高度容错的状态管理，防止状态在计算过程当中由于系统异常而出现丢失，Flink周期性地经过分布式快照技术Checkpoints实现状态的持久化维护，使得即便在系统停机或者异常的状况下都能计算出正确的结果。
Flink具备先进的架构理念、诸多的优秀特性，以及完善的编程接口，而Flink也在每一次的Release版本中，不断推出新的特性，例如Queryable State功能的提出，允许用户经过远程的方式直接获取流式计算任务的状态信息，数据不须要落地数据库就能直接从Flink流式应用中查询。对于实时交互式的查询业务能够直接从Flink的状态中查询最新的结果。
在将来，Flink将不只做为实时流式处理的框架，更多的可能会成为一套实时的状态存储引擎，让更多的用户从有状态计算的技术中获益。
从单体到Flink：一文读懂数据架构的演变
Flink的具体优点有如下几点。

1. 同时支持高吞吐、低延迟、高性能

Flink是目前开源社区中惟一一套集高吞吐、低延迟、高性能三者于一身的分布式流式数据处理框架。像Apache Spark也只能兼顾高吞吐和高性能特性，主要由于在Spark Streaming流式计算中没法作到低延迟保障;而流式计算框架Apache Storm只能支持低延迟和高性能特性，可是没法知足高吞吐的要求。而知足高吞吐、低延迟、高性能这三个目标对分布式流式计算框架来讲是很是重要的。

2. 支持事件时间(Event Time)概念

在流式计算领域中，窗口计算的地位举足轻重，但目前大多数框架窗口计算采用的都是系统时间(Process Time)，也是事件传输到计算框架处理时，系统主机的当前时间。
Flink可以支持基于事件时间(Event Time)语义进行窗口计算，也就是使用事件产生的时间，这种基于事件驱动的机制使得事件即便乱序到达，流系统也可以计算出精确的结果，保持了事件本来产生时的时序性，尽量避免网络传输或硬件系统的影响。

3. 支持有状态计算

Flink在1.4版本中实现了状态管理，所谓状态就是在流式计算过程当中将算子的中间结果数据保存在内存或者文件系统中，等下一个事件进入算子后能够从以前的状态中获取中间结果中计算当前的结果，从而无须每次都基于所有的原始数据来统计结果，这种方式极大地提高了系统的性能，并下降了数据计算过程的资源消耗。
对于数据量大且运算逻辑很是复杂的流式计算场景，有状态计算发挥了很是重要的做用。

4. 支持高度灵活的窗口(Window)操做

在流处理应用中，数据是接二连三的，须要经过窗口的方式对流数据进行必定范围的聚合计算，例如统计在过去的1分钟内有多少用户点击某一网页，在这种状况下，咱们必须定义一个窗口，用来收集最近一分钟内的数据，并对这个窗口内的数据进行再计算。
Flink将窗口划分为基于Time、Count、Session，以及Data-driven等类型的窗口操做，窗口能够用灵活的触发条件定制化来达到对复杂的流传输模式的支持，用户能够定义不一样的窗口触发机制来知足不一样的需求。

5. 基于轻量级分布式快照(Snapshot)实现的容错

Flink可以分布式运行在上千个节点上，将一个大型计算任务的流程拆解成小的计算过程，而后将tesk分布到并行节点上进行处理。在任务执行过程当中，可以自动发现事件处理过程当中的错误而致使数据不一致的问题，好比：节点宕机、网路传输问题，或是因为用户由于升级或修复问题而致使计算服务重启等。
在这些状况下，经过基于分布式快照技术的Checkpoints，将执行过程当中的状态信息进行持久化存储，一旦任务出现异常中止，Flink就可以从Checkpoints中进行任务的自动恢复，以确保数据在处理过程当中的一致性。

6. 基于JVM实现独立的内存管理

内存管理是全部计算框架须要重点考虑的部分，尤为对于计算量比较大的计算场景，数据在内存中该如何进行管理显得相当重要。针对内存管理，Flink实现了自身管理内存的机制，尽量减小JVM GC对系统的影响。
另外，Flink经过序列化/反序列化方法将全部的数据对象转换成二进制在内存中存储，下降数据存储的大小的同时，可以更加有效地对内存空间进行利用，下降GC带来的性能降低或任务异常的风险，所以Flink较其余分布式处理的框架会显得更加稳定，不会由于JVM GC等问题而影响整个应用的运行。

7. Save Points(保存点)

对于7*24小时运行的流式应用，数据源源不断地接入，在一段时间内应用的终止有可能致使数据的丢失或者计算结果的不许确，例如进行集群版本的升级、停机运维操做等操做。值得一提的是，Flink经过Save Points技术将任务执行的快照保存在存储介质上，当任务重启的时候能够直接从事先保存的Save Points恢复原有的计算状态，使得任务继续按照停机以前的状态运行，Save Points技术可让用户更好地管理和运维实时流式应用。