大數據處理技術與區塊鏈技術 -- 相關技術概念

　　下學期導師接了一個973軍工項目，會用到大數據處理、分佈式存儲等相關技術。整體來講，仍是與本身以後想要從事的區塊鏈領域有些相關性的，能夠爲本身以後的求職簡歷增長些相關項目經驗。下面，咱們來分析幾個區塊鏈工程師的任職要求，來看看相關性。

 

 

---

　　分析以上崗位，咱們很容易發現，許多區塊鏈開發工程師的應聘要求：對分佈式數據庫、分佈式系統、分佈式存儲 熟悉並由相關經驗者優先！

　　下面對相關概念進行下梳理：

Redis

Redis是一個key-value存儲系統。和Memcached相似，它支持存儲的value類型相對更多，包括string(字符串)、list(鏈表)、set(集合)、zset(sorted set --有序集合)和hash（哈希類型）。這些數據類型都支持push/pop、add/remove及取交集並集和差集及更豐富的操做，並且這些操做都是原子性的。在此基礎上，redis支持各類不一樣方式的排序。與memcached同樣，爲了保證效率，數據都是緩存在內存中。區別的是redis會週期性的把更新的數據寫入磁盤或者把修改操做寫入追加的記錄文件，而且在此基礎上實現了master-slave(主從)同步。

Redis 是一個高性能的key-value數據庫。 redis的出現，很大程度補償了memcached這類key/value存儲的不足，在部 分場合能夠對關係數據庫起到很好的補充做用。它提供了Java，C/C++，C#，PHP，JavaScript，Perl，Object-C，Python，Ruby，Erlang等客戶端，使用很方便。

 

KV數據庫

KV數據庫速覽

　　這部分旨在簡短的介紹K-V數據庫，更詳細的描述能夠參考文章下方的引用部分。

　　K-V存儲系統是最簡單的數據庫類型之一。幾乎全部的編程語言都帶有內置的K-V存儲功能。好比C++中STL的map，Java的HashMap，Python的dictionary。K-V數據庫一般包含下列接口：

• Get(key): 獲取以前以"key"做爲標識存儲的數據，若"key"不存在則獲取失敗。
• Set(key,value): 將"value"存儲內存中，其標識符爲"key"，以便咱們以後能夠用"key"來獲取數據。若是在"key"下已經有數據了，那麼原數據將被替換。
• Delete(key): 刪除"key"標識下的數據。 

　　大多數底層的實現都使用了hash table或者是自平衡的樹結構（好比B-Tree和紅黑樹）。有時候數據太大了沒法放在內存中，或者爲了防止宕機必須把數據持久化，這種狀況下，就必須使用文件系統來存儲。 

　　K-V數據庫是NoSQL運動的一部分，它重組了沒有徹底使用關係數據庫中概念的衆多數據庫，Wikipedia articles on NoSQL  總結了這些數據庫的主要特色：

• 不使用SQL查詢語言
• 可能不對ACID規範提供徹底支持
• 可能提供分佈式，可容錯的架構

K-V數據庫和關係型數據庫

　　不一樣於關係型數據庫，K-V數據庫並不清楚存儲數據的值，並且也沒有像MySQL和PostgreSQL中schema的概念。這也就意味着它不能像關係型數據庫同樣經過

使用帶where的SQL語句來過濾並查詢所存數據的部份內容。若是你不知道該從哪查詢，你須要遍歷全部的key值，找到對應的value，對其進行過濾，最終只保留你

想要的那部分數據。這樣以來計算量會很是大，同時也意味着只有在key已知的狀況下，K-V數據庫才能保證高性能，不然其性能明顯不足。（注：有一些K-V數據庫

支持結構化存儲，並且有域索引）所以，雖然在絕對訪問速度方面K-V數據庫優於關係型數據庫，但須要已知key值的要求限制了其應用場景。

 

NoSQL數據庫（Not Only SQL）

　　NoSQL(NoSQL = Not Only SQL )，意即「不只僅是SQL」，是一項全新的數據庫革命性運動，早期就有人提出，發展至2009年趨勢愈加高漲。NoSQL的擁護者們提倡運用非關係型的數據存儲，相對於鋪天蓋地 的關係型數據庫運用，這一律念無疑是一種全新的思惟的注入。

