大數(shù)據(jù)學(xué)習(xí)常見問題

Hadoop幾個主要產(chǎn)品的架構(gòu)都是一主多從。HDFS，一個NameNode，多個DataNode；MapReduce 1，一個JobTracker，多個TaskTracker；Yarn，一個ResourceManager，多個NodeManager。Storm，一個Nimbus，多個Supervisor；Spark，一個Master，多個Slave。

大數(shù)據(jù)因?yàn)橐獙?shù)據(jù)和計(jì)算任務(wù)進(jìn)行統(tǒng)一管理，所以和互聯(lián)網(wǎng)在線應(yīng)用不同，需要一個全局管理者。而在線應(yīng)用因?yàn)槊總€用戶請求都是獨(dú)立的，而且為了高性能和便于集群伸縮，會盡量避免有全局管理者。

所以我們從Hadoop中可以學(xué)到大數(shù)據(jù)領(lǐng)域的一個架構(gòu)模式，也就是集中管理，分布存儲與計(jì)算。

學(xué)習(xí)方法

學(xué)習(xí)新知識遵循5-20-2法則：

5分鐘的時間了解這個新知識的特點(diǎn)、應(yīng)用場景、要解決的問題

如果5分鐘不能搞懂它要解決的問題，我就會放棄

20分鐘理解它的主要設(shè)計(jì)原理、核心思想和思路

20分鐘沒有理解它的設(shè)計(jì)思路，我也會放棄

2個小時看關(guān)鍵的設(shè)計(jì)細(xì)節(jié)，嘗試使用或者做一個demo

2個小時還上不了手，我也會放一放

你相信我，一種真正有價值的好技術(shù)，你這次放棄了，它過一陣子還會換一種方式繼續(xù)出現(xiàn)在你面前。這時，再嘗試用5-20-2法則學(xué)習(xí)，也許就理解了。

實(shí)時計(jì)算的結(jié)果，一般都存儲在什么庫上?便于實(shí)時展示

實(shí)時計(jì)算的結(jié)果一般通過兩種方式輸出：

寫入到數(shù)據(jù)庫里，和離線計(jì)算的結(jié)果組成全量數(shù)據(jù)供業(yè)務(wù)使用

通過Kafka之類的實(shí)時隊(duì)列給業(yè)務(wù)，比如你提到的監(jiān)控展示

HDFS水平伸縮的文件讀寫速度比起垂直伸縮的速度理論上會慢很多，如何保證速度?

并不會慢，影響文件讀寫速度的是磁盤的速度。同樣的數(shù)據(jù)量、同樣類型的磁盤，HDFS能將數(shù)據(jù)分布在更多的服務(wù)器和磁盤，肯定比單機(jī)的幾塊磁盤速度更快。

HDFS常用的使用方式是結(jié)合MapReduce或Spark大數(shù)據(jù)計(jì)算框架進(jìn)行計(jì)算，這些計(jì)算框架會在集群中啟動很多的分布式計(jì)算進(jìn)程同時對HDFS上的數(shù)據(jù)進(jìn)行讀寫操作，數(shù)據(jù)讀寫的速度非常快，甚至能支撐起Impala這樣的準(zhǔn)實(shí)時計(jì)算引擎。

互聯(lián)網(wǎng)應(yīng)用中，用戶從手機(jī)或者PC上發(fā)起一個請求，請問這個請求數(shù)據(jù)經(jīng)歷了怎樣的旅程?完成了哪些計(jì)算處理后響應(yīng)給用戶?

一個請求從Web或者移動App上發(fā)起，請求的URL是用域名標(biāo)識的，如taobao.com，而HTTP網(wǎng)絡(luò)通信需要得到IP地址才能建立連接，所以先要進(jìn)行域名解析，訪問域名解析服務(wù)器DNS，得到域名的IP地址。

得到的這個IP地址其實(shí)也不是淘寶的服務(wù)器的IP地址，而是CDN服務(wù)器的IP地址，CDN服務(wù)器提供距離用戶最近的靜態(tài)資源緩存服務(wù)，如圖片、JS、CSS。若CDN：

有請求需要的資源就直接返回

若無，再把請求轉(zhuǎn)發(fā)給真正的淘寶數(shù)據(jù)中心服務(wù)器。

請求到達(dá)數(shù)據(jù)中心后，首先處理請求的是負(fù)載均衡服務(wù)器，它會把這個請求分發(fā)給下面的某臺具體服務(wù)器處理。這臺服具體的服務(wù)器通常是反向代理服務(wù)器，也緩存著大量靜態(tài)資源，淘寶也會把一些通常是動態(tài)資源的數(shù)據(jù)，比如我們購物時經(jīng)常訪問的商品詳情頁，把整個頁面緩存在這里：

若請求的數(shù)據(jù)在反向代理服務(wù)器，就返回

若無，請求將發(fā)給下一級的負(fù)載均衡服務(wù)器

這一級的負(fù)載均衡服務(wù)器負(fù)責(zé)應(yīng)用服務(wù)器的負(fù)載均衡，將請求分發(fā)給某Java Web容器處理。在Java Web容器之前，還前置了一臺Nginx服務(wù)器，做一些前置處理。

應(yīng)用服務(wù)器根據(jù)請求，調(diào)用后面的微服務(wù)進(jìn)行邏輯處理。若為寫請求，如下單，應(yīng)用服務(wù)器和微服務(wù)之間通過MQ進(jìn)行異步操作，避免對DB造成太大壓力。

微服務(wù)若在處理過程中需讀取數(shù)據(jù)，會去緩存服務(wù)器查找，若沒找到，就去查DB或NoSQL，甚至搜索引擎，得到數(shù)據(jù)后，計(jì)算，將結(jié)果返給應(yīng)用服務(wù)器。

應(yīng)用服務(wù)器將結(jié)果包裝成前端需要格式后返回，經(jīng)過前面的訪問通道，最后到達(dá)用戶發(fā)起請求的地方，完成一次互聯(lián)網(wǎng)請求的旅程。

架構(gòu)圖表示的流程：

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。