Apache DolphinScheduler，為Apache開源項目, 簡稱”DS”, 中文名 “小海豚調度”（海豚聰明、人性化，又左右腦可互相換班，終生不用睡覺）。希望 DolphinScheduler 就像它的名字一樣，成為一個“開箱即用”的靈活易用的調度系統。

DolphinScheduler已經一歲了,很榮幸與它一起成長, 2020年就剩幾天了,記錄一下,就當是對這一年多的成長做了一個梳理
(開啟碎碎念模式…).

一. 相遇

2019年10月公司決定開展中臺方面的業務,基于大數據體系,要搞一套從數據接入到數據輸出一站式的"全家桶". 在大數據體系,其實各項技術已經相對成熟了. 之前公司用的技術棧是HDP體系,所以一直使用Oozie作為調度系統. 在調研階段,出于各種原因吧,但是我覺得Oozie并不是很好用,比如在考慮到定制開發的時候,覺得前端開發成本有點高以及最重要的是覺得在DAG可視化方面并不是很好等等各種原因,所以就開始尋找其他的解決方案.
機緣巧合之下,我在gitee上找到了人氣爆棚的Easy Scheduler (DolphinScheduler的前身). 然后就被它的兩張圖所吸引.

一種心動的感覺,不慌不慌,穩住. 再看技術體系:

后端: SpringBoot (2.x)
前端: VUE
編譯: Maven(3.3+) ,
元數據存儲: Mysql5.5+
分布式無中心化設計: ZooKeeper(3.4.6+)

我去,都是主流技術棧,二次開發基本零門檻. 再看一下其他的特性,

• 以DAG圖的方式將Task按照任務的依賴關系關聯起來，可實時可視化監控任務的運行狀態
• 支持豐富的任務類型：Shell、MR、Spark、SQL(mysql、postgresql、hive、sparksql),Python,Sub_Process、Procedure等
• 支持工作流定時調度、依賴調度、手動調度、手動暫停/停止/恢復，同時支持失敗重試/告警、從指定節點恢復失敗、Kill任務等操作
• 支持工作流優先級、任務優先級及任務的故障轉移及任務超時告警/失敗
• 支持工作流全局參數及節點自定義參數設置
• 支持資源文件的在線上傳/下載，管理等，支持在線文件創建、編輯
• 支持任務日志在線查看及滾動、在線下載日志等
• 實現集群HA，通過Zookeeper實現Master集群和Worker集群去中心化
• 支持對Master/Worker cpu load，memory，cpu在線查看
• 支持工作流運行歷史樹形/甘特圖展示、支持任務狀態統計、流程狀態統計
• 支持補數
• 支持多租戶
• 支持國際化

O(∩_∩)O哈哈~ , 就這樣一見鐘情 …

---

二. 相識

接下來,就是考慮怎么跟領導推薦這個技術,當時也調研了一些其他的技術,比如NIFI, Azkaban,AirFlow等等.
首先排除掉的就是NIFI和AirFlow. 不是這兩個不好,是一些其他的原因.
NIFI是做的最完善的,但是太重了,出問題用源碼定位費勁. 維護/二開成本真要命.
AirFlow是Python寫的,因為公司的人基本都是JAVA體系,考慮到這點就直接放棄了.

剩下的無非就是做對比了,出一份報告,然后跟領導匯報.雖然我個人是推崇DS的,
但是DS比較特殊.畢竟是草根,也沒有一些大廠背書,所以領導這邊也在猶豫.
轉機:
2019年12月27日DolphinScheduler發布了第一個 apache版本,真正成為中國在apache中為數不多的開源項目之一
背靠大樹好乘涼,最終調度系統決定采用DolphinScheduler作為技術原型.

二. 相知

人生是由無數個第一次組成的,總有那么一些事情值得回憶~

2.1. 貢獻PR

2020年3月31日,第一次PR被merge . 雖然只是解決了一個小小的問題,對我來說確是一個從0到1的開始. 這是我走進開源的第一步.

更多的可能是一些心態上的轉變, 平時雖然讀過一些項目的源碼,但是從來沒有考慮貢獻過自己的PR,最多也就是寫寫博客記錄一下,便于以后查找. 當看到自己的PR被merge的時候. 瞬間成就感滿滿,還開心的發了一個朋友圈mark了一下.
技術人嘛,快樂就是這么簡單.

2.2. 文章入選公眾號

