hadoop
1，数据越来越大，尤其是搜索引擎公司，数据的类别---分为三种，结构型，非结构型，半结构型，对应产生的数据库，关系型数据库，非关系型数据库；数据的来源---自己公司业务，爬虫（网络），购买（第三方交易）；数据的处理---缺失字段，重要补全，不重要删除，隐私字段则脱敏
2，谷歌三篇论文 GFS（google filesystem）、产生了hdfs，解决海量数据存储；MAPREDUCE、产生了mapreduce，解决计算；BIGTABLE，产生了hbase，解决海量数据查询；最初的hadoop没有yarn，就是hdfs和mr，和hbase。
3，大数据的核心概念---集群（横向扩展），分布式（分而治之），负载均衡（性能最优）
4，hadoop的启动---start-hfs.sh start-yarn.sh hadoop-daemon.sh start namenode/secondarynamenode/datenode/resourcemanager/nodemanager ;启动时报错---要么是格式化错误，要么就是权限问题
5，hdfs设计思想有两个，需要注意的也有两点
切块存储（过大过小都会影响性能，其实所做的一切都是为了更快更好的完成存储计算查询）；64-128-256（128M对应的134217728B），设置的参数是hdfs-default.xml中的hdfs.site.xml中的dfs.blocksize参数（所有的参数统属于四类---core-default.xml、hdfs.default.xml、mapred.default.xml、yarn.default.xml）
冗余存储（其实就是防止宕机影响数据的完整进行多备份），设置hdfs.default.xml中的hdfs.site.xml中的dfs.replication参数
需要注意的有两点：副本的存储和数量---存储时要避免相同的副本备份到同一个节点（备份和副本都是复制，其区别在于有无主次，后者没有）；宕机时若副本设置的数量少于现存节点，会重新复制一个副本，恢复宕机后，会在一个小时后检测是否真的恢复宕机进而删除多余的副本，副本数量设置的多余总节点时会进行记账
6，hdfs的架构：主从架构（主管理，从干活）
namenode
---存储元数据（相当于元类，描述原始数据的数据，简明扼要的备注原始数据），hdfs的元数据包含三部分（抽象目录树，描述整个虚拟的所有datenode共同而非单一构成的存储体系，由hdfs：//hadoop01:9000入口）、（块和数据的对应关系，每个块实际是存在某一个datenode中，记录其全局唯一的id，即blockid，记录在mapred.site.xml文件中）、（记录数据块的位置，即将blockid和节点一一对应）
---处理客户端的数据读写请求，只有namenode中有元数据，只有元数据才能知道块-id-节点的对应
secondarynamenode
---备份主节点的元数据，在主节点宕机后进行数据恢复
---减轻主节点压力，处理一些非核心问题
datenode
---负责数据的存储，原始数据存储好后生成一个id，产生一个元数据传给namenode
---执行客户端的数据读写请求，根据namenode给予的命令，存到该存的地方，读取该读的地方
7，hdfs的使用，有shell和api两种
---shell命令：hadoop fs xxxx（类似linux命令）
---api操作：用的很少
8，hdfs的四大机制
---心跳机制：报告namenode自己的存活状况，心跳报告周期dfs.heartbeat.interval，宕机次数dfs.namenode.handler.count
主动检查dfs.namenode.heartbeat.recheck-interval，因此默认时确定宕机需要10*3+300*2=630s
---机架策略：同样的数据不要放在同一个节点，甚至同一个机架，甚至同一个机房，甚至同一个数据中心
---负载均衡：冗余存储的最开始是相对随机存储的，所以会有负载不均的情况，集群有自动调整的功能，dfs.datenode.balance.bandwidthPerSec，但是默认的为1M/s ,过大会影响性能，因此集群规模不大时无所谓，集群规模大时，则需要手动负载均衡，首先是调整带宽，其次是start-balancer.sh -t 10%（意思是datenode中的最大占比与最小占比相差少于10%，但不会立即执行，提升的是响应时效） 没有绝对的负载均衡。
---安全模式：集群的自我保护模式，限制用户对集群进行部分操作（实质就是不予许产生元数据的修改，查询可以）。三种方式进入（集群启动时的顺序name-date-secondaryname，依次启动完后自动进入安全模式，namenode启动时：磁盘中只有元数据的前两部分，内存中含有元数据的所有信息，启动时会将磁盘中的元数据全部加载到内存中；datenode启动时：发送心跳报告，发送块的相应信息，将块放到该放的节点上；secondarynamenode启动时：检查块的副本数，dfs.namenode.replication.min，至少为1，检查标准块的比例，dfs.namenode.safenode.threshold-pct，检查存活的datenode个数，dfs.namenode.safenode.min.datenodes，表示退出安全模式时安全节点的个数，为0表示立刻退出安全模式，大于节点数表示永远处于安全模式，最后一项：三大标准符合30s之后退出安全模式，dfs.namenode.safemode.extension-----总结就是集群启动时进入安全模式的原因，那么namenode将硬盘中的元数据加载打内存，namenode接收datenode传来的心跳报告和块报告，再者就是检查集群）、（集群运行过程中进入安全模式：运行过程中会随时检查每个副本个数是否大于1，以及符合标准的块的比例是否达标，一旦不符则自动进入安全模式）、（集群维护或系统升级时可以手动进入：
）
安全模式时可以进行的操作---ls get tail cat 不可以的---mkdir put touchz rm 总之就是不允许元数据改变（namenode is in safe mode）
9，hdfs上传
10，hdfs下载
11，hdfs元数据合并
12，shuffle的原理
13、yarn的架构：主从架构，resourcemanager nodemanager
---resourcemanager的作用（管理所有的nodemanager、监控其运行状态，掌握其资源、为每一个job分配资源、启动每一个job的老大，也就是MRappmaster，之后由其来调度整个job）
resourcemanager的组成（ASM（applicationsmanager）：管理所有的应用程序、负责所有的job，启动所有的mrappmaster、监控mrappmaster的运行，失败时重启；Scheduler（调度器）：就是负责调度各个job的提交顺序，调度器的分类：FIFO，顺序调度器，first in first out 先入先出 ，缺点是遇到大任务后造成后面的任务等待过长；Fair，公平调度器，n个job ，每个job占用1/n的资源，缺点是资源分配不合理，有的任务量很大资源不够，有的任务量很小资源过剩；Capacity，计算能力调度器，又叫容量调度器，内部维护的是多个FIFO队列，可以手动配置每个队列的资源，）
系统默认的是Capacity，容量调度器，一个job开始时，首先通知ASM，ASM通知调度器，等待系统分配资源。
---nodemanager的作用，以container（逻辑资源容器，虚拟资源容器）为单位提供资源，container是一个虚拟划分的资源，封装了一定的cpu、内存、磁盘、网络、io等，且数量必定为整数；
真正的作用，为job提供资源，向resourcemanager发送心跳报告，接收resourcemanager的命令，接收mrappmaster的命令。
jobclient里面关于maptask初始化的源码可以看到maptask的数量是由inputformat指定的，inputformater生成多少个inputspilt就会产生多少个maptask，若剩余的map slot多余inputspilt就会如数启动，少于则将剩余的全部启动；而split与block的指定就决定了启动多少maptask，默认一对一，这样性能比较高，但是也可以设置成一对多。reduce task 由job中指定，如果不指定则默认启动一个，指定多个则按照hash来进行分区。
sqoop和flume都是信息收集组件
flume是分布式、可靠、高可用的海量日志收集器，进行收集、聚合、传输的系统，收集的是流动型数据，核心组件就是agent，（agent包含三部分，source用来靠近信息源，收集信息进行特定的格式化；channal是缓冲区，用来暂存source传来的event（flume中存在的其实就是一个个的event，是一个特定格式的元素集合，字节数组形式，并且携带有头元素）；sink，是处理缓冲区中的enent，将event序列化，进行持久性的保存，处理完后传入hdfs或者另一个source）其实就是附着在web、access、nginx的一个JVM，最终产生web.log access.log nginx.log
flume的常用部署：单agent；多agent串联；合并串联；多路复用；高可用部署
常用组件：
---source：网络端口；监控文件；监控文件夹
---channal：内存（memory）；jdbc（形成一个临时的数据库，默认的是derby）
---sink：hdfs、kafka
sqoop是采集关系型数据库数据，底层还是mr任务，导入是从数据库导入到大数据平台DBinputformat，自定义数据输入；导出是从大数据平台传到关系型数据库DBoutputformat，自定义数据输出；
---导入：import mysql---->hdfs/hive
--connect
mysql：jdbc：//hdp03:3306/ //指定关系型数据库链接url
--usename //数据库的用户名、密码、需要迁移的表
--password
--table
--m //指定maptask的个数
--terget-dir //hdfs的存储目录
--fields-terminated-by //指定每条记录不同字段之间的分隔符
--where //指定sql的查询条件
--query //指定查询的sql
--columns //指定查询的列，也就是需要导出的列
列举数据库中有哪些数据库，有哪些表，
list-datebases list-tables 
---导出：export hdfs/hive ----> mysql ；导出不同于导入的特点是需要事先建表
首先是创建一个表
create datebase sqoopdb default character set utf8 collete utf8-general-ci；
use sqoopdb；
create table sqoopful（
id int
name varchar（60）
）;
//导出HDFS数据到数据库
sqoop export
--connect jdbc：mysql：//hdp02:3306/sqoopdb \
--usename
--password
--table sqoopdb //事先已经建好的表
--export-dir /hdfs的目录 //指定的是hdfs中的需要导出的文件夹
--filed terminated-by 't' //指定的是hdfs文件中字段的分隔符
------------hive和hdfs与数据库迁移的时候其实是一回事，因为hive是存在hdfs中的一个目录 ---hbase和mysql的迁移
①可以介入hdfs使用mr进行迁移（hbse与hdfs之间的导入可以使用mr也可以使用hbse自带的工具，hbase自带的工具是：org.apache.hadoop.hbase.mapreduce.Export）
②也可以直接连接hbase和mysql，hbase到mysql的数据通道就算打通，问题的关键其实是，如何设计mysql里的行数据，让其转换为hbase中的类数据，因为hbase是列式存储，按照表->行->列簇：列->值的形式来存储。
zookeeper
分布式的集群管家，分布式服务的协调组件，管理集群的配置文件，组件版本，节点动态上线，分布式队列，分布式同步锁等分布式集群中关于数据一致性的各种繁琐问题，可以很条理简单的解决；其功能的实现基于两部分，znode系统（挂载数据，存储数据，但数据不可太大，不能超过1M，最好是1k左右）和watch监听机制（回调 、异步）注册一个个的监听。
特点是对等架构，其实所做的事情核心只有一件，就是保持数据的持久准确性，存入一个数据，只要存进去，那么必须保证它是对的，而且永不丢失。拜占庭问题的解决方案：鸽巢原理 抽屉原理（即W+R>N）（N是总节点个数，R是写入成功节点个数，S是写入失败的节点个数，W是读取数据的节点个数）；为了保证顺序，所有的提案也就是请求都必须有序；client是客户端，发起请求，learner包括follower和observer，前者接收请求并返回结果，且参与投票，后者接收到请求之后转发给leaner节点且不参与投票，只是实时同步learner的状态，作用就是提升系统延展性，提高读取速度；leader，负责投票的发起和决议，更新系统的状态（即写入数据，但读取数据任一节点都可以）
leader的产生采用的是选举制，leader的首要条件就是其节点的数据必须是完整且最新的，新的系统，那么直接根据id来确定，大者直接当leader；参与生产的系统，采用版本和逻辑时钟，最新版本可以参与竞争，逻辑时钟保证投票的准确性，最终获得票数最多的就是新leader
azkaban
就是一个任务调度的组件，保证任务的顺序执行，类似于crontab（但是比crontab更加复杂和功能强大），上传一个压缩文件，然后进行脚本的运行；
安装时时首先是上传脚本文件，配制环境变量，进行密匙认证，检查时区，初始化即可
kafka
NIO:与普通的io作用和功能是一样的，用来进行数据的传输，N的意思即是new，又是 non-blocking，相比普通io，普通io是面向流，nio是面向通道和缓冲区的；io没有选择器，对应的网络编程是serversocket，即服务端和客户端相匹配，服务端会一直开启等待着客户端，因此是网络编程时是阻塞式的，nio有选择器，网络编程时是非阻塞式的；从性能上来看nio比io的性能更好更高。
nio的两道核心就是通道和缓冲区，通道是用来连接数据源和应用程序，（其实是连接缓冲区和数据源，而同道中不可以暂存数据，因此才必须要有缓冲区）缓冲区是用来临时存储数据的，底层是一个数组，不同类型的数组用来存储不同类型的数据，缓冲区的大小实际就是数组的长度（缓冲区的重要属性：capacity 容量 ；limit 限制；position 当前缓冲区的指针位置 mark 标记；缓冲区常用的方法：put get flip（进入读模式） reset（读取标记处）clear）（清空缓冲区） ），获取缓冲区使用allocate
选择器的用处是监控客户端通道的状态，将符合服务端需要的通道过滤出来，给服务端，因此做到非阻塞，高性能
kafka的功能：将生产者和消费者进行解耦，提供信息暂存服务，持久化到磁盘，还可以降低峰值，以前是点对点的队列服务，现在是生产者+服务器+消费者，采用消息或产品发布订阅的形式，异步并行。
kafka由broker组成，他不是主从架构是对等架构，每个broker管理多个partition，每个partition中存在不同topic的不同的segment。partition副本默认是一个，且只能变多不能变少。
由topic组成，每个topic由segment，segment是topic切割而成，topic1G切分一次，segment由log和index文件组成。最小的单位是message，也就是segment由message组成，message包含key+value+时间戳。
消费者组是逻辑概念，并没有实际分组切分，可以包含一到多个消费者，一个消费者组共同消费一整个topic的所有分区一次，也就是一个消费者可以消费整数倍的分区，消费的时候宏观上并行，微观上串行，广播则需要所有的消费者处于不同的消费者组，单播则要所有的消费者处于同一个消费者组
使用经验：topic的分区数最好大于等于broker的数量，消费者组中消费者组的个数最好等于topic的分区数，这样每个broker都会进行服务，读写和存储效率都会比较高，
生产者push消息到kafka，消费者从kafka中pull消息。读取消息的时候根据偏移量读取，每个偏移量都是一个有序的序列，不超过8个字节，保证一次读取完成，低阶API自己保存偏移量，高阶API不需要自己保存偏移量，
Hbase
分布式数据库，存储能力无上限（分布的核心技术就是分库分表，读写隔离），存储非关系型数据，并且可以做到实时增删改查（单机型限制了其性能，无法实时，同时Hbase中还应用了许多）它的结构可以看做一个四维表，存入数据时不会进行检查，底层均是字节数组，查询显示时会检测；维度表实质就是进制，可以解决一些数量问题（测出8只8种药水需要3只小鼠。）整个表在rowkey方向划分为region，region根据cf划分为store（store实质就是一个二维表）；几维表即是几个key确定一个value）（与进制的思想是一样的），所有的数据库，无论关系型还是非关系型都是key-value（map：key=object（id）；mysql：key=object（id，column）；hbase：key=object（id cf column ts）），根据算法（一般是hash算法）进行分区，这样分区多少就可以将查询效率提升多少（查询时先进型算法，找到对应的分区）
region中存在缓冲区--memstore，产生很多小文件，因此写入数据是异步的，缓冲区满了或手动都可以进行刷盘，也就是持久化到region，compact会将小文件不断合并，单个hfile会越来越大，之后运用split进行切割
rowkey 、cf ttl、region的设计。