数据平台工具系统概述
谈到大数据平台，在当今大数据备受关注的时代，大家首先想到会是HDFS、YARN、Hbase、Spark、Hive之类著名开源组件，当然目前基于开源解决方案的大数据平台建设一般也是围绕着它们作为底层支持的，我司也是采用这种开源方案，那么是否我们将这些组件配置好参数搭建run起来，就可以称之为我们已经有了大数据平台了呢？这个回答当然是否定的。
目前从业界来看，如果是基于PasS层做数据平台建设的（本文也是基于PasS层平台建设做讨论），基本都需要在这些Hadoop生态基础组件之上研发衍生出工具系统层，那工具系统层的主要的作用是什么，我认为主要有以下几点：
1、基础服务封装，满足业务需求：如数据采集系统每天从业务系统抽取几千张表的数据存储到HDFS中，数据仓库团队后续基于存储在HDFS上的数据进行数据仓库的建设。
2、减少使用门槛和学习成本：Hadoop生态系统的周边组件的使用有技术使用门槛，一般操作接口都是Linux命令或需要编程对接的API程序接口。
3、安全性：Hadoop生态周边组件的安全性提供的一般相对比较薄弱，需要严格控制，需要在工具系统层面做统一收口，也就是说将业务同事的操作由工具系统代理提交给Hadoop生态，工具系统就可以控制操作的安全性，数据的安全性，当然我们讨论的基于PasS层做数据平台建设，如果基于SasS层做数据平台建设，一般可考虑使用Kerberos做安全性控制，但是细粒度的数据权限还是很难控制的。
回到本文正题，大数据平台工具系统之任务调度系统。从业界各大互联网公司以及我司的任务调度系统在数据平台的作用来看，像点样子的大数据平台，基本都有调度系统的存在。
调度系统的类别
从技术实现和功能层面结合来划分，市场上目前有两类的调度系统
1、基于时间维度的
基于时间维度的这类调度系统最根本的功能就是将任务在指定的时间计划下，正确及时的运行起来，比如我希望一个任务在每周三的下午14点运行起来，Linux的crontab、quartz、cron4j、当当网的elastic-job都属于这类，当当网的elastic-job在高可用、集群化、失败转移、分片化执行任务方面做的更加的完善，这里不做深入讨论。
2、基于DAG关系维度（也可结合时间维度）
这类调度系统主要的目标是基于DAG图，将任务在指定的逻辑关系下正确执行，也可以结合时间维度，我司的调度系统目前也是采用DAG关系维度方向。
举2个例子：
A任务执行完才可以执行A任务下的B任务。
A任务12点执行，A执行完下面的B任务才可以执行。
上面的例子比较简单，现实场景可能涉及到几百个任务相互关联依赖，以及任务执行之间的延迟策略，周期性执行策略都需要考虑。
目前这类开源调度系统比较出名的有Azkaban、oozie。
选择自研还是开源直接使用
针对自研还是使用开源版本直接使用，我们选择的是自研方向，主要有以下几点原因：
使用开源有学习成本：如果想用好开源产品，遇到问题及时解决，必须在功能和代码实现级别都非常熟悉，需要有一定的学习时间。
兼容性：我们数据平台的工具系统层的其它工具系统都是自研，如果中间有一个开源的，这样对后续的产品交互通信和功能层面都需要进行衔接，可能还需要二次开发。
功能不满足：开源产品的功能不一定满足自身的业务场景。
当然事情不是绝对的，需要根据自身的资源和实际情况做考虑。
我们自研调度系统实现了哪些功能
任务配置管理：支持添加任务基本信息，同一个界面支持配置关系维度、时间维度，以及关系维度和时间维度的混合配置方式。界面化操作配置，无需像oozie配置任务工作流需要编写XML文件后加载。
任务触发机制：支持时间维度、时间和关系维度结合触发任务执行机制，下图举出三种示例：
任务延迟执行策略：任务延时执行策略的使用一般发生时间和关系结合的场景，目前我们系统采用的延迟即刻恢复策略，那先来说说什么叫延迟即刻恢复策略，我们先来看一下如下图示两个场景：
我们先来分析一下场景1的情况，A任务1点半开始运行，B任务依赖A任务2点运行，假设A任务1点半开始运行后，运行了半个小时到2点还没有运行完，这个时候到了B任务2点启动的时间发现A任务没有运行完，程序这时就会将任务B标记为父任务延迟状态，那假设A任务在2点20的时候执行完成了，应用延迟即刻恢复策略，就会马上将B任务带起了运行。
我们再来看一下场景2的稍微复杂一点的情况，A任务每小时运行一次，B任务依赖A任务每天的2点运行一次，假设A任务1点开始执行，但是执行到2点还没有运行完，大家注意到了2点A任务的下一个执行周期也到了，并且B任务也需要在2点执行，那遇到这种情况，我们处理逻辑是这样做的，将A任务标记为自延迟状态并且在2点的时候不执行，将B任务标记为父任务延迟状态并且在2点的时候也不执行，如果A任务在2点20执行完成，则将B任务应用延迟即刻恢复策略马上执行起来。不知道大家有没有疑问就是A任务目前也是自延迟状态，它会应用延迟即刻恢复策略马上运行起来吗？答案是不能的，因为A任务如果马上运行起来，状态就是开始状态，B任务运行起来后看见A任务是开始状态则必然失败，所以此处需要增加一个逻辑就是自延迟状态的任务在恢复阶段，需要检查这个任务下面是否有父任务延迟状态的任务，如果有，优先将这个任务下处于父任务延迟状态的子任务恢复。
上面两个场景的描述都是针对延迟即刻恢复的策略说明，我们可能还需要考虑一种情况就是延迟忽略恢复策略，也就是针对上面的场景1和场景2，当B任务到达触发时间需要执行，但是发现依赖的父任务没有执行成功的，这时候就应用延迟忽略恢复策略，忽略B任务的本次执行。
任务基础信息和关系信息实时变更：任务基本信息以及上、下游依赖关系的变更都能立刻生效。
这里需要注意的是，实时生效再技术层面需要数据的强一致性保证，所以在业务功能方面要将影响任务信息状态变化的操作梳理出来。例如任务的增、删、改以及任务运行中的状态变化，手动触发等场景都可能涉及。所以针对这些操作要使用锁进行互斥处理，分布式环境下需要使用分布式锁。
任务手动触发执行策略：支持手动触发任务，目前有三种触发模式，触发当前任务、触发当前任务及下游子孙，触发当前任务的下游和子孙但是不包含当前任务。
特殊情况流程处理机制：人工标注失败或状态恢复重置功能，调度系统的任务类型有很多种，例如一个数据抽取任务依赖于业务数据库的稳定性，我们不能保证依赖环境都完全高效可用，遇到特殊情况可以将任务重置状态，重新进行全新的生命周期恢复执行至关重要，此功能都是在实践中吸取的经验：），大家懂的~。
任务手动停止资源释放：任务停止并不是简单的设置一下状态，如果任务是MR、Sqoop、Hive等类型，需要将对应在YARN上的任务停止释放。
报警通知机制：任务失败报警、超时报警、支持用户指定时间查看任务运行状态的订阅功能。
任务运行历史日志和实时日志可视化：日志是观察任务执行情况和排查问题的重要信息，需要提供给用户便捷的日志浏览功能，跟踪任务执行进度状态。
任务信息可视化展现：任务的状态信息、上下游关系方便查看。
调度系统 3.0预告
我们不断优化迭代调度系统的功能和技术架构，目前调度系统3.0已经开始研发，主要的改进涉及如下方面：
调度系统多租户方面：目前调度系统主要针对我们自身的数据仓库团队使用，其它的业务团队也有需求和意愿进行使用，我们将会用一个迭代针对业务数据的隔离，基础数据隔离，业务功能操作隔离，资源使用隔离方面进行研发演进，实现多租户的使用体系。
任务执行策略方面：上面再介绍现有功能的时候，介绍了任务延迟策略几种情况、后续我们会根据业务需求，针对这方面做更多的策略支持，并且实现界面化的可选择配置，这样业务同事根据业务场景可以自行选择。
技术架构不断优化：调度系统 3.0此次迭代会将后台公用组件模块化，无状态化，以实现高可用，负载均衡等。
总结
任务调度系统是大数据平台工具系统核心组件，本文也将我们自身实现的一些功能特性做了相关描述，后续我们会针对我们自身的大数据平台，从工具系统层、核心组件层，在功能和技术实现方面持续介绍。
