Laxcus大數據管理系統2.0（3）- 第一章 基礎概述 1.2 產品特色

1.2 產品特色

 

　　Laxcus大數據管理系統運行在計算機集羣上，特別強調軟件對分佈資源可隨機增減的適應性。這種運行過程當中數據動態波動和須要瞬時感知的特色，徹底不一樣與傳統的集中處理模式。這個特性衍生出一系列的新變化，須要從新審視產品的目標，設計新的架構，當咱們把這些需求和定位綜合起來，而後逐一分解歸併後，最終造成與以往徹底不一樣的結果。

1.2.1 以節點爲單位的計算集羣

　　在Laxcus設計裏，節點是計算機集羣的基本單位。相較與物理性質的計算機來講，節點是一個邏輯概念的單位。以一臺實體計算機爲例，在它上面能夠部署最少一個節點，也能夠部署多個節點，共享一臺計算機的資源。按照工做屬性劃分，節點分爲四種類型：前端節點、網關節點、工做節點、管理節點。前端節點負責發起任務請求和顯示數據處理結果。網關節點將Laxcus集羣分紅內外隔絕的兩個部分，它處於「邊界」位置。對外，它接受來自前端節點的任務請求；對內，它將前端節點的任務請求轉發給集羣內部的工做節點處理，同時起到對外部屏蔽集羣內部拓撲結構的安全做用。工做節點承接網關節點的任務請求，組織和實施具體的數據處理工做，在完成後，將數據處理結果轉發給邊界節點。管理節點在集羣裏是一個「維護者」的角色，它沒有任何數據處理任務，只負責監測和協調下屬的網關節點和工做節點的工做。在Laxcus集羣裏，前端節點的部署和維護由是用戶來實施，沒有明確的要求。被大量部署的是工做節點，以及少許的網關節點，和一個管理節點。Laxcus把它們組織起來，來完成許多大型的數據存儲和計算工做。這些大型工做的工做量，一般是一臺幾臺計算機不能完成，或者短期內不能完成的。在實際部署中，一個標準的集羣能夠擁有數百到數千臺不等的計算機。

1.2.2 超大規模集羣

　　「域」是計算機集羣的單位。在一個計算機集羣裏，管理節點處於核心地位，負責監督、維護整個集羣的運行，它的做用很是重要。管理節點實質也是一臺計算機，也受到自身CPU、內存、網絡接口等硬件性能的限制，隨着集羣內計算機數量的增長，它的管理負荷也在隨之升高。由於有這樣的限制，在實際部署時，一個集羣內的計算機數量是不可能無限增長的。根據咱們對多套硬件和數據應用的組合測試顯示，當集羣的節點數量達到3000至8000這個範圍時，會達到性能峯值，超過這個範圍，穩定性會大打折扣。可是在實際使用時，用戶對數據存儲和計算需求老是在持續增長的，這樣就產生一個矛盾：如何在保證集羣穩定運行的狀況下，仍然可以知足用戶更大規模存儲數據和計算數據須要？多域並行集羣就成爲這樣的一個選擇。

　　Laxcus的多域並行集羣是對現有單域集羣的升級和改進。經過把原來多個孤立運行的集羣鏈接起來，在這些集羣之上，創建更高一層的管理模型，造成一個兩級的管理架構。這個兩級架構的集羣，在Laxcus中被稱爲「主域集羣」，原來的集羣成爲它下屬的子集羣，這個集羣被稱爲「子域集羣」。子域集羣接受主域集羣的管理，同時向主域集羣反饋本身的運行狀態。按照Laxcus對集羣的設計定義，子域集羣必須集中在一個物理環境裏，主域集羣能夠跨地域分散存在。就是說，若是A子域集羣的機房在北京，B子域集羣的機房在廣州，天津機房是C主域集羣，只要它們之間可以經過網絡進行通訊，就能夠在天津的C主域集羣管理下協同工做。

　　經過這樣的組合，集羣的節點數量得到巨大的提高，極大地拓展了數據存儲、計算範圍，知足了當前包括將來一段時間內的須要。在跨域測試中，主域集羣管理下的計算機節點數量能夠達到百萬級的規模，數據存儲、計算能力能夠達到EB級別。

1.2.3 多用戶共享

