e-works数字化企业网  »  文章频道  »  基础信息化  »  大数据

面向大数据的分布式调度

2017/8/23    来源:极客头条    作者:梁福坤      
关键字:大数据  分布式调度  
大数据的分布式调度是在进行数据ETL过程中起到了总体的承上启下的角色,整个数据的生产、交付、消费都会贯穿其中,本文从调度、分布式调度的特征展开,再对大数据调度个性化特征的一些阐述。
    前言:大数据的分布式调度是在进行数据ETL过程中起到了总体的承上启下的角色,整个数据的生产、交付、消费都会贯穿其中,本文从调度、分布式调度的特征展开,再对大数据调度个性化特征的一些阐述,由满足大数据使用的架构和业务场景的需求上娓娓道来,从实践的角度分享如何打造一个高可用、高效率、灵活性的大数据调度平台。
 
    一、调度
 
    从上个世纪50年代起,调度问题的研究就受到数学、运筹学、工程技术学等领域科学的重视[1],人们主要从数学的角度来研究调度问题,调度问题也同样被定义为”分配一组资源来执行一组任务”,以获得生产任务执行时间或成本的最优[2]。调度在计算机任务的实现可以依赖操作系统的定时任务进行触发(例如Linux系统的Crontab),主要针对单任务机制的触发,调度最基本的需要能够按时或者按照事件进行触发(At-least-once),如果任务不符合预期,还需要在应用端进行重试,最大可能保证任务被按时执行,并且成功执行,同时不能多次执行(Exactly once);但是在业务场景能保证可重复执行、一致性操作情况下对于争取能正常调度执行多次执行也是不可或缺的,比如给商户进行1min前的例行结算,如果结算是按照30min的时间窗口查找未结算的商户,那么就会容忍30min延迟,并且多次被执行也不会给商户多结算,因为在结算付款和重置是否结算标志位可以设计成原子性操作。所以在调度上能够做到按时、正确的执行,在业务方设计为了保证最终一致性也有一些架构上的取舍。
 
    如果应用场景有上下游的协作,或者在任务执行会存在不同的宿主机来完成,或者为了保证任务高可用场景,就需要引入分布式调度的架构。
 
    二、分布式调度
 
    分布式调度是在单机的基础上发展起来,在综合考虑高可用、高效率、分布式协作的背景下逐步演进的调度方式,从单点调度到分布式协作是一个质变的过程,这个过程涉及到许多在单机并不存在的特征,下面针对重点展开聊下:
 
