> 原文出處: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和磁盤的運行情況。當超載現象持續時,系統將啟動“鎖”機制,限制計算任務運行,同時通知任務發起方,減少對本節點的調用頻度。
對數據超載的檢測會具體到每個數據塊,如果系統發現某個數據塊的調用在一定時段內超過閥值,會選擇臨時加載到內存或者分發到其它空閑的計算機上執行,以達到降載的目的。