　　NoSQL，泛指非關係型的數據庫。隨着互聯網web2.0網站的興起，傳統的關係數據庫在應付web2.0網站，特別是超大規模和高併發的SNS類型的web2.0純動態網站已經顯得力不從心，暴露了不少難以克服的問題，而非關係型的數據庫則因爲其自己的特色獲得了很是迅速的發展。NoSQL數據庫的產生就是爲了解決大規模數據集合多重數據種類帶來的挑戰，尤爲是大數據應用難題。

雖然NoSQL的流行與火起來才短短几年的時間，可是不能否認，如今已經開始了第二代運動。儘管早期的堆棧代碼只能算是一種實驗，然而如今的系統已經更加的成熟、穩定。不過如今也面臨着一個嚴酷的事實：技術愈來愈成熟——以致於原來很好的NoSQL數據存儲不得不進行重寫，也有少數人認爲這就是所謂的2.0版本。該工具能夠爲大數據創建快速、可擴展的存儲庫。

 

NoSQL數據庫的四大分類表格分析

分類	Examples舉例	典型應用場景	數據模型	優勢	缺點
鍵值（key-value）	Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB	內容緩存，主要用於處理大量數據的高訪問負載，也用於一些日誌系統等等。	Key 指向 Value 的鍵值對，一般用hash table來實現	查找速度快	數據無結構化，一般只被看成字符串或者二進制數據
列存儲數據庫	Cassandra, HBase, Riak	分佈式的文件系統	以列簇式存儲，將同一列數據存在一塊兒	查找速度快，可擴展性強，更容易進行分佈式擴展	功能相對侷限
文檔型數據庫	CouchDB, MongoDb	Web應用（與Key-Value相似，Value是結構化的，不一樣的是數據庫可以瞭解Value的內容）	Key-Value對應的鍵值對，Value爲結構化數據	數據結構要求不嚴格，表結構可變，不須要像關係型數據庫同樣須要預先定義表結構	查詢性能不高，並且缺少統一的查詢語法。
圖形(Graph)數據庫	Neo4J, InfoGrid, Infinite Graph	社交網絡，推薦系統等。專一於構建關係圖譜	圖結構	利用圖結構相關算法。好比最短路徑尋址，N度關係查找等	不少時候須要對整個圖作計算才能得出須要的信息，並且這種結構不太好作分佈式的集羣方案。

詳情參考：https://baike.baidu.com/item/NoSQL/8828247

 

SPARK（計算引擎）

　　Apache Spark 是專爲大規模數據處理而設計的快速通用的計算引擎。Spark是UC Berkeley AMP lab (加州大學伯克利分校的AMP實驗室)所開源的類Hadoop MapReduce的通用並行框架，Spark，擁有Hadoop MapReduce所具備的優勢；但不一樣於MapReduce的是——Job中間輸出結果能夠保存在內存中，從而再也不須要讀寫HDFS，所以Spark能更好地適用於數據挖掘與機器學習等須要迭代的MapReduce的算法。

　　Spark 是一種與 Hadoop 類似的開源集羣計算環境，可是二者之間還存在一些不一樣之處，這些有用的不一樣之處使 Spark 在某些工做負載方面表現得更加優越，換句話說，Spark 啓用了內存分佈數據集，除了可以提供交互式查詢外，它還能夠優化迭代工做負載。

　　Spark 是在 Scala 語言中實現的，它將 Scala 用做其應用程序框架。與 Hadoop 不一樣，Spark 和 Scala 可以緊密集成，其中的 Scala 能夠像操做本地集合對象同樣輕鬆地操做分佈式數據集。

儘管建立 Spark 是爲了支持分佈式數據集上的迭代做業，可是實際上它是對 Hadoop 的補充，能夠在 Hadoop 文件系統中並行運行。經過名爲 Mesos 的第三方集羣框架能夠支持此行爲。Spark 由加州大學伯克利分校 AMP 實驗室 (Algorithms, Machines, and People Lab) 開發，可用來構建大型的、低延遲的數據分析應用程序。

　　 Apache Spark是一個圍繞速度、易用性和複雜分析構建的大數據處理框架。

　　與Hadoop和Storm等其餘大數據和MapReduce技術相比，Spark有以下優點：

首先，Spark爲咱們提供了一個全面、統一的框架用於管理各類有着不一樣性質（文本數據、圖表數據等）的數據集和數據源（批量數據或實時的流數據）的大數據處理的需求。

