1、hadoop 1.X 数据块块默认64M；2.X 128M （该值可以更改，dfs.block.size 在 hdfs-site.xml中）
2、重点说一下2.X版本和3.X版本，现在2.X用的比较多，2和3的最大区别是在防止文件丢失上：2.X是做冗余存储，为了保证数据不丢失，做了多个备份，默认的存储数应该是3，这个参数可在配置文件中设置replicas。3.X是使用算法对丢失的数据进行恢复，但是不能保证100%的恢复，但是无疑节省了很大的磁盘空间
3、求内存方法： 文件大小/128M * 0.15kb== 需要的内存
4.1、zookeeper在hadoop集群中主要作用就是HA(高可用机制，防单点故障)。举个例子，如果 namenode节点宕机，岂不是整个集群都瘫痪了，有了HA，就可以根据选举算法自动选举出新的namenode。
4.2、一个集群中保证只有一个 active namenode， ZKFailoverController（独立运行进程）可以及时的检测到namenode的状况，当namenode宕机，通过Zookeeper 实现自动的主备选举，切换备用 standby namenode（可能多个等待主namenode宕机，通过共享存储系统（qjournal）同步数据替代主namenode，确认完全同步后)
4.3、zookeeper集群的节点个数一定要是单数，方便选举，当然可以把不选举的设为observer
5.1、SecondaryNameNode是一个检查节点，（作用1是镜像备份，2是（日志与镜像定期合并）定时从namenode中获取edit.logs更新合并fsimage），减少重启时间！！！ 为namenode分担压力，不能和namenode在一个节点下(在一起还怎么分担压力，只会增加压力)。checkpoint fs.checkpoint.period默认一小时记录一次， fs.checkpoint.size 一次记录多大 默认128M（2.7.4版本） （core-site.xml中）*****SecondaryNameNode切记它不是第二个namenode的意思
5.2、fsimage（镜像） – 它是在NameNode启动时对整个文件系统的快照， edit logs（日志） – 它是在NameNode启动后，对文件系统的改动序列，在NameNode重启时，edit logs才会合并到fsimage文件中，从而得到一个文件系统的最新快照。当namenode宕机重启时，fsimage会加载到内存中。seen_txid 下一次日志开始的事务编号。内存元数据 metadata ==fsimage+edits_inprogress_xxx
6、namenode 负责管理整个文件系统的元数据，并且负责响应客户端的请求；datanode 负责管理用户的文件数据块，并且通过心跳机制汇报给 namenode，文件会按照固定的大小(dfs.blocksize)切成若干块后分布式存储在若干台 datanode 上；datanode 会定期向 namenode 汇报自身所保存的文件 block 信息，而 namenode 则会负责 保持文件的副本数量；datanode之间有相互通信
7、hadoopfs -copyFromLocal weblog_entries.txt /data/weblogs 导入数据
8、启动HDFS集群： sbin/start-dfs.sh 启动YARN集群(需要在yarn的主节点启动)： sbin/start-yarn.sh 单个守护进程启动 hadoop-daemon.sh start namenode/datanode yarn-daemon.sh start resourcemanager/nodemanager hdfs dfsadmin -report 查看dfs集群的工作状态
9、YARN：（一主多从架构）
主节点：resourcemanager 从节点: nodemanager
两次检查时长一次5分钟（线程服务），10次心跳机制（heartbeat）时长30秒，一共10分半，检查宕机 namenode->datanode
Yarn的资源调度器支持三种FIFO Scheduler ,FAIR Scheduler ,Capacity Scheduler（后两种多队列，具体细节直接百度搜就行，解释挺详细）
Yarn支持三种调度方式：FIFO（时间、字符串）、FAIR（按内存大小）和DRF(mesos算法)分别是指先来先服务、公平调度和主资源公平调度
yarn解决了扩展性差，单点故障以及只能局限于MR计算框架等的问题。
两次检查时长一次5分钟（线程服务），10次心跳机制（heartbeat）时长30秒，一共10分半，检查宕机 namenode->datanode
10、MapReduce：一个数据块就会启动一个mapTask, FileInputFormat.getSplits();数量默认由此决定 List splits = getSplits(JobContext context) ， CombineFileInputFormat就是用来解决计算大量小文件造成的 任务计算效率过低的问题，可以包含多个不不同文件的数据块
11、JVM：这一块我就做个简单的基础介绍，首先JVM现在主要研究堆内存，分年轻带（copy算法）、老年代（标记整理算法），年轻带包括Eden区、s1、s2区（年轻带默认Eden区是占80%，s1,s2各占10%，并且s1,s2只会使用其中一个，所以正常来讲年轻带只会使用90%。这个比例是可配置的）。工作流程：当一个对象进入后，先进到年轻带(如果是特别大的对象，会直接进入老年代)，当每遇到一次GC的时候，没被回收掉的对象，年龄就会+1，当年龄达到15的时候就会进入老年代（默认是15好像，我也记不太清了）。JVM优化主要配置一些参数-Xms等等，这个可以搜一下很多。
12、HDFS上传（写）：客户端向namenode发出RPC请求；namenode检查要创建的文件是否存在和是否有权限处理，如果成功，则创建一个记录；客户端将文件切成多个packets，一”data queue（数据队列）”的形式管理，并向namenode申请blocks，获取存储repilicas的datanode列表；客户端以管道流的形式将packets写入datanode；成功存储后datanode会返回一个ack packet（确认队列）客户端从”data queue”中移除相应的packet；如果传输过程中出现了故障，则当前管道会被关闭，继续向下传输，同时namenode会分配一个新的datanode，来保证replicas的设定数量；完成后，close()关闭流；
13、HDFS下载（读）：客户端向namenode发出RPC请求；namenode返回文件block列表和地址给客户端；客户端会选取最近的datanode来读取block；如果客户端本身就是datanode就直接从本地获取数据；当前的datanode读取完成后，关闭当前的链接，继续寻找下一个最佳的datanode；如果读取失败，客户端会通知namenode，然后在从下一个拥有该block拷贝的datanode继续读；
14、MapReduce——shuff阶段流程(数据混洗)：收集map（）方法的kv对，放到环形内存缓冲区中；内存缓冲区数据不断溢出，可能在磁盘中形成多个文件，多个溢出文件会被合并成大的文件；在溢出和合并的过程中，会调用partitioner进行分区和key进行排序；（在数据量大的时候可以对maptask进行压缩，增加传输reducer效率，可能占用cpu）reduceTask根据自己的分区号，去各个mapTask机器上取相应分区的数据；reduceTask会取到同一个分区来自不同mapTask的结果文件，reduceTask会将这些结果文件进行合并（归并排序）；shuffle阶段完事，调用reduce（）执行逻辑——缓冲区默认大小100M，在io.sort.mb
15、YARN执行流程(资源调度系统)：用户向yarn中提交应用程序，ResourceManager为该程序分配一个Container（一个限定大小的区域），并与nodemanager通讯，在Container中启动程序；ApplicationMaster首先向ResourceManager注册，用户可以直接通过ResourceManager查看应用程序状态，为各任务申请资源，监控运行状态，直到结束；ApplicationMaster轮询方式通过RPC协议向ResourceManager申请和领取资源；ApplicationMaster取到资源后会要求nodemanager启动任务；nodemanager设置好运行环境后，将任务启动命令写到脚本中并启动该脚本；各任务通过RPC协议向ApplicationMaster汇报状态、进度，如果失败可以重启任务；完成后AM向RM注销并关闭；
