温州女商人阿秋这次在 7月 Meetup 为大家带来的是基于DolphinScheduler的智能调度引擎在DDS的应用,这场演讲主要会跟大家介绍宇动源-DDS(自研的图形化数据开发工作室)、大数据架构、DDS产品和使用中遇到的问题,包括在迁移过程中的调研情况、遇到的困难、解决方案以及针对需求的优化,还有一些心得体会,希望你有所收获。
BDP是宇动源自研的大数据基础平台,类似的商业的应用主要有fusioninsget和EMR,都是在工业互联网领域比较领先的大数据平台,他们也都对现有开源大数据底层组件的封装和统一管理,使其更适用于工业领域的实时数据、时序数据、生产监控数据等,为DDS上层应用提供一个使用更方便、更容易使用的基础平台。
主要提供的功能:统一计算调度及管理、计算节点管理、存储节点管理、数据统一访问接口、统一权限控制、全局智能运维
有了BDP之后,我们不需要手动的安装/维护这些组件,包括我们DDS所有的组件也都是通过BDP进行安装和维护。
DDS实际上是对底层的调度引擎的优化,主要是使用的workflow code 和Stream code的两种开发方式,利用拖拉拽快速完成大数据开发。
除此之外还支持Notebook 交互式开发方式,当我们使用Shell SQL节点的时候可以在线编辑。
最终在执行过程,其实和我们平时使用DolphinScheduler一样,在运行后,也会生成一个调度任务,并且可以在调度管理中查看/管理。
问题:基于上一代调度引擎在性能、权限控制等方面存在缺陷,导致出现告警延迟、无法精准控制权限等问题。
问题:DDS与Hadoop架构紧密耦合,不仅前期需要额外部署Hadoop集群(即使客户不使用),后期Hadoop集群维护也增加了运维成本。
问题:无法对整个集群的运行状态进行统计,比如1000个任务,在运行过程中,我们不知道哪些任务是正常运行的,哪些任务挂掉了;
DDS中老调度引擎无法获取日志(日志的粒度依赖oozie 的日志)从而增加了调试维护成本,在开发过程中,命令行的方式也不是很友好,XML配置文件容易出错,开发效率低,无法更全面的统计与维护。
综上所诉的这些缺点和问题,导致了我们需要迭代一个新的版本,在DDS的后续版本准备对调度引擎进行替换,来解决这些使用当中的痛点。
接下来跟大家分享的就是在迁移过程当中,我们的一些调研工作、遇到的问题以及解决方案。
我们调研了oozie,azkaban,Airflow, 还有DolphinScherduler,当然还有一些其他的调度,这个表格里就没整理,在整个调研的阶段,我们特别重视的指标主要是资源的监控和分布式和日志,还有权限等方面的控制。
日志方面,通过DolphinsScheduler我们能准确的定位到每一个task任务执行的日志。也可以监控在执行过程当中启动时间,停止时间,然后运行的机器所在的运行阶段;
支持多租户。DolphinsScheduler的租户能和Hadoop的用户能实现映射关系,实现对资源的精确管理;
在迁移的过程当中,我们遇到了一个典型的问题:DolphinScheduler中的描述文件(json)无法与DDS的工作流描述文件(xml)兼容。就是DDS中的工作流是用xml的格式来绘制描述的。而DolphinScheduler中是使用json格式来描述的,这样就会导致于现有的前端生成的XML,无法兼容DolphinScheduler。
我们在DDS和DolphinScheduler中间,加入了DDS-adaptor服务,它有一个自己的API,DDS前端绘制完工作流,会将XML格式的请求体,通过API接口的形式发送到parser-engine,parser-engine收到了带有XML参数的请求后,会将它解析成JSON格式 ,当然这个JSON就是我们DS引擎能解析和兼容的。这样就解决了保留DDS前端框架不变的情况下,将原有的XML描述方式,适配到DolphinScheduler的json方式。
也就是说可能有个客户DDS使用了几年。上面配了几千个任务,用这个架构接入方案它就不需要重新的做任务的迁移,可以无缝的实现底层调度引擎的迁移。
5.其中parser方法实际上是XML格式的字符串,里面调用的是核心方法、核心类
但是每个Graph 中包含很多组件,因此每个组件都需要进行转换,需要调用到的方法是
第二步是中间对象转换成目标对象,我们想要的是Dolphin的Graph,这个时候实际上就是将中间组件转换成目标组件,这样就实现了中间的Graph转换成目标Graph,中间的Graph就是Adaptor-Garph,目标组件就是Dolphin-Graph,这样就实现了前端以XML的方式发送,引擎解析出来是Dolphin支持的json格式
在DDS调度启动之前,可以进行一个调度策略的设置,分别有一个分配策略和推荐节点;
在分配策略的时候,我们可以根据实际情况来选择,比如你是采集任务还是计算任务?是让它网络优先,还是IO优先,在这里你可以根据不同的情况自定义选择。
这里没有展示时间关系代码,主要依赖是基于DDS-monitor。在每一个子节点上部署 agent,那么agent它会采集系统的各种信息,比如说我们的系统版本,CPU,内存,磁盘等。
agent会将这些信息上报给server端,sever端将这些指标全部存在时序数据库里,数据库主要有两个用途,一个是我们监控数据,我们可以监控每一个agent上面的信息,另一个就是分析计算,指标分析计算后,根据我们的策略规则,会将符合功能策略的节点推荐返回给server,从而实现了节点的推荐机制。
我们指标分析计算里面涉及到的一些指标,有系统版本、CPU、内存、磁盘、进程、端口、网络io等等
我们对调度的是否重跑可以进行控制。比如说当任务运行到一半的时候,节点重启,所有的任务都失败了,有一些任务可以直接进行重跑覆盖,但是有一些任务重跑会影响它的结果,所以对这些重跑的限制也是针对需求来进行优化的点。
一方面,不管是基于DolphinScheduler引擎去开发自己的调度系统,还是直接使用DolphinScheduler进行二次开发,都是需要根据自己的开发环境来实际操作,比如说公司的环境要求、规范、前后端技术栈、开发环境等等,不要拿过来就开发,需要多方面的考虑。
另一方面,我们在devops过程当中需要收集和整理产生的这些缺陷、缺点和一些用户的痛点, 我们需要在这个版本的迭代当中,有针对性的去处理这些问题。
我们后续也有很多功能在实现当中,给大家列举一下,比如说后续的Task组件节点之间结果集的传递、SQL 运行后传递给后续节点等,然后还需要集成一些热门的时序数据库,比如说influxdb、open plant等。
随着国内开源的迅猛崛起,Apache DolphinScheduler 社区迎来蓬勃发展,为了做更好用、易用的调度,真诚欢迎热爱开源的伙伴加入到开源社区中来,为中国开源崛起献上一份自己的力量,让本土开源走向全球。
参与 DolphinScheduler 社区有非常多的参与贡献的方式,包括:
贡献第一个PR(文档、代码) 我们也希望是简单的,第一个PR用于熟悉提交的流程和社区协作以及感受社区的友好度。
来吧,DolphinScheduler开源社区需要您的参与,为中国开源崛起添砖加瓦吧,哪怕只是小小的一块瓦,汇聚起来的力量也是巨大的。
参与开源可以近距离与各路高手切磋,迅速提升自己的技能,如果您想参与贡献,我们有个贡献者种子孵化群,可以社区小助手(Leonard-ds) ,手把手教会您( 贡献者不分水平高低,有问必答,关键是有一颗愿意贡献的心 )。
添加小助手时请说明想参与贡献,来吧,开源社区非常期待您的参与。返回搜狐,查看更多
|