Spark能夠將Hadoop集羣中的應用在內存中的運行速度提高100倍，甚至可以將應用在磁盤上的運行速度提高10倍。

Spark讓開發者能夠快速的用Java、Scala或Python編寫程序。它自己自帶了一個超過80個高階操做符集合。並且還能夠用它在shell中以交互式地查詢數據。

除了Map和Reduce操做以外，它還支持SQL查詢，流數據，機器學習和圖表數據處理。開發者能夠在一個數據管道用例中單獨使用某一能力或者將這些能力結合在一塊兒使用。

 

詳情請參考：http://dataunion.org/13853.html

 

分佈式存儲

　　分佈式存儲是一種數據存儲技術，經過網絡使用企業中的每臺機器上的磁盤空間，並將這些分散的存儲資源構成一個虛擬的存儲設備，數據分散的存儲在企業的各個角落。

 

詳情請參考：https://baike.baidu.com/item/%E5%88%86%E5%B8%83%E5%BC%8F%E5%AD%98%E5%82%A8/5557030?fr=aladdin

 

Docker容器

　　Docker 容器是一個開源的應用容器引擎，讓開發者能夠打包他們的應用以及依賴包到一個可移植的容器中，而後發佈到任何流行的Linux機器上，也能夠實現虛擬化。容器是徹底使用沙箱機制，相互之間不會有任何接口（相似 iPhone 的 app）。幾乎沒有性能開銷,能夠很容易地在機器和數據中心中運行。最重要的是,他們不依賴於任何語言、框架包括系統。

 

高併發、分佈式系統特色：

如今不少高談闊論，高併發，大流量，分佈式，SOA，名詞一大堆每每抓不住要點，對於熟悉的人來講，言之無味，而對不熟悉的人來講，更相似大師講法，除了增長神祕感外，讓人愈加無從瞭解。

其實這些問題，本質是成本收益的平衡，嚴格說，這其實就是所謂技術最關注的問題， 
正由於沒有銀彈，沒有統一的解決方案，因此任何系統都要結合業務自身特色，與軟件，硬件平衡一塊兒考慮完整的解決方案。

能夠從一個典型的電商平臺來分析，

假如，從無到有，有足夠人力時間，並且目標也很是明確，一個支持海量商家，海量用戶的，海量商品的平臺，應該怎麼設計？

1.前端接入 
只要高併發，即使所有是靜態頁面，哪怕只有一個文件，海量的併發鏈接也是必須首先解決的。 
這個方案相對比較成熟，能夠經過負載均衡，簡單增長web服務器，承載瀏覽器鏈接。單臺服務器nginx能承載的併發鏈接大體5000到數萬， 
根據優化狀況，能夠簡單算出到底須要多少臺機器。在用戶使用瀏覽器的狀況下，這裏幾乎沒有取巧的地方。 
若是不能接受則只能考慮專用客戶端，經過長連接，甚至UDP這類協議，來本身實現。

2.一旦請求所有接入了，就須要考慮處理問題 
若是應用很單一，那麼應用服務器就能夠簡單擴展，相似接入的web服務器，單臺時間能處理的請求數，和單位時間總請求數，便可算出須要多少應用服務器，固然通常場景每每與用戶相關，這裏最重要的就是要解決，應用服務器無狀態的問題，這樣才能無縫擴展，任何web接入的請求，能夠隨便找一個空閒的應用服務器丟過去。

典型的，能夠把用戶相關的信息保存到專門的狀態服務器中，請求時僅僅經過cookie提交一個令牌，用令牌從狀態服務器得到對應用戶的信息。

狀態服務器，有一個天生的優點，就是各個用戶數據之間每每隔離的，當單臺服務器抗不住時，簡單增長狀態服務器，而在應用服務器上簡單根據用戶id或令牌，計算出對應的狀態服務器便可。

狀態服務器能夠充分利用各類NoSQL服務，好比典型的Redis，這裏系統設計與業務需求就要綜合考慮了。

A 若是偶爾丟失狀態，能夠接受，redis便可配置成不持久化。此時效率最高。 
萬一狀態服務器掛了，應用端，簡單該向請求到新狀態服務器，用戶從新登陸便可，不會中斷太長服務。

