Hdfs

1、NameNode启动2、DataNode启动3、文件上传4、文件下载

面对企业级数据量，单机容量太小，无奈存储海量的数据，这时候就须要用到多台机器存储，并对立治理散布在集群上的文件，这样就造成了分布式文件系统。HDFS是Hadoop下的分布式文件系统技术，Ceph是能解决海量非结构化数据存储的对象存储技术，本文将对他们的架构原理、个性和优缺点做介绍。 — 分布式文件系统HDFS —HDFS全称为Hadoop Distributed File System，在2006年由Doug Cutting公布了第一个版本，是运行在通用硬件上的分布式文件系统。它提供了一个高度容错性和高吞吐量的海量数据存储解决方案。HDFS的推出给过后的行业提供了一个低成本、高可扩大的数据存储计划，尤其实用于互联网行业的海量用户拜访日志的存储和检索需要，因而一经推出就受到了互联网行业的欢送，以Yahoo为代表的互联网企业疾速构建了基于HDFS的企业数仓，从而减速了Hadoop在互联网行业内的疾速落地（起初这个Yahoo团队独立进去创建了Hortonworks）。尔后通过3~4年的疾速倒退，海内的大型企业都开始拥抱HDFS，各种新型利用场景开始呈现并发明了较大的业务价值。从2009年开始，国内的Hadoop利用开始呈现，并最早在运营商和互联网行业落地。作为Hadoop体系的最胜利的我的项目，HDFS曾经在各种大型在线服务和数据存储系统中失去广泛应用，曾经成为私有化部署畛域海量数据存储的施行规范。 HDFS通过一个高效的分布式算法，将数据的拜访和存储散布在大量服务器之中，在牢靠地多备份存储的同时还能将拜访散布在集群中的各个服务器之上。在构架设计上，NameNode治理元数据，包含文件目录树，文件->块映射，块->数据服务器映射表等。DataNode负责存储数据、以及响应数据读写申请；客户端与NameNode交互进行文件创建/删除/寻址等操作，之后间接与DataNode交互进行文件I/O。 HDFS通过正本机制保证数据的存储平安与高牢靠，默认如上图所示配置为3正本，每个数据块散布在不同的服务器之上。在用户拜访时，HDFS将会计算应用网络最近的和访问量最小的服务器给用户提供拜访。HDFS反对文件的创立、删除、读取与追加，对于一个较大的文件，HDFS将文件的不同局部寄存于不同服务器之上。在拜访大型文件时，零碎能够并行从服务器阵列中的多个服务器并行读入，减少了大文件读入的拜访带宽。通过以上实现，HDFS通过分布式计算的算法，将数据拜访均摊到服务器阵列中的每个服务器的多个数据拷贝之上，单个硬盘或服务器的吞吐量限度都能够冲破，提供了极高的数据吞吐量。 HDFS将文件的数据块调配信息寄存在NameNode服务器之上，文件数据块的信息散布地寄存在DataNode服务器上。当整个零碎容量须要裁减时，只须要减少DataNode的数量，HDFS后续通过balance算法将数据块搬迁到新的DataNode实例中。通过以上实现，HDFS能够做到在不进行服务的状况下横向扩容和数据从新散布。HDFS文件系统假如系统故障（服务器、网络、存储故障等）是常态，并通过多方面措施来保证数据的可靠性。数据在写入时被复制多份，能够通过用户自定义的复制策略散布到物理地位不同的服务器上；数据在读写时将主动进行数据的校验，一旦发现数据校验谬误将从新进行复制。 受限于过后的需要背景和硬件能力程度，HDFS也有一些显著的架构问题，随着技术和需要的演进而逐步成为瓶颈。通过NameNode来治理元数据有它的架构问题，首先是服务高可用问题，在Hadoop 1.0时代这是最大的架构问题，不过在2013年Hadoop 2.0中通过Master-Slave的形式得以解决；另外每个存储的文件都必须在NameNode的内存中保护一个描述符从而占据内存空间，当文件数据量太大时就会受限于单个NameNode的内存资源从而导致性能瓶颈（个别单个集群文件数量在亿级别以上时），社区在2017年推出的Hadoop 2.9版本提供HDFS Router Federation性能，通过不同的NameService解决挂载在HDFS上不同目录下的文件的形式来缓解这个问题。 存储老本问题对于大型HDFS集群是个更大的问题，HDFS的三正本策略保障了性能和存储老本的平衡，适宜于热数据和温数据的存储和解决，对于冷数据存储来说老本就偏高，尤其与对象存储类的解决方案相比。开源社区直到2019年Hadoop 3.0里才推出了Erasure Code技术（星环科技在2014年推出HDFS EC技术），但因为推出工夫较晚和技术成熟度等起因，目前并没有大规模落地。与云计算的存储技术交融是另外一个重要的架构问题，私有云有成熟的云存储计划，绝对HDFS老本更低，与云平台的调度零碎协调的更好，而HDFS只能定位作为云上的企业存储的一个细分计划之一。如各个云平台都推出EMR（Elastic MapReduce）类产品，如Google Dataproc，阿里云EMR等，但总体受欢迎度比拟个别，短少与云上其余数据分析与解决零碎的全方位的买通和互联。 从2012年开始，国内重点行业的中大型企业都曾经开始了大数据的布局，到2019年像金融、运营商、能源、政府公安等重要行业大部分企业都曾经构建了基于HDFS的数据存储系统，推动了一批重点的数字化利用的推广。如金融行业的ODS、历史数据存储、数据湖、科技监管类利用，运营商的经分系统、电子围栏、数字营销零碎等，都曾经是宽泛应用的业务零碎。因为国内外行业需要的差异性以及对私有云的接受程度不同，HDFS在国内依然是一个十分重要的数据存储技术，也领有更好的技术和利用生态，因而有着更为欠缺的技术生命力。 — 对象存储Ceph —对象存储的设计指标是为了解决海量非结构化数据的存储问题，如邮件、图谱、视频、音频以及其余多媒体文件，并在社交、挪动等利用中大量被应用，此外也大量被用于数据备份和灾备场景。 在业务开发层个别提供基于S3协定的开发接口，这套API提供了一整套的RESTful API，能够让利用能够通过HTTP PUT或GET命令来操作数据对象，每个对象有个本人的拜访地址。与HDFS等文件类存储采纳目录构造或多层级树形构造不同，对象存储在物理存储上个别采纳一个扁平的数据存储构造，每个对象都是一个包含元数据、数据和惟一标识ID的齐备数据形容，这样利用能够十分不便的去找到并拜访这个数据对象，在存储的治理上也绝对比较简单，尤其是大部分利用场景下数据对象都存储在远端的云服务器上。对象存储管理软件会将所有的硬盘资源形象为一个存储池，用于数据的物理化存储。绝对于文件类存储，对象存储相对来说老本更低，但绝对数据分析的性能不佳，须要配套各种剖析的缓存技术来能提供比拟好的数据分析性能。 Ceph是一个开源的对象存储我的项目，诞生于2004年，提供对象、块和文件存储，其中对象存储性能在业内十分受欢迎，在国内曾经有很多私有化云平台的对象存储生产落地案例。一个Ceph的存储集群个别包含三个局部：Ceph存储集群服务端：在Ceph存储集群服务端架构中外围组件有Monitor服务、OSD(Object Storage Daemons)服务和Manager服务等。其中Mon服务用于保护存储系统的硬件逻辑关系，次要是服务器和硬盘等在线信息。Mon服务通过集群的形式保障其服务的可用性。OSD服务用于实现对磁盘的治理并实现真正的数据读写，通常一个磁盘对应一个OSD服务。Ceph Clients：以library形式提供的客户端，能够用于拜访Ceph服务端，它提供了3种协定来拜访，包含对象存储的RADOSGW、块存储端的RBD以及文件存储的CephFS。Ceph 协定：用于服务端和Client的通信协议。 因为一个分布式存储集群治理的对象数量十分多，可能是百万级甚至是千万级以上，因而OSD的数量也会比拟多，为了有好的管理效率，Ceph引入了Pool、Place Groups（PGs）、对象这三级逻辑。PG是一个资源池的子集，负责数据对象的组织和地位映射，一个PG负责组织一批对象（数据在千级以上）。同时一个PG会被映射到多个OSD，也就是由多个OSD来负责其组织的对象的存储和查问，而每个OSD都会承载大量的PG，因而PG和OSD之间是多对多的映射关系。 当用户要将数据存储到Ceph集群时，存储数据会被宰割成多个对象（Ceph的最小存储单元），每个对象都有一个惟一的id，每个对象的大小是能够配置的，默认为4MB。Ceph通过借鉴的CRUSH哈希算法，将若干个对象映射到PG上，造成一个对象与PG的逻辑组合，并依据PG所在的Pool的正本数，将数据复制到多个OSD上，保证数据的高可用。 图片来源于：https://www.wenjiangun.com/blog/952/在集群的可扩展性上，Ceph能够做到简直线性扩大。CRUSH 通过一种伪随机的形式将数据进行散布，因而 OSD 的利用就可能精确地通过二项式建模或者惯例形式调配。无论哪一个都能够获得完满的随机过程。随着 PG 的减少，差别就降落：对于每个 OSD 100 个 PG的状况下，标准差是 10%；对于1000 个的状况下为 3%。线性的散布策略极好地将负载在集群中均衡。CRUSH 通过卸载所有的调配碎片到一个特定的 OSD 上从而来修改这样的问题。与哈希以及线性策略不同，CRUSH 同时也最小化了数据在集群扩大产生的迁徙，同时又保障了负载的均衡。CRUSH 的计算复杂度为 O（log(n)）（对于有 n 个 OSD 的集群），因而只须要 10 几个微秒就能够使集群增长到好几千个 OSDs。 值得关注的是，Ceph客户端所有的读写操作都须要通过代理节点，一旦集群并发量较大，代理节点就容易成为单点瓶颈。在数据的一致性方面，Ceph只能反对数据的最终一致性。 — 小结—本文从架构和原理介绍了高度容错性、高吞吐量的分布式文件系统HDFS，和解决海量非结构化数据存储的对象存储技术Ceph（当初各项技术倒退比拟快，可能存在技术形容跟最新技术倒退状况不太统一的状况）。那么在特定场景下，数据的疾速查问、疾速写入和可扩展性也是必不可少的，下一篇咱们将介绍搜索引擎技术和宽表存储技术。 ...

