草庐IT

深入浅出聊Taier—大数据分布式可视化DAG任务调度系统

袋鼠云数栈 2023-09-17 原文

导读:

上周,袋鼠云数栈全新技术开源规划——DTMO(DTstack Meetup Online)的第一场直播圆满完成。袋鼠云数栈大数据开发专家、Taier项目主导人偷天为大家带来了《Taier入门介绍》的分享,我们将直播精华部分做了整理,带大家再次回顾内容,加深技术细节的了解。

你能看到???

▫ Taier发展历程

▫ Taier架构设计和功能详解

▫ Taier具体应用和未来规划

点击链接,查看直播视频回放

https://www.bilibili.com/video/BV13L4y1L71w?spm_id_from=333.1007.top_right_bar_window_history.content.click

欢迎加入开源框架技术交流群

(钉钉群:30537511)

开源项目技术交流

ChunJun

https://github.com/DTStack/chunjun

https://gitee.com/dtstack_dev_0/chunjun

Taier

https://github.com/DTStack/Taier

https://gitee.com/dtstack_dev_0/taier

MoleCule

https://github.com/DTStack/molecule

https://gitee.com/dtstack_dev_0/molecule

Taier发展历程

Taier是袋鼠云数栈大数据家族的开源项目之一 ,于2022年2月22日正式在github上开源,它是一个分布式可视化的DAG任务调度系统,旨在降低ETL开发成本、提高大数据平台稳定性,让大数据开发人员可以在Taier直接进行业务逻辑的开发,而不用关心任务错综复杂的依赖关系与底层的大数据平台的架构实现,将工作的重心更多地聚焦在业务之中。

2021年4月,数栈技术团队确定了以DAGScheduleX为主,复合多个项目工程的核心板块的开源计划;

2021年9月,技术团队完成了项目雏形;

2021年11月,我们重构了DAGScheduleX的工程代码,并将之正式命名为Taier;

2022年2月22日,经过不断的打磨和不懈的努力,Taier终于正式开源1.0版本。

开源并不意味着项目的结束,恰恰是项目的开始,未来Taier将持续自我迭代,积极吸取社区力量,不断优化,推出更优越的版本。

[图片上传失败...(image-f4839e-1650432937136)]

Taier的前世与雏形

Taier最早之前在数栈内的雏形是当时负责数栈“承上启下”的基础组件DAGScheduleX

它承上对接各个上层应用(离线开发、实时开发、算法开发、标签引擎、数据服务、数据质量、数据资产),启下兼容多集群多版本(Hadoop、CDH、TDH、HDP、MRS),实现任务实例的分布式调度运行。在作为数栈的基础组件服务过程中,DAGScheduleX累计为数百家企业提供了大数据任务调度能力,在前期为后续的更新整合积累了大量的实战经验。

DAGScheduleX可以做到很多,但还远远不够。数栈边运用边迭代,渐渐地看见围绕着它开发更多功能,一体化解决问题的可能性。这时,Taier雏形已经具备清晰的构想,作为一个任务调度系统,Taier初步设计具备以下这些模块。

v1.0的里程碑意义

回头看,Taier的开发之路是由4组具有里程碑意义的数据铺成的:

  • Taier开发团队累计解决了70+个大大小小的 issue ;

  • 总共311次代码commit ;

  • 90w+代码修改行数

  • 初始的9位Contributor。

道阻且长,我们却已经走了这么远。

架构设计和功能详解

在架构设计与功能特点上,Taier整体架构是使用插件式的开发模式,在任务开发下面有调度模块和各项组件,也包括数栈开源家族的Chunjun等等。

Taier功能特点

Taier的功能特点有下面几个比较重要的方面:

1.任务类型:Spark SQL、数据同步(流计算任务);

2.控制台:包括队列管理、资源管理、多集群管理等;

3.运维中心:比如任务管理、周期调度、补数据等;

4.插件化开发:具体包括 taier-plugin、、DatasourceX、Chunjun等几个插件。

Taier功能特征

随着不断更新完善,现在的Taier已经具有以下的几种特性:

