Java知识分享网 - 轻松学习从此开始!    

Java知识分享网

Java1234官方群25:java1234官方群17
Java1234官方群25:838462530
        
SpringBoot+SpringSecurity+Vue+ElementPlus权限系统实战课程 震撼发布        

最新Java全栈就业实战课程(免费)

springcloud分布式电商秒杀实战课程

IDEA永久激活

66套java实战课程无套路领取

锋哥开始收Java学员啦!

锋哥开始收Java学员啦!
当前位置: 主页 > Java文档 > 大数据云计算 >

企业大数据基础平台搭建和实用开发代码 PDF 下载


分享到:
时间:2021-08-31 12:56来源:http://www.java1234.com 作者:转载  侵权举报
企业大数据基础平台搭建和实用开发代码 PDF 下载
失效链接处理
企业大数据基础平台搭建和实用开发代码 PDF 下载


本站整理下载:
提取码:ohp9 
 
 
相关截图:
 
主要内容:

2.1 设计目标
HDFS是Hadoop的核心项目,也是现在大数据领域的事实存储标准。它的高容错性设计,使它可以运行在大量的廉价商业硬件之上,那么它的设计会有这么几个假设的前提。
首先,它会首先假设硬件的故障是一个通常现象。也就是说即使每一块磁盘故障的概率非常小,当你的服务器集群有数千台甚至上万台节点的时候,那这(磁盘故障)也是非常司空见惯的事情。所以说如何快速的发现、定位问题,并且快速地做故障恢复。这是它最重要的设计目标。
第二,HDFS适合于大容量数据,流式访问这样的场景。比如说在大数据场景下,动辄就是上百G,甚至上T的文件。因此,相比于低延时而言,它会更加在意批量处理,高吞吐这样的诉求。
第三,它是形成一个理念,就是移动计算的代价小于移动数据的代价。它也是大数据领域的一个普遍的共识。因此Hadoop在推出HDFS存储的时候,也推出了MapReduce计算框架,就是出于这个目的。
还有,存储非常大的文件:这里非常大指的是几百M、G、或者TB级别。实际应用中已有很多集群存储的数据达到PB级别。根据Hadoop官网,Yahoo!的Hadoop集群约有10万颗CPU,运行在4万个机器节点上。更多世界上的Hadoop集群使用情况,参考Hadoop官网.
以及,采用流式的数据访问方式: HDFS基于这样的一个假设:最有效的数据处理模式是一次写入、多次读取数据集经常从数据源生成或者拷贝一次,然后在其上做很多分析工作 
分析工作经常读取其中的大部分数据,即使不是全部。 因此读取整个数据集所需时间比读取第一条记录的延时更重要。
最后,运行于商业硬件上: Hadoop不需要特别贵的、reliable的(可靠的)机器,可运行于普通商用机器(可以从多家供应商采购) ,商用机器不代表低端机器。在集群中(尤其是大的集群),节点失败率是比较高的HDFS的目标是确保集群在节点失败的时候不会让用户感觉到明显的中断。
2.2 系统架构和容错性设计
HFDS是一个典型的Master-Slave架构,那这里NameNode用来存储文件系统的元数据,比如说分块的大小,文件路径等等之类的。那数据是以BLOCK的形式存储在多个DataNode上的,那整体HDFS提供一个client对客户提供一个文件系统的命名空间操作。比如说文件的打开、关闭、重命名、移动等等。
那我们说到HDFS存储文件,就不得不提到它的数据副本机制。比如说这里的PART 0文件,它包括了Block 1和Block 3这么两个Block。同时,它又被设置了replica,副本数等于2。因此,1和3这两Block会被再复制出另外一个1和另外一个3,存储在另外一个DataNode节点上,从而使得这个文件被拆分为两个Block存储且拥有两个副本。那这里面还有核心的问题就是,拆分后的数据会被存储在地方(DataNode),这样一个调度策略问题。那当一个Block所有的副本都存在同一节点(DataBlock)上,这个节点挂掉的时候,数据不就丢失了吗? HFDS是怎么解决这个问题的呢?它引入了机架感知(Rack Awareness)这样一个概念。那这里我们引入了两个机架Rack 1和Rack 2,每台机架上会有三个这样的节点(DataNode)。
2.3 HDFS不适合的应用类型
有些场景不适合使用HDFS来存储数据。下面列举几个:
1) 低延时的数据访问
对延时要求在毫秒级别的应用,不适合采用HDFS。HDFS是为高吞吐数据传输设计的,因此可能牺牲延时HBase更适合低延时的数据访问。
2)大量小文件
文件的元数据(如目录结构,文件block的节点列表,block-node mapping)保存在NameNode的内存中, 整个文件系统的文件数量会受限于NameNode的内存大小。
我们不应该把大量的小文件放在HDFS里边去存储,因为NameNode会在内存里面维护整个的目录树,文件的数量越多,NameNode压力越大,我们应该尽量的去减少NameNode的压力。
经验而言,一个文件/目录/文件块一般占有150字节的元数据内存空间。如果有100万个文件,每个文件占用1个文件块,则需要大约300M的内存。因此十亿级别的文件数量在现有商用机器上难以支持。
3)多方读写,需要任意的文件修改
HDFS采用追加(append-only)的方式写入数据。不支持文件任意offset的修改。不支持多个写入器(writer)。
2.4 HDFS的存储策略
HDFS针对不同类型的数据可以指定不同的策略,我们在HDFS上创建了一个文件夹,我们可以指定这个文件夹的存储策略是hot,还是worm或者是cold,如果说我们要求某一个文件夹下了数据能够快速的被处理,我们也可以把这些数据当成策略指定为SSD。
3. HDFS核心概念
3.1 Blocks
物理磁盘中有块的概念,磁盘的物理Block是磁盘操作最小的单元,读写操作均以Block为最小单元,一般为512 Byte。文件系统在物理Block之上抽象了另一层概念,文件系统Block物理磁盘Block的整数倍。通常为几KB。Hadoop提供的df、fsck这类运维工具都是在文件系统的Block级别上进行操作。
HDFS的Block块比一般单机文件系统大得多,默认为128M。HDFS的文件被拆分成block-sized的chunk,chunk作为独立单元存储。比Block小的文件不会占用整个Block,只会占据实际大小。例如, 如果一个文件大小为1M,则在HDFS中只会占用1M的空间,而不是128M。
HDFS的Block为什么这么大? 
是为了最小化查找(seek)时间,控制定位文件与传输文件所用的时间比例。假设定位到Block所需的时间为10ms,磁盘传输速度为100M/s。如果要将定位到Block所用时间占传输时间的比例控制1%,则Block大小需要约100M。 
但是如果Block设置过大,在MapReduce任务中,Map或者Reduce任务的个数 如果小于集群机器数量,会使得作业运行效率很低。
Block抽象的好处 
block的拆分使得单个文件大小可以大于整个磁盘的容量,构成文件的Block可以分布在整个集群, 理论上,单个文件可以占据集群中所有机器的磁盘。 
Block的抽象也简化了存储系统,对于Block,无需关注其权限,所有者等内容(这些内容都在文件级别上进行控制)。 
Block作为容错和高可用机制中的副本单元,即以Block为单位进行复制。

 

------分隔线----------------------------

锋哥公众号


锋哥微信


关注公众号
【Java资料站】
回复 666
获取 
66套java
从菜鸡到大神
项目实战课程

锋哥推荐