上傳文件至hdfs

① hdfs詳解之塊、小文件和副本數

1、block：block是物理切塊，在文件上傳到HDFS文件系統後，對大文件將以每128MB的大小切分若干，存放在不同的DataNode上。例如一個文件130M，那麼他會存被切分成2個塊，一個塊128M，另一個塊2M.

1、HDFS 適應場景: 大文件存儲，小文件是致命的
2、如果小文件很多的，則有可能將NN(4G=42億位元組)撐爆。例如:1個小文件(閾值<=30M),那麼NN節點維護的位元組大約250位元組。一億個小文件則是250b * 1億=250億.將會把NN節點搜念撐爆。如果世兄困一億個小文件合並成100萬個大文件:250b * 1百萬=2億位元組。
3、在生產上一般會:
1）調整小文件閾值
2）合並小文件:
a.數據未落地到hdfs之前合並
b.數據已經落到hdfs，調用spark service服務 。每天調度去合並 （-15天 業務周期）
3）小文件的危害:
a.撐爆NN。
b.影響hive、spark的計算。佔用集群計算資源

1、如果是偽分布式，那麼副本數只能為一。
2、生成上副本數一般也是官方默認參數塵枝: 3份

如果一個文件130M，副本數為3。那麼第一個block128M，有三份。另外一個block2M，也有三份。
題目:
blockSize128M,副本數3份，那麼一個文件260M，請問多少塊，多少實際存儲？
260%128=2....4M 3個塊 3個副本=9塊
260M 3=780M

② Hive四種數據導入方式

Hive提供了多種數據導入方式，以下是其中幾種常見的方法：

1、從本地系統導入數據至Hive表：Hive通過Hadoop的HDFS介面，可以從本地文件系統導入數據。首先將數據文件上傳至HDFS，然後在Hive中使用命令`LOAD DATA INPATH '本地文件路徑' INTO TABLE 表名;`實現數據導入。

2、從HDFS導入數據至Hive表：數據存儲在HDFS中時，可以使用`LOAD DATA INPATH 'HDFS文件路徑' INTO TABLE 表名;`命令將數據導入Hive表。這種方式適用於數據已經在HDFS上的場景。

3、從一個Hive表導入到另一個Hive表：使用`INSERT INTO TABLE 目標表 SELECT * FROM 源表`語句可以將源表的數據導入至目標表。確保目標表結構與源表結構相匹配，包括列名、類型和數量。

4、創建表時從其他表導入數據：在創建表的過程中，可以使用`PARTITIONED BY`子句和`SELECT * FROM`子句將其他表的數據作為新表的一部分。例如`CREATE TABLE 新表 (LIKE 源表 INCLUDING ALL);`命令創建的新表結構與源表相同，包括所有列和分區。

這些導入方式在大數據處理中非常實用，能夠根據實際需求靈活選擇和使用。通過Hive的導入功能，數據分析師可以快速將各種來源的數據整合到Hive中，便於進行進一步的查詢、分析和管理。

③ HDFS筆記

1.Hadoop 分布式 文件系統。特點：性能高、效率高、速度快
2.可以在廉價的機器上運行的 可容錯 文件系統。
當集群中有機器掛掉時，HDFS會自動將掛掉的機器上的任務分配給正常的機器，使任務繼續保持正常工作。

2.HDFS處理更加容易。當對一個大型文件進行寫操作時，如果將該文件整個寫入一個節點，那麼該節點的負載便會急劇增加，這樣就喪失了分布式文件系統的意義。所以，應該利用HDFS將文件拆分成不同的塊，然後將不同的塊分配到不同的節點上去，此時，DFS就需要管理者確定文件如何進行拆分，以及每一個塊應該分配到哪一個節點。對文件進行操作時，在單機情況下，首先需要知道文件被拆分成多少塊，每一個塊被放在了哪一個節點上，以及塊之間的順序(文件的粘連)。而HDFS的出現，使得分布式文件集群不再需要人進行管理，利用HDFS讀取文件時，我們不需要關心文件如何拆分，分配，粘連。只用告訴HDFS文件的路徑即可。