　　Laxcus是多用戶系統，支持任意數量的用戶同時使用。每一個用戶可以在任何能夠聯網的位置，以遠程登陸的方式進入系統。區分用戶身份的惟一是帳號，帳號由用戶名和密碼組成。在一個系統裏，用戶名是惟一的，密碼能夠修改。創建帳號，以及後續的帳號管理工做由系統管理員或者擁有管理員權限的用戶實施。用戶在得到受權後，就擁了管理、操做數據的權力，能夠在本身的集羣空間裏，執行寫入、更新、刪除、計算操做。從這一點來講，用戶與數據的關係，更接近博客、推特等網絡應用，而與關係數據庫中的用戶、數據的定義有所區別。在邏輯空間上，系統中的每個用戶和用戶持有的數據都是獨立的，彼此不存在關聯，也不會發生衝突。另外，爲了充分發揮多集羣並行處理能力，實現大規模並行處理效果，Laxcus容許一個帳號同時使用多個地址登陸，同時進行多種數據操做。固然，這也是在得到操做受權和登陸驗證的前提下取得的。

1.2.4 低成本的硬件設備

　　大數據系統運行依賴於計算機集羣。部署計算機集羣，須要大量的計算機，以及鏈接它們網絡通訊設備，這對全部運營大數據的企業和機構來講，都是一筆龐大的開支。而大數據分佈處理和「以多勝強」的特色，更強調使用分佈算法和軟件設計所帶來的效能，對硬件設備自己並無太多的要求。因此，低價、性能穩定的硬件設備成爲首選。

　　具有這樣特色的硬件設備，目前有不少選擇，典型如PC架構的X86系統，還有移動架構的ARM系列，Laxcus都實現了支持。

　　實際上，可是不管上述哪款系列的計算機，在穩定性和可靠性上都不能和專業服務器相比，發生故障和宕機的可能性比服務器要大得多。針對這個狀況，Laxcus採用了一個簡單的辦法：冗餘，來解決這個問題。實現這項功能的要求是Laxcus具有實時的節點感知能力，當集羣內任何一個節點發生故障，都能很快被Laxcus捕獲到。在確認故障節點失效後，Laxcus將執行「隔離」方案，將故障節點從集羣中排除，而後從集羣中尋找一個新的備用節點，或者通知其它同類型的節點，來分擔故障節點的工做。排除故障的處理過程，都會同步通知給集羣的維護管理人員。

　　這項措施簡單且有效，在屢次故障處理中，都驗證了這個結論。

1.2.5 弱中心化管理

　　在Laxcus集羣裏，大量計算機被用來執行數據處理工做，管理節點作爲集羣的核心，起着監督和協調的做用。若是管理節點的工做內容過多或者複雜，勢必將增長管理計算機的工做負荷，下降處理效率，延長處理時間，不能對下級節點的請求及時作出反饋，減弱對集羣的監督和協調做用。在此前的幾個運行環境，上述狀況都分別發生過，是形成系統穩定性變差，影響集羣正常運行的重要緣由。因此，進一步分散管理節點的工做內容，減小計算開銷，下降工做負荷，是提升集羣穩定性的主要辦法。「弱中心化」思想即由此衍生而來。

鑑於此前的教訓，經過對1.x版本的運行統計和評估，在2.0版本中，管理節點的工做被壓縮到只有兩項內容：監聽節點心跳、記錄節點元數據。這兩項工做由子節點上傳，管理節點負責彙總和分析，網絡通訊量極少，內容簡單，計算量很是少，而且只有計算內存裏存儲和執行，不存在計算瓶頸和計算壓力，管理節點的工做負荷所以大幅度減小，從而提升了集羣的穩定性。目前由於管理節點問題形成的故障已經基本消失。

1.2.6 鬆耦合架構和系統羣

　　Laxcus被設計爲鬆耦合架構，與之對應的，咱們提出了「系統羣」（group of systems）的概念。「系統羣」能夠理解爲：在鬆耦合架構下爲適應複雜分佈運行環境而組織起來的工做模塊。這樣，在鬆耦合架構和系統羣之下，全部運行中的數據處理業務被視爲服務，能夠自由地加入和退出，分別以離散、獨立、弱依賴的形態存在。從人機交互界面開始，用戶的操做請求經過語句化的操做命令，被解釋成各類數據處理業務，業務的內容和含義由通訊雙方決定。集羣內的數據處理，採起按需分配的原則，根據不一樣的屬性分別創建，並遵循查找、發現、關聯、綁定、執行、撤銷的流程運行。集羣內的數據管理業務，也遵循一樣的流程，而且與數據處理業務保持非關聯和獨立性。

