導讀：隨着 IT 時代步入到 DT 時代，從數據中挖掘價值已經變得越來越重要。數據倉庫系統長期以來一直是企業 IT 架構的重要組成部分，並且逐步與大數據等技術相融合，已然成爲建設數據文化的智慧型企業的必然措施。
本文主要針對數據倉庫建設中存在的 workflow 應用場景進行分析，結合數據倉庫自身的特性，對現有 workflow 方式進行優化，提出了一套適用於數據倉庫建設的 workflow 優化方案。
01
數據倉庫建設
1. 數據倉庫基本概念
數據倉庫的概念在 1991 年被美國著名的信息工程專家 William Inmon 博士首次提出，它是數據庫技術發展到一定階段的產物。數據倉庫是面向主題的、集成的、穩定的和隨時間變化的數據集合，是一個數據分析處理過程，而不僅僅是一個數據存儲軟件或產品。
OLAP ( On-line Analytical Processing，聯機分析處理 ) 是數據倉庫中最經常使用的數據處理和分析技術，最早由關係數據庫之父 E．F．Codd 於 1993 年提出。OLAP 委員會對聯機分析處理的定義爲：使分析人員、管理人員或執行人員能夠從多種角度對從原始數據中轉化出來的、能夠真正爲用戶所理解的、並真實反映企業特性的信息進行快速、一致、交互的存取，從而獲得對數據更深入瞭解的一類軟件技術。簡單來說，OLAP 就是幫助用戶更好的從多個角度去理解現有的數據。
多維模型 ( Multidimensional Model ) 是 OLAP 的數據存儲和組織範型，是 OLAP 操作的核心技術。OLAP 基於多維模型定義了一些常見的數據操作，包括下鑽 ( Drill-down )、 上卷 ( Roll-up )、切片 ( Slice )、切塊 ( Dice ) 以及旋轉 ( Pivot ) 使決策者、分析者對數據進行各種分析操作。
維度建模 ( Dimensional Modeling ) 是數據倉庫建設中的一種數據建模方法，將數據結構化的邏輯設計方法，它將客觀世界劃分爲度量和上下文，由 Kimball 最先提出這一概念。維度建模屬於一種關係建模方法，即將多維模型映射到關係模型，將關係模型中的表分爲維度表 ( dimension table ) 和事實表 ( fact table ) 兩種，其中維度表表示對分析主題所屬類型的描述，而事實表表示對分析主題的度量。
2. 數據倉庫建設主要工作
數據倉庫體系架構的核心組件有三個：原始數據層，數據倉庫，前端應用。如下圖所示：
整體來看，數據倉庫系統對業務數據和 server 日誌等原始數據進行匯聚，數據分析處理後，提供給前端應用系統進行使用，包括 BI ( Business Intelligence )、搜索、推薦等各類應用場景。
在數據倉庫系統內部，需要對數據進行分層，主要有如下好處：
防止煙囪式開發，減少重複開發，開發通用中間層數據，減少重複計算；
將複雜問題簡單化，將複雜任務的多個步驟分解到各個層次中，每一層只處理較少的步驟，使單個任務更容易理解；
可進行數據血緣追蹤，便於快速定位問題；
整個數據層次清晰，每個層次的數據都有職責定位，便於使用和理解。
數據倉庫主要分爲 STG、ODS、DWD、DWS、ADS 和 DIM 共 6 個層次，數據從底層開始，向上層進行傳遞、轉換、重組等操作，可以理解爲，根據數據分析業務的需要，對原有的 OLAP 多維數據，進行維度和指標的重新組合。層次的具體描述如下：
STG原始數據層：用來表示原始數據在數據倉庫的落地，數據結構和原始系統發送上來的保持一致。
ODS數據操作層：用於原始數據在數據平臺的落地。數據從數據結構、數據之間的邏輯關係上都與原始數據層基本保持一致。在源數據裝入這一層時，要進行諸如業務字段提取或去掉不用字段、髒數據處理等等。
DWD數據明細層：用於源系統數據在數據平臺中的永久存儲。它用以支撐 DWS 層和 ADS 層無法覆蓋的需求，比如像用戶購買詳單類業務需求。這一層主要解決一些數據質量問題和數據的完整度問題。
DWS數據服務層：數據彙總層，該層會在 DWD 層的數據基礎上。對數據做輕度的聚合操作，生成一系列的中間表，提升公共指標的複用性，減少重複加工。按照業務劃分，如流量、產品、用戶等，生成字段比較多的寬表，用於提供後續的業務查詢，OLAP 分析，數據分發等。
ADS應用數據層：該層存放數據產品個性化的統計指標數據，一般以某個業務應用爲出發點進行建設， ADS 層只關心自己需要的數據，不會全盤考慮企業整體的數據架構和應用。面向實際的業務數據需求，以 DWD 或者 DWS 層的數據爲基礎，組成各種統計報表。
DIM維度層：主要存儲公共的屬性數據，比如產品類別、地理位置、時間詳情等信息。綜上所述，數據倉庫建設的主要工作，就是對原始業務數據進行匯聚，進行分層次的數據處理，生成業務需要的數據，提供給前端業務使用。
02
Workflow 在數據倉庫建設中的應用場景
1. Workflow 概述
工作流概念起源於生產組織和辦公自動化領域，是針對日常工作中具有固定程序活動而提出的一個概念，目的是通過將工作分解成定義良好的任務或角色，按照一定的規則和過程來執行這些任務並對其進行監控，達到提高工作效率、更好的控制過程、增強對客戶的服務、有效管理業務流程等目的。
工作流技術的標準化組織工作流管理聯盟 ( Workflow Management Coalition，WfMC ) 於 1993 年成立，它的成立標誌着工作流技術在計算機應用研究領域之中被明確地劃分出了自己的一席之地。
WfMC 對工作流給出定義爲：工作流是指一類能夠完全自動執行的經營過程，根據一系列過程規則，將文檔、信息或任務在不同的執行者之間進行傳遞與執行。
簡單來說，工作流是通過計算機軟件進行定義、執行並監控的經營過程，而這種計 算機軟件就是工作流管理系統。
工作流模型是對工作流的抽象表示，也就是對經營過程的抽象表示，由於工作流需要在計算機環境下運行，因此建立相應的工作流模型就是必不可少的。由於工作流必須首先描述清楚一個經營過程是怎樣進行的，因此許多工作流模型都是從過程定義入手，比如流程圖、狀態圖、活動網絡圖等等，當然也有一些如形式化語言等手段進行工作流建模，本文在此不做闡述。
下面通過數據倉庫建設過程的主要工作流程圖，來描述下 Workflow 在數據倉庫建設中的應用場景。
2. 應用場景
下面的有向無環圖反應了數據倉庫建設中的主要工作，圖中的節點表示數據處理任務，帶箭頭的線表示了數據在任務之間的傳遞方向，圖例正好契合工作流的定義，可以根據任務依賴，自動執行任務，在任務之間傳遞數據。
數據倉庫建設中工作流的主要特點：
根據數據層次和數據分析維度，工作流節點通過數據流向依賴在一起；
對於規模稍大的數據倉庫，可涉及到多位數開發人員的工作協調；
可以根據數據處理或數據分析工作需要，隨時增加工作流節點。
3. 當前應用狀況
目前市面上，也存在一些用於數據倉庫建設場景的工作流管理系統，典型的代表 Azkaban、Oozie 和 Airflow。下面主要從 Workflow 構建和運行等角度對三個系統進行介紹。
綜合來看，目前應用於數據倉庫建設場景的工作流管理系統，主要存在以下幾個問 題：
都是以工作流爲單位進行編輯、管理和發佈部署，但是在實際的數據倉庫建設過程中，經常是多個數據開發工程師協同完成整個工作流的開發部署工作，每個人只負責部分工作流任務節點，不同開發者的任務相互依賴，現有的工作流管理系統不能很好滿足多人的開發協同工作。
針對一些複雜的任務依賴，比如兩個任務都是小時調度，小時調度之間存在某種對應關係，現有工作流管理系統都是按任務進行依賴配置，不能做到每個任務不同調度時間之間的依賴配置，或者要寫大量的輔助代碼實現，給用戶帶來極大的使用不便。
對於新增或修改 ( 如發現某個統計指標計算有錯 ) 的任務節點，經常需要針對這樣的任務節點及其子任務節點進行歷史數據修補，以工作流爲單位進行調度的系統，不太適合這種場景的處理。
03
Workflow 在數據倉庫建設中應用優化
計算機系統中軟件體系結構採用一種分層的結構，有句名言："計算機科學領域的 任何問題都可以通過增加一個間接的中間層來解決"。結合數據倉庫建設工作的特點，本文所優化的工作流管理系統，將數據倉庫建設工作流中的節點，抽象成任務和實例兩個層次：數據開發人員專注於單個任務的設計，配置任務的依賴和週期等調度屬性，構建任務的工作流；根據任務的依賴和週期屬性，工作流管理系統自動生成任務對應的實例，構建實例的工作流。這樣可以解決上節中提到的現有開源工作流管理系統的問題，提升開發協同、減少重複性工作。
1. 工作流層次
工作流管理系統將數據倉庫建設中的數據處理工作流分成任務和實例兩個層次，任務是對實例的抽象，實例是對任務的具化，任務是數據處理的本體，負責創建實例，而實例是具體的執行單元。這樣系統就包含兩個相互獨立又相互關聯的工作流，即任務工作流和實例工作流。
① 任務工作流
任務工作流層面，用戶根據數據分析的需要，手動增加或修改單個任務。任務除了包括數據處理內容 ( 如 Shell、HIVE SQL、Spark 等代碼 )，還要包括依賴和週期等任務屬性。通過依賴屬性，所有任務可以形成任務工作流 DAG，用戶只需定義本任務依賴的父任務 ( 也可依賴自身 )，工作流管理系統會進行相關校驗，保證 DAG 屬性 ( 如無環等 ) 不被破壞等；通過週期屬性，確定任務一天中被調度的次數和時間。
只需要配置依賴和週期屬性，便能滿足任務依賴自身上一次運行結果或一天中多個時間點要被調度等複雜配置場景，極大簡化了任務配置難度。
② 實例工作流
實例工作流層面，工作流管理系統根據任務工作流的任務屬性等信息，按照預定的生成規則 ( 規則具體說明參見後面章節 )，創建出任務對應的實例，形成實例工作流。
工作流管理系統根據實例工作流，按照 DAG 方式進行調度，當實例滿足如下兩個條件時，才能被調度執行：
該實例所有的父實例節點都已完成調度執行；
到達本實例的調度時間。
③ 兩者關聯
任務工作流是一個靜態的工作流，不會被系統調度；實例工作流是任務工作流在某 一時刻的鏡像，會被系統調度執行，完成數據處理工作。
工作流管理系統一般按天爲單位，在固定時間點生成所有任務一天的所有實例信息， 即依據任務工作流構建實例工作流；也可以按照其他時間間隔單位生成實例，比如以小時爲單位，在每個小時的某個時間點，生成所有任務在對應小時時間段的實例信息。
下面兩張圖爲具體的任務工作流和實例工作流，其中左圖爲任務工作流，右圖爲實例工作流。
圖中 parent 的任務節點，週期屬性爲天，每天 8 點被調度；依賴屬性爲自身依賴，即依賴上一天的執行結果。
圖中 child 的任務節點，週期屬性爲小時，從 0 點開始，每隔 4 小時調度一次；依賴屬性，parent 爲其依賴的父任務節點，即父任務 parent 執行完後，child 任務節點纔可以被調度執行。
2. 任務屬性
任務屬性，主要包括週期屬性和依賴屬性，工作流管理系統根據這兩個屬性，將任務工作流轉換成實例工作流。
① 週期屬性
週期屬性用於指定任務的調度週期及具體的調度時間。
調度週期，可以設置爲月、周、日、小時等 ( 一般不考慮分鐘級別，分鐘級別的數據處理任務可以使用 Storm、Flink 或 Spark Streaming 等實時數據處理系統 )。一般設置爲日級別週期，即每天都被調度一次；對於月、周級別，需要制定每個月或周的哪幾天進行調度，即不是每天都被調度；對於小時級別，需要設定一天當中哪幾個小時進行調度，即每天被調度多次。
調度時間，設置任務具體的執行時間。對於月、周、日級別任務，設置一個調度時間即可；對於小時級別任務，需要設置對應的多個調度時間。
② 依賴屬性
依賴屬性分爲任務間依賴和任務自身依賴：
任務間依賴，用於指定任務的父任務，即上游任務。例如 DWD 層的任務 A，需要用到 ODS 層的任務 B 和 C 產出的數據，在配置任務 A 的任務間依賴屬性時，就要設置依賴任務 B 和 C。針對天級別任務依賴小時級別任務的場景，還可以設置就近依賴屬性，則子任務調度執行依賴父任務中第一個不小於子任務調度執行時間的調度執行。
任務自身依賴，用於指定任務各週期之間的依賴，當前的調度執行，依賴上一次的調度執行結果。例如某個天級別任務，當天的調度執行就依賴昨天的調度執行結果；某個小時級別任務，每天 8 點和 16 點執行，當天 8 點的調度執行就依賴昨天 16 點的調度執行，當天 16 點的調度執行就依賴當天 8 點的調度執行。
3. 實例生成
工作流管理系統，在設定的時間，根據各個任務的週期和依賴屬性，結合預定義的生成規則，生成任務對應的實例，形成實例工作流，用於實際的數據處理任務執行。
① 生成規則
生成規則受到任務的週期和依賴屬性影響：
首先根據週期屬性生成實例，比如天級任務，根據調度時間每天生成一個實例；小時級任務，根據調度時間，每天生成一個或多個實例；月和周任務，根據調度時間，在對應日期生成一個實例。
然後就是根據依賴屬性，構建實例間的依賴關係，具體如下圖所示。
依賴屬性規則圖
通過以上的生成規則，已經可以覆蓋絕大部分的數據倉庫建設使用場景，也可以設計其他的依賴屬性來覆蓋更多場景，本文在此不再過多闡述。
② 生成實例
下面結合具體的生成規則，給出各類依賴場景的生成示例。
小時任務依賴小時任務：
小時任務小時任務可分爲兩種情況，一是當自生任務節點與依賴的父任務節點在一天內生成的實例相同，二是當自生任務節點與依賴的父任務節點在一天內生成的實例不同這兩種依賴情況。
實例數相同：基於調度時間分別排序當前任務和父任務實例，當前任務實例依賴父任務中與之排序序號相同的實例。例如下圖，節點 A 中實例 A1 是第一個實例節點，則節點 B 中第一個實例節點實例 B1 就依賴於實例 A1。
實例數不同：當前任務實例只依賴父任務實例中第一個不大於本任務實例調度時間的實例。例如下圖中，在自身實例數大於父節點實例數時，節點 B 中的實例 B1 和實例 B2 都依賴於節點 A 中的 A1，在自身實例數小於父節點實例數時，節點 B 中的實例 B1 會依賴於節點 A 中的實例 A1。
小時任務依賴天任務：
小時任務依賴於天任務即所有小時實例的都依賴於當天執行的天實例。
天任務依賴小時任務：
天任務依賴小時任務也可以分爲兩種，一是天實例依賴父任務生成的全部小時實例，二是天實例就近依賴其自身執行時間節點前父任務執行的最近的一個小時實例。
依賴全部小時實例：
天實例依賴全部小時實例的依賴情況
就近依賴小時實例
任務自身依賴：
任務自身依賴可以與任務間依賴一起作用構建實例間依賴關係，任務實例依賴本任務上一次調度執行的實例。例如下圖節點 A 爲小時任務，且配置自身依賴屬性，則 2019-11-21 的實例 1 依賴於 2019-11-20 的實例 24，21 號的實例 2 依賴於 21 號的實例 1。
4. 優化效果
通過上述的方案，將數據倉庫建設中的工作流節點，抽象成任務和實例兩個層次，可達到以下的優化效果：
配置工作流任務節點時，無需變更整個工作流配置信息，只需配置當前任務節點的週期和依賴屬性等內容，提升工作流配置靈活性；
通過任務的週期和依賴屬性，可以生成複雜的實例依賴關係，降低工作流節點依賴配置的複雜度；
能夠以某個任務節點爲根節點，構造子工作流 ( 包含此任務節點，及其子任務節點、孫子任務節點等 )，覆蓋歷史數據修復等場景。
04
總 結
本文主要根據數據倉庫建設過程中的 workflow 相關特點，將 workflow 中的節點抽象成任務和實例兩個層次，用戶只需要定義任務的週期屬性和依賴屬性，workflow 管理系統根據任務的這些屬性自動轉換成實例間的依賴，提升數據倉庫工作流管理系統的易用性。當然，數據倉庫工作流管理系統不僅僅包含本文描述的任務依賴和調度管理，還包括數據質量監控、數據處理任務追蹤、數據處理流程優化等等，需要深入融合 workflow 和數據倉庫兩個技術領域，提升數據倉庫建設工作的效率。
參考資料：
[1] MBA 智庫·百科.聯機分析處理[EB/OL]. https://wiki.mbalib.com/wiki/%E8%81%94%E6%9C%BA%E5%88%86%E6%9E%90%E5% A4%84%E7%90%86.
[2]百度百科.數據倉庫[EB/OL]. https://baike.baidu.com/item/%E6%95%B0%E6%8D%AE%E4%BB%93%E5%BA%93
[3]百度百科.聯機分析處理[EB/OL]. https://baike.baidu.com/item/%E8%81%94%E6%9C%BA%E5%88%86%E6%9E%90%E5% A4%84%E7%90%86?fromtitle=OLAP&fromid=1049009
[4]百度百科.工作流[EB/OL]. https://baike.baidu.com/item/%E5%B7%A5%E4%BD%9C%E6%B5%81
[5]Wikipedia.Indirection[EB/OL].
[6]Torben Bach Pedersen.Multidimensional Database Technology[EB/OL]. https://www.researchgate.net/profile/Torben_Pedersen4/publication/2955558_Multidimensio nal_database_technology/links/565c92eb08aefe619b25342f/Multidimensional-database-techn ology.pdf.2002
[7]Galaktikasoft.OLAP Basics and Multidimensional Model[EB/OL]. ology.html.2017
[8]羅海濱.工作流技術綜述[EB/OL].http://www.jos.org.cn/1000-9825/11/899.pdf.2000
[9]代立冬. 大數據下的企業數據倉庫建設[EB/OL]. https://myslide.cn/slides/8201.2017
[10]阿里巴巴數據技術及產品部.大數據之路-阿里巴巴大數據實踐[M].2017.7
[11]Document.Azkaban[M].https://azkaban.readthedocs.io/en/latest/
[12]Document.Oozie[M].https://oozie.apache.org/docs/5.2.0/index.html
[13]Document.Airflow[M].https://airflow.apache.org/docs/stable/
往期推薦
▬
Uber基於Apache Hudi構建PB級數據湖實踐
數據湖 | 一文讀懂Data Lake的概念、特徵、架構與案例
認識 Delta Lake：讓數倉進化到數據湖
乾貨 | Kafka 內核知識梳理，附思維導圖