HDFS的指令類似於linux下的指令。
查看文件：hdfs dfs -ls /查詢的文件目錄
刪除文件：hdfs dfs -rm r /刪除的文件
創建文件夾：hdfs dfs -mkdir /文件夾名稱
上傳文件至HDFS：hdfs dfs -put 需要上傳的文件 /上傳的文件路徑

為什麼需要學習HDFS結構？
1.面試中，能夠運用於所有分布式文件系統設計。
既然分布式系統下是多節點運行，那麼節點之間是否通信？slave節點只接受來自master節點的命令，向master節點發送心跳指令，slave節點之間不會主動通信。
a.Master slaver 模式：
1.High consistency:一致性。當文件中的一個數據塊寫入slave節點時，當且僅當數據塊被成功寫入到所有備份的slave節點，slave節點向client反饋寫入操作成功，否則，重傳寫入；
2.Simple design:易設計：不需要考慮子節點如何通信。只需要考慮主節點的工作；
3.單master節點不具有魯棒性。
b.Peer peer 模式：
1.所有的讀寫操作均勻分布在每一個節點上，每一個節點的負載不會很高；
2.任意一個節點掛掉不會影響其他節點；
3.低一致性。沒有數據的復制步驟。
2.更好的理解hadoop生態系統

a.master節點會傳輸數據嗎？
不會，master節點只接收client的請求，決定哪一個slave節點進行讀寫操作，然後，client直接與slave節點進行通信。如果數據從master節點傳輸，那麼master節點就會成為影響數據傳輸的瓶頸。
b.slave節點如何存儲數據？
整個大文件？小的文件塊？。HDFS借鑒GFS的設計理念，以block為傳輸單位，將大文件拆分成一個一個小文件，而一個小文件就是block。block的大小可以由Configuration定義，默認大小是128M。
c.誰來決定將文件拆分成塊？
master?slave?。兩者都不是，由HDFS client決定將大文件拆分成block(塊)。HDFS的目的是將所有的節點包裝起來，可以理解成將所有的節點放在一個黑箱里，我們不需要知道黑箱里到底發生了什麼，只需要告訴黑箱需要做什麼工作，這里的HDFS client相當於HDFS與user通信的中間媒介。HDFS client相當於一個軟體包(api)，可以存放在master或者slave或者額外的一個新節點上。

寫入in memory失敗(ACK出現問題)時，master會重新選擇3個新的slave節點。

④ 大數據之HDFS

在現代的企業環境中，單機容量往往無法存儲大量數據，需要跨機器存儲。統一管理分布在集群上的文件系統稱為 分布式文件系統 。

HDFS （Hadoop Distributed File System）是 Hadoop 的核心組件之一， 非常適於存儲大型數據 (比如 TB 和 PB)， HDFS 使用多台計算機存儲文件，並且提供統一的訪問介面，像是訪問一個普通文件系統一樣使用分布式文件系統。

HDFS是分布式計算中數據存儲管理的基礎，是基於流數據模式訪問和處理超大文件的需求而開發的，可以運行於廉價的商用伺服器上。它所具有的 高容錯、高可靠性、高可擴展性、高獲得性、高吞吐率 等特徵為海量數據提供了不怕故障的存儲，為超大數據集的應用處理帶來了很多便利。

HDFS 具有以下 優點 ：

當然 HDFS 也有它的 劣勢 ，並不適合以下場合：

HDFS 採用Master/Slave的架構來存儲數據，這種架構主要由四個部分組成，分別為HDFS Client、NameNode、DataNode和Secondary NameNode。

Namenode是整個文件系統的管理節點，負責接收用戶的操作請求。它維護著整個文件系統的目錄樹，文件的元數據信息以及文件到塊的對應關系和塊到節點的對應關系。