　　因爲鬆耦合和系統羣的這些特色，使Laxcus在應對愈來愈複雜的數據業務時，仍然具備極好的靈活性和敏捷性。可以在不影響既有業務的狀況下，快速創建新的業務。在保持強大處理能力的同時，還有足夠的裕度來知足將來擴展的須要。另外，鬆耦合和系統羣也下降Laxcus系統設計的複雜性和風險，對開發這種複雜的大型軟件系統助益甚多。

1.2.7 命令驅動的數據處理模式

　　命令驅動是鬆耦合架構下的一個「系統羣」子集，Laxcus數據處理都採用命令驅動的方式進行。系統運行過程當中，當收到用戶或者系統自身發出的任務請求時，這些請求被轉換爲相應的命令。命令根據任務提出的處理需求，結合集羣環境作出解釋，分散做用到集羣的不一樣節點上，執行數據處理操做。在表現形式上，命令經過網絡在各節點之間傳遞，造成一條先後關聯的命令鏈。在執行過程當中，每道命令鏈都是獨立的，嚴格按照預約的工做軌跡運行。當它們出如今計算機裏的時候，實質是一個個對內存佔用很小的「程序片斷」，而命令鏈之間處於徹底隔離的狀態。這種「被隔離」和內存佔用小的特色使它們之間沒有干擾，同時又容許大量存在，即便某一條命令鏈在運行過程當中發生故障，產生的影響也只限於這個命令鏈自己，不會出現波及效應。而且這種方式對排查故障緣由和故障源頭十分方便。尤爲重要的是，由於命令鏈的獨立性，在編寫代碼的時候，每條命令鏈能夠按照其自身的需求，被設計得很是細緻和有針對性。這些特色，使它在保證系統穩定運行的過程當中，起到重要的做用。

1.2.8 任務調度模型

　　命令被用來執行一道道具體的數據處理工做，分配、管理、監督這些命令運行的是「Invoke/Produce」任務調度模型。這是一種集成了多種軟硬件控制功能的委託管理模型，可以對計算機運行過程當中的各類資源，包括網絡流量、適配器、數據、CPU、內存、硬盤，進行實時的監督和隨機的調節。在命令執行過程當中，「Invoke/Produce」將持續檢查它們的運行狀態和對資源的使用狀況，當任何一項硬件資源的使用比率達到峯值或者接近臨界點時，危機管理機制就被啓動，依次對影響最大的執行任務採起限制措施，包括暫停或者休眠這樣的處理，以及要求它們釋放硬件資源等手段，來達到下降系統載荷的目的。而全部這一切工做的目的，都以保障系統穩定運行爲核心，儘量多地經過軟硬件的結合，爲每一道命令在它的運行過程當中，實現數據處理效率的最大化。

1.2.9 負載自適應控制

　　咱們已經部署了多個Laxcus系統，這些系統在運營過程當中，咱們一般不限制用戶發出的命令數量，這種忽略常常致使集羣的某個節點涌現大量的計算任務，發生超載現象。例如在此前的一次例行檢測時，就發現有一個計算節點並行着8000多個計算任務。面對如此龐大的計算壓力，若是任由這些現象持續下去而不加以控制，計算機宕機現象隨時可能發生。

　　在1.x版本中，負載控制是由管理節點來監視和協調控制的。在實地運行中顯示，這種處理方式雖然達到了協同節點工做和平衡集羣負載的目的，可是也存在不少隱憂，主要體現如下幾個方面：

　　1.每一個節點的負載狀況都被反饋到管理節點上，增長了管理節點的數據存儲量和計算量，不利於管理節點的弱中心化管理。

　　2. 負載的平衡和分配調度依賴於網絡通訊，當發生大面積超載時，每每也意味着網絡中存在大量數據傳輸，這時的通訊成功率會直線降低。實際上爲了保證通訊成功，就須要進一步加大了管理節點通訊量和工做負擔，這種狀況對管理節點穩定運行有巨大影響。

　　3. 負載控制要求實時處理，若是管理節點匯聚了大量任務請求，很難作到實時處理，延時將不可避免發生。同時下屬的節點收不到指令，超載會持續下去，宕機的可能性大幅增長。

　　4. 整套過載處理機制過於複雜，管理成本頗高，不符合簡單化的設計原則。

