学习部分已经告一段落了,在准备项目的时候,找了一些资料作为补充。
《基于Flink平台的资源感知任务调度策略》
由于流式数据具有实时性、突发性、无序性、无限性等特点,传统的先存储后计算的批量计算理念已经不适用于实时流计算的处理,因此如何构造高吞吐、低延时的大数据流式计算系统称为当前亟待解决的问题,然而面对大规模高速无序的数据流,任务负载不均衡导致计算节点可能存在资源过剩或资源不足的问题,从而影响计算集群的吞吐量,资源利用率等性能
ApacheFlink是一个由两类节点构成的开源分布式流式计算处理框架。
(1)主控节点
是运行FlinkJobManager的后台服务节点,JobManager是Flink计算集群的核心,
负责
任务调度(schedulingtasks)
管理检查点(managingcheckpoints)
及错误恢复(failurerecovery)
在flink中的地位相当于Storm中的Nimbus
(2)计算节点
它是运行FlinkTaskManager后台服务的节点,
TaskManager负责监听JobManager分配的任务并在一个JVM进程内用一个或多个线程执行任务,
在Flink中的地位相当于Storm中的Supervisor,
Flink计算集群默认使用先来先服务、静态资源分配的调度算法
但目前静态资源分配算法存在以下问题:
(1)由于流式处理系统的负载随着数据流流量的变化而呈现波动性变化,
因此静态的资源配置不能满足动态变化的负载对资源的需求,使得应用程序:
在负载峰值的时候无法获得更多的资源,从而增加数据处理延迟;
而在负载波谷的时候空闲资源无法释放,从而造成资源浪费.
(2)用户手动设置资源的方法无法准确地判断处理不同任务拓扑时的计算节点在不同负载情况下真正剩余的资源量
因此,为了更好地解决流式计算系统的吞吐量瓶颈问题,许多学者提出了各种资源感知调度算法以及资源评估模型(以下省略,是具体的算法,实现了基于资源感知的任务调度策略,在大数据基准测试WordCount以及TeraSort下吞吐量平均提高了29.32%和35.86%)
《基于Flink的实时计算平台的设计与实现》
Flink实时计算框架功能:Flink提供了SQL语法可以对实时数据进行DML(datamanipulationlanguage)操作,但不支持DDL(datadefinitionlanguage)操作以及外部维表数据源直接关联的功能。
思路:提供可视化页面展示任务调度所处的状态信息,任务执行时实时展示内部监控指标以及运行日志信息
对于SparkStreaming的理解:
Spark是如今众多大数据开源项目中最为活跃、使用最多的项目之一,最早由加州大学柏克莱分校AMPLab所开发,并交给Apache开源组织进行孵化,如今围绕Spark衍生出的多个组件,已经被广泛应用于数据分析、机器学习等多个领域。
而SparkStreaming则是针对数据实时处理场景而扩展出的组件。
Spark批数据处理的编程模型是RDD(Resilient Distributed Datasets弹性分布式数据集),代表一组不可变的数据集,它可以分散到集群中的多个节点中并发执行,同时把中间结算结果存储到内存中,并传递给下一个RDD或者直接输出到外部数据源。
而SparkStreaming抽象出另一种编程模型DStream(Discretized Stream)
DStream底层是按时间窗口将多个RDD进行划分,其中的每个RDD都包含了一个数据段的数据。SparkStreaming通过持续从外部读取实时数据,将数据按时间间隔划分成连续的DStream,并交由Spark底层来执行,做到了不需要改动底层架构就可以处理实时数据。
此外,SparkStreaming支持通过SQL语法对数据进行处理,极大的降低了学习成本,并且支持多种主流语言对应用进行开发,例如 Python、Scala、R和Java 等。
此外,在数据容错方面,SparkStreaming采用预写日志机制,将接收到的外部数据预先保存到容错存储中,在开启预写日志机制的情况下能够保证数据零丢失,这种情况下,会提供At Least Once(至少一次)的可靠保障。从Spark1.3.4版本开始,又引入了读取Kafka数据新的API,可以保证从Kafka消息队列中接
收的数据有且只有一次,从而保障了Exactly Once(精确一次)的语义。
但是,SparkStreaming实现数据实时处理的机制是通过对批数据处理的思想演变而来的,它按数据达到的先后顺序将数据划分为小的批数据,以微批的方式来处理实时数据。
这种以微批的方式来实现数据的实时处理主要有两个弊端,
首先在数据处理的延迟上,没有真正做到实时处理,SparkStreaming时间窗口的划分只能精确到秒级,这就意味着从数据被接收到最终真正处理有秒级的延迟。
其次,划分微批的数据量大小难以把控,极其容易造成内存溢出。Spark是将中间计算结果存储到内存中,按秒来划分数据,这可能会因为某一时间间隔内的数据量太大,导致内存溢出而终止任务的执行。
存储实时数据的消息队列Kafka
处理实时数据的计算引擎Flink
监控系统Prometheus
实时计算框架通常使用sql语句中的join语法将两个来自不同数据源表中的流数据进行关联,
作为通用的实时计算框架,Flink无法包含对所有维表数据源的支持,只能由开发人员进行扩展。
使用SQL语句中的JOIN语法,将实时数据与维表数据进行关联,进而补齐字段,是实时计算系统不可缺少的一部分。
Flink的有状态计算和无状态计算:
有状态计算是指在处理一个事件或者一条数据时,结果与先前处理事件有关
无状态计算表示处理结果只和事件本身相关。
Flink集群架构:
Flink程序运行时的两个主要进程:JobManager和TaskManager
程序启动时:客户端进程JobClient和JobManager进行交互,将用户程序提交到集群中进行存储
JobManager负责申请资源并启动多个TaskManager进程共同执行程序
Flink系统架构与大多数典型分布式架构类似,同样遵循了Master-Slave架构设计原则。
当启动Flink集群后,JobManager会根据程序设置的并发度,启动一个或多个TaskManager进程
TaskManager启动后会将当前进程占有的CPU核数以及内存大小上报给JobManager进行汇总,同时周期性的主动向JobManager发送心跳信息,并执行用户程序。
JobManager将各个TaskManager执行的任务结果进行汇总,同时监控每个TaskManager的运行情况,当检测到某个TaskManager心跳停止,则启动新的TaskManager进行任务转移。
其中TaskManager进程间通过网络数据流的形式来传输数据。
JobManager是Flink集群中的协调者,负责与JobClient交互,也负责监控、管理TaskManager的任务执行情况。作业被调度执行后,JobManager会协调TaskManager做Checkpoint操作,定期将执行的状态信息进行持久化,从而保证任务失败重启后,之前的计算结果依然保留。
在接收到JobClient任务停止请求后,JobManager会要求TaskManager做一次Checkpoint操作,保留当前任务执行的状态信息。此外,JobManager还负责WaterMark数据的下发,TaskManager接收到的WaterMark后,触发窗口计算。
TaskManager是Flink任务的执行者,通过运行在多个JVM进程中的多个线程中,并发执行用户程序。TaskManager的个数以及其中槽Slots的数量,决定了任务的最大并发度。例如一个TaskManager具有4个Slot,那么JVM的内存将会平均分配给每个Slot,每个Slot可以并发运行多个线程,处于同一个JVM中的多个子任务,可以使用同一个TaskManager心跳信息和TCP连接。当处理的数据量很大时,通过增加TaskManager及Slot个数,能够有效的提高数据处理速度,这也是分布式计算框架的核心设计思想。
JobClient用来接收客户端程序,将用户程序优化为可被Flink接收的数据结构JobGraph后,传递给JobManager进行调度执行。程序被调度执行后,通过JobClient能够获取程序的处理结果,也能向JobManager发送任务停止请求。
Flink的容错机制:
Flink基于异步分布式快照来实现容错机制,任务在执行过程中会持续创建分布式数据流及其状态的一致快照,这些快照以检查点Checkpoint的形式存放在外部存储系统中,当任务在执行过程中遇到故障而失畋时,可以通过选择某一时刻的状态快照进行恢复,从而保障数据被正确处理。
Flink分布式快照采用的算法是受Chandy-Lamport论文启发,并针对Flink执行模型进行定制开发,该异步分布式快照的容错机制是Flink的最大亮点之一。
Flink状态一般是指一个具体子任务或者操作需要记录的计算信息,而Checkpoint则是整个任务的所有操作,在某一时刻的状态汇总。
在Flink中,有两类对象需要具备容错的能力,分别是实现Checkpointed接口和StreamOperator接口的类,这两个类在任务执行过程中被调用,并将相关的状态信息记录到Checkpoint中。
Flink为我们提供了两种基础的状态,也是使用最多的两种状态即 Keyed State 和Operator State。
Keyed State 只能使用在Key Stream中,是跟特定的Key绑定,通常用在聚合操作中。
Operator State 跟特定操作的的并发实例绑定,最典型的应用是记录已消费外部数据源数据的偏移量。
Flink分布式快照通过JobManager定期向数据流中插入数据栅栏(Barrier)并跟踪Barrier的执行来决定是否要产生。Barrier作为数据流的一部分和数据一起向下流动,它不会对程序的执行结果有任何影响,并且能够保证新产生的Barrier不会被后产生的Barrier超越。根据Barrier插入数据流的位置,可以将数据流分割成两部分,一部分进入当前快照,另一部分进入下一个快照。每一个Barrier都带有当前快照的唯一标识,并且Barrier之前的数据也都进入了此快照,另外多个不同快照的多个Barrier会在流中同时出现,即多个快照可能同时创建。
Barrier从数据源的起始位置被下发,当快照n的Barrier插入后,系统会记录当前快照位置值,接着Barrier同流数据一起向下流动,当一个算子从其输入流接收到所有标识快照n的Barrier时,它会向其所有输出流发射一个标识快照n的Barrier n。当结果端从其输入的流数据中,接收到所有Barrier n时,它向CheckpointCoordinator确认快照n己完成。当并行的所有结果端确认了这个快照,则该快照就被标识为完成,并存储到外部文件系统。如果任务在执行过程中意外崩溃,那么Flink会选择最近一次己经完成的分布式快照进行恢复。
Kafka消息系统
Kafka是由LinkedIn公司使用Scala语言编写的分布式消息系统和存储系统,支持水平扩展并且有很高的吞吐量(每秒处理任务数),目前由Apache开源组织管理。
作为一个分布式的基于发布-订阅模式的消息系统,Kafka高吞吐量、可扩展性、持久性和可靠性的特性臝得了广大数据工程师的青睐。
Kafka主要的应用场景为日志收集、消息存储和消息订阅,处理的数据主要针对一些较活跃的流数据。对由多个子系统构成的消息系统,Kafka能够保障数据在各个子系统中快速高效运转。Kafka能够将Topic中分区Partition的数据交由唯一的消费者进行顺序消费,从而保证了分区内数据被消费的先后顺序。作为存储系统来讲,Kafka可以将接收到的数据写入到磁盘中备份以便容错,Kafka中的每个分区对应了操作系统中的一个文件夹,接收到的数据按先后顺序存储到文件中,这种按顺序将数据写入磁盘的机制,保证了即使数据占用空间很大性能也不会下降,这也是Kafka高吞吐率的一个很重要的保证。
Kafka集群架构
Kafka集群采用了分布式的架构模型,由若干Producer、Broker和Consumer共同组成,并通过Zookeeper来管理Kafka集群配置,当Leader节点地址发生变更以及消费者组配置发生改变时,能够及时有效的做出重新负载均衡操作。Producer和Consumer分别使用推(Push)、拉(Pull)模式对Broker进行消息发送和消费,从而能够在生产和消费速度不一致的情况下,有效保证整个集群的稳定性。Producer将产生的数据及时传送给Broker,Broker则作为中间缓存和数据分发的协调者,将数据传递给Consumer进行消费,Producer和Consumer能够使用各种编程语言实现,因此在各种编程语言实现的系统中都可以被使用。客户端和服务器端之间通信是基于一个简单的,高性能的,且与编程语言无关的TCP协议进行实现,从而保证了数据的快速传输。
下面介绍Kafka集群架构中的各个角色:
Broker:就是组成Kafka的多个服务器,一个Kafka集群包含了一个或多个Broker服务器,一个Broker中可以容纳多个Topic。启动Kafka服务端进程的单台服务器被称为Broker,介于Kafka分布式模型的架构设计,这就使得集群吞吐率随着Broker数量的增加而得到显著提升。
Producer:Kafka消息的生产者,就是向Broker发送消息的客户端。它将数据发送到Kafka Broker对应Topic的指定分区Partition中,分区内的数据都带有偏移量信息,消费者可以选择从指定偏移量开始消费分区数据。
Consumer:Kafka消息的消费者,通过从Broker中拉取数据进行消费。消费者通常使用一个消费者组ConsumerGroup来进行标识,一个Topic中的数据可以被多个消费者组同时读取,而在消费者组内部只能有一个消费者实例消费一条数据。
Topic和日志
Topic是生产者生产数据、消费者消费数据的队列标识,是存储数据记录的地方,不同的业务系统可以将数据打入不同的Topic中,而消费者消费数据时必须指定Topic信息。
一个Topic由一个或多个Partition组成,每个Partition可以单独存储在一个Broker上,也可以存储在多个Broker上。消费者可以往任一Partition发送消息,以此实现数据生产的分布式,任一Partition可以被多个消费者组消费,以此实现消费的分布式,因此Partition的设计是Kafka分布式消息框架的基础。
对于每一个Topic,Kafka集群都会维持一个分区日志,每个分区都保存着有序且顺序不变的记录集,并且不断追加到已提交日志文件中,分区内的每一条记录都会分配一个ID号来标识其在Partition中的顺序,我们称之为偏移量Offset,消费者可以设置偏移量从分区内的指定位置进行消费。
数据安全相关:
《三级等保措施下与外部系统信息交互的一种方法》
什么是三级等保?
每个单位或企业的信息系统的重要程度、应对威胁的能力、具有的安全保护能力等方面各不相同,所以需要按照系统受到破坏时,对客体造成侵害的程度分别进行不同等级的保护。
信息系统的安全等级被分为五个等级,他们分别是:
第一级自主保护、
第二级指导保护、
第三级监督保护、
第四级强制保护、
第五级专控保护。
三级等保是指信息系统受到破坏后,会对社会秩序和公共利益造成严重损害,或者对国家安全造成损害。
国家信息安全监管部门需对该级信息系统安全等级保护工作进行监督、检查。
三级等保信息系统适用于地级市以上国家机关、企业、事业单位内部重要信息系统,重要领域、重要部门跨省、跨市或全国(省)联网运行的用于生产、调度、管理、作业、指挥等方面的重要信息系统,跨省或全国联网运行的重要信息系统在省、地市的分支系统,中央各部委、省(区、市)门户网站和重要网站,跨省连接的网络系统等。
第三级安全保护能力需达到在统一安全策略下防护系统免受外来有组织的团体、拥有较为丰富资源的威胁源发起的恶意攻击、较为严重的自然灾难和其他相应程度的威胁所造成的主要资源损害,能够发现重要的安全漏洞和安全事件,在系统遭受攻击损害后,能较快恢复绝大部分功能。
三级等保信息系统与外界交互的传统方式:
通常情况下,三级等保信息系统中如果业务流程调度控制涉及必须从外部信息系统获取信息则需通过外部介质将需要传递给三级等保系统的信息拷贝到特定区域后,并对信息进行安全扫描后方可进入到三级等保系统。例如运行于电子政务外网的一套三级等保的政务系统需从互联网获取信息通常是将该互联网信息拷贝到电子政务外网系统可访问的位置,对该信息进行安全检查处理后该三级等保政务系统方可使用该信息。
------------------------------------------------我是分隔线---------------------------------------------
SparkCore为什么可以取代MapReduce?
Spark计算速度为什么比MapReduce快?
1.Spark申请资源的粗粒度的申请资源。在提交一个应用程序的时候Spark先去申请资源,申请到了资源之后先启动executer,当基本工作完成之后,它才进行任务的分发,不管任务是运行在standalone集群还是yarn集群都是这样一个模式,所以它是粗粒度的申请资源,我们在进行任务调度的时候,每一个任务启动的速度就变快了。并且每一个Task执行完之后,它并不会把当前的executer给kill掉,而是等所有的Task都执行完之后,才会释放资源,kill掉那些executer
有利有弊:(自行总结:粗粒度与细粒度资源调用的区别以及利弊)
利:让我们的Task启动时间变快,整体的执行时间变短
弊:浪费集群资源
MapReduce是一个细粒度的资源调度,每一个Task都会启动一个JVM,当Task执行完之后,它就会把这个JVM干掉,正因为Spark是一个粗粒度的资源调度,所以说Spark可以基于内存来计算,可以把有些RDD的计算结果进行cache或persist,从另外一个角度pipeline的计算模式,每一个算子执行完之后的结果,立马迁移给另外一个算子
什么是pipeline管道:迭代器调用
Spark中的pipeline叫chain,只不过是pipeline改了个名字
// 写一段伪代码
val rdd=sc.textFile(xxxx)
val maprdd=rdd.map(x=>{
println("map")
x
})
maprdd.filter(x=>{
println("filter")
true
}).count
打印结果是什么样子,先打印map还是filter?
先打印map
第一个RDD中会封装着textFile()的逻辑
第二个mapRdd中存放的是map(xxx)的逻辑
第三个filterRdd中存放的是filter(xxx)的逻辑
如果这个Rdd里面有两个partition,每个partition里面封装都都是这样的逻辑,而不是真正的数据。