Laxcus大資料管理系統2.0（9）- 第七章 分布工作群組件

標籤：

第七章 分布工作群組件

　　Laxcus 2.0版本的分布工作群組件，是在1.x版本的基礎上，重新整合中介軟體和分布計算技術，按照新增加的功能，設計的一套新的、分布狀態下啟動並執行資料計算群組件和資料構建組件，以及依此建立的新的運行架構、操作管理規範、API介面等。

　　新分布工作群組件的改變主要體現在資料處理能力方面。經過重新調整後的運行架構，原來因為架構問題受到的諸多限制被全部取消，分布工作群組件可以隨著叢集的不斷擴充，同步提供無限制的資料處理能力。這足以滿足我們當前以及未來相當長一段時間內，對各種大規模資料處理業務的需要。同時我們也把大量原來由叢集管理員執行的管理工作給省略掉，交由系統來自主監管和執行，自動化管理能力因此大幅提高。

　　在Laxcus 2.0版本裡，分布工作群組件按照組件部署位置分為兩種：內部組件和外部組件。內部組件在叢集內部運行，執行大部分的分布處理工作；外部組件屬於用戶端組件，只在Front節點運行，根據使用者需要反饋處理結果。

　　從程式員角度來說，新的分布工作群組件是簡單的，可以不必再去考慮與系統有關的各種操作，只要求調用幾個API介面，就可以開發出符合要求的分布工作群組件，這類似於一個本地的資料庫開發過程，使很多有Java編程經驗的人都可以掌握。

　　由於本文是介紹Laxcus大資料管理系統，編程部分不在其列，所以下述內容仍然循此慣例，介紹分布工作群組件的相關概念和功能。希望通過介紹分布工作群組件，使大家對Laxcus運行機理有進一步瞭解。

7.1 階段命名

　　我們在第二章提到過“命名”的概念，它是對實體資源的抽象化表述。階段命名是命名中的一種，它在命名的基礎上，結合進分布資料處理中的“步驟”，加上使用者簽名引申而來，用於描述運行中的分布工作群組件，當時所處的狀態和位置。8.1所示，“step”用來說明當前分布組件的操作步驟，“root”是根命名，每個根命名必須全域唯一。判斷根命名唯一性的工作可以聯絡系統管理員，或者直接讓管理員提供。“sub”是子命名，用於迭代化的資料處理過程中。“issuer”是使用者簽名，是使用者登入時輸入的使用者名稱稱SHA1散列碼，用於分布環境下的安全檢查。

　　階段命名是分布工作群組件在Laxcus叢集部署、運行時的唯一身份標識，資料計算和資料構建都要用到它。

 

圖7.1 階段具名引數

7.2. 資料計算和Conduct命令

　　資料計算群組件在Diffuse/Converge演算法基礎上實現，在分布描述語言中的命令是Conduct。一個完整的資料計算群組件由5個階段組成，每個階段是一個獨立的子組件。資料計算各階段的工作內容和處理範圍，系統都做了明確的規定。Call節點處於中心位置，負責調配資料資源，和控制資料處理操作。

7.2.1 Init階段

　　Init階段是執行資料計算的初始化工作，按照Conduct命令中提供的參數和要求，為後續工作檢查分布資料資源，調配運行參數。產生的計算結果，將成為後續資料計算的參考依據，被儲存在Conduct命令中。Init階段組件屬於內部組件，指定部署到Call網站。

7.2.2 From階段

　　From階段對應Diffuse/Converge演算法中的Diffuse。在這個階段，將產生資料計算需要的未經處理資料。相對後續的To階段組件，這些資料是它們的輸入資料，對整個資料計算流程而言，屬於中間資料。資料產生來源目前有三種：1. 使用SQL Select語句產生；2.根據自訂參數，按照使用者解釋規則產生；3. SQL Select語句和自訂參數結合產生。無論哪一種情況，這些未經處理資料最初都會儲存在硬碟或者記憶體上（預設儲存到硬碟，儲存到記憶體需要程式員特別指定，同是視運行環境許可而定），然後產生資料位元圖返回給Call節點。資料位元圖是Laxcus系統的一種中繼資料，針對不同的需求有各種樣式。為了正常化處理，目前已經定義了一個基礎介面，各種應用可以在此基礎上加入新的元素，實現使用者自訂自解釋。From階段組件屬於內部組件，指定部署到Data節點。

