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中的。