今天在刷CSDN时偶然看到一个有关 Apache DolphinScheduler的征文活动,在初步了解了相关情况之后,我发现 Apache DolphinScheduler就是那个大数据任务调度平台EasyScheduler的前身,这引起了我很大的兴趣,深入调研一番以后,我认为Apache DolphinScheduler虽然目前知名度不高,但是其发展潜力却是不容忽视的,未来继续发展将为大数据的从业人员们解决不少痛点,因此决定参加这个征稿活动,向大家科普一下Apache DolphinScheduler的情况。
大数据-越来越大也越来越难管
业界对于大数据概念其实还没有一个统一的定义,到底什么规模的数据算是大数据似乎是一个不断变化的动态概念,我们看到比如IDC就直接把大数据的定义为现有技术难以处理的数据,这样的定义虽然看似回避了对于具体规模的表述却也相当聪明。从历史经验来看最新的技术往往就是因为数据处理需求不断升级而催生迭代出来的,比如在谷歌提出大数据三驾马车的论文时,当时像Oracle之类的主流数据库技术根本处理不了谷歌所要存存储的搜索数据,现在的数仓也很难挖掘出数据湖中的宝藏。
目前诸多行业都将数字化转型的任务提上了日程,系统上云也是如火如荼,在这样的大背景下未来大数据的量级肯定还会不断创出新高,比如在上周阿里云的峰会上,Caffe之父贾扬清就指出阿里存储的数据量级正在以年化80%左右的速度增长,不过这样的数据增长速度,却成为大数据工程师的甜蜜负担,传统数据库与数仓用到数据湖三套体系的兼容性很差,能让他们整体协同工作运转就非常不易了,想提高效率真是难比上青天。
从我所在金融行业的情况看,现在的数据分析流程已经太长了,以金融数据为例,分析数据在交易核心的OLTP数据库中跑批处理,再ODS抽取ETL分析到数仓,再进一步训练流式计算,最后再入湖,其时效最快也是T+1日,如果还回答不出更细节、隐含的问题,比如非线性问题,还要把数据复制到SAS中做机器学习,再做统计的指标体系,去做进一步挖掘。数据要在这里搬动三次,复制三份冗余,还要管理数据一致性,每天数据中心运维的大量工作在做数据搬家。可以说目前各种大数据任务还能够正常运行真是堪称奇迹,即使是运行异常了大部分情况下唯一的应对方案也就是重启,重启解决不了就延时重启,具体的异常原因已经很难去分析了。
Apache DolphinScheduler的杀手锏-简单易用
为了解决任务调度的问题,我们之前也尝试过几种其它的方案比如Quartz,但是Quartz虽然是Java的定时任务标准,但它针对的是定时任务而不是数据流,根据数据流处理去定制化流程的工作量很大。而且Quartz最大的问题是其ACID特性保证,完全是基于数据库实现的,不同节点之间是通过数据库表来感知状态的,如果某一个节点失效,那么Job执行的原子性是很难保证的,缺少分布式并行调度的功能。
当然后来的Airflow可能会比Quartz更好一点,但是Airflow的问题是可视化程度较低,流程及任务必须通过Python代码定义,如果一家机构拥有海量数据流程那么代码定义流程的方式维护起来简直是个噩梦,而且从我们实测的情况看,Airflow的可靠性一般,常出现卡死现象,当然这个也许是我们使用或者配置的问题,不是最终的结论。
对比之后,笔者觉得 Apache DolphinScheduler还是最舒服的,按照官网的说法Apache DolphinScheduler是一个分布式去中心化,易扩展的可视化DAG工作流任务调度系统。致力于解决数据处理流程中错综复杂的依赖关系,使调度系统在数据处理流程中开箱即用。
而笔者认为分布式与可视化DAG工作流,分别针对了Airflow和Quartz的痛点,而且从不少大牛的实测反馈看Apache DolphinScheduler的可靠性还是很强的。
正如我们前面所说一般目前的大型企业都需要把分析数据从OLTP 核心数据库中抽取到数据仓库中,有的还需要从数据仓库中再同步到数据湖里,个人觉得至少做这种不同类型数据库之间的传输工作,完全可以让Apache DolphinScheduler来进行一下试点,如果Apache DolphinScheduler真的可以全面铺开,那么这对于大数据工程师来说将是巨大福音,因为这是一个完全可视化的工具,只要把流程定义好,那么运行时的监控以及错误处理等关键环节也就自然生成了,这将极大为大数据同仁们减负!
本文正在参与 “拥开源 — Apache DolphinScheduler 有奖征稿活动