7.2.3 To階段

　　To階段對應Diffuse/Converge演算法中的Converge。在這個階段，將執行實際的計算工作。對應上述Converge介紹，To階段是迭代的，要求發生最少一次，可以發生任意多次。如果是多次，分布描述語言中的子級To階段語句要使用SubTo。對應SubTo，這個子命名在階級集中也是唯一的。To階段迭代次數是程式員指定，被寫入到Conduct命令裡面，由Call節點按照理解執行。To階段最初用於計算的資料，來源於From階段，以後是上一次的To階段。To階段迭代在Call節點控制下持續進行，直到最後完成，把資料計算結果輸出給Call節點，如果沒有完成，向Call節點返回資料位元圖。To階段組件屬於內部組件，指定部署到Work節點。

7.2.4 Balance階段

　　Balance階段存在於From/To/Subto階段之間。它的工作是根據上個階段返回的資料位元圖資訊，為後續的To/Subto階段調配分散在Data/Work節點上的資料資源，使每一個To/Subto任務儘可能獲得相同的計算量，以儘可能相同的計算時間返回計算結果，達到節省總計算時間、提高計算效率的目的。對於資料位元圖，如果上個階段是由系統產生，那麼在Balance階段，解釋工作也由系統處理；如果是使用者自訂規則產生，那麼Balance階段就就按照使用者自訂規則來完成。Balance階段組件屬於內部組件，指定部署在Call節點。

7.2.5 Put階段

　　Put階段承接最後一次的To/Subto階段計算工作，是對上述資料處理結果的最終輸出。這些輸出通常是以電腦螢幕和磁碟為目標，把資料存入磁碟，或者以文字、圖形的方式顯示在電腦螢幕上。Put階段組件功能要求簡單，屬於外部組件，由使用者部署在自己的Front網站上。

7.3 資料構建和Establish命令

　　資料構建組件在Scan/Sift演算法基礎上實現，對應分布描述語言命令Establish。一個完整的資料構建組件由7個階段組成，和Conduct命令一樣，每個階段只處理一項規定工作，7個階段銜接，形成一個完整的資料構建處理流程。資料構建是順序執行的，不發生迭代現象，每個階段的輸出是下一個階段的輸入，或者引導下一個階段輸入方向。Call節點繼續介於中心位置，負責調配資料構建的資料資源和監控資料處理流程。

7.3.1 Issue階段

　　Issue階段與Conduct.Init階段有極大相似性，也是提供資料處理前的準備工作。這包括對Establish命令中的全部參數進行檢查，為後續階段檢查和調配資料資源。如果指定的參數中存在錯誤，或者資料資源不滿足要求，它將拒絕執行，並向使用者返回錯誤報表。Issue階段組件屬於內部組件，指定部署在Call節點。

7.3.2 Scan階段

　　Scan階段執行資料掃描工作，它只發生在Data主節點，檢查資料區塊的索引資訊。因為只掃描資料區塊的索引，所以這個速度是非常快的。在Laxcus系統中，現在已經提供了一個標準化的Scan階段組件介面，如果沒有特殊需要，程式員只需要調用這個介面就可以了。如果有個人化需求時，也可以在這個介面基礎進行再實現。Scan階段工作完成後，會向Call節點返回一個資料位元圖，裡麵包含了下個階段所需要的各種資訊。Scan階段組件屬於內部組件，指定部署在Data節點。

7.3.3 Assign階段

　　Assign階段工作承接Scan階段，它儲存來自Data節點的資料位元圖，直到全部收集完成。然後判斷已經在Issue階段定義的、所有關聯Build節點在當時的有效性，並依此對資料位元圖進行綜合比較和重組，按照平均分配的原則，把調整過的資料位元圖發給它們。Assign階段的工作和Conduct.Balance有部分相似之處，都要考慮下一階段的資料平衡問題。Assign階段組件屬於內部組件，指定部署在Call節點。

