引言 我叫李慶旺，是Cisco Webex的一名軟體工程師，同時也是Apache DolphinScheduler（以下簡稱DS）的Committer。 在過去的兩年裡，公司基於Apache DolphinScheduler進行了多項持續改進和創新，以更好地適應我們的業務需求。本文將介紹這些改進的具 ...
引言
我叫李慶旺，是Cisco Webex的一名軟體工程師，同時也是Apache DolphinScheduler（以下簡稱DS）的Committer。
在過去的兩年裡，公司基於Apache DolphinScheduler進行了多項持續改進和創新，以更好地適應我們的業務需求。本文將介紹這些改進的具體內容，以及我們對社區的貢獻。
主要包括以下五個部分：
- 我們的系統架構
- 在業務上遇到的挑戰以及解決方案
- 探討在安全性方面所做的優化和關鍵指標
- 我們對社區的貢獻
- 遇到的有趣技術問題。
公司及項目背景
首先，跟大家簡要介紹一下我們公司。Cisco Webex是一家專註於開發和銷售線上會議產品的軟體公司，這些產品包括Meeting、Calling、ContactCenter等。
我們團隊設計並搭建了一個大數據平臺，為上述產品的數據接入和處理提供支持。以Webex Meeting產品為例，Webex會議會生成各種指標。當會議進行時，客戶端和伺服器會向我們的Kafka集群發送指標和日誌。
外部和內部客戶依賴這些指標來優化會議體驗或生成相關報告。
我們的願景是打造一個能夠服務於內部和外部客戶的大數據平臺，通過消除數據孤島，實現所有基礎設施的整合，並且該平臺需要能夠適應公共雲和現有私有數據中心的架構。
由於思科網訊是一家全球協作服務提供商，我們的客戶跨越多個時區和大洲，因此我們在全球擁有許多數據中心。這些數據中心包括本地自我管理的數據中心 Webex DC，同時最近兩年，我們也支持了亞馬遜雲管理的集群。
調度選型
三年前，我們選擇了Apache DolphinScheduler作為我們的工作流數據處理引擎，原因是它的功能強大、設計優雅且易於擴展。我們最初使用的版本是2.0.3，之後升級到了3.1.1。
感興趣的朋友可以參考公眾號的文章
- 使用 Apache DolphinScheduler 構建和部署大數據平臺，將任務提交至 AWS 的實踐經驗:https://mp.weixin.qq.com/s/Md5C84kZLA_H4pdfzLmxbw
- 杭州思科對 Apache DolphinScheduler Alert 模塊的改造:https://mp.weixin.qq.com/s/cyGs1MHnlxhLBl0mumJBdg
- Apache DolphinScheduler2.0升級3.0版本方案:https://mp.weixin.qq.com/s/tZMEatdnQibX7ifxp67DTQ
技術架構
以上是兩年前的架構圖，基於社區版本，我們做了一些適應性的改動。
由於平臺部署在Kubernetes（K8s）上，我們開發了Flink on K8s，支持將Spark調度到K8s上，同時開發了一套通過拖拽形式生成ETL作業的ETL模塊。
我們在每個K8s集群中配置了Grafana，每個集群有一個系統任務Pod，用於獲取集群中Pod的狀態。此外，我們在系統中增加了集群和Namespace的管理功能。
業務挑戰與解決方案
在過去的兩年中，我們在業務上面臨了諸多挑戰，併為此提出了相應的解決方案。
多集群支持
首先是多集群支持。目前，我們已經支持了多個Webex DC數據中心，但由於業務需求，我們需要支持亞馬遜AWS下的EKS集群、公司基於EKS二次封裝的Kubed集群，以及支持美國政府業務的高安全性集群。
AWS EKS集群的支持
如何支持AWS EKS 集群？
我們使用單個DolphinScheduler服務來控制多個集群，當前支持多個Webex DC。為了支持任務在K8s集群上運行，我們依賴多個組件，包括Docker鏡像、JAR包和配置文件，這些資源都存儲在AWS S3存儲桶中，集群在運行任務時從這個S3存儲桶拉取資源。
對於涉及到資料庫密碼、Kafka topic等需要加密的信息，我們將其存儲在Cisco內部的Vault服務中，任務實際運行時將相關密碼映射到任務內部。
許可權控制
我們還開發了一個許可權管理系統，將IAM Account存到K8s Secert里，內容是AWS Key id和Access key。
如果想要支持AWS EKS，我們需要做一些改動。
AWS裡面提供了Docker Repo相關的服務，名字叫ECR，我們會將Docker images存入了ECR中。而支持多地的EKS集群，每個集群都有對應的S3 Bucket，需要支持資源讀寫入多個S3 kubet。
密鑰管理
對於密鑰管理，AWS也提供了對應的服務，叫ASM。我們將需要加密的信息存到了ASM裡面。
對於IAM Account，K8s的Secert裡面存的AWS Key ID和Access Key，會存在過期，需要重新Refresh，這裡面存在著不夠安全的問題。
於是我們切換到了Service Account，Service Account裡面保存的是AWS Role，會更加安全，同時也不存在過期的問題。
同時我們對於Clusterr管理也做了修改，支持了多重集群類型。
我們還開發了Auth系統，在上面保存了AWS的組件，比如不同的S3 bucket，ECR等，用戶如果想要申請許可權需要在auth上走申請流程。
說了這麼多，其實對於用戶來說操作很簡單，在定義任務的時候選取想要運行的集群、Namespace，就會根據當前的Project、Cluster、Namespace，和用戶ID展示出來用戶擁有許可權的Service account。
當用戶選取了Service account，就會列出這service account下麵綁定的AWS組件，比如ECR Bucket、AWS等。
然後在任務運行時，會把用戶選取的資源下載或者映射到Pod裡面。
安全性優化
在安全性方面，我們對社區版的審計日誌功能進行了優化。在實際場景中，許多用戶需要查看任務的修改記錄，尤其是那些具有較高安全要求的客戶（如美國政府）。
我們將審計日誌的開發分為兩部分：
社區在3.x版本已經有了審計日誌的框架。但是只有一個框架，對於實際的用戶操作並沒有做記錄。並且之前社區版的設計採用的發佈訂閱模式，對於代碼的侵入性非常大。
我們進行了重構，採取了AOP方法實現審計日誌，這樣只需要在需要記錄審計日誌的介面上添加註解，代碼侵入性很低。支持了Model層面的日誌，記錄誰做了改動。二期我們會記錄改動的詳細內容。
採用了策略模式的設計模式，這樣非常易於擴展，如果有新的模塊需要支持審計日誌，只需要新建一個實現類，裡面定義這個模塊特定的審計邏輯即可。
如圖就是審計日誌的頁面，用戶也可以按照模塊緯度去搜索日誌。比如用戶想看所有針對於Project的操作等。
數據質量模塊的開發
在沒有數據質量模塊之前，用戶在任務執行結束後需要人工去檢測生成的數據的質量，比如手動去執行一些檢測SQL來判斷數據質量。
引入數據質量模塊後，用戶只需配置一個數據質量任務，批處理任務結束後會自動調用該任務。
如果檢測失敗，會及時通知用戶進行干預。該模塊支持一些常見的規則配置，如查詢數據表的總行數、檢查是否存在重覆鍵值等，從而降低了使用成本並提高了易用性。
我們還在數據質量模塊中增加了對不同數據源（如Iceberg和Pinot）的支持。
同時在生產環境中，由於一些數據遷移等需要，用戶偶爾需要比對兩個資料庫同一個數據表，按照Day或者Org的維度聚合，總數應該是接近的，不一定完全一致但是總數誤差在5%之內，我們也需要支持這種規則。
我們的DolphinScheduler是all on k8s的，後續也會支持數據質量任務跑在k8s上面。
端到端測試（E2E）的改進
我們先來看一下社區的流程。當貢獻者代碼寫完以後，會往社區提交一個PR，會觸發CI/CD流程，首先會基於貢獻者提交的代碼打最新Docker鏡像，然後在鏡像上面會運行寫好的Case，來保證貢獻者寫的代碼不會影響到現有功能。
只有所有的Case通過後，經過Committer或者PMC Approve PR後，代碼才可以合進倉庫。這個流程是沒什麼問題的。同時社區也很多基礎功能的Case。
但是對於我們的實際生產環境有些不夠用。
剛纔介紹過，我們的服務on k8s，支持多k8s集群，包括Webex DC和AWS EKS集群，同時還支持多Bucket，不光多個S3 Bucket，同時針對於美國政府業務，我們還在Webex搭建了HDFS作為相關的存儲中心。
這些服務往往是需要一些特定的配置文件，而這些配置文件或者配置信息是無法在代碼中寫死的，甚至也不是完全存在資料庫中，比如AWS秘鑰的Service Account是存在K8s集群中。
社區的E2E流程較為基礎，無法覆蓋我們實際生產環境中的所有測試場景。
為此，我們將E2E拆分為兩部分：一部分使用社區的E2E測試增刪改查基礎功能，另一部分需要依賴一些配置信息的我們重新編寫了一些測試遠端服務的case。
可以看到E2E local就是社區相關的基礎的Case。
E2E Remote我簡單列出來了一些，比如我們Spark Flink ETL 任務需要支持不同的集群運行。
我們就編寫了相關的E2E Case來判斷是否可以實際運行到不同類型的集群，一些Spark Flink UI是否能打開等等。
像資源中心，也會測試往多個S3 Bucket和HDFS實際上傳下載刪除文件來測試系統的功能。這些測試用例覆蓋了多個K8s集群的實際運行、資源中心的文件操作等場景。
CI/CD經過改動後，開發人員想要提交代碼到Github倉庫，會首先經過E2E Local的監測，通過基礎功能的檢測後才能合併進倉庫，同時在發版的時候，會將發版的分支部署到預發環境，進行E2E Remote test，通過所有Case後才會正常的走發佈流程，同時發佈完成後會再次運行E2E Remote test再次確保線上功能符合預期。
新架構及其他優化
以下是我們添加了上述功能後的新架構圖。
在過去兩年，我們團隊還做了其他一些優化。
例如，我們使用ETCD替代了Zookeeper作為註冊中心，開發了許可權系統，簡化了集群申請和命名空間授權流程。
還擴展了K8s集群上支持的任務類型，如SQL任務、Python任務，並優化了監控系統。
此外，為了支持美國政府的高安全性業務需求，修複了相關的代碼漏洞，並將漏洞數量從81個減少到1個。
我們還繪製了平臺相關的Metrics，顯示有多少用戶，多少任務。可以看到比較活躍的Flink Spark等用戶。
同時還添加一些告警，比如某個Spark Job的運行時間過長，會及時通知運維人員及時介入處理。
對社區的貢獻
在對社區的貢獻方面，我們將絕大多數功能都回饋給了社區。例如，審計日誌、數據質量模塊、一系列告警優化、K8s部署相關的Bug修複、以及對LDAP和etcd SSL連接的支持等功能。
後續開發的新功能我們也會持續貢獻給社區。
技術問題分享
最後，我想與大家分享一個有趣的技術問題。我們之前的監控檢測到同一任務在同一時間被執行了兩次，可以看到這兩個任務實例的調度時間是相同的，並且ID相差1。
具體的排查過程也不是非常順利，先說結論，DS底層使用的調度框架時Quartz，Quartz使用了資料庫的鎖來控制併發。
我們使用的是TiDB資料庫。TiDB資料庫和Mysql資料庫，在預設的RR，可重覆讀的隔離級別下。創建事務時，創建Read-view 讀試圖的時機不一定，導致了TiDB資料庫會出現重覆調度的問題。
可以參考這篇文章：【故障排查】10 分鐘解決 Quartz 重覆調度的疑難雜症
Mysql是在事務執行第一個快照讀時創建read-view。而TiDB官方沒有找到相應的文檔說明，但是經過測試，應該在事務開始的時候就創建了Read-view。
解決方案是將TIDB的隔離級別切換為讀已提交（RC）。
結語
以上就是我今天的全部分享內容。在過去的兩年裡，我們在基於DolphinScheduler的系統中遇到了許多挑戰，並通過一系列的改進和創新，成功應對了這些挑戰。
未來，我們將繼續致力於優化和擴展Apache DolphinScheduler，並將新功能持續回饋給社區。
本文由 白鯨開源 提供發佈支持！