　　鑑於以上問題，2.0版本的負載控制，取消了以管理節點爲中心的協同處理方式，改成分散到每一個節點的自適應調節。這樣，當節點在執行計算任務的時候，也監視本身的運行負載。若是發生超載現象，能夠當即作出反應，中止分配新的計算任務，或者根據運行任務的權重和資源佔用比率，有選擇地要求某些任務進入暫停、休眠狀態，以達到即時發現即時處理，下降運行負載的目的。原來管理節點承擔的平衡運行負載的工做，交給網關節點來協調解決。新的負載處理方式避免了上述1.x版本的問題，同時簡化了負載管理的處理流程，提升了運行系統的穩定性。

1.2.10 以大規模的讀操做爲主，兼顧少許的寫操做

　　在咱們試驗室的集羣中，因爲固態硬盤（SSD）使用成本居高不下，承擔數據存儲工做的仍然是傳統的機械硬盤（溫徹斯特硬盤）。根據咱們的調查，這種狀況在不少運營的集羣中也一樣存在。另外咱們對多個集羣上的數據應用追蹤調查也顯示，因爲硬盤的處理效率遠遠滯後於CPU和內存，整個數據處理過程當中，75%-90%的時間被消耗在硬盤存取上，即便是固態硬盤，也僅比機械硬盤提升一個量級，仍然遠低於CPU和內存的處理能力。這種硬件之間的不匹配，致使硬盤成爲大數據處理過程當中的最主要瓶頸。因此，改善硬盤的處理效率，對提升大數據處理效率有立竿見影的效果，可是機械硬盤工做的特色，又使它與CPU、內存這些電子部件在運行效率上存在着巨大的差別。在這種條件下，儘量多地根據硬盤自身的特色，發揮出它的最大效能，成爲解決問題的重要辦法。

　　與此同時，咱們對許多用戶的數據應用追蹤中也發現，大數據處理過程當中，96%發生在檢索操做上，3%是添加數據，刪除和更新合計只佔不到1%的比例。這個現象促使咱們對數據存儲產生了不一樣以往的定位和思路，將數據存儲設計的重點圍繞着檢索展開，並據此制定瞭如下的執行策略：首先，爲保證大數量高頻度的檢索操做，結合到計算機內的CPU、內存、硬盤各主要工做部件的性能，在保證數據的持續吞吐性能上，流式處理效率最高。並行的數據寫入在進入存儲層面時，匯流爲串行模式。檢索操做的最終目標是硬盤，硬盤檢索受制於硬盤物理特性的影響，在數據計算過程當中，嚴重拖滯了總體性能的發揮，爲提升數據處理性能，須要在檢索前對數據進行優化，如關聯和聚湊，同時提供一批優化算法給用戶，使用戶能夠按照本身的意願去組織和檢索數據。刪除不改變數據自己，只對數據作無效記錄。數據更新分解爲刪除和添加兩步操做，目的在於簡化和內聚數據處理流程，同時避免發生屢次硬盤讀寫現象。

　　上述處理雖然改善了存取性能，可是不可能從根本改變硬盤慢的特色。若要使性能得到根本性的提高，必須跳過硬盤這個瓶頸，因此在2.0版本中增長了一套新的數據處理方案：讓內存代替硬盤，數據在網絡、內存、CPU之間流動，以接近CPU的速度運行。這種內存處理方案解決了硬盤存取慢的問題，使數據處理性能得到巨大的提高。根據咱們的測試評估結果，這個提高幅度在2個量級左右。在實際應用中，用戶若是有實時性的數據處理需求，且有足夠的內存作保證時，內存處理方案無疑是最佳的選擇。

1.2.11 數據存儲方案

　　以上只是針對硬盤存取作的優化，若是根據數據業務不一樣的需求特色，提供有針對性的數據存儲方案，數據處理效率還可以得到進一步的提高。

　　達成這個目標的辦法是實現兩套數據存儲方案：以「行」爲數據單元的行存儲模型（NSM），和以「列」爲數據單元的列存儲模型（DSM）。前者將數據處理的重點放在「行」上，每次操做的假定對象是一行中的多列數據，這方面有表明性的就是目前廣泛使用的數據庫業務。後者的數據處理重點是「列」，其特色是能夠對單一數據進行大批量的讀取操做，好比當前火熱的互聯網數據和數據倉庫應用。前者的數據操做量廣泛很少，然後者的數據操做量則很是巨大。在使用時，用戶能夠根據本身的業務需求任意選擇。根據咱們對現有用戶的追蹤調查，在他們的數據應用中，廣泛是採起混合使用兩種存儲模型的辦法來提升數據存取效率的。

