Hadoop：MapReduce 计算框架

写的不到位的地方，欢迎评论指出不足之处

• HDSF：存储文件
  • 存储模型
    • 切块、散列
      • 分治目的
        • 分布式计算
  • 实现
    • 框架
      • 角色 NameNode、DataNode
  • 特长/特点
    • 读写流程很重要
• MapReduce：批量计算
  •  计算模型
    • 两阶段：Map 与 Reduce 是一种阻塞关系
      • Map
        • 单条记录加工和处理
      • Reduce
        • 按组、多条记录加工和处理
  • 实现 ：框架
    • 计算向数据移动
      • hdfs 暴露数据的位置
        • 资源管理
        • 任务调试
    • 角色
      • JobTracker （主）
        • 资源管理
        • 任务调试
      • TaskTracker（主）
        • 任务管理
        • 资源汇报
    • 逻辑
      • Client
        • 根据每次的计算数据，咨询 NameNode 元数据 （block）
          • 算：split 得到一个切片的清单
            • map 的数量就有了
            • split 逻辑、block 物理、block 身上有（offset、locations）、split 和 block 是有映射关系
              • split 包含偏移量，以及 split 对应的 map 任务应该移动到哪些节点（locations）
              • 例：split01  A文件   起始0b   结束500b     n1  n3  n5（块的位置）
          • 可以支持计算程序向数据移动
        • 生成计算程序未来运行时的相关配置的文件
        • 未来的移动应该相对可靠
          • Client 会将：jar、split 清单、配置 xml、 上传到 hdfs 的目录中（上传的数据副本数为10）
        • Client 会调用 JobTracker，通知要启动一个计算程序了，并且告知文件都放在了 hdfs 的哪些地方
      • JobTracker
        • 从 hdfs 中取回：split 清单
        • 根据取到的 TaskTracker 汇报的资源，最终确定每一个 split 对应的 map 应该去到哪一个节点：确定清单
        • 未来，TaskTracker 再心跳交互时会取回分配给自己的任务信息
      • TaskTracker
        • 心跳互动时取回任务后
        • 从 hdfs 中下载相关文件 jar、xml...等到本地
        • 最终启动任务描述中的 MapTask / ReduceTask
          • 最终代码在某一个节点被启动
            • 是通过：Client上传、TaskTracker下载：计算向数据移动实现
• 问题
  • JobTracker 三个问题
    • 单点故障
    • 压力过大
    • 集成了【资源管理和任务调度】，两者耦合
      • 弊端：未来新的计算框架不能利用资源管理
        • 重复造轮子
        • 因各自实现资源管理，但部署在同一批硬件上，因为隔离，不能感知对方的情况
          • 资源争抢
• 思路
  • 计算要向数据移动
  • 哪些节点可以去呢（需要有整体资源的把控）
  • 确定了节点后对方怎么知道呢（任务调度），还有比如有一个失败了，应该重新在哪个节点重试

  • 来个 JobTracker 搞定这2件事，但问题也随之暴露