大資料行業發展到今天，它創造的價值和帶來的社會效應，大家已經看得很明白，同時很多問題和不足也暴露出來，特別是hadoop能夠提供的資料處理能力，現在已經挖掘到極限，但是現在各行業對資料的儲存和計算需求，似乎卻沒有停止的跡象。在最近的一次大資料論壇上，大家開始討論下一代大資料系統和系統標準，藉此機會，我們laxcus大資料實驗室表達了自己的看法，提出了4s標準，得到與會者的普遍贊同和肯定。回來後，覺得這個話題應該再說說，所以藉著csdn這個平台，和諸位談談我們眼中的下一代大資料系統和4s標準。
概述地說一下4s標準，就是：「超大規模、跨地域、簡單、安全」。這4項標準的首個英文本母都是「s」，所以我們把它稱為4s標準。很不巧，和四代戰鬥機的4s標準重名了。。
下面從4s標準來談我們眼中的下一代大資料系統。
1. 超大規模
「規模」這個話題要從hadoop說起。諸位應該都知道，現在市面上大資料產品，基本都屬於hadoop系列，要不就是與hadoop做了各種繫結。hadoop能夠提供的資料處理能力，計算機節點數量在「千台級「，資料儲存量在」pb量級「。再往上，hadoop將很難支撐。即使勉強維持，穩定性和可靠性也難以保證。而經常接觸網際網路業務，或者做各種科學計算的兄弟們應該有這樣的感觸：當下的資料應用需求是越來越多，需要完成的資料計算量是越來越大。hadoop設計於十年前，就象資料庫的程式設計師們沒想到後來的大資料應用，當初的hadoop設計者們大概也沒料到今天的資料應用會是這個情況吧。而且隨著未來各種大規模計算業務的進一步增長，hadoop現有的處理能力將無法保障這種增長需要。所以，當前的資料處理規模還要進一步擴大，保守的估計， 起碼應該能夠支撐未來二十年的資料處理需要。在這樣的乙個目標下，大資料系統的工作指標應該是：計算機節點數量達到「百萬臺」級，資料儲存和計算規模達到「eb」量級。只有這樣乙個裕度，我們才有可能適應未來資料處理業務的需要。
2. 跨地域
「跨地域」要從去年的一次事故說起。大家應該都知道，2023年8月份，天津發生了一起大**。在這次事故中，有多家it企業被涉及，其中就有我們後來這位客戶。這次事故，他們的伺服器損失了一大半，更糟糕的是資料丟失了，這可是比伺服器更大的損失。用ceo原話說：伺服器壞了花錢換一台就是了，但是資料毀掉就再也找不回來了。這家企業原來用的是hadoop集群，被集中部署在乙個機房裡，如果hadoop當時能夠分散到多個地域部署，然後用網路連線，形成乙個多地域的並行集群和資料冗餘，就不會有後來的損失。這也是這家企業找到我們的原因，要求用我們的laxcus重新部署他們的大資料集群，實現跨地域和多集群協同工作。由此可見，且不說協同計算這樣的需求，僅僅在冗災管理中，跨地域有多麼重要。
3. 簡單
「簡單」是我們對下一代大資料軟體乙個綜合性描述。概括地說，就是做到盡可能簡化一切操作，實現「傻瓜」式處理。 這個標準的提出，緣於上面提到的下一代大資料系統超大規模化，在這種環境中，如果每減少乙個環節處理，都可能獲得數倍的效率提公升。具體到實現要求上，應該有以下這樣幾個指標。
3.1 高度整合
現在市面上流行的幾個大資料軟體，嚴格地說，都不是完整的產品，而是功能模組，它們只是完成了大資料體系中的一兩個功能而已。這樣的產品交到使用者手上，當他需要乙個完整的大資料服務的時候，就必須了解這些軟體各自的功能屬性，才能夠操作它們，把它們粘合到一起，然後才能組織和部署起大資料集群。這對所有使用者來說都是乙個巨大的考驗，徒然增加了軟體使用門檻。這個問題有多嚴重，有過集群部署和維護經驗的人應該是最有感觸的。另外，還有乙個問題是，這些軟體來自不同的開發團隊，每個團隊設計開發自己軟體的時候，著眼點必然是自己的產品需求，而大資料是乙個整體，使用者普遍需要的是完整功能的大資料產品，而不是其中幾個功能模組。所以在部署和運營集群的時候，就會產生這樣的矛盾：如何組織和搭配這些模組，做好各模組之間的銜接和相容，以及更少的冗餘？實際上，很多時候，這個問題都推給了使用者，成為了使用者使用大資料成本的一部分。
所以，下一代的大資料產品，應該是全體系全功能的設計，實現深度嵌合和一站式服務。當乙個使用者需要部署乙個大資料集群的時候，只用懂得安裝軟體和配置即可，而不必去深入了解軟體的各種特性，乃至被迫參與到軟體開發中來。相比於多個團隊開發的功能模組，全體系的設計開發還有乙個好處：可以有效減少模組拼接和組裝造成的冗餘，在保證穩定性和處理效率上也是最好的。對使用者來說，當乙個軟體實現了原來n個模組組合才能達到的全部功能，省略了自己做軟體裝配工的時間，簡化了流程，用這樣的軟體，何樂而不為呢？
3.2 易操作
易維護是對集群管理員而言。如果閣下是一位機房或者大資料中心的管理員，應該有這樣的感受：要管理少則幾百台，多則數千台的計算機，每台計算機不知道什麼時候發生故障，發生故障後，還要排查和排除，工作量著實太大。而且隨著下一代大資料系統的超大規模化，如果管理模式不發生改變，集群管理員將會不堪工作重負。所以，下一代大資料系統的乙個重要要求，就是減輕管理員的工作負擔，提高大資料系統的自適應能力，以及部分實現系統的自維護管理。即使執行系統在發生故障後，也能夠做到迅速定位和顯式地提供故障源頭，而不是讓集群管理員去查詢故障。從另乙個方面說，這種自動化的管理，也有助於提高集群的穩定執行。普通的日常管理工作，也應該是通過終端，輸入類似sql這樣的命令就可以完成。
3.4 易程式設計
易程式設計是對程式設計師提出的。實際上，程式設計師目前是整個大資料鏈上最苦逼的一群人，他們要在終端使用者、資料業務、計算機集群之間，用程式設計搭建起一道橋梁，來實現整個大資料鏈條的最終運轉。憑心而論，目前的分布式程式設計，的確比早期簡化了很多，但是放到普通的程式設計師面前，仍然過於複雜。其中諸如介面化、可移植、操作規範等問題，都沒有實現標準化，在這些條件沒有完備之前，程式設計師的程式設計擔負將難以減輕。而大資料行業的快速發展，卻在要求程式設計師具備快速程式設計能力。但是目前這種矛盾的現狀，顯然不能滿足要求，這同時也是造成大資料行業人才奇缺的乙個因素之一。把這些情況疊加一起，目前乙個可行的解決辦法，應該是採用類似ejb、corba這樣的中介軟體方案，把大資料程式設計元件化。程式設計師通過呼叫規範的介面，然後加入一些資料業務規則，就可以完成工作。以此實現快速設計、快速程式設計、快速投入部署的目的。
4. 資料安全
最後說一下資料安全。資料安全對當今社會的影響有多大，看一看這些年發生了的一些案例就知道了，例如維基解密、**登這樣的事件，用**形容也不為過。我們現在已經步入後**登時代，如果仍然忽視網路和大資料的安全問題，那麼下乙個安全事件很可能在我們身邊發生。所以，從這個角度來說，安全在下一代大資料系統中的重要性，可能要遠超過上述幾個指標。但是回頭看看現在的這些大資料軟體，包括hadoop，安全工作做得實在乏善可陳。
在我們的理念裡，下一代大資料系統中，安全應該是全方位的，能夠深入資料處理的每乙個環節，而且在使用者這個層面上，安全還應該是可以制訂的，就是允許讓使用者自己設計安全方案，定義安全規則，然後加入到大資料系統中來。只有這樣，在網際網路絡和雲計算大行其道的今天，資料安全才能夠有所保證。
以上是我們對下一代大資料系統的一些粗淺看法。順便夾帶個私貨：《laxcus大資料管理系統2.0》，其中有不少與上述介紹相關的內容。歡迎與諸位同仁交流、**。
laxcus大資料管理系統架構
laxcus安全管理模型
大資料及下一代基礎設施
什麼是大資料？對於大資料的概念，這裡給出的定義是超出現有資料庫系統處理能力的資料。由於過快的資料產生速度，以及規模巨大的資料量，這就要求使用合適的系統來處理它們。大資料的價值主要可以分為兩種 資料分析 開發新產品。大資料分析能夠揭露消費行為及趨勢，如消費者如何受到同齡人的影響。對開發新產品而言，通過...
下一代狀態管理系統 Ractor
乙個基於 action 設計的狀態管理工具 npm i ractor 複製 ractor 僅僅包含三個基本概念，您只需要熟悉這三樣東西就能徹底掌握 ractor 的用法。import from ractor export const system new system counter 複製 類似 r...
DataWorks 下一代智慧型資料工場
阿里巴巴從2009年開始從hadoop搭建資料平台體系,資料工場與以前體系一脈相承,有了資料工場後,大家不用再自建資料工場,資料平台會建立乙個雲服務。從自建水電煤廠 水電煤成為基礎設施服務 從自建it資料中心 使用雲計算服務，雲計算本質上解決了運維問題 從自建大資料平台 使用雲資料平台服務 資料工場...