Namenode保存了兩個核心的數據結構：

在NameNode啟動的時候，先將fsimage中的文件系統元數據信息載入到內存，然後根據edits中的記錄將內存中的元數據同步到最新狀態；所以，這兩個文件一旦損壞或丟失，將導致整個HDFS文件系統不可用。

為了避免edits文件過大， SecondaryNameNode會按照時間閾值或者大小閾值，周期性的將fsimage和edits合並 ，然後將最新的fsimage推送給NameNode。

並非 NameNode 的熱備。當NameNode 掛掉的時候，它並不能馬上替換 NameNode 並提供服務。其主要任務是輔助 NameNode，定期合並 fsimage和fsedits。

Datanode是實際存儲數據塊的地方，負責執行數據塊的讀/寫操作。

一個數據塊在DataNode以文件存儲在磁碟上，包括兩個文件，一個是數據本身，一個是元數據，包括數據塊的長度，塊數據的校驗和，以及時間戳。

文件劃分成塊，默認大小128M，以快為單位，每個塊有多個副本（默認3個）存儲不同的機器上。

Hadoop2.X默認128M， 小於一個塊的文件，並不會占據整個塊的空間 。Block數據塊大小設置較大的原因：

文件上傳 HDFS 的時候，Client 將文件切分成 一個一個的Block，然後進行存儲。

Client 還提供一些命令來管理 HDFS，比如啟動或者關閉HDFS。

Namenode始終在內存中保存metedata，用於處理「讀請求」，到有「寫請求」到來時，namenode會首 先寫editlog到磁碟，即向edits文件中寫日誌，成功返回後，才會修改內存 ，並且向客戶端返回，Hadoop會維護一個fsimage文件，也就是namenode中metedata的鏡像，但是fsimage不會隨時與namenode內存中的metedata保持一致，而是每隔一段時間通過合並edits文件來更新內容。

HDFS HA（High Availability）是為了解決單點故障問題。

HA集群設置兩個名稱節點，「活躍（ Active ）」和「待命（ Standby ）」，兩種名稱節點的狀態同步，可以藉助於一個共享存儲系統來實現，一旦活躍名稱節點出現故障，就可以立即切換到待命名稱節點。

為了保證讀寫數據一致性，HDFS集群設計為只能有一個狀態為Active的NameNode，但這種設計存在單點故障問題，官方提供了兩種解決方案：

通過增加一個Secondary NameNode節點，處於Standby的狀態，與Active的NameNode同時運行。當Active的節點出現故障時，切換到Secondary節點。

為了保證Secondary節點能夠隨時頂替上去，Standby節點需要定時同步Active節點的事務日誌來更新本地的文件系統目錄樹信息，同時DataNode需要配置所有NameNode的位置，並向所有狀態的NameNode發送塊列表信息和心跳。

同步事務日誌來更新目錄樹由JournalNode的守護進程來完成，簡稱為QJM，一個NameNode對應一個QJM進程，當Active節點執行任何命名空間文件目錄樹修改時，它會將修改記錄持久化到大多數QJM中，Standby節點從QJM中監聽並讀取編輯事務日誌內容，並將編輯日誌應用到自己的命名空間。發生故障轉移時，Standby節點將確保在將自身提升為Active狀態之前，從QJM讀取所有編輯內容。

注意，QJM只是實現了數據的備份，當Active節點發送故障時，需要手工提升Standby節點為Active節點。如果要實現NameNode故障自動轉移，則需要配套ZKFC組件來實現，ZKFC也是獨立運行的一個守護進程，基於zookeeper來實現選舉和自動故障轉移。

雖然HDFS HA解決了「單點故障」問題，但是在系統擴展性、整體性能和隔離性方面仍然存在問題：

HDFS HA本質上還是單名稱節點。HDFS聯邦可以解決以上三個方面問題。

