Flink基础之流处理架构

 

目录

前言:

1、传统架构与流处理架构

2、消息传输层和流处理层

3、消息传输层的理想功能

3.1、兼具高性能和持久性

3.2、将生产者和消费者解耦

4、支持微服务架构的流数据

4.1、数据流作为中心数据源

4.2、欺诈检测:流处理架构用例

4.3、给开发人员带来的灵活性

5、不限于实时应用程序

6、流的跨地域复制


前言:

   作为新型系统, Flink 扩展了“流处理”这个概念的范围。有了它,流处理 不仅指实时、低延迟的数据分析,还指各类数据应用程序。其中,有些应 用程序基于流处理器实现,有些基于批处理器实现,有些甚至基于事务型数据库实现事实证明,让 Flink 能有效工作的数据架构,恰恰是充分利用流数据的基础。在详细介绍如何构建支持 Flink 流处理的管道之前,我们先来看看与传统架构相比,流处理架构有何优势。

1、传统架构与流处理架构

   对于后端数据而言,典型的传统架构是采用一个中心化的数据库系统,该 系统用于存储事务性数据。换句话说,数据库(SQL 或者 NoSQL)拥有 “新鲜”(或者说“准确”)的数据,这些数据反映了当前的业务状态,如系 统当前有多少已登录的用户,网站当前有多少活跃用户,以及当前每个用户的账户余额是多少。需要新鲜数据的应用程序都依靠数据库实现。分布式文件系统则用来存储不需要经常更新的数据,它们也往往是大规模批量计算所依赖的数据存储方式。

   这种传统架构成功地服务了几十年,但随着大型分布式系统中的计算复杂度不断上升,这种架构已经不堪重负。许多公司经常遇到以下问题。
在许多项目中,从数据到达到数据分析所需的工作流程太复杂、太缓慢。
传统的数据架构太单一:数据库是唯一正确的数据源,每一个应用程序都需要通过访问数据库来获得所需的数据。
采用这种架构的系统拥有非常复杂的异常问题处理方法。当出现异常问题时,很难保证系统还能很好地运行。
   传统架构的另一个问题是,需要通过在大型分布式系统中不断地更新来维持一致的全局状态。随着系统规模扩大,维持实际数据与状态数据间的一致性变得越来越困难;流处理架构则少了对这方面的要求,只需要维持本地的数据一致性即可。
作为一种新的选择,流处理架构解决了企业在大规模系统中遇到的诸多问题。以流为基础的架构设计让数据记录持续地从数据源流向应用程序,并在各个应用程序间持续流动。没有一个数据库来集中存储全局状态数据,取而代之的是共享且永不停止的流数据,它是唯一正确的数据源,记录了业务数据的历史。在流处理架构中,每个应用程序都有自己的数据,这些数据采用本地数据库或分布式文件进行存储。

2、消息传输层和流处理层

   如何有效地实现流处理架构并从 Flink 中获益呢?一个常见的做法是设置消 息传输层和流处理层

     (1) 消息传输层从各种数据源(生产者)采集连续事件产生的数据,并传输 给订阅了这些数据的应用程序和服务(消费者)。

    (2) 流处理层 3 个用途:①持续地将数据在应用程序和系统间移动;②聚 合并处理事件;③在本地维持应用程序的状态。
   上图是Flink 项目的架构有两个主要组成部分:消息传输层和由 Flink 提供的流处 理层。消息传输层负责传输连续事件产生的消息,能够提供消息传输的系统包括 Kafka 和 MapR Streams MapR Streams MapR 融合数据平台的一个主要组成部分,它兼容 Kafka API。
   事实上,在设计高效的流处理架构时,不仅流处理器的选择会造成架构的 巨大差异,消息传输层也很关键。现代系统之所以更容易处理大规模的流 数据,其中很大一部分原因就是消息传输方式的改进,以及流处理器与消 息传输系统的交互方式的改变。
消息传输层需要具备一些特定的功能。目前来看,有两种技术可以很好 地提供所需的功能,它们便是 Kafka MapR Streams MapR Streams 是 MapR 融合数据平台的一部分,它支持 Kafka API

3、消息传输层的理想功能

3.1、兼具高性能和持久性

   消息传输层的一个作用是作为流处理层上游的安全队列——它相当于缓冲区,可以将事件数据作为短期数据保留起来,以防数据处理过程发生中断。直到最近几年,高性能和持久性不可兼得的困境才被打破。人们习惯上认为流数据从消息传输层到流处理层之后就被丢弃:用了就没了。
