hadoophdfsftp
❶ 大數據Hadoop2.x與Hadoop3.x相比較有哪些變化
在這篇文章中，我們將討論Hadoop 2.x與Hadoop 3.x之間的比較。 Hadoop3版本中添加了哪些新功能，Hadoop3中兼容的Hadoop 2程序，Hadoop 2和Hadoop 3有什麼區別？ 我們希望Hadoop 2和Hadoop 3之間的這個功能的區別將幫助回答上述問題。
Hadoop 2.x與Hadoop 3.x之間的功能比較
本節將講述Hadoop 2.x與Hadoop 3.x之間的22個差異。 現在讓我們逐一討論
1.License
adoop 2.x - Apache 2.0，開源
Hadoop 3.x - Apache 2.0，開源
2.支持的最低java版本
Hadoop 2.x - java的最低支持版本是java 7
Hadoop 3.x - java的最低支持版本是java 8
3.容錯
Hadoop 2.x - 可以通過復制（浪費空間）來處理容錯。
Hadoop 3.x - 可以通過Erasure編碼處理容錯。
4.數據平衡
Hadoop 2.x - 對於數據，平衡使用HDFS平衡器。
Hadoop 3.x - 對於數據，平衡使用Intra-data節點平衡器，該平衡器通過HDFS磁碟平衡器CLI調用。
5.存儲Scheme
Hadoop 2.x - 使用3X副本Scheme
Hadoop 3.x - 支持HDFS中的擦除編碼。
6.存儲開銷
Hadoop 2.x - HDFS在存儲空間中有200％的開銷。
Hadoop 3.x - 存儲開銷僅為50％。
7.存儲開銷示例
Hadoop 2.x - 如果有6個塊，那麼由於副本方案（Scheme），將有18個塊佔用空間。
Hadoop 3.x - 如果有6個塊，那麼將有9個塊空間，6塊block，3塊用於奇偶校驗。
8.YARN時間線服務
Hadoop 2.x - 使用具有可伸縮性問題的舊時間軸服務。
Hadoop 3.x - 改進時間線服務v2並提高時間線服務的可擴展性和可靠性。
9.默認埠范圍
Hadoop 2.x - 在Hadoop 2.0中，一些默認埠是linux臨時埠范圍。所以在啟動時，他們將無法綁定。
Hadoop 3.x - 但是在Hadoop 3.0中，這些埠已經移出了短暫的范圍。
10.工具
Hadoop 2.x - 使用Hive，pig，Tez，Hama，Giraph和其他Hadoop工具。
Hadoop 3.x - 可以使用Hive，pig，Tez，Hama，Giraph和其他Hadoop工具。
11.兼容的文件系統
Hadoop 2.x - HDFS（默認FS），ftp文件系統：它將所有數據存儲在可遠程訪問的FTP伺服器上。 Amazon S3（簡單存儲服務）文件系統Windows Azure存儲Blob（WASB）文件系統。
Hadoop 3.x - 它支持所有前面以及Microsoft Azure Data Lake文件系統。
12.Datanode資源
Hadoop 2.x - Datanode資源不專用於MapRece，我們可以將它用於其他應用程序。
Hadoop 3.x - 此處數據節點資源也可用於其他應用程序。
13.MR API兼容性
Hadoop 2.x - 與Hadoop 1.x程序兼容的MR API，可在Hadoop 2.X上執行
Hadoop 3.x - 此處，MR API與運行Hadoop 1.x程序兼容，以便在Hadoop 3.X上執行
14.支持Microsoft Windows
Hadoop 2.x - 它可以部署在Windows上。
Hadoop 3.x - 它也支持Microsoft Windows。
15.插槽/容器
Hadoop 2.x - Hadoop 1適用於插槽的概念，但Hadoop 2.X適用於容器的概念。通過容器，我們可以運行通用任務。
Hadoop 3.x - 它也適用於容器的概念。
16.單點故障
Hadoop 2.x - 具有SPOF的功能，因此只要Namenode失敗，它就會自動恢復。
Hadoop 3.x - 具有SPOF的功能，因此只要Namenode失敗，它就會自動恢復，無需人工干預就可以克服它。
17.HDFS聯盟
Hadoop 2.x - 在Hadoop 1.0中，只有一個NameNode來管理所有Namespace，但在Hadoop 2.0中，多個NameNode用於多個Namespace。
Hadoop 3.x - Hadoop 3.x還有多個名稱空間用於多個名稱空間。
18.可擴展性
Hadoop 2.x - 我們可以擴展到每個群集10,000個節點。
Hadoop 3.x - 更好的可擴展性。 我們可以為每個群集擴展超過10,000個節點。
19.更快地訪問數據
Hadoop 2.x - 由於數據節點緩存，我們可以快速訪問數據。
Hadoop 3.x - 這里也通過Datanode緩存我們可以快速訪問數據。
20.HDFS快照
Hadoop 2.x - Hadoop 2增加了對快照的支持。 它為用戶錯誤提供災難恢復和保護。
Hadoop 3.x - Hadoop 2也支持快照功能。
21.平台
Hadoop 2.x - 可以作為各種數據分析的平台，可以運行事件處理，流媒體和實時操作。
Hadoop 3.x - 這里也可以在YARN的頂部運行事件處理，流媒體和實時操作。
22.群集資源管理
Hadoop 2.x - 對於群集資源管理，它使用YARN。 它提高了可擴展性，高可用性，多租戶。
Hadoop 3.x - 對於集群，資源管理使用具有所有功能的YARN。
小夥伴們想了解更多的大數據相關技術可以點擊文章末尾「了解更多」查看
了解更多
❷ 4、Hadoop-HDFS部署步驟（1.X）
· 依賴軟體ssh、jdk
· 環境的配置
Java_Home
免密鑰
· 時間同步
· hosts、hostname
· /opt/sxt/
· 配置文件新修改
Java_Home
· 角色在哪裡啟動
部署參考步驟（請點擊此處）
（1）設置ssh免密鑰
ssh-keygen -t dsa -P '' -f ~/.ssh/id_dsa
cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
此時可檢驗是否設置成功，嘗試免密登錄本機，如下
（2）安裝jdk
首先利用xftp將安裝包導入，再解壓安裝
解壓後，java所在目錄位置如下 /usr/java
配置環境變數，打開 vi /etc/profile 追加下面兩行
保存退出後，是設置系統配置，linux下使用source /etc/profile保存配置後，新的環境變數只能在一個終端裡面有效。
（3）hadoop部署
利用xftp將hadoop-2.6.5.tar.gz包上傳，解壓安裝
新建目錄存放hadoop
配置hadoop環境變數，增加如下兩行
進入如下目錄修改hadoop-env.sh等配置文件，首先修改hadoop-env.sh文件，改後如下
其次、修改mapred-env.sh，/usr/java/jdk1.8.0_261-amd64
修改yarn-env.sh
其次修改etc/hadoop下的core-site.xml和hdfs-site.xml,使主節點位置可知
```
<configuration>
<property>
<name>fs.defaultFS</name>
<value>hdfs://node01:9000</value>
</property>
<property>
<name>hadoop.tmp.dir</name>
<value>/var/sxt/hadoop/local</value>
</property>
</configuration>
```
```
<configuration>
<property>
<name>dfs.replication</name>
<value>1</value>
</property>
<property>
<name>dfs.namenode.secondary.http-address</name>
<value>node01:50090</value>
</property>
</configuration>
```
配置slaves文件，使DataNode可知，修改如下，如以後還有namenode，可添加
隨後格式化 hdfs namenode -format 顯示successfully則配置成功
啟動，如報錯，在查看下方日誌文件排錯
訪問node01：50070 如下所示，成功！
計劃：node01 ： NameNode
node02 ： SecondaryNode DataNode
node03 node04 ： DataNode
（1）安裝jdk，配置環境變數，設置ssh免密鑰（將node01d1ssh的id_dsa.pub寫到其他三個節點）
此時查看node02中.ssh下目錄
或者直接將node01的authorized_keys追加到node02的.ssh下，如下所示，此時node01可以免密登錄node02
之後node03和node04依次執行圖3-1和圖3-2的命令。校準四個系統時間
修改node01的core-site.xml
進入node01的sxt目錄將hadoop-2.6.5拷貝到node02（03、04都要執行相同步驟）的同目錄下（node02下的opt/sxt）
經過以上步驟配置完成，再從node01進行格式化
hdfs namenode -format
❸ ftp提取文件到hdfs
實際場景中，我們經常需要通過ftp協議把不同數據源的文件統一匯入到hdfs數據中心，經過實踐，有以下的三種方法，分別列出其優缺點及適用場景。
1、 先把文件ftp到本地，然後用命令hdfsdfs –put [local_path] [hdfs_path]
優點：文件在本地可以進行本地化的一系列操作後，再放回hdfs中
缺點：文件傳輸經過兩層，並且從源伺服器到本地提取是單機串列，比較消耗時間。
適用於文件放入hfds前需要預處理的情景，如：.zip壓縮文件不被hadoop支持的，所以我們可以先在本地轉壓縮方式然後再放入hdfs中。
2、 hdfs dfs –cp [ftp://username:password@hostname/ftp_path] [hdfs:///hdfs_path]
優點：簡單，提取速度快
缺點：CLI執行不會顯示進度
適用場景：適用於小文件的ftp拷貝。
3、 hadoop distcp [ftp://username:password@hostname/ftp_path] [hdfs:///hdfs_path]
優點：簡單，能顯示拷貝進度，並且是分布式提取的，數據比較快。
缺點： 如果拷貝的文件是不斷有其他程序寫入，會報錯，因為該命令最後要對數據進行checksum導致兩邊不一致，當然，該命令是主要用於集群間拷貝的。
適用場景：大量文件或大文件的拷貝。
❹ Hadoop系列之HDFS架構
本篇文章翻譯了Hadoop系列下的 HDFS Architecture ，原文最初經過筆者翻譯後大概有6000字，之後筆者對內容進行了精簡化壓縮，從而使筆者自己和其他讀者們閱讀本文時能夠更加高效快速的完成對Hadoop的學習或復習。本文主要介紹了Hadoop的整體架構，包括但不限於節點概念、命名空間、數據容錯機制、數據管理方式、簡單的腳本命令和垃圾回收概念。
PS：筆者新手一枚，如果看出哪裡存在問題，歡迎下方留言！
Hadoop Distributed File System（HDFS）是高容錯、高吞吐量、用於處理海量數據的分布式文件系統。
HDFS一般由成百上千的機器組成，每個機器存儲整個數據集的一部分數據，機器故障的快速發現與恢復是HDFS的核心目標。
HDFS對介面的核心目標是高吞吐量而非低延遲。
HDFS支持海量數據集合，一個集群一般能夠支持千萬以上數量級的文件。
HDFS應用需要對文件寫一次讀多次的介面模型，文件變更只支持尾部添加和截斷。
HDFS的海量數據與一致性介面特點，使得遷移計算以適應文件內容要比遷移數據從而支持計算更加高效。
HDFS支持跨平台使用。
HDFS使用主從架構。一個HDFS集群由一個NameNode、一個主伺服器（用於管理系統命名空間和控制客戶端文件介面）、大量的DataNode（一般一個節點一個，用於管理該節點數據存儲）。HDFS對外暴露了文件系統命名空間並允許在文件中存儲用戶數據。一個文件被分成一個或多個塊，這些塊存儲在一組DataNode中。NameNode執行文件系統命名空間的打開關閉重命名等命令並記錄著塊和DataNode之間的映射。DataNode用於處理客戶端的讀寫請求和塊的相關操作。NameNode和DataNode一般運行在GNU/Linux操作系統上，HDFS使用Java語言開發的，因此NameNode和DataNode可以運行在任何支持Java的機器上，再加上Java語言的高度可移植性，使得HDFS可以發布在各種各樣的機器上。一個HDFS集群中運行一個NameNode，其他機器每個運行一個（也可以多個，非常少見）DataNode。NameNode簡化了系統的架構，只用於存儲所有HDFS元數據，用戶數據不會進入該節點。下圖為HDFS架構圖：
HDFS支持傳統的分層文件管理，用戶或者應用能夠在目錄下創建目錄或者文件。文件系統命名空間和其他文件系統是相似的，支持創建、刪除、移動和重命名文件。HDFS支持用戶數量限制和訪問許可權控制，不支持軟硬鏈接，用戶可以自己實現軟硬鏈接。NameNode控制該命名空間，命名空間任何變動幾乎都要記錄到NameNode中。應用可以在HDFS中對文件聲明復制次數，這個次數叫做復制系數，會被記錄到NameNode中。
HDFS將每個文件存儲為一個或多個塊，並為文件設置了塊的大小和復制系數從而支持文件容錯。一個文件所有的塊（除了最後一個塊）大小相同，後來支持了可變長度的塊。復制系數在創建文件時賦值，後續可以更改。文件在任何時候只能有一個writer。NameNode負責塊復制，它周期性收到每個數據節點的心跳和塊報告，心跳錶示數據節點的正常運作，塊報告包含了這個DataNode的所有塊。
副本存儲方案對於HDFS的穩定性和性能至關重要。為了提升數據可靠性、靈活性和充分利用網路帶寬，HDFS引入了機架感知的副本存儲策略，該策略只是副本存儲策略的第一步，為後續優化打下基礎。大型HDFS集群一般運行於橫跨許多支架的計算機集群中，一般情況下同一支架中兩個節點數據傳輸快於不同支架。一種簡單的方法是將副本存放在單獨的機架上，從而防止丟失數據並提高帶寬，但是增加了數據寫入的負擔。一般情況下，復制系數是3，HDFS存儲策略是將第一份副本存儲到本地機器或者同一機架下一個隨機DataNode，另外兩份副本存儲到同一個遠程機架的不同DataNode。NameNode不允許同一DataNode存儲相同副本多次。在機架感知的策略基礎上，後續支持了 存儲類型和機架感知相結合的策略 ，簡單來說就是在機架感知基礎上判斷DataNode是否支持該類型的文件，不支持則尋找下一個。
HDFS讀取數據使用就近原則，首先尋找相同機架上是否存在副本，其次本地數據中心，最後遠程數據中心。
啟動時，NameNode進入安全模式，該模式下不會發生數據塊復制，NameNode接收來自DataNode的心跳和塊報告，每個塊都有一個最小副本數量n，數據塊在NameNode接受到該塊n次後，認為這個數據塊完成安全復制。當完成安全復制的數據塊比例達到一個可配的百分比值並再過30s後，NameNode退出安全模式，最後判斷是否仍然存在未達到最小復制次數的數據塊，並對這些塊進行復制操作。
NameNode使用名為EditLog的事務日誌持續記錄文件系統元數據的每一次改動（如創建文件、改變復制系數），使用名為FsImage的文件存儲全部的文件系統命名空間（包括塊到文件的映射關系和文件系統的相關屬性），EditLog和FsImage都存儲在NameNode本地文件系統中。NameNode在內存中保存著元數據和塊映射的快照，當NameNode啟動後或者某個配置項達到閾值時，會從磁碟中讀取EditLog和FsImage，通過EditLog新的記錄更新內存中的FsImage，再講新版本的FsImage刷新到磁碟中，然後截斷EditLog中已經處理的記錄，這個過程就是一個檢查點。檢查點的目的是確保文件系統通過在內存中使用元數據的快照從而持續的觀察元數據的變更並將快照信息存儲到磁碟FsImage中。檢查點通過下面兩個配置參數出發，時間周期（dfs.namenode.checkpoint.period）和文件系統事務數量（dfs.namenode.checkpoint.txns），二者同時配置時，滿足任意一個條件就會觸發檢查點。
所有的HDFS網路協議都是基於TCP/IP的，客戶端建立一個到NameNode機器的可配置的TCP埠，用於二者之間的交互。DataNode使用DataNode協議和NameNode交互，RPC包裝了客戶端協議和DataNode協議，通過設計，NameNode不會發起RPC，只負責響應來自客戶端或者DataNode的RPC請求。
HDFS的核心目標是即使在失敗或者錯誤情況下依然能夠保證數據可靠性，三種常見失敗情況包括NameNode故障、DataNode故障和network partitions。
網路分區可能會導致部分DataNode市區和NameNode的連接，NameNode通過心跳包判斷並將失去連接的DataNode標記為掛掉狀態，於是所有注冊到掛掉DataNode的數據都不可用了，可能會導致部分數據塊的復制數量低於了原本配置的復制系數。NameNode不斷地追蹤哪些需要復制的塊並在必要時候進行復制，觸發條件包含多種情況：DataNode不可用、復制亂碼、硬體磁碟故障或者認為增大負值系數。為了避免DataNode的狀態不穩定導致的復制風暴，標記DataNode掛掉的超時時間設置比較長（默認10min），用戶可以設置更短的時間間隔來標記DataNode為陳舊狀態從而避免在對讀寫性能要求高的請求上使用這些陳舊節點。
HDFS架構兼容數據各種重新平衡方案，一種方案可以在某個DataNode的空閑空間小於某個閾值時將數據移動到另一個DataNode上；在某個特殊文件突然有高的讀取需求時，一種方式是積極創建額外副本並且平衡集群中的其他數據。這些類型的平衡方案暫時還未實現（不太清楚現有方案是什麼...）。
存儲設備、網路或者軟體的問題都可能導致從DataNode獲取的數據發生亂碼，HDFS客戶端實現了對文件內容的校驗，客戶端在創建文件時，會計算文件中每個塊的校驗值並存儲到命名空間，當客戶端取回數據後會使用校驗值對每個塊進行校驗，如果存在問題，客戶端就會去另一個DataNode獲取這個塊的副本。
FsImage和EditLog是HDFS的核心數據結構，他們的錯誤會導致整個HDFS掛掉，因此，NameNode應該支持時刻維持FsImage和EditLog的多分復制文件，它們的任何改變所有文件應該同步更新。另一個選擇是使用 shared storage on NFS 或者 distributed edit log 支持多個NameNode，官方推薦 distributed edit log 。
快照能夠存儲某一特殊時刻的數據副本，從而支持HDFS在發生錯誤時會滾到上一個穩定版本。
HDFS的應用場景是大的數據集下，且數據只需要寫一次但是要讀取一到多次並且支持流速讀取數據。一般情況下一個塊大小為128MB，因此一個文件被切割成128MB的大塊，且每個快可能分布在不同的DataNode。
當客戶端在復制系數是3的條件下寫數據時，NameNode通過目標選擇演算法收到副本要寫入的DataNode的集合，第1個DataNode開始一部分一部分的獲取數據，把每個部分存儲到本地並轉發給第2個DataNode，第2個DataNode同樣的把每個部分存儲到本地並轉發給第3個DataNode，第3個DataNode將數據存儲到本地，這就是管道復制。
HDFS提供了多種訪問方式，比如 FileSystem Java API 、 C language wrapper for this Java API 和 REST API ，而且還支持瀏覽器直接瀏覽。通過使用 NFS gateway ，客戶端可以在本地文件系統上安裝HDFS。
HDFS使用目錄和文件的方式管理數據，並提供了叫做 FS shell 的命令行介面，下面有一些簡單的命令：
DFSAdmin命令集合用於管理HDFS集群，這些命令只有集群管理員可以使用，下面有一些簡單的命令：
正常的HDFS安裝都會配置一個web服務，通過可配的TCP埠對外暴露命名空間，從而使得用戶可以通過web瀏覽器查看文件內容。
如果垃圾回收配置打開，通過FS shell移除的文件不會立刻刪除，而是會移動到一個垃圾文件專用的目錄（/user/<username>/.Trash），類似回收站，只要文件還存在於那個目錄下，則隨時可以被回復。絕大多數最近刪除的文件都被移動到了垃圾目錄（/user/<username>/.Trash/Current），並且HDFS每個一段時間在這個目錄下創建一個檢查點用於刪除已經過期的舊的檢查點，詳情見 expunge command of FS shell 。在垃圾目錄中的文件過期後，NameNode會刪除這個文件，文件刪除會引起這個文件的所有塊的空間空閑，需要注意的是在文件被刪除之後和HDFS的可用空間變多之間會有一些時間延遲（個人認為是垃圾回收機制佔用的時間）。下面是一些簡單的理解刪除文件的例子：
當文件復制系數減小時，NameNode會選擇多餘的需要刪除的副本，在收到心跳包時將刪除信息發送給DataNode。和上面一樣，這個刪除操作也是需要一些時間後，才能在集群上展現空閑空間的增加。
HDFS Architecture
❺ 如何hadoop distcp ftp目錄中部分文件
hadoop中有一個叫做distcp（分布式復制）的有用程序，能從hadoop的文件系統並行復制大量數據。
distcp一般用於在兩個HDFS集群中傳輸數據。如果集群在hadoop的同一版本上運行，就適合使用hdfs方案：
% hadoop distcp hdfs://namenode1/foo hdfs://namenode2/bar
這將從第一個集群中復制/foo目錄（和它的內容）到第二個集群中的/bar目錄下，所以第二個集群會有/bar/foo目錄結構。如果/bar不存在，則會新建一個。可以指定多個源路徑，並且所有的都會被復制到目標路徑。源路徑必須是絕對路徑。
默認情況下，distcp會跳過目標路徑已經有的文件，但可以通過提供的-overwrite選項進行覆蓋，也可以用-update選項來選擇只更新那些修改過的文件。第一個集群的子樹/foo下的一個文件與第二個集群的改變進行同步。
% hadoop distcp -update hdfs://namenode1/foo hdfs://namenode2/bar/foo
distcp是作為一個MapRece作業執行的，復制工作由集群中並行運行的map來完成。這里沒有recer。每個文件都由一個單一的map進行復制，並且distcp通過將文件分成大致相等的文件來為每個map數量大致相同的數據。
map的數量確定：
通過讓每一個map復制數量合理的數據以最小化任務建立所涉及的開銷，是一個很好的想法，所以每個map的副本至少為256MB。例如，1GB的文件被分成4個map任務。如果數據很大，為限制帶寬和集群的使用而限制映射的數據就變得很有必要。map默認的最大數量是每個集群節點（tasktracker）有20個。例如，復制1000GB的文件到一個100個節點的集群，會分配2000個map（每個節點20個map），所以平均每個會復制512MB。通過對distcp指定-m參數，會減少映射的分配數量。例如，-m 1000會分配1000個map，平均每個復制1GB。
如果想在兩個運行著不同版本HDFS的集群上利用distcp，使用hdfs協議是會失敗的，因為RPC系統是不兼容的。想要彌補這種情況，可以使用基於HTTP的HFTP文件系統從源中進行讀取。這個作業必須運行在目標集群上，使得HDFS RPC版本是兼容的。使用HFTP重復前面的例子：% hadoop distcp hftp://namenode1:50070/foo hdfs://namenode2/bar
注意，需要在URI源中指定名稱節點的Web埠。這是由dfs.http.address的屬性決定的，默認值為50070。
保持HDFS集群的平衡
向HDFS復制數據時，考慮集群的平衡相當重要。文件塊在集群中均勻地分布時，HDFS能達到最佳工作狀態。回顧前面1000 GB數據的例子，通過指定-m選項為1，即由一個單一的map執行復制工作，它的意思是，不考慮速度變慢和未充分利用集群資源，每個塊的第一個副本會存儲在運行map的節點上(直到磁碟被填滿)。第二和第三個副本分散在集群中，但這一個節點並不會平衡。通過讓map的數量多於集群中節點的數量，我們便可避免這個問題。鑒於此，最好首先就用默認的每個節點20個map這個默認設置來運行distcp。
然而，這也並不總能阻止一個集群變得不平衡。也許想限制map的數量以便一些節點可以被其他作業使用。若是這樣，可以使用balancer工具繼續改善集群中塊的分布。
❻ hadoop上傳問題
是不是hdfs空間滿了，還有是不是上傳的 文件路徑 都是相同的啊，如果是相同的，就是在對同一文件進行put
http://www.linuxidc.com/Linux/2012-02/54888.htm
在數據上傳的客戶端hadoop- site.xml里修改配置參數 dfs.socket.timeout（默認十分鍾），之後重新運行大批量的數據上傳操作，問題不再重現：）
❼ hadoop2 VS hadoop3 功能對比
1.目的
在這篇文章中，我們將討論Hadoop 2.x與Hadoop 3.x之間的比較。 Hadoop3版本中添加了哪些新功能，Hadoop3中兼容的Hadoop 2程序，Hadoop 2和Hadoop 3有什麼區別？ 我們希望Hadoop 2和Hadoop 3之間的這個功能的區別將幫助回答上述問題。
2.1License
Hadoop 2.x - Apache 2.0，開源
Hadoop 3.x - Apache 2.0，開源
2.2支持的最低Java版本
Hadoop 2.x - java的最低支持版本是java 7
Hadoop 3.x - java的最低支持版本是java 8
2.3容錯
Hadoop 2.x - 可以通過復制（浪費空間）來處理容錯。
Hadoop 3.x - 可以通過Erasure編碼處理容錯。
2.4數據平衡
Hadoop 2.x - 對於數據，平衡使用HDFS平衡器。
Hadoop 3.x - 對於數據，平衡使用Intra-data節點平衡器，該平衡器通過HDFS磁碟平衡器CLI調用。
2.5存儲Scheme
Hadoop 2.x - 使用3X副本Scheme
Hadoop 3.x - 支持HDFS中的擦除編碼。
2.6存儲開銷
Hadoop 2.x - HDFS在存儲空間中有200％的開銷。
Hadoop 3.x - 存儲開銷僅為50％。
2.7存儲開銷示例
Hadoop 2.x - 如果有6個塊，那麼由於副本方案（Scheme），將有18個塊佔用空間。
Hadoop 3.x - 如果有6個塊，那麼將有9個塊佔用6塊空間，3個用於奇偶校驗。
2.8YARN時間線服務
Hadoop 2.x - 使用具有可伸縮性問題的舊時間軸服務。
Hadoop 3.x - 改進時間線服務v2並提高時間線服務的可擴展性和可靠性。
2.9默認埠范圍
Hadoop 2.x - 在Hadoop 2.0中，一些默認埠是Linux臨時埠范圍。所以在啟動時，他們將無法綁定。
Hadoop 3.x - 但是在Hadoop 3.0中，這些埠已經移出了短暫的范圍。
2.10工具
Hadoop 2.x - 使用Hive，pig，Tez，Hama，Giraph和其他Hadoop工具。
Hadoop 3.x - 可以使用Hive，pig，Tez，Hama，Giraph和其他Hadoop工具。
2.11兼容的文件系統
Hadoop 2.x - HDFS（默認FS），FTP文件系統：它將所有數據存儲在可遠程訪問的FTP伺服器上。 Amazon S3（簡單存儲服務）文件系統Windows Azure存儲Blob（WASB）文件系統。
Hadoop 3.x - 它支持所有前面以及Microsoft Azure Data Lake文件系統。
2.12Datanode資源
Hadoop 2.x - Datanode資源不專用於MapRece，我們可以將它用於其他應用程序。
Hadoop 3.x - 此處數據節點資源也可用於其他應用程序。
2.13MR API兼容性
Hadoop 2.x - 與Hadoop 1.x程序兼容的MR API，可在Hadoop 2.X上執行
Hadoop 3.x - 此處，MR API與運行Hadoop 1.x程序兼容，以便在Hadoop 3.X上執行
2.14支持Microsoft Windows
Hadoop 2.x - 它可以部署在Windows上。
Hadoop 3.x - 它也支持Microsoft Windows。
2.15插槽/容器
Hadoop 2.x - Hadoop 1適用於插槽的概念，但Hadoop 2.X適用於容器的概念。通過容器，我們可以運行通用任務。
Hadoop 3.x - 它也適用於容器的概念。
2.16單點故障
Hadoop 2.x - 具有SPOF的功能，因此只要Namenode失敗，它就會自動恢復。
Hadoop 3.x - 具有SPOF的功能，因此只要Namenode失敗，它就會自動恢復，無需人工干預就可以克服它。
2.17HDFS聯盟
Hadoop 2.x - 在Hadoop 1.0中，只有一個NameNode來管理所有Namespace，但在Hadoop 2.0中，多個NameNode用於多個Namespace。
Hadoop 3.x - Hadoop 3.x還有多個名稱空間用於多個名稱空間。
2.18可擴展性
Hadoop 2.x - 我們可以擴展到每個群集10,000個節點。
Hadoop 3.x - 更好的可擴展性。 我們可以為每個群集擴展超過10,000個節點。
2.19更快地訪問數據
Hadoop 2.x - 由於數據節點緩存，我們可以快速訪問數據。
Hadoop 3.x - 這里也通過Datanode緩存我們可以快速訪問數據。
2.20HDFS快照
Hadoop 2.x - Hadoop 2增加了對快照的支持。 它為用戶錯誤提供災難恢復和保護。
Hadoop 3.x - Hadoop 2也支持快照功能。
2.21平台
Hadoop 2.x - 可以作為各種數據分析的平台，可以運行事件處理，流媒體和實時操作。
Hadoop 3.x - 這里也可以在YARN的頂部運行事件處理，流媒體和實時操作。
2.22群集資源管理
Hadoop 2.x - 對於群集資源管理，它使用YARN。 它提高了可擴展性，高可用性，多租戶。
Hadoop 3.x - 對於集群，資源管理使用具有所有功能的YARN。
3.結論
正如我們已經討論了Hadoop 2.x與Hadoop 3.x之間的22個重要差異，現在我們可以看到Hadoop 2和Hadoop 3哪個更好。
❽ Hadoop（一) HDFS概念及原理總結
HDFS的文件讀取原理，主要包括以下幾個步驟：
1、首先調用FileSystem對象的open方法，其實獲取的是一個DistributedFileSystem的實例。
2、DistributedFileSystem通過RPC(遠程過程調用)獲得文件的第一批block的locations，同一block按照重復數會返回多個locations，這些locations按照hadoop拓撲結構排序，距離客戶端近的排在前面。
3、前兩步會返回一個FSDataInputStream對象，該對象會被封裝成 DFSInputStream對象，DFSInputStream可以方便的管理datanode和namenode數據流。客戶端調用read方法，DFSInputStream就會找出離客戶端最近的datanode並連接datanode。
4、數據從datanode源源不斷的流向客戶端。
5、如果第一個block塊的數據讀完了，就會關閉指向第一個block塊的datanode連接，接著讀取下一個block塊。這些操作對客戶端來說是透明的，從客戶端的角度來看只是讀一個持續不斷的流。
6、如果第一批block都讀完了，DFSInputStream就會去namenode拿下一批blocks的location，然後繼續讀，如果所有的block塊都讀完，這時就會關閉掉所有的流。
HDFS的文件寫入原理，主要包括以下幾個步驟：
1、客戶端通過調用 DistributedFileSystem 的create方法，創建一個新的文件。
2、DistributedFileSystem 通過 RPC（遠程過程調用）調用 NameNode，去創建一個沒有blocks關聯的新文件。創建前，NameNode 會做各種校驗，比如文件是否存在，客戶端有無許可權去創建等。如果校驗通過，NameNode 就會記錄下新文件，否則就會拋出IO異常。
3、前兩步結束後會返回 FSDataOutputStream 的對象，和讀文件的時候相似，FSDataOutputStream 被封裝成 DFSOutputStream，DFSOutputStream 可以協調 NameNode和 DataNode。客戶端開始寫數據到DFSOutputStream,DFSOutputStream會把數據切成一個個小packet，然後排成隊列 data queue。
4、DataStreamer 會去處理接受 data queue，它先問詢 NameNode 這個新的 block 最適合存儲的在哪幾個DataNode里，比如重復數是3，那麼就找到3個最適合的 DataNode，把它們排成一個 pipeline。DataStreamer 把 packet 按隊列輸出到管道的第一個 DataNode 中，第一個 DataNode又把 packet 輸出到第二個 DataNode 中，以此類推。
5、DFSOutputStream 還有一個隊列叫 ack queue，也是由 packet 組成，等待DataNode的收到響應，當pipeline中的所有DataNode都表示已經收到的時候，這時akc queue才會把對應的packet包移除掉。
6、客戶端完成寫數據後，調用close方法關閉寫入流。
7、DataStreamer 把剩餘的包都刷到 pipeline 里，然後等待 ack 信息，收到最後一個 ack 後，通知 DataNode 把文件標示為已完成。
❾ 資料庫與hadoop與分布式文件系統的區別和聯系
資料庫與hadoop與分布式文件系統的區別和聯系
1. 用向外擴展代替向上擴展
擴展商用關系型資料庫的代價是非常昂貴的。它們的設計更容易向上擴展。要運行一個更大
的資料庫，就需要買一個更大的機器。事實上，往往會看到伺服器廠商在市場上將其昂貴的高端機
標稱為「資料庫級的伺服器」。不過有時可能需要處理更大的數據集，卻找不到一個足夠大的機器。
更重要的是，高端的機器對於許多應用並不經濟。例如，性能4倍於標准PC的機器，其成本將大大
超過將同樣的4台PC放在一個集群中。Hadoop的設計就是為了能夠在商用PC集群上實現向外擴展
的架構。添加更多的資源，對於Hadoop集群就是增加更多的機器。一個Hadoop集群的標配是十至
數百台計算機。事實上，如果不是為了開發目的，沒有理由在單個伺服器上運行Hadoop。
2. 用鍵/值對代替關系表
關系資料庫的一個基本原則是讓數據按某種模式存放在具有關系型數據結構的表中。雖然關
系模型具有大量形式化的屬性，但是許多當前的應用所處理的數據類型並不能很好地適合這個模
型。文本、圖片和XML文件是最典型的例子。此外，大型數據集往往是非結構化或半結構化的。
Hadoop使用鍵/值對作為基本數據單元，可足夠靈活地處理較少結構化的數據類型。在hadoop中，
數據的來源可以有任何形式，但最終會轉化為鍵/值對以供處理。
3. 用函數式編程（MapRece）代替聲明式查詢（SQL ）
SQL 從根本上說是一個高級聲明式語言。查詢數據的手段是，聲明想要的查詢結果並讓資料庫引擎
判定如何獲取數據。在MapRece中，實際的數據處理步驟是由你指定的，它很類似於SQL
引擎的一個執行計劃。SQL 使用查詢語句，而MapRece則使用腳本和代碼。利用MapRece可
以用比SQL 查詢更為一般化的數據處理方式。例如，你可以建立復雜的數據統計模型，或者改變
圖像數據的格式。而SQL 就不能很好地適應這些任務。
4.
分布式文件系統（dfs）和分布式資料庫都支持存入，取出和刪除。但是分布式文件系統比較暴力，
可以當做key/value的存取。分布式資料庫涉及精煉的數據，傳統的分布式關系型資料庫會定義數據元
組的schema，存入取出刪除的粒度較小。
分布式文件系統現在比較出名的有GFS（未開源），HDFS（Hadoop distributed file system）。
分布式資料庫現在出名的有Hbase，oceanbase。其中Hbase是基於HDFS，而oceanbase是自己內部
實現的分布式文件系統，在此也可以說分布式資料庫以分布式文件系統做基礎存儲。
共享文件與分布式文件系統的區別
分布式文件系統(Distributed File System，DFS)
如果區域網中有多台伺服器，並且共享文件夾也分布在不同的伺服器上，這就不利於管理員的管理和用戶的訪問。而使用分布式文件系統,系統管理員就可以把不同伺服器上的共享文件夾組織在一起，構建成一個目錄樹。這在用戶看來，所有共享文件僅存儲在一個地點，只需訪問一個共享的DFS根目錄，就能夠訪問分布在網路上的文件或文件夾，而不必知道這些文件的實際物理位置。
ftp server和分布式文件系統的區別
換個思路，使用mount --bind把目錄載入過來就可以了 先將數據盤掛載 mount /dev/sdb1 /mnt/d 在ftp目錄下建一個文件夾data mount --bind /mnt/d data
FTP server和分布式文件系統的區別, 分布式文件系統和分布式資料庫有什麼不同
分布式文件系統（dfs）和分布式資料庫都支持存入，取出和刪除。但是分布式文件系統比較暴力，可以當做key/value的存取。分布式資料庫涉及精煉的數據，傳統的分布式關系型資料庫會定義數據元組的schema，存入取出刪除的粒度較小。
分布式文件系統現在比較出名的有GFS（未開源），HDFS（Hadoop distributed file system）。分布式資料庫現在出名的有Hbase，oceanbase。其中Hbase是基於HDFS，而oceanbase是自己內部實現的分布式文件系統，在此也可以說分布式資料庫以分布式文件系統做基礎存儲。
hadoop是分布式文件系統嗎
是的
Hadoop分布式文件系統(HDFS)是一種被設計成適合運行在通用硬體上的分布式文件系統。HDFS是一個高度容錯性的系統，適合部署在廉價的機器上。它能提供高吞吐量的數據訪問，非常適合大規模數據集上的應用。要理解HDFS的內部工作原理，首先要理解什麼是分布式文件系統。
1.分布式文件系統
多台計算機聯網協同工作(有時也稱為一個集群)就像單台系統一樣解決某種問題，這樣的系統我們稱之為分布式系統。
分布式文件系統是分布式系統的一個子集，它們解決的問題就是數據存儲。換句話說，它們是橫跨在多台計算機上的存儲系統。存儲在分布式文件系統上的數據自動分布在不同的節點上。
分布式文件系統在大數據時代有著廣泛的應用前景，它們為存儲和處理來自網路和其它地方的超大規模數據提供所需的擴展能力。
2.分離元數據和數據：NameNode和DataNode
存儲到文件系統中的每個文件都有相關聯的元數據。元數據包括了文件名、i節點(inode)數、數據塊位置等，而數據則是文件的實際內容。
在傳統的文件系統里，因為文件系統不會跨越多台機器，元數據和數據存儲在同一台機器上。
為了構建一個分布式文件系統，讓客戶端在這種系統中使用簡單，並且不需要知道其他客戶端的活動，那幺元數據需要在客戶端以外維護。HDFS的設計理念是拿出一台或多台機器來保存元數據，並讓剩下的機器來保存文件的內容。
NameNode和DataNode是HDFS的兩個主要組件。其中，元數據存儲在NameNode上，而數據存儲在DataNode的集群上。NameNode不僅要管理存儲在HDFS上內容的元數據，而且要記錄一些事情，比如哪些節點是集群的一部分，某個文件有幾份副本等。它還要決定當集群的節點宕機或者數據副本丟失的時候系統需要做什麼。
存儲在HDFS上的每份數據片有多份副本(replica)保存在不同的伺服器上。在本質上，NameNode是HDFS的Master(主伺服器)，DataNode是Slave(從伺服器)。
文件系統與資料庫系統的區別和聯系
其區別在於：
(1)
文件系統用文件將數據長期保存在外存上，數
據庫系統用資料庫統一存儲數據。
(2)
文件系統中的程序和數據有一
定的聯系，資料庫系統中的程序和數據分離。
(3)
文件系統用操作系
統中的存取方法對數據進行管理，資料庫系統用
DBMS
統一管理和控
制數據。
(4)
文件系統實現以文件為單位的數據共享，資料庫系統實
現以記錄和欄位為單位的數據共享。
其聯系在於：
(1)
均為數據組織的管理技術。
(2)
均由數據管理軟
件管理數據，程序與數據之間用存取方法進行轉換。
(3)
資料庫系統
是在文件系統的基礎上發展而來的。
資料庫系統和文件系統的區別與聯系
文件系統和資料庫系統之間的區別：
（1） 文件系統用文件將數據長期保存在外存上，資料庫系統用資料庫統一存儲數據；
（2） 文件系統中的程序和數據有一定的聯系，資料庫系統中的程序和數據分離；
（3） 文件系統用操作系統中的存取方法對數據進行管理，資料庫系統用DBMS統一管理和控制數據；
（4） 文件系統實現以文件為單位的數據共享，資料庫系統實現以記錄和欄位為單位的數據共享。
文件系統和資料庫系統之間的聯系：
（1） 均為數據組織的管理技術；
（2） 均由數據管理軟體管理數據，程序與數據之間用存取方法進行轉換；
（3） 資料庫系統是在文件系統的基礎上發展而來的。
什麼是Hadoop分布式文件系統
分布式文件系統（Distributed File System）是指文件系統管理的物理存儲資源不一定直接連接在本地節點上，而是通過計算機網路與節點相連。
Hadoop是Apache軟體基金會所研發的開放源碼並行運算編程工具和分散式檔案系統，與MapRece和Google檔案系統的概念類似。
HDFS（Hadoop 分布式文件系統）是其中的一部分。