2020年過年因為疫情的原因,在家辦公. ( ps :所以這也是我自從畢業之后,陪爸媽最久的一次. 待久了真容易遭嫌棄. )
在家搞調度的設計文檔,需要工作流定義創建時有關于task任務數據結構的說明.當前的版本工作流里面的DAG圖是拼裝一個很大很大的Json字符串, 我需要對這里數據做一個梳理,可以給外部系統調用. 但是官方沒有,就自己梳理了一下,習慣性的寫了一篇文章,方便以后查找. 正好當時微信群里有一個哥們也需要,就共享了一下. 官方在征求我的同意之后,轉發到了官方[海豚調度]公眾號上. 開心是肯定的,不過想起來很久之前立下的要寫公眾要的flag,臉疼.
現在,更疼…

2.3. 基于源碼開發

設計完成了,肯定是要進入到開發階段的 ,當時有兩個版本可選一個是1.2.1版本,另一個是1.3.0版本, 不過1.3.0版本正在開發中,還不穩定.
但是1.3.0相對比1.2.1多了很多新特性. 比如: 重構了worker架構.資源文件支持目錄創建,新增了條件分支、Sqoop、DataX任務類型的節點.工作流定義支持移動/導入/導出等等多個特性, 所以就選了1.3.0版本進行開發.
因為1.3.0的worker進行了重構,所以又得重新過一遍源碼,重構之后worker節點確實簡潔了很多. 就是看master類型節點的時候有點費勁.
翻出來之前看master源碼畫的圖,看著依舊覺得代碼有點繞.慶幸,官方下一個階段要做的事情就是對master進行重構,歡迎加入哦.

貼一張之前分析master的圖代碼邏輯圖:

2.4. 貢獻文檔

大多數人應該都知道DS的github代碼庫的地址, 但是很少知道 DolphinScheduler文檔庫的地址.
隨著DolphinScheduler的用戶不斷的增多,文檔的缺失成為了DolphinScheduler的一個短板,所以代老板(DolphinScheduler PPMC) 在開發群里提出文檔的需求,大家有空的話,多貢獻點文檔, 為此還單獨發了一個issue,長期置頂了很久,有需要啥文檔的小伙伴可以過去留言.

因為之前寫過關于task的數據結構的文檔,就先報名寫了一篇任務總體存儲結構.

當然隨后又寫了幾篇.有一件事讓我印象深刻[ 為了一段文檔,我來回改了好幾次,我得吐槽一下代老板…].
事情是這樣滴.

有一陣用戶老問關于1.3.x版本worker分組創建和資源中心如何配置的問題. 所以我就想著把文檔完善一下.

先寫了worker分組如何配置文檔, 然后又寫的資源中心如何配置. 因為改的是同一個文件,所以合并到同一個pr里面了.

代老板反饋: 寫的不錯, 最好能拆開分兩個PR進行提交. 修改 + 1

正常在提交的代碼的時候,正常來說首先要先提一個issue,每個PR用于處理issue中的問題, 每個PR只能處理一個問題.如果有多個問題,需要拆分為多個PR **

代老板反饋: 資源中心配置的時候, 你關于kerbos的配置怎么給刪了 ? 現在用kerbos的人還是蠻多的,把這個加上吧. 修改 + 1

個人覺得用kerbos的人比較少,直接就把kerbos部分的配置就先刪了,只保留了幾條非kerbos配置…

代老板反饋: 你咋加了這么多參數 ? 這樣不夠直觀啊 . 修改 + 1

我把關于hdfs的大部分需要改的配置都列上了,嗯,這是嫌多了… ^_

代老板反饋: 中文合并了,剛翻譯的英文用戶手冊兄弟檢查一下,看看是不是也有這個問題 修改 + 1

同步修改英文的文檔, 蹭了一個PR O(∩_∩)O哈哈~

思考: 是不是有些事情可以做的更好,不只是追求95% , 而是99% ~

2.5. 配置checkstyle

每一個人寫代碼的時候都有自己的習慣,開源參與的人比較多,隨著時間的推移,但是如何代碼規范一直是一個問題,之前DolphinScheduler社區是采用sonarcloud做一些初步的驗證,比如代碼的UT覆蓋率必須到33%以上, 使用sonarcloud做code smell檢查. 然后必須有兩個review ( + 1) 之后,才會被merge到代碼庫.但是代碼的風格不好控制, 比如代碼的縮進,空格,換行的數量等等的代碼風格上的問題. 后來一個小伙伴貢獻了一個code style 檢查約束.
使用sonarcloud自動檢查,并根據配置的代碼風格給與提示.之前我一直用阿里的代碼檢查工具, 這個還真是第一次用,配置這個當時花了不少時間.

