hdfs上傳本地文件-ag真人国际官网
❶ 大數據之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中的。
❷ hadoop的幾個問題 1.將本地文件復制到hdfs中，那麼在hdfs中這個文件是存放在namenode還是分開放在datanode
試著回答：
先說明一下：
1. namenode負責管理目錄和文件信息，真正的文件塊是存放在datanode上。
2. 每個map和rece（即task)都是java進程，默認是有單獨的jvm的，所以不可能同一個類的對象會在不同節點上。
看你的描述是把namenode,datanode和jobtracker,tasktracker有點混了。
所以：
問題1. 分塊存放在datanode上
問題2.inputformat是在datanode上，確切的說是在tasktracker中。每個map和rece都會有自己的對象，當多個map讀入一個文件時，實際上不同的map是讀的文件不同的塊，rece也是一樣，各個任務讀入的數據是不相交的。
問題3.rece輸出肯定是在hdfs上，和普通文件一樣在datanode上。
問題4.每個recer會有自己的outputformat對象，與前面inputformat原因一樣。
❸ 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中，便於進行進一步的查詢、分析和管理。
❹ hadoop中在hdfs中創建一個input目錄，然後hadoop fs -ls命令
從fs -ls從列出來的文件看，這個文件夾/user/root/input是通過root用戶創建的。說明你在從本地文件系統拷貝input目錄到hdfs系統的時候，不是採用的hadoop用戶，而是用root用戶執行的拷貝命令，你可能忘記切換用戶了，可以刪除現在的input目錄(採用root用戶運行hadoop的刪除命令，或者不刪除也沒關系)，重新使用hadoop用戶把input導入到hdfs系統中試試看。
另外，實際上應用的時候是需要關注hdfs中文件的目錄結構的。你現在採用的是默認的方式，預設會放/user/${user.name}目錄下。
在把本地文件導入到hdfs的時候，是可以指定傳到什麼目錄的，比如:
#創建input目錄
sh bin/hadoop fs -mkdir /user/hadoop/input
#把myfile.txt導入到hdfs的input目錄下
sh bin/hadoop fs –put /usr/hadoop/mydata/myfile.txt /user/hadoop/input