Please enable JavaScript.

Coggle requires JavaScript to display documents.

hadoop 1.0 中的(HDFS) (1.初探 (优缺点 (缺点 (低延时高吞吐率的问题 (延迟与高吞吐的问题 (比如你去商店买完东西…

- - - - 数据的存放形式
        
        HDFS 数据存储单元(block)
        
        单元固定内存大小
        
        1.0 默认64M
        2.0 默认128M
        
        超出一块的大小,另存一个块,哪怕它很小
        
        比方: 买个10斤肉,正常人都会切成块,在烧着吃(量还是那么多,变得只是思维方式)
        
        单个文件的存储方式
        
        若干块,存放在不同的节点
        
        默认三个副本(自己本身以及复制的2份)
        
        bloc大小固定不变,副本书可变(应对访问量大了,节点坏了临时添加等)
      - NameNode(简称NN)
        
        1. 保存metadata信息
        
        metadata信息详情
        
        文件包含块
        
        Block保存在哪个DataNode信息
        
        文件owership(归属) 和 permissions(权限)
        
        功能: 接收读写操作(其实就是数据的源头)
        
        2. 启动后加载到内存(好比登陆qq将进程存入后台)
        
        Block的位置信息保存到fsimage(同时将保存block信息一并存入)
        
        (文件的操作)edits记录对metadata的操作日志
        
        (数据)metadata存储到磁盘名为fsimage
      - SecondaryNameNode(SNN)
        
        合并机制
        
        配置文件的设置的时间间隔默认1小时
        
        edits log文件默认最大值64M
        
        合并流程
        
        3. SNN将edits和fsimage进行合并,合并之后在替换原来的fsimage
        
        4, 每隔一段时间就进行一个合并替换
        
        2.不能影响用户实时的操作,新生成一个edits进行日志记录
        
        1. NN中的fsimage和edits文件通过网络拷贝到NN服务器中
        
        思想:在不影响的用户的操作情况下日志记录,以及进行替换合并
        
        功能
        
        帮助NN合并edits log文件, 减少NN启动时间,它不是备份(但可作为备份,可以理解为:小秘不是小三,可以当小三用一样)
      - DataNode(DN)
        
        存储数据(block)
        
        类似数据结构中的链表节点,存储数据
        
        向NN发现心跳保持联系(3s一次),如果没有收到,就gg了,将其信息copy到其他DN
        
        启动DN线程时, 会向DN发送block信息
      - Block的副本放置策略
        
        第二个副本
        
        放置在与第一个副本不同的机架的节点上
        
        第三个副本
        
        第二个副本相同机架的不同节点
        
        第一个副本
        
        放置在上传文件的DN.若是集群外的提交,随机放入空闲磁盘(节点)中
        
        更多副本: 随机节点
      - HDFS 读写流程
        
        1. 读文件过程
        
        3, 前2步会返回一个FSDataInputStream对象,客户端调用read方法,DFSInputStream会找到最近的datanode
        
        4. 数据会源源不断流入客户端
        
        2. DistributedFileSystem通过rpc协议获得文件的第一批block的locations地址(因为同一个block有多个副本,分布在不同的节点上,会返回多个locations),按照就近原则选择(离客户端最近的排在最前)
        
        5. 读完了第一个的数据,就会关闭datanode连接,接着读取下一块
        
        1. 首先调用FileSystem对象open方法,DistributedFileSystem只是其实例之一(打开源,开闸)
        
        6. 若第一批读完了,就会到NN中拿下一批block locations进行读取,如此循环,直到结束,关闭所有流
        
        中间过程异常处理
        
        如果DFSInputStream和datanode通讯异常,就可以试着读取block最近的完好的datanode,并且记录那个datanode出错,剩余的block读取的时候,也会跳过错误datanode,若发现一个坏的block,则会在其它datanode读block镜像
        
        读过程总结
        
        流的打开open,读取read,close关闭都在client JVM里完成的,两头连着namenode,datanode,从namenode拿到block locations(源头地址),中转战是...JVM,利用read指令对datanode进行读取流到客户端
  - - - 分布性特性
        
        百万规模的文件数量:10k+节点
        
        适合批处理,只需数据位置移动计算即可,而非数据本身
        
        适合大数据的处理(pb级别以上)
      - 自身特性
        
        成本较低,租用廉价的机器
        
        高可靠行:利用多副本保证text
        
        高容错性:数据自动保存多个副本,只要不是全部丢失,提供自动恢复机制恢复
    - - 低延时高吞吐率的问题
        
        无法做到毫秒级别,只支持秒级别
        
        延迟与高吞吐的问题
        
        比如你去商店买完东西,收营员扫码结账这是固定消耗时间一对多(比如延时20s,不可避免的).排队的人比较多,(队列的形式),先付先出,只会照顾到前几个人,后面的人只能等待(延时)处理,大家都着急了,解决的方案来了,多开几个窗口,分布数量,降低延迟,减轻访问压力
      - 小文件存取大量的NameNode 大量内存(寻道时间大于读取时间),上海和一个偏僻的地方,哪个更好找,不言而喻
      - 不支持文件修改(空间换时间)