1.2.12 流式處理

　　因爲硬盤自己物理性能與內存、CPU之間存在的巨大差別，在數據處理過程當中，實際上不管給硬盤作怎麼樣的優化設計，都只能減小而不能避免這種差別所形成的影響。要想徹底突破硬盤性能滯後所形成的數據處理效率低下的問題，惟一的解決辦法就是跳過硬盤這道瓶頸，只使用內存作數據存取，讓數據象「水流」同樣，在集羣的各節點的內存、CPU之間流動，使它們接近匹配的速率，進行傳遞、轉換、處理。這就是流式處理的由來。

　　在Laxcus 1.x版本中，流式處理是一項內測功能。在版本發佈後，收到愈來愈多用戶的快速處理要求，因此從新考慮後，在原來流式處理基礎上，通過調整修改，如今在2.0版本，把它正式公佈出來。兼顧到原來的數據處理方案，流式處理要求用戶在使用前顯示指定，系統會根據當時每臺計算機的資源使用狀況，有選擇地進行分配。這樣，當用戶要求流式處理的時候，數據處理過程將忽略掉硬盤，徹底在集羣的網絡、內存、CPU之間進行。

　　流式處理主要針對一些快速檢索和計算業務（數據存儲操做仍然要寫入硬盤，不在此列），典型如在線分析 、實時計算這類業務。根據咱們對多種流式處理的實地測試顯示，相較於基於硬盤的數據處理，基於內存的流式處理可帶來數十倍的效率提高。這種巨大的提高，將使一些用戶的數據處理業務發生根本性的改變。

1.2.13 即時存取

　　數據即時存取即一般所稱的「所存即所得」，這是衡量大數據系統可否支持實時處理的關鍵性標誌。其表現就是當數據保存到數據系統的分佈存儲環境後，可以當即生效而且可使用，而不是以後的某一個時段才能生效和使用。數據即時存取在Laxcus 0.1版本已經實現，又分別在1.0和2.0版本中進行優化，性能得到進一步提高。因爲實現了即時存取，能夠保證對整個主域集羣數據執行無遺漏的檢索，使Laxcus達到一般關係數據庫才具備的響應能力。即時存取很是重要，尤爲是商業用戶，是他們許多數據業務必須知足的一項功能。

1.2.14 支持事務

　　如今的大數據應用已經不侷限於互聯網，尤爲是隨着商業和科研行業的加入，開始呈現出需求多樣化的趨勢。其中有不少商業處理業務，爲了防止資源競用形成的數據錯誤，愈來愈須要得到事務支持。順應這一發展潮流，通過咱們仔細分析研究和設計，從Laxcus 2.0版本開始，提供事務處理能力。

　　Laxcus事務保持了數據庫對事務定義的基本原貌，即全部數據處理只能有兩種結果：成功或者失敗。若是失敗，數據將回滾到它的開始狀態。在此基礎上，結合大數據運行環境，避免由於事務形成數據處理效率降低，Laxcus事務具備如下特色：

　　1. 事務基於帳號。

　　2. 數據處理默認執行事務流程。

　　3. 事務分紅用戶、數據庫、表三種類型。

　　4. 事務操做分爲排它和共享兩種。

　　更多關於事務的說明請見第二章的介紹。

1.2.15 命名

　　在Laxcus體系裏，命名是一組由文字和數字組成的有意義的字符串，是網絡設備、分佈目錄、任務接口、數據資源等各類實體資源抽象化的表示，被應用在全部與數據處理有關環節上。經過命名，系統在運行過程當中，屏蔽了數據處理環節，與網絡地址、數據定位、數據檢索有關的工做，簡化了分佈計算方法和計算流程，使複雜的網絡運行環境變得簡單，同時減小和避免了由於網絡拓撲和數據分散可能致使的錯誤和漏洞。命名只在系統運行過程當中產生，被存儲在內存裏，在節點之間分發，可能隨時間和節點發生變化。每一個命名在系統中都是惟一的，不容許出現重疊現象。由於命名只用於系統內部環境，因此它對用戶是透明的，用戶沒必要在乎，也無需瞭解它的使用、執行狀況。

　　設計命名，對簡化系統架構設計，提升系統穩定性、保障系統安全有重要做用。

1.2.16 安全

