当前位置:   article > 正文

Hadoop 学习总结_hadoop的环境搭建及编程实践总结

hadoop的环境搭建及编程实践总结

Hadoop 关于

大数据概念

  • 不能使用一台机器进行处理数据
  • 大数据的核心是样本=总体

大数据特性

  • 大量性(volume): 一般在大数据里,单个文件的级别至少为几十,几百GB以上
  • 快速性(velocity): 反映在数据的快速产生及数据变更的频率上
  • 多样性(variety): 泛指数据类型及其来源的多样化,进一步可以把数据结构归纳为结构化(structured),半结构化(semi-structured),和非结构化(unstructured)
  • 易变性: 伴随数据快速性的特征,数据流还呈现一种波动的特征。不稳定的数据流会随着日,季节,特定事件的触发出现周期性峰值
  • 准确性: 又称为数据保证(data assurance)。不同方式,渠道收集到的数据在质量上会有很大差异。数据分析和输出结果的错误程度和可信度在很大程度上取决于收集到的数据质量的高低
  • 复杂性: 体现在数据的管理和操作上。如何抽取,转换,加载,连接,关联以把握数据内蕴的有用信息已经变得越来越有挑战性

关键技术

  1. 数据分布在多台机器上

    • 可靠性:每个数据块都复制到多个节点
    • 性能:多个节点同时处理数据
  2. 计算随数据走

    • 网络IO速度 << 本地磁盘 IO 速度,大数据系统会尽量地将任务分配到离数据最近的机器上运行(程序运行时,将程序及其依赖包都复制到数据所在的机器运行)
    • 代码向数据迁移,避免大规模数据时,造成大量数据迁移的情况,尽量让一段数据的计算发生在同一台机器上
  3. 串行 IO 取代随机 IO

    传输时间 << 寻道时间,一般数据写入后不在修改

Hadoop 简介

概念

Hadoop 可运行与一般的商用机器上,具有高容错,高可靠性,高扩展等特点

特别适合写一次,读多次的场景

适用场景

  • 大规模数据
  • 流式数据(写一次,读多次)
  • 商用硬件(一般硬件)

不适用场景

  • 低延时的数据访问
  • 大量的小文件
  • 频繁修改文件(基本就是写1次)

Hadoop 架构

img

  • HDFS:分布式文件存储
  • YARN:分布式资源管理
  • MapReduce:分布式计算
  • Others:利用YARN的资源管理功能实现其他的数据处理方式

内部各个节点基本都是采用 Master-Worker 架构

Hadoop HDFS

Hadoop Distributed File System,分布式文件系统

HDFS 架构

hdfs-architecture

  • Block 数据块

    1. 基本存储单位,一般大小为 128M,配置大的块主要因为:
      • 减少搜索时间,一般硬盘传输速率比寻道时间要快,大的块可以减少寻道时间;
      • 减少管理块的数据开销,每个块都需要在 NameNode 上有对应的记录;
      • 对数据块进行读写,减少建立网络的连接成本。
    2. 一个大文件会被拆分为一个个的块,然后存储于不同的机器上。如果一个文件小于 Block 大小,那么实际占用空间为其文件的大小。
    3. 基本的读写单位,类似磁盘的页,每次都是读写一个块。
    4. 每个块都会被复制到多台机器,默认复制3份。
  • NameNode

    1. 存储文件的 metadata,运行时所有数据都保存到内存,整个HDFS可存储的文件数受限于 NameNode 的内存大小。
    2. 一个Block在 NameNode 中对应一条记录(一般一个Block占用150字节),如果是大量的小文件,会消耗大量内存。同时 map task 的数量使用 splits 来决定的,所以用 MapReduce 处理大量的小文件时,就会产生过多的 map task,线程管理开销将会增加作业时间。处理大量小文件的速度远远小于处理同等大小的大文件的速度。因此 Hadoop 建议存储大文件。
    3. 数据会定时保存到本地磁盘,但不保存 Block 的位置信息,而是由 DataNode 注册时上报和运行时维护(NameNode 中与 DataNode 相关的信息并不保存到 NameNode 的文件系统中,而是 NameNode 每次重启后,动态创建)。
    4. NameNode 失效则整个HDFS都失效了,所以要保证 NameNode 的可用性。
  • Secondary NameNode

    定时与 NameNode 进行同步(定期合并文件系统镜像和编辑日志,然后把合并后的结果传给 NameNode,替换其镜像,并清空编辑日志,类似于 CheckPoint 机制),但 NameNode 失效后仍需要手工将其设置成主机。

  • DataNode

    1. 保存具体的 Block 数据。
    2. 负责数据的读写操作和复制操作。
    3. DataNode 启动时会向 NameNode 报告当前存储的数据块信息,后续也会定时报告修改信息。
    4. DataNode 之间会进行通信,复制数据块,保证数据的冗余性。