B 若是但願儘可能少的丟失狀態，那麼redis就應該按期持久化，並作複製。 
這樣某臺狀態服務器掛了，能夠根據狀況，選擇恢復主服務器，中斷一小段時間，數據最完整，或備用狀態服務器接管，快速恢復服務，數據可能多丟失一點點。 
大部分用戶徹底感知不到，個別用戶從新登陸便可。業務中斷也很小。

若是有可能，作成自動切換，會更高效率，可是必定要注意，不是什麼都自動的好，若是沒有積累，你寫的程序，每每沒法考慮大量意外，在「正常」的異常狀況下可能切換很好，可是更多的異常狀況下，有可能更糟糕。

C 若是要求絕對不能丟失狀態，容許中斷服務一段時間，redis能夠配置成每次都持久化。持久化的硬盤也作冗餘甚至作成共享存儲。 
若是出問題，由於數據都沒有丟失，系統重啓或更換其餘硬件，全部狀態便可恢復。可是顯然此時redis處理能力將大大減弱。

D 若是要求絕對不能丟失狀態，儘可能減小中斷服務， 
redis能夠適當本身改造，將數據成功推送到備份服務器上，且備份服務器持久化以後，再返回成功。那麼理論上，當主服務器掛掉，能夠馬上切換到備份服務器上，而不丟失數據，用戶也基本感知不到變化。固然如何判斷主的掛掉，這裏仍是有大量陷阱，處理很差，反而更多的中斷服務。

若是去問一個不太瞭解技術的產品，這個用戶狀態到底什麼要求，他極可能認爲D是理所固然的，由於他徹底沒有成本意識。 
實際上對於大部分系統，A,B都是更佳的選擇，不管對於開發者，運維者，仍是最終用戶。

A,B簡單，所以可靠，不容易出其餘問題，開發成本低，運維成本低，最終更穩定，致使最終用戶更滿意。

只有用戶量足夠多，技術團隊，運維團隊足夠強，有能力實現更好的D，這時候D纔是對產品來講更好的方案。

3.應用的拆分 
到2，實際上解決了絕大多數系統的併發問題，由於能夠簡單的經過增長硬件來擴容。 
可是當應用原來越複雜以後，讓一個應用服務器包含全部的服務，是很困難的，從運維成本上考慮，必然有很大浪費，由於每一個服務使用頻率不同。 
一些，不太經常使用的服務，可能所有集中到兩臺服務器上就足夠了，這樣從其餘大量服務器上將這些服務去掉，至關於整個系統節省大量內存。

而從開發角度，也必然是10個小項目每一個10人維護，比100人維護一個大項目更容易，所以從開發角度也要求拆分應用。

拆分應用，雖然有些技術輔助手段，但實際主要仍是依賴業務自己的分析，技術僅僅是輔助，好比解決各個應用系統之間數據同步問題，跨系統RPC問題等等。

而流行的SOA，則會努力將服務拆成更小而獨立的服務，一方面提升功能複用，另外一方面便於開發維護，也方便運維管理。

可是這裏有一個誤區，認爲服務拆分得越小越好，其實，從理論上，服務怎麼拆分，傳統的面向對象已經指明瞭方向，低耦合，高內聚， 
說直白些，就是要善於封裝，面向對象歷來不是類越多，方法越多越好。

所謂SOA治理，關鍵仍是業務梳理！

4.持久化問題 
若是說上面各類問題，目前技術均可以給出比較理想的解決方案，那麼持久化瓶頸問題，卻始終是最大的問題所在。 
前端接入服務器，應用服務器，均可以很好的橫向擴展，而狀態服務器，也由於其特殊性（持久化能夠不太嚴格，數據之間無關聯），也能夠比較好的橫向擴展。

而典型的聯機交易系統，老是要求數據一致性的，沒有產品會說偶爾用戶帳戶上少1分錢，是能夠接受的。

傳統的銀行系統數據庫系統，會選擇更快的專有共享存儲，多機互備，將數據實實在在的寫到可靠存儲裏，存儲經過raid方式來保證冗餘防止單硬盤故障， 
當主機故障時，不管軟硬件，簡單將共享存儲掛到備機上，來完成切換。

從安全角度，這種方案是很是高的，可是有兩個問題，一是價格昂貴，二是系統容量仍是有限。

這種方案，其實就是目前大多數雲平臺提供給中小系統的解決方案，只是用雲存儲代替了傳統昂貴的共享存儲。 
若是你的系統能夠用雲平臺的數據庫系統或者強勁單機來提供，其實這就是一個合理的好方案。不管你是租用雲主機，仍是本身弄個物理機。

