CN116974851A - 基于分布式调度的实时监控Spark引擎输出进度的方法及平台 - Google Patents
基于分布式调度的实时监控Spark引擎输出进度的方法及平台 Download PDFInfo
- Publication number
- CN116974851A CN116974851A CN202310949386.XA CN202310949386A CN116974851A CN 116974851 A CN116974851 A CN 116974851A CN 202310949386 A CN202310949386 A CN 202310949386A CN 116974851 A CN116974851 A CN 116974851A
- Authority
- CN
- China
- Prior art keywords
- task
- progress
- output
- tasks
- spark
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000012544 monitoring process Methods 0.000 title claims abstract description 63
- 238000000034 method Methods 0.000 title claims abstract description 40
- 238000012545 processing Methods 0.000 claims description 30
- 238000004364 calculation method Methods 0.000 claims description 19
- 230000004044 response Effects 0.000 claims description 11
- 230000008569 process Effects 0.000 claims description 10
- 238000006243 chemical reaction Methods 0.000 claims description 9
- 230000001960 triggered effect Effects 0.000 claims description 3
- 238000012423 maintenance Methods 0.000 abstract description 4
- 230000002159 abnormal effect Effects 0.000 description 3
- 238000013461 design Methods 0.000 description 3
- 238000010586 diagram Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000002688 persistence Effects 0.000 description 2
- 230000002085 persistent effect Effects 0.000 description 2
- 238000011084 recovery Methods 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000003139 buffering effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000004140 cleaning Methods 0.000 description 1
- 230000000052 comparative effect Effects 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 239000008358 core component Substances 0.000 description 1
- 238000007418 data mining Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000036541 health Effects 0.000 description 1
- 238000010801 machine learning Methods 0.000 description 1
- 230000011218 segmentation Effects 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 239000000725 suspension Substances 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3051—Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Software Systems (AREA)
- Mathematical Physics (AREA)
- Debugging And Monitoring (AREA)
Abstract
本发明公开了一种基于分布式调度的实时监控Spark引擎输出进度的方法及平台,属于信息技术领域,包括:任务创建、任务执行和进度监控及任务状态和进度监控展示。本发明整合分布式调度与Spark计算引擎,采用MasterServer、WorkerServer及SeaTunnel引擎进行任务执行和进度监控,实时从Spark计算引擎端获取输出进度的相关信息并发送回调度系统,让用户能够在利用可靠且性能稳定的调度能力以及高性能可扩展的计算能力的同时,方便地从调度监控的页面中实时地看到任务的输出进度情况,提高数据对账效率,降低数据运维成本。
Description
技术领域
本发明涉及信息技术、大数据技术领域,特别是一种基于分布式调度的实时监控Spark引擎输出进度的方法。
背景技术
计算引擎和任务调度系统是数据中台建设的两个最核心的组件。
其中,Spark是一个开源的基于内存的分布式计算引擎,可以支持SQL即席查询、实时流计算、机器学习、图计算等等,Spark可以部署在资源管理器YARN之上,提供一站式的大数据解决方案,在数据采集、清洗、加工、数据挖掘等各个环节中都起到了重要的作用。
而,调度系统为数据中台中的各种数据任务的执行提供了定时调度、任务依赖调度、手动调度、调度监控、容错恢复等功能。
目前,用于调度Spark任务的调度系统主要有Oozie、Airflow、DolphinScheduler、Azkaban,它们都能监控Spark任务的开始时间、结束时间、成功或者失败。但是,对于向外部存储输出数据的任务并不能实时监控其输出进度,特别是对于需要长时间运行的处理海量数据的任务,用户难以及时采取有效措施防止异常的产生或者及时恢复业务,如果任务失败也不能显示成功输出了多少、失败了多少,用户难以及时了解任务运行情况、难以进行数据对账。
发明内容
本发明的发明目的是,针对上述问题,提供一种基于分布式调度的实时监控Spark引擎输出进度的方法,实时从计算引擎端获取输出进度的相关信息并发送回调度系统,便于从调度监控的页面中实时地看到任务的输出进度情况,提高数据对账效率,降低数据运维成本。
为达到上述目的,本发明所采用的技术方案是:
基于分布式调度的实时监控Spark引擎输出进度的方法,包括以下内容:
步骤S10、任务创建:创建Spark任务,设置输入数据源、输出数据源、数据处理、计算规则及使用资源;设置调度规则,选中需要调度的任务,设置定时触发的规则或者任务依赖的规则;
步骤S20、任务执行和进度监控,具体处理流程包括:
步骤S21、分发任务:MasterServer定时轮询任务调度信息,获取符合触发执行条件的任务,然后将任务分发给WorkerServer;
步骤S22、执行任务:WorkerServer接收到MasterServer分发的任务,然后执行shell启动SeaTunnel引擎,并通过shell的退出码监听任务是否成功启动,然后发送任务启动应答信息给MasterServer更新任务运行状态;
步骤S23、提交Spark任务:SeaTunnel解析WorkerServer指定的配置文件后,把应用提交到YARN上,然后生成Spark应用的数据处理链路;
步骤S24、监控任务进度:YARN在driver端统计和缓存待输出总数,然后实时获取和累加各计算节点的已输出总数,再由进度汇报线程发送任务进度信息给MasterServer更新任务进度;
步骤S30、任务状态和进度监控展示:获取任务状态和进度监控信息进行展示。
其中,步骤S21具体内容如下:MasterServer服务启动后定时通过jdbc轮询任务调度信息,获取符合触发执行条件的任务,然后通过Zookeeper获取资源可用的Worker地址和端口相关信息,然后使用Netty将任务分发给WorkerServer。
步骤S22具体内容如下:WorkerServer接收到MasterServer分发的任务,根据接收的任务信息生成临时的执行目录、SeaTunnel配置文件、和启动SeaTunnel的shell脚本,然后执行shell启动SeaTunnel引擎;SeaTunnel启动后WorkerServer使用Netty向MasterServer发送应答消息,MasterServer接收到应答消息后通过jdbc连接DB,把任务状态更新为运行中;当任务完成或者任务失败后,WorkerServer使用Netty向MasterServer发送任务结果信息,MasterServer接收到结果信息后通过jdbc连接DB,把该任务状态更新为完成或失败。
步骤S23具体内容如下:SeaTunnel解析WorkerServer指定的配置文件后,把应用提交到YARN上;YARN分配资源后初始化Driver程序,根据SeaTunnel提交的资源配置信息初始化SparkSession,再获取输入数据源配置信息使用SparkSession创建DataFrameReader,然后从DataFrameReader获取Dataset并根据数据处理和计算规则配置定义Dataset转换和计算的步骤,再从完成定义步骤后的Dataset根据输出数据源配置生成DataFrameWriter,形成一个或多个“读取->转换和计算->输出”的Spark数据处理链路,且每个链路最终通过DataFrameWriter的save接口触发执行,运算任务分发到YARN的各个节点初始化executor进行分布式执行。
步骤S24具体内容如下:YARN初始化SparkSession后启动一进度汇报线程,每隔一个心跳时间,该线程就使用Netty把指任务进度信息发送给MasterServer,由MasterServer持久化到DB;其中,待输出总数从“完成定义步骤后的Dataset”调用count接口统计获取,获取待输出总数数值后缓存Dataset和统计值,进度汇报线程从缓存中取值;当前已输出总数需要分别收集每个executor中已输出数值并进行累加,然后发送回进度汇报线程中;初始化SparkSession后创建LongAccumulator,并设置到DataFrameWriter的写入算子访问域内,写入算子每完成一次输出提交后,LongAccumulator则累加已输出数值,之后进度汇报线程就可以使用LongAccumulator的value接口实时获取当前已输出总数。
由于采用上述技术方案,本发明具有以下有益效果:
本发明整合分布式调度与Spark计算引擎,采用MasterServer、WorkerServer及SeaTunnel引擎进行任务执行和进度监控,实时从Spark计算引擎端获取输出进度的相关信息并发送回调度系统,让用户能够在利用可靠且性能稳定的调度能力以及高性能可扩展的计算能力的同时,方便地从调度监控的页面中实时地看到任务的输出进度情况,提高数据对账效率,降低数据运维成本。
附图说明
图1是本发明的监控Spark引擎输出进度的方法的流程图。
图2是本发明的监控Spark引擎输出进度的平台架构及服务示意图。
图3是本发明的Spark数据处理链路示意图。
具体实施方式
以下结合附图对发明的具体实施进一步说明。
参见图1,如上述,该监控Spark引擎输出进度的方法包括步骤S10-步骤S24的处理程序,其存储在存储器并配置成由处理器执行,相关存储器及处理器等均采用既有技术,在此不再赘述。据该监控Spark引擎输出进度的方法可组成基于分布式调度的实时监控Spark引擎输出进度的平台,下述将对该监控Spark引擎输出进度的方法及平台进行具体说明。
如图1及图2所示,该监控Spark引擎输出进度的平台包括UI端、ApiServer、MasterServer、WorkerServer及SeaTunnel引擎;其中,交互和业务端设计遵循MVC分层理论,并采用前后端分离的模式,任务调度和执行端采用去中心化Master/Worker集群模式,Worker端通过SeaTunnel生成并提交Spark任务。整个平台主要包括UI服务、ApiServer、MasterServer、WorkerServer、SeaTunnel引擎,UI端及ApiServer用于进行任务创建及任务状态和进度监控展示,MasterServer、WorkerServer及SeaTunnel引擎用于进行任务执行和进度监控,各服务主要功能说明如下。
UI服务:系统的前端页面,提供系统的各种可视化操作界面,包括任务创建、任务监控、暂停、恢复、重跑等。
ApiServer:API接口层,主要负责处理前端UI层的请求。该服务统一提供RESTfulapi向外部提供请求服务。接口包括工作流的创建、定义、查询、修改、发布、下线、手工启动、停止、暂停、恢复、从该节点开始执行等等。
MasterServer:MasterServer采用分布式无中心设计理念,MasterServer主要负责DAG任务切分、任务提交监控,并同时监听其它MasterServer和WorkerServer的健康状态。MasterServer服务启动时向Zookeeper注册临时节点,通过监听Zookeeper临时节点变化来进行容错处理。MasterServer基于netty提供监听服务。
WorkerServer:WorkerServer也采用分布式无中心设计理念,支持自定义任务插件,主要负责任务的执行和提供日志服务。WorkerServer服务启动时向Zookeeper注册临时节点,并维持心跳。
SeaTunnel引擎:SeaTunnel可以把配置文件翻译成Spark任务,并将生成的任务和依赖提交到Yarn集群进行分布式运算。
如上述,各服务之间的处理流程如下:
步骤S10、任务创建:Spark任务的创建由UI服务和ApiServer两个服务完成,服务间通过HTTP协议进行通讯,UI作为请求客户端,ApiServer作为服务端提供RESTful api,流程如下:
a)用户在UI端配置外部数据源信息后调用ApiServer接口保存数据源配置,ApiServer通过jdbc将配置信息保存到DB。
b)用户在UI端创建任务,UI端调用ApiServer接口获取可用数据源,ApiServer通过jdbc读取配置信息并返回给UI,用户在UI上选择可用数据源配置数据处理任务的输入、输出、处理逻辑、使用资源后提交,UI端调用ApiServer接口,ApiServer接收到请求后将配置转换成SeaTunnel任务配置文件并保存。
c)用户在UI端进行调度设置,选中需要设置的任务后设置好定时触发的规则或者任务依赖的规则后提交,UI端调用ApiServer接口,ApiServer接收到请求后通过jdbc将调度信息保存到DB。
步骤S2、任务执行和进度监控:Spark任务的执行和输出进度监控由MasterServer、WorkerServer以及SeaTunnel三个部分相互协作共同完成,流程如下:
a)MasterServer获取和分发任务:MasterServer服务启动后,后台线程通过jdbc轮询任务调度信息获取符合触发执行条件的任务,然后通过Zookeeper获取资源可用的Worker地址和端口相关信息,然后使用Netty将任务分发给WorkerServer。
b)WorkerServer接收并执行任务:WorkerServer在接收到MasterServer分发的任务后,根据接收的任务信息生成临时的执行目录、SeaTunnel配置文件、和启动SeaTunnel的shell脚本,然后执行shell启动SeaTunnel引擎。启动后WorkerServer使用Netty向分发任务的MasterServer发送启动应答消息,MasterServer接收到启动应答消息后通过jdbc连接DB把任务状态(启动状态)更新为运行中。当任务完成或者任务失败后,WorkerServer同样使用Netty向分发任务的MasterServer发送任务状态信息,MasterServer接收到状态信息后通过jdbc连接DB更新任务状态。
c)SeaTunnel生成并提交Spark任务:WorkerServer执行shell启动SeaTunnel后,SeaTunnel解析WorkerServer指定的配置文件后把应用提交到YARN上。YARN分配资源后初始化Driver程序,根据SeaTunnel提交的资源配置信息初始化SparkSession,再获取输入数据源配置信息使用SparkSession创建DataFrameReader,然后再从DataFrameReader获取Dataset并根据数据处理和计算规则配置定义Dataset的转换和计算步骤,然后再从经过定义步骤后的Dataset(完成定义步骤后的Dataset)根据输出数据源的配置生成DataFrameWriter,形成一个或多个“读取->转换和计算->输出”的Spark数据处理链路(见图3),每个链路最终通过DataFrameWriter的save接口触发执行,运算任务分发到YARN的各个节点初始化executor进行分布式执行。
d)任务进度和状态信息获取和保存:任务进度信息的获取一共需要两个指标数据,一个是待输出的总数,另一个是当前已输出总数。在流程c)中,初始化SparkSession后启动一个后台线程用于实时将指标数据发送回调度服务,每隔一个心跳时间,该线程就使用Netty把指标数据发送给MasterServer,由MasterServer持久化到DB。其中,待输出总数从流程c)的“经过定义转换和计算步骤后的Dataset”调用count接口统计获取,获取数值后缓存Dataset和统计值,避免重复计算,进度汇报线程从缓存中取值。而当前已输出总数因为需要每隔一个心跳时间实时获取最新数值,因而不能使用预统计和缓存的方法。YARN中的Spark任务会把运算任务分发到相同或者不同节点的executor中执行,获取当前已输出总数需要分别收集每个executor中已输出的数值然后进行累加,然后发送回driver的汇报线程中,这里使用了Spark的LongAccumulator来实现:在流程c)中,初始化SparkSession后创建LongAccumulator,并设置到DataFrameWriter的写入算子访问域内,写入算子每完成一次输出提交后,LongAccumulator则累加对应输出值。这样之后进度汇报线程就可以使用LongAccumulator的value接口实时获取当前已输出的总数了。任务状态的获取则相对简单,因为任务由WorkerServer执行shell启动,运行结束后WorkerServer通过shell的退出状态码判断任务成功或者失败,然后使用Netty把状态发送给MasterServer,最终由MasterServer通过jdbc把任务状态持久化到DB。
步骤S30、任务状态和进度监控展示:Spark任务的状态和进度相关信息的展示由UI服务和ApiServer两个服务完成,用户通过UI服务选择需要查看的相关任务,UI端调用ApiServer接口获取任务状态和进度信息,ApiServer通过jdbc获取由MasterServer实时更新的DB相关状态和进度信息返回给UI端,最终展示给用户。
如上述,该监控Spark引擎输出进度的平台中,在用户通过浏览器访问平台的Web页面的交互步骤说明如下:
1)创建数据源:用户进入数据源管理页面,点击创建数据源按钮,然后在表单中设置ip地址、端口等相关参数后测试连接可用后保存。
2)创建任务:用户进入任务管理页面,点击创建任务按钮,在页面中设置输入数据源、输出数据源、数据处理和计算规则、使用资源等信息后保存。
3)设置调度:用户进入任务管理页面,选择需要调度的任务点击调度设置按钮,在表单中设置触发规则后保存。
4)查看调度情况:用户进入调度管理页面,查看任务的调度情况、运行历史等信息。
5)查看任务运行情况:用户进入任务实例管理页面,查看Spark任务的运行状态、输出进度相关指标。
6)进行数据对账:用户根据自己业务的具体情况,对照5)的待写入总数(待输出总数)和已写入总数(已输出总数)进行核对,如果数值有偏差则进行相应处理。
如上述,本发明使用了已完成数和总数两个关键指标,作为进度监控方法基本指标,下述将从技术细节和应用场景上继续分析说明本发明的该监控Spark引擎输出进度的方法及平台的优势。
本发明的该监控Spark引擎输出进度的方法及平台,所获取的指标是精确到数据输出外部数据源的task,获取的指标是“已输出数据总条数”和“待输出数据总条数”,指标获取的关键步骤是:始化SparkSession后创建LongAccumulator,并设置到DataFrameWriter的输出算子访问域内,先使用count接口统计得到“待输出数据总条数”,然后再执行输出任务,输出算子每完成一次输出提交后,LongAccumulator则累加对应输出值,然后driver端通过LongAccumulator的value接口获取“已输出数据总条数”。
作为对比示例,通过调用Spark RESTAPI获取已完成任务数和总任务数的这种方法所实现的监控仅适用于只有单个job的Spark application,因为Spark引擎对于job的调度是串行的,只有当前job的所有task执行完毕才会继续切分和调度下一个job,也就是说它不能从任务开始时就获取到所有的任务总数,因此,当有多个job时进度显示会出现谬误。同时,该“针对task的监控:一个stage里所有的task列表”具体到了代码行的层面,需要对Spark很了解才能理解,需要专业开发人员解读。若将其应用在业务人员(非专业开发人员)进行数据对账场景中,业务人员只知道完成了多少个task,并不知道每个task输出了多少条数据,也不知道总共需要输出多少条数据,根本无法完成数据对账工作。
而相对的,本发明的该监控Spark引擎输出进度的方法则没有这种限制。本发明的该监控Spark引擎输出进度的方法,单个job和多个job都能适用,而且,指标能精确到数据的条数,监控粒度细。
本发明适用于实时监控向外部存储输出数据的任务,用户通过监控能精确地了解到当前有多少条待输出的数据、有多少条已输出的数据。如果任务发生异常,用户在进行数据对账时能知道成功输出了多少、失败了多少,以进行准确的补数操作。用户只需关注数据的业务处理即可,无需了解任何Spark相关的知识。本发明的监控维度精确到数据输出条数的粒度,适用于数据业务人员进行数据对账。
上述对该监控Spark引擎输出进度的方法及平台作出具体说明,结合图2和图3,下述将以某单位的数据中台的数据入湖和对账过程为例,进一步对本发明的具体工作过程进行说明。
某单位的数据中台的数据入湖和对账过程可分成以下步骤:
步骤1.用户在平台的数据源管理页面新增需要入湖的业务数据数据源信息,提交后UI端通过RestApi接口调用ApiServer,由ApiServer持久化数据源信息到DB。
步骤2.用户在平台的任务管理页面创建任务,设置需要入湖的业务数据的数据源、入湖规则、使用资源等信息,提交后UI端通过RestApi接口调用ApiServer,由ApiServer通过JDBC持久化任务信息到DB。
步骤3.用户在平台的任务管理页面,选择需要调度的任务设置调度规则,设置好触发规则后提交,提交后UI端通过RestApi接口调用ApiServer,由ApiServer通过JDBC持久化任务的调度规则信息到DB。
步骤4.MasterServer定时通过JDBC轮询DB,当用户创建的任务符合执行条件时,MasterServer把任务分发给WorkerService。
步骤5.WorkerService接收到用户创建的任务后通过shell启动SeaTunnel,并通过shell的退出码监听任务是否成功启动,然后使用Netty发送任务状态信息(运行中、已完成或失败)给MasterServer进行持久化。
步骤6.SeaTunnel启动后提交用户的数据入湖任务到YARN,然后根据配置生成Spark应用的数据处理链路,并在driver端统计和缓存待写入总数,然后实时获取和累加各计算节点的已写入总数后使用Netty发送进度信息给MasterServer进行持久化。
步骤7.用户进入平台的调度管理页面,UI端调用ApiServer获取DB最新的任务状态数据,用户即可查看任务的调度情况、运行历史等信息,进行审计或者确认调度是否正常,如果存在异常则及时处理。
步骤8.用户进入平台的任务实例管理页面,UI端调用ApiServer获取DB最新的任务进度指标数据,用户即可查看Spark任务的运行状态、输出进度相关指标,确认输出进度有无异常,根据入湖业务数据的具体情况进行核对,如果数值有偏差则进行相应处理。
如上述,本发明的该监控Spark引擎输出进度的方法及平台,提供了一种整合分布式调度与Spark计算引擎的方法和平台,通过页面配置生成SeaTunnel任务配置,再在SeaTunnel生成的Spark数据处理链路中加入指标获取算子,实现实时从计算引擎端获取输出进度的相关信息并发送回调度系统,让用户能够在利用可靠且性能稳定的调度能力以及高性能可扩展的计算能力的同时,方便地从调度监控的页面中实时地看到任务的输出进度情况,提高数据对账效率,降低数据运维成本。
需要指出的是,上述实施例的实例可以根据实际需要优选一个或两个以上相互组合,而多个实例采用一套组合技术特征的附图说明,在此就不一一展开说明。
上述说明是针对本发明较佳可行实施例的详细说明和例证,但这些描述并非用以限定本发明所要求保护范围,凡本发明所提示的技术教导下所完成的同等变化或修饰变更,均应属于本发明所涵盖专利保护范围。
Claims (10)
1.基于分布式调度的实时监控Spark引擎输出进度的方法,其特征在于,包括以下内容:
步骤S10、任务创建:创建Spark任务,设置输入数据源、输出数据源、数据处理、计算规则及使用资源;设置调度规则,选中需要调度的任务,设置定时触发的规则或者任务依赖的规则;
步骤S20、任务执行和进度监控,具体处理流程包括:
步骤S21、分发任务:MasterServer定时轮询任务调度信息,获取符合触发执行条件的任务,然后将任务分发给WorkerServer;
步骤S22、执行任务:WorkerServer接收到MasterServer分发的任务,然后执行shell启动SeaTunnel引擎,并通过shell的退出码监听任务是否成功启动,然后发送任务启动应答信息给MasterServer更新任务运行状态;
步骤S23、提交Spark任务:SeaTunnel解析WorkerServer指定的配置文件后,把应用提交到YARN上,然后生成Spark应用的数据处理链路;
步骤S24、监控任务进度:YARN在driver端统计和缓存待输出总数,然后实时获取和累加各计算节点的已输出总数,再由进度汇报线程发送任务进度信息给MasterServer更新任务进度。
步骤S30、任务状态和进度监控展示:获取任务状态和进度监控信息进行展示。
2.根据权利要求1所述的基于分布式调度的实时监控Spark引擎输出进度的方法,其特征在于:步骤S21具体内容如下:MasterServer服务启动后定时通过jdbc轮询任务调度信息,获取符合触发执行条件的任务,然后通过Zookeeper获取资源可用的Worker地址和端口相关信息,然后使用Netty将任务分发给WorkerServer。
3.根据权利要求1所述的基于分布式调度的实时监控Spark引擎输出进度的方法,其特征在于:步骤S22具体内容如下:WorkerServer接收到MasterServer分发的任务,根据接收的任务信息生成临时的执行目录、SeaTunnel配置文件、和启动SeaTunnel的shell脚本,然后执行shell启动SeaTunnel引擎;SeaTunnel启动后WorkerServer使用Netty向MasterServer发送应答消息,MasterServer接收到应答消息后通过jdbc连接DB,把任务状态更新为运行中;当任务完成或者任务失败后,WorkerServer使用Netty向MasterServer发送任务结果信息,MasterServer接收到结果信息后通过jdbc连接DB,把该任务状态更新为完成或失败。
4.根据权利要求1所述的基于分布式调度的实时监控Spark引擎输出进度的方法,其特征在于:步骤S23具体内容如下:SeaTunnel解析WorkerServer指定的配置文件后,把应用提交到YARN上;YARN分配资源后初始化Driver程序,根据SeaTunnel提交的资源配置信息初始化SparkSession,再获取输入数据源配置信息使用SparkSession创建DataFrameReader,然后从DataFrameReader获取Dataset并根据数据处理和计算规则配置定义Dataset转换和计算的步骤,再从完成定义步骤后的Dataset根据输出数据源配置生成DataFrameWriter,形成一个或多个“读取->转换和计算->输出”的Spark数据处理链路,且每个链路最终通过DataFrameWriter的save接口触发执行,运算任务分发到YARN的各个节点初始化executor进行分布式执行。
5.根据权利要求1所述的基于分布式调度的实时监控Spark引擎输出进度的方法,其特征在于:步骤S24具体内容如下:YARN初始化SparkSession后启动一进度汇报线程,每隔一个心跳时间,该线程就使用Netty把指任务进度信息发送给MasterServer,由MasterServer持久化到DB;其中,待输出总数从“完成定义步骤后的Dataset”调用count接口统计获取,获取待输出总数数值后缓存Dataset和统计值,进度汇报线程从缓存中取值;当前已输出总数需要分别收集每个executor中已输出数值并进行累加,然后发送回进度汇报线程中;初始化SparkSession后创建LongAccumulator,并设置到DataFrameWriter的写入算子访问域内,写入算子每完成一次输出提交后,LongAccumulator则累加已输出数值,之后进度汇报线程就可以使用LongAccumulator的value接口实时获取当前已输出总数。
6.基于分布式调度的实时监控Spark引擎输出进度的平台,其特征在于:包括UI端、ApiServer、MasterServer、WorkerServer及SeaTunnel引擎,用于进行如下处理流程:
步骤S10、UI端及ApiServer用于进行任务创建:创建Spark任务,设置输入数据源、输出数据源、数据处理、计算规则及使用资源;设置调度规则,选中需要调度的任务,设置定时触发的规则或者任务依赖的规则;
步骤S20、MasterServer、WorkerServer及SeaTunnel引擎用于进行任务执行和进度监控,具体处理流程包括:
步骤S21、分发任务:MasterServer定时轮询任务调度信息,获取符合触发执行条件的任务,然后将任务分发给WorkerServer;
步骤S22、执行任务:WorkerServer接收到MasterServer分发的任务,然后执行shell启动SeaTunnel引擎,并通过shell的退出码监听任务是否成功启动,然后发送任务启动应答信息给MasterServer更新任务运行状态;
步骤S23、提交Spark任务:SeaTunnel解析WorkerServer指定的配置文件后,把应用提交到YARN上,然后生成Spark应用的数据处理链路;
步骤S24、监控任务进度:YARN在driver端统计和缓存待输出总数,然后实时获取和累加各计算节点的已输出总数,再由进度汇报线程发送任务进度信息给MasterServer更新任务进度;
步骤S30、UI端及ApiServer用于进行任务状态和进度监控展示:UI端调用ApiServer接口获取任务状态和进度监控信息进行展示。
7.根据权利要求6所述的基于分布式调度的实时监控Spark引擎输出进度的平台,其特征在于:步骤S21具体内容如下:MasterServer服务启动后定时通过jdbc轮询任务调度信息,获取符合触发执行条件的任务,然后通过Zookeeper获取资源可用的Worker地址和端口相关信息,然后使用Netty将任务分发给WorkerServer。
8.根据权利要求6所述的基于分布式调度的实时监控Spark引擎输出进度的平台,其特征在于:步骤S22具体内容如下:WorkerServer接收到MasterServer分发的任务,根据接收的任务信息生成临时的执行目录、SeaTunnel配置文件、和启动SeaTunnel的shell脚本,然后执行shell启动SeaTunnel引擎;SeaTunnel启动后WorkerServer使用Netty向MasterServer发送应答消息,MasterServer接收到应答消息后通过jdbc连接DB,把任务状态更新为运行中;当任务完成或者任务失败后,WorkerServer使用Netty向MasterServer发送任务结果信息,MasterServer接收到结果信息后通过jdbc连接DB,把该任务状态更新为完成或失败。
9.根据权利要求6所述的基于分布式调度的实时监控Spark引擎输出进度的平台,其特征在于:步骤S23具体内容如下:SeaTunnel解析WorkerServer指定的配置文件后,把应用提交到YARN上;YARN分配资源后初始化Driver程序,根据SeaTunnel提交的资源配置信息初始化SparkSession,再获取输入数据源配置信息使用SparkSession创建DataFrameReader,然后从DataFrameReader获取Dataset并根据数据处理和计算规则配置定义Dataset转换和计算的步骤,再从完成定义步骤后的Dataset根据输出数据源配置生成DataFrameWriter,形成一个或多个“读取->转换和计算->输出”的Spark数据处理链路,且每个链路最终通过DataFrameWriter的save接口触发执行,运算任务分发到YARN的各个节点初始化executor进行分布式执行。
10.根据权利要求6所述的基于分布式调度的实时监控Spark引擎输出进度的平台,其特征在于:步骤S24具体内容如下:YARN初始化SparkSession后启动一进度汇报线程,每隔一个心跳时间,该线程就使用Netty把指任务进度信息发送给MasterServer,由MasterServer持久化到DB;其中,待输出总数从“完成定义步骤后的Dataset”调用count接口统计获取,获取待输出总数数值后缓存Dataset和统计值,进度汇报线程从缓存中取值;当前已输出总数需要分别收集每个executor中已输出数值并进行累加,然后发送回进度汇报线程中;初始化SparkSession后创建LongAccumulator,并设置到DataFrameWriter的写入算子访问域内,写入算子每完成一次输出提交后,LongAccumulator则累加已输出数值,之后进度汇报线程就可以使用LongAccumulator的value接口实时获取当前已输出总数。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310949386.XA CN116974851A (zh) | 2023-07-31 | 2023-07-31 | 基于分布式调度的实时监控Spark引擎输出进度的方法及平台 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310949386.XA CN116974851A (zh) | 2023-07-31 | 2023-07-31 | 基于分布式调度的实时监控Spark引擎输出进度的方法及平台 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN116974851A true CN116974851A (zh) | 2023-10-31 |
Family
ID=88472739
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202310949386.XA Pending CN116974851A (zh) | 2023-07-31 | 2023-07-31 | 基于分布式调度的实时监控Spark引擎输出进度的方法及平台 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN116974851A (zh) |
-
2023
- 2023-07-31 CN CN202310949386.XA patent/CN116974851A/zh active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN106549829B (zh) | 大数据计算平台监控系统及方法 | |
US9727405B2 (en) | Problem determination in distributed enterprise applications | |
CN106487596B (zh) | 分布式服务跟踪实现方法 | |
US9678964B2 (en) | Method, system, and computer program for monitoring performance of applications in a distributed environment | |
KR101683321B1 (ko) | 분산 애플리케이션들을 모니터링 하는 방법 | |
US10116534B2 (en) | Systems and methods for WebSphere MQ performance metrics analysis | |
US20110078519A1 (en) | Internal Server Error Analysis | |
US20120159517A1 (en) | Managing a model-based distributed application | |
US20120158925A1 (en) | Monitoring a model-based distributed application | |
JP7254975B2 (ja) | 実行可能論理を用いて構造化データアイテムを処理するためのキーベースのロギング | |
US20130124720A1 (en) | Usage reporting from a cloud-hosted, distributed system | |
EP3204848B1 (en) | Real-time reporting based on instrumentation of software | |
WO2016057211A1 (en) | Real-time reporting based on instrumentation of software | |
US20120254277A1 (en) | Aggregating information of distributed jobs | |
CN116974851A (zh) | 基于分布式调度的实时监控Spark引擎输出进度的方法及平台 | |
Chhetri et al. | CL-SLAM: Cross-layer SLA monitoring framework for cloud service-based applications | |
CN113296840B (zh) | 一种集群运维方法及装置 | |
US20230124387A1 (en) | Server performance and application health management system and method | |
Legrand et al. | Workflow management in large distributed systems | |
CN116339999A (zh) | 线程池监控预警方法及装置 | |
CN114418342A (zh) | 一种业务数据处理方法、装置和可读存储介质 | |
Bubak et al. | GRID MONITORING BASED ON COMPLEX EVENT PROCESSING TECHNOLOGIES |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |