你好，我是李智慧。專欄的模塊一已經更新完畢，按照計劃，今天是我們答疑的時間。首先要感謝訂閱專欄的同學給我留言，每條留言我都看過了，有些留言對我的啓發也很大，希望同學們可以多多跟我互動。我在每個模塊都設置了一個答疑的主題，想跟你聊聊我在學習這個模塊時的心得體會。另外，我也會貼出一些同學的疑問，跟你聊聊我的想法。
今天的主題是：我們能從Hadoop學到什麼？
最近幾年，我跟很多創業者交流，發現創業最艱難的地方，莫過於創業項目難以實現商業價值。很多時候技術實現了、產品做好了，然後千辛萬苦做運營，各種補貼、各種宣傳，但是用戶就是不買賬，活躍差、留存低。
很多時候，我們不是不夠努力，可是如果方向錯了，再多努力似乎也沒有用。阿里有句話說的是“方向對了，路就不怕遠”，雷軍也說過“不要用你戰術上的勤奮，掩蓋你戰略上的懶惰”。這兩句話都是說，要找好方向、找準機會，不要爲了努力而努力，要爲了目標和價值而努力。而王興則更加直言不諱：“很多人爲了放棄思考，什麼事情都幹得出來”。
說了那麼多，我們再回過來看看Hadoop的成長曆程。從2004年Google發表論文，到2008年Hadoop成爲Apache的開源項目，歷時4年。當時世界上那麼多搜索引擎公司似乎都對這件事熟視無睹，Yahoo、百度、搜狐（是的，搜狐曾經是一家搜索引擎公司），都任由這個機會流失。只有Doug Cutting把握住機會，做出了Hadoop，開創了大數據行業，甚至引領了一個時代。
所以，我們能從Hadoop中學到的第一個經驗就是識別機會、把握機會。有的時候，你不需要多麼天才的思考力，也不需要超越衆人去預見未來，你只需要當機會到來的時候，能夠敏感地意識到機會，全力以赴付出你的才智和努力，就可以脫穎而出了。
結合大數據來說，雖然大數據技術已經成熟，但是和各種應用場景的結合正方興未艾，如果你能看到大數據和你所在領域結合的機會，也許你就找到了一次出人頭地的機會。
另一方面，你看一下Hadoop幾個主要產品的架構設計，就會發現它們都有相似性，都是一主多從的架構方案。HDFS，一個NameNode，多個DataNode；MapReduce 1，一個JobTracker，多個TaskTracker；Yarn，一個ResourceManager，多個NodeManager。
事實上，很多大數據產品都是這樣的架構方案：Storm，一個Nimbus，多個Supervisor；Spark，一個Master，多個Slave。
大數據因爲要對數據和計算任務進行統一管理，所以和互聯網在線應用不同，需要一個全局管理者。而在線應用因爲每個用戶請求都是獨立的，而且爲了高性能和便於集羣伸縮，會盡量避免有全局管理者。
所以我們從Hadoop中可以學到大數據領域的一個架構模式，也就是集中管理，分佈存儲與計算。我在思考題裏提出如何利用個人設備構建一個存儲共享的應用，很多同學也都提到了類似的架構方案。
最後我想說，使用Hadoop，要先了解Hadoop、學習Hadoop、掌握Hadoop，要做工具的主人，而不是工具的奴隸，不能每天被工具的各種問題牽着走。最終的目標是要超越Hadoop，打造適合自己業務場景的大數據解決方案。
正好提到了每期文章後留給你的思考題，在這裏也分享一下我是如何設置思考題的。
關於思考題，你會發現，我留的思考題很多都是和當期內容沒有直接關聯的，甚至和大數據無關的。它們或是相似的問題場景，或是有類似的解決思路，或是引申的一些場景。
其實我是希望你在學習大數據的時候，不要僅侷限在大數據技術這個領域，能夠用更開闊的視野和角度去看待大數據、去理解大數據。這樣一方面可以更好地學習大數據技術本身，另一方面也可以把以前的知識都融會貫通起來。
計算機知識更新迭代非常快速，如果你只是什麼技術新就學什麼，或者什麼熱門學什麼，就會處於一種永遠在學習，永遠都學不完的境地。前一陣子有個鬧得沸沸揚揚的事件，有個程序員到GitHub上給一個國外的開源軟件提了個Issue“不要再更新了，老子學不動了”，就是一個典型例子。
如果這些知識點對於你而言都是孤立的，新知識真的就是新的知識，你無法觸類旁通，無法利用過往的知識體系去快速理解這些新知識，進而掌握這些新知識。你不但學得累，就算學完了，忘得也快。
所以不要糾結在僅僅學習一些新的技術和知識點上了，構建起你的知識和思維體系，不管任何新技術出現，都能夠快速容納到你的知識和思維體系裏面。這樣你非但不會懼怕新技術、新知識，反而會更加渴望，因爲你需要這些新知識讓你的知識和思維體系更加完善。
關於學習新知識我有一點心得體會想與你分享。我在學習新知識的時候會遵循一個5-20-2法則，用5分鐘的時間瞭解這個新知識的特點、應用場景、要解決的問題；用20分鐘理解它的主要設計原理、核心思想和思路；再花2個小時看關鍵的設計細節，嘗試使用或者做一個demo。
如果5分鐘不能搞懂它要解決的問題，我就會放棄；20分鐘沒有理解它的設計思路，我也會放棄；2個小時還上不了手，我也會放一放。你相信我，一種真正有價值的好技術，你這次放棄了，它過一陣子還會換一種方式繼續出現在你面前。這個時候，你再嘗試用5-20-2法則去學習它，也許就會能理解了。我學Hadoop實際上就是經歷了好幾次這樣的過程，才終於入門。而有些技術，當時我放棄了，它們再也沒有出現在我面前，後來它們被歷史淘汰了，我也沒有浪費自己的時間。
還有的時候，你學一樣新技術卻苦苦不能入門，可能僅僅就是因爲你看的文章、書籍本身寫的糟糕，或者作者寫法跟你的思維方式不對路而已，並不代表這個技術有多難，更不代表你的能力有問題，如果換個方式、換個時間、換篇文章重新再看，可能就豁然開朗了。
接下來我們看一下同學們的具體問題。
我的判斷是是大數據與業務的結合，在每個垂直領域、每個垂直領域的細分領域，將大數據和業務場景結合起來，利用大數據發現新的業務增長點。
對技術人員而言，其實挑戰更高了，一方面要掌握大數據的知識，這正是專欄想要輸出的；另一方面，要掌握業務知識，甚至得成爲業務領域的專家，能發現業務中可以和大數據結合的點，利用大數據和業務結合構建起技術驅動業務的增長點，這需要你在業務中有敏銳的觀察力和領悟力。
實時計算的結果一般通過兩種方式輸出，一個是寫入到數據庫裏，和離線計算的結果組成全量數據供業務使用；一個是通過Kafka之類的實時隊列給業務，比如你提到的監控展示。關於大數據怎麼和業務結合，我會在專欄第四模塊與你討論，請繼續關注。
事實上並不會慢，影響文件讀寫速度的是磁盤的速度。同樣的數據量、同樣類型的磁盤，HDFS可以將數據分佈在更多的服務器和磁盤上，肯定比單機上的的幾塊磁盤速度更快。
HDFS常用的使用方式是結合MapReduce或者Spark這樣的大數據計算框架進行計算，這些計算框架會在集羣中啓動很多的分佈式計算進程同時對HDFS上的數據進行讀寫操作，數據讀寫的速度是非常快的，甚至能支撐起Impala這樣的準實時計算引擎。
我在專欄第8期留了一個思考題，我看了大家的留言，發現很多同學可能沒有意識到互聯網處理一個請求的複雜性，這裏我來談談我的理解。
這個思考題其實並不簡單，考察的是一個典型的互聯網應用，比如淘寶的架構是怎樣的。簡化描述下，這個過程是：
首先，一個請求從Web或者移動App上發起，請求的URL是用域名標識的，比如taobao.com這樣，而HTTP網絡通信需要得到IP地址才能建立連接，所以先要進行域名解析，訪問域名解析服務器DNS，得到域名的IP地址。
得到的這個IP地址其實也不是淘寶的服務器的IP地址，而是CDN服務器的IP地址，CDN服務器提供距離用戶最近的靜態資源緩存服務，比如圖片、JS、CSS這些。如果CDN有請求需要的資源就直接返回，如果沒有，再把請求轉發給真正的淘寶數據中心服務器。
請求到達數據中心後，首先處理請求的是負載均衡服務器，它會把這個請求分發給下面的某臺具體服務器處理。
這臺服具體的服務器通常是反向代理服務器，這裏同樣緩存着大量的靜態資源，淘寶也會把一些通常是動態資源的數據，比如我們購物時經常訪問的商品詳情頁，把整個頁面緩存在這裏，如果請求的數據在反向代理服務器，就返回；如果沒有，請求將發給下一級的負載均衡服務器。
這一級的負載均衡服務器負責應用服務器的負載均衡，將請求分發給下面某個具體應用服務器處理，淘寶是用Java開發的，也就是分發被某個Java Web容器處理。事實上，淘寶在Java Web容器之前，還前置了一臺Nginx服務器，做一些前置處理。
應用服務器根據請求，調用後面的微服務進行邏輯處理。如果是一個寫操作請求，比如下單請求，應用服務器和微服務之間通過消息隊列進行異步操作，避免對後面的數據庫造成太大的負載壓力。
微服務如果在處理過程中需要讀取數據，會去緩存服務器查找，如果沒有找到，就去數據庫查找，或者NoSQL數據庫，甚至用搜索引擎查找，得到數據後，進行相關計算，將結果返回給應用服務器。
應用服務器將結果包裝成前端需要的格式後繼續返回，經過前面的訪問通道，最後到達用戶發起請求的地方，完成一次互聯網請求的旅程。如果用架構圖表示的話，就是下面的樣子。
這張圖來自我寫的《大型網站技術架構：核心原理與案例分析》一書，對互聯網實時業務處理感興趣的同學，歡迎閱讀這本書。大數據的數據來源最主要的就是網站數據，瞭解網站架構對學習大數據、用好大數據也很有幫助。
最後，我在今天的文章裏貼了陳晨、虎虎、您的好友William、lyshrine、不求、Panmax、wmg、西貝木土的留言，我認爲是比較精彩很有深度的，也把它們分享給你，希望其他同學的思考也能對你有所啓發，也歡迎你給我留言與我一起討論。