可是若是系統規模足夠大，雲平臺提供的單機沒法知足，或者其雲數據庫也沒法知足（或者僅僅是由於價格過高），那麼仍是要想辦法本身來實現。

首先，存在這樣一個大數據庫相似傳統單機數據庫那樣，能夠無限橫向擴展嗎？ 
在我看來是不存在的，由於傳統單機數據庫，重要的就是提供嚴格的事務支持，多機分佈式事務，要想簡單橫向擴展，至少目前看來是很困難的。

CAP原則指出在一個分佈式系統中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性），三者不可得兼。 
而三者如何權衡，仍是要依賴業務！而不是技術。

固然目前由於技術問題P是沒法避免的，因此問題每每簡化成CA的選擇。

對於電商系統，從業務角度，A每每不能捨棄，而C則能夠根據業務設計成最終一致性。

好比，購買業務，若是用戶帳戶錢一扣，他的訂單就應該是支付成功，單機上這點經過事務很容易實現，可是對於分佈式系統，若是作這樣的要求，用戶未必高興，由於假設訂單系統出了些問題，訂單沒法更新狀態，那麼此時只能將用戶成功的支付也取消掉！

對於一個龐大的分佈式系統，要保證每一個系統都正常是不可能的，因此即使放棄A，容許任何一系統故障，整個系統暫停以保證數據一致性，從實際角度看也是不現實的。更不要說，參與系統越多分佈協調成本越高，最終多是即使全部系統都正常，其處理速度也徹底沒法接受了。

反之，若是支付成功了，容許訂單狀態暫時沒變，就能夠等待訂單系統恢復後，再將其狀態修改成成功。經過業務設計，避免分佈式事務，不光獲得最大限度的A，也提升了整個系統的處理能力。 具體細節可參看《多數據源之間不使用分佈式事務實現異步最終一致性》

用戶會不會容忍這個短暫的數據不一致呢？錢付了，訂單狀態卻沒馬上改。

會的，其實現實中他們常常這樣，之前去匯款時，本身的錢馬上交了出去，可是對方卻沒馬上收到，過幾天后，對方纔收到，或者對方不在了，匯款再退回。

固然另一些最終一致卻不會被接納，好比，若是存在一段時間，訂單先支付成功，用戶餘額卻沒扣。

此時用戶便可用沒扣的餘額去購買其餘商品，這是系統巨大的漏洞。

因此必定是要和業務結合才能解決現實問題，也所以，在持久層這裏，不要指望一個完整的分佈式強數據一致性的系統，而應該學習現實世界的實現方式，分析業務，找到能夠接受的最終數據一致性方案。

只要能接受最終數據一致性方案，那麼就能夠將存儲系統拆分紅多個相對獨立的子系統，每一個子系統內都是傳統的強一致性嚴格事務實現，而各個系統之間則經過相對鬆散的消息機制來互動。任何一個子系統均可以故障，操做能夠在其餘系統被cache，要麼隨後恢復，要麼超時取消。

其實很典型的例子就是第三方支付系統，每一個系統都會對接，顯然這是兩個徹底獨立的系統,甚至全部者也不一樣，可是對於支付業務的確很好的實現了，是一個真正意義上的分佈式系統。

總結

對於一個電商平臺，能夠大體描述一下其基礎架構， 
1.一個接入的web集羣，用來接入連接 
2.一個狀態保存系統 
3.拆分紅多個相對獨立的應用系統，每一個系統都無狀態，可橫向擴展。 
4.根據應用和數據規模，將數據拆分紅多個相對對立的存儲系統 
能夠是相似：用戶系統，訂單系統，支付系統這樣按功能拆分， 
也能夠再拆分紅：用戶1系統，用戶2系統…這些系統功能徹底一致，只是保存了不一樣用戶羣的數據

其中每一個存儲系統本身負責容錯，不一樣存儲系統經過應用系統經過內部消息來銜接，老是假定其餘系統可能故障，也就必須考慮恢復或衝正。

這一切，尤爲是3和4顯然更多依賴於業務的分析與設計，那麼從技術角度，最終的系統就是一個徹底分佈式的系統，能夠支持幾乎無限的擴展。

而某些技術，熱門中間件，框架，其實僅僅是一個技術手段，並無想象的那麼重要。