目錄：
1.典型需求
2.40K以上專家必備技能
3.項目中的迷宮場景部件制作
4.Hadoop生態核心原理
一、典型需求（互聯網公司）
二、40K以上專家必備技能
三、大數從業者角色分類
四、Hadoop生態核心原理
1.大數據整體畫像
- 數據流程
- 數據技術
2.大數據平臺整體畫像
- 大數據平臺邏輯劃分
數據相關的工具、產品和技術：比如批量數據采集傳輸的 Sqoop 、離線數據處理的Hadoop 和Hive 、實時流處理的 Storm和 Spark 以及數據分析的R語言等。
數據資產：不僅包含公司業務本身產生和沉淀的數據，還包括公司運作產生的數據（如財務、行政），以及從外界購買 交換或者爬蟲等而來的數據等。
數據管理：有了數據工具，也有了數據資產，但是還必須對它們進行管理才能讓數據產生最大價值并最小化風險，因此數據平臺通常還包括數據管理的相關概念和技術，如數據倉庫、數據建模、 數據質量、數據規范、 數據安全和元數據管理等。在入門大數據的過程中缺乏基礎入門視頻教程和開發工具，可以戳我領取
- 從數據處理的時效性劃分
（1）離線數據平臺。
（2）實時數據平臺。
- 和離線數據平臺相關的技術
Hadoop 、Hive 、數據倉庫、 ETL 、維度建模、 數據邏輯分層等。
- 離線數據平臺的整體架構
3.Hadoop 核心原理
（1）系統簡介
- 正是 Hadoop 開啟了大數據時代的大門，而大數據的發展也是和Hadoop 發展密不可的，甚至從某些方面來說大數據就是 Hadoop 。
- Hadoop 是一種分析和處理大數據的軟件平臺，是一個用 JAVA 語言實現的 Apache 的開源軟件框架，在大量計算機組成的集群中實現了對海量數據的分布式計算。
- Hadoop 采用 MapReduce 分布式計算框架，根據 GFS 原理開發了 HDFS（分布式文件系統），并根據 BigTable 原理開發了 HBase 數據存儲系統。
- Yahoo、Facebook、Amazon，以及國內的百度、阿里巴巴等眾多互聯網公司都以 Hadoop 為基礎搭建了自己的分布式計算系統。
- Hadoop 是一個基礎框架，允許用簡單的編程模型在計算機集群上對大型數據集進行分布式處理。
- 用戶可以在不了解分布式底層細節的情況下，輕松地在 Hadoop 上開發和運行處理海量數據的應用程序。低成本、高可靠、高擴展、高有效、高容錯等特性讓 hadoop 成為最流行的大數據分析系統。
（2）Hadoop 生態里的最核心技術
- HDFS：Hadoop 分布式文件系統，它是Hadoop 的核心子項目。
- MapReduce ：Hadoop 中的 MapReduce 是一個使用簡單的軟件框架，基于它寫出來的應用程序能夠運行在由上千個商用機器組成的大型集群上，并能可靠容錯地并行處理 TB 級別的數據集。
- Hive ：是建立在 Hadoop 體系架構上的一層 SQL抽象，使得數據相關人員使用他們最為熟悉的 SQL 語言就可以進行海量數據的處理、分析和統計工作，而不是必須掌握 Java 等編程語言和具備開發MapReduce 程序的能力。HiveSQL 際上先被 SQL 解析器進行解析然后被 Hive 框架解析成一個MapReduce 可執行計劃，并按照該計劃生成 MapReduce 任務后交給 Hadoop 集群處理。
（3）HDFS
- 文件系統
文件系統是操作系統提供的磁盤空間管理服務，該服務只需要用戶指定文件的存儲位置及文件讀取路徑，而不需要用戶了解文件在磁盤上是如何存放的。對于我們編程人員也是這樣的。
但是當文件所需空間大于本機磁盤空間時，應該如何處理呢？
加磁盤，但是加到一定程度就有限制了。
加機器，即用遠程共享目錄的方式提供網絡化的存儲，這種方式可以理解為分布式文件系統的雛形，它可以把不同文件放入不同的機器中，而且空間不足時可繼續加機器，突破了存儲空間的限制。
- 傳統的分布式文件系統---架構
- 傳統的分布式文件系統---訪問過程
- 傳統的分布式文件系統帶來的問題
各個存儲結點的負載不均衡，單機負載可能極高。例如，如果某個文件是熱門文件，則會有很多用戶經常讀取這個文件，這就會造成該文件所在機器的訪問壓力極高。
數據可靠性低。如果某個文件所在的機器出現故障，那么這個文件就不能訪問了，甚至會造成數據的丟失。
文件管理困難。如果想把一些文件的存儲位置進行調整，就需要查看目標機器的空間是否夠用，并且需要管理員維護文件位置，在機器非常多的情況下，這種操作就極為復雜。
- HDFS 的基本原理
- HDFS 的體系結構（一主多從）
- HDFS 的文件讀取
- HDFS 的文件寫入
- HDFS 異常處理之NameNode
（1） 兩個核心文件
FsImage文件：
a.FsImage用于維護文件系統樹以及文件樹中所有的文件和文件夾的元數據
b.FsImage文件沒有記錄塊存儲在哪個數據節點。而是由名稱節點把這些映射保留在內存中，這個信息單獨在內存中一個區域維護，當數據節點加入HDFS集群時，數據節點會把自己所包含的塊列表告知給名 稱節點，此后會定期執行這種告知操作，以確保名稱節點的塊映射是最新的
EditLog文件：
操作日志文件EditLog中記錄了所有針對文件的創建、刪除、重命名等操作
（2）名稱節點的啟動
在名稱節點啟動的時候，它會將FsImage文件中的內容加載到內存中，之后再執行 EditLog文件中的各項操作，使得內存中的元數據和實際的同步，存在內存中的元數據支持客戶端的讀寫操作。
接收所有datanodes上的文件塊信息匯報，退出安全模式。
（3）名稱節點的問題
名稱節點運行期間，HDFS的所有更新操作都是直接寫到EditLog中，久而久之，EditLog件將會變得很大，這對名稱節點運行沒有什么明顯影響的，但是，名稱節點重啟的時候，需要先將FsImage里面的所有內容映像到內存中，然后再一條一條地執行EditLog中的記錄，當EditLog文件非常大的時候，會導致名稱節點啟動操作非常慢，而在這段時間內HDFS系統處于安全模式，一直無法對外提供寫操作，影響了用戶的使用。
名稱節點壞掉了。
（4）解決方案之一
（5）解決方案之二（Hadoop HA）
（6）HDFS 異常處理之DataNode
- 數據節點出錯
每個數據節點會定期向名稱節點發送“心跳”信息，向名稱節點報告自己的狀態 ，當數據節點發生故障，或者網絡發生斷網時，名稱節點就無法收到來自一些數據節點的心跳信息，這時，這些數據節點就會被標記為“宕機”，節點上面的所有數據都 會被標記為“不可讀”，名稱節點不會再給它們發送任何I/O請求 這時，有可能出現一種情形，即由于一些數據節點的不可用，會導致一些數據塊的 副本數量小于冗余因子 ，名稱節點會定期檢查這種情況，一旦發現某個數據塊的副本數量小于冗余因子，就 會啟動數據冗余復制，為它生成新的副本。HDFS和其它分布式文件系統的最大區別就是可以調整冗余數據的位。
- 數據出錯
客戶端在讀取到數據后，會采用md5等對數據塊進行校驗，以確定讀取到正確 的數據 ，如果校驗出錯，客戶端就會請求到另外一個數據節點讀取該文件塊，并且向名稱節點報告這個文件塊有錯誤，名稱節點會定期檢查并且重新復制這個塊 。
（7）其他
- 優點
a.存儲非常大的文件
b.采用流式的數據訪問方式
c.運行于普通商用機器
d.高容錯、高可靠性
- 不適合的應用場景：
a.低延時的數據訪問
b.大量小文件的情況
c.多方讀寫，需要任意的文件修改
（8）擴展 GFS簡介（google File System）
談到Hadoop的起源，就不得不提Google的三駕馬車：Google FS、MapReduce、BigTable。雖然Google沒有公布這三個產品的源碼，但是他發布了這三個產品的詳細設計論文，奠定了風靡全球的大數據算法的基礎！
（9）問題
1、為什么不適用于處理大量小文件？
2、HDFS的Block為什么這么大？
3、讀取或者寫入文件，如果不調用Close方法關閉文件流會咋樣？