7.3.4 Sift階段

　　Sift階段是資料構建最重要的部分，所有資料構建的實質性工作都在Sift階段執行和完成，是資料構建的核心階段。在實際應用中，因為資料構建有太多的差異性，所以系統提供的Sift階段介面也是寬範的。系統負責完成的只有從Data主節點下載資料區塊一項工作，剩下的工作，程式員可以在安全功能內，在Sift介面裡執行各種資料操作。當Sift階段工作完成後，它將產生新的資料區塊，這些資料區塊將產生一個固定格式的資料位元圖，並返回給Call節點。Sift階段組件屬於內部組件，指定部署在Build節點。

7.3.5 Each階段

　　Each階段接受Sift階段返回的資料位元圖，它按照資料位元圖中提供的資訊，結合關聯的Data主節點，確認它們的存在，然後把資料位元圖進行重組和調配，產生新的資料位元圖，並傳遞給所有要求的Data主節點。由此可見，Each階段這樣的操作，從處理方式來說，和Assign階段基本一致，不同之處是，Assign階段是把中繼資料分配給Build節點，Each階段是把Build節點返回的中繼資料再分配返回給Data主節點。這可以理解為是Assign階段的反向操作。Each階段組件屬於內部組件，指定部署在Call節點。

7.3.6 Rise階段

　　Rise階段工作承接Each階段，它的工作內容就是按照Each提供的資料位元圖，找到指定的Build節點和資料區塊，進行下載。當下載完成後，這些資料區塊將被轉寄給關聯的其它Data從節點。因為Rise階段工作的內容是固定的，所以象Scan階段一樣，系統也提供了一個標準化介面，程式員只需要調用這個介面，把工作交給系統處理就可以了。Rise階段完成後，仍將返回一個資料位元圖，資料位元圖可以交給系統預設設定或者使用者自訂群組織。Rise階段組件屬於內部組件，指定部署在Data主節點。

7.3.7 End階段

　　End階段承接Rise階段，是資料構建的最後一個環節。它的工作內容也與Conduct.Put類似，是顯示資料構建的最終處理結果。由於End輸出的內容遠比Conduct.Put簡單和標準，只是一種提示資訊，所以通常程式員不需要太多處理，交給系統的標準化介面輸出即可。End階段組件屬於外部組件，指定部署在Front節點上。

7.4 打包

　　一個項目的編程工作完成後，接下來的工作就是打包。打包是把已經編譯好的代碼檔案放在一個檔案裡。打包操作可以使用Java運行環境提供的jar命令，或者Eclipse整合的ant工具來完成，這個過程和一般的Java打包操作完全一樣。不一樣的是，Laxcus系統要求打包後的分布工作群組件檔案名稱尾碼是“.dtc”，Task節點需要根據這個尾碼名來判斷分布工作群組件。另外，在每個分布工作群組件包裡，必須提供一個"tasks.xml"檔案。這是一個XML格式的設定檔，放在檔案包根目錄的"TASK-INF"目錄下面。它指定了一個組件包中，所有需要提供給系統識別和處理的資料。Task節點將根據這個檔案中提供的參數，把每個分布工作群組件推送到它的關聯節點下面。這是一個很重要的檔案，其中的配置和格式，系統都有明確規定，不允許出現任何錯誤。

 

 

圖7.4.1 tasks.xml設定檔

 

圖7.4.2 分布工作群組件目錄

7.5 發布

　　打包工作完成後，接下來就要執行分布工作群組件的發布工作。為了不影響叢集正常運行，在將分布工作群組件正式提交到叢集之前，我們提供了一個測試環境，供程式員檢查自己的分布工作群組件。由於這是測試環境，通常不具備運營環境所擁有的各種資源（使用者可以在測試環境裡搭建），所以在這個測試環境裡，主要是對分布工作群組件的格式、配置、運行流程進行檢查。當這些都確認正確後，就可以提交給叢集了。