敞开所有hadoop,zk节点stop-dfs.shzk.sh stop顺次启动所有节点journalnodehdfs --daemon start journalnode任一节点格式化namenodehdfs namenode -format启动hdfs --daemon start namenode其余节点同步namenode信息hdfs namenode -bootstrapStandby其余节点启动namenodehdfs --daemon start namenode启动zk集群zk.sh start初始化zkfchdfs zkfc -formatZK敞开hadoop集群stop-dfs.sh启动hadoop集群start-dfs.sh

本期话题本期分享将介绍分布式文件系统 HDFS（Hadoop Distributed File System）在 Shopee 如何从一个小型集群倒退到由数千个节点组成的联邦集群，以及在这一过程中咱们遇到的问题与解决措施。 通过本期分享，你将可能理解到： HDFS 的根本设计等相干常识；Shopee Data Infra 团队为什么改良，以及如何改良 HDFS 的可扩展性；HDFS 的常见问题和解决方案。 嘉宾简介Yiyang，大数据工程师 来自 Shopee Data Infrastructure 团队，热衷于 HDFS、Ozone 等存储系统相干的研发。 叮！来自直播小助手的揭示⏰ 直播工夫 2022年7月21日 19:00-20:00 直播地址 戳这里预约 Zoom 直播 -> 查收邮件，获取链接 Zoom 会议号：959 2107 0966明码：116335*可通过 Zoom 桌面端、挪动端以及 PC 端浏览器退出直播间；无需 Zoom 账号，无需登录即可退出直播间，并可能发送发问，参加互动。 有奖征集欢送大家间接在「Shopee技术团队」公众号留言，就「HDFS」相干话题向 Yiyang 发问；也可在流动当天来直播间现场参加互动。嘉宾自己将在分享完结后的 Q&A 环节与大家一起聊聊这些话题。 咱们为发问被选中的观众筹备了 Shopee 周边礼包盲盒各一份，获奖名单将于流动当天在直播间揭晓。

学习了应用命令 hdfs haadmin -failover 手动进行故障转移，在该模式下，即便现役 NameNode 曾经生效，零碎也不会主动从现役 NameNode 转移到待机 NameNode，上面学习如何配置部署 HA 主动进行故障转移。主动故障转移为 HDFS 部署减少了两个新组件：ZooKeeper 和 ZKFailoverController（ZKFC）过程，如图 3-20 所示。ZooKeeper 是保护大量协调数据，告诉客户端这些数据的扭转和监督客户端故障的高可用服务。HA 的主动故障转移依赖于 ZooKeeper 的以下性能： 1）故障检测：集群中的每个 NameNode 在 ZooKeeper 中保护了一个长久会话，如果机器解体，ZooKeeper 中的会话将终止，ZooKeeper 告诉另一个 NameNode 须要触发故障转移。 2）现役 NameNode 抉择：ZooKeeper 提供了一个简略的机制用于惟一的抉择一个节点为 active 状态。如果目前现役 NameNode 解体，另一个节点可能从 ZooKeeper 取得非凡的排外锁以表明它应该成为现役 NameNode。 ZKFC 是主动故障转移中的另一个新组件，是 ZooKeeper 的客户端，也监督和治理 NameNode 的状态。每个运行 NameNode 的主机也运行了一个 ZKFC 过程，ZKFC 负责： 1）衰弱监测：ZKFC 应用一个健康检查命令定期地 ping 与之在雷同主机的 NameNode，只有该 NameNode 及时地回复衰弱状态，ZKFC 认为该节点是衰弱的。如果该节点解体，解冻或进入不衰弱状态，衰弱监测器标识该节点为非衰弱的。 2）ZooKeeper 会话治理：当本地 NameNode 是衰弱的，ZKFC 放弃一个在 ZooKeeper 中关上的会话。如果本地 NameNode 处于 active 状态，ZKFC 也放弃一个非凡的 znode 锁，该锁应用了 ZooKeeper 对短暂节点的反对，如果会话终止，锁节点将主动删除。 ...

咱们晓得hdfs是hadoop体系上的文件系统，负责具体的数据文件存储，且如果一旦hdfs文件被误删除后，尤其是重要数据，对公司来说影响十分大。所以须要提前做一些平安预防措施，例如应用Hdfs Trash机制，或者重要目录利用Hdfs SnapShot性能，而后针对于删除的文件或者目录能够通过trash或者SnapShot机制来进行复原，如果数据的确曾经删除了（例如间接通过hadoop api进行delete，未配置SnapShot），如果想复原数据，就须要疾速采取肯定的措施了。上面咱们来别离介绍下这些复原数据的应用形式与机制。 Hdfs Trash（回收箱） 对于线上生产环境的HDFS，开启回收站性能是必不可少的。该性能相似于linux零碎的回收站设计，HDFS会为每个用户创立一个专属的回收站目录（/user/${user.name}/.Trash），用户删除文件时，实际上是被挪动到了回收站目录。用于预防当用户误删HDFS上的数据时，可能及时从回收站复原这些数据（当然回收站是防不住删库跑路的）。 应用这种形式的前提是在hdfs下面开启trash性能，默认是没有开启的。interval的值默认为0，单位是分钟。只须要在hadoop的配置文件core-site.xml中增加上面的内容： <!--Enable Trash --><property>      <name>fs.trash.interval</name>      <value>120</value></property><property>      <name>fs.trash.checkpoint.interval</name>      <value>120</value></property> 增加好上述内容后，不须要重启后台程序，间接就会失效。执行删除操作后，会先将文件挪动到以后操作用户的.Trash/Current目录上面。 Hdfs SnapShot(快照) hadoop从2.1版本后开始反对HDFS快照（SnapShot）性能， 快照创立瞬时性：除去inode的查问工夫，算法耗费O(1)复杂度。 只有在对快照批改时才会耗费额定内存：内存应用O(M)，M是被批改的文件或者目录数。 DataNode的block不被复制：快照文件记录block列表和文件大小。不做数据的拷贝复制。 快照不会对失常HDFS操作产生不利影响：所有的批改都依照工夫倒序排序，因而以后数据总能被间接拜访到。快照数据是依据与以后数据进行变更局部的差值计算得来的。 应用实例： 应用形式： 创立快照：hdfs fs -allowSnapshot /testhdfs fs -put test.txt /testhdfs fs -createSnapshot /test import_data 将test文件删除：hdfs fs -rmr /test/test.txt 误删除后就能够应用快照目录进行复原：hdfs  fs  -cp /test/.snapshot/import-data/test.txt  /text复原数据 然而如果间接调用hadoop delete api进行删除操作，是默认不会走trash机制的，同时也未配置快照性能的状况下，文件所对应的block数据曾经开始真正从底层文件系统层面进行删除，此时须要疾速的做出决断进行复原操作。因为须要进行数据服务（nn、dn），所以须要综合思考，去衡量复原数据和停服对线上服务的影响两者之间的利害关系。 首先梳理下hdfs delete的流程，如下图： 咱们能够看到hdfs delete流程中很多环节都是异步进行操作的，所以如果想复原数据，须要立刻做出决定是否进行停服，能够复原的数据量也取决于操作与停服间隔时间，还有集群的忙碌水平，所以可能复原全副或者局部数据，如果工夫过了很久了，在集群规模比拟大、集群比拟闲暇的状况下，可复原的数据量百分比就不能太乐观了。上面咱们来阐明下具体复原步骤（阐明：操作的前提是有删除操作之前的fsimage元数据，同时须要有备用的新集群）： 及时进行hdfs集群服务（nn、dn），阻止block数据从os上进一步被删除；由上述的hdfs delete流程可知namenode删除block指令是通过datanode心跳一批批下发的，且datanode是通过异步线程删除block数据， 所以须要立刻进行服务过程，阻止datanode上的block文件进一步被删除； 拷贝删除数据前的元数据fsimage文件，并在新集群namenode加载2.1) 通过hdfs审计log找到删除操作开始的确切工夫点； 2.2) 从fsimage备份的多个版本中，找到删除操作工夫点前的fsimage； 2.3) 停掉新集群所有过程(保留journalnode)，初始化新环境； 2.4) 停掉所有journalnode过程，在image目录替换为备份的fsimage文件，替换imaeg、edits、和所有journalnode目录下的VERSION文件为生产环境上的VERSION文件； 2.5) 启动namenode过程； ...

