1. hadoop內部表直接添加文件
方法如下:
1、添加本地文件到hdfs目錄:hadoopfs-put的命令後面的第一個參數是本地路徑,第二個參數是hadoopHDFS上的路徑,意思就是將本地路徑載入到HDFS上。
2、創建文件夾:在hadoop的HDFS上創建文件夾。
3、上面命令在HDFS的tmp目錄下穿件了input文件夾。
2. HDFS常用命令
hdfs dfs -linux命令 操作是一樣
hadoop fs 等同於 hdfs dfs
如果壓縮是false,一般需要自己編譯 支持壓縮,如果是使用CDH系列的,不用擔心 。
自己編譯可參考: https://segmentfault.com/a/1190000038464476?utm_source=sf-similar-article
hadoop 3.2.2的版本dfs.disk.balancer.enabled默認為true,以前的老版本默認值是false,這個參數可以在hdfs-site.xml 中修改。
命令:
hdfs diskbalancer -plan hadoop001 #生成計劃
hdfs diskbalancer -execute hadoop001.plan.json #執行計劃
3. HDFS文件
Hadoop支持的文件系統由很多(見下圖),HDFS只是其中一種實現。java抽象類 org.apache.hadoop.fs.FileSystem 定義了Hadoop中一個文件系統的客戶端介面,並且該抽象類有幾個具體實現。Hadoop一般使用URI(下圖)方案來選取合適的文件系統實例進行交互。
特別的,HDFS文件系統的操作可以使用 FsSystem shell 、客戶端(http rest api、Java api、C api等)。
FsSystem shell 的用法基本同本地shell類似,命令可參考 FsSystem shell
Hadoop是用Java寫的,通過Java Api( FileSystem 類)可以調用大部分Hadoop文件系統的交互操作。更詳細的介紹可參考 hadoop Filesystem 。
非Java開發的應用可以使用由WebHDFS協議提供的HTTP REST API,但是HTTP比原生的Java客戶端要慢,所以不到萬不得已盡量不要使用HTTP傳輸特大數據。通過HTTP來訪問HDFS有兩種方法:
兩種如圖
在第一種情況中,namenode和datanode內嵌的web服務作為WebHDFS的端節點運行(是否啟用WebHDFS可通過dfs.webhdfs.enabled設置,默認為true)。文件元數據在namenode上,文件讀寫操作首先被發往namenode,有namenode發送一個HTTP重定向至某個客戶端,指示以流的方式傳輸文件數據的目的或源datanode。
第二種方法依靠一個或多個獨立代理伺服器通過HTTP訪問HDFS。所有集群的網路通信都需要通過代理,因此客戶端從來不直接訪問namenode或datanode。使用代理後可以使用更嚴格的防火牆策略和帶寬策略。
HttpFs代理提供和WebHDFS相同的HTTP介面,這樣客戶端能夠通過webhdfs URI訪問介面。HttpFS代理啟動獨立於namenode和datanode的守護進程,使用httpfs.sh 腳本,默認在一個不同的埠上監聽(14000)。
下圖描述了
讀文件時客戶端與 HDFS 中的 namenode, datanode 之間的數據流動。
對上圖的解釋如下:
在讀取過程中, 如果 FSDataInputStream 在和一個 datanode 進行交流時出現了一個錯誤,他就去試一試下一個最接近的塊,他當然也會記住剛才發生錯誤的 datanode 以至於之後不會再在這個 datanode 上進行沒必要的嘗試。 DFSInputStream 也會在 datanode 上傳輸出的數據上核查檢查數(checknums).如果損壞的塊被發現了, DFSInputStream 就試圖從另一個擁有備份的 datanode 中去讀取備份塊中的數據。
在這個設計中一個重要的方面就是客戶端直接從 datanode 上檢索數據,並通過 namenode 指導來得到每一個塊的最佳 datanode。這種設計允許 HDFS 擴展大量的並發客戶端,因為數據傳輸只是集群上的所有 datanode 展開的。期間,namenode 僅僅只需要服務於獲取塊位置的請求(塊位置信息是存放在內存中,所以效率很高)。如果不這樣設計,隨著客戶端數據量的增長,數據服務就會很快成為一個瓶頸。
我們知道,相對於客戶端(之後就是 maprece task 了),塊的位置有以下可能性:
我們認為他們對於客戶端的帶寬遞減,距離遞增(括弧中表示距離)。示意圖如下:
如果集群中的機器都在同一個機架上,我們無需其他配置,若集群比較復雜,由於hadoop無法自動發現網路拓撲,所以需要額外配置網路拓撲。
基本讀取程序,將文件內容輸出到console
FileSystemCat
隨機讀取
展開原碼
下圖描述了寫文件時客戶端與 HDFS 中的 namenode, datanode 之間的數據流動。
對上圖的解釋如下:
如果在任何一個 datanode 在寫入數據的時候失敗了,接下來所做的一切對客戶端都是透明的:首先, pipeline 被關閉,在確認隊列中的剩下的包會被添加進數據隊列的起始位置上,以至於在失敗的節點下游的任 何節點都不會丟失任何的包。然後與 namenode 聯系後,當前在一個好的 datanode 會聯系 namenode, 給失敗節點上還未寫完的塊生成一個新的標識ID, 以至於如果這個失敗的 datanode 不久後恢復了,這個不完整的塊將會被刪除。失敗節點會從 pipeline 中移除,然後剩下兩個好的 datanode 會組成一個的新的 pipeline ,剩下的 這些塊的包(也就是剛才放在數據隊列隊首的包)會繼續寫進 pipeline 中好的 datanode 中。最後,namenode 注意到塊備份數小於規定的備份數,他就安排在另一個節點上創建完成備份,直接從已有的塊中復制就可以。然後一直到滿足了備份數( dfs.replication )。如果有多個節點的寫入失敗了,如果滿足了最小備份數的設置( dfs.namenode.repliction.min ),寫入也將會成功,然後剩下的備份會被集群非同步的執行備份,直到滿足了備份數( dfs.replication )。
創建目錄
文件壓縮有兩大好處:
Hadoop 對於壓縮格式的是自動識別。如果我們壓縮的文件有相應壓縮格式的擴展名(比如 lzo,gz,bzip2 等)。Hadoop 會根據壓縮格式的擴展名自動選擇相對應的解碼器來解壓數據,此過程完全是 Hadoop 自動處理,我們只需要確保輸入的壓縮文件有擴展名。
Hadoop中有多種壓縮格式、演算法和工具,下圖列出了常用的壓縮方法。
表中的「是否可切分」表示對應的壓縮演算法是否支持切分,也就是說是否可以搜索數據流的任意位置並進一步往下讀取數據,可切分的壓縮格式尤其適合MapRece。
所有的壓縮演算法都需要權衡空間/時間:壓縮和解壓縮速度更快,其代價通常是只能節省少量的空間。不同的壓縮工具有不同的特性:
更詳細的比較如下
1.壓縮性能比較
2.優缺點
另外使用hadoop原生(native)類庫比其他java實現有更快的壓縮和解壓縮速度。特徵比較如下:
使用容器文件格式結合壓縮演算法也能更好的提高效率。順序文件、Arvo文件、ORCFiles、Parqurt文件同時支持壓縮和切分。
壓縮舉例(Java)
壓縮
解壓縮
六、文件序列化
序列化是指將結構化數據轉換為位元組流以便在網路上傳輸或寫到磁碟進行永久存儲。反序列化獅子將位元組流轉換回結構化對象的逆過程。
序列化用於分布式數據處理的兩大領域:進程間通信和永久存儲。
對序列化的要求時是格式緊湊(高效使用存儲空間)、快速(讀寫效率高)、可擴展(可以透明地讀取老格式數據)且可以互操作(可以使用不同的語言讀寫數據)。
Hadoop使用的是自己的序列化格式 Writable ,它絕對緊湊、速度快,但不太容易用java以外的語言進行擴展或使用。
當然,用戶也可以使用其他序列化框架或者自定義序列化方式,如 Avro 框架。
Hadoop內部還使用了 Apache Thrift 和 Protocal Buffers 來實現RPC和數據交換。
4. hdfs命令查找文件所在路徑
指令
hadoop fsck /user/hadoop/filename -files -blocks -locations -racks
-files 文件分塊信息,
-blocks 在帶-files參數後才顯示block信息
-locations 在帶-blocks參數後才顯示block塊所在datanode的具體IP位置,
-racks 在帶-files參數後顯示機架位置
注意:此命令只能在namenode里輸入,在datanode里輸入會報錯的
5. hadoop面試題之HDFS
1、簡單介紹下hadoop吧?
廣義上hadoop是指與hadoop相關的大數據生態圈。包含hive、spark、hbase等。
狹義上hadoop指的是apache的開源框架。有三個核心組件:
----hdfs:分布式文件存儲系統
----yarn:分布式資源管理調度平台
----mr:分布式計算引擎
2、介紹下hdfs?
全稱為Hadoop Distributed File System。有三個核心組件:
namenode:有三個作用,第一是負責保存集群的元數據信息,第二是負責維護整個集群節點的正常運行。
第三是負責處理客戶端的請求。
datanode:負責實際保存數據。實際執行數據塊的讀寫操作。
secondarynamenode:輔助namenode進行元數據的管理。不是namenode的備份。
3、namenode的工作機制?
namenode在內存中保存著整個內存系統的名稱空間和文件數據塊的地址映射。整個hdfs可存儲的文件數受限於namenode的內存大小。所以hdfs不適合大量小文件的存儲。
---namenode有三種元數據存儲方式來管理元數據:
》內存元數據:內存中保存了完整的元數據
》保存在磁碟上的元數據鏡像文件(fsimage):該文件時hdfs存在磁碟中的元數據檢查點,裡面保存的是最後一次檢查點之前的hdfs文件系統中所有目錄和文件的序列化信息。
》數據操作日誌文件(edits):用於銜接內存meta data和持久化元數據鏡像fsimage之間的操作日誌文件。保存了自最後一次檢查點之後所有針對hdfs文件系統的操作。如對文件的增刪改查。
4、如何查看元數據信息?
因為edits和fsimage文件是經過序列化的,所以不能直接查看。hadoop2.0以上提供了查看兩種文件的工具。
----命令:hdfs oiv 可以將fsimage文件轉換成其他格式,如xml和文本文件。-i 表示輸入fsimage文件。-o 輸出文件路徑,-p 指定輸出文件
hdfs oev可以查看edits文件。同理需要指定相關參數。
詳情查看: https://www.imooc.com/article/79705
4、datanode的工作機制?
1)以數據塊的形式存儲hdfs文件
2)datanode響應客戶端的讀寫請求
3)周期性的向namenode匯報心跳信息、數據塊信息、緩存數據塊信息
5、secondary namenode工作機制?
當發生checkpoint機制時會觸發second namenode進行工作。checkpoint:
新的edists文件不會立即和fsimage文件合並,是在edits文件大小超過(默認)64m,或者時間超過(默認)1小時,會觸發checkpoint操作。當checkpoint時,namenode會新建一個edits.new的文件,此時second namenode將文件fsimage文件和edits文件(http get)到本地,然後載入到內存中進行合並,完成的文件名稱為fsimage.ckpt。最後 second namenode將該文件(http post)到namenode,然後edits.new和fsimage.ckpt文件轉換為fsimage和edits。
6、hdfs的文件副本機制?
所有的文件都是以塊的形式保存到hdfs中。塊的大小默認為128m。在hdfs-site文件中進行指定。
動態副本創建策略:默認副本數是3,可以在上傳文件時,顯式設定replication。也可以通過指令修改文件的副本數 hadoop fs -setrep -R 1
7、為實現高可用,hdfs採用了哪些策略?
副本機制、機架感知、心跳機制、安全模式、校驗和、回收站、元數據保護、快照機制(具體介紹導航- https://www.jianshu.com/writer#/notebooks/44567747/notes/66453316 )
8、hdfs的存儲過程?
①client向hdfs發起寫請求,通過RPC與namenode建立通訊。namenode檢查文件是否存在等信息,返回是否可以存儲。
②client將文件切割為一個個block塊,client申請存儲第一塊block。namenode返回可以存儲這個block塊的datanode的地址,假設為ABC。
③A到B到C逐級構建pipeline。client向A上傳第一個packet,默認為64k。A收到一個packet後會將packet傳給B,再傳給C。pipeline反方向返回ack信息。最終由第一個節點A將pipelineack發送給client
④一個block完成之後,再進行下一個block的存儲過程。
9、hdfs的讀過程?
10、hdfs的垃圾桶機制?
hdfs的垃圾桶機制默認是關閉的,需要手動開啟。hdfs刪除的文件不會立刻就刪除,而是在設定的時間後進行刪除。
11、hdfs的擴容和縮容
【
12、
6. spark、hive、impala、hdfs的常用命令
對spark、hive、impala、hdfs的常用命令作了如下總結,歡迎大家補充!
1. Spark的使用:
以通過SecureCRT訪問IP地址:10.10.234.198 為例進行說明:
先輸入:ll //查詢集群是否裝有spark
>su - mr
>/home/mr/spark/bin/beeline -u "jdbc:hive2:/bigdata198:18000/" -n mr -p ""
>show databases; //顯示其中資料庫,例如
>use bigmax; //使用資料庫bigmax
>show tables; //查詢目錄中所有的表
>desc formatted TableName; //顯示表的詳細信息,包括分區、欄位、地址等信息
>desc TableName; //顯示表中的欄位和分區信息
>select count(*) from TableName; //顯示表中數據數量,可以用來判斷表是否為空
>drop table TableName; //刪除表的信息
>drop bigmax //刪除資料庫bigmax
>describe database zxvmax //查詢資料庫zxvmax信息
創建一個表
第一步:
>create external table if not exists lte_Amaze //創建一個叫lte_Amaze的表
( //括弧中每一行為表中的各個欄位的名稱和其所屬的數據類型,並用空格隔開
DateTime String,
MilliSec int,
Network int,
eNodeBID int,
CID int,
IMSI String,
DataType int,
AoA int,
ServerRsrp int,
ServerRsrq int,
TA int,
Cqi0 Tinyint,
Cqi1 Tinyint //注意,最後一個欄位結束後,沒有逗號
)
partitioned by (p_date string, p_hour INT) //以p_date和p_hour作為分區
row format delimited fields terminated by ',' /*/*表中行結構是以逗號作為分隔符,與上邊的表中欄位以逗號結尾相一致*/
stored as textfile; //以文本格式進行保存
第二步:添加分區,指定分區的位置
>alter table lte_Amaze add partition (p_date='2015-01-27',p_hour=0) location'/lte/nds/mr/lte_nds_cdt_uedetail/p_date=2015-01-27/p_hour=0';
//添加lte_Amaze表中分區信息,進行賦值。
//並制定分區對應目錄/lte/nds/mr下表lte_nds_cdt_uedetail中對應分區信息
第三步:察看添加的結果
>show partitions lte_Amaze; //顯示表的分區信息
2. hdfs使用:
#su - hdfs //切換到hdfs用戶下 、
#hadoop fs –ls ///查看進程
# cd /hdfs/bin //進入hdfs安裝bin目錄
>hadoop fs -ls /umtsd/cdt/ //查詢/umtsd/cdt/文件目錄
>hadoop fs -mkdir /umtsd/test //在/umtsd目錄下創建test目錄
>hadoop fs -put /home/data/u1002.csv /impala/data/u5002 //將home/data/u1002.csv這個文件put到hdfs文件目錄上。put到hdfs上的數據文件以逗號「,」分隔符文件(csv),數據不論類型,直接是數據,沒有雙引號和單引號
>hadoop fs -rm /umtsd/test/test.txt //刪除umtsd/test目錄下的test.txt文件
>hadoop fs -cat /umtsd/test/test.txt //查看umtsd/test目錄下的test.txt文件內容
3hive操作使用:
#su - mr //切換到mr用戶下
#hive //進入hive查詢操作界面
hive>show tables; //查詢當前創建的所有表
hive>show databases; //查詢當前創建的資料庫
hive>describe table_name; {或者desc table_name}//查看錶的欄位的定義和分區信息,有明確區分(impala下該命令把分區信息以欄位的形式顯示出來,不怎麼好區分)
hive> show partitions table_name; //查看錶對應數據現有的分區信息,impala下沒有該命令
hive> quit;//退出hive操作界面
hive>desc formatted table_name; 查看錶結構,分隔符等信息
hive> alter table ceshi change id id int; 修改表的列數據類型 //將id數據類型修改為int 注意是兩個id
hive> SHOW TABLES '.*s'; 按正條件(正則表達式)顯示表,
[mr@aico ~]$ exit; 退出mr用戶操作界面,到[root@aico]界面
impala操作使用:
#su - mr //切換到mr用戶下
#cd impala/bin //進入impala安裝bin目錄
#/impala/bin> impala-shell.sh -i 10.10.234.166/localhost //進入impala查詢操作界面
[10.10.234.166:21000] >show databases; //查詢當前創建的資料庫
[10.10.234.166:21000] >use database_name; //選擇使用資料庫,默認情況下是使用default資料庫
[10.10.234.166:21000] > show tables; //查詢當前資料庫下創建的所有表
[10.10.234.166:21000] >describe table_name; //查看錶的欄位的定義,包括分區信息,沒有明確區分
[10.10.234.166:21000] > describe formatted table_name; //查看錶對應格式化信息,包括分區,所屬資料庫,創建用戶,創建時間等詳細信息。
[10.10.234.166:21000] >refresh table_name; //刷新一下,保證元數據是最新的
[10.10.234.166:21000] > alter TABLE U107 ADD PARTITION(reportDate="2013-09-27",rncid=487)LOCATION '/umts/cdt/
MREMITABLE/20130927/rncid=487' //添加分區信息,具體的表和數據的對應關系
[10.10.234.166:21000] > alter TABLE U100 drop PARTITION(reportDate="2013-09-25",rncid=487); //刪除現有的分區,數據與表的關聯
[10.10.234.166:21000] >quit; //退出impala操作界面
[mr@aicod bin]$ impala-shell; 得到welcome impala的信息,進入impala 查詢操作界面
[aicod:21000] > 按兩次tab鍵,查看可以用的命令
alter describe help profile shell values
connect drop history quit show version
create exit insert select unset with
desc explain load set use
7. 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導致兩邊不一致,當然,該命令是主要用於集群間拷貝的。
適用場景:大量文件或大文件的拷貝。
8. HDFS中根目錄下創建user文件夾的命令為
HDFS中根目錄下創建user文件夾的命令為hadoop dfs-mkdir。在hdfs中創建一個input文件夾:hadoopfs-mkdir/input/1、使用參數-p創建多級目錄:hadoopfs-mkdir-p/input/file1。拷貝input目錄到hdfs系統的時候,不是採用的hadoop用戶,而是用root用戶執行的拷貝命令。
hdfs的特點和目標:
1、硬體故障
硬體故障是常態,而不是異常。整個HDFS系統將由數百或數千個存儲著文件數據片段的伺服器組成。實際上它裡面有非常巨大的組成部分,每一個組成部分都很可能出現故障,這就意味著HDFS里的總是有一些部件是失效的,因此,故障的檢測和自動快速恢復是HDFS一個很核心的設計目標。
2、數據訪問
運行在HDFS之上的應用程序必須流式地訪問它們的數據集,它不是運行在普通文件系統之上的普通程序。HDFS被設計成適合批量處理的,而不是用戶互動式的。重點是在數據吞吐量,而不是數據訪問的反應時間,POSIX的很多硬性需求對於HDFS應用都是非必須的,去掉POSIX一小部分關鍵語義可以獲得更好的數據吞吐率。
3、大數據集
運行在HDFS之上的程序有很大量的數據集。典型的HDFS文件大小是GB到TB的級別。所以,HDFS被調整成支持大文件。它應該提供很高的聚合數據帶寬,一個集群中支持數百個節點,一個集群中還應該支持千萬級別的文件。
以上內容參考:網路-hdfs