對於大資料的學習，很長一段時間，都覺得非常迷茫。不知道具體該學習什麼！進而導致知識的知識點挺多，而自己所會的內容都不能夠形成很好的體系，進而為自己的職場加分。而最近一直在學習相關大數的架構知識，進而具體到乙個廠商。這樣反而自己學的很快，總結一下前段時間的學習，溫故而知新!!!
首先，大資料開始做為概念開始進入公眾並在實際業務中落地是在13年。從一項技術的發展來看，這項技術會在18年形成乙個很好的閉環。而在此期間，不管你是不是大資料的專案，在這五年內，只要冠以大資料名稱都可以獲益。
所以，大資料第一件能做的事就忽悠！不管你是不是大資料的專案，只要是你懂一點分布式，知道一點hadoop,spark。就可以去說我可以承接相關的專案，這是相關冒險的。因為當你不能夠對大資料有乙個整全的理解，而是靠著在實際工程中不斷的學習進而再去指導並優化工作。這樣做無異於事倍功半！所以回歸到題目的方向，就是如何從技術架構的解度去豐富你的知識。
1，儲存
大資料，顧名思義。就是你的資料量很大，傳統的資料有excel，txt，word........剛開始這些還可以儲存到硬碟上。但多到一定程度，勢必會影響你開機的速度，這時，就要引入資料庫的概念來儲存。而你用資料庫來存資料時，就又要涉及要你與資料庫的對話語言－－sql語句。
單點，結構化的資料完成了以後，你的工作效率得到了很大的提公升。相鄰城鎮的人看著這樣不錯的時候，就也開始了相應的部署。但資料庫內容還是要和總部鏈結的。這樣就形成了我們常說的分布式儲存。
隨著經濟的不均衡發展，各種地區推出的營銷活動不同。所要儲存使用者的資訊也不同。這樣就造成了傳統結構化的儲存效率下降，轉而改變為使用者單一id+相關行為的非結構化資料的儲存。
好了，存完了資料，放到那裡呢，放在硬碟上的起名叫hadoop,放在記憶體中的就叫spark.
2,計算
任何的資料都是要參於到運算當中來的，而在運算的過程中是一定要呼叫cpu的，而傳統的高帥富的大型機在高效能計算上是有優勢的。可在大資料如海水一般的湧來時，這些高帥富的大型機就不好起到作用了。
還是老祖宗的智慧型過人，分而治之。這是治水的思路，也是解決乙個高帥富面對眾多請求時不知所措的茫然。在技術上，用100臺pc或小型機來分而治之所湧來的資料。然後再統一匯報解決情況。這個也就是大資料裡邊常說的那句話：100個窮吊絲相當於乙個高富帥！這是第一種計算方案。
那還有一種是什麼呢！類似於周伯通的左右互博擊，你想想，你一台pc可以做的事情，我再加一顆cpu，是不是就相當於模擬出來兩套。而這樣計算的好處是可以將資料分類處理，而這一方面，在技術上是通過虛擬化來實現的。
3，可視
講完了前邊的基礎之後，我們就來看看資料展現，資料的展現有許多種，而這一部人是需要**人員有一些藝術細胞的（什麼，沒有！那藝術細菌也行）。
畢竟，要將你所計算的結果呈現現大眾面前。相應的邏輯清楚就一點就顯得非常重要。在這方面，建議多看一些其他人的優秀作品。更重要的是你要具備一些心理學的知識，資料的突顯及策略的把控。可以說，大資料專案的成敗基本上就是在可視的這一塊是否能產生效果了。
好了，這次就先總結這麼多。以後學習過程中，再慢慢總結！
從架構的角度看Kafka 二
從架構角度看kafka 一 我們第一次接觸可能都是作為訊息傳輸來學，作用很簡單，就是生產者與消費者解耦，非同步操作。kafka是乙個很好地選擇，它有很高的吞吐量以及可行性。在大資料時代，這些使用者的行為資訊是很寶貴的，kafka很適合做這件事，他可以收集多台機器的使用者行為，進行資料分析和機器學習等...
從技術的角度審視專案計畫
乙個好的專案計畫需要在合適的時候計畫處理以下技術內容 技術類文件的準備 編碼規約 是否定義了完善的編碼規約，是否在內部講解了編碼規約的內容。文件注釋規約 是否定義了詳細的檔案注釋規約，檔案頭注釋格式定義，屬性，方法注釋定義，修改，刪除的注釋方法，版本公升級定義等。常見 問題彙總 是否將常見的問題收集...
從技術的角度審視專案計畫
乙個好的專案計畫需要在合適的時候計畫處理以下技術內容 技術類文件的準備 編碼規約 是否定義了完善的編碼規約，是否在內部講解了編碼規約的內容。文件注釋規約 是否定義了詳細的檔案注釋規約，檔案頭注釋格式定義，屬性，方法注釋定義，修改，刪除的注釋方法，版本公升級定義等。常見 問題彙總 是否將常見的問題收集...