　　Laxcus大資料系統支援“熱發布”，分布工作群組件在進入叢集的幾分鐘內，經過識別和處理，就可以生效。它首先會被投遞到Task節點，Task節點將根據“tasks.xml”檔案中提供的配置參數，對分布工作群組件進行一系列的檢查，在確認無誤後，分發給關聯節點。如果在檢查過程中發現錯誤，Task節點將拒絕分發，並把分布工作群組件和出現的錯誤推送給Watch節點，由管理員去聯絡使用者。為避免熱發布過程中發生版本衝突錯誤，使用者在發布前和發布過程中，應該停止工作，等待新的發佈動作完畢。

　　分布工作群組件投遞到Task節點的工作，有兩種操作方式：一種是使用者聯絡叢集管理員，讓他代為完成；另一種是使用者通過一個Web發布介面，跳過叢集管理員，讓Web程式直接投遞到Task節點下面。事實上，叢集管理員也主要是使用這個Web介面來發布分布工作群組件的。只是Web發布介面的管理權由叢集管理員掌握，他是否願意承接安全風險，開放這個介面，就由叢集管理員來決定了。

7.6 分區

　　無論是資料計算還是資料構建，它們本質都是分布處理。都存在著在計算中間資料過程中，如何把一大塊資料分割成多個小塊資料的問題。按照資料的不同特性建立對應的分割規則，就是“分區”要做的工作。

　　分區一般首先按照後續的節點數目劃分。這樣當把一塊資料分割後，後續每一個節點都能得到其中一小塊資料。更多時候要考慮資料屬性，按照資料屬性進行分割。比如執行帶order by、group by子句的select檢索時，就要根據排列、分組的資料類型，把資料划到不同的類別中。另外一些個人化的分割要求，因為系統無法實現統一處理，就留出了API介面，讓程式員去自主完成。

　　目前From/To、Scan階段的分布工作群組件都提供了預設的分割資料處理。

7.7 資料平衡

　　在分區基礎上，如果讓資料計算時間最短、計算效率最大化，還要進一步考慮平衡分布資料問題。

　　事實上，為了實現資料平衡處理，在分區時就已經準備了平衡處理參數。在執行過程中，資料計算的資料平衡工作由Balance階段負責，資料構建的資料平衡工作由Each階段負責。當不考慮電腦效能的時候，簡單的資料平衡是按照資料長度處理，這個參數已經在資料位元圖中提供。理論上，相同內容和長度的兩組資料，在兩台相同硬體設定的電腦上，它們的執行時間是一樣的。比較複雜的時候，就要考慮到資料類型和處理的內容，比如加減計算肯定比乘除要快，整數計算肯定比浮點數計算要快，多媒體的音頻、視頻資料肯定比文本資料計算密度大。與分區一樣，更多複雜的、個人化的資料平衡計算也通過API介面的方式，交給程式員處理。

7.8 記憶體模式

　　分布工作群組件在運行過程中，會產生大量的中間資料。在預設條件下，這些中間資料會被系統儲存到硬碟上，並在使用結束後被系統釋放。此前已經多次提過，由於磁碟的讀寫效率很低，系統對此做了很多最佳化處理。在分布工作群組件這一環節，為了滿足一些使用者的快速資料處理要求，加速資料處理速度，提升處理效率，系統提供了一個介面選項，允許中間資料儲存到記憶體裡。這項功能要求使用者在調用資料寫入介面時顯示指定，系統會根據當時的資源使用方式，有選擇地分配。在實際使用時，這項功如果與資料存取中的“記憶體計算”結合使用，將會使資料處理完全跳過硬碟這道瓶頸，把資料處理變成一次純粹的串流，並帶來數十倍的效率提升。流式資料處理方案，是那些對時間有敏感性的資料業務迫切需要的。

 

圖7.8 資料寫入記憶體介面

Laxcus大資料管理系統2.0（9）- 第七章 分布工作群組件