目錄：

1.典型需求

2.40K以上專家必備技能

3.項(xiàng)目中的迷宮場景部件制作

4.Hadoop生態(tài)核心原理

一、典型需求（互聯(lián)網(wǎng)公司）

二、40K以上專家必備技能

?

三、大數(shù)從業(yè)者角色分類

?

四、Hadoop生態(tài)核心原理

1.大數(shù)據(jù)整體畫像

• 數(shù)據(jù)流程

?

• 數(shù)據(jù)技術(shù)

2.大數(shù)據(jù)平臺整體畫像

• 大數(shù)據(jù)平臺邏輯劃分

數(shù)據(jù)相關(guān)的工具、產(chǎn)品和技術(shù)：比如批量數(shù)據(jù)采集傳輸?shù)?Sqoop 、離線數(shù)據(jù)處理的Hadoop 和Hive 、實(shí)時(shí)流處理的 Storm和 Spark 以及數(shù)據(jù)分析的R語言等。

數(shù)據(jù)資產(chǎn)：不僅包含公司業(yè)務(wù)本身產(chǎn)生和沉淀的數(shù)據(jù)，還包括公司運(yùn)作產(chǎn)生的數(shù)據(jù)（如財(cái)務(wù)、行政），以及從外界購買 交換或者爬蟲等而來的數(shù)據(jù)等。

數(shù)據(jù)管理：有了數(shù)據(jù)工具，也有了數(shù)據(jù)資產(chǎn)，但是還必須對它們進(jìn)行管理才能讓數(shù)據(jù)產(chǎn)生最大價(jià)值并最小化風(fēng)險(xiǎn)，因此數(shù)據(jù)平臺通常還包括數(shù)據(jù)管理的相關(guān)概念和技術(shù)，如數(shù)據(jù)倉庫、數(shù)據(jù)建模、 數(shù)據(jù)質(zhì)量、數(shù)據(jù)規(guī)范、 數(shù)據(jù)安全和元數(shù)據(jù)管理等。如果你對大數(shù)據(jù)開發(fā)感興趣，想系統(tǒng)學(xué)習(xí)大數(shù)據(jù)的話，可以加入大數(shù)據(jù)技術(shù)學(xué)習(xí)交流扣扣君羊：522189307

• 從數(shù)據(jù)處理的時(shí)效性劃分

（1）離線數(shù)據(jù)平臺。

（2）實(shí)時(shí)數(shù)據(jù)平臺。

• 和離線數(shù)據(jù)平臺相關(guān)的技術(shù)

Hadoop 、Hive 、數(shù)據(jù)倉庫、 ETL 、維度建模、 數(shù)據(jù)邏輯分層等。

• 離線數(shù)據(jù)平臺的整體架構(gòu)

?

3.Hadoop 核心原理

（1）系統(tǒng)簡介

• 正是 Hadoop 開啟了大數(shù)據(jù)時(shí)代的大門，而大數(shù)據(jù)的發(fā)展也是和Hadoop 發(fā)展密不可的，甚至從某些方面來說大數(shù)據(jù)就是 Hadoop 。

• Hadoop 是一種分析和處理大數(shù)據(jù)的軟件平臺，是一個(gè)用 Java 語言實(shí)現(xiàn)的 Apache 的開源軟件框架，在大量計(jì)算機(jī)組成的集群中實(shí)現(xiàn)了對海量數(shù)據(jù)的分布式計(jì)算。

• Hadoop 采用 MapReduce 分布式計(jì)算框架，根據(jù) GFS 原理開發(fā)了 HDFS（分布式文件系統(tǒng)），并根據(jù) BigTable 原理開發(fā)了 HBase 數(shù)據(jù)存儲系統(tǒng)。

• Yahoo、Facebook、Amazon，以及國內(nèi)的百度、阿里巴巴等眾多互聯(lián)網(wǎng)公司都以 Hadoop 為基礎(chǔ)搭建了自己的分布式計(jì)算系統(tǒng)。

• Hadoop 是一個(gè)基礎(chǔ)框架，允許用簡單的編程模型在計(jì)算機(jī)集群上對大型數(shù)據(jù)集進(jìn)行分布式處理。

• 用戶可以在不了解分布式底層細(xì)節(jié)的情況下，輕松地在 Hadoop 上開發(fā)和運(yùn)行處理海量數(shù)據(jù)的應(yīng)用程序。低成本、高可靠、高擴(kuò)展、高有效、高容錯(cuò)等特性讓 hadoop 成為最流行的大數(shù)據(jù)分析系統(tǒng)。

（2）Hadoop 生態(tài)里的最核心技術(shù)