在HDFS聯邦中，設計了多個相互獨立的NN，使得HDFS的命名服務能夠水平擴展，這些NN分別進行各自命名空間和塊的管理，不需要彼此協調。每個DN要向集群中所有的NN注冊，並周期性的發送心跳信息和塊信息，報告自己的狀態。

HDFS聯邦擁有多個獨立的命名空間，其中，每一個命名空間管理屬於自己的一組塊，這些屬於同一個命名空間的塊組成一個「塊池」。每個DN會為多個塊池提供塊的存儲，塊池中的各個塊實際上是存儲在不同DN中的。

⑤ hdfs的特點有哪些

hdfs的特點
一、hdfs的優點
1.支持海量數據的存儲：一般來說，HDFS存儲的文件可以支持TB和PB級別的數據。
2.檢測和快速應對硬體故障：在集群環境中，硬體故障是常見性問題。因為有上千台伺服器連在一起，故障率很高，因此故障檢測和自動恢復hdfs文件系統的一個設計目標。假設某一個datanode掛掉之後，因為數據是有備份的，還可以從其他節點里找到。namenode通過心跳機制來檢測datanode是否還存活。
3.流式數據訪問：（HDFS不能做到低延遲的數據訪問，但是HDFS的吞吐量大）=》Hadoop適用於處理離線數據，不適合處理實時數據。HDFS的數據處理規模比較大，應用一次需要大量的數據，同時這些應用一般都是批量處理，而不是用戶互動式處理。應用程序能以流的形式訪問資料庫。主要的是數據的吞吐量，而不是訪問速度。訪問速度最終是要受制於網路和磁碟的速度，機器節點再多，也不能突破物理的局限。
4.簡化的一致性模型：對於外部使用用戶，不需要了解hadoop底層細節，比如文件的切塊，文件的存儲，節點的管理。一個文件存儲在HDFS上後，適合一次寫入，多次讀取的場景。因為存儲在HDFS上的文件都是超大文件，當上傳完這個文件到hadoop集群後，會進行文件切塊，分發，復制等操作。如果文件被修改，會導致重新觸發這個過程，而這個過程耗時是最長的。所以在hadoop里，2.0版本允許數據的追加，單不允許數據的修改。
5.高容錯性：數據自動保存多個副本，副本丟失後自動恢復。可構建在廉價的機器上，實現線性擴展。當集群增加新節點之後，namenode也可以感知，將數據分發和備份到相應的節點上。
6.商用硬體：Hadoop並不需要運行在昂貴且高可靠的硬體上。它是設計運行在商用硬體（在各種零售店都能買到的普通硬體）的集群上的，因此至少對於龐大的集群來說，節點故障的幾率還是非常高的。HDFS遇到上述故障時，被設計成能夠繼續運行且不讓用戶察覺到明顯的中斷。
二、HDFS缺點（局限性）
1、不能做到低延遲數據訪問：由於hadoop針對高數據吞吐量做了優化，犧牲了獲取數據的延遲，所以對於低延遲數據訪問，不適合hadoop。對於低延遲的訪問需求，HBase是更好的選擇。
2、不適合大量的小文件存儲 ：由於namenode將文件系統的元數據存儲在內存中，因此該文件系統所能存儲的文件總數受限於namenode的內存容量。根據經驗，每個文件、目錄和數據塊的存儲信息大約佔150位元組。因此，如果有一百萬個小文件，每個小文件都會佔一個數據塊，那至少需要300MB內存。如果是上億級別的，就會超出當前硬體的能力。
3、修改文件：對於上傳到HDFS上的文件，不支持修改文件。Hadoop2.0雖然支持了文件的追加功能，但是還是不建議對HDFS上的文件進行修改。因為效率低下。HDFS適合一次寫入，然後多次讀取的場景。
4、不支持用戶的並行寫：同一時間內，只能有一個用戶執行寫操作。