分布式调度组件化分解图
 
    图1 分布式调度组件化分解图
 
    2.1 调度器去中心化&高可用
 
    涉及到分布式调度的协作,就需要有调度中心节点,同时要保证高可用的目的就需要调度中心节点是多节点发布,主备的方式去单点依赖。
 
    2.2 宿主选择
 
    分布式调度在任务执行阶段,可以在目标宿主中进行全部执行、N选M(N>=M>=1)的选择,宿主机具备相同类型任务互备的机制,在MPP(Massively Parallel Processor)架构中尤为常见,把大任务分而治之快速完成。也存在场景(比如外卖给商户结算)为了一致性和准确性只能由一台主机进行执行,并且需要成功执行。
 
    被动选择策略:宿主的被动选择机制一般可以随机或者按照顺序选择策略,也可以按照当前宿主机进行的任务执行数量的方式进行常规的调度分配。当然,也可以进行高级的操作,参照宿主机的处理能力(吞吐量和响应时间)、资源使用情况(CPU、Memory、Disk I/O、Net I/O等)进行反馈机制的动态分配。后者需要有集中节点存储当前宿主机的处理能力、资源情况,便于在决策选择中提供参照。
 
    主动选择策略:宿主的主动选择具备更加丰富的选举策略,任务在下达到具体算子时,会比较明确的定义出当前任务需要由多少个宿主参与执行,通过zookeeper的分布式锁来实现锁的抢占机制,抢占成功则执行,否则放弃。这种选举策略让宿主机得到了更多的参与,降低了对调度器的依赖。这种主动选择的方式,避免被动选择因不具备执行条件被选中,在执行的能力在时间上的损耗。
 
    2.3 任务故障转移
 
    调度任务的从任务级别job到transformer、operator,整个链条都存在具体局部失败的情况,调度器需要在原目标宿主机重试和失败后转移到其他备宿主机的功能,最大力度的保证任务被成功执行。
 
    2.4 执行算子抽象
 
    以往单机任务的调度可以比较灵活的执行多样的任务,可以是脚本、Webservice调用、HDFS Client命令行等,但是对于分布式协作需要接收外部命令运行,这就需要算子通过标准的数据通讯协议对外提供调用服务,常规的WebService、RPC(thrift/protocol buffer)等协议在跨语言通讯上具有较为广泛的应用。所以具体执行单元可以是具体任务的抽象,例如提供了Rest API方式,调用的URL和参数都是执行方填入,最大程度上支撑了灵活性;数据库操作算子可以包含数据库验证信息、具体执行的SQL等。执行算子抽象后,满足规范和灵活性,灵活是一个双刃剑,可以最大限度的满足用户需求,但也会导致大数据层面无法很细粒度的去感知数据的表、字段数据的完成情况,对数据生产无法更加精细粒度的产出交付。
 
    2.5 弹性扩展
 
    任务具体执行的宿主机需要在调度层面满足弹性的扩展,扩展最主要的需要是满足高可用和任务随着水平扩展进行分摊压力。在集群目标宿主机选择时,一般目标集合可以指定具体IP-List,也可以是一个BNS(百度机器的NameServer服务)。IP-List方式设置比较简单直观,但是存在每次调整依赖变更调度系统服务,变更之后还需要进行刷新宿主机的情况。而通过BNS服务比较简单,同时和线上服务发布部署进行结合,不存在延迟部署和刷新,推荐通过BNS的方式介入。
 
    2.6 触发机制
 
    常规触发是按照执行间隔或者具体时间的Crontab语法,开始时间,截止时间参数完成,但是在分布式调度任务中,最重要的就是完成协作,所以如果要进阶的话,就是依赖触发的机制。这种就很好的形成了上下游依赖触发,是分布式协作的关键步骤。从最初的任务节点按照常规触发,下游节点形成依赖链条,这里如果在高级进阶的话,就是依赖的某个/某些频次触发,比如每小时的12分钟开始被执行,下游可以选择具体的2:12 ,4:12进行触发,而非每个整点12分都被调用。这三种方式目前在外卖的大数据平台都有不同场景诉求,架构设计在3个需求上都有灵活的交付。
 
    2.7 堵塞机制
 
    对于相同任务的不同时间的运行实例,会存在前面的实例还没有正常结束的情况,这种在高频次调用,第三方依赖故障延迟等情况下会出现,如果继续调用会造成调用链条恶化,所以防止这种情况,堵塞机制会提供三种模式:常规例行(默认模式)、丢弃后续、丢弃前例。后面2种方案都需要提供容错重放机制,这个场景比较类似1.1章节提到的结算案例。
 
    2.8 图形化进展查看
 
    调度可以根据调用链条和不同事件频次的实例,通过树状图形化的方式查看执行的进度情况,例如可以查看job中transformer、算子的运行机器状况、状态和具体的实时执行日志。图形化是根据调用的触发机制分析出来的一个链条,是在烦冗复杂的调用关系中找到清晰脉络的数据直观表达的方式,是调度中常规的展示方式。在进阶中可以查看相应的参数传递,并发算子的执行进度条,预估完成周期等。
 
    2.9 报警
 
    通过邮件或者短信的方式对不符合预期返回标识的进行中止,同时通过邮件或者短信等方式对预先设置的用户或者用户组发出警告。报警触发的机制可以在宿主机单台时候触发,也可以在一定占比的宿主机在一定的时间窗口超过了阈值,触发报警。同时也要支持报警的屏蔽,用在进行运维或者升级部署、运维接管的情况。
 
    上面是很多常规调度拥有的一些特征,这些是在分布式场景下的延伸需求,从单点简单的逻辑到多节点的协作统筹在工程层面无疑增加了额外辅助,这些都是在业务演进中逐步完善起来,而高可用、高效率是在分布式环境下做出的改变。
 
    三、大数据分布式调度
 
    大数据分布式调度,在上面通用调度的基础上又进行了具体跟数据特征相匹配的改良。主要是从数据的流程层面进行梳理,用来解释数据的上下游、血缘关系的问题,具体又有哪些特征是针对大数据的呢?
 
    3.1 数据扇入扇出
 
    大数据的存储和检索方案很多,因大数据特征之一就是多样性,为了满足多样的业务场景会有不同的引擎或者存储选择,在多样化解决方案的同时,造成了数据之间进行交换变得复杂,引擎之间的数据存取规则都有个性化的支持,比如Hbase的数据到Mysql和ElasticSearch(以下简称ES),涉及到Hbase的读取和后续后面两者的数据存入,这种对于Hbase就是一对二的数据扇出,但是在数据在Hbase中通过Get或者Scan方式获取后,要插入数据需要了解后面2者的存储结构,甚至是索引结构。所以类似这种跨引擎(或者跨版本,不同API)的方式,为了保持通用,需要进行需求的抽象,在外卖平台针对数据的交换定义了一套开放式SQL,这个框架对数据引擎的存和取分别作了抽象,在不同的目标引擎中有具体的实现,所以就有一些约定的规范。 
 
