分布式存儲hadoop
㈠ hadoop作用
1.hadoop有三個主要的核心組件：HDFS（分布式文件存儲）、MAPREDUCE（分布式的計算）、YARN（資源調度），現在雲計算包括大數據和虛擬化進行支撐。
在HADOOP（hdfs、MAPREDUCE、yarn）大數據處理技術框架，擅長離線數據分析.
Zookeeper 分布式協調服務基礎組件，Hbase 分布式海量資料庫，離線分析和在線業務處理。
Hive sql 數據倉庫工具，使用方便，功能豐富，基於MR延遲大，可以方便對數據的分析，並且數據的處理可以自定義方法進行操作，簡單方便。
Sqoop數據導入導出工具，將數據從數據導入Hive，將Hive導入資料庫等操作。
Flume數據採集框架，可以從多種源讀取數據。
Azkaban對操作進行管理，比如定時腳本執行，有圖形化界面，上傳job簡單，只需要將腳本打成bao，可直接上傳。
2.hadoop的可以做離散日誌分析，一般流程是:
將web中的數據取過來【通過flume】，然後通過預處理【maprece,一般只是使用map就可以了】，就是將數據中沒有用處的數據去除掉，將數據轉換【比如說時間的格式，Agent的組合】，並將數據進行處理之後以固定格式輸出，由Hive處理，Hive是作用是將數據轉換出一個表，RTL就是寫SQL的一個過程，將數據進行分析，然後將數據報表統計，這個時候使用的是pig數據分析【hive一般作為庫，pig做分析，我沒有使用pig，因為感覺還沒有hive的HQL處理方便】，最後將含金量最大的數據放入到mysql中，然後將mysql中的數據變為可視圖化的工具。
推薦的使用：當我們瀏覽一各網頁的時候，將數據的值值傳遞給後台保存到log中，後台將數據收集起來，hadoop中的fiume可以將數據拿到放入到HDFS中，原始的數據進行預處理，然後使用HIVE將數據變為表，進行數據的分析，將有價值的數據放入到mysql，作為推薦使用，這個一般是商城，數據的來源也是可以通過多種方式的，比如說隱形圖片、js、日誌等都可以作為採集數據的來源。
3.hadoop中的HDFS有兩個重要的角色：NameNode、datanode，Yarn有兩個主要的主角：ResourceManager和nodeManager.
4.分布式：使用多個節點協同完成一項或者多項業務功能的系統叫做分布式系統，分布式一般使用多個節點組成，包括主節點和從節點，進行分析
5.maprece：是使用較少的代碼，完成對海量數據的處理，比如wordCount，統計單詞的個數。
實現思想：將單詞一個一個的遍歷，然後將單詞加1處理，但是這是集群，那麼就每個節點計算自己節點的數據，然後最後交給一個統計的程序完成就可以了，最後將單詞和結果輸出。
㈡ hadoop三大組件是什麼
目前開源hadoop只包含hdfs,mr,和yarn，yarn是hadoop2新增組件。
hdfs是hadoop分布式文件系統，主要採用多備份方式存儲文件，可以對接hive和hbase等產品並存儲對應數據。
maprece是大數據處理並行框架，用戶可以編寫自己的程序調用mr框架並行的處理大數據，在調用過程中可以調整m和r的數目。不過總的來說編程相對復雜，因此誕生了hive。
yarn作為新生控制項，主要管理hadoop各個模塊運行過程中的任務調度，目前主要有公平調度與容量調度兩種模型。如果需要其他組件，需要單獨下載安裝。
Hadoop是一個由Apache基金會所開發的分布式系統基礎架構。用戶可以在不了解分布式底層細節的情況下，開發分布式程序。
充分利用集群的威力進行高速運算和存儲。Hadoop實現了一個分布式文件系統（ Distributed File System），其中一個組件是HDFS（Hadoop Distributed File System）。HDFS有高容錯性的特點，並且設計用來部署在低廉的（low-cost）硬體上。
㈢ hadoop框架的核心是什麼
maprece
由於現在大家都接觸的是hadoop2.x。對於hadoop1.x了解還是比較少的。
很多人問，如果沒有1.x的基礎，能否學習hadoop2.x。答案是可以的。但是如果了解hadoop1.x有助於我們理解hadoop2.x。
我們來看看hadoop1.x存在哪些問題？
hadoop有jobtracker,trasktracker.對於jobtracker,trasktracker剛接觸其實還是比較抽象的。可能多次遇到過。但是對於它的認識和理解還是比較模糊。
我們這里打個比喻：在一個組織結構中，既有管理者，又有執行者。而jobtracker,trasktracker則是管理者，執行者是map task和rece task。
trasktracker像是一個中層管理者，既監控執行者--map task和rece task，如果map任務或rece任務有更新，會通過心跳（一般間隔是3秒）告訴TraskTracker，TraskTracker再通過心跳（一般至少5s，因為代價比較大）告訴JobTracker。
JobTracker是最高層管理者，它接受trasktracker的心跳，負責資源管理和job的調度。
上面如果你思維謹密，就能看出，如果一旦最高層管理JobTracker掛掉，那麼整個集群就癱瘓了。
為什麼那？
1.不能提交job。
2.不能分配資源
3.job無法調度
這就有點像一個國家的leader掛掉了，那麼誰會來負責國家的運轉。如果你了解運行機制，其實也是有方案的。而這個方案就是我們所熟悉的高可用方案。而如果JobTracker掛掉了，顯然hadoop集群就掛掉了。所以顯然hadoop1.x是存在缺陷的。
既然存在缺陷，那麼我們該如何來彌補。如果還是在原先的框架上修改，弄兩個jobtracker是否可以。這肯定是一種方案。但是hadoop也是有野心的。作為大數據最初的開拓者，Spark，storm都非常的活躍。
所以我們列出了，hadoop需改造的下面需求：
1.hadoop存在單點故障
2.hadoop能否統一spark，storm
從上面我們看到hadoop自身存在問題，需要改造，同時又想統一spark和storm。所以hadoop急切需要改造升級。
這里想到了很多種解決方案。
方案1：兩個jobtraker
hadoop自身來講，既然存在單點故障，所以那麼我們可以創建兩個jobtraker，這是否可以。答案是可以的。因為一旦一個掛掉。我們啟用另外一個jobtraker，這也是合適的。但是還存在另外一個問題，就是該如何統一spark和storm。如果spark和storm運行的話，兩個jobtraker是否可以。答案是不行的，因為jobtraker其實還是沒有脫離他本身的框架，只能運行hadoop的map和rece。spark的DAG和storm的拓撲，還是不能運行的。那如果你說我們在jobtraker中加入不就行了。可是這是相當麻煩的，jobtraker肯定會累死的，他的任務太多。顯然需要分離的職務。
方案2：Yarn
兩個jobtraker是不行了，那麼就從jobtraker職能分離並且解決存在的問題
1.性能問題
2.單點故障
3.能運行maprece，spark，storm。
所以這時候就產生了Yarn。
補充hadoop的發展歷程
（1）Hadoop 1.0
Hadoop 1.0即第一代Hadoop，由分布式存儲系統HDFS和分布式計算框架MapRece組成，其中，HDFS由一個NameNode和多個DataNode組成，MapRece由一個JobTracker和多個TaskTracker組成，對應Hadoop版本為Apache Hadoop 0.20.x、1.x、0.21.X、0.22.x和CDH3。
（2）Hadoop 2.0
Hadoop 2.0即第二代Hadoop，為克服Hadoop 1.0中HDFS和MapRece存在的各種問題而提出的。針對Hadoop 1.0中的單NameNode制約HDFS的擴展性問題，提出了HDFS Federation，它讓多個NameNode分管不同的目錄進而實現訪問隔離和橫向擴展，同時它徹底解決了NameNode 單點故障問題；針對Hadoop 1.0中的MapRece在擴展性和多框架支持等方面的不足，它將JobTracker中的資源管理和作業控制功能分開，分別由組件ResourceManager和ApplicationMaster實現，其中，ResourceManager負責所有應用程序的資源分配，而ApplicationMaster僅負責管理一個應用程序，進而誕生了全新的通用資源管理框架YARN。基於YARN，用戶可以運行各種類型的應用程序（不再像1.0那樣僅局限於MapRece一類應用），從離線計算的MapRece到在線計算（流式處理）的Storm等。Hadoop 2.0對應Hadoop版本為Apache Hadoop 0.23.x、2.x和CDH4。
（3）MapRece 1.0或MRv1
MapRece 1.0計算框架主要由三部分組成，分別是編程模型、數據處理引擎和運行時環境。它的基本編程模型是將問題抽象成Map和Rece兩個階段，其中Map階段將輸入數據解析成key/value，迭代調用map()函數處理後，再以key/value的形式輸出到本地目錄，而Rece階段則將key相同的value進行規約處理，並將最終結果寫到HDFS上；它的數據處理引擎由MapTask和ReceTask組成，分別負責Map階段邏輯和Rece階段邏輯的處理；它的運行時環境由（一個）JobTracker和（若干個）TaskTracker兩類服務組成，其中，JobTracker負責資源管理和所有作業的控制，而TaskTracker負責接收來自JobTracker的命令並執行它。該框架在擴展性、容錯性和多框架支持等方面存在不足，這也促使了MRv2的產生。
（4）MRv2
MRv2具有與MRv1相同的編程模型和數據處理引擎，唯一不同的是運行時環境。MRv2是在MRv1基礎上經加工之後，運行於資源管理框架YARN之上的計算框架MapRece。它的運行時環境不再由JobTracker和TaskTracker等服務組成，而是變為通用資源管理系統YARN和作業控制進程ApplicationMaster，其中，YARN負責資源管理和調度，而ApplicationMaster僅負責一個作業的管理。簡言之，MRv1僅是一個獨立的離線計算框架，而MRv2則是運行於YARN之上的MapRece。
（5）YARN
YARN是Hadoop 2.0中的資源管理系統，它是一個通用的資源管理模塊，可為各類應用程序進行資源管理和調度。YARN不僅限於MapRece一種框架使用，也可以供其他框架使用，比如Tez（將在第9章介紹）、Spark、Storm（將在第10章介紹）等。YARN類似於幾年前的資源管理系統Mesos（將在12章介紹）和更早的Torque（將在6章介紹）。由於YARN的通用性，下一代MapRece的核心已經從簡單的支持單一應用的計算框架MapRece轉移到通用的資源管理系統YARN。
（6）HDFS Federation
Hadoop 2.0中對HDFS進行了改進，使NameNode可以橫向擴展成多個，每個NameNode分管一部分目錄，進而產生了HDFS Federation，該機制的引入不僅增強了HDFS的擴展性，也使HDFS具備了隔離性。
㈣ hadoop是做什麼的
提供海量數據存儲和計算的，需要java語言基礎。
Hadoop實現了一個分布式文件系統（Hadoop Distributed File System），簡稱HDFS。有高容錯性的特點，並且設計用來部署在低廉的（low-cost）硬體上；而且它提供高吞吐量來訪問應用程序的數據，適合那些有著超大數據集（large data set）的應用程序。
特點
1、快照支持在一個特定時間存儲一個數據拷貝，快照可以將失效的集群回滾到之前一個正常的時間點上。HDFS已經支持元數據快照。
2、HDFS的設計是用於支持大文件的。運行在HDFS上的程序也是用於處理大數據集的。這些程序僅寫一次數據，一次或多次讀數據請求，並且這些讀操作要求滿足流式傳輸速度。
HDFS支持文件的一次寫多次讀操作。HDFS中典型的塊大小是64MB，一個HDFS文件可以被切分成多個64MB大小的塊，如果需要，每一個塊可以分布在不同的數據節點上。
3、階段狀態：一個客戶端創建一個文件的請求並不會立即轉發到名位元組點。實際上，一開始HDFS客戶端將文件數據緩存在本地的臨時文件中。
㈤ Hadoop到底是干什麼用的
用途：將單機的工作任務進行分拆，變成協同工作的集群。用以解決日益增加的文件存儲量和數據量瓶頸。
通俗應用解釋：
比如計算一個100M的文本文件中的單詞的個數，這個文本文件有若干行，每行有若干個單詞，每行的單詞與單詞之間都是以空格鍵分開的。對於處理這種100M量級數據的計算任務，把這個100M的文件拷貝到自己的電腦上，然後寫個計算程序就能完成計算。
關鍵技術：
HDFS（Hadoop Distributed File System）：
既可以是Hadoop 集群的一部分，也可以是一個獨立的分布式文件系統，是開源免費的大數據處理文件存儲系統。
HDFS是Master和Slave的主從結構（是一種概念模型，將設備分為主設備和從設備，主設備負責分配工作並整合結果，或作為指令的來源；從設備負責完成工作，一般只能和主設備通信）。主要由Name-Node、Secondary NameNode、DataNode構成。
Name-Node：分布式文件系統中的管理者，主要負責管理文件系統的命名空間、集群配置信息和存儲塊的復制等
Secondary NameNode：輔助 NameNode，分擔其工作，緊急情況可以輔助恢復
DataNode：Slave節點，實際存儲數據、執行數據塊的讀寫並匯報存儲信息給NameNode
HDFS客戶端的存儲流程：當客戶需要寫數據時，先在NameNode 上創建文件結構並確定數據塊副本將要寫道哪幾個 datanode ，然後將多個代寫 DataNode 組成一個寫數據管道，保證寫入過程完整統一寫入。
讀取數據時則先通過 NameNode 找到存儲數據塊副本的所有 DataNode ，根據與讀取客戶端距離排序數據塊，然後取最近的。
㈥ Hadoop在大數據中有什麼作用
HDFS按照Master和Slave的結構。分為NameNode、SecondaryNameNode、DataNode這幾個角色。
NameNode：是Master節點，是大領導。管理數據塊映射;處理客戶端的讀寫請求;配置副本策略;管理HDFS的名稱空間。
SecondaryNameNode：是一個小弟，分擔大哥namenode的工作量;是NameNode的冷備份;合並fsimage(元數據鏡像文件，文件系統的目錄樹)和fsedits(元數據的操作日誌，針對文件系統做的修改操作記錄)，然後再發給namenode。
DataNode：是Slave節點，是奴隸，幹活的。負責存儲客戶端發來的block;執行block的讀寫操作。NameNode和DataNode之間的通信是通過心跳機制實現的。
Map(映射)任務處理：
讀取HDFS中的文件。每一行解析成一個。每一個鍵值對調用一次map函數。map函數接收前面產生的，進行處理，轉換為新的輸出。對轉換後的進行分區。對不同分區中的數據按key進行排序、分組。分組指的是相同key的value放到一個集合中。
Rece(歸約)任務處理：
多個map任務的輸出，按照不同的分區，通過網路到不同的rece節點上。對多個map的輸出進行合並、排序。覆蓋rece函數，接收的是分組後的數據，實現自己的業務邏輯，處理後，產生新的輸出。對rece輸出的寫到HDFS中。
關於Hadoop在大數據中有什麼作用，青藤小編就和您分享到這里了。如果您對大數據工程有濃厚的興趣，希望這篇文章能夠對你有所幫助。如果您還想了解更多關於數據分析師、大數據工程師的技巧及素材等內容，可以點擊本站的其他文章進行學習。
㈦ IT培訓分享Hadoop環境中管理大數據8大存儲技巧
在現如今，隨著IT互聯網信息技術的飛速發展和進步。目前大數據行業也越來越火爆，從而導致國內大數據人才也極度缺乏，下面IT培訓http://www.kmbdqn.com/介紹一下關於Hadoop環境中管理大數據存儲技巧。
1、分布式存儲
傳統化集中式存儲存在已有一段時間。但大數據並非真的適合集中式存儲架構。Hadoop設計用於將計算更接近數據節點，同時採用了HDFS文件系統的大規模橫向擴展功能。
雖然，通常解決Hadoop管理自身數據低效性的方案是將Hadoop數據存儲在SAN上。但這也造成了它自身性能與規模的瓶頸。現在，如果你把所有的數據都通過集中式SAN處理器進行處理，與Hadoop的分布式和並行化特性相悖。你要麼針對不同的數據節點管理多個SAN，要麼將所有的數據節點都集中到一個SAN。
但Hadoop是一個分布式應用，就應該運行在分布式存儲上，這樣存儲就保留了與Hadoop本身同樣的靈活性，不過它也要求擁抱一個軟體定義存儲方案，並在商用伺服器上運行，這相比瓶頸化的Hadoop自然更為高效。
2、超融合VS分布式
注意，不要混淆超融合與分布式。某些超融合方案是分布式存儲，但通常這個術語意味著你的應用和存儲都保存在同一計算節點上。這是在試圖解決數據本地化的問題，但它會造成太多資源爭用。這個Hadoop應用和存儲平台會爭用相同的內存和CPU。Hadoop運行在專有應用層，分布式存儲運行在專有存儲層這樣會更好。之後，利用緩存和分層來解決數據本地化並補償網路性能損失。
3、避免控制器瓶頸(ControllerChokePoint)
實現目標的一個重要方面就是——避免通過單個點例如一個傳統控制器來處理數據。反之，要確保存儲平台並行化，性能可以得到顯著提升。
此外，這個方案提供了增量擴展性。為數據湖添加功能跟往裡面扔x86伺服器一樣簡單。一個分布式存儲平台如有需要將自動添加功能並重新調整數據。
4、刪重和壓縮
掌握大數據的關鍵是刪重和壓縮技術。通常大數據集內會有70%到90%的數據簡化。以PB容量計，能節約數萬美元的磁碟成本。現代平台提供內聯(對比後期處理)刪重和壓縮，大大降低了存儲數據所需能力。
5、合並Hadoop發行版
很多大型企業擁有多個Hadoop發行版本。可能是開發者需要或是企業部門已經適應了不同版本。無論如何最終往往要對這些集群的維護與運營。一旦海量數據真正開始影響一家企業時，多個Hadoop發行版存儲就會導致低效性。我們可以通過創建一個單一，可刪重和壓縮的數據湖獲取數據效率
6、虛擬化Hadoop
虛擬化已經席捲企業級市場。很多地區超過80%的物理伺服器現在是虛擬化的。但也仍有很多企業因為性能和數據本地化問題對虛擬化Hadoop避而不談。
7、創建彈性數據湖
創建數據湖並不容易，但大數據存儲可能會有需求。我們有很多種方法來做這件事，但哪一種是正確的?這個正確的架構應該是一個動態，彈性的數據湖，可以以多種格式(架構化，非結構化，半結構化)存儲所有資源的數據。更重要的是，它必須支持應用不在遠程資源上而是在本地數據資源上執行。
㈧ 什麼是HDFS硬碟分布式存儲
Namenode 是一個中心伺服器，單一節點（簡化系統的設計和實現），負責管理文件系統的名字空間(namespace)以及客戶端對文件的訪問。
文件操作，NameNode 負責文件元數據的操作，DataNode負責處理文件內容的讀寫請求，跟文件內容相關的數據流不經過NameNode，只會詢問它跟哪個DataNode聯系，否則NameNode會成為系統的瓶頸。
副本存放在哪些DataNode上由 NameNode來控制，根據全局情況做出塊放置決定，讀取文件時NameNode盡量讓用戶先讀取最近的副本，降低帶塊消耗和讀取時延
Namenode 全權管理數據塊的復制，它周期性地從集群中的每個Datanode接收心跳信號和塊狀態報告(Blockreport)。接收到心跳信號意味著該Datanode節點工作正常。塊狀態報告包含了一個該Datanode上所有數據塊的列表。
NameNode支持對HDFS中的目錄、文件和塊做類似文件系統的創建、修改、刪除、列表文件和目錄等基本操作。 塊存儲管理，在整個HDFS集群中有且只有唯一一個處於active狀態NameNode節點，該節點負責對這個命名空間（HDFS）進行管理。
1、Name啟動的時候首先將fsimage（鏡像）載入內存，並執行（replay）編輯日誌editlog的的各項操作；
2、一旦在內存中建立文件系統元數據映射，則創建一個新的fsimage文件（這個過程不需SecondaryNameNode） 和一個空的editlog；
3、在安全模式下，各個datanode會向namenode發送塊列表的最新情況；
4、此刻namenode運行在安全模式。即NameNode的文件系統對於客服端來說是只讀的。(顯示目錄，顯示文件內容等。寫、刪除、重命名都會失敗)；
5、NameNode開始監聽RPC和HTTP請求
解釋RPC:RPC（Remote Procere Call Protocol）——遠程過程通過協議，它是一種通過網路從遠程計算機程序上請求服務，而不需要了解底層網路技術的協議；
6、系統中數據塊的位置並不是由namenode維護的，而是以塊列表形式存儲在datanode中；
7、在系統的正常操作期間，namenode會在內存中保留所有塊信息的映射信息。
存儲文件，文件被分成block存儲在磁碟上，為保證數據安全，文件會有多個副本 namenode和client的指令進行存儲或者檢索block，並且周期性的向namenode節點報告它存了哪些文件的blo
文件切分成塊（默認大小128M），以塊為單位，每個塊有多個副本存儲在不同的機器上，副本數可在文件生成時指定（默認3）
NameNode 是主節點，存儲文件的元數據如文件名，文件目錄結構，文件屬性（生成時間,副本數,文件許可權），以及每個文件的塊列表以及塊所在的DataNode等等
DataNode 在本地文件系統存儲文件塊數據，以及塊數據的校驗和。
可以創建、刪除、移動或重命名文件，當文件創建、寫入和關閉之後不能修改文件內容。
NameNode啟動流程
1、Name啟動的時候首先將fsimage（鏡像）載入內存，並執行（replay）編輯日誌editlog的的各項操作；
2、一旦在內存中建立文件系統元數據映射，則創建一個新的fsimage文件（這個過程不需SecondaryNameNode） 和一個空的editlog；
3、在安全模式下，各個datanode會向namenode發送塊列表的最新情況；
4、此刻namenode運行在安全模式。即NameNode的文件系統對於客服端來說是只讀的。(顯示目錄，顯示文件內容等。寫、刪除、重命名都會失敗)；
5、NameNode開始監聽RPC和HTTP請求
解釋RPC:RPC（Remote Procere Call Protocol）——遠程過程通過協議，它是一種通過網路從遠程計算機程序上請求服務，而不需要了解底層網路技術的協議；
6、系統中數據塊的位置並不是由namenode維護的，而是以塊列表形式存儲在datanode中；
7、在系統的正常操作期間，namenode會在內存中保留所有塊信息的映射信息。
HDFS的特點
優點：
1）處理超大文件
這里的超大文件通常是指百MB、數百TB大小的文件。目前在實際應用中，HDFS已經能用來存儲管理PB級的數據了。
2）流式的訪問數據
HDFS的設計建立在更多地響應"一次寫入、多次讀取"任務的基礎上。這意味著一個數據集一旦由數據源生成，就會被復制分發到不同的存儲節點中，然後響應各種各樣的數據分析任務請求。在多數情況下，分析任務都會涉及數據集中的大部分數據，也就是說，對HDFS來說，請求讀取整個數據集要比讀取一條記錄更加高效。
3）運行於廉價的商用機器集群上
Hadoop設計對硬體需求比較低，只須運行在低廉的商用硬體集群上，而無需昂貴的高可用性機器上。廉價的商用機也就意味著大型集群中出現節點故障情況的概率非常高。這就要求設計HDFS時要充分考慮數據的可靠性，安全性及高可用性。
缺點：
1）不適合低延遲數據訪問
如果要處理一些用戶要求時間比較短的低延遲應用請求，則HDFS不適合。HDFS是為了處理大型數據集分析任務的，主要是為達到高的數據吞吐量而設計的，這就可能要求以高延遲作為代價。
2）無法高效存儲大量小文件
因為Namenode把文件系統的元數據放置在內存中，所以文件系統所能容納的文件數目是由Namenode的內存大小來決定。一般來說，每一個文件、文件夾和Block需要佔據150位元組左右的空間，所以，如果你有100萬個文件，每一個占據一個Block，你就至少需要300MB內存。當前來說，數百萬的文件還是可行的，當擴展到數十億時，對於當前的硬體水平來說就沒法實現了。還有一個問題就是，因為Map task的數量是由splits來決定的，所以用MR處理大量的小文件時，就會產生過多的Maptask，線程管理開銷將會增加作業時間。舉個例子，處理10000M的文件，若每個split為1M，那就會有10000個Maptasks，會有很大的線程開銷；若每個split為100M，則只有100個Maptasks，每個Maptask將會有更多的事情做，而線程的管理開銷也將減小很多。
1280M 1個文件 10block*150位元組 = 1500 位元組 =1.5KB
1280M 12.8M 100個 100個block*150位元組 = 15000位元組 = 15KB
3）不支持多用戶寫入及任意修改文件
在HDFS的一個文件中只有一個寫入者，而且寫操作只能在文件末尾完成，即只能執行追加操作。目前HDFS還不支持多個用戶對同一文件的寫操作，以及在文件任意位置進行修改。
四、HDFS文件 讀寫流程
4.1 讀文件流程
（1） 打開分布式文件
調用 分布式文件 DistributedFileSystem.open()方法。
（2） 從 NameNode 獲得 DataNode 地址
DistributedFileSystem 使用 RPC 調用 NameNode， NameNode返回存有該副本的 DataNode 地址， DistributedFileSystem 返回一個輸入流 FSDataInputStream對象， 該對象封存了輸入流DFSInputStream。
（3） 連接到DataNode
調用 輸入流 FSDataInputStream 的 read() 方法， 從而輸入流DFSInputStream 連接 DataNodes。
（4） 讀取DataNode
反復調用 read()方法， 從而將數據從 DataNode 傳輸到客戶端。
（5） 讀取另外的DataNode直到完成
到達塊的末端時候， 輸入流 DFSInputStream 關閉與DataNode 連接，尋找下一個 DataNode。
（6） 完成讀取， 關閉連接
即調用輸入流 FSDataInputStream.close() 。
4.2 寫文件流程
（1） 發送創建文件請求： 調用分布式文件系統DistributedFileSystem.create()方法；
（2） NameNode中創建文件記錄： 分布式文件系統DistributedFileSystem 發送 RPC 請求給namenode， namenode 檢查許可權後創建一條記錄， 返回輸出流 FSDataOutputStream， 封裝了輸出流 DFSOutputDtream；
（3） 客戶端寫入數據： 輸出流 DFSOutputDtream 將數據分成一個個的數據包， 並寫入內部隊列。 DataStreamer 根據 DataNode 列表來要求 namenode 分配適合的新塊來存儲數據備份。一組DataNode 構成管線(管線的 DataNode 之間使用 Socket 流式通信)
（4） 使用管線傳輸數據： DataStreamer 將數據包流式傳輸到管線第一個DataNode， 第一個DataNode 再傳到第二個DataNode ,直到完成。
（5） 確認隊列： DataNode 收到數據後發送確認， 管線的DataNode所有的確認組成一個確認隊列。 所有DataNode 都確認， 管線數據包刪除。
（6） 關閉： 客戶端對數據量調用close（） 方法。 將剩餘所有數據寫入DataNode管線， 並聯系NameNode且發送文件寫入完成信息之前等待確認。
（7） NameNode確認
（8） 故障處理： 若過程中發生故障， 則先關閉管線， 把隊列中所有數據包添加回去隊列， 確保數據包不漏。 為另一個正常DataNode的當前數據塊指定一個新的標識， 並將該標識傳送給NameNode, 一遍故障DataNode在恢復後刪除上面的不完整數據塊. 從管線中刪除故障DataNode 並把餘下的數據塊寫入餘下正常的DataNode。 NameNode發現復本兩不足時， 會在另一個節點創建一個新的復本
㈨ 雲南電腦培訓學校告訴你Hadoop環境中管理大數據8大存儲技巧
在現如今，隨著IT互聯網信息技術的飛速發展和進步。目前大數據行業也越來越火爆，從而導致國內大數據人才也極度缺乏，下面IT培訓http://www.kmbdqn.cn/介紹一下關於Hadoop環境中管理大數據存儲技巧。
1、分布式存儲
傳統化集中式存儲存在已有一段時間。但大數據並非真的適合集中式存儲架構。Hadoop設計用於將計算更接近數據節點，同時採用了HDFS文件系統的大規模橫向擴展功能。
雖然，通常解決Hadoop管理自身數據低效性的方案是將Hadoop數據存儲在SAN上。但這也造成了它自身性能與規模的瓶頸。現在，如果你把所有的數據都通過集中式SAN處理器進行處理，與Hadoop的分布式和並行化特性相悖。你要麼針對不同的數據節點管理多個SAN，要麼將所有的數據節點都集中到一個SAN。
但Hadoop是一個分布式應用，就應該運行在分布式存儲上，這樣存儲就保留了與Hadoop本身同樣的靈活性，不過它也要求擁抱一個軟體定義存儲方案，並在商用伺服器上運行，這相比瓶頸化的Hadoop自然更為高效。
2、超融合VS分布式
注意，不要混淆超融合與分布式。某些超融合方案是分布式存儲，但通常這個術語意味著你的應用和存儲都保存在同一計算節點上。這是在試圖解決數據本地化的問題，但它會造成太多資源爭用。這個Hadoop應用和存儲平台會爭用相同的內存和CPU。Hadoop運行在專有應用層，分布式存儲運行在專有存儲層這樣會更好。之後，利用緩存和分層來解決數據本地化並補償網路性能損失。
3、避免控制器瓶頸(ControllerChokePoint)
實現目標的一個重要方面就是——避免通過單個點例如一個傳統控制器來處理數據。反之，要確保存儲平台並行化，性能可以得到顯著提升。
此外，這個方案提供了增量擴展性。為數據湖添加功能跟往裡面扔x86伺服器一樣簡單。一個分布式存儲平台如有需要將自動添加功能並重新調整數據。
4、刪重和壓縮
掌握大數據的關鍵是刪重和壓縮技術。通常大數據集內會有70%到90%的數據簡化。以PB容量計，能節約數萬美元的磁碟成本。現代平台提供內聯(對比後期處理)刪重和壓縮，大大降低了存儲數據所需能力。
5、合並Hadoop發行版
很多大型企業擁有多個Hadoop發行版本。可能是開發者需要或是企業部門已經適應了不同版本。無論如何最終往往要對這些集群的維護與運營。一旦海量數據真正開始影響一家企業時，多個Hadoop發行版存儲就會導致低效性。我們可以通過創建一個單一，可刪重和壓縮的數據湖獲取數據效率
6、虛擬化Hadoop
虛擬化已經席捲企業級市場。很多地區超過80%的物理伺服器現在是虛擬化的。但也仍有很多企業因為性能和數據本地化問題對虛擬化Hadoop避而不談。
7、創建彈性數據湖
創建數據湖並不容易，但大數據存儲可能會有需求。我們有很多種方法來做這件事，但哪一種是正確的?這個正確的架構應該是一個動態，彈性的數據湖，可以以多種格式(架構化，非結構化，半結構化)存儲所有資源的數據。更重要的是，它必須支持應用不在遠程資源上而是在本地數據資源上執行。