從開源使用者到Apache PPMC之路

近日, 觀遠數據聯合創始人&首席架構師吳寶琪, 做爲 Apache DolphinScheduler 的PPMC參加了 Apache DolphinScheduler 的首屆用戶大會, 並在大會上作了《從開源使用者到Apache PPMC之路》的分享, 如下是分享的主要內容。

---

Table of Contents
• 1. Part 1. 緣起
o 1.1. 階段1, Airflow自己是很是強大的, 咱們也作了大量的Operator擴展
o 1.2. 階段2, Apache NiFi 和 StreamSets Data Collector (簡稱 SDC)
o 1.3. 階段2.5, Kettle 和 Talend DI
o 1.4. 階段3, 開始調研各類開源調度項目, 並最終選定 DolphinScheduler
• 2. Part 2. 開工
o 2.1. 在項目中作的貢獻
o 2.2. 簡單談談爲何貢獻開源
o 2.3. 開源的收穫
• 3. Part 3. 將來
o 3.1. 打算探索的一些功能

---

1 Part 1. 緣起

觀遠數據是一家BI + AI的數據科技公司. 好比: 對於BI(Business Intelligence,商業智能)來講, 並不簡單的是酷炫的可視化, 而是會涉及到大量的外部系統對接和數據融合, 這裏都會牽扯到複雜的數據清洗和任務調度. 雖然咱們的BI中也內置了輕量的數據處理模塊, 可是, 對於更復雜的任務調度/補數據等需求, 以及AI產品中的一些數據清洗/特徵工程/調度等, 咱們也在尋找更適合的開源工具.

1.1 階段1, Airflow自己是很是強大的, 咱們也作了大量的Operator擴展

不過Airflow有個主要問題: "太依賴於Python編程, 須要作大量的Python擴展, 任務的依賴編排都要經過寫Python實現"
而咱們對於調度工具的主要定位是: 須要顧問同事也能實施. 對於不會編程序的顧問同事來講, 要求每一個人都寫Python太難了. 因此咱們得出的結論: 須要一個有不錯的可視化界面的web工具, 不能假設用戶都會編程序.

1.2 階段2, Apache NiFi 和 StreamSets Data Collector (簡稱 SDC)

主要結論:
• Nifi支持非結構化數據, 功能也比SDC多
• 可是: StreamSets SDC 更易用, 更好看! (更好看也是很重要的), 尤爲是以下三點:
o 實時Metrics支持 (實時看到pipeline的運行信息, 並且是可視化的圖形展現)
o 代碼寫的很贊!
o 插件化設計贊! 編寫自定義插件更容易!
雖然SDC很吸引人, 不過SDC主要場景仍是實時數據抽取轉化. BI還是離線定時任務爲主, 因此不是徹底匹配.

1.3 階段2.5, Kettle 和 Talend DI

主要結論:
• 這兩個都是傳統的ETL, 調度功能都偏弱 (注: Talend DI是評估的開源版本, 商業版本有更復雜的調度能力, 可是價格不菲)
• 插件擴展都有點複雜
• Talend 能夠把job翻譯成 Java工程, 贊! (這樣不用每臺機器都安裝 Talend, 能夠直接跑Jar包程序, 不過也有問題, 好比: 不少報錯都是java的exception, 不少自定義擴展都須要使用者會基本的Java)

可是這兩個項目的代碼都十分複雜, 閱讀/掌握代碼基本上太難, 而對因而否使用一個開源項目的一個很重要的考量指標是: 是否本身公司的同事能掌握這個項目.

1.4 階段3, 開始調研各類開源調度項目, 並最終選定 DolphinScheduler

主要結論: DolphinScheduler (加入Apache前叫 EasyScheduler) 更適合咱們的場景. 主要緣由:
• Apache License
• Process/Task的definition 和 instance 分離, 支持補數據, 概念清晰. 路走對了, 就不怕遠
• 有還不錯的圖形化配置界面, 而不是什麼都要寫json配置, 或者python設置DAG等.
• 基於JVM, 之後方便Java Shop來擴展

2 Part 2. 開工