为了设计新一代的流处理架构,高性能和持久性不可兼得是首先要改变的一个观念。兼具高性能和持久性对于消息传输系统来说至关重要;Kafka 和MapR Streams 都可以满足这个需求。
具有持久性的好处之一是 消息可以重播 。这个功能使得像 Flink 这样的处理器能对事件流中的某一部分进行重播和再计算 。正是
由于消息传输层和流处理层相互作用,才使得像 Flink 这样的系统有了准确处理和“时空穿梭”(指重新处理数据的能力)的保障,认识到这一点至关重要。

3.2、将生产者和消费者解耦

   采用高效的消息传输技术,可以从多个源(生产者)收集数据,并使这些数据可供多个服务或应用程序(消费者)使用,如图下图所示。Kafka 和MapR Streams 把从生产者获得的数据分配给既定的主题。数据源将数据推送给消息队列,消费者(或消费者群组)则拉取数据。事件数据只能基于给定的偏移量从消息队列中按顺序读出。生产者并不向所有消费者自动广播。这一点听起来微不足道,但是对整个架构的工作方式有着巨大的影响。

   这种传输方式——消费者订阅感兴趣的主题——意味着消息立刻到达,但并不需要被立刻处理。在消息到达时,消费者并不需要处于运行状态,而是可以根据自身的需求在任何时间使用数据。这样一来,添加新的消费者和生产者也很容易。采用解耦的消息传输系统很有意义,因为它能支持微服务,也支持将处理步骤中的实现过程隐藏起来,从而允许自由地修改实现过程。

   在上图中在 Kafka 和 MapR Streams 这样的消息传输工具中,数据的生产者和消费者(Flink 应用程序也是其中的一种消费者)是解耦的。到达的消息既可以立刻被使用,也可以稍后被使用。消费者从队列中订阅消息,而不是由生产者向所有消费者广播。
在消息到达的时候,消费者不必处于运行状态

4、支持微服务架构的流数据

   微服务方法指的是将大型系统的功能分割成通常具有单一目的的简单服务, 从而使小型团队可以轻松地构建和维护这些服务。即使是超大型组织,也可以用这种设计实现敏捷。若要使整个系统正常工作,各服务之间因通信而产生的连接必须是轻量级的。

   消息传输系统一方面将生产者和消费者解耦,另一方面又有足够高的吞吐量,并且能够满足像 Flink 这样的高性能流处理器。这种系统非常适合用于构建微服务。就连接微服务而言,流数据是相对较新的模式,但是它有许多好处。

4.1、数据流作为中心数据源

   流处理架构的核心是使各种应用程序互连在一起的消息队列。流处理器例如Flink从消息队列中订阅数据并加以处理。处理后的数据可以流向另一个消息队列。这样一来,其他应用程序(包括其他 Flink 应用程序)都可以共享流数据。在一些情况下,处理后的数据会被存放在本地数据库中

   如上图所示在流处理架构中,消息队列(图中以水平圆柱体表示)连接应用程序,并作 为新的共享数据源;它们取代了从前的大型集中式数据库。在本例中,Flink 被多个 应用程序使用。本地化的数据能够根据微服务项目的需要被存储在文件或者数据库中。 这种流处理架构的另一个好处是,流处理器(例如 Flink)还可以保障数据一致性。

   流处理架构不需要集中式数据库。取而代之的是消息队列, 它作为共享数据源,服务于各种不同的消费者。

