趙孔明 哔哩哔哩技術 2023-05-12 12:01 發表于上海
本期作者
趙孔明
哔哩哔哩資深開發工程師
一、背景
數倉建設離不開資料模型，資料分析師通過資料模型分析歸納各類資料，模型中離不開各種資料表，表代表不同次元資料，進而表/資料之間有上下遊依賴關系，資料的産出是由任務計算得出，分為周期性或實時産出，是以資料之間的依賴等價于計算任務的依賴。資料平台的排程系統作用為根據任務配置，包括排程時間與依賴的上遊任務，進行排程任務，即等待到達排程時間且上遊任務完成，才送出運作下遊任務。
排程系統的核心服務業務是資料開發，資料開發的開發模型為項目（Project），項目中可以建立多個任務（Job），項目由多個任務組成，計算分析一張表或多張表的任務DAG。基于項目模型，整體鍊路依賴模型為項目依賴，不支援跨項目的任務依賴，依賴模型不夠準确，影響資料産對外連結路準确性以及實效。
資料開發為周期排程的離線批處理任務，而資料産出還有流任務實時産出，或者非資料平台産出。離線批任務均在資料開發，由排程系統判斷依賴與送出執行，而實時任務或非資料平台的計算任務依賴需要打通，來避免任務空跑。
資料本身具有時間屬性，比如4點小時計算得出上一個小時3點資料，明天計算得出今天的資料，周月類似，可以看出資料産出分為小時、天、周、月。回到依賴上，3點的小時資料可以依賴上遊表3點資料，1号的天資料可以依賴1号0～23點小時資料做彙總，或者1号的天資料可以依賴1号23點小時資料取最新，這麼看來上下遊依賴不是簡單的一條邊，而是在邊上還有屬性，來準确靈活描述具體怎麼依賴上遊。
二、名詞解釋
為友善大家了解，對于涉及的名詞先進行解釋
名詞
英文
說明
任務
job
任務開發和執行的最小管理單元，一個任務包括可執行代碼（或jar包）、執行參數、血緣配置和排程依賴依賴
DAG
任務之間有資料依賴，進而形成的任務依賴，多個任務依賴組成運作的上下遊鍊路或DAG圖，表示資料的生産關系自依賴
--
後一個周期的資料依賴前一個周期的資料項目
project
排程開發的一種管理方式，為一組任務的畫布執行個體
instance
任務每次執行産生的一次執行記錄。包括該次執行的相關資訊業務時間
bizDate執行個體屬性，即資料時間，任務計算産出表的分區時間觸發時間
--
執行個體屬性，任務被定時執行的觸發時刻T-1
--
觸發時間與業務時間相差一個周期，以此類推T-2，即相差2個周期偏移
offsetT-1，其中的"-1"為偏移量，形容業務時間和觸發時間的偏差或依賴資料的偏差
三、依賴模型更新
1.項目依賴到任務依賴
由項目依賴過度到任務依賴難題：依賴為排程核心、依賴模型改造如何過渡、内外統籌，是以引入項目起始節點（root node）、結尾節點（end node），起始節點表示該項目的起點，實際使用者建立的任務均依賴起始節點，表示項目開始，結尾節點表示該項目的終點，實際使用者建立的任務均被結尾節點依賴，然後将項目間等價轉換為root 和 end 節點，即項目依賴模型改造為任務依賴模型，最終0風險将曆史項目依賴切換為任務依賴、依賴模型改為任務依賴。由項目依賴切換為任務依賴個别鍊路提效4小時。
2.打通外部依賴
目标：提供一種通用方案，各個系統均可接入，且不增加使用者開發效率。
方案1：表分區打通依賴，即當上遊表小時或天分區資料ready後，下遊調起執行
優點：
- 通過某種表分區ready約定，由排程系統适配，實作成本低
缺點：
- 當表有業務分區時，會擴大依賴範圍，即必須等待所有業務分區都寫入ok下遊才排程執行，這樣依賴放大不夠準确
- 表分區ready的标志為表分區建立事件或hdfs有succss檔案，前者和實時數倉查詢有沖突，後者需要下遊輪詢hdfs檔案，有性能瓶頸，且當有業務分區時，依然不能準确依賴，且考慮其他資料源不夠通用
- 沒有完整任務依賴DAG，和資料開發任務依賴不統一，有使用者解釋成本
方案2：虛任務打通外部依賴，即虛任務邏輯上表示某份資料，且有産出周期，比如一張小時表，虛任務執行個體表示某個時間的資料，比如3點小時資料，由下遊依賴虛任務等價依賴上遊實際任務
優點：
- 可細化到業務分區或任意粒度，準确依賴
- 依賴統一為任務依賴，無外部依賴性能瓶頸、場景局限性
- 通過虛任務可以建構出準确的任務DAG
缺點：
- 虛任務有維護成本，歸屬各外部服務
基于上述分析我們選擇虛任務打通外部依賴，細節如下圖所示，并複用排程串聯品質DQC服務，外部上遊任務産出資料品質也自動得到保障。
3.依賴偏移
業務時間偏移：任務實際産出的資料時間相對排程時間相差周期數，如今天産出昨天資料為T-1，今天産出前天資料為T-2
依賴偏移：用于描述下遊具體依賴上遊任務的哪個或哪些業務時間，是下遊任務的排程配置屬性，舉例如下：
| 依賴場景（以下時間均為業務/資料時間） | 下遊依賴偏移配置 |
| 2号天下遊依賴2号天上遊 | 集合，0 |
| 2号天下遊依賴1号天上遊 | 集合，-1 |
| 2号天下遊依賴2号小時上遊 | 區間，0-23 |
| 某周周下遊依賴當周天上遊 | 集合，0,1,2,3,4,5,6 或 區間，0-6 |
四、技術實作
B站目前有任務數8W，每天運作執行個體15W，任務依賴關系邊12W，依賴實作的關鍵目标：
- 實效性：高峰5W下遊，16W邊，依賴判斷時延要低、排程吞吐高
- 準确性：依賴無誤、定時排程和回刷/回補資料依賴獨立
1.抽象依賴模型
有項目、job依賴、表資料依賴（ods層資料系統預設有分區兜底檢測）共存，而且分為定時、手動回刷場景，通過抽象依賴模型，來靈活适配各種依賴并且可持續疊代，定義DependencySubject對象，該對象表示某種上遊依賴，唯一ID通過DependencySubjectId表示，DependencySubjectId由多個條件表示，比如 1月1号資料的上遊表示為“任務id=1234&&業務時間=20220101”、1月1号至5号資料的上遊表示為“任務id=1234&&業務時間>=20220101&&業務時間<=20220105”、某張上遊表分區表示為“表名=ods.tt_a&&day=20220101”，非常靈活可拓展。模型如下：
2.依賴異步回調
排程中核心元件：依賴中心DependencyCenter，主要功能計算依賴、依賴巡檢、依賴監聽回調。功能圖如下：任務定時觸發或手動回補到達依賴送出元件（該元件負責任務依賴判斷與送出），依賴送出元件詢問DependencyCenter上遊依賴是否OK，若依賴的上遊任務執行完成，則依賴送出元件送出到下一元件，反之任務執行個體停留在該元件。由DependencyCenter監聽上遊完成後，判斷依賴該上遊的下遊是否所有依賴都已完成，若都已完成則回調依賴送出元件送出任務，反之繼續監聽其他未完成上遊不進行回調。監聽功能由每種依賴檢測器完成，每種DependencySubject依賴對象對應一個依賴檢測器，依賴檢測方式支援巡檢、消息訂閱、接口調用。
3.依賴異步回調
依賴子產品性能，準确率100%，依賴時延（上遊任務狀态成功到通知下遊任務收到上遊成功時差）平均秒級别，90線平均1.6秒，最大6.3秒，穩定運作3年
五、未來規劃
1.依賴自動化
目前的資料依賴實際是通過任務進行串聯的，包括流、批之間的依賴，當使用者調整模型時，比如産出表調整，需要同步調整任務依賴，降低一定開發效率，如果沒有變更造成空跑、下遊延時嚴重問題。當我們任務資料血緣解析準确時，或者大部分準确時，可以大面積使用“自動依賴”，而任務依賴作為補充，解決“自動依賴”解決不了的很少部分場景。
2.依賴規則豐富
目前依賴規則支援偏移，且都是強依賴（上遊們必須都完成），某些場景下需要弱依賴，使用場景不多，但是很有用，具體分為：
- 等待到某個時間點，如果上遊失敗或還未執行完成，下遊不再等待開始執行，常見特征應用場景；
- 同一個上遊任務，隻要配置區間中 最新的一個 或 其中任意一個 任務執行個體，下遊開始執行，常見上遊表每小時全量更新；
3.依賴周邊支援
依賴規則的豐富，會給運維工具、基線帶來很大挑戰。
當進行鍊路修數時，運維工具需要從root節點+root節點的修數時間，根據依賴規則先計算第一層的修數時間，然後再根據第一層的修數時間與第二層的依賴規則計算第二層的修數時間，後續依次......，層數越多，計算複雜度越高，性能為瓶頸。
基線的出發點為保障任務，複雜的依賴規則對于基線應該是黑盒，但是又要考慮基線預測的準确性，是個待解決問題。
以上是今天的分享内容，如果你有什麼想法或疑問，歡迎大家在留言區與我們互動，如果喜歡本期内容的話，歡迎點個“在看”吧！