HDFS 写文件

img

  1. 客户端将文件写入本地磁盘的文件中

  2. 当临时文件大小达到一个Block大小时,HDFS Client 通知 NameNode,申请写入文件

  3. NameNode 在HDFS的文件系统中创建一个文件,并把该 Block ID 和要写入的 DataNode 的列表返回给客户端

  4. 客户端收到这些消息后,将临时文件写入 DataNodes

    1. 客户端将文件内容写入第一个 DataNode(一般以 4kb 单位进行传输)。
    2. 第一个 DataNode 接收后,将数据写入本地磁盘,同时也传输给第二个 DataNode。
    3. 以此类推到最后一个 DataNode,数据在 DataNode 之间是通过 pipeline 的方式进行复制的。
    4. 后面的 DataNode 接受完数据后,都会发送一个确认给前一个 DataNode,最终第一个 DataNode 返回确认给客户端。
    5. 当客户端接收到整个 Block 的确认后,会向 NameNode 发送一个最终的确认信息。
    6. 如果写入某个 DataNode 失败,数据会继续写入其他的 DataNode。然后 NameNode 会找另一个好的 DataNode 继续复制,以保证冗余性。
    7. 每个Block 都会有一个校验码,并存放到独立的文件中,以便读的时候验证其完整性。
  5. 文件写完后(客户端关闭),NameNode 提交文件(这时文件才可见,如果提交前,NameNode 挂掉,那文件也就丢失了。

    fsync:只保证数据的信息写到 NameNode 上,但并不保证数据已经被写道 DataNode 中)

Rack Aware(机架感知)

  • 通过配置文件制定机架名和DNS的对应关系

  • 假设复制参数是3,在写入文件时,会在本地的机架保存一份数据,然后再另一个机架内保存两份数据(同机架内的传输速度快,从而提高性能)

  • 整个HDFS的集群,最好是负载均衡的,这样才能尽量利用集群的优势

HDFS 读文件

img

  1. 客户端向 NameNode 发送读取请求。
  2. NameNode 返回文件的所有 Block 和这些 Block 所在的 DataNodes(包括复制节点)。
  3. 客户端直接从 DataNode 中读取数据,如果该 DataNode 读取失败(DataNode 失效或校验码不对),则从复制节点中读取(如果读取的数据就在本机,则直接读取,否则通过网络读取)。

HDFS 可靠性

  1. DataNode 可以失效

    DataNode 会定时发送心跳到 NameNode。如果在一段时间内 NameNode 没有收到 DataNode 的心跳信息,则认为其失效。此时 NameNode 就会将该节点的数据(从该节点的复制节点中获取)复制到另外的 DataNode 中。

  2. 数据可以损坏

    无论是写入时还是硬盘本身的问题,只要数据有问题(读取时通过校验码来检测),都可以通过其他的复制节点读取,同时还会再复制一份到健康的节点中。

  3. NameNode 不可靠

HDFS 命令工具

  • fsck:检查文件的完整性
  • start-balancer.sh:重新平衡 HDFS
  • hdfs dfs -copyFromLocal:从本地磁盘复制文件到 HDFS

Hadoop YARN

旧版架构

yarn-old-mapreduce

  • JobTracker:负责资源管理,跟踪资源消耗和可用性,作业生命周期管理(调度作业任务,跟踪进度,为任务提供容错)
  • TaskTracker:加载或关闭任务,定时报告任务状态

架构存在的问题:

  1. JobTracker 是 MapReduce 的集中式处理点,存在单点故障。
  2. JobTracker 完成了太多的任务,造成了过多的资源消耗,当 MapReduce Job 非常多的时候,会造成很大的内存开销。这也是业界普遍总结出来 Hadoop 的 MapReduce 只能支持 4000 节点主机的上限。
  3. 在 TaskTracker 端,以 map/reduce task 的数目作为资源的表示过于简单,没有考虑到 cpu/内存 的占用情况。如果两个大内存消耗的 task 被调度到一块,很容易出现 OOM。
  4. 在 TaskTracker 端,把资源强制划分为 Map task slot 和 Reduce task slot,如果当系统中只有 Map task 或者只有 Red
声明:本文内容由网友自发贡献,转载请注明出处:【wpsshop】
推荐阅读
相关标签
  

闽ICP备14008679号