做爲公司的首席架構師, 一部分的工做是思考和嘗試一些公司的將來方向, 因此, 開始對於DolphinScheduler的貢獻公司內部主要是我一我的奮鬥 (固然我不是一我的, 我是和開源社區的不少不少小夥伴們一塊兒奮鬥), 不過如今公司內部也有其餘夥伴在和我一塊兒爲開源作貢獻.

2.1 在項目中作的貢獻

主要的方式是: 從簡單到複雜, 逐步融入社區

最開始:
• 熟悉項目代碼, 搭建本地環境
• 修復一些小bug

接下來能夠作一些簡單的功能:
• 增長 Clickhouse 支持
• 增長 Oracle 支持
• 增長 SQL Server支持

接下來就能夠作一些更復雜些的功能了:
• SQL任務增長 Pre/Post Statement支持
• 支持Minio/S3 做爲」資源中心」的文件存儲
• 支持CombinedServer: 多個Server一塊兒啓動, 方便本地開發
• 用 Sifting Appender 解決 task 日誌錯亂問題

固然, 貢獻不是光指合併的pull request. 而還包括:
• Pull Request Review
• 社區回答問題
• 也包括: 來 User Meeting 分享, 宣傳DolphinScheduler等 :)

2.2 簡單談談爲何貢獻開源

爲開源作貢獻也是一個必然的選擇. 我以前在前公司就遇到過這麼一個項目: (具體的公司/項目名就隱藏了)

開始一切都很美好,
• 咱們基於某個開源軟件, 實現了一個功能
• 在上面作了大量的擴展,大量的修改

直到某一天, PM過來講:
• 這個軟件已經由 1.x 升級到了 2.0
• 這個 2.0 作了大量的代碼重構, 性能大幅提高
• 支持新的國際標準, 有不少新的script功能!
• 我們來升級支持一下吧

結果, 負責升級的同事升級了6個月. 他天天作的工做就是以下三件事:
• 編譯C++到各個平臺, 修復各類build error
• 仔細學習《Modern C++ Design》 這本書來了解各類特殊的C++ template寫法和模式
• 在版本控制軟件中, 查看和了解每一個commit的緣由/修改, 而後試着應用到新的版本上

後來, 咱們反思, 除了C++和跨平臺編譯等緣由外, 另外一個重要結論就是: 對於使用的開源軟件, 必定要千方百計把擴展/bugfix 合併到官方repository中, 這樣長期來看會大大減小維護成本.

2.3 開源的收穫

開源軟件發展到今天
• 已經再也不只是極客的我的項目爲主了
• 開源這十年發展太快了, 開源是將來的趨勢
• 開源和商業自己並不矛盾, 開源只是商業的一種形式
• 代碼只是開源的一小部分, 更重要的實際上是圍繞這個開源項目的社區
爲開源作貢獻, 不僅是能得到到apache郵箱, 也能同時:
• 提升代碼質量, 寫更多註釋 (內心想着, 我寫的代碼, 未來要被成千上萬人圍觀)
• 方案須要更通用
• 志同道合的朋友們
• 更多的使用者, 更快發現問題
• 對於公司來講, 也更利於公司吸引人才

3 Part 3. 將來

3.1 打算探索的一些功能
• 插件化
• 相似於Airflow的Pool功能, 限制同時執行的指定任務個數
• 工做流調度增長基於 時間觸發, 複雜規則, webhook觸發等機制
• Task Metrics支持, 實時查看每一個組件的一些metrics (好比: 輸入記錄數, 輸出記錄數, 執行時間. 以及近30次運行的變化曲線等)
• 工做流定義, 資源文件 等的 簡單多版本管理,(查看歷史, 回滾到指定版本)
• 數據血緣關係(data lineage)上報組件

我心中的DolphinScheduler (不負責任瞎想)將來架構, 固然, 這個只是一個設想, DolphinScheduler目前架構不是如此, 將來也不會徹底同樣, 只是我的的一種對於通用數據調度平臺的想法

以上是我對於參與DolphinScheduler開源項目的經歷的簡單分享, 由於主要面向技術人員, 因此沒有介紹太多比較虛的項目背景, 項目意義, 將來方向等內容. 提早劇透一下, 根據文章反饋, 將來適當時間也會介紹一些觀遠怎麼基於DolphinScheduler作的一些將來產品. Stay Tuned!