大資料時代，各種分布式框架層出不窮，儲存方面有: hdfs, es, hbase... 計算方面有:mr, spark, flink等等。如何根據業務選取合適的技術方案，相信一定是大家都比較關心的問題，這次的分享就簡單談一談我對現在比較主流的分布式框架的理解，希望能和大家一起學習進步。
mysql、hbase、elastcisearch是目前比較流行的儲存方式。mysql廣泛應用於oltp業務，支援事務，提供二級索引。hbase面向海量資料儲存，有良好的寫效能，讀效能稍差，不支援事務和二級索引。es適用於複雜查詢和全文檢索，不支援事務。接下來我們將通過儲存方式和讀寫方式這兩個方面來分析他們的特點。
常見的儲存方式有行存和列存兩種。行存的形式如上圖，一條一條記錄連續存放，這種方式比較適合於線上，比如一次性讀取檢索到的資料的全部資訊。列儲存適合於一些資料分析的業務，這種情況下不需要全部資訊，只需特定欄位下的相關資料。
與前兩種方式不同，es儲存的是倒排索引，適用於全文檢索的業務。如圖所示原始文件的內容在儲存的時候首先會進行分詞，然後這些分詞會被組合成字典，每個字典後有對應的鍊錶，鍊錶儲存的就是該分詞所在的文件id。這樣就可以通過一些關鍵字快速的定位到文件資訊。
mysql的讀寫方式是典型的1+4，其特點在於所有的讀寫都有可能是隨機io。而hbase的每張表都是由很多region組成，寫模式下資料首先會被寫入記憶體，當記憶體到達某個閾值之後會進行刷盤生成乙個小檔案，任何的更新、插入、刪除操作都被當做寫操作，都是順序寫記憶體然後刷到盤中。讀的時候是通過元件定位到指定region，然後遍歷region上的所有小檔案。這相當於犧牲了讀效能來提高寫效能。es的寫入類似於hbase，同樣是先寫記憶體然後刷盤，不過效能上不如hbase，因為es在建立倒排索引的時候不僅要做分組，還有評分、壓縮之類的操作。雖然es寫入效能較差，但正因為在寫入的時候做了這些複雜的計算，所以獲得了很強的檢索功能。
上圖對mysql、hbase、es之間的特點進行了詳細的總結。關於一致性的問題，這裡需要提一下。es寫入資料的時候會建立索引，這個操作會耗費一定的時間，因此es中資料從寫入到可以檢索到預設的時間間隔為1s。
解決了資料儲存問題之後，接下來就是發現資料價值，這就要利用到計算框架。對此我們主要**兩方面，離線計算和實時計算。
移動計算優於移動資料是mapreduce的早期思想，因此當map任務在hdfs節點啟動的時候，資料不用遷移就可以直接在資料中跑計算任務，當然reduce階段還是要做彙總。需要注意的是即使記憶體足夠，map階段的資料也還是會落盤。
對於上圖中的 ，相信大家一眼就能求出解。而計算機求解的時候首先會將該方程轉換成下面的形式，然後假設乙個初始值代入方程右邊獲得新的x值，接著進行不斷的迭代，當上乙個x值和當前值的差值小於規定閾值的時候迭代結束。在ai和資料分析領域其實都會涉及到這樣的解方程形式以及迭代計算。如果用mapreduce來實現的話，每一次迭代都會啟動乙個mapreduce任務，相對來說代價還是很大的。
針對以上兩點問題，spark提供了一種新的rdd資料結構，如果資料可以存放在記憶體中就不會進行落盤。另外它還提供了更好的api，不僅是任務排程，在程式編寫方面也更加友好。
在講實時計算之前需要明確一點，離線計算不等於批量計算，實時計算也不等於流式計算。離線和實時指的是資料處理的延時，批量和流式則是資料處理的方式。其實流式計算是可以完成批量計算的工作的，之所以還有批量計算框架，是因為流式計算的設計難度遠高於批量計算。google的流式計算負責人有過這樣的觀點——乙個設計良好的流式系統可以完全取代批量系統。
目前實時計算有這樣幾個難點，分別是吞吐、exactly once、資料亂序。下面會分別介紹storm、spark、flink針對這三點提出的解決方案。
上圖是storm統計詞群的過程，首先由spout從輸入源中讀取一條資料，然後上游bolt接收資料進行分詞，接著下游bolt根據key值接收資料並將資料入庫，最終得到統計結果。
如果中間的分詞系統掛了，storm會提供乙個acker任務，每個bolt在計算完之後都會向acker傳送乙個ack資訊用來宣告任務執行成功，當整個流程中所有的ack資訊都傳送給acker之後，acker就認為這條資訊處理成功並返回成功訊息給輸入源。這種場景下ack資訊會隨著資料量增長，因此特別影響storm的效能，這也是早期我們認為流式計算的吞吐量不如批量計算的乙個重要原因。
如果在處理的過程中某個計算節點掛了，而另外的節點卻入庫成功，這時acker會認為該條記錄已處理失敗進而重發，導致db中的部分資料會重複累加。
spark streaming針對以上兩個問題進行了優化。首先是關於吞吐，不再是一條一條處理而是小批量的處理，預設間隔為1秒，這1秒內所接收到的資料會被生成為乙個batch然後向下游傳送，也就是通過擴大粒度來提高吞吐。
我們都知道離線計算本來就是精準計算架構，spark streaming內部是利用spark的邏輯來保證exactly once。
flink不再是一條一條資料做ack，而是在每段資料之間打上checkpoint，然後針對每段資料進行確認，如果任務掛掉就會在上一次成功的checkpoint點重新恢復資料。通過這種方式將流式計算和容災較好的結合起來。
流式計算會有乙個視窗的概念，比如上圖中就有3個5秒視窗，方框中的編號代表事件發生的時間。可以看到第3秒的時候有兩條訪問事件，由於網路的延遲問題很有可能這3秒的資料會被分到第二個5秒視窗中，導致資料不正確。造成這樣結果的原因是早期的流式框架在處理資料的時候，將接收資料的時間認為是資料產生的時間。這裡延伸出里了兩個概念，event time——資料真正產生的時間，process time——系統處理該資料的時間。對此最直觀的解決方案就是讓資料攜帶自身產生時的時間戳，流式系統以該時間戳為基準。
大資料時代，傳媒行業如何與大資料結合？
新興網際網路 發展迅猛，各種新技術 新思維 新模式不斷湧現。大資料時代正在推動整個傳媒行業進行深刻變革，要想在這種變革中獲得優勢必須構建創新思維體系，充分利用傳統 和大資料時代的特點，發展壯大傳媒產業。內容變革 大資料時代引入了 資料新聞 這一概念，即利用資料來分析新聞事件，這一點在財經類新聞中尤為...
如何選擇乙個合適的大資料視覺化工具
高質量的視覺化工具對資料分析是必不可少的。資料視覺化工具是一種應用軟體，它幫助使用者以視覺化和圖形化的格式顯示資料，並提供資料的完整輪廓。餅圖 曲線 熱圖 直方圖 雷達 蜘蛛圖只是視覺化的一小部分，這些方法可以簡單地表示資料並顯示特徵和趨勢。要使資料分析真正有價值和有洞察力，就需要高質量的視覺化工具...
大資料時代 資料該如何保護？
隨著資料發掘的不斷深入和在各行業應用的不斷推進，大資料安全的 脆弱性 逐漸凸顯，國內外資料洩露事件頻發，使用者隱私受到極大挑戰。而且在大資料環境下隱私洩露的危險，不僅僅在於洩露本身，還在於基於資料對下一步行動的 和判斷，因此大資料時代的隱私保護儼然成為大資料應用發展的一項重要課題。目前隱私資料洩露的...