> 原文出處：http://www.infoq.com/cn/articles/laxcus-introduction-part1 > 作者：梁祖邦 ## 前言 LAXCUS是一套數據管理軟件，應用于大規模數據存儲和計算環境。這是一個獨立和完整的產品，融合了包括數據存儲、網絡通信、網絡計算、數據安全、網絡安全、任務調度、容錯處理、自動化管理、人機交互接口、應用開發等多方面的技術。LAXCUS采用JAVA語言編寫，支持行/列兩種數據存儲，通過終端或者應用接口嵌入方式接入，執行SQL和類SQL操作。產品布署使用快捷簡單，遵循LGPL協議，開放源代碼，運行在LINUX平臺。 [TOC=3,3] ### 1.1 基于現狀的一些思考 在過去十幾年里，隨著互聯網絡和各種新興技術的快速發展，數字信息存量呈爆炸性增長之勢。面對如此龐大的數據，如何實現高效的存儲和計算，通常采用的提高CPU性能和改用更大容量磁盤的做法，已經變得越來越困難。在這種背景下，以網絡和網絡通信技術為依托，將分散在不同地理位置的計算機連接起來，組成空間上分散、邏輯上統一的數據存儲和計算集群，成為當前實現大規模數據處理的主要選擇。 集群計算的優勢在于：它強調總體的處理能力，每臺計算機做為單個節點參與計算過程，承擔其中一部分計算任務，處理能力的強弱由全部節點共同決定。這種工作模式極大地發揮出網絡的能量，使得單臺計算機的處理性能變得不再重要。并且由于網絡的連接，每臺計算機隨時可以加入或者撤離計算過程。這種類似計算機“即插即用”的功能，使得集群在運行過程中可以動態地調整自己的計算能力，賦與了集群計算近乎無限增長的可能，這是傳統的集中式計算無法比擬的。同時由于不再追求單臺計算機的處理性能，采購硬件設備時，可以根據實際應用需求酌情考量，為節約成本投入提供了選擇的空間。 但是必須看到，正如硬幣的兩面一樣，集群計算在提供了前所未有的處理能力的同時，也有著它與生俱來的許多問題。 首先由于連接的節點眾多且分散，集群組織結構變得龐大。個體硬件品質良莠不一，網絡線路、通信設備、計算機之間的連接和通信過程存在著不確定性，硬件設備內部、設備與設備、設備與外界環境，彼此互相交叉影響。在這樣的條件下，保證每臺設備完全穩定運行已無可能，解決集群組織不安定狀態下的穩定計算成為首要問題。 另外，與集中計算不同的是，集群的數據處理是一個分散的計算過程。它的前端受理大量的請求任務，然后將這些任務分配到后端眾多的計算機上去執行。一個高效并且合理的分布計算算法成為必須。算法需要解決的問題包括：任務分配、過程調度、故障容錯、數據篩選、數據平衡、數據匯總等諸多環節的工作，最終形成與集中計算一樣的處理結果。這個過程十分復雜。 數據管理益變得重要。在一個大規模的數據存儲序列中，要保證完全正確的處理結果，任何單點上的數據都不能遺漏。這需要感知每個數據的存在，確定數據的物理位置，能夠驗證數據的可用性和正確性，即使在故障狀態下，仍然需要確保計算過程的正常進行。這是對數據處理的基本要求。 更重要的是用戶體驗。沒有人會喜歡一個復雜、繁瑣、難以維護的系統。相反，一個人機界面友好、容易操作的產品更容易受到用戶青睞。這需要在產品設計時做很多工作，綜合考量產品的應用范圍、處理效率、運營成本，以及用戶的使用行為和習慣，做出必要的取舍，輔以技術實現，才能產生良好的使用體驗。 當能夠提供的硬件基礎設施已經固定，各種應用需求還在不斷發展和變化，如何適應這種變革中的趨勢，以上種種，都是軟件設計需要思考的問題。 ### 1.2 產品特點 由于新的系統基于網絡環境，需要適應數據在存儲量和計算能力上的可調節的增減，這種運行中動態波動的數據計算，完全不同與傳統的處理方式。一系列新的變化促使我重新審視產品的定位和設計，這些因素疊加在一起，最終形成了與以往完全不同的結果。 #### 1.2.1 以普通硬件為標準的動態可伸縮的容錯處理 LAXCUS將集群設備的硬件參考標準定位為普通的個人計算機。這種設計有兩個好處：1.將用戶的硬件設備投入成本降到足夠低；2.需要充分考慮硬件的不穩定性。在產品設計和實現中，硬件的不穩定由軟件通過監控和故障冗災機制來彌補恢復，任何設備和設備組件的失效被視為正常情況，而不是異常。設備故障通過自檢報告和管理服務器追蹤來感知。發生和發現故障后，故障點將被隔離，同時通知系統管理員。設備的故障恢復被視為新設備加入。故障設備中的數據通過多機冗余備份和復制機制來保證有效存在。 #### 1.2.2 弱中心化管理 見圖1.1，運行中的集群由節點構成。節點按功能劃分為管理節點和任務節點，TOP和HOME是管理節點，其它都是任務節點。管理節點是整個集群的核心，承擔著監督和管理任務節點作用。與強調管理節點的中心全責監管的理念不同，LAXCUS采取了弱中心化的管理設計措施。在LAXCUS集群中，管理節點只承擔少量和重要的管理任務，任務節點在負責具體工作的同時，也需要監視自身的工作行為。這種自維持的工作方式，可以減少與管理節點的通信。帶來的優勢就是：管理節點的壓力減輕，能夠騰出更多計算能力處理主要的任務，任務處理速度可以更快，服務器硬件配置因此可以降低。任務節點由于自維持的特點，既使在管理節點宕機情況下，也能維持一段時間的正常運行，直到再次發起對管理節點的請求。而這段時間內，管理節點可能已經恢復。弱中心化管理增強了集群的穩定性。 #### 1.2.3 多集體群的協同工作模式 見圖1.1的LAXCUS集群結構圖，其中包括兩個HOME集群，TOP節點位于兩個HOME集群上。這是一個典型的多集群結構模型，LAXCUS最顯著特點之一，就是能夠支持多個集群跨地域協同工作，這與單集群處理系統有著根本的不同。在傳統的單集群系統中，管理節點承擔著管理維護整個集群運行的工作任務，如果一味提高集群中計算機的數量，就會增加管理節點的處理壓力，從而影響到集群的穩定運行。采用多集群協同工作方式后，將每個集群的計算機數量限制在一定規模，則能夠有效化解這個可能成為瓶頸的問題。另一方面，由于多集群結構是數個子集群的組合，每個子集群可以分散在不同甚至遙遠的地理位置，只要能夠通過VPN或者互聯網絡實現連接，就能夠實現更大規模的網絡計算，成倍增加集群的數據處理能力，進一步提升工作效率。 #### 1.2.4 以支持大規模檢索/添加為主，兼顧小批量刪除/更新的數據處理 在產品設計前，通過對大量數據操作行為的追蹤和分析發現，數據操作主要集中在添加和檢索階段，刪除和更新極少發生，其中檢索行為又遠遠超過添加。這個現象促使我對數據存儲設計產生了不同以往的定位，將整個存儲方案重點圍繞著檢索展開，并據此制定了以下的執行策略：首先，為保證大數量高頻度的檢索操作，結合到計算機內的CPU、內存、磁盤各主要工作部件的性能，在保持數據的最大吞吐量上，流式處理效率最高。并行的數據寫入在進入存儲層面時，匯流為串行模式。檢索操作的最終目標是磁盤（溫徹斯特硬盤），磁盤檢索受制于磁盤物理特性的影響，在數據計算過程中，嚴重拖滯了整體性能的發揮，為提高數據處理性能，需要在檢索前對數據進行優化，如關聯和聚湊，同時提供一批優化規則給用戶，讓用戶能夠按照自己的意愿去組織和檢索數據。刪除不改變數據本身，只對數據做無效記錄。數據更新分解為刪除和添加兩步操作，其目的在于簡化和內聚數據處理流程，同時避免發生多次磁盤讀寫現象。 #### 1.2.5 數據即時存取 即時存取是衡量系統是否支持實時處理的關鍵性指標。其表現是數據一旦進入存儲環境，立即生效并且可以使用，而不是之后的某一個時段才能生效和使用。由于實現了即時存取，LAXCUS可以保證在任何時間任何范圍內對全網數據執行無遺漏的檢索，達到與關系數據庫同等的響應能力。即時存取非常重要，是許多關鍵業務處理必須滿足的一項功能。 #### 1.2.6 SQL LAXCUS采用SQL做為系統的人機交互接口。采用SQL的原因主要有二：以關系代數為后盾的理論基礎，優秀的類自然語言表述能力。關系代數將數據處理和處理結果的嚴謹性得以體現，類自然語言使得SQL靈活簡單、易學易用，還有其豐富的功能、語法規范標準化、被普遍接受的程度、管理維護成本低，這些都是促成LAXCUS采用SQL的原因。更重要的是，在SQL發展的四十年里，其衍生出的各種數據設計思想和使用經驗，影響延續到今天，即使在這個大規模數據處理時代，也是可以借鑒和彌足珍貴的。 但是大規模數據處理和以SQL為代表的關系數據庫的應用需求畢竟有太多不同，所以本著揚棄的原則，LAXCUS保留了大部分SQL功能，取消了一些不合適大規模數據處理的定義，對其中一些定義中的元素和概念進行了調整，同時引入了一批新的概念和操縱語句。這些變化，都是為了適應大規模數據處理時代所做的抉擇。 有關SQL的更多介紹，將在第6章闡述。 #### 1.2.7 網絡計算可編程接口 為了滿足各種大規模數據計算業務需要，方便用戶開發LAXCUS上運行的網絡計算中間件程序，LAXCUS為程序員提供了一套經過抽象處理的網絡計算可編程接口。接口將網絡計算流程規范化，屏蔽了系統的服務部分，呈現給程序員的是一組可派生的接口類。這樣就使程序員不必考慮網絡計算過程中的任務分配和調度問題，只需要將精力集中到業務規則的編程實現上。完成后打包發布，剩下的工作，將交給集群去托管處理。用戶可以通過終端，使用SQL和類SQL語句操作中間件運行。LAXCUS將集群環境下的大規模計算任務簡單化，降低了程序員的開發難度和用戶布署使用的壓力，也減少了故障發生概率。為防止運行中的錯誤，LAXCUS還提供了一套錯誤檢索機制，幫助快速定位和檢查錯誤，盡可能不影響系統運行。 出于安全的考慮，這些中間件程序被限制在“沙箱”框架內工作，避免因為惡意破壞或者越權操作影響到系統正常運行。 ### 1.3 架構 如圖1.1所示，LAXCUS是一個由多種類型節點組成，通過網絡實現連接，有任意多個子集群同時運行的數據存儲和計算的集群。節點在這里是一個邏輯單位概念，每個節點都嚴格遵守設計規定的工作范圍。理論上，一臺物理計算機上可以擁有任意個節點，包括組織成為一個集群。節點從工作屬性來看，具有雙重身份，即是服務器又是客戶端。當它做為服務器使用時，接受來自其它節點的任務調度；當做為客戶端使用時，會向其它節點發送處理命令。節點按功能分為管理節點和工作節點。管理節點在所屬集群內可以同時存在多個，但是只能有一個處于運行服務狀態，職責是監督和控制所屬范圍內的節點運行。其它管理節點處于備用狀態，監督這個運行節點的工作，當運行節點故障失效時，通過協商方式推選出一個新的節點，來接替故障節點繼續實施監督和控制工作。工作節點可以有任意多個，數量上沒有限制，視用戶需求決定。各節點之間通過網絡進行任務分配和調用，形成分散且協同的工作模式。軟件層面上，節點實質是LINUX系統根用戶下的一個進程，沒有操作界面，在后臺運行，啟動時運行一個網絡通信服務器保持與外界對話。 (點擊圖像放大) [](https://box.kancloud.cn/2015-09-17_55fa66ed7d5f3.jpg) 圖1.1 LAXCUS集群 #### 1.3.1 TOP節點 TOP是管理節點，是LAXCUS集群的基礎核心節點，必須保證有效存在。其它類型的節點都是TOP節點的下屬節點，TOP節點在其它節點前啟動，在其它節點全部停止后才能停止。TOP節點的管理范圍包括：接受、保存、檢查、分配所屬的用戶登錄賬號、操作權限、數據庫配置、網絡資源，同時接受HOME節點和終端的注冊，以及監測它們的運行。如上面所述，TOP節點做為管理節點要求有多個，但是通常要求一個運行節點和最少一個備份節點，因為TOP節點故障會造成整個集群的運行管理混亂，隨時保持最少一個備份節點替代故障節點是必須的。TOP備份節點在備用期間，除了監測運行中的TOP節點，還會通過網絡定時復制它的管理資料和運行數據。當運行節點發生故障后，協商選舉出的新的運行節點會通知原來的HOME節點和終端，重新注冊到它的環境下。 通常情況下，TOP節點只維持不多的HOME節點和終端/應用接口的通信，所以它的管理任務并不繁重。 #### 1.3.2 HOME節點 HOME節點是LAXCUS子集群(也稱HOME集群)的管理節點，是HOME集群的核心。對上，向TOP節點注冊，接受TOP節點的管理；對下，接受所屬集群節點的注冊，監控和協調它們運行。LAXCUS中定義的工作節點全部運行在HOME集群內。HOME節點的管理范圍包括：匯總工作節點的元信息、追蹤工作節點的運行狀態、檢測網絡故障和故障節點、控制數據塊分發、協調集群負載均衡。與TOP節點一樣，HOME集群也要求一個運行節點和最少一個備份節點，備份節點定時復制運行節點上的運行數據。 #### 1.3.3 LOG節點 在整個運行過程中，LOG節點唯一的工作就是接收和保存其它節點發來的日志信息。對這些節點，LOG節點將根據它們的節點類型和節點地址建立目錄，日志文件名是當前操作系統日期。日志中的主要信息是各節點的工作流程和運行錯誤，這些信息能夠為分布狀態下的數據追蹤和分析、程序調試、定位和判斷節點運行故障提供重要依據，所以LOG節點的工作雖然簡單，但是非常重要。 #### 1.3.4 CALL節點 CALL節點介于LAXCUS集群的中繼環節，起到類似路由器的作用。對外，它接受終端和應用接口的調用；對內，它定時收集DATA、WORK、BUILD節點的運行信息，把終端和應用接口的指令轉換成具體的操作任務，分派給DATA、WORD、BUILD節點執行，并且在中間協調網絡計算過程，將最后的計算結果返回給任務發起方。CALL節點通常做為一個根用戶進程獨立運行，也可以是一個WEB服務器（如TOMCAT）的子進程，綁定在WEB服務器上運行。CALL還是集群中除TOP節點外，唯一與外界保持聯絡的節點。 #### 1.3.5 WORK節點 WORK節點在整個運行過程中只做一件事：接受CALL節點調用，執行具體的數據計算。在實際應用中，WORK節點的工作量會很大，經常發生硬件部件使用達至極限的超載現象(如CPU的使用率達到100%)。如果這種現象持續存在，WORK節點會通知CALL節點，減少對自己的調用。 #### 1.3.6 DATA節點 DATA節點提供數據存儲服務，它的數據管理范圍包括：建立、檢查、回收數據空間，接受SQL操縱，添加、檢索、刪除、轉發、檢查、優化數據。DATA節點有“級別”概念，分為“主節點”（PRIME SITE）和“從節點”（SLAVE SITE），它們的區別在于數據處理范圍不同。主節點具有“讀/寫”能力，負責數據的添加、刪除、更新、檢索、優化工作，從節點只執行讀操作，承擔檢索和來自主節點的數據備份工作。網絡計算的初始數據也從DATA節點上產生，數據來源一般是SQL SELECT的檢索結果，或者根據業務規則生成的信息，這些數據將提供給后續的WORK節點使用。 #### 1.3.7 BUILD節點 BUILD節點的工作是處理ETL業務(extrace、transform、load)，它在執行前會收集DATA節點的數據，然后執行ETL處理。一般經過BUILD節點處理后的數據計算效率會更高。系統提供了一套API接口，支持ETL業務服務。用戶需要派生接口實現自己的業務流程。與其它節點不同的是，BUILD節點只在收到用戶或者管理節點的作業指令后才進行工作，通常情況下都處于空閑狀態。 #### 1.3.8 終端 終端是由用戶驅動的界面輸入接口，為用戶提供SQL和類SQL語句的遠程操控能力。 它能夠在任何可以聯網的位置運行，是一個純客戶端的概念。所以，從這一點嚴格地說，終端并不屬于集群范疇。為適應不同操作系統和用戶的使用習慣，LAXCUS提供了兩種模式的終端：基于字符界面的LAXCUS Console和基于圖形界面的LAXCUS Terminal，如圖1.2和圖1.3。圖形界面的終端主要是考慮了WINDOWS用戶的需求，而專業的LINUX用戶可能更喜歡使用字符界面。兩種終端的操作指令是完全一樣的。  圖1.2 LAXCUS字符終端  圖1.3 LAXCUS圖形終端 當前發生的很多大規模數據計算，一次計算驅動幾個GB的數據已經是十分普遍的現象。這種在網絡間傳遞，數量大、發生頻度高的數據處理，需要保證數據具有足夠的穩定性和可靠性，才能正確完成計算任務。這是一個復雜的工作，必須兼顧好每一個環節。在這一章里，將從數據的存儲、組織、分配、維護等多個角度去闡述數據的設計和管理，以及如何優化它們。 ### 2.1 數據塊 在實際的數據應用中，一個單位的數據尺寸往往有很大的隨機性。小者可能是幾十個字節，大者可能達到數十兆，甚至數百兆。當一個集群里的計算機，每臺計算機的數據存儲量達到TB規模，每天可能處理的數據超過PB量級的時候，即使磁盤文件系統支持這種單位的存儲，也將使磁盤運行不堪重負，這是操作系統不能接受的，并且因此產生的磁盤碎片也是對磁盤空間的極大浪費。 針對這種現狀，LAXCUS設計了一套新的數據存儲流程，來保障高效的數據處理。首先，在內存的自由區域開辟出一塊固定長度的空間，此后的每一批數據，系統都以流式的串行追加方式寫入。這樣即使當時有多個寫入者，因為內存處理效率頗高和串行寫入的原因，在寫入過程中幾乎沒有延遲或者很小，也不會產生寫入沖突。當內存空間的數據量達到規定閥值的時候，系統將內存空間關閉，并且執行一系列的數據優化措施，包括壓縮和重組這樣的處理，最后將這片內存數據以文件形式一次性寫入磁盤。這個進入磁盤的文件，被稱為“數據塊”。 LAXCUS將駐留在內存時的數據稱為數據塊的“CACHE”狀態，寫入磁盤后，被稱為數據塊的“CHUNK”狀態。系統設置的內存數據區域的標準閥值是64M，這個參數也可以由用戶定義，最大不能超過4G。對于超大尺寸的內存數據區域，系統將視磁盤文件系統和可用內存空間而定，如果不能支持，將自動調整到合適的尺寸。 為了能夠區分內存和磁盤上的每一個數據塊，系統會在每個數據塊生成時，為它設置一個64位的無符號長整數，做為唯一標識它的編號。編號由TOP運行節點提供，保證集群中唯一，不會重復。數據寫入磁盤后，這個編號也是數據塊的文件名。 依據1.3.6節對DATA節點的定義，數據塊只保存在DATA節點上，并且依從DATA節點的主從關系。所有主節點上保有的數據塊都是主塊(PRIME CHUNK)，從節點保存從塊(SLAVE CHUNK)。數據塊的主從角色會根據所屬DATA節點級別發生變化。一個集群上，同質數據塊只允許擁有一個主塊，其它都是從塊。寫數據的傳入，由CALL節點負責實施，向相關的DATA主節點均勻推送，這樣可以使這些DATA主節點，在各自擁有的數據量上保持一個相對均衡的狀態。 系統不會在非DATA節點上緩存數據，這個設計是參考了大量實例后做的決定。經統計，單位時間內的網絡計算，一個指令被重復執行的概率極低，這就連帶影響到數據的重復命中率，使得在內存里緩存數據沒有意義，并且緩存數據會占用大量寶貴的內存空間，顯得得不償失。 數據塊的采用，很好地消除了磁盤碎片的現象，也減輕數據輸入磁盤時的寫處理壓力。按照數據塊標準的64M計算，數據寫入磁盤的時間不會超過1秒。檢索數據時，將按照優化規則從磁盤讀取數據，這樣也降低了數據輸出過程的讀處理壓力。 ### 2.2 存儲模型 存儲模型是數據在磁盤上的物理組織結構。在許多介紹數據庫的書籍里，存儲模型又被稱為內模型。它在很大程度上決定了數據的可應用范圍，是衡量數據存取性能的重要指標之一。 LAXCUS在數據塊的基礎上實現了行存儲模型(NSM)和列存儲模型(DSM)。因為兩種存儲模型的組織結構完全不同，以下將結合圖2.1和數據運作流程，來闡述這兩種存儲模型的特點及優劣。 這是一個網絡音樂文件表，由6個屬性組成。圖2.1左側是行存儲模型，每一行由不同屬性的列值組成，數據是從左到右、從上到下的排列，形成行與行連接的布局。圖2.1右側是列存儲模型，同屬性的列值被組織在一起，成為列的集合，數據是從上向下、從左到右的排列，形成列集合與列集合連接的布局。 如2.1節所述，行/列存儲模型都是建立在數據塊的基礎上。CACHE狀態時，數據的讀/寫處理都在內存中進行，雖然兩種存儲模型的組織結構不盡相同，但是因為內存處理效率頗高，這個問題在速度面前就顯示得微不足道。放到實際環境中檢驗，通過追蹤兩個存儲模型的數據處理流程，發現它們的處理效率的確沒有差別，所以兩種存儲模型雖然結構不同，但是在CACHE狀態可以完全忽略。 差異主要體現在數據塊的CHUNK狀態。進行CHUNK狀態后，數據處理將在磁盤上執行。行存儲是以行為單位，若整行讀取，那么行存儲效率很高；如果讀取多行，最好在數據寫入前將被檢索的數據排列在一起，這樣只需要對磁盤做一次定位和讀取。同樣的，列存儲是以列集合為單位，它適合對單列連續數據的讀取，如果讀取多列數據，就需要掃描不同的磁盤位置，這會降低磁盤檢索效率。 數據塊CHUNK狀態的寫處理，只會發生刪除和更新操作。因為更新被分解為刪除和追加，所以實質仍然是刪除操作。刪除操作不會將數據從磁盤中清除，只在數據的某個位置做一個無效標記。如果是批量刪除，就需要分別做多個無效標記，這種操作對磁盤性能影響很大。 但是在實際應用時不是這樣。根據磁盤(溫徹斯特硬盤)工作特性，一個完整的讀/寫處理，分為磁頭定位、等待、數據傳輸三個階段。從目前磁盤性能的發展趨勢來看，帶寬速率的提升優于磁頭定位，況且現在計算機的內存容量已經足夠大，緩存一些數據也綽綽有余。根據這種情況，實際的讀/寫處理，是將需要的數據一次性調入內存，在內存中完成處理后再輸出。這種處理方式，非常有助于提高磁盤處理效率。 在其它方面，列存儲模型的數據是可以壓縮的，壓縮的直接優勢就是能夠節省磁盤和內存的空間。比如當某一列有10個999的整數時，就不必把10個999依次排列，而是在999前面加一個10，就表達了10個999的含義。行存儲模型則沒有這方面的能力。列存儲模型的值還可以自動成為索引使用，省略了用戶設置索引這一步驟，其優勢除了節省磁盤和內存空間，還因為沒有了關聯操作，簡化了存儲層面上的計算。行存儲模型如果使用索引，則需要用戶說明具體的列，并且在行數據集合之外開辟一塊索引數據空間，處理前進行關聯才能生效。 綜上所述，行/列存儲模型在CACHE狀態的處理性能持平。在CHUNK狀態，行存儲模型適合整行讀取，列存儲模型適合單列讀取。CHUNK狀態的寫處理，因為數據在內存進行，它們處理性能仍然基本一致。 (點擊圖像放大) [](https://box.kancloud.cn/2015-09-17_55fa66f609541.png) 圖2.1 行存儲模型和列存儲模型 ### 2.3 行級鎖 從數據組織的邏輯角度來看，“行”是能夠表述一個完整信息的最小單位。為了保證數據一致性，防止多方操作競用可能引起的數據混亂，LAXCUS在“行”這個層級對數據執行鎖定操作，這個設計理念與關系數據庫完全一致。行級鎖是一個互斥鎖，在一個時間內只允許執行多讀或者單寫操作。因為它的粒度足夠細，只對單個行進行操作，不會涉及到其它行，所以幾乎對整個集群計算沒有什么影響。目前行級鎖在行/列兩個存儲模型上都已經得到技術實現。 ### 2.4 元信息 為了快速定位和計算數據，元信息做為數據操作者和被操作對象之間的中間媒質，來配合完成這項工作。元信息的本質是實體資源的抽象描述，包括節點元信息和數據元信息，前者由網絡地址、運行參數組成，后者將數據塊的“列”格式化為4至16字節不等的數值，按順序排列。 元信息的數據量都很小，在所在節點的運行過程中產生，隨節點運行發生變化和更新。這些特點使它適合在內存中駐留，執行快速計算。產生元信息的節點會不定期的，向它的上級管理節點提交元信息，管理節點根據這些元信息按規則進行匯總和排列。需要元信息的節點，向它的上級管理節點申請和獲取，存儲在本地內存中，并將元信息重新篩選和排列，形成一種類似索引的數據結構，為后續的數據計算提供必要的判斷和準備依據。 ### 2.5 內存模式 數據塊存儲在磁盤上，受制于磁盤性能的限制，其讀寫效率相較于CPU和內存嚴重滯后，拖慢了整個計算過程。尤其在面對熱點數據塊讀寫，或者需要提取大量數據計算時，這個影響尤其明顯。一個簡單的辦法是把數據塊調入內存，使其以接近CPU的速度運行，可以有效減少磁盤對數據的影響。 系統提供了兩個加載數據塊的方案：1.當內存空間比較充裕時，由系統判斷，把熱點數據塊調入內存。 2.由用戶決定，通過終端或者應用接口發送指令，指定某些或者某臺計算機上的數據塊，把它們加載到內存里。加載數據的過程中，系統會判斷計算機的實際內存容量，在接近限制前會停止，不會發生內存溢出的現象。 如果是系統加載的數據塊，這個調用是臨時的，熱點數據塊會持續受到監視，當低于調用閥值，或者內存有限，使用頻率更高的數據塊需要加入時，會把它從內存中移出。 用戶也可以做反向操作，把數據塊從內存中釋放，同樣是通過終端或者應用接口進行。 內存模式不影響數據的寫操作，如果是添加、刪除、更新情況，會同步修改在內存和磁盤的數據塊。 內存模式更適合只讀操作，這和大規模數據檢索需求匹配。尤其在今天很多CPU都已經是64位，尋址范圍突破4G限制的情況下，內存可以充當一個臨時的數據倉庫，是一個提升數據計算效率的好辦法。 ### 2.6 快照和備份 每一個CACHE狀態的主數據塊，在主節點上生成后，會通過網絡定向通知其它幾個關聯節點，產生相同編號的CACHE數據塊。此后這個主數據塊，每一次寫操作，都會通過網絡向它們傳遞當前數據的復本。這些以復本形式存在的CACHE狀態數據塊，被稱為“快照”。 每一個主數據塊，從CACHE狀態轉入CHUNK狀態后，主節點將立即啟動，通過網絡分發這個數據塊的數據復本。這些被傳播到不同節點的數據塊，被稱為“備份”。備份也就是2.1節所述的從塊。 備份數據塊傳遞完成后，主DATA節點會通知關聯的DATA節點，將CACHE狀態的“快照”刪除。此后的運行過程中，如果發生寫操作，CHUNK狀態的主數據塊仍會執行與快照一樣的處理。 快照和備份的分配，將根據集群的網段原則進行選擇。這是一個類似LINUX TRACEROUTE命令的處理過程，通過向不同DATA節點發送ICMP包，探測當前節點與目標節點的跳點數，判斷網段之間的距離，按照由遠及近的順序進行分配。 系統規定同質數據塊的默認存量是3，即有1個主塊，2個屬于快照或者備份的從塊。主塊允許執行讀/寫處理，從塊只能執行讀處理，和接受主塊的原始數據覆寫操作。這個參數也可以由用戶定義，但在運行時將受到具體環境的限制，如果實際節點存量不足，將只能滿足到最大可用數量要求。 快照和備份使同質數據塊之間保持了原始級的數據一致性，同時還實現了分解讀處理壓力、負載平衡、冗災恢復的目的。如果當某個數據塊讀操作壓力過大時，這個DATA節點會向HOME節點提出請求，HOME節點會進行協調，將這個數據塊分發到其它空閑DATA節點上，以降低請求節點的讀取壓力。或者某個DATA主節點發生運行故障，HOME節點能夠快速感知，然后根據數據塊編號，從相同的快照或者備份中選擇一個，把它分發到某個正常的DATA主節點，升級為主數據塊，來取代故障數據塊。選擇的依據是時間，在所有快照或者備份中，以文件修改日期最新的那個為準。 ### 2.7 完整性檢查 DATA節點啟動時，會對磁盤上的每個數據塊進行掃描，檢索它的數據完整性。掃描將首先判斷數據塊的存儲模型，再分別進行處理，具體到數據塊的每一行或者列集合。如果掃描過程中發現錯誤，將進入暫停狀態，通過網絡申請一段正確的數據復本，來覆蓋錯誤的數據。數據塊的掃描在內存中進行，完成后釋放。掃描采用CRC32校驗和算法，這個計算過程非常快，在32位的PENTIUM4 2G計算機上，一個標準的64M數據塊的執行時間不會超過1秒。通過完整性檢查，可以即時判斷數據塊的每一段數據錯誤，保證后續正確的數據處理。 ### 2.8 數據優化 數據塊長時間運行后，由于刪除和更新操作的增加，會對數據塊的不同位置做很多無效標記。這些無效標記導致了數據碎片的產生，除了占據著磁盤空間，還嚴重影響到磁盤數據檢索效率。為了消除這個影響，提高數據檢索效率，有必要對數據塊做優化處理。 系統提供了一個數據優化的命令，用戶可以通過終端或者應用接口發起操作，或者定義在數據字典里，委托給TOP節點管理，定時啟動。 數據優化只作用于DATA主節點的主數據塊上。工作完成后，會通知關聯的從節點，更新相同編號的數據塊。在數據優化期間，全部數據塊都被鎖定，所以這個時候不能執行任何數據操作。但是優化過程完全在內存中進行，計算一個標準的64M數據塊，更新時間大約在1秒左右，所以也能夠較快完成任務。考慮到需要回避正常計算業務工作的時段，建議這項工作在系統的空閑時間進行，比如夜間的某個時刻，這些時間的用戶請求量通常會顯著減少。 ### 2.9 數據構建 數據優化是在不修改數據結構的前提下，對DATA主節點下的數據塊進行的更新工作，目的是清除垃圾數據和提高檢索效率。數據構建在此基礎上更進一步，依靠一種或者多種數據結構的數據塊，提取它們全部或者部分數據信息，經過篩選、分析、計算，形成包括存儲模型、數據結構、數據內容在內的新的數據集合，并且工作位置也轉到BUILD節點上進行。 數據構建屬于ETL服務的一部分。因為數據構建會涉及到不同的業務方案，無法進行統一處理，所以系統提供了一套API。API提供了規范的數據處理流程，其中具體的業務，由了解業務的工作人員按照實際需求編寫計算機代碼。編碼完成后，發布到BUILD節點運行，BUILD節點會自動感知并且識別它們。 啟動數據構建的工作由用戶通過終端或者應用接口觸發，或者交由TOP節點代為管理執行。BUILD節點在收到命令后，按照系統規定的工作流程處理。 數據構建是大規模數據計算中一項很重要的功能，在很多場合都有實際應用。例如許多數據計算業務都需要分別采集各種不同的數據，如果在運行時處理，過程會繁瑣，耗時長，運算成本高。如果提前產生，一次性獲得全部數據結果，然后在這個基礎上再進行計算，程序員的開發工作和數據處理會變得簡單，時間會縮短，運算成本也會降低。 #### 2.10 主塊沖突 首先，主數據塊在任何時間只能有一個。當DATA主節點發生故障恢復后，會重新向HOME節點注冊，同步上傳的還有節點所屬的數據信息。HOME節點會檢查每一個數據元信息，與內存中駐留的數據元信息進行比較，這時可能會發生兩個相同編號主數據塊的情況，這就是主塊沖突。 解決主塊沖突的唯一辦法仍然是時間。根據兩個主數據塊最后的文件修改時間，判斷它們的數據有效性，以時間最新的那個主塊為準。舊的主塊將會從磁盤刪除，從而達到防止主塊沖突的目的。 #### 2.11 負載檢測 在系統運行過程中，一個現實的情況是：隨時會因為需求增加有大批計算任務加入，同時也會有個別節點因為各種原因而退出運行過程。在這種波動的運行狀態里，不可能完全杜絕超載現象，能做到的只是盡可能減少超載發生頻率。 使計算機發生超載的源頭主要有兩個：CPU、磁盤。CPU超載原因是存在大量數據計算，磁盤超載是讀寫頻率過高，減少超載現象的有效辦法是限制計算任務量。通過LINUX的top命令能夠觀察到CPU和磁盤的運行情況。當超載現象持續時，系統將啟動“鎖”機制，限制計算任務運行，同時通知任務發起方，減少對本節點的調用頻度。 對數據超載的檢測會具體到每個數據塊，如果系統發現某個數據塊的調用在一定時段內超過閥值，會選擇臨時加載到內存或者分發到其它空閑的計算機上執行，以達到降載的目的。