问题JuiceFS 是一个基于对象存储的分布式文件系统，在之前跟对象存储比拟的文章中曾经介绍了 JuiceFS 可能保证数据的强一致性和极高的读写性能，因而齐全能够用来代替 HDFS。然而数据平台整体迁徙通常是一个费时费力的大工程，须要做到迁徙超大规模数据的同时尽量不影响下层业务。上面将会介绍如何通过 JuiceFS 的迁徙工具来实现平滑迁徙 HDFS 中的海量数据到 JuiceFS。 平滑迁徙计划数据平台除了咱们在 HDFS 上理论看到的文件以外，其实还有一些同样重要的信息，也就是所谓的「元数据」，这些元数据存储在相似 Hive Metastore 这样的零碎里。因而当咱们议论数据迁徙时不能把这两种数据拆分开来，必须同时思考，迁徙完数据当前须要同时更新 Hive 表或者分区的地位（LOCATION）信息，如果任何一种数据出了问题都会对业务方造成影响。 为了保证数据和元数据的一致性，通常的做法是在迁徙完数据当前同步更新元数据中的地位信息，但当数据规模比拟大，并且业务又可能更新数据时，很难保证数据拷贝和更新地位信息是个原子操作，迁徙过程中可能导致数据失落，影响整体迁徙的可靠性。甚至须要以暂停业务为代价来实现，或者在业务中采纳双写等机制来实现在线迁徙，侵入业务逻辑，费时费力。 如果可能在迁徙过程中为数据拜访提供对立的门路来屏蔽理论的数据地位，实现元数据和实在数据地位的解耦，将会大大降低整体迁徙的危险。文件系统的符号链接就能够达到这个成果，JuiceFS 也反对符号链接，并且反对跨文件系统的符号链接，借助它能够为多个文件系统提供对立的拜访入口，造成对立命名空间。 符号链接是操作系统中广泛应用的概念，你能够通过符号链接实现在一个目录树中治理扩散在各个中央的数据。对应的，咱们也能够通过 JuiceFS 的符号链接个性实现在一个文件系统中治理多个存储系统。其实符号链接这个性能早在 2013 年 Hadoop 社区就曾经想要在 HDFS 上实现（HADOOP-10019），但遗憾的是目前为止还没残缺反对。借助符号链接即可在 JuiceFS 上治理包含但不限于 HDFS、对象存储在内的各种存储系统，外表上看起来拜访的是 JuiceFS，但理论拜访的是底层实在的存储。 同时，JuiceFS 的原子重命名（rename）操作也能在数据迁徙过程中施展关键作用。JuiceFS 通过符号链接来跳转回原始数据，但当数据齐全拷贝过去当前须要笼罩这个符号链接，这个时候原子重命名就能保证数据的安全性和可靠性，避免出现数据失落和损坏。 此外，JuiceFS 还能够通过配置文件和非凡的标记文件来动静感知到迁徙过程，并在新增和删除文件时进行额定的查看，确保新创建的文件也会呈现在迁徙后的目录中，并且确保要删除的文件也能从新零碎中删掉。对于更简单的重命名操作，也有相似的机制来保障正确性。 有了方才介绍的 JuiceFS 的这些个性，就能够实现在数据迁徙时别离迁徙数据和元数据，同时整个迁徙过程对于业务是齐全通明的。上面解说具体的迁徙操作步骤。 操作步骤步骤一：将 JuiceFS 作为 HDFS 的拜访入口在 JuiceFS 上给 HDFS 的所有第一级目录（或文件）创立对应的符号链接（假设不会再在 HDFS 根目录创立内容），之后通过 jfs://name/<path> 就能残缺拜访 HDFS 外面的内容，两者是齐全等价的。如下图所示。 步骤二：应用 JuiceFS 来拜访 HDFS 中的数据这一步有两种实现办法。第一种是批改 Hive Metastore 中表或者分区的 LOCATION 为对应的 JuiceFS 门路，例如之前是 hdfs://ns/user/test.db/table_a，新门路则为 jfs://name/user/test.db/table_a。第二种办法是将 fs.hdfs.impl 批改为 com.juicefs.MigratingFileSystem，这样能够维持 LOCATION 不变。 ...

HDFS（Hadoop Distributed File System）分布式文件存储系统，次要为各类分布式计算框架如Spark、MapReduce等提供海量数据存储服务，同时HBase、Hive底层存储也依赖于HDFS。HDFS提供一个对立的形象目录树，客户端可通过门路来拜访文件。HDFS集群分为两大角色：Namenode、Datanode（非HA模式会存在Secondary Namenode）NamenodeNamenode是HDFS集群主节点，负责管理整个文件系统的元数据，所有的读写申请都要通过Namenode。元数据管理Namenode对元数据的治理采纳了三种模式：1) 内存元数据：基于内存存储元数据，元数据比拟残缺2) fsimage文件：磁盘元数据镜像文件，在NameNode工作目录中，它不蕴含block所在的Datanode 信息3) edits文件：数据操作日志文件，用于连接内存元数据和fsimage之间的操作日志，可通过日志运算出元数据fsimage + edits = 内存元数据留神：当客户端对hdfs中的文件进行新增或批改时，操作记录首先被记入edit日志文件，当客户端操作胜利后，相应的元数据会更新到内存元数据中 能够通过hdfs的一个工具来查看edits中的信息bin/hdfs oev -i edits -o edits.xml查看fsimagebin/hdfs oiv -i fsimage_0000000000000000087 -p XML -o fsimage.xml 元数据的checkpoint（非HA模式）Secondary Namenode每隔一段时间会查看Namenode上的fsimage和edits文件是否须要合并，如触发设置的条件就开始下载最新的fsimage和所有的edits文件到本地，并加载到内存中进行合并，而后将合并之后取得的新的fsimage上传到Namenode。checkpoint操作的触发条件次要配置参数： dfs.namenode.checkpoint.check.period=60 #查看触发条件是否满足的频率，单位秒dfs.namenode.checkpoint.dir=file://${hadoop.tmp.dir}/dfs/namesecondarydfs.namenode.checkpoint.edits.dir=${dfs.namenode.checkpoint.dir} 以上两个参数做checkpoint操作时，secondary namenode的本地工作目录，次要解决fsimage和edits文件的dfs.namenode.checkpoint.max-retries=3 #最大重试次数dfs.namenode.checkpoint.period=3600 #两次checkpoint之间的工夫距离3600秒dfs.namenode.checkpoint.txns=1000000 #两次checkpoint之间最大的操作记录 checkpoint作用 放慢Namenode启动Namenode启动时，会合并磁盘上的fsimage文件和edits文件，失去残缺的元数据信息，但如果fsimage和edits文件十分大，这个合并过程就会十分慢，导致HDFS长时间处于平安模式中而无奈失常提供服务。SecondaryNamenode的checkpoint机制能够缓解这一问题数据恢复Namenode和SecondaryNamenode的工作目录存储构造完全相同，当Namenode故障退出须要从新复原时，能够从SecondaryNamenode的工作目录中将fsimage拷贝到Namenode的工作目录，以复原Namenode的元数据。然而SecondaryNamenode最初一次合并之后的更新操作的元数据将会失落，最好Namenode元数据的文件夹放在多个磁盘下面进行冗余，升高数据失落的可能性。注意事项：SecondaryNamenode只有在第一次进行元数据合并时须要从Namenode下载fsimage到本地。SecondaryNamenode在第一次元数据合并实现并上传到Namenode后，所持有的fsimage已是最新的fsimage，无需再从Namenode处获取，而只须要获取edits文件即可。SecondaryNamenode从Namenode上将要合并的edits和fsimage拷贝到本人以后服务器上，而后将fsimage和edits反序列化到SecondaryNamenode的内存中，进行计算合并。因而个别须要把Namenode和SecondaryNamenode别离部署到不同的机器下面，且SecondaryNamenode服务器配置要求个别不低于Namenode。SecondaryNamenode不是充当Namenode的“备服务器”，它的次要作用是进行元数据的checkpointDatanodeDatanode作为HDFS集群从节点，大数据培训负责存储管理用户的文件块数据，并定期向Namenode汇报本身所持有的block信息（这点很重要，因为，当集群中产生某些block正本生效时，集群如何复原block初始正本数量的问题）。对于Datanode两个重要的参数：通过心跳信息上报参数<property><name>dfs.blockreport.intervalMsec</name><value>3600000</value><description>Determines block reporting interval in milliseconds.</description></property> Datanode掉线判断时限参数Datanode过程死亡或者网络故障造成Datanode无奈与Namenode通信时，Namenode不会立刻把该Datanode断定为死亡，要通过一段时间，这段时间称作超时时长。HDFS默认的超时时长为10分钟30秒。如果定义超时工夫为timeout，则超时时长的计算公式为：timeout = 2 heartbeat.recheck.interval（默认5分钟） + 10 dfs.heartbeat.interval（默认3秒）。<property><name>heartbeat.recheck.interval</name> 单位毫秒<value>2000</value></property><property><name>dfs.heartbeat.interval</name> 单位秒<value>1</value></property> HDFS读写数据流程理解了Namenode和Datanode的作用后，就很容易了解HDFS读写数据流程，这个也是面试中常常问的问题。HDFS写数据流程留神：1.文件block块切分和上传是在客户端进行的操作2.Datanode之间自身是建设了一个RPC通信建设pipeline3.客户端先从磁盘读取数据放到一个本地内存缓存，开始往Datanode1上传第一个block，以packet为单位，Datanode1收到一个packet就会传给Datanode2，Datanode2传给Datanode3；Datanode1每传一个packet会放入一个应答队列期待应答4.当一个block传输实现之后，客户端会告诉Namenode存储块结束，Namenode将元数据同步到内存中 Datanode之间pipeline传输文件时，个别依照就近可用准则a) 首先就近筛选一台机器b) 优先选择另一个机架上的Datanodec) 在本机架上再随机筛选一台HDFS读数据流程留神：Datanode发送数据，是从磁盘外面读取数据放入流，以packet为单位来做校验客户端以packet为单位接管，先在本地缓存，而后写入指标文件客户端将要读取的文件门路发送给namenode，namenode获取文件的元信息（次要是block的寄存地位信息）返回给客户端，客户端依据返回的信息找到相应datanode一一获取文件的block并在客户端本地进行数据追加合并从而取得整个文件HDFSHA机制HA：高可用，通过双Namenode打消单点故障。双Namenode协调工作的要点：元数据管理形式须要扭转a) 内存中各自保留一份元数据b) edits日志只能有一份，只有active状态的Namenode节点能够做写操作c) 两个Namenode都能够读取editsd) 共享的edits放在一个共享存储中治理（qjournal和NFS两个支流实现，图中以放在一个共享存储中治理（qjournal和为例）须要一个状态治理功能模块a) 实现了一个zk failover，常驻在每一个Namenode所在的节点b) 每一个zk failover负责监控本人所在Namenode节点，利用zk进行状态标识，当须要进行状态切换时，由zk failover来负责切换，切换时须要避免brain split景象的产生

