一、HA
1.HA可以避免NN之间切换带来的数据丢失
2.协同概念：举例---由一个节点（journalnode)监听几个节点的文件创建情况，当一个节点创建了一个文件，则上传至监听服务器，监听服务器通知其他机器，更新同步创建该文件入口
3.HA中的JN（至少3台），监听active NN的edits，不监听fsimage。jn可以单独部署3台服务器或者放在DN上，不能放在master上。Active NN和Standby NN通过JN共享状态，JN用于二者同步数据。
1）DN上传给NN的心跳信息：DN和Block id的对应关系；是否活着；磁盘使用状况；已用和可用的资源信息；
2）为什么底下的DN会同时向active NN和standby NN发送心跳信息呢？是为了在启动时上报完全一样的fsimage信息，即为了保证二者（active nn和staudby nn)的fsimage以及其他信息一致，避免出现数据丢失；
注：NN部署多少台：取决于机房归谁管，自己管，可以只部署2台；如果是别人管，只要保证有1台或者即可；
active nn 和standby nn 如何切换？取决与ZK，分布式锁是ZK的其中一个作用。
当集群建好后，还不能直接使用start-all.sh来启动。
4.ZK：分布式锁，一定是奇数台（内部投票机制）
1）第一次启动集群时，所有的NN都是standby，需要手动切换其中一台为active，ZK会将分布式锁交给这个NN，如果该NN挂了，则ZK通知其他NN竞争该锁(拿到ZK给的写权限)，得到该所的NN自动切换会active
2）脑裂：2.5版本前可能出现脑裂问题，2.5后官方已解决。（如果之后的版本依旧有问题，可能是环境配置出错）
ZK监听不到active NN的心跳信息，就把standby NN设置为active，假设出现原active NN活了，此时就存在两个active，这个问题就是脑裂（因为此时JN不知道监听谁，便放弃监听，不知道哪个是active nn；同时也导致查不到信息）
3）不是所有的ZK都是低配，当使用kafka时，可能需要用到高配。
注：当ZK出现故障，同时NN也挂掉，则可能无法工作（投票机制可能导致无法选出新active NN）
5.Federation（联邦方式）：搭建后，会有多个active NN对外提供服务，可分管不同的目录文件
应用场景：单个NN无法抗住并发访问需求；机房在不同的地方，需要进行合并；
6.服务器高低配情况处理：高配做计算，低配做存储；二、MapReduce
1.设计理念：分布式计算；移动计算，而不是移动数据（将代码复制成多份，在各个block所在地上执行）；
2.MR运行流程
1）Input(<text> input format)
2）splitting（按块切分）
3）RecordReader（块转化为键值对，key是偏移量，value是偏移量下的一整行数据）
4）Mapping
A.当Map输出小于100M，直接放内存；大于走partition sort and spill to disk，默认partition是按hash来partition的；
B.Map算出来先放在本地，中间结果如果放HDFS是不删的；
C.具有本地优势，数据在哪里，就在哪里执行；
5）shuffling
6）Reducing
A.程序入口需要键值对
B.选择资源较宽裕的机器执行
7）Final result
3.MR开发
1）所有在大数据领域，只要数据来源于HDFS，默认情况，直接写/就是hdfs路径，如果是本地则要以file:///开头，第三个斜杠才是本地路径的根路径；
2）开发中结果目录，默认是不存在的，如果存在会报错；
3）开发时setNumReduceTasks可以设置为0，结果没有reduce
HIVE执行时，没有聚合操作时，只有MAP，没有reduce
4.问题点
1）写入文件时，如果HDFS的副本数是8个，写入后只有3个副本，3周后（时间可改）会再补足那8个；如果是从8个降为3个，HDFS不会自动删除，需要运维人员手工删除；写入文件时，如果HDFS的副本数是8个，写入后只有3个副本，3周后（时间可改）会再补足那8个；如果是从8个降为3个，HDFS不会自动删除，需要运维人员手工删除；
2）数据倾斜：服务器与服务器之间的存储相差比不超过20%（可自主设定，但建议20%）
危害-磁盘容易损坏；负载不均衡；如果存储数据多的磁盘损坏，损失较严重；
发生原因-Map时，会做partition，partition可能导致大量的数据在一个reduce，导致这些数据最后放在一个节点，则可能导致倾斜（如果这种情况发生比较频繁，需要根据数据重写partition策略）
处理办法-执行命令sbin/start-balancer.sh（在不影响对外服务服务的情况下做数据迁移，带宽限制在内网的100K/S；会随机选几台服务器进行比对，20%以内就不做balance；），
重写SORT策略场景-当需要按自然数排序时（默认是按字典顺序排序，1,11,12,2,21,22,3...）
问题:服务器中只有两台发生倾斜，需要在短时间内解决数据倾斜问题
解决办法：方法一：1）将其他节点从集群中踢掉；2）更改带宽；
方法二：人工迁，但步骤不能错，错了数据可能就找不回来了
3）默认Map启动20%时，Reduce启动；Map启动80%时，Reduce开始做事（Reduce在20%-80%之间不做事）；
mapred-site.xml中有个参数，有一个key值，为1表示MAP运行到100%时再启动reduce，建议设置为1
问题：1T数据，启动10个Map后，必须进入Reduce
解决办法：方法一-改Block大小（1T/10），比较麻烦
方法二-splitting中会根据partition来拆分，默认一个partition是一个block，可以改变partition的大小
4）磁盘陈列：DN上建议不做，做了读写速度很低。（NN可以做）
5）磁盘损坏：硬件支持热插拔、损坏的不是操作系统————磁盘可以直接拔掉，插则需要设置（挂盘，然后把HDFS相关文件目录做到这块磁盘）
6）任务提交执行需具备的条件：CPU、内存（最重要，最小资源数，有算法公式-某任务需要多少资源）、数据。当数据所在节点都没有CPU，内存资源时，会将这些数据拷贝到别的有资源的节点运行，此事发生数据拷贝。
7）虚拟化（大数据领域）：一般指CPU和内存虚拟化，只有CPU能造假。
内存造假（不可行）：硬件上限制，内存可虚拟为2.5倍，但是根据DN启动的一些限制（DAY1），一般会禁用交换空间。则内存如果虚拟，则大量任务会挂掉。
CPU造假：时钟频率一到，要做切换。一个物理核对应过来，可虚拟为2个，根据CPU能力，可虚拟为4个。
8）MR输出压缩要注意的事项：本身是否支持切割（如果能切割，直接存在某节点，1个BLOCK；可切割，存放方式与HDFS文件类同）；压缩比如何；三、YARN
1.作业执行（YARN）
1）Hadoop 1.0：JobTracker & TaskTracker
一代一个TaskTracker，只能运行2个MAP,2个Reduce
缺陷：JobTracker负载较高
2）Hadoop 2.0改进：Resource Manager & Node Manager
注意：DistributedCache的操作一定要放在job的初始化之前，否则会报出文件找不到的异常
2.Job调度管理：调度器算法；管理多少资源；调度器谁可用；任务等级；
1）算法：FIFO先进先出调度器；Fair公平调度器；Capacity容量调度器；
补充：搜索引擎算法（索引比原文大很多，Solr&ES）四、架构：
1.数据传输：爬虫/Flume/Kafka==>Storm
Sparking streaming==>SQL/AI==>Web==>存储
flink(蘑菇街在用，雷声大雨点小，性能不敢恭维）
2.存储：HDFS，本地（次之），关系DB（最差，优点在于 OLTP），Hive，HBase，Kudu，ES/Solr，Redis，MPP DB，Kafka，Cassandra，Impala，Presto（FB开发的，国内京东在使用）...
注：ES,Solr,MMP要部署在不同的集群，这三类都需要资源，资源抢占会造成一个DN挂掉，所有Server都会挂掉。
HBase和Spark也建议不要搭在一块，资源抢占严重
如果框架需要内存，则不要部署在同一个集群内。书籍推荐
1.Hadoop权威指南：大数据的存储与分析（第四版）-----只能了解各大概，入门级教材
2.Hadoop技术内幕——深入解析YARN架构设计与实现原理（董西成），可以去官网找英文论文（只是翻译过来了）
3.Hadoop技术内幕——深入解析MR架构设计与实现原理（董西成）——用到时再买
4.Hive编程指南——看完再看官网的
5.HBase权威指南——替换kudu，kudu上官网看
6.深入理解Java虚拟机：JVM高级特性与最佳实践（周志明）——能找到1.8最好
7.深入理解JVM&G1 GC——建议只看G1，不用买，只有几十页值得看
8.图解Spark：核心技术与案例实践
9.Scala编程（第3版，下面是风景的）——七百多页，看书方法：如果要长时间能记录80%内容，要求一周内看完。
10.深入理解Scala——高阶的，有兴趣了再看
11.机器学击败AlphaGo的武林秘籍——理论，除了神经网络
12.深度学习 人工智能算法——理论，神经网络
13.机器学习实战（哈林顿，基于Python）——实践
看视频的方法：看完视频，回顾一遍，记得住的就学到了，记不住的再看一遍。（或者讲给别人听）