其實不管用什么工具,在代碼的質量上開始做要求并給與規范化的限定, 這不是一件好事么~

參考的配置 記錄一下,方便以后自己查找:

checkstyle 參考[https://checkstyle.sourceforge.io/]是一種幫助開發者編寫遵循編碼規范的 Java 代碼開發工具。它可以自動化檢查 Java 代碼的方法以及格式，使得開發者不用再做這項無聊（但很重要）的任務。它非常適合于希望實施編碼標準的項目。

在 DolphinScheduler 中配置 checkstyle 和 code-style 的方式：

.checkstyle 和 code-style 配置文件
checkstyle: https://github.com/apache/incubator-dolphinscheduler/blob/dev/style/checkstyle.xml
code-style: https://github.com/apache/incubator-dolphinscheduler/blob/dev/style/intellij-java-code-style.xml

2.6. 群管理

9月初,代老板在開發群里的說 DolphinScheduler已經有10來個群了, 想找一些人幫忙代為管理,正好我在用戶群里面,就主動報了名,感謝信任.我順利成為了二,五,七這三個用戶群里的管理員. DolphinScheduler的發展很快,前一陣又開通了DolphinScheduler的第八個用戶群. 當時新任的管理員問需要注意哪些事項,我就梳理了一些,發了出來.

1.管理一下群里的日常.給大家提供一個積極向上的環境.
2.新人審核,邀請時驗證信息需要填寫驗證信息“公司+職位+姓名” 或 “學校+姓名”。(有效過濾廣告神器)
3.回答問題,解決用戶遇到的問題,當初我就是在社區大佬的幫助下走過來的,投桃報李.
4.微信群的特權只有國內的用戶享有. apache組織對微信群是不提倡的,一般只是認可issue或者郵件. 微信記錄不利于知識的沉淀,考慮到社區的良性發展,需要引導發Issue, 積累久了,有問題可以做到搜索issue直接獲取答案.簡單高效.畢竟微信群里的答疑的人都是義務性質的,都有自己的工作要忙.回復的時效性沒有辦法保障. 而issue會有專人來處理,肯定不會遺漏…
5.群里發招聘信息的讓他配100元紅包，10分鐘內不發的也可以送飛

哈哈,第五條是代老板給加的,我專門拿小本本記下來的 …

三. 相守

自從參與了DolphinScheduler之后,覺得社區的技術氛圍會特別好,尤其是一個技術人,跟一堆牛人在一起,相互成長是一件蠻幸福的事情.
比如最近一陣官方有大動作,比如重構工作流定義數據結構, 重構master服務. 光線上的架構討論會就開了四次. 一群技術人在聊架構,聊設計,分享思路這個是平時很難遇到的. 在討論的過程中,真的是考驗知識儲備靈活運用的時刻.收獲良多.越發的認可一句話:
一個人可能會走的很快,但是一群人才能走的更遠.

PS: 推薦一項福利,對DolphinScheduler有過貢獻的人,可以進入到開發群,遇到問題可以優先幫忙解決.我當時搞定制開發的時候,就收到過很多大佬的幫助,重要的問題可以獲取到第一手資料,及時反饋到生產.

最后秀兩張Apache DolphinScheduler Group 8 群 @ SUN 同學畫的兩張工作流的圖,誰說程序員不懂浪漫~

---

歡迎加入APachec dolphinscheduler社區

https://github.com/apache/incubator-dolphinscheduler (請記得fork和star)
訂閱郵件列表
用自己的郵箱向dev-subscribe@dolphinscheduler.apache.org發送一封郵件，主題和內容任意。
接收確認郵件并回復。完成步驟1后，將收到一封來自dev-help@dolphinscheduler.apache.org的確認郵件（如未收到，請確認郵件是否被自動歸入垃圾郵件、推廣郵件、訂閱郵件等文件夾）。然后直接回復該郵件，或點擊郵件里的鏈接快捷回復即可，主題和內容任意。
接收歡迎郵件。完成以上步驟后，會收到一封主題為WELCOME to dev@dolphinscheduler.apache.org的歡迎郵件，至此已成功訂閱Apache DolphinScheduler（Incubating）的郵件列表。

總結

以上是生活随笔為你收集整理的我和DolphinScheduler的这一年的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。