咱们在HDFS - 什么是元数据中提到了，元数据会存在与内存和磁盘中，内存为了进步响应速度，磁盘是为了长久化保证数据的平安，然而写磁盘的速度绝对于内存是慢了几个数量级的，如果NameNode每次都要把数据落到磁盘上那是没方法解决那么多客户端的申请的，所以NameNode用了双缓冲机制以及分段加锁。所谓双缓冲就是定义了两个内存块，一个是bufCurrent，用于以后写入元数据的，一个是bufReady，用于写入磁盘的，两个内存块都是512k。 第一把锁线程1会先获取锁，而后会看看以后有没有在替换缓存（这里通过isAutoSyncScheduled来判断），如果没有，就去获取一个全局惟一的事务ID，这个ID是递增的。拿到事务ID后，就开始写入bufCurrent，写完后判断bufCurrent是否超过了512k，如果没有，线程1的流程就完结了（前面完结的背景是红色的）。因为线程2，3，4在线程1没开释锁的时候，都会始终等到，如果线程2，3，4拿到了锁，也会持续下面线程1的操作。因为这个锁里的操作都是基于内存的，所以速度就会十分块。咱们假如线程4写完后，发现bufCurrent内存超过了512k，此时就会把isAutoSyncScheduled设置为true，阐明要开始替换内存了，其余线程就不能做以上的操作了。这里的bufCurrent就是线程1，2，3，4写入的数据。这个时候，线程5进来并拿到锁，咱们给拿锁的过程色彩标深一点，发现要开始替换内存了，于是他就是wait状态。 第二把锁咱们假如接下来获取到锁的是线程4。他发现此时并没有其余线程替换内存（这里通过isSyncRunning判断），于是他就开始bufCurrent和bufReady的内存进行了替换，替换后，bufCurrent的数据就清空了。在这里还会把isSyncRunning设置true，而后isAutoSyncScheduled设置为false，最初就唤醒wait的线程。线程4唤醒其余线程后，他就开始把bufReady的数据写入磁盘，这个操作是很耗时的，所以并没有加锁，然而他是运行状态，所以下图标记为绿色。这里的bufReady就是线程1，2，3，4写入的数据。此时是线程5获取了锁，发现内存替换结束了，开始往bufCurrent写数据。尔后线程6拿到了锁，此时bufCurrent又超过了512k了，就会把isAutoSyncScheduled设置为true，阐明开始替换内存，其余线程就不能往bufCurrent写入数据了。然而他发现isSyncRunning为true，阐明有其余线程在写磁盘了，所以他就开始wait。 第三把锁此时线程4写完了磁盘，而后他获取到锁，就会把synctxid更改为本人的事务ID，而后赋值isSyncRunning为false，阐明磁盘写入实现了。最初唤醒其余wait的线程。此时线程6从新拿到了锁，他发现isSyncRunning为false了，那就是阐明其余线程曾经把本人的内容刷入磁盘了，所以线程6开始了下面线程4的操作，替换内存，写入磁盘。 总结第一把锁，次要是判断isAutoSyncScheduled以及对isAutoSyncScheduled的赋值，这个次要是阐明bufCurrent和bufReady开始替换内存了。第二把锁，次要是判断isSyncRunning以及对isSyncRunning和isAutoSyncScheduled的赋值。isSyncRunning是用来判断是否在写磁盘，isAutoSyncScheduled用来判断是否在替换内存，如果在替换，就不能写入bufCurrent，如果在写磁盘，那就不能写磁盘。第三把锁，赋值isSyncRunning，阐明磁盘写入实现。这期间最耗时的操作并没有加锁，其余内存操作的加锁，然而速度比拟快，采纳在这种分段加锁的形式和双缓冲机制，大大提高了性能。

HDFS简介HDFS是Hadoop外围组成, 是分布式存储服务HDFS是分布式文件系统中的一种 HDFS的重要概念HDFS通过对立的命名空间目录树来定位文件另外, 它是分布式的, 由很多服务器联结起来实现其性能. 集群中的服务器有各自的角色(分布式实质是拆分, 各司其职)典型的Master/Slave架构HDFS的架构是典型的Master/Slave构造HDFS集群往往是一个NameNode+多个DataNode组成NameNode是集群的主节点, DataNode是集群的从节点分块存储(block机制)HDFS中的文件在物理是分块存储(block)的, 块的大小能够通过配置参数来指定Hadoop2.x版本中默认的block大小是128M命名空间(NameSpace)HDFS反对传统的档次型文件组织构造.用户或者应用程序能够创立目录, 而后将文件保留在这些目录里.文件系统命名空间的层次结构和大多数现有的文件系统相似: 用户能够创立, 删除, 挪动或重命名文件NameNode负责保护文件系统的命名空间, 任何对文件系统命名空间或属性的批改都将被NameNode记录下来 NameNode元数据管理咱们把目录构造及文件分块地位叫做元数据NameNode的元数据记录每一个文件所对应的block信息(block的id, 以及所在的DataNode节点)DataNode数据存储文件的各个block的具体存储管理由DataNode节点来承当一个block会有多个DataNode来存储, DataNode会定时向NameNode来汇报本人持有的block信息正本机制为了容错, 文件的所有block都会有正本每个文件的block大小和正本系数都是可配置的应用程序能够指定某个文件的正本数目正本系数能够在文件创建的时候指定, 也能够在之后扭转正本数量默认是3个一次写入, 屡次读出HDFS设计成适应一次写入, 屡次读出的场景, 且不反对文件的随机批改 . (反对追加写入, 不反对随机更新)正因为如此, HDFS适宜用来做大数据分析的底层存储, 并不适宜用来做网盘等利用 (批改不不便, 提早大, 网络开销大, 老本太高)HDFS架构 NameNode: HDFS集群的管理者, Master 保护治理HDFS的命名空间(NameSpace)保护正本策略记录文件块(Block)的映射信息负责解决客户端读写申请DataNode: NameNode下达命令, DataNode执行实际操作, Slave 保留理论的数据块负责数据块的读写Client: 客户端 上传文件到HDFS的时候, Client负责将文件切分成Block, 而后进行上传申请NameNode交互, 获取文件的地位信息读取或写入文件, 与DataNode交互Client能够应用一些命令来治理HDFS或拜访HDFS HDFS读写解析HDFS读数据流程 客户端通过Distributed FileSystem向NameNode申请下载文件, NameNode通过查问元数据找到文件块所在的DataNode地址筛选一台DataNode(就近准则, 而后随机)服务器, 申请读取数据DataNode开始传输数据给客户端 (从磁盘外面读取数据输出流, 以Packet为单位来做校验)客户端以Packet为单位接管, 先在本地缓存, 而后写入指标文件HDFS写数据流程 客户端通过Distributed FileSystem模块向NameNode申请上传文件, NameNode查看指标文件是否已存在, 父目录是否存在NameNode返回是否能够上传客户端申请第一个Block上传到哪几个DataNode服务器上NameNode返回3个DataNode节点, 别离是dn1, dn2, dn3客户端通过FSDataOutputStream模块申请dn1上传数据, dn1收到申请会持续调用dn2, 而后dn2调用dn3, 将这个通信管道建设实现dn1, dn2, dn3逐级应答客户端NN与2NNNN故障解决Hadoop的限额与归档以及集群平安模式