稳定性

  • 单点故障:去中心化的分布式模式

  • 高可用方式:Zookeeper

  • 过载处理∶分布式节点+两级存储策略+队列机制。每个节点都可以处理任务调度与提交;任务多时会优先缓存在内存队列,超出可配置的队列最大数量值后会全部落数据库;任务处理以队列方式消费,队列异步从数据库获取可执行实例

  • 实战检验:得到数百家企业客户生产环境实战检验

    易用性

  • 支持大数据作业Spark、Flink的调度;

  • 支持众多的任务类型,目前支持Spark SQL、Chunjun

  • 可视化工作流配置︰支持封装工作流、支持单任务运行,不必封装工作流、支持拖拽模式绘制;

  • DAG监控界面:运维中心、支持集群资源查看,了解当前集群资源的剩余情况、支持对调度队列中的任务批量停止、任务状态、任务类型、重试次数、任务运行机器、可视化变量等关键信息一目了然;

  • 调度时间配置:可视化配置;

  • 多集群连接:支持一套调度系统连接多套Hadoop集群。

多版本引擎

  • 支持Spark 、Flink等引擎的多个版本共存,例如可同时支持Flink1.10、Flink1.12(后续开源)

  • Kerberos支持Spark、Flink

  • 丰富,支持3种时间基准,且可以灵活设置输出格式。

    扩展性

  • 设计之处就考虑分布式模式,目前支持整体Taier 水平扩容方式;调度能力也随集群线性增长。

Taier****重要概念

下面从原理和操作层面给大家进一步介绍Taier,还有一些具体概念的解释。

任务与实例

方便起见,数栈在Taier中提出“任务”和“实例”两个概念,例如数据开发的数据同步这项工作称之为“任务”,而已经提交并且配置了周期属性的任就称之为“实例”。

实例具体操作

在Taier中,实例有这几种构建的方式:

1.基于Zookeeper选举Master节点参与Job 实例构建,T+1构建JobGraph

2. JobGraph构建前check &clean DirtyData

3.依据Task、TaskTask的数据(JobGraph)生成Job .JobJob实例数据

4.Master节点控制实例数据的负载均衡持久化入数据库

构建完毕后,实例处理的几种方式如下图所示:

其中:

1.三种任务类型:周期任务、补数据任务、重跑任务,统一调度方式

2. Job 优先入队列(1),队列容量不足入DB (2)

3.当队列容量空余时,异步线程从DB加载数据入队列(3)

4. Job出队列后进行任务提交

处理完成后,实例提交我们也做了思考,具体设计:

1.内存优先级队列,控制Job有序执行

2.多线程并发提交(可配置)

3. Job 执行超时判断(可配置)

4. Job资源不足/失败重试进入延迟队列(可配置)﹔避免长时间占用提交权

Taier 的实例状态大家主要应该关注标志停止的几个,具体有下面几种:

  1. WaitEngine:内存队列中的Job、内存容量不足存储在DB中的Job(默认500 )

  2. Lacking:资源不足暂时等待的Job(默认2min)

3. Restarting:失败重试的Job(默认2min )

4. Finshed、Failed、Canceled、Killed:结束状态

Taier的整个控制台设计分为公共组件、调度组件、存储组件和计划组件。通过一个租户ID,拿到这个集群下common, YARN-conf等的四个配置信息,组成包含一个任务插件所有信息的pluginlnfo。将它解析之后,一些资源初始化上传,以便我们缓存对应的客户端。

Taier Client Plugin这里,要快速开发一个插件要注意以下几点:

  • 一种任务类型对应一个插件,即一个jar包

  • 自定义类加载器(Classloader) 破坏双亲委派优先加载( Child-First)插件

  • 插件实现IClient接口方法

  • SPI: 在classpath 下的META-INF/services/目录下,创建以接口IClient 全限定名命名的文件,内容是上一步中实现类的全限定名

11.png

具体应用

Taier 部署环境依赖

  • 大数据组件:Flink、Spark (ThriftServer)、Hive

  • 三方框架:Datasourcex (4.3.0)、Chunjun(1.10.5)

  • 基础组件: JDK版本:JDK 1.8 + 、MySQL版本:MySQL 5.7.33+、Zookeeper版本:Zookeeper 3.5.7

  • Hadoop 2.7.3 :HDFS、Yarn

环境依赖配置完毕之后,Taier编译&启动按下面流程操作:

  • 后端: /build/mvn-build.sh,检查lib、pluginLibs目录

DB初始化,sql/create.sql、sql/insert.sql、Datasourcex、Chunjun插件、配置conf/application.properties

  • 前端:安装Node、yarn、mini-cup 和pm2、yarn build、检查dist目录、cup.config.js