　　在當今社會，由於信息產業的快速發展和信息安全管理的相對滯後，由網絡安全和數據安全引起的一系列重大事件可謂是層出不窮。當前大數據正在快速融入現代社會，如何保護好這些數據，保證數據只被它的持有人使用，而不會受到非法的監視和竊取，就益發顯得重要了。基於這樣的理念，又鑑於集羣的複雜運行環境，若是隻是作局部的改善，那麼將沒法知足總體的安全須要，咱們從Laxcus 2.0版本開始，歸入了全體系的安全管理設計和技術實現。它從用戶操做界面開始，一直延伸到數據存取層面，貫穿系統的每個環節，造成一道完整的安全屏障。在這道安全屏障後面，用戶執行安全的數據處理成爲可能。

　　不過任何事情都有它的兩面性。換一個角度實事求是地說，咱們雖然實現了全體系的安全管理設計，可是這個安全管理的取得是以犧牲集羣整體計算性能爲代價的。實際上，如今IT行業全部高安全度的技術實現背後，都存在着一個使用CPU進行密集計算的處理過程。尤爲對於也是數據密集和計算密集的大數據來講，會嚴重影響到CPU處理數據業務的能力，增長業務處理時間。考慮到這樣的狀況，咱們在進行安全設計時，對系統的不一樣環節進行了不一樣的安全管理規劃，設置了不一樣的安全等級，提供了不一樣的安全管理策略，其中大部分的安全管理工做，咱們都以配置文件的形式提供給集羣管理者，由他們根據本身業務需求作出取捨。可是無論怎麼樣，事實是，這套安全措施啓動後，不管是作爲私有云仍是公有云部署時，Laxcus都已經能夠承擔了。

1.2.17 分佈任務組件

　　Laxcus雖然提供了一個分佈的數據處理環境，可是大量個性化、與用戶業務有關的數據處理工做仍然須要用戶來完成。要達成這個目標，就須要程序員來編寫代碼，而後放到計算機集羣上去運行。分佈任務組件就是爲完成這個工做而設計的。

　　在1.x版本中，分佈任務組件只是一個集成了中間件和分佈計算技術，提供了熱發佈能力，在Laxcus架構下運行的模塊。在2.0版本中，咱們對分佈任務組件進行了大規模的調整修繕，從新定義了操做規範和API接口，增長了開發、部署、運行、管理等一系列功能，而且從原來的框架下剝離出來，已經獨立發展成爲一個完整的子系統，實現了全方位的數據處理和管理服務。

　　從設計上來講，Laxcus 2.0版本的分佈任務組件確實比1.x版本複雜了不少，可是對程序員來講則變得簡單了。在新的框架下，原來須要由程序員負責的網絡通訊、遠程存取、分佈操做等代碼被所有屏蔽掉，歸併到系統管理範圍內。新架構只留下了數據輸入輸出接口給程序員，程序員能夠沒必要再去考慮複雜的分佈處理流程，只須要遵循開發規範，調用API接口，象操做本地方法同樣，專一於本身的業務功能實現就能夠了。經過本次對分佈任務組件的簡化修改完善，咱們但願在減小程序員工做量和運行錯誤的同時，也可以爲程序員快速開發和部署分佈任務組件提供幫助。

1.2.18 人機交互語言

　　出於簡化數據處理過程、提升數據處理效率、令人機交互界面更加友好等緣由，咱們設計和開發了分佈描述語言（Distributed Description Language）。這是一種專門針對大數據用戶和集羣管理者設計的類天然語句高階語言，由許多命令組成。命令採用英文語句的語法風格，由使用者經過終端輸入，也能夠嵌入到驅動程序裏使用，語法解釋器負責解釋，轉換成計算機指令後，分發到集羣上執行。分佈描述語言的核心要旨是簡單，咱們但願可以藉助分佈描述語言，使用戶在沒必要了解複雜的分佈計算體系和計算流程的前提下，經過簡單的交互語句，就可以得到管理和操縱大數據的能力。這種簡化所帶來的效果，對全部使用者，不管是集羣管理者仍是普通的大數據用戶來講，都是很是重要的。同時，作爲對大數據的補充，也爲了方便用戶從數據庫轉向大數據環境，咱們在分佈描述語言裏面全面兼容SQL，包括SQL語言最主要的「INSERT、SELECT、DELETE、UPDATE」語句，以及JOIN語句、SQL函數、SQL數據類型、和其它的管理語句等。截止到目前，Laxcus分佈描述語言仍在發展中，咱們但願經過與你們的努力，共同完善它。