1. 常用的高级命令：ps -ef 查看进程、top、iotop、netstat -tunlp | grep 端口号、df -h 、free 、tar、rpm
2. 查看磁盘使用情况：ps -ef，查看内存：top、free、jmap -heap 进程号，查看端口号：netstat
1. 常用工具 awk sed sort cut，知道对应名称。--》一般用Python写脚本。
2. 手写过哪些shell脚本、dataX导入，hive读取脚本。
3. 数据层级内部：ods -》 ads层。
#! /bin/bash 、定义变量、获取时间、SQL=‘’、执行SQL。
4.注意单引号与双引号区别。 ''不解析里面变量的值；""解析里面变量的值。遇到嵌套，谁在最外面以谁为准
1. 入门：常用端口号3.x： 9870 8088 19888 9820/8020；常用配置：core-site.xml hdfs-site.xml mapred-site.xml yarn-site.xml slaves workers
2. hdfs：
hdfs写流程：hdfs包含几个角色，namenode，DataNode，client。首先由client（一个分布式文件系统）向namenode发起写文件流程-》namenode收到请求后检查是否有权限写入以及文件路径是否存在-》检查无误后响应可以上传，客户端请求上传第一个文件，由namenode返回要写入到哪个DataNode节点的路径。-》然后client创建一个写的文件流，根据返回的路径与DataNode节点建立写入通道，写入DataNode节点的内存中，写到内存中的文件是一个个的chunk（包含512字节数据+4字节校验位），多个chunk累计够64KB后形成一个packet对象再进行传输，一边写入磁盘一边通过内存传输给其他DataNode节点。文件量过大可能一个节点不够写，由DataNode节点之间互相传输，client只对接一台DataNode。目的是提高写入效率-》写入DataNode内存的同时也会写入到一个ack队列作为备份，防止写入失败文件丢失。-》写入完成后返回请求。关闭客户端。
hdfs读流程：客户端client创建一个分布式文件系统对象向namenode请求读取数据，-》namenode检查权限和路径，返回目标文件的元数据，-》client创建一个读的文件流，根据元数据信息读取DataNode节点上的信息。-》串联读取，先读取第一个文件完成后再读下一个文件。
小文件危害：存储和计算。默认情况下，一个文件块，不管多小都会占用NN 150字节左右。小文件过多，浪费NN的存储内存。128M的内存能存储多少个文件块：128g * 1024m * 1024k * 1024字节 /150字节 =9.1亿个文件块
默认情况下，每个文件单独切片。1字节-》 1个maptask-》1g内存。 128m -》1个maptask-》1g内存
小文件怎么解决：har归档，本质是减少NN的存储压力。
jvm重用。
combineTextinputformat。
3. mr:
combinner是mapreduce程序中为了减小网络传输量而设置的一个组件，其父类其实就是reducer，combinner在每一个maptask后面进行数据的汇总，从而减少在map之后reduce之前的shuffle机制一系列的数据读写的io操作。
mr工作流程：客户端对输入文件进行切片-》切片大小与hdfs块文件大小一致128M，文件大小决定切片个数，切片个数决定maptask个数，-》inputformat根据文件类型读取切片-》根据切片个数开启maptask-》通过getpartition方法给文件标记分区-》写入环形缓冲区，默认大小是100M，写入达到80%开始反向溢写，左边存放索引数据，右边存放真实数据-》同一个文件内根据索引的key进行快排，设置combinner预聚合，然后对每个分区小文件进行归并排序，设置combinner预聚合，对同一分区内数据做统计，将文件压缩写入到磁盘。减少网络传输数据量-》reducetask主动拉取所有map对应分区的文件，拉取到内存，内存满了溢写磁盘，个数与maptask个数一致=》归并排序内存和磁盘中相同key的小文件进入同一个reduce方法执行计算，调用outputformat输出到磁盘文件。
shuffle原理：shuffle发生在map之后，reduce之前。map对切片文件标记分区写入到环形缓冲区，默认100M，写入80%开始反向溢写，左边放索引，右边放数据-》同一个文件内根据索引的key进行快排，排序完成后设置combinner预聚合，对多个文件进行归并排序，因为文件内各个key是有序的所以用归并排序，然后combinner预聚合结果，将文件压缩写入到磁盘。设置combinner是为了减少map之后reduce之前的shuffle中一系列的数据读写的io操作。
4. yarn：
yarn工作流程：yarn包含几个角色，client，resourcemanager，nodemanager，applicationmaster，container。首先client向rm发起提交任务请求（以flink为例，使用onyarn方式提交任务）-》rm收到请求后返回要提交任务的hdfs集群路径-》client将job提交到hdfs路径，提交的部分包括三样，job的切片，job的xml配置文件以及jar包。-》提交job完成后，申请运行applicationmaster。rm将请求初始化成一个任务，放在任务队列排队。可以一次运行多个任务，所以放到队列中-》等到有空闲的nodemanager从队列中领取任务，开启一个容器container运行job。-》容器启动applicationmaster，从hdfs读取job信息，计算运行任务所需的资源，然后向resourcemanager申请。-》由applicationmaster调用脚本运行计算任务，计算完成后向rm申请注销，请求关闭资源。
状态后端：负责状态的存储、访问以及维护。主要负责管理本地状态的存储方式和位置。
状态后端分类：哈希表状态后端（HashMapStateBackend）内存计算，内嵌RocksDB状态后端磁盘存储持久化。默认是HashMapStateBackend。
检查点：flink容错机制保证故障后的恢复，将之前某个时间点所有的状态保存下来，这个存档就是检查点。
检查点保存：周期性触发检查点，间隔时间可以设置。保存状态应该在所有算子都恰好处理完一个相同的输入数据的时候。
检查点算法：基于chandy-lamport算法的分布式快照，可以在不暂停整体流程的前提下，将状态备份到检查点。
状态一致性分类：最多一次at-most-once，至少一次at-least-once，精确一次exactly-once。
端到端的状态一致性：完整的流处理应用，包含了数据源、流处理器和外部存储系统三个部分，这个完整应用的一致性就叫端到端的状态一致性。
端到端精准一次：要求输入端数据可重放，如kafka可重置偏移量，要求flink开启checkpoint且精准一次，flink1.11之后采用非barrier对齐精准一次，输出端采用幂等或者事务。幂等：如hashmap的put，天然支持幂等的有mysql的主键update，HBASE的rowkey唯一。事务（外部系统提供）：事务写入要么成功要么失败，能够保证精准一次。如两阶段提交写kafka，两阶段提交写mysql。
两阶段提交：预写日志方式：
1.先把数据结果作为日志状态保存起来。
2.执行checkpoint进行检查点保存时，将这些数据结果持久化存储到检查点。
3.在收到检查点完成的通知时，将这些结果写入到外部系统。
4.成功写入所有数据后，在内部再次确认检查点（ack机制），将确认信息也持久化保存。
两阶段提交：用来解决分布式场景下的事务。分成两个阶段，第一段预提交，等检查点完成之后再正式提交。这种提交方式是真正基于事务的，需要外部系统提供事务支持。
1.当第一条数据到来，或者收到检查点的barrier时，sink任务会启动一个事务。
2.接下来接收到的所有数据，都通过这个事务写入到外部系统；这时由于事务没有提交，虽然已经写入到外部系统，但是不可用，属于预提交的状态。
3.当sink任务收到jobmanager发来检查点完成的通知时，正式提交事务，写入的结果就真正可用了。
4.发生故障时，未提交的事务也会回滚，未提交的数据都会撤回。
状态恢复是从最近的一个检查点恢复。
flink写入kafka两阶段提交：
1.flink从kafka主题的分区拉取数据，jobmanager触发检查点的保存，向所有source节点插入一个相同ID的barrier，将偏移量持久化存储到外部文件系统，这里是hdfs。
2.flink计算处理，将结果发送到sink。sink端收到第一条数据，开启kafka的事务，预提交开始。同时将事务的状态也保存到状态中。
3.预提交阶段：到达sink的数据调用kafka的.send方法，将数据写入缓冲区，再flush，此时数据写入到kafka，标记为未提交状态。任意一个sink节点在预提交过程中失败，整个预提交都会失败。
4.barrier到达sink节点，触发checkpoint将状态存储到hdfs，状态包含自身的状态和事务快照，同时开启一个新的kafka事务，用于barrier后面数据的预提交。
注意：只有第一个事务由sink节点的第一条数据开启，其他事务都是由barrier开启。
5.全部节点做完本地checkpoint，jobmanager向所有节点发送一个本轮成功的回调消息，预提交结束。