HDFS 文件读取流程 Client 端调用 DistributedFileSystem 对象的 open() 方法。 由 DistributedFileSystem 通过 RPC 向 NameNode 请求返回文件的 Block 块所在的 DataNode 的地址。（我们知道 HDFS 默认策略对某个 Block 会保存三份副本到不同的 DataNode，那么 NameNode 应该返回那个 DataNode？答案是根据 DataNode 到 Client 端的距离。假设请求的 Block 块刚好就落在 Client 端所在机器上，即 Client 端本身也是 DataNode，那么毫无疑问 DataNode 将会返回 Client 端所在机器地址。这也验证了 Hadoop 的一个设计特性，移动计算而不是移动数据，极大了减小了带宽。） Client 端调用 FSDataInputStream 对象的 read() 方法，通过 FSDataInputStream 向 DataNode 获取 Block 数据。之后数据流源源不断地从 DataNode 返回至 Client。当最后一个 Block 返回至 Client 端后， DFSInputStream 会关闭与 DataNode 连接。上述过程对 Client 端都是透明的，从 Client 来看，它只是在不停的读取数据流。 ...

HDFS 文件读取流程 The client opens the file it wishes to read by calling open() on the FileSystem object, which for HDFS is an instance of DistributedFileSystem (step 1 in Figure 3-2). DistributedFileSystem calls the namenode, using remote procedure calls (RPCs), to determine the locations of the first few blocks in the file (step 2). For each block, the namenode returns the addresses of the datanodes that have a copy of that block. ...

1.准备hadoop源码编译后的客户端，便于改动追踪代码上传文件，ec目录和普通目录均上传测试：hadoop fs -put hadoop-hadoop-datanode-cluster-host1.log hdfs://hadoop1:9000/userhadoop fs -put hadoop-hadoop-datanode-cluster-host1.log hdfs://hadoop1:9000/ecec目录：普通目录：]

客户端写数据到HDFS的流程：client就是shell命令行1.client先发送给namenode一个写数据请求2.namenode返回允许写请求3.client向namenode请求写BLK14.namenode返回告知BLK1写入哪几个机器 （ex. dn1,dn2,dn3）5.找dn1建立数据传输的链接6.dn2和dn3分别建立连接7.dn1,dn2,dn3分别返回连接是否建立成功8.client正式开始数据的传输到dn1,然后dn1-->dn2,dn2-->dn39.传输完成之后告知namenode，记录文件名，大小，副本数量，分别记录信息

在每次hdfs namenode -format之后，namenode的cluster id都会被自动更新，一般这种情况先去看datanode的logs日志，确定是cluster id不一致的问题了，这时候应该去到hdfs的tmp/dfs/current文件下，把datanode的cluster id更新成和namenode一样的cluster id就可以了

整体：https://segmentfault.com/a/11...HDFS是hadoop的最底层存储部分官方：http://hadoop.apache.org/docs...HDFS是每台机器运行的守护进程，对外暴露网络服务，允许其他节点访问存储在该机器上的文件NameNode跟踪哪个文件块存储在哪台机器上 架构 先从namenode获取元数据，再到具体的datanode中读取数据。 namespace:允许每个命名空间的NN自定义DNid的ip，无需和另一个NS商议。删除命名空间可删除自己的dn,nn。比如在NN1的DN1:IP2,NN3的DN2:IP4的配置： <property> <name>dfs.nameservices</name> <value>ns1,ns2</value></property><property> <name>dfs.nameservices.ns1</name> <value>nn1,nn2</value></property><property> <name>dfs.namenode.rpc-addr.ns1.nn1</name> <value>ip1:8082</value></property><property> <name>dfs.nameservices.ns2</name> <value>nn3,nn4</value></property><property> <name>dfs.namenode.rpc-addr.ns2.nn3</name> <value>ip4:8082</value></property>NN：存放每个节点的路由。可以每个机器放一个+n个dn。为了保证可靠性，每个NS都有两个NN，多NN的HA保证：1.使用共享存储，存放nnlog，一个写一个读同步+zk自动故障转移SNN在升级前确保log同步全，两个机器同时发心跳和block-map，为了保证只有一个ANN写入NFS，一个ANN发出写DN，只有一个ANN对客户端做响应。必须在ANN降级后切段写入，确保网络延时的数据等不再写入。2.QJM。QJM奇数个节点，轻量级，可以混部，QJM负责NN的接管转换隔离，写入持久化，读写一致性，自动故障还是要用zk。 还可以增加集中式缓存，DN将缓存上报到NN，NN路由到缓存节点存储：DISK,ARCHIVE（pb级，冷存档）,RAM_DISK（HDFS支持写入由数据节点管理的堆外内存。数据节点将异步刷新内存中的数据到磁盘，从而从性能敏感的IO路径中删除昂贵的磁盘IO和校验和计算，因此我们称这种写入为Lazy Persist写入。HDFS为Lazy Persist Writes提供尽力而为的持久性保证。如果在将副本持久保存到磁盘之前重新启动节点，则可能会丢失数据。应用程序可以选择使用Lazy Persist Writes来换取一些持久性保证，以减少延迟）,SDD

