构建Hadoop集群（内含impersonation） —— Hadoop权威指南15

• 《Hadoop权威指南》的10章和11章，基本都是讲集群的搭建、配置、目录结构等细节
• 知识比较凌乱，在此将自己觉得重要的知识记录一下

1. 为何不使用RAID？

• NameNode需要永久性储存文件元数据，可以使用RAID（磁盘阵列）做存储器
• 但是DataNode不建议使用RAID做存储器，主要原因有三个：
  • 原因一： HDFS的多副本已经能满足冗余需求，无需再使用RAID
  • 原因二： Hadoop的JBOD（just bound of disk）技术，通过实验表明会比RAID的读写更快。因为，JBOD再所有磁盘间循环调度数据块，取决于磁盘的平均读写速度。然而，RAID却取决于读写速度最慢的磁盘。
  • 原因三： JBOD的某一磁盘故障，HDFS可以忽略该故障，而RAID中某一磁盘故障则整体瘫痪

2. Hadoop集群配置

• 在etc/hadoop目录下，存在很多的配置文件和bash脚本
• 其中map-env.sh和yarn-env.sh可以覆盖hadoop-env.sh中对MR或yarn的配置
• 具体的xml配置，可以查看官网的configuration主题

3. Hadoop的两类日志

• .log结尾的日志： Hadoop使用log4j进行日志打印，大部分应用程序的日志信息都存放于此

  • 日志采用日常滚动追加的方式写入，系不会自动删除过期的.log文件，需要用户手动删除或存档

• .out日志文件： 标准输出和标准错误日志存放于此

  • 系统只保留5个最新的日志文件，使用1~5的数字作为后缀，以标记.out文件的新旧。
  • 数字1表示最新，数字5表示最旧

• 日志文件的命名方式：hadoop-守护进程名-ip.log.日期，具体需要查看集群中的真实文件去验证

4. 守护进程的RPC和HTTP端口

• RPC端口，用于守护进程间相互通信
• HTTP端口，用于提供守护进程与用户交互的web页面
• 端口号，一方面决定了守护进程绑定的网络接口；另一方面决定了用户或其他守护进程与之交互的网络接口。

5. 垃圾回收

• Hadoop文件系统也支持垃圾回收，对应的属性为fs.trash.interval
• 默认值为0，表示不开启垃圾回收机制
• 垃圾回收是用户级特性，只有通过shell命令删除文件，才能被回收
• 如果通过编写应用程序，实现文件删除，则无法被回收
• 例外： 通过moveToTrash()方法将指定文件放入垃圾回收站，成功返回true；垃圾回收特性未开启，或文件已经在垃圾回收站中，返回false
• 题外话： 运维清理过期数据，输入rm -rf命令立马enter后，发现命令使用错误，用户的最新数据没了。然后从故障复盘文档中，发现运维又通过垃圾回收恢复了文件。
• 因此，自己也才对垃圾回收特性有所关注的 😂

6. 慢启动

• 一个普通的MR作业，包含map任务和reduce任务，map任务在reduce任务之前。
• 等所有的map任务都运行完成，再调度reduce任务？或者，一开始就让为map和reduce任务都调度？
• 为了不让reduce任务存在浪费容器不做事的情况，默认当map任务完成5%后，才调度reduce任务
• 实际使用时，为了提高集群额吞吐率，可以提高到80%

7. 短回路本地读

• 如果客户端和所要读取的block在同一节点，则可以不通过TCP进行读
• 绕过网络，直接进行磁盘读，可以让诸如HBase这样的应用程序执行效率更高

8. Hadoop的验证机制

• 为了避免Hadoop文件系统的数据，被伪装的恶意用户删除，需要进行安全认证
• 雅虎工程师，基于kerberos（一种成熟的开源网络认证协议）实现了基于kerberos的安全认证
• kerberos认证只负责鉴定登陆账号是否为声称的用户，而用户的访问权限则是由Hadoop自己负责管理
• kerberos的认证过程
  • 用户向认证服务器发送一条请求报文，认证服务器返回一个带时间戳的票据授予票据（TGT）
  • 用户使用TGT向票据授予服务器（TGS）请求一个服务票据
  • 用户向真实的服务器出示服务票据，以证实自己的合法性。
  • 注意： TGT具有一定的有效期，无需每次访问服务器都需要进行kerberos认证
    
• 工作中，自己还了解到hive的impersonation验证机制
  • 例如，查询Hive的用户为A，但是访问时，一般默认使用hive用户 （这是菜鸟的一个比方，可能并不正确 😂）
  • 最终，Hive查询会访问HDFS中数据，那如果使用hive用户去访问，hive用户的权限比用户A大的话，会导致权限放大的问题
  • 最好的办法：hive用户访问HDFS时，还带有用户A的信息。
  • 这样真实访问时，底层鉴权将基于用户A，而非统一的hive用户
  • 这个在Hadoop中叫proxy User技术，hive用户被称为superuser（并非权限上的那个superuser 😂），用户A被称为proxy user
  • 这样，Hadoop集群可以维护少量的superuser认证信息，而无需为每一个新的proxy user添加认证信息
  • 具体过程如下：
    

总结

Hadoop的两类日志文件

1. .log结尾的文件，是log4j打印的日志，系统不会自动删除，需要用户手动删除或存档
2. .out结尾的文件，是标准输出和标准错误输出；系统只保留5个日志文件，带有序号1~5，5表示最旧

两类端口

1. RPC端口，守护进程间的通信
2. HTTP端口，提供用户与守护进程交互的web界面

HDFS的垃圾回收

1. 只有通过shell命令删除的文件，才能进行垃圾回收
2. 通过用户程序删除文件，无法被垃圾回收，但可以通过moveToTrash()可以将指定文件放入垃圾桶

Hadoop的验证机制

1. 基于kerberos的验证机制：只负责验证用户的合法性，不负责管理用户权限
2. Hive的proxy user / impersonation机制：superuser拿到访问的门票，带着proxy user进入hive游乐园；proxy user能体验何种hive操作，需要刷自己的脸（基于自身鉴权）