开放式SQL扇入扇出流程图
 
    图2 开放式SQL扇入扇出流程图
 
    主键:数据必须存在业务主键或者联合主键,目的是为了保证数据在聚合或者更新的时候有依据。主键在Nosql的引擎中作为RowKey,在关系数据库中作为主键,在ES中作为主键key。对于Kudu来讲也是主键,针对数据的upsert就可以有依据的进行更新或者插入。
 
    数据列:数据列的变更会稍微复杂,如果在关系数据库中会涉及到增加、变更列,但是在Hbase、ES中基本不需要主动扩展列,只需要对数据变更就可以了。
 
    分区字段:对于事实表数据,在大数据量的情况下,为了检索效率和数据存放最优,一般会提供分区和桶的策略,针对Hive、Impala、GreenPlum的引擎会额外增加分区字段,分区可以是一级到多级,一般业务场景下第一分区为日期,根据实际业务需求可以变更更细粒度或者其他业务字段。在一般Mysql、Postgresql、Hbase这种引擎中不需要单独增加分区字段。
 
    数据更新范围:大数据的数据交换,一般为了提高效率会进行多批次的并发处理,这就需要在一批次的数据进行分割,一般情况下会按照单一字段的进行截取,字段的类型以时间戳(create_time、update_time)居多,也可以根据主键的key排序后分批次获取,在源数据引擎允许的情况下,按照多批次的并发query可以做到很好的数据获取,把串行的操作截断成多段的并发;这种在同一个任务多时间批次的情况下也很重要,每个批次会界定本批次设计数据更新的范围。数据更新范围使用前一般会获取本次更新的数据量,可以根据原目标引擎单个批次的最优性能计算出offset。
 
    多步骤过程:多步骤顾名思义就是数据的准备不是一蹴而就的,例如在3个Mysql库、Postgresql、Oracle中获取员工信息,而员工编号是统一的,最终数据在DB2中汇聚在一起,最基础的步骤是三份数据汇入到Oracle中,这就涉及到前面通过key做数据的Merge,这里会涉及到数据的插入和更新,但是如果有key存在并且不同数据源目标数据列清楚的情况下,三份数据早到和晚到场景都没有太大区别。第二步骤则根据汇总完的数据分析出一个过滤场景下的聚合信息,这步骤的场景作为计算数据源,再次进行数据的扇出插入结果。第三步骤可以把第一步的临时结果进行删除。所以在多步骤的场景下数据是分步骤完成了汇聚、聚合和删除。

责任编辑:李欢
本文为授权转载文章,任何人未经原授权方同意,不得复制、转载、摘编等任何方式进行使用,e-works不承担由此而产生的任何法律责任! 如有异议请及时告之,以便进行及时处理。联系方式:editor@e-works.net.cn tel:027-87592219/20/21。
e-works
官方微信
掌上
信息化
编辑推荐
新闻推荐
博客推荐
视频推荐