hdfs上傳數據
① 導入 HDFS 數據至 HBase
Time: 2017.9.14
Targets: 對於用戶活躍情況的數據
數據格式
執行腳本，java的Hive腳本。
Hive的Maven Jar包，與Orc包造成沖突，版本不同，導致類不同，一些方法找不到， 參考 。
原因是hive-exec和orc-maprece的hive-storage-api版本不同，導致VectorizedRowBatch類異常。
測試：
解決方案，添加hive-storage-api，強制指定使用新的類。
HDFS導入HBase，查看錶
表數據
執行數據，從HDFS導入HBase
Processor業務類
注冊Processor
執行
使用Log_Analysis分析框架
OK, that's all!
② Nosql-HDFS-基本概念
Hadoop
文件系統：文件系統是用來存儲和管理文件，並且提供文件的查詢、增加、刪除等操作。
直觀上的體驗：在shell窗口輸入 ls 命令，就可以看到當前目錄下的文件夾、文件。
文件存儲在哪裡？硬碟
一台只有250G硬碟的電腦，如果需要存儲500G的文件可以怎麼辦？先將電腦硬碟擴容至少250G，再將文件分割成多塊，放到多塊硬碟上儲存。
通過 hdfs dfs -ls 命令可以查看分布式文件系統中的文件，就像本地的ls命令一樣。
HDFS在客戶端上提供了查詢、新增和刪除的指令，可以實現將分布在多台機器上的文件系統進行統一的管理。
在分布式文件系統中，一個大文件會被切分成塊，分別存儲到幾台機器上。結合上文中提到的那個存儲500G大文件的那個例子，這500G的文件會按照一定的大小被切分成若干塊，然後分別存儲在若乾颱機器上，然後提供統一的操作介面。
看到這里，不少人可能會覺得，分布式文件系統不過如此，很簡單嘛。事實真的是這樣的么？
潛在問題
假如我有一個1000台機器組成的分布式系統，一台機器每天出現故障的概率是0.1%，那麼整個系統每天出現故障的概率是多大呢？答案是(1-0.1%)^1000=63%，因此需要提供一個容錯機制來保證發生差錯時文件依然可以讀出，這里暫時先不展開介紹。
如果要存儲PB級或者EB級的數據，成千上萬台機器組成的集群是很常見的，所以說分布式系統比單機系統要復雜得多呀。
這是一張HDFS的架構簡圖：
client通過nameNode了解數據在哪些DataNode上，從而發起查詢。此外，不僅是查詢文件，寫入文件的時候也是先去請教NameNode，看看應該往哪個DateNode中去寫。
為了某一份數據只寫入到一個Datanode中，而這個Datanode因為某些原因出錯無法讀取的問題，需要通過冗餘備份的方式來進行容錯處理。因此，HDFS在寫入一個數據塊的時候，不會僅僅寫入一個DataNode，而是會寫入到多個DataNode中，這樣，如果其中一個DataNode壞了，還可以從其餘的DataNode中拿到數據，保證了數據不丟失。
實際上，每個數據塊在HDFS上都會保存多份，保存在不同的DataNode上。這種是犧牲一定存儲空間換取可靠性的做法。
接下來我們來看一下完整的文件寫入的流程：
大文件要寫入HDFS，client端根據配置將大文件分成固定大小的塊，然後再上傳到HDFS。
讀取文件的流程：
1、client詢問NameNode，我要讀取某個路徑下的文件，麻煩告訴我這個文件都在哪些DataNode上？
2、NameNode回復client，這個路徑下的文件被切成了3塊，分別在DataNode1、DataNode3和DataNode4上
3、client去找DataNode1、DataNode3和DataNode4，拿到3個文件塊，通過stream讀取並且整合起來
文件寫入的流程：
1、client先將文件分塊，然後詢問NameNode，我要寫入一個文件到某個路徑下，文件有3塊，應該怎麼寫？
2、NameNode回復client，可以分別寫到DataNode1、DataNode2、DataNode3、DataNode4上，記住，每個塊重復寫3份，總共是9份
3、client找到DataNode1、DataNode2、DataNode3、DataNode4，把數據寫到他們上面
出於容錯的考慮，每個數據塊有3個備份，但是3個備份快都直接由client端直接寫入勢必會帶來client端過重的寫入壓力，這個點是否有更好的解決方案呢？回憶一下mysql主備之間是通過binlog文件進行同步的，HDFS當然也可以借鑒這個思想，數據其實只需要寫入到一個datanode上，然後由datanode之間相互進行備份同步，減少了client端的寫入壓力，那麼至於是一個datanode寫入成功即成功，還是需要所有的參與備份的datanode返回寫入成功才算成功，是可靠性配置的策略，當然這個設置會影響到數據寫入的吞吐率，我們可以看到可靠性和效率永遠是「魚和熊掌不可兼得」的。
潛在問題
NameNode確實會回放editlog，但是不是每次都從頭回放，它會先載入一個fsimage，這個文件是之前某一個時刻整個NameNode的文件元數據的內存快照，然後再在這個基礎上回放editlog，完成後，會清空editlog，再把當前文件元數據的內存狀態寫入fsimage，方便下一次載入。
這樣，全量回放就變成了增量回放，但是如果NameNode長時間未重啟過，editlog依然會比較大，恢復的時間依然比較長，這個問題怎麼解呢？
SecondNameNode是一個NameNode內的定時任務線程，它會定期地將editlog寫入fsimage，然後情況原來的editlog，從而保證editlog的文件大小維持在一定大小。
NameNode掛了， SecondNameNode並不能替代NameNode，所以如果集群中只有一個NameNode，它掛了，整個系統就掛了。hadoop2.x之前，整個集群只能有一個NameNode，是有可能發生單點故障的，所以hadoop1.x有本身的不穩定性。但是hadoop2.x之後，我們可以在集群中配置多個NameNode，就不會有這個問題了，但是配置多個NameNode，需要注意的地方就更多了，系統就更加復雜了。
俗話說「一山不容二虎」，兩個NameNode只能有一個是活躍狀態active，另一個是備份狀態standby，我們看一下兩個NameNode的架構圖。
兩個NameNode通過JournalNode實現同步editlog，保持狀態一致可以相互替換。
因為active的NameNode掛了之後，standby的NameNode要馬上接替它，所以它們的數據要時刻保持一致，在寫入數據的時候，兩個NameNode內存中都要記錄數據的元信息，並保持一致。這個JournalNode就是用來在兩個NameNode中同步數據的，並且standby NameNode實現了SecondNameNode的功能。
進行數據同步操作的過程如下：
active NameNode有操作之後，它的editlog會被記錄到JournalNode中，standby NameNode會從JournalNode中讀取到變化並進行同步，同時standby NameNode會監聽記錄的變化。這樣做的話就是實時同步了，並且standby NameNode就實現了SecondNameNode的功能。
優點：
缺點：
③ 2020-10-28 hdfs塊數據傳輸的數據加密
操作系統：CentOS linux release 7.4.1708 (Core)
軟體：jdk-8u201-linux-x64.tar.gz、hadoop-2.7.7.tar.gz
安裝：
登陸 192.168.1.17
hostnamectl set-hostname node1;mkdir /opt/namenode;mkdir /opt/datanode
vi /etc/hosts
192.168.1.17 node1
192.168.1.18 node2
tar -zxvf jdk-8u201-linux-x64.tar.gz;mv jdk1.8.0_201/ /opt/jdk
tar -zxvf hadoop-2.7.7.tar.gz;mv hadoop-2.7.7/ /opt/hadoop
vi ~/.bashrc
export JAVA_HOME=/opt/jdk
export HADOOP_HOME=/opt/hadoop
export PATH=$PATH:$JAVA_HOME/bin:$HADOOP_HOME/bin:$HADOOP_HOME/sbin
source ~/.bashrc
------------------------------------
登陸 192.168.1.18
hostnamectl set-hostname node2;mkdir /opt/namenode;mkdir /opt/datanode
vi /etc/hosts
192.168.1.17 node1
192.168.1.18 node2
tar -zxvf jdk-8u201-linux-x64.tar.gz;mv jdk1.8.0_201/ /opt/jdk
tar -zxvf hadoop-2.7.7.tar.gz;mv hadoop-2.7.7/ /opt/hadoop
vi ~/.bashrc
export JAVA_HOME=/opt/jdk
export HADOOP_HOME=/opt/hadoop
export PATH=$PATH:$JAVA_HOME/bin:$HADOOP_HOME/bin:$HADOOP_HOME/sbin
source ~/.bashrc
-----------------------------------
修改 core-site.xml 配置
<configuration>
<property>
<name>fs.defaultFS</name>
<value>hdfs://192.168.1.17:9000</value>
</property>
</configuration>
修改 hdfs-site.xml 配置
<configuration>
<property>
<name>dfs.replication</name>
<value>1</value>
</property>
<property>
<name>dfs.namenode.name.dir</name>
<value>file:///opt/namenode</value>
</property>
<property>
<name>dfs.datanode.data.dir</name>
<value>file:///opt/datanode</value>
</property>
<property>
<name>dfs.encrypt.data.transfer</name>
<value>true</value>
</property>
<property>
<name>dfs.encrypt.data.transfer.algorithm</name>
<value>3des</value>
</property>
<property>
<name>dfs.encrypt.data.transfer.cipher.suites</name>
<value>AES/CTR/NoPadding</value>
</property>
<property>
<name>dfs.block.access.token.enable</name>
<value>true</value>
</property>
</configuration>
-------------------------------
登陸 192.168.1.17
hadoop-daemon.sh start namenode;hadoop-daemon.sh start datanode
登陸 192.168.1.18
hadoop-daemon.sh start datanode
-------------------------------
測試
hadoop fs -mkdir -p /user/linzw
hadoop fs -put anaconda-ks.cfg /user/linzw
備註：
如果不添加 dfs.block.access.token.enable = true，會出現如下報錯。添加該配置以後，可以正常寫入數據
20/10/28 21:29:12 INFO hdfs.DFSClient: Exception in createBlockOutputStream
java.io.IOException: Connection reset by peer
at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
at sun.nio.ch.IOUtil.read(IOUtil.java:197)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380)
at org.apache.hadoop.net.SocketInputStream$Reader.performIO(SocketInputStream.java:57)
at org.apache.hadoop.net.SocketIOWithTimeout.doIO(SocketIOWithTimeout.java:142)
at org.apache.hadoop.net.SocketInputStream.read(SocketInputStream.java:161)
at org.apache.hadoop.net.SocketInputStream.read(SocketInputStream.java:131)
at org.apache.hadoop.net.SocketInputStream.read(SocketInputStream.java:118)
at java.io.FilterInputStream.read(FilterInputStream.java:83)
at java.io.FilterInputStream.read(FilterInputStream.java:83)
at org.apache.hadoop.hdfs.protocolPB.PBHelper.vintPrefixed(PBHelper.java:2292)
at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.createBlockOutputStream(DFSOutputStream.java:1480)
at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.nextBlockOutputStream(DFSOutputStream.java:1400)
at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.run(DFSOutputStream.java:554)
20/10/28 21:29:12 INFO hdfs.DFSClient: Abandoning BP-304062021-127.0.0.1-1603891241969:blk_1073741825_1001
20/10/28 21:29:12 INFO hdfs.DFSClient: Excluding datanode DatanodeInfoWithStorage[192.168.1.17:50010,DS-d431ec75-6a89-42b2-b782-7a2d224873d8,DISK]
20/10/28 21:29:12 INFO hdfs.DFSClient: Exception in createBlockOutputStream
java.io.IOException: Connection reset by peer
at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
at sun.nio.ch.IOUtil.read(IOUtil.java:197)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380)
at org.apache.hadoop.net.SocketInputStream$Reader.performIO(SocketInputStream.java:57)
at org.apache.hadoop.net.SocketIOWithTimeout.doIO(SocketIOWithTimeout.java:142)
at org.apache.hadoop.net.SocketInputStream.read(SocketInputStream.java:161)
at org.apache.hadoop.net.SocketInputStream.read(SocketInputStream.java:131)
at org.apache.hadoop.net.SocketInputStream.read(SocketInputStream.java:118)
at java.io.FilterInputStream.read(FilterInputStream.java:83)
at java.io.FilterInputStream.read(FilterInputStream.java:83)
at org.apache.hadoop.hdfs.protocolPB.PBHelper.vintPrefixed(PBHelper.java:2292)
at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.createBlockOutputStream(DFSOutputStream.java:1480)
at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.nextBlockOutputStream(DFSOutputStream.java:1400)
at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.run(DFSOutputStream.java:554)
20/10/28 21:29:12 INFO hdfs.DFSClient: Abandoning BP-304062021-127.0.0.1-1603891241969:blk_1073741826_1002
20/10/28 21:29:12 INFO hdfs.DFSClient: Excluding datanode DatanodeInfoWithStorage[192.168.1.18:50010,DS-168fefa8-5ff0-4fcb-82be-ecd9f81c5861,DISK]
20/10/28 21:29:12 WARN hdfs.DFSClient: DataStreamer Exception
org.apache.hadoop.ipc.RemoteException(java.io.IOException): File /user/linzw/anaconda-ks.cfg._COPYING_ could only be replicated to 0 nodes instead of minReplication (=1). There are 2 datanode(s) running and 2 node(s) are excluded in this operation.
at org.apache.hadoop.hdfs.server.blockmanagement.BlockManager.chooseTarget4NewBlock(BlockManager.java:1620)
at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getNewBlockTargets(FSNamesystem.java:3135)
at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getAdditionalBlock(FSNamesystem.java:3059)
at org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.addBlock(NameNodeRpcServer.java:725)
at org.apache.hadoop.hdfs.protocolPB..addBlock(.java:493)
at org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java)
at org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:616)
at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:982)
at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2217)
at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2213)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1762)
at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2211)
at org.apache.hadoop.ipc.Client.call(Client.java:1476)
at org.apache.hadoop.ipc.Client.call(Client.java:1413)
at org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:229)
at com.sun.proxy.$Proxy10.addBlock(Unknown Source)
at org.apache.hadoop.hdfs.protocolPB..addBlock(.java:418)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:191)
at org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:102)
at com.sun.proxy.$Proxy11.addBlock(Unknown Source)
at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.locateFollowingBlock(DFSOutputStream.java:1603)
at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.nextBlockOutputStream(DFSOutputStream.java:1388)
at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.run(DFSOutputStream.java:554)
put: File /user/linzw/anaconda-ks.cfg._COPYING_ could only be replicated to 0 nodes instead of minReplication (=1). There are 2 datanode(s) running and 2 node(s) are excluded in this operation.
④ csv數據導入Hadoop中的HDFS
作者 : lly
本文介紹通過使用Hadoop命令的方式將csv數據導入進入HDFS中
具體的環境准備及搭建流程可參考以下文章，本文不再做贅述
基礎環境准備：https://blog.csdn.net/supermapsupport/article/details/91443032
Hadoop集群搭建：https://blog.csdn.net/supermapsupport/article/details/91972499
未注冊到 iServer的 csv 數據進行分布式分析服務，則需確保在 csv 存放目錄下有與其對應的 .meta 文件，該.meta文件包含 csv 數據文件的元信息，所以我們將兩個數據一起拷入。以示範數據 newyork_taxi_2013-01_14k.csv 為例，.meta 文件內容為：
"FieldInfos": [
{
"name": "col0",
"type": "WTEXT"
} ,
{
"name": "col1",
"type": "WTEXT"
} ,
{
"name": "col2",
"type": "WTEXT"
} ,
{
"name": "col3",
"type": "INT32"
} ,
{
"name": "col4",
"type": "WTEXT"
} ,
{
"name": "col5",
"type": "WTEXT"
} ,
{
"name": "col6",
"type": "WTEXT"
} ,
{
"name": "col7",
"type": "INT32"
} ,
{
"name": "col8",
"type": "INT32"
} ,
{
"name": "col9",
"type": "DOUBLE"
} ,
{
"name": "X",
"type": "DOUBLE"
} ,
{
"name": "Y",
"type": "DOUBLE"
} ,
{
"name": "col12",
"type": "DOUBLE"
} ,
{
"name": "col13",
"type": "DOUBLE"
}
] ,
"GeometryType": "POINT",
"HasHeader": false,
"StorageType": "XYColumn"
}
1.首先將數據放到opt目錄下
2.將示例數據導入到 hdfs 中，啟動 hadoop，在 hadoop-2.7.7/bin 中執行
. /hadoop fs -mkdir /input #創建/input 目錄
. /hdfs dfs -put /opt / newyork_taxi_2013-01_14k.csv /input/ #將 taxi 數據導入到/input 目錄中
. /hdfs dfs -put /opt / newyork_taxi_2013-01_14k.meta /input/
3.導入完成後，可以使用如下命令查看
. /hadoop fs -ls /input
4.輸出結果如下
⑤ 怎樣將hdfs上的文件導入數據
額，是指什麼？啥叫將hdfs上的文件導入數據
上傳 hdfs dfs -put
下載 hdfs dfs -get
如果已經存在的文件似乎是不能修改的，比如HIVE輸出結果到目錄就是覆蓋（而不是修改）。
⑥ hdfs主要功能
hdfs主要功能？1.HDFS各個角色和主要功能.
(1)、Client其主要的職責如下
(a)、在上傳數據的時候對數據進行分塊，在進行數據的下載的時候對數據進行合並
(b)、與NameNode進行通信在進行數據上傳的時候獲取數據上傳時的數據節點，在數據下載的時候獲取存儲數據的節點
(c)、與DataNode進行通信進行數據的上傳和下載
(2)、NameNode主要的職責如下
(a)、負責數據塊映射信息的管理，在上傳數據的時候給Client返回可以上傳的數據節點，在需要獲取數據的時候返回數據所在的節點，其本身並不存儲數據。
(b)、副本數據的管理策略。
(c)、管理HDFS的名稱空間
(3)、DataNode的主要的職責如下
(a)、負責數據的存儲以及數據的讀寫。
(4)、SecondaryNameNode主要職責
(a)、是NM的一個備用。
(b)、減去NM的負擔，對NM中的日誌以及鏡像文件進行合並在把合並之後的數據發回到NM。
2.HDFS的寫過程及內部原理
1. 使用HDFS提供的客戶端開發庫，向遠程的Namenode發起RPC請求；
2. Namenode會檢查要創建的文件是否已經存在，創建者是否有許可權進行操作，成功則會為文件創建一個記錄，否則會讓客戶端拋出異常；
3. 當客戶端開始寫入文件的時候，開發庫會將文件切分成多個packets（信息包），並在內部以"data queue"的形式管理這些packets，並向Namenode申請新的blocks，獲取用來存儲replicas（復製品）的合適的datanodes列表，列表的大小根據在Namenode中對replication的設置而定。
4. 開始以pipeline（管道）的形式將packet寫入所有的replicas中。開發庫把packet以流的方式寫入第一個datanode，該datanode把該packet存儲之後，再將其傳遞給在此pipeline（管道）中的下一個datanode，直到最後一個datanode，這種寫數據的方式呈流水線的形式。
5. 最後一個datanode成功存儲之後會返回一個ack packet，在pipeline里傳遞至客戶端，在客戶端的開發庫內部維護著"ack queue"，成功收到datanode返回的ack packet後會從"ack queue"移除相應的packet。
6. 如果傳輸過程中，有某個datanode出現了故障，那麼當前的pipeline會被關閉，出現故障的datanode會從當前的pipeline中移除，剩餘的block會繼續剩下的datanode中繼續以pipeline的形式傳輸，同時Namenode會分配一個新的datanode，保持replicas設定的數量。
⑦ HDFS 架構
HDFS 涉及兩個重要進程：NameNode、DataNode。
他們一般都部署單獨部署在不同伺服器上，運行 NameNode 的伺服器是主伺服器，運行 DataNode 的伺服器是從伺服器。主伺服器只有一個，從伺服器有多個。
這種一主多從的架構基本適用於所有分布式系統或框架。可重復使用的架構方案叫作架構模式，一主多從可謂是大數據領域的最主要的架構模式。主伺服器只有一台，掌控全局。從伺服器有很多台，負責具體的事情。這樣很多台伺服器可以有效組織起來，對外表現出一個統一又強大的存儲計算能力。
DataNode 負責文件數據的存儲和讀寫操作，HDFS 將文件數據分割成若干數據塊（Block），每個 DataNode 存儲一部分數據塊，這樣文件就分布存儲在整個 HDFS 伺服器集群中。應用程序客戶端（Client）可以並行對這些數據塊進行訪問，從而使得 HDFS 可以在伺服器集群規模上實現數據並行訪問，極大地提高了訪問速度。
在實踐中，HDFS 集群的 DataNode 伺服器會有很多台，一般在幾百台到幾千台這樣的規模，每台伺服器配有數塊磁碟，整個集群的存儲容量大概在幾 PB 到數百 PB。
NameNode 負責整個分布式文件系統的元數據（MetaData）管理，也就是文件路徑名、數據塊的 ID 以及存儲位置等信息，相當於操作系統中文件分配表（FAT）的角色。HDFS 為了保證數據的高可用，會將一個數據塊復制為多份（默認3份），並將多份相同的數據塊存儲在不同的機架的伺服器上。這樣當有磁碟損壞，或者某個 DataNode 伺服器宕機，甚至某個交換機宕機時，系統能通過其備份的數據塊進行查找。
處理客戶端的請求。
客戶端向 HDFS 上傳文件。
客戶端向 HDFS 讀取文件。
像 NameNode 這樣主從伺服器管理同一份數據的場景，如果從伺服器錯誤地以為主伺服器宕機而接管集群管理，會出現主從伺服器一起對 DataNode 發送指令，進而導致集群混亂，也就是所謂的「腦裂」。這也是這類場景選舉主伺服器時，引入 ZooKeeper 的原因。
⑧ 雲外面的數據怎麼上傳到hdfs
hadoop計算需要在hdfs文件系統上進行，文件上傳到hdfs上通常有三種方法：a hadoop自帶的dfs服務，put；b hadoop的API，Writer對象可以實現這一功能；c 調用OTL可執行程序，數據從資料庫直接進入hadoop
hadoop計算需要在hdfs文件系統上進行，因此每次計算之前必須把需要用到的文件(我們稱為原始文件)都上傳到hdfs上。文件上傳到hdfs上通常有三種方法：
a hadoop自帶的dfs服務，put；
b hadoop的API，Writer對象可以實現這一功能；
c 調用OTL可執行程序，數據從資料庫直接進入hadoop
由於存在ETL層，因此第三種方案不予考慮
將a、b方案進行對比，如下：
1 空間：方案a在hdfs上佔用空間同本地，因此假設只上傳日誌文件，則保存一個月日誌文件將消耗掉約10T空間，如果加上這期間的各種維表、事實表，將佔用大約25T空間
方案b經測試，壓縮比大約為3~4:1，因此假設hdfs空間為100T，原來只能保存約4個月的數據，現在可以保存約1年
2 上傳時間：方案a的上傳時間經測試，200G數據上傳約1小時
方案b的上傳時間，程序不做任何優化，大約是以上的4~6倍，但存在一定程度提升速度的餘地
3 運算時間：經過對200G數據，大約4億條記錄的測試，如果程序以IO操作為主，則壓縮數據的計算可以提高大約50%的速度，但如果程序以內存操作為主，則只能提高5%~10%的速度
4 其它：未壓縮的數據還有一個好處是可以直接在hdfs上查看原始數據。壓縮數據想看原始數據只能用程序把它導到本地，或者利用本地備份數據
壓縮格式：按照hadoop api的介紹，壓縮格式分兩種：BLOCK和RECORD,其中RECORD是只對value進行壓縮，一般採用BLOCK進行壓縮。
對壓縮文件進行計算，需要用SequenceFileInputFormat類來讀入壓縮文件，以下是計算程序的典型配置代碼：
JobConf conf = new JobConf(getConf(), log.class);
conf.setJobName(」log」);
conf.setOutputKeyClass(Text.class);//set the map output key type
conf.setOutputValueClass(Text.class);//set the map output value type
conf.setMapperClass(MapClass.class);
//conf.setCombinerClass(Rece.class);//set the combiner class ,if havenot, use Recuce class for default
conf.setRecerClass(Rece.class);
conf.setInputFormat(SequenceFileInputFormat.class);//necessary if use compress
接下來的處理與非壓縮格式的處理一樣
⑨ 如何快速把hdfs數據動態導入到hive表
（1）、從本地文件系統中導入數據到 Hive 表；
（2）、從 HDFS 上導入數據到 Hive 表；
（3）、從別的表中查詢出相應的數據並導入到 Hive 表中；
（4）、在創建表的時候通過從別的表中查詢出相應的記錄並插入到所創建的表中。
⑩ 大數據之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中的。