HDFS

hive需要引入包时？该怎么引入？ 注意如果你的hive服务的和cli端是在同一台机器上，那么直接在 hive-env.sh中的HIVE.AUX.JARS.PATH设置指向hive/lib下即可，把需要的包加到lib下，和配置 hive-site.xml中的hive.aux.jars.path的效果是一样的。 一、hive-site.xml中的hive.aux.jars.path 此配置项对于hive server有效，但是是不会作用到hive shell.也就是说即使你在hive节点上配置了这一项，但是对于hive shell来说是无效的（为什么会这样？难道不是服务器配置了，所有的hive shell都能生效吗？搞不懂）。但是在hive-site.xml的模板文件中找不到hive.aux.jars.path的配置，是不是hive正慢慢改变用户放弃配置此属性呢？ 注意：1，目前只支持file://也就是本地文件，暂不支持HDFS，也不支持文件夹。2，多个文件使用逗号分隔。3，不能换行。 有类似hbase-0.94.15-cdh4.7.0.jar包时，可以使用如下配置： <property> <name>hive.aux.jars.path</name> <value>file:///home/cdh/apps/hive-0.10.0-cdh4.7.0/lib/hive-hbase

http://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/FileSystemShell.html#Overview FS Shell 调用文件系统(FS)Shell命令应使用 bin/hadoop fs <args> 的形式。 所有的的FS shell命令使用URI路径作为参数。URI格式是 scheme://authority/path 。对HDFS文件系统，scheme是 hdfs ，对本地文件系统，scheme是 file 。其中scheme和authority参数都是可选的，如果未加指定，就会使用配置中指定的默认scheme。一个HDFS文件或目录比如 /parent/child 可以表示成 hdfs://namenode:namenodeport/parent/child ，或者更简单的 /parent/child （假设你配置文件中的默认值是 namenode:namenodeport ）。大多数FS Shell命令的行为和对应的Unix Shell命令类似，不同之处会在下面介绍各命令使用详情时指出。出错信息会输出到 stderr ，其他信息输出到 stdout 。 appendToFile Usage: hdfs dfs -appendToFile <localsrc> ...

适合的应用场景： 存储非常大的文件： 这里非常大指的是几百M、G、或者TB级别，需要高吞吐量，对延时没有要求。 采用流式的数据访问方式： 即一次写入，多次读取，数据集经常从数据源生成或者拷贝一次， 然后在其上做很多分析工作。 运行于商业硬件上： Hadoop不需要特别贵的机器，可运行于普通廉价机器，可处节约成本。 需要高容错性 为数据存储提供所需要的扩展能力 不适合的应用场景： 低延时的数据访问对延时要求在毫秒级别的应用，不适合采用HDFS。 HDFS是为高吞吐数据传输设计的，因此可能牺牲延时。 大量小文件 ： 文件的元数据保存在NameNode的内存中，整个文件系统的文件数量会受限于 NameNode的内存的大小。经验而言，一个文件/目录/文件快一般占有150字节的元数据内存空间。如果有100万个文件，每个文件占用1个文件快，则需要大约300M的内存。因此十亿级别的文件数量在现有商用机器上难以支撑。 多方读写，需要任意的文件修改HDFS采用追加 的方式写入数据。不支持文件任意offset的修改。不支持多个写入器。 来源： CSDN 作者： 散_步 链接： https://blog.csdn.net/zhumengguang/article/details/104579013

HDFS是Hadoop Distribute File System 的简称，也就是Hadoop的一个分布式文件系统。 一、HDFS的主要设计理念 1、存储超大文件 这里的“超大文件”是指几百MB、GB甚至TB级别的文件。 2、最高效的访问模式是 一次写入、多次读取(流式数据访问) HDFS存储的数据集作为hadoop的分析对象。在数据集生成后，长时间在此数据集上进行各种分析。每次分析都将设计该数据集的大部分数据甚至全部数据，因此读取整个数据集的时间延迟比读取第一条记录的时间延迟更重要。 3、运行在普通廉价的服务器上 HDFS设计理念之一就是让它能运行在普通的硬件之上，即便硬件出现故障，也可以通过容错策略来保证数据的高可用。 二、HDFS的忌讳 1、将HDFS用于对数据访问要求低延迟的场景 由于HDFS是为高数据吞吐量应用而设计的，必然以高延迟为代价。 2、存储大量小文件 HDFS中元数据（文件的基本信息）存储在namenode的内存中，而namenode为单点，小文件数量大到一定程度，namenode内存就吃不消了。 三、HDFS基本概念 数据块（block）：大文件会被分割成多个block进行存储，block大小默认为64MB。每一个block会在多个datanode上存储多份副本，默认是3份。 namenode：namenode负责管理文件目录