环境环境使用：hadoop3.1，Python3.6，ubuntu18.04Hadoop是使用Java开发的，推荐使用Java操作HDFS。有时候也需要我们使用Python操作HDFS。本次我们来讨论如何使用Python操作HDFS，进行文件上传，下载，查看文件夹，以及如何使用Python进行MapReduce编程。使用Python操作HDFS首先需要安装和导入hdfs库，使用pip install hdfs。1. 连接并查看指定路径下的数据from hdfs import * client = Client(‘http://ip:port’) #2.X版本port 使用50070 3.x版本port 使用9870client.list(’/’) #查看hdfs /下的目录2. 创建目录client.makedirs(’/test’)client.makedirs(’/test’,permision = 777 ) # permision可以设置参数3. 重命名、删除client.rename(’/test’,‘123’) #将/test 目录改名为123client.delete(’/test’,True) #第二个参数表示递归删除 4.下载将/test/log.txt 文件下载至/home目录下。client.download(’/test/log.txt’,’/home’) 5. 读取with client.read("/test/[PPT]Google Protocol Buffers.pdf") as reader: print reader.read()其他参数：read(args, *kwds) hdfs_path：hdfs路径 offset：设置开始的字节位置 l- ength：读取的长度（字节为单位） buffer_size：用于传输数据的字节的缓冲区的大小。默认值设置在HDFS配置。 encoding：指定编码 chunk_size：如果设置为正数，上下文管理器将返回一个发生器产生的每一chunk_size字节而不是一个类似文件的对象 delimiter：如果设置，上下文管理器将返回一个发生器产生每次遇到分隔符。此参数要求指定的编码。 progress：回调函数来跟踪进度，为每一chunk_size字节（不可用，如果块大小不是指定）。它将传递两个参数，文件上传的路径和传输的字节数。称为一次与- 1作为第二个参数。6.上传数据将文件上传至hdfs的 /test下。client.upload(‘/test’,’/home/test/a.log’)Python-MapReduce编写mapper代码，map.py：import sysfor line in sys.stdin: fields = line.strip().split() for item in fields: print(item + ’ ’ + ‘1’)编写reducer代码，reduce.py：import sysresult = {}for line in sys.stdin: kvs = line.strip().split(’ ‘) k = kvs[0] v = kvs[1] if k in result: result[k]+=1 else: result[k] = 1for k,v in result.items(): print("%s\t%s" %(k,v))添加测试文本，test1.txt：tale as old as timetrue as it can bebeauty and the beast本地测试执行map代码：cat test1.txt | python map.py结果：tale 1as 1old 1as 1time 1true 1as 1it 1can 1be 1beauty 1and 1the 1beast 1本地测试执行reduce代码：cat test1.txt | python map.py | sort -k1,1 | python reduce.py执行结果：and 1be 1old 1beauty 1true 1it 1beast 1as 3can 1time 1the 1tale 1在Hadoop平台执行map-reduce程序本地测试完毕，编写脚本在HDFS中执行程序脚本：run.sh （请根据本机环境修改）HADOOP_CMD="/app/hadoop-3.1.2/bin/hadoop"STREAM_JAR_PATH="/app/hadoop-3.1.2/share/hadoop/tools/lib/hadoop-streaming-3.1.2.jar"INPUT_FILE_PATH_1="/py/input/“OUTPUT_PATH="/output”$HADOOP_CMD fs -rmr-skipTrash $OUTPUT_PATH# Step 1.$HADOOP_CMD jar $STREAM_JAR_PATH -input $INPUT_FILE_PATH_1 -output $OUTPUT_PATH -mapper “python map.py” -reducer “python reduce.py” -file ./map.py -file ./reduce.py \添加执行权限chmod a+x run.sh；执行测试：bash run.sh，查看结果：练习1. 文件合并去重输入文件file1的样例如下：20150101 x20150102 y20150103 x20150104 y20150105 z20150106 x输入文件file2的样例如下：20150101 y20150102 y20150103 x20150104 z20150105 y根据输入文件file1和file2合并得到的输出文件file3的样例如下：20150101 x20150101 y20150102 y20150103 x20150104 y20150104 z20150105 y20150105 z20150106 x对于两个输入文件，即文件file1和文件file2，请编写MapReduce程序，对两个文件进行合并，并剔除其中重复的内容，得到一个新的输出文件file3。为了完成文件合并去重的任务，你编写的程序要能将含有重复内容的不同文件合并到一个没有重复的整合文件，规则如下：第一列按学号排列；学号相同，按x,y,z排列。2. 挖掘父子关系输入文件内容如下：child parentSteven LucySteven JackJone LucyJone JackLucy MaryLucy FrankJack AliceJack JesseDavid AliceDavid JessePhilip DavidPhilip AlmaMark DavidMark Alma输出文件内容如下：grandchild grandparentSteven AliceSteven JesseJone AliceJone JesseSteven MarySteven FrankJone MaryJone FrankPhilip AlicePhilip JesseMark AliceMark Jesse你编写的程序要能挖掘父子辈关系，给出祖孙辈关系的表格。规则如下：孙子在前，祖父在后孙子相同，祖父的名字按照A-Z排列 ...

通过研究一些不太常用的替代方案来解决MapReduce性能问题以及选择解决方案时要考虑的因素。解决MapReduce性能问题以下解决方案来缓解MapReduce性能问题：更改摄取过程/间隔批处理文件合并序列文件HBaseS3DistCp（如果使用Amazon EMR）使用CombineFileInputFormatHive配置使用Hadoop的附加功能已经讨论过更改摄取过程，批处理文件合并和序列文件。Hbase如果要生成大量小文件，将数据作为文件存储在HDFS中可能不是最佳解决方案。相反，您可以考虑使用HBase列存储。使用HBase可以将摄取过程从生成许多小型HDFS文件更改为将单个记录写入HBase表。如果您的数据访问模式基于明确定义的随机访问查找，则HBase可能是您的最佳选择。它在架构上针对高速数据记录插入，大容量，单个记录查找和基于流的分析进行了调整。但是，如果您的数据访问模式倾向于完整文件/表扫描，那么HBase可能不是最佳的。可以创建映射到HBase数据的Hive表; 但是，此设计中的查询性能会有所不同。当选择单行或一系列行时，HBase上的Hive会闪烁，但如果您的查询倾向于全表扫描，则HBase的效率非常低。大多数分析查询，尤其是那些使用group by的查询，都需要进行全表扫描。HBase提供了将数据流式传输到Hadoop并使其可实时处理的最佳能力。但是，平衡HBase与其他集群进程的需求可能具有挑战性，并且需要高级系统管理。此外，HBase性能在很大程度上取决于数据访问模式，在选择HBase解决小文件问题之前，应仔细考虑这些模式。S3DistCp此解决方案仅适用于Amazon EMR的用户。Amazon EMR集群的生命周期很短，将数据保存在Amazon S3中。即使使用Amazon S3，处理大量小文件仍然会导致启动不必要的map任务，从而降低性能。S3DistCp是亚马逊提供的一种实用程序，用于将数据从S3分发复制到临时HDFS甚至其他S3存储桶。该实用程序提供了通过使用groupBy和targetSize选项将文件连接在一起的功能。当您在S3中存储了数千个要使用Amazon EMR处理的小文件时，这非常有用。S3DistCp通过连接许多小文件并使它们出现在更快，短暂的HDFS存储中，一举两得。据报道，使用这种机制可以提高15倍的性能。出于所有实际目的，S3DistCp执行与提到的批处理文件合并方法相同的任务。如果使用Amazon EMR，请注意您有一个预先构建的工具来完成此任务。使用CombineFileInputFormatCombineFileInputFormat是Hadoop提供的抽象类，它在MapReduce读取时合并小文件。合并的文件不会持久保存到磁盘。相反，该过程读取多个文件并“动态”合并它们以供单个map任务使用。您可以获得不为每个文件启动一个map任务的好处，并且不需要将多个文件合并到一个持久文件中作为准备步骤的一部分。这解决了MapReduce作业启动太多map任务的问题; 但是，由于作业仍在读取多个小文件，因此随机磁盘IO仍然存在问题。此外，CombineFileInputFormat的大多数实现都不考虑数据局部性，并且通常会通过网络从各种数据节点提取数据。为了实现这一点，必须在Java中为不同的文件类型扩展CombineFileInputFormat。这需要大量的开发专业知识来开发您的自定义输入格式类。但是，一旦编写，您可以配置最大分割大小，它将合并文件，直到满足此大小。请注意，由于合并数据不会在HDFS中保留，因此CombineFileInputFormat不会缓解NameNode内存问题。Hive配置如果您注意到Hive通过“create table as”或“insert overwrite”语句在Hadoop集群中创建小文件，则可以调整一些Hive特定配置设置以进行缓解。使用时，这些设置会告诉Hive将创建的任何小文件合并到较大的文件中。但是，有一个惩罚。Hive将启动一个额外的MapReduce作业后查询，以执行合并。此外，在Hive向用户指示查询已完成处理而不是异步发生之前完成合并。应该注意，这些设置仅适用于由Hive创建的文件。例如，如果使用其他工具（如Sqoop）在Hive外部创建文件，则使用hdfs fs -mv命令将其复制到Hive表中，Hive将不会合并文件。因此，当摄入Hadoop的文件很小时，此解决方案不起作用。此解决方案仅建议在以Hive为中心的体系结构中，其中insert overwrite和create table as语句中的小性能损失是可接受的。要使用的设置是：使用Hadoop的附加功能附加可能是可用的，但Hadoop生态系统中的主要工具都不支持它：Flume，Sqoop，Pig，Hive，Spark和Java MapReduce。MapReduce强制执行一条规则，即MapReduce作业的输出位置在执行之前不得存在。由于这个规则，MapReduce显然不可能通过其输出附加到预先存在的文件。由于Sqoop，Pig和Hive都使用了MapReduce，因此这些工具也不可能支持追加。Flume不支持追加很大程度上是因为它假设经过一段时间（无论是秒，字节，事件数或不活动秒），Flume将关闭文件而不再打开它。Flume社区认为这足够，而不是要求追加支持。如果你真的必须在Hadoop中使用appends，你必须编写自己的系统来执行摄取并附加到现有文件。此外，如果您的任何群集内处理需要附加到现有文件，您将无法使用Spark或MapReduce。因此，使用HDFS附加功能非常复杂，只能由技术最精湛的组织使用。如果没有重要的工程团队和支持承诺，则不建议使用此选项。选择解决方案选择使用小文件的最佳解决方案取决于各种问题。可能有必要根据访问模式和数据要求使用这些解决方案的组合。应该考虑的问题包括：数据流中的哪一点是生成的小文件？是在摄取时还是通过群集内处理创建小文件？生成小文件的工具是什么？更改工具配置可以减少小文件的数量吗？您的组织有多少技术技能？您是否有能力维护输入格式或编写自己的摄取引擎？生成小文件的频率是多少？为了创建大文件，可以多久合并一次小文件？这些小文件需要哪种数据访问？这些文件是否需要通过Hive访问？可以在集群内部运行流程以减轻小文件的管理周期类型？MapReduce流程可接受的延迟级别是多少？

[TOC]在第一篇文章中，我讨论了什么构成了一个小文件，以及为什么Hadoop存在小文件问题。我将一个小文件定义为小于Hadoop块大小75％的任何文件，并解释说由于NameNode内存使用和MapReduce性能，Hadoop更喜欢较少的较大文件。在这篇文章中，当小文件真正不可避免时，我将讨论这些挑战的解决方案。解决NameNode内存问题正如之前的文章中所讨论的，Hadoop中每个块的元数据必须存储在NameNode的内存中。这导致实际限制Hadoop中可以存储的对象数量，并且还会影响启动时间和网络带宽。有两种解决方案，减少Hadoop集群中的对象数量，或以某种方式使NameNode更多地使用内存 - 但不会导致过多的启动时间。解决此内存问题的最常用方法涉及Hadoop存档（HAR）文件和联合NameNodes。Hadoop存档文件Hadoop归档文件通过将许多小文件打包到更大的HAR文件中来缓解NameNode内存问题，类似于Linux上的TAR文件。这导致NameNode保留单个HAR文件的知识，而不是数十个或数百个小文件。可以使用har://前缀而不是hdfs://来访问HAR文件中的文件。HAR文件是从HDFS中存在的文件创建的。因此，HAR文件可以合并摄取的数据以及通过正常的MapReduce处理创建数据。可以独立于用于创建小文件的技术来使用HAR文件。除了HDFS之外没有共同的依赖。虽然HAR文件减少了许多小文件的NameNode内存占用，但访问和处理HAR文件内容的效率可能会降低。HAR文件仍然随机存储在磁盘上，并且读取HAR内的文件需要两个索引访问 - 一个用于NameNode以找到HAR文件本身，一个用于在HAR内查找小文件的位置。在HAR中读取文件实际上可能比读取本机存储在HDFS上的相同文件慢。MapReduce作业会影响此性能问题，因为它们仍将在HAR中的每个文件中启动一个map任务。最后，你有一个HAR文件可以解决NameNode内存问题，但可能会恶化处理性能。如果您的小文件主要用于存档目的，并且不经常访问，那么HAR文件是一个很好的解决方案。如果小文件是正常处理流程的一部分，您可能需要重新考虑您的设计。Federated NameNodesFederated NameNodes允许您在群集中拥有多个NameNode，每个NameNode都存储对象元数据的子集。这消除了将所有对象元数据存储在单个机器上的需要，从而为内存使用提供了更多的扩展。从表面上看，用这种技术解决小文件内存问题很有吸引力，但是稍微想一想你会很快意识到这些局限性。Federated NameNodes隔离对象元数据 - 只有一个NameNode知道任何特定对象。这意味着要获取文件，您必须知道要使用哪个NameNode。如果您的群集包含多个租户或孤立的应用程序，那么Federated NameNode很自然 - 您可以通过租户或应用程序隔离对象元数据。但是，如果要在群集中的所有应用程序之间共享数据，则此方法并不理想。由于Federated实际上不会更改群集中的对象或块的数量，因此它无法解决MapReduce性能问题。相反，Federated为您的Hadoop安装和管理增加了重要且通常不必要的复杂性。当用于解决小文件问题时，通常更多的是隐藏小文件问题的机制。解决MapReduce性能问题MapReduce性能问题是由随机磁盘IO和启动/管理太多map任务的组合引起的。解决方案似乎很明显 - 拥有更少，更大的文件或启动更少的map任务; 然而，这说起来容易做起来难。一些最常见的解决方案包括：更改摄取过程/间隔批处理文件合并序列文件HBaseS3DistCp（如果使用Amazon EMR）使用CombineFileInputFormatHive配置使用Hadoop的附加功能更改摄取过程/间隔摆脱小文件的最简单方法就是不首先生成它们。如果源系统生成数千个复制到Hadoop的小文件，请调查更改源系统以生成一些大文件，或者在摄取到HDFS时可能连接文件。如果您每小时仅摄取10 MB数据，请确定是否每天只能摄取一次。您将创建1x240MB文件而不是24x10MB文件。但是，您可能无法控制创建文件的源系统或业务需求要求您以间隔频率接收数据，以便小文件不可避免。如果小文件确实是不可避免的，那么应该考虑其他解决方案。批处理文件合并当小文件不可避免时，文件合并是最常见的解决方案。使用此选项，您可以定期运行一个简单的合并MapReduce作业来读取文件夹中的所有小文件，并将它们重写为更少的大文件。如果文件夹中有1000个文件，并且MapReduce作业仅指定5个文件，则1000个输入文件将合并为5个输出文件。接下来是一些简单的HDFS文件/文件夹操作，您将内存占用减少了200:1，并且可能提高了对同一数据的未来MapReduce处理的性能。这可以在Pig，load和store语句中实现。例如，如果合并文本文件：在Hive或Java MapReduce中实现这一点也同样容易。这些MapReduce作业在执行时显然需要集群资源，并且通常在非工作时间进行调度。但是，应该足够频繁地运行它们，这样小文件的性能影响就不会变得太大。通常在这些作业中内置额外的逻辑，以便只合并文件夹中对性能有显著影响的文件。在一个仅包含三个文件的文件夹中合并文件的性能优势不如在一个包含500个小文件的文件夹中合并文件。检查文件夹以确定应合并哪些文件夹可以通过多种方式完成。例如，Pentaho数据集成作业可用于迭代HDFS中的一组文件夹，找到满足最小合并要求的文件夹。还有一个专门为此任务设计的预编写应用程序名为File Crush，这是一个由Edward Capriolo编写的开源项目。File Crush不受专业支持，因此不保证它将继续与未来版本的Hadoop一起使用。批处理文件合并不会保留原始文件名。如果拥有原始文件名对于处理或了解数据来源非常重要，则批处理文件合并将不起作用。但是，大多数HDFS设计在文件夹级别而不是在每个文件中嵌入命名语义。采用这种做法会将文件名依赖性作为一个问题删除。序列文件当需要维护原始文件名时，一种非常常见的方法是使用Sequence文件。在此解决方案中，文件名作为密钥存储在序列文件中，文件内容作为值存储。下表给出了如何将小文件存储在序列文件中的示例：如果您有10,000个小文件，则您的序列文件将包含10,000个密钥，每个文件一个。序列文件支持块压缩，并且是可拆分的，这意味着MapReduce作业每个128MB块只能启动一个map任务，而不是每个小文件一个map任务。当您需要维护输入文件名，并且同时摄取数百或数千个小文件时，这非常有效。但是，如果您一次只提取少量小文件，则序列文件也不能正常工作，因为Hadoop文件是不可变的，无法追加。三个10MB文件将产生30MB的序列文件，根据我们的定义，这仍然是一个小文件。另一个挑战是检索序列文件中的文件名列表需要处理整个文件。此外，Hive在此结构中与序列文件不兼容。Hive将值中的所有数据视为单行。使用Hive查询此数据并不容易，因为文件的整个内容将是Hive中的单行。最后，您创建的Hive表将无法访问序列文件密钥，文件名，并且只能访问值，即文件的内容。可以编写自定义Hive serde来解决这些挑战，但这是一个超越Hadoop本机功能的高级功能。结论我们讨论了使用Hadoop Archive（HAR）文件来最小化NameNode内存使用的权衡。我们讨论并驳回了使用Federated NameNodes作为小文件问题的灵丹妙药。并且，我们为小文件整合引入了一些常用的解决方案 - 这些解决方案可以提高NameNode内存使用率和MapReduce性能。

实际上,关于Hadoop及其生态系统的文章或者书籍已经汗牛充栋,在2016年大数据这个概念兴起的时候,有幸于能进入数据行业。虽然,在这2年里,并没有达到自己最初的期望,不过还是跨出了那么一步。 这里,我们简单的聊聊Hadoop及其生态圈(系统),不做太深入的探讨。Hadoop是什么?在互联网上经常看到Hadoop和大数据的名词,那么有时候有没有想过什么是Hadoop呢? Hadoop是什么,是1个使用Java编写的分布式系统架构。它让用户在不了解分布式底层细节的情况下,可以开发出分布式程序,并充分利用集群进行高速运算和存储。 现在,你应该知道Hadoop是什么了吧。Hadoop的组成在Hadoop的框架版本1.0中,最核心的设计是:HDFSMapReduce其中HDFS是Hadoop Distributed File System的缩写,是1个分布式文件系统,实际操作与POSIX(如Unix、Linux)系统的操作类似。这个文件系统提供了海量数据的存储,可以部署在低廉的硬件上。这对企业来说是1个很不错的选择,在硬件成本上降低了不少却完成了任务。 而MapReduce主要是为海量数据提供了计算。这样,通过Hadoop这个架构,我们就可以实现对海量数据的存储、访问与计算。 而在Hadoop版本2.0中,其核心设计演变为:HDFSYARN在这里,MapReduce被YARN所替代。YARN是1个Hadoop的资源管理器,它为上层应用提供了统一的资源管理和调度。它的引入,为集群在利用率、资源统一管理和数据共享等方面带来了巨大的好处。此时的Hadoop就不再是1个简单MapReduce处理的架构了。Hadoop适合怎样的应用场景?对于Hadoop适应的应用场景的问题,我们先来说下它不适合的场景:Hadoop不适合实时计算与分析方面的应用Hadoop不适合大量小文件处理场景Hadoop不适合低延迟数据访问场景Hadoop不适合多用户写入的场景由于Hadoop在设计的最初被设计为针对超大文件及流式数据访问,因此Hadoop适合如下一些场景:日志处理非实时的数据分析海量存储,比如ETL广告推荐离线计算需要注意的是,Hadoop只是1个架构。具体的应用场景,还需要借助它生态圈的其他工具来完善。Hadoop的生态圈有哪些?Hadoop的生态圈主要包括:Hive,提供数据仓库的数据分析Pig,提供数据流处理Mahout,提供数据挖掘相关算法HBase,提供分布式、实时、高维数据库Sqoop,提供关系型数据库数据与Hadoop的导入导出Flume,提供日志收集Zookeeper,提供分布式协作服务其结构如下图所示:Hadoop有哪些替代产品?由于Hadoop设计的问题以及企业业务的要求,存在如下一些替代Hadoop的产品:SparkFlinkdisco其中以Spark作为代表,最有潜力可以替代Hadoop。但是需要注意的是,Hadoop只是1个工具,存在其他替代品是很正常的。但是,这并不代表Hadoop会在未来就消失,只是在某些场景上使用的更少一些而已。 毕竟,Hadoop已经比较成熟和稳定,生态也相对完善,因此企业也喜欢应用。Hadoop与Spark有什么区别?Spark是另外1个大数据处理框架,相比Hadoop,其将计算数据存储在内存而不是硬盘,因此计算性能上比Hadoop快很多,可以作为Hadoop的1种补充。 相比Hadoop,Spark更适用于实时处理与分析的场景,另外在Spark中还提供了图计算GraphX及机器学习的Mlib库,通用性比Hadoop更强一些。 另外,Spark不是非要依附在Hadoop上才能生存,它可以与其他的分布式文件系统进行集成来运作。对于大数据开发来说,很多情况下是堆积木的1个过程。 对于大数据的技术栈而言,存在多个可选的方案而不是完全替代的方案。毕竟在软件工程项目中,是要考虑成本的,我们需要根据项目的经费选择合适的技术方案。学习Hadoop能拿高薪吗?任何1门高薪的职业,必定有其不可替代的技术门槛和技能要求,比如基金经理,必定是金融行业那么一撮的精英的存在,但是人家也要至少花个1亿美金的操练才可能称为称职的职业人士。 如果单纯觉得学习1个Hadoop就可以拿到高薪,那只能是痴人说梦话。当然,不排除一些培训机构会打着这样的幌子让你去培训。而要拿到高薪需要具有如下一些条件:有这样需求和给得起钱的企业你具有相关的职业技能你具有相关的学历具备相关面试技巧在2018年,可以说大家都过得小心翼翼,加薪是1件不容易的事情。伴随着2018各家厂商的裁员,人们在互联网的冬天的呼喊中迎来2019年爆竹声。随着资本会在2019年逐渐回归本质,但是要真的想通过大数据拿到高薪还是1件不容易的事情。 据不准确统计,实际上在招聘中很多企业虽然给出了大数据相关的岗位,但是并不代表它能提供给你合适的岗位。很多中小型企业招聘1个职位,实际上很多情况下它也不知道具体的岗位要求是什么,只能在网上搜罗一些关键词进行填写。可想而言,开出的薪资自然不尽如意。 另外,有些企业只是为了单纯的刷新存在感,发布一些招聘职位,而并不打算招聘,为了避免浪费时间,还需要擦亮眼睛。 排除了上述第1个外部原因,需要有这样需求和给得起前的企业的外因后,那么剩下的内因就是招聘人员自身的水平了。 首先,1家靠谱的企业总有完善的招聘流程,如果自己不是过硬的学历,比如985院校毕业。那么,要进入大数据行业真的会被拒之门外。另外,要想拿高薪,还需要具备过硬的心理素质和技术能力,而不是我对Hadoop及其生态系统有所了解,就可以轻松进入的。 在大数据行业中,加班加点是常饭,因为数据有时候真的很令人堪忧,自然是逃脱不了的事情。 当然,万事都不是绝对的。有些企业还是要转型的,会开设这样的研发部门,此时还是比较容易进去的。有必要进入大数据行业吗?大数据行业的工作,是1个考验综合能力的职位,绝不是网上一些公众号宣称的那么神奇和简单。 如果只是为了高薪而随意进入1个行业,是件挺危险的事情。如果在事先没有考虑妥当,完全是为了薪资而不是个人兴趣的话,你会很快发现就失去了前行的动力。 无论从事什么岗位,都要不定期的总结和归纳,从而形成自己的知识体系,并扩充自己的软技能。原文地址:http://blog.52sox.com/hadoop-…

commons-httpclient-3.1.jarcommons-io-2.4.jarcommons-lang-2.6.jarcommons-logging-1.1.3.jarcommons-net-3.1.jarguava-11.0.2.jarhadoop-common-2.6.2.jarhadoop-auth-2.6.2.jarslf4j-api-1.7.5.jarhadoop-hdfs-2.6.2.jarcommons-cli-1.2.jarprotobuf-java-2.5.0.jarhtrace-core-3.0.4.jar在pom.xml中添加这些commons-httpclient-3.1.jarcommons-io-2.4.jarcommons-lang-2.6.jarcommons-logging-1.1.3.jarcommons-net-3.1.jarguava-11.0.2.jarhadoop-common-2.6.2.jarhadoop-auth-2.6.2.jarslf4j-api-1.7.5.jarhadoop-hdfs-2.6.2.jarcommons-cli-1.2.jarprotobuf-java-2.5.0.jarhtrace-core-3.0.4.jar 以下为示例代码： /** * @Autohor: liyj * @Description: * @Date:Created in 2017/11/7 * @Modified by : */import org.apache.hadoop.conf.Configuration;import org.apache.hadoop.fs.FileStatus;import org.apache.hadoop.fs.FileSystem;import org.apache.hadoop.fs.Path;import java.io.IOException;import java.net.URI;import java.net.URISyntaxException;public class HdfsFileReader { private static final String NAME_NODE = “hdfs://tj02:8020”;//nameNomeHost = localhost if you use hadoop in local mode public static void main(String[] args) throws URISyntaxException, IOException {// String fileInHdfs = “/user/hive/warehouse/t001011003”; Configuration configuration = new Configuration();// configuration.set(“fs.hdfs.impl”,// org.apache.hadoop.hdfs.DistributedFileSystem.class.getName()// );// configuration.set(“fs.file.impl”,// org.apache.hadoop.fs.LocalFileSystem.class.getName()// ); FileSystem fs = FileSystem.get(URI.create(NAME_NODE), configuration);//// fs.createNewFile(new Path("/user/hive/warehouse/t001011003/0000sadasd"));// String fileContent = IOUtils.toString(fs.open(new Path(fileInHdfs)), “UTF-8”);// System.out.println(“File content - " + fileContent);// copyFile2Hdfs(); Path listf = new Path("/user/hive/warehouse/t001011003”); FileStatus stats[] = fs.listStatus(listf); for (int i = 0; i < stats.length; ++i) { System.out.println(stats[i].getPath().toString()); } fs.close(); } public static void copyFile2Hdfs() throws IOException { Configuration conf = new Configuration(); FileSystem hdfs = FileSystem.get(conf); //本地文件// Path src =new Path(“D:\HebutWinOS”); //HDFS为止 Path dst = new Path("/");// hdfs.copyFromLocalFile(src, dst); System.out.println(“Upload to” + conf.get(“fs.default.name”)); FileStatus files[] = hdfs.listStatus(dst); for (FileStatus file : files) { System.out.println(file.getPath()); } }} ...

1、执行hive，进入hive窗口2、执行show databases,查看所有的database;3、执行use origin_ennenergy_onecard; 则使用origin_ennenergy_onecard数据库4、执行show create table M_BD_T_GAS_ORDER_INFO_H;则可以查看table在hdfs上的存储路径如下：hive (origin_ennenergy_onecard)> show create table M_BD_T_GAS_ORDER_INFO_H;OKCREATE TABLE M_BD_T_GAS_ORDER_INFO_H(fguid string,fstationno string,fstationname string,fgunno int,fserialno int,fgas double,fprice double,fmoney double,fsumgas double,ftradedatetime date,fstopdatetime date,fsavedatetime date,ffueltype string,recorddate date)ROW FORMAT DELIMITEDFIELDS TERMINATED BY ‘\t’STORED AS INPUTFORMAT’org.apache.hadoop.mapred.TextInputFormat’OUTPUTFORMAT’org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat’LOCATION’hdfs://mycluster/user/hive/warehouse/origin_ennenergy_onecard.db/m_bd_t_gas_order_info_h’ —–标红部分为hdfs的路径TBLPROPERTIES (‘COLUMN_STATS_ACCURATE’=‘true’,’numFiles’=‘6’,’numRows’=‘3546198’,‘rawDataSize’=‘435279808’,’totalSize’=‘438826006’,’transient_lastDdlTime’=‘1468831756’)Time taken: 0.279 seconds, Fetched: 30 row(s)备注：hive其他命令：show functions —–>查看所有的hive函数desc tablesname ——>查看table的表结构感谢 “sborgite"提醒！