4.2、欺诈检测流处理架构用例

   基于流处理的微服务架构有着强大的灵活性,特别是当同一份数据被用于不同的场景时,其灵活性更为明显。以信用卡服务提供商的欺诈检测项目为例。项目的目标是尽可能快地识别可疑的刷卡行为,从而阻止盗刷,并将损失降到最低。例如,欺诈检测器可以将刷卡速度作为评判依据:在很短的时间内,发生在跨度很大的不同地点,这样的连续交易合理吗?事实上,真正的欺诈检测器会使用几十个(甚至几百个)特征作为评判依据,但是我们仅仅通过分析刷卡速度这一个特征就可以理解许多问题。 下图 展示了流处理架构在欺诈检测项目中的优势。在图中,许多销售终端 (POS 1~n)请求欺诈检测器判定是否有欺诈行为。这些来自销售终端的询问需要立即被应答,因此在销售终端与欺诈检测器之间形成了询问与应答的交互。

    上图中欺诈检测可以从基于流处理的微服务架构中受益。在这种架构中,Flink 在 如下几个部分都非常有用:欺诈检测器、更新器,甚至刷卡行为分析器。值得一提的是,这种架构没有直接在本地数据库中更新刷卡行为的数据,而是将数据放在消息队列里,这些数据还可以不受干扰地被刷卡行为分析器等其他服务使用

    传统的欺诈检测模型将包含每张信用卡最后一次刷卡地点的文件直接存储在数据库中。但在这样的集中式数据库设计中,其他消费者并不能轻易使用刷卡行为的数据,因为访问数据库可能会影响欺诈检测系统的正常工作;在没有经过认真仔细的审查之前,其他消费者绝不会被授权更改数据库。这将导致整个流程变慢,因为必须仔细执行各种检查,以避免核心的业务功能受到破坏或影响。

   与传统方法相比,上图所示的流处理架构设计将欺诈检测器的输出发送给外部的消息队列(Kafka MapR Streams),再由如 Flink 这样的流处理器更新数据库,而不是直接将输出发送给数据库。这使得刷卡行为的数据可以通过消息队列被其他服务使用,例如刷卡行为分析器。上一次刷卡行为的数据被存储在本地数据库中,不会被其他服务访问。这样的设计避免了因为增加新的服务而带来的过载风险。

4.3、给开发人员带来的灵活性

    基于流处理的微服务架构也为欺诈检测系统的开发人员带来了灵活性。假设开发团队正试图改进欺诈检测模型并加以评估。刷卡行为产生的消息流可以被新模型采用,而完全不影响已有的检测器。新增加一个数据消费者的开销几乎可以忽略不计,同时只要合适,数据的历史信息可以保存成任何一种格式,并且使用任意的数据库服务。此外,如果刷卡行为队列中的消息被设计成业务级别的事件,而不是数据库表格的更新,那么消息的形式和内容都会非常稳定。若一定要更改,向前兼容可以避免更改已有的应 用程序。

   信用卡欺诈检测只是流处理架构的一个用例。流处理架构通过一个合适的消息传输系统(Kafka MapR Streams)和一个多用途、高性能的流处理器(Flink),能支持各种应用程序使用共享数据源,即消息流。

5、不限于实时应用程序

    虽然低延迟性很重要,但是实时应用程序只是众多流数据消费者中的一种。流数据的应用很广泛,比如,流处理应用程序可以通过订阅消息队列中的流数据来实时更新仪表盘(如下图中的 A 组消费者)。

    持久化的消息可以被重播,这一特性使许多用户获益(如下图中的 C 组消费者)。在本例中,消息流成为了可审计的日志,或者长期的事件历史。能够重现的历史非常有用,比如可以在工业安全分析中作为预知维护模型的一部分输入,也可以在医学或环境科学领域用于回顾性研究。

    流数据消费者并不仅限于实时应用程序,尽管它们是很重要的一种。本图展示了从流处理架构中获益的几类消费者。A 组消费者可能做各种实时分析,包括实时更新仪表盘。B 组消费者记录数据的当前状态,这些数据可能同时也被存储在数据库或搜索文件中在其他一些用例中,应用程序使用消息队列中的数据更新本地数据库或者搜索文件(如图上图中的 B 组消费者)。消息队列中的数据往往必须被流处理器聚合或者分析并转换之后,才会输出到数据库中。这是 Flink 擅长的另一个场景。

6、流的跨地域复制

    流处理架构并不是玩具:它被用于具有重要使命的系统,这些系统要求流处理层和消息传输层具备一些特性。许多关键的业务系统依靠跨数据中心的一致性,它们不仅需要高效的流处理层,更需要消息传输层拥有可靠的跨地域复制能力。例如,电信公司需要在移动通信基站、用户和处理中心之间共享数据;金融机构需要快速、准确地在相隔很远的办公室之间复制数据,同时控制成本。类似的例子还有很多。具体来说,数据中心之间的数据复制需要保存消息偏移量,这一点最有用,因为它使得任何数据中心的更新都可以被传播到其他数据中心,且允许双向和循环的数据复制。如果消息偏移量没有被保存,那么另一个数据中心就无法可靠地重启程序。如果不允许其他数据中心更新数据,那么就必须设计可靠的主节点。循环复制则可以避免复制过程出现单点故障。

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 程序猿惹谁了 设计师:白松林 返回首页