HDFS 原理 HDFS （ Hadoop Distributed File System ）是一个分布式文件系统，是谷歌的 GFS 山寨版本。它具有高容错性并提供了高吞吐量的数据访问，非常适合大规模数据集上的应用，它提供了一个高度容错性和高吞吐量的海量数据存储解决方案。 l 高吞吐量访问： HDFS 的每个 Block 分布在不同的 Rack 上，在用户访问时， HDFS 会计算使用最近和访问量最小的服务器给用户提供。由于 Block 在不同的 Rack 上都有备份，所以不再是单数据访问，所以速度和效率是非常快的。另外 HDFS 可以并行从服务器集群中读写，增加了文件读写的访问带宽。 l 高容错性：系统故障是不可避免的，如何做到故障之后的数据恢复和容错处理是至关重要的。 HDFS 通过多方面保证数据的可靠性，多份复制并且分布到物理位置的不同服务器上，数据校验功能、后台的连续自检数据一致性功能都为高容错提供了可能。 l 线性扩展：因为 HDFS 的 Block 信息存放到 NameNode 上，文件的 Block 分布到 DataNode 上，当扩充的时候仅仅添加 DataNode 数量，系统可以在不停止服务的情况下做扩充，不需要人工干预。 HDFS 架构 如上图所示 HDFS 是 Master 和 Slave 的结构，分为 NameNode 、 Secondary

一、Zookeeper配置kerberos认证 1、环境说明 根据之前的组件安排如下： 172.16.57.74 bd-ops-test-74 kdc zookeeper-client 172.16.57.75 bd-ops-test-75 zookeeper 172.16.57.76 bd-ops-test-76 zookeeper 172.16.57.77 bd-ops-test-77 zookeeper 2、配置 ZooKeeper Server 2.1生成keytab 在 74 节点，即 KDC server 节点上执行下面命令： kadmin.local -q "addprinc -randkey zookeeper/bd-ops-test-75@BIGDATA.COM " kadmin.local -q "addprinc -randkey zookeeper/bd-ops-test-76@BIGDATA.COM " kadmin.local -q "addprinc -randkey zookeeper/bd-ops-test-77@BIGDATA.COM " kadmin.local -q "xst -k zookeeper.keytab zookeeper/bd-ops-test-75@BIGDATA.COM " kadmin.local -q "xst -k

　　集群格式化hdfs后，在主节点运行启动hdfs后，发现namenode启动了，而datanode没有启动，在其他节点上jps后没有datanode进程！ 原因： 　　当我们使用hdfs namenode -format格式化namenode时，会在namenode数据文件夹中保存一个current/VERSION文件，记录clusterID，而datanode中保存的current/VERSION文件中的clustreID的值是第一次格式化保存的clusterID，刚好有进行了一次格式化，在namenode的current/VERSION文件保存新的clusterID这样datanode和namenode之间的ID不一致。导致上述结果！ 解决： 　　找current/VERSION文件路径。 　　namenode节点的路径是：/解压路径/hadoop-2.6.0/tmp/dfs/name/current/ 　　datanode节点的路径是：/解压路径/hadoop-2.6.0/tmp/dfs/data/current/ 　　找到VERSION后打开查看，一对比，datanode的clustreID与其他3台datanode的clustreID真的不同！ 　　将datanode的clustreID的值改成与datanode的clustreID相同后再启动，成功！　　 来源：

一、HDFS初识 hdfs的概念： 　　HDFS,它是一个文件系统,用于存储文件,通过目录树定位文件,其次,他是分布式的,由很多服务器联合起来 实现功能,集群中的服务器各有各自的角色 HDFS设计适合一次写入,多次读出的场景,且不支持文件的修改,适合用来做数据分析,并不适合做网盘等应用 HDFS的组成： 　　HDFS集群包括,NameNode和DataNode以及Secondary NameNode NameNode负责管理整个文件系统的元数据,以及每一个路径(文件) 所对应的数据块信息 DataNode负责管理用户的文件数据块,每一个数据块可以在多个NameNode上存储多副本 SecondNameNode 用来监控HDFS状态的辅助后台程序,每隔一段时间获取HDFS元数据的快照 HDFS的快比磁盘块大的原因： 目的是为了最小寻址开销 寻址时间为传输时间的1%时,则为最佳状态。 hdfs-默认Block块大小是128M hadoop2.0以下默认块是64M,通过hdfs的web端 可以看到数据块的BlockId 和 当前数据分为多少个Block 例如2G的数据, 会分成16个Block块. 而且如果最后一个块分配不满的话,会动态伸缩 不会固定占用128M 二、当一个DataNode进程挂掉,数据还会继续同步吗？ 会的hdfs-client会报错,但是数据会继续上传,

Hadoop分布式文件系统（Hadoop Distributed File System, HDFS） 分布式文件系统是一种同意文件通过网络在多台主机上分享的文件系统。可让多机器上的多用户分享文件和存储空间。 hdfs仅仅是当中一种。 适用于一次写入、多次查询的情况。不支持并发写情况。小文件不合适。 2.HDFS架构 HDFS採用master/slave架构。一个HDFS集群是由一个Namenode和一定数目的Datanodes组成。Namenode是一个中心server，负责管理文件系统的名字空间(namespace)以及client对文件的訪问。 集群中的Datanode通常是一个节点一个，负责管理它所在节点上的存储。HDFS暴露了文件系统的名字空间。用户可以以文件的形式在上面存储数据。从内部看，一个文件事实上被分成一个或多个数据块，这些块存储在一组Datanode上。Namenode运行文件系统的名字空间操作，比方打开、关闭、重命名文件或文件夹。它也负责确定数据块到详细Datanode节点的映射。Datanode负责处理文件系统client的读写请求。在Namenode的统一调度下进行数据块的创建、删除和复制。 NameNode 是整个文件系统的管理节点。 它维护着整个文件系统的文件文件夹树，文件/文件夹的元信息和每个文件相应的数据块列表。 接收用户的操作请求。 文件包括：