编译启动之后,Taier应用的具体操作的步骤如下:

  • 登录、新建租户

  • 依次配置集群组件、公共组件、调度组件,上传hadoop zip配置·存储组件,同上

  • 计算组件:Spark相关(Spark SQL)、Hive相关(Hive sQL)、Flink相关(数据同步)

  • 租户绑定:资源使用情况

  • 任务开发&运行操作界面如下图:

未来规划

目前袋鼠云开源家族已经汇齐TaierChunjun双剑,未来我们计划集成Chunjun,丰富数据同步支持的数据源、实时采集、FlinkSQL;同时加入Docker 部署,使用docker使Taier能进一步简化,轻量化部署依赖;集成OceanBase v1.2版本中,预计对OceanBase插件高优集成;

未来,Taier会持续在实战中自我迭代,也会积极汲取社区的力量,我们的开发计划已经在路上,每月也会有固定一到两场的线上直播分享,线下meetup也在积极计划中。大家保持关注,数栈希望与大家一起进步。

有关深入浅出聊Taier—大数据分布式可视化DAG任务调度系统的更多相关文章

  1. ruby - Ruby 中的波形可视化 - 2

    我即将开始一个将录制和编辑音频文件的项目,我正在寻找一个好的库(最好是Ruby,但会考虑Java或.NET以外的任何库)以进行实时可视化波形。有人知道我应该从哪里开始搜索吗? 最佳答案 要流入浏览器的数据量很大。Flash或Flex图表可能是唯一能提高内存效率的解决方案。Javascript图表往往会因大型数据集而崩溃。 关于ruby-Ruby中的波形可视化,我们在StackOverflow上找到一个类似的问题: https://stackoverflow.c

  2. ruby - 分布式事务和队列,ruby,erlang,scala - 2

    我有一个涉及多台机器、消息队列和事务的问题。因此,例如用户点击网页,点击将消息发送到另一台机器,该机器将付款添加到用户的帐户。每秒可能有数千次点击。事务的所有方面都应该是容错的。我以前从未遇到过这样的事情,但一些阅读表明这是一个众所周知的问题。所以我的问题。我假设安全的方法是使用两阶段提交,但协议(protocol)是阻塞的,所以我不会获得所需的性能,我是否正确?我通常写Ruby,但似乎Redis之类的数据库和Rescue、RabbitMQ等消息队列系统对我的帮助不大——即使我实现某种两阶段提交,如果Redis崩溃,数据也会丢失,因为它本质上只是内存。所有这些让我开始关注erlang和

  3. ruby-on-rails - 在 ruby​​ 进程之间处理大数据对象 - 2

    如果使用Marshal.dump写入文件,我有一个Ruby散列达到大约10兆字节。gzip压缩后约为500KB。在ruby​​中迭代和改变这个散列是非常快的(几分之一毫秒)。即使复制它也非常快。问题是我需要在RubyonRails进程之间共享此散列中的数据。为了使用Rails缓存(file_store或memcached)执行此操作,我需要先Marshal.dump文件,但这会在序列化文件时产生1000毫秒的延迟,在序列化文件时产生400毫秒的延迟。理想情况下,我希望能够在100毫秒内从每个进程保存和加载此哈希。一个想法是生成一个新的Ruby进程来保存这个散列,该散列为其他进程提供AP

  4. ruby - 停止分布式 Ruby 服务 - 2

    我有一个启动DRb服务的脚本,然后生成处理程序对象并通过DRb.thread.join等待。我希望脚本一直运行直到被明确杀死,所以我添加了trap"INT"doDRb.stop_serviceend在Ruby1.8下成功停止DRb服务并退出,但在1.9下似乎死锁(在OSX10.6.7上)。对该进程进行采样显示在semaphore_wait_signal_trap中有几个线程在旋转。我假设我在调用stop_service时做错了什么,但我不确定是什么。谁能给我任何关于如何正确处理它的指示? 最佳答案 好的,我想我已经找到了解决方案。如

  5. Unity数据可视化图表插件XCharts3.0发布 - 2

    Unity数据可视化图表插件XCharts3.0发布历时8个多月,业余时间,断断续续,XCharts3.0总算发布了。如果要打个满意度,我给3.0版本来个80分。对于代码框架结构设计的调整改动,基本符合预期,甚是满意。相比之前的1.0和2.0版本,我认为3.0才是一个拿得出手给广大开发者使用的版本。1.0发布的时候,很兴奋,从0.1到1.0,也磨了一年,真的等不及想给大家试用了,还特地写过一篇文章以示庆祝。那个时候,1.0虽然还还不够完善,功能也不够丰富,但它是XCharts的开始,没有1.0,也就没有后面的2.0和3.0。后面的2.0发布,做了很多改进和优化,随着版本迭代,慢慢的发现有不少硬

  6. 企业大数据发展面临问题之存算分离技术思考 - 2

    文章目录概述背景为何要存算分离优势**应用场景**存算分离产品技术流派华为JuiceFSHashDataXSKY概述背景Hadoop一出生就是奔存算一体设计,当时设计思想就是存储不动而计算(code也即是代码程序)动,负责调度Yarn会把计算任务尽量发到要处理数据所在的实例上,这也是与传统集中式存储最大的不同。为何当时Hadoop设计存算一体的耦合?要知道2006年服务器带宽只有100Mb/s~1Gb/s,但是HDD也即是磁盘吞吐量有50MB/s,这样带宽远远不够传输数据,网络瓶颈尤为明显,无奈之举只好把计算任务发到数据所在的位置。众观历史常言道天下分久必合合久必分,随着云计算技术的发展,数据

  7. 大数据之Hadoop数据仓库Hive - 2

    目录:一、简介二、HQL的执行流程三、索引四、索引案例五、Hive常用DDL操作六、Hive常用DML操作七、查询结果插入到表八、更新和删除操作九、查询结果写出到文件系统十、HiveCLI和Beeline命令行的基本使用十一、Hive配置一、简介Hive是一个构建在Hadoop之上的数据仓库,它可以将结构化的数据文件映射成表,并提供类SQL查询功能,用于查询的SQL语句会被转化为MapReduce作业,然后提交到Hadoop上运行。特点:简单、容易上手(提供了类似sql的查询语言hql),使得精通sql但是不了解Java编程的人也能很好地进行大数据分析;灵活性高,可以自定义用户函数(UDF)和

  8. micropython复现经典单片机项目(二)可视化音频 频谱解析(基本搞定) - 2

    本人是音乐爱好者,从小就特别喜欢那个随着音乐跳动的方框效果,就是这个:arduino上一大把对,我忍你很久了,我就想用mpy做,全网没有,行我自己研究。果然兴趣是最好的老师,我之前有篇博客专门讲音频,有兴趣的可以回顾一下。提到可视化频谱,必然绕不开fft,大学学过这玩意,当时一心玩,老师讲的一个字都么听进去,网上教程简略扫了一下,大该就是把时域转频域的工具,我大mpy居然没有fft函数,奶奶的,先放着。音频信息如何收集?第一种傻瓜式的ADC,模拟转数字,原始粗暴,第二种,I2S库,我之前博客有讲过,数据是PCM编码。然后又去学PCM编码,一学豁然开朗,舒服,以代码为例:audio_in=I2S

  9. ruby-on-rails - Ruby On Rails 4.2 的可视化日志查看器 - 2

    我以前在Laravel4上工作过,它有一个很棒的日志查看器工具laravellogviewer查看demo我正在寻找与Rubyonrails4.2非常相似的东西,如果你们知道Rails4.2的任何好的可视化日志记录GEM,请告诉我..从代码我需要记录不同的日志级别,这个工具应该直观地组织我的日志,谢谢.. 最佳答案 这应该可以帮助您入门https://github.com/shadabahmed/logstasher如其所说Thisgemisheavilyinspiredfromlograge,butit'sfocusedonone

  10. ChatGPT教程之深入了解魔术背后的技术 - 2

    解开谜团:深入探索ChatGPT的技术奇迹。ChatGpt无处不在,无论是在播客、博客、YouTube还是社交媒体上。当我注意到这项新技术如此受欢迎时,我决定试一试,我被震惊了!有很多关于ChatGpt及其魔力的博客,但在这篇博客中,我将深入探讨其内部技术及其工作原理!ChatGpt简介根据OpenAI,ChatGpt被描述为:“我们训练了一个名为ChatGpt的模型,它以对话方式进行交互。对话格式使ChatGpt可以回答后续问题、承认错误、挑战不正确的前提并拒绝不适当的请求。ChatGPT是InstructGPT的兄弟模型,它经过训练可以按照提示中的说明进行操作并提供详细的响应。”OpenA

随机推荐