• HDFS：Hadoop 分布式文件系統(tǒng)，它是Hadoop 的核心子項(xiàng)目。

• MapReduce ：Hadoop 中的 MapReduce 是一個(gè)使用簡單的軟件框架，基于它寫出來的應(yīng)用程序能夠運(yùn)行在由上千個(gè)商用機(jī)器組成的大型集群上，并能可靠容錯(cuò)地并行處理 TB 級別的數(shù)據(jù)集。

• Hive ：是建立在 Hadoop 體系架構(gòu)上的一層 SQL抽象，使得數(shù)據(jù)相關(guān)人員使用他們最為熟悉的 SQL 語言就可以進(jìn)行海量數(shù)據(jù)的處理、分析和統(tǒng)計(jì)工作，而不是必須掌握 Java 等編程語言和具備開發(fā)MapReduce 程序的能力。HiveSQL 際上先被 SQL 解析器進(jìn)行解析然后被 Hive 框架解析成一個(gè)MapReduce 可執(zhí)行計(jì)劃，并按照該計(jì)劃生成 MapReduce 任務(wù)后交給 Hadoop 集群處理。

（3）HDFS

• 文件系統(tǒng)

文件系統(tǒng)是操作系統(tǒng)提供的磁盤空間管理服務(wù)，該服務(wù)只需要用戶指定文件的存儲位置及文件讀取路徑，而不需要用戶了解文件在磁盤上是如何存放的。對于我們編程人員也是這樣的。

但是當(dāng)文件所需空間大于本機(jī)磁盤空間時(shí)，應(yīng)該如何處理呢？

加磁盤，但是加到一定程度就有限制了。

加機(jī)器，即用遠(yuǎn)程共享目錄的方式提供網(wǎng)絡(luò)化的存儲，這種方式可以理解為分布式文件系統(tǒng)的雛形，它可以把不同文件放入不同的機(jī)器中，而且空間不足時(shí)可繼續(xù)加機(jī)器，突破了存儲空間的限制。

?

• 傳統(tǒng)的分布式文件系統(tǒng)---架構(gòu)

?

• 傳統(tǒng)的分布式文件系統(tǒng)---訪問過程

• 傳統(tǒng)的分布式文件系統(tǒng)帶來的問題

各個(gè)存儲結(jié)點(diǎn)的負(fù)載不均衡，單機(jī)負(fù)載可能極高。例如，如果某個(gè)文件是熱門文件，則會有很多用戶經(jīng)常讀取這個(gè)文件，這就會造成該文件所在機(jī)器的訪問壓力極高。

數(shù)據(jù)可靠性低。如果某個(gè)文件所在的機(jī)器出現(xiàn)故障，那么這個(gè)文件就不能訪問了，甚至?xí)斐蓴?shù)據(jù)的丟失。

文件管理困難。如果想把一些文件的存儲位置進(jìn)行調(diào)整，就需要查看目標(biāo)機(jī)器的空間是否夠用，并且需要管理員維護(hù)文件位置，在機(jī)器非常多的情況下，這種操作就極為復(fù)雜。

• HDFS 的基本原理

?

• HDFS 的體系結(jié)構(gòu)（一主多從）

?

• HDFS 的文件讀取

?

• HDFS 的文件寫入

?

• HDFS 異常處理之NameNode

（1） 兩個(gè)核心文件

FsImage文件：

a.FsImage用于維護(hù)文件系統(tǒng)樹以及文件樹中所有的文件和文件夾的元數(shù)據(jù)

b.FsImage文件沒有記錄塊存儲在哪個(gè)數(shù)據(jù)節(jié)點(diǎn)。而是由名稱節(jié)點(diǎn)把這些映射保留在內(nèi)存中，這個(gè)信息單獨(dú)在內(nèi)存中一個(gè)區(qū)域維護(hù)，當(dāng)數(shù)據(jù)節(jié)點(diǎn)加入HDFS集群時(shí)，數(shù)據(jù)節(jié)點(diǎn)會把自己所包含的塊列表告知給名 稱節(jié)點(diǎn)，此后會定期執(zhí)行這種告知操作，以確保名稱節(jié)點(diǎn)的塊映射是最新的

EditLog文件：

操作日志文件EditLog中記錄了所有針對文件的創(chuàng)建、刪除、重命名等操作

（2）名稱節(jié)點(diǎn)的啟動

在名稱節(jié)點(diǎn)啟動的時(shí)候，它會將FsImage文件中的內(nèi)容加載到內(nèi)存中，之后再執(zhí)行 EditLog文件中的各項(xiàng)操作，使得內(nèi)存中的元數(shù)據(jù)和實(shí)際的同步，存在內(nèi)存中的元數(shù)據(jù)支持客戶端的讀寫操作。

接收所有datanodes上的文件塊信息匯報(bào)，退出安全模式。

（3）名稱節(jié)點(diǎn)的問題

名稱節(jié)點(diǎn)運(yùn)行期間，HDFS的所有更新操作都是直接寫到EditLog中，久而久之，EditLog件將會變得很大，這對名稱節(jié)點(diǎn)運(yùn)行沒有什么明顯影響的，但是，名稱節(jié)點(diǎn)重啟的時(shí)候，需要先將FsImage里面的所有內(nèi)容映像到內(nèi)存中，然后再一條一條地執(zhí)行EditLog中的記錄，當(dāng)EditLog文件非常大的時(shí)候，會導(dǎo)致名稱節(jié)點(diǎn)啟動操作非常慢，而在這段時(shí)間內(nèi)HDFS系統(tǒng)處于安全模式，一直無法對外提供寫操作，影響了用戶的使用。

名稱節(jié)點(diǎn)壞掉了。

（4）解決方案之一

?

（5）解決方案之二（Hadoop HA）

?

（6）HDFS 異常處理之DataNode

• 數(shù)據(jù)節(jié)點(diǎn)出錯(cuò)

每個(gè)數(shù)據(jù)節(jié)點(diǎn)會定期向名稱節(jié)點(diǎn)發(fā)送“心跳”信息，向名稱節(jié)點(diǎn)報(bào)告自己的狀態(tài) ，當(dāng)數(shù)據(jù)節(jié)點(diǎn)發(fā)生故障，或者網(wǎng)絡(luò)發(fā)生斷網(wǎng)時(shí)，名稱節(jié)點(diǎn)就無法收到來自一些數(shù)據(jù)節(jié)點(diǎn)的心跳信息，這時(shí)，這些數(shù)據(jù)節(jié)點(diǎn)就會被標(biāo)記為“宕機(jī)”，節(jié)點(diǎn)上面的所有數(shù)據(jù)都 會被標(biāo)記為“不可讀”，名稱節(jié)點(diǎn)不會再給它們發(fā)送任何I/O請求 這時(shí)，有可能出現(xiàn)一種情形，即由于一些數(shù)據(jù)節(jié)點(diǎn)的不可用，會導(dǎo)致一些數(shù)據(jù)塊的 副本數(shù)量小于冗余因子 ，名稱節(jié)點(diǎn)會定期檢查這種情況，一旦發(fā)現(xiàn)某個(gè)數(shù)據(jù)塊的副本數(shù)量小于冗余因子，就 會啟動數(shù)據(jù)冗余復(fù)制，為它生成新的副本。HDFS和其它分布式文件系統(tǒng)的最大區(qū)別就是可以調(diào)整冗余數(shù)據(jù)的位。

?

• 數(shù)據(jù)出錯(cuò)

客戶端在讀取到數(shù)據(jù)后，會采用md5等對數(shù)據(jù)塊進(jìn)行校驗(yàn)，以確定讀取到正確 的數(shù)據(jù) ，如果校驗(yàn)出錯(cuò)，客戶端就會請求到另外一個(gè)數(shù)據(jù)節(jié)點(diǎn)讀取該文件塊，并且向名稱節(jié)點(diǎn)報(bào)告這個(gè)文件塊有錯(cuò)誤，名稱節(jié)點(diǎn)會定期檢查并且重新復(fù)制這個(gè)塊 。

?

（7）其他

• 優(yōu)點(diǎn)

a.存儲非常大的文件

b.采用流式的數(shù)據(jù)訪問方式

c.運(yùn)行于普通商用機(jī)器

d.高容錯(cuò)、高可靠性

• 不適合的應(yīng)用場景：

a.低延時(shí)的數(shù)據(jù)訪問

b.大量小文件的情況

c.多方讀寫，需要任意的文件修改

（8）擴(kuò)展 GFS簡介（Google File System）

談到Hadoop的起源，就不得不提Google的三駕馬車：Google FS、MapReduce、BigTable。雖然Google沒有公布這三個(gè)產(chǎn)品的源碼，但是他發(fā)布了這三個(gè)產(chǎn)品的詳細(xì)設(shè)計(jì)論文，奠定了風(fēng)靡全球的大數(shù)據(jù)算法的基礎(chǔ)！

（9）問題

1、為什么不適用于處理大量小文件？

2、HDFS的Block為什么這么大？

3、讀取或者寫入文件，如果不調(diào)用Close方法關(guān)閉文件流會咋樣？

總結(jié)

以上是生活随笔為你收集整理的大数据开发工程师需要具备哪些技能？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。