大数据进阶相关重要原理-个人整理笔记

HDFS

1.HDFS概念：分布式文件存储系统，可通过线性添加机器扩充存储能力，有高容错性、适合大数据处理的优点，缺点为不适合小文件存储、不适合低延迟的数据访问。
2.HDFS的原理：把数据文件切分成大小等大的BLOCK块，把BLOCK块以多副本的行式存放在多个DATANODE上，在NAMENODE上保存数据文件与BLOCK块的映射和BLOCK块和DATANODE的映射，读取时从多个DATANODE上读取使负载均衡（就近原则读取）。
3.HDFS的组件及作用：
（1）NAMENODE 作用：管理HDFS的名称空间、管理数据块映射信息、处理读写请求。
注：其有两个重要文件：
①．fsimage文件：是HDFS文件系统存于硬盘中的永久性元数据检查点（即全量），里面记录了自最后一次检查点之前HDFS文件系统中所有目录和文件的序列化信息。
②．edits log文件：保存了自最后一次检查点之后所有针对HDFS文件系统的操作（即增量）。
Standby namenode备份并合并两个文件，形成新的fsimage文件传输给Active namenode。

（2）DATANODE作用：存储实际的数据块，执行数据块的读写。
（3）Client作用：切分数据块、与NAMENODE交互，获取文件信息、与DATANODE交互，读取或写入数据。
4.HDFS最小的存储单元为BLOCK数据块，默认情况下每个BLOCK有三个副本（可配置）；HADOOP1.X版本默认为64MB，2.X以上为128MB，可根据磁盘读写速度设置，一般100M/S 为128，200M/S为256MB，400M/S为512MB。
5.读写流程：
读

写

客户端通过DF类访问NN，发起写入请求，NN处理请求并给出写入地址；客户端领取地址后通过FOUTPUT类访问DN，将已经切分好的BLOCK块以更小的PACKET传输给第一个DN，DN会把已写入的PACKET传输给第二个DN，并向客户端领取切分的第二个PACKET，以此类推直到全部文件写入完成后，客户端结束与DN的交互，向NN告知写入完成，NN记录元数据。
6.HDFS副本放置策略：第一个副本放置在上传文件的DataNode服务器节点上，如果是在集群外提交，则随机放置在一个DataNode服务器节点上，第二个副本放置在不同机架的某个节点，第三个副本放置在第二个副本的机架的不同与第二个的节点，其他副本随机。
7.HDFS不适合存储小文件的原因：一个Namenode的内存是有限的，一个BLOCK元信息消耗的内存是一定的，即使不足128M。
8.hadoop2.x Federation（异构层级存储结构）：多个NN共用一个集群里的存储资源，每个NN都可以单独对外提供服务每个NN都会定义一个存储池，有单独的id，每个DN都为所有存储池提供存储。DN会按照存储池id向其对应的NN汇报块信息，同时，DN会向所有NN汇报本地存储可用资源情况。如果需要在客户端方便的访问若干个NN上的资源，可以使用客户端挂载表，把不同的目录映射到不同的NN，但NN上必须存在相应的目录。
9.ACL权限管理机制：类Linux的权限管理，对于一个文件来说，该文件有自己的所属用户和所属组，控制着读写权限。
Yarn
1.YARN概念：资源管理系统，提高资源利用率，可兼容各种计算架构，将多个计算框架集成在一个集群中，并使其数据共享。
2.YARN组件及作用：
（1）ResourManager：责所有资源的监控、分配和管理（已基于ZK实现高可用，有多个），内部包含schedule（分配资源）和Applicationmanager（应用的管理与监控）。
（2）NodeManager：有多个，负责单节点资源管理和使用。
（3）ApplicationMaster：每个应用有一个，负责应用程序的管理。
（4）Container：任务的运行环境。
3.运行流程：

客户端向RM传输应用程序，其中包括该应用的AM的相关信息，如启动命令、所需CPU及内存资源等，RM在各个NM上查找满足其运行的环境，并启动一个container用于运行AM，AM启动时会向RM注册自己，启动成功后与RM保持心跳，其内部会将应用程序切分成小TASK，然后向RM申请对应任务数的container环境，并与NM交互调起内部的container运行TASK，AM对container进行监控，container通过RPC协议向对应的AM汇报自己的进度和状态等信息，应用运行结束后，AM向RM注销自己，并收回属于它的container。
4.YARN的双层调度框架：RM将资源分配给AM，AM将资源进一步分配给各个TASK。
5.YARN的基于资源预留的调度策略：资源不够时会为TASK预留，直到资源充足,资源包括CPU和内存。
6.任务在NM运行失败后通过心跳反馈给RM，RM会将失败的任务告诉AM，AM决定如何处理失败的任务；RM负责重启AM，AM会保存已经运行完成的任务，重启后无需重新运行。
7.Yarn有三种调度方式：
（1）先进先出：优先提交的，优先执行，后面提交的等待。
（2）容量调度：允许创建多个任务对列，每个队列使用所有资源的一部分。多个任务对列可以同时执行。但是一个队列内部还是先进先出。CDH默认的调度器。
（3）公平调度：第一个程序在启动时可以占用其他对列的资源（100%占用），当其他对列有任务提交时，占用资源的对列需要将资源还给该任务。还资源的时候，效率比较慢。

Zookeeper

1.ZOOKEEPER概念：针对大型分布式系统的可靠的协调系统，是集群的管理者，监视着集群中各个节点的状态并根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
2.Zookeeper中组件及作用：
（1）领导者（Leader）：负责更新系统状态，发起投票（数据是否更新成功，大多数成功则认为成功）。
（2）跟随者（Follower）：接收客户请求，反馈结果，在选主过程中参与投票。
（3）观察者（ObServer）：3.3.0版本新增，接收客户端连接，将请求转发给Leader，不参加投票过程，只同步Leader的状态，目的为了扩展系统，提高读写速度。
（4）客户端（Client）：请求发起方。
3.Zookeeper 下的四种工作状态：
（1）LOOKING： 寻找Leader状态。当服务器处于该状态时，它会认为当前集群中没有Leader，因此需要进入Leader选举状态。
（2）LEADING： 领导者状态。表明当前服务器角色是Leader。
（3）FOLLOWING： 跟随者状态。表明当前服务器角色是Follower。
（4）OBSERVING： 观察者状态。表明当前服务器角色是Observer。
4.Znode的四种类型：
（1）PERSISTENT-持久节点：除非手动删除，否则节点一直存在于Zookeeper上。
（2）EPHEMERAL-临时节点：临时节点的生命周期与客户端会话绑定，一旦客户端会话失效（客户端与zookeeper连接断开不一定会话失效），那么这个客户端创建的所有临时节点都会被移除。
（3）PERSISTENT_SEQUENTIAL-持久顺序节点：基本特性同持久节点，只是增加了顺序属性，节点名后边会追加一个由父节点维护的自增整型数字。
（4）EPHEMERAL_SEQUENTIAL-临时顺序节点：基本特性同临时节点，增加了顺序属性，节点名后边会追加一个由父节点维护的自增整型数字。
5.ZAB协议：支持崩溃恢复的原子广播协议，ZAB协议包括两种基本的模式：崩溃恢复和消息广播。
当整个zookeeper集群刚刚启动或者Leader服务器宕机、重启或者网络故障导致不存在过半的服务器与Leader服务器保持正常通信时，所有进程（服务器）进入崩溃恢复模式，首先选举产生新的Leader服务器，然后集群中Follower服务器开始与新的Leader服务器进行数据同步，当集群中超过半数机器与该Leader服务器完成数据同步之后，退出恢复模式进入消息广播模式，Leader服务器开始接收客户端的事务请求生成事物提案来进行事务请求处理。
6.Zab和Paxos区别：
相同点：两者都存在一个类似于Leader进程的角色，由其负责协调多个Follower进程的运行，Leader进程都会等待超过半数的Follower做出正确的反馈后，才会将一个提案进行提交。ZAB协议中，每个Proposal中都包含一个 epoch 值来代表当前的Leader周期，Paxos中名字为Ballot。
不同点：目标不一样，ZAB用来构建高可用的分布式数据主备系统（Zookeeper），Paxos是用来构建分布式一致性状态机系统。
7.Zookeeper运行流程：客户端发起请求给S1，S1将请求传给领导者，领导者给各个S节点广播写请求（写入操作，包含领导者节点），各个节点反馈请求结果给领导者，多数成功则成功，领导者发布成功结果给各个S节点，S1节点反馈给客户端。
8.每个节点在Zookeeper中叫做znode，并且其有一个唯一的路径标识，节点znode可以包含数据和子节点（临时类型的节点不能有子节点），znode节点中数据可以有多个版本，比如某个路径下存多个数据版本，查询数据需要带版本号，客户端应用可以在节点上设置监视器（Watcher），某个节点发生变化时客户端可知道并做操作，节点不支持部分读写，必须一次性完整读写（要么成功要么失败）。
9.Watcher机制：Zookeeper允许客户端向服务端的某个Znode注册一个Watcher监听，当服务端的一些指定事件触发了这个Watcher，服务端会向指定客户端发送一个事件通知来实现分布式的通知功能，然后客户端根据Watcher通知状态和事件类型做出业务上的改变，出发后监听失效（一次性），减轻服务器压力，Watcher通知非常简单，只会告诉客户端发生了事件，而不会说明事件的具体内容，客户端向服务端注册Watcher的时候，并不会把客户端真实的Watcher对象实体传递到服务端，仅仅是在客户端请求中使用boolean类型属性进行了标记。
10.Watcher分三大步骤：
（1）客户端注册Watcher：getdata() and exists()设置数据监视，getchildren()设置了子节点监视。
（2）服务端处理Watcher：setData()会触发znode上设置的数据监视（如果set成功的话）。一个成功的create() 操作会触发被创建的znode上的数据watch，以及其父节点上的child watch。而一个成功的delete()操作将会同时触发一个znode的data watch和child watch（因为这样就没有子节点了），同时也会触发其父节点的child watch。
（3）客户端回调Watcher
11.Chroot特性：3.2.0版本后，添加了 Chroot特性，该特性允许每个客户端为自己设置一个命名空间。如果一个客户端设置了Chroot，那么该客户端对服务器的任何操作，都将会被限制在其自己的命名空间下，实现客户端应用隔离。
12.serverId（服务器ID 即 myid）、zxid（最新的事物ID 即 LastLoggedZxid）、epoch （逻辑时钟 即 PeerEpoch）。zxid实际上是一个64位的数字，高32位是epoch（时期; 纪元; 世; 新时代）用来标识leader周期，如果有新的leader产生出来，epoch会自增，低32位用来递增计数。
13.Leader选举：有两种，一种为集群启动时选举，一种为运行时选举。
运行时选举为例（如出现Leader宕机），首先各个节点状态会由FOLLOWING变更为LOOKING，每个节点会先发出一个投标给自己，格式为（myid,zxid），其它节点接受各个节点的投票后，首先判断该投票的有效性，如检查是否是本轮投票（通过逻辑时钟判断）、是否来自LOOKING状态的服务器，再与自己进行比较，具体比较为先进行zxid比较，大的则推举为Leader，如其相同则比较myid，大的获胜，然后变更自己的投票，超过半数则选为Leader，各个节点变更自己的状态为FOLLOWING，OBSERVING状态节点也就是观察者不参与投票。
14.Zookeeper分布式锁（文件系统、通知机制）：
（1）保持独占：我们将zookeeper上的一个znode看作是一把锁，通过createznode的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。用完删除掉自己创建的distribute_lock 节点就释放出锁。
（2）控制时序： /distribute_lock 已经预先存在，所有客户端在它下面创建临时顺序编号目录节点，和选master一样，编号最小的获得锁，用完删除，依次使用。

MapReduce

1.MapReduce概念：是一种分布式计算架构，适合大规模数据集的并行运算，能自动完成计算任务的并行化处理，在集群节点上自动分配及执行任务并收集计算结果，将数据分布存储、数据通信、容错处理等并行计算涉及到的很多系统底层的复杂细节交由系统负责处理，减少了开发人员的负担。不适合实时、流式、依赖计算。
2.运行过程：

整体流程为：input\splitting\mapping\shuffling\reducing\output
每个输入文件会被切分成片，默认以一个HDFS的BLOCK块大小为一片，每个分片会让一个MAP任务处理，map输出的结果（为key,value行式）会暂且放在一个环形内存缓冲区中（该缓冲区的大小默认为100M，由io.sort.mb属性控制），当该缓冲区快要溢出时（默认为缓冲区大小的80%，由io.sort.spill.percent属性控制），会在本地文件系统中创建一个溢出文件，将该缓冲区中的数据写入这个文件，在写入磁盘之前，会根据reduce任务的数目将数据划分为等数目的分区，一个reduce任务对应一个分区的数据（解决数据倾斜），然后对每个分区中的数据进行排序，如果此时设置了Combiner（主要作用是减少输出到reduce的个数，减少reducer的输入，提高reducer的执行效率），将排序后的结果进行聚合操作（这样做的目的是让尽可能少的数据写入到磁盘），当map任务输出最后一个记录时，会有很多的溢出文件，这时需要将这些文件合并。合并的过程中会不断地进行排序和聚合操作（目的有两个：尽量减少每次写入磁盘的数据量；尽量减少下一复制阶段网络传输的数据量，为了减少网络传输的数据量，这里可以将数据压缩）最后合并成了一个已分区且已排序的文件，然后将分区中的数据拷贝给相对应的reduce任务，Reduce会接收到不同map任务传来的数据，并且每个map传来的数据都是有序的。如果reduce端接受的数据量小，则直接存储在内存中（缓冲区大小由mapred.job.shuffle.input.buffer.percent属性控制，表示用作此用途的堆空间的百分比），如果数据量超过了该缓冲区大小的一定比例（由mapred.job.shuffle.merge.percent决定），则对数据合并后溢写到磁盘中，随着溢写文件的增多，后台线程会将它们合并成一个更大的有序的文件，最后一次合并的结果并没有写入磁盘，而是直接输入到reduce函数。
3.在Map任务和Reduce任务的过程中，一共发生了3次排序：
（1）当map函数产生输出时，会首先写入内存的环形缓冲区，当达到设定的阀值，在刷写磁盘之前，后台线程会将缓冲区的数据划分成相应的分区。在每个分区中，后台线程按键进行内排序。
（2）在Map任务完成之前，磁盘上存在多个已经分好区，并排好序的，大小和缓冲区一样的溢写文件，这时溢写文件将被合并成一个已分区且已排序的输出文件。由于溢写文件已经经过第一次排序，所有合并文件只需要再做一次排序即可使输出文件整体有序。
（3）在reduce阶段，需要将多个Map任务的输出文件copy到ReduceTask中后合并，由于经过第二次排序，所以合并文件时只需再做一次排序即可使输出文件整体有序。
注：在这3次排序中第一次是内存缓冲区做的内排序，使用的算法使快速排序，第二次排序和第三次排序都是在文件合并阶段发生的，使用的是归并排序。

HBase

1.HBase概念：Hbase一个分布式的基于列式存储的数据库，基于Hadoop的hdfs存储，zookeeper进行管理，主要用于海量结构化数据的存储。
2.优点/特点：
（1）Hbase适合存储半结构化或非结构化数据。
（2）面向列：面向列（族）的存储和权限控制，列（族）独立检索。
（3）稀疏：空（null）列并不占用存储空间，表可以设计的非常稀疏。
（4）数据类型单一：Hbase 中的数据都是字符串，没有类型。
（5）以列存储，rowkey、colunm family、colunm 定位一个单元。
3.HBaes架构及各组件：

（1）Zookeeper：保证集群中只有一个Master，存储所有region的寻址入口，监控region server并实时通知Master。
（2）Master：为region server分配region，负责region server的负载均衡，发现失效的region server并重新分配其上的region，管理用户对table的操作。
（3）region server：维护region，处理IO请求，切分region，一个region server可以有多个表的region，一个region只能被一个region server加载。
（4）Region：一个表被分成多个region存储，其rowkey是连续的且不重合的，一个region保存多个列族的数据，每个列族都是单独存储，列族的数据可以保存在不同的storeFile中。
4.读取流程：客户端先访问zookeeper 的ROOT表，查找meta的映射信息，然后访问HRegionServer上的meta表数据，找到所读取表与HRegionServer的映射，从而访问到对应的HRegionServer，进一步读取表数据。
5.写入流程：文件在行的方向上按大小分割成多个Region，每个表开始只有一个，随着数据增多，region不断增大，当达到一个阀值时（默认10G），region就会分成两个等大的新region，Region由一个或多个store组成，每个store保存一个colunm family，每个store又由一个memstore和0至多个storeFile组成，memstore存储在内存中，storeFile存储在HDFS上，当一个memstore满了后会FLASH一个storeFile存在磁盘上，在FLASH之前如果宕机也会丢失数据，所以数据也会同时先写入HLOG中，其也是HDFS中的文件（由LOG FLUSHER \LOG ROLLER对LOG文件进行切分和删除），当数据FLASH成具体的storeFile后则LOG文件中备份的数据会被删除，当 Storefile 越来越多，会触发 Compact 合并操作，把过多的 Storefile 合并成一个大的 Storefile。
6.Rowkey设计三大原则：
（1）长度原则：建议是越短越好，不要超过 16 个字节（太长会占用MEMSTORE的内存使用空间、会占用实际存储空间影响存储效率、操作系统64位，内存8字节对齐，所以8整数倍最好）。
（2）散列原则：建议将Rowkey的高位作为散列字段，由程序循环生成，低位放时间字段，这样将提高数据均衡分布在每个Regionserver 实现负载均衡的几率，避免热点现象（一段时间内数据在一个region上）。阿里：MD5+主维度+维度标识+子维度1+时间维度+子维度2。
（3）唯一原则：必须在设计上保证其唯一性。
7.root表在zookeeper上，存储META表的元数据，META表信息存储为：rowkey为表名+具体的regionID，列为：info:regioninfo 存表名+regionID+STARTKEY+ENDKEY；info:server 存regionserver的域名:端口号；info:serverstartcode 存regionserver的启动时间。
8.操作：
（1）建表：create ‘表名’，’列族名’
（2）查看表：list 或list
（3）插入数据：put ‘表名’,’row_key’,’列族名:列名’,’value’
（4）查询数据：get ‘表名’,’row_key’
（5）扫描表：scan ‘表名’
（6）删除数据：delete ‘表名’,’row_key’,’列族名:列名’,时间戳
9.HBase的cell：由{row key, column, version}唯一确定的单元，cell 中的数据是没有类型的，全部是字节码形式存贮。
10.TTL超时清除机制：ttl指清除机制，指超过时间则清除，老版本针对column family，新版本可支持Cell级别；Column family的TTL以秒为单位，cell的TTL以毫秒为单位。
11.HBase两种compaction的方式：
（1）Minor：只用来做部分文件的合并操作以及包括 minVersion=0 并且设置 ttl 的过期版本清理，不做任何删除数据、多版本数据的清理工作。
（2）Major：是对Region下的HStore下的所有StoreFile 执行合并操作，最终的结果是整理合并出一个文件。
12.预分区：针对rowkey的设计原则，进行预分区处理，避免出现热点问题（通过splits设置）。

Hive

1.Hive概念：HIVE是构建在Hadoop之上的数据仓库，数据计算使用MR，存储使用HDFS，其定义了一种类SQL语言HQL，通常用于离线处理，可认为是HQL-》MR的语言翻译器。
2.Hive架构及作用：

（1）元数据存储（metastore）：即数据存放在HDFS或MYSQL的位置信息，默认存储在自带的数据库derby中，使用时一般换成Mysql（存储于 derby数据库，此方法只能开启一个hive客户端；存储于mysql数据库中，可以多客户端连接）。
（2）用户接口：CLI，JDBC\ODBC，WebUI。
（3）驱动器（Driver）：解释器、编译器、优化器、执行器。
①．SQL Parser解析器：校验SQL语法问题。
②．Physical Plan编译器：将HQL翻译成MR任务。
③．Query Optimizer优化器：起优化作用。
④．Execution执行器：提交任务。
（4）Hadoop：用MR计算，用HDFS存储。
3.创建内部表：
Create table 表名 (z int, a string, no double)
partitioned by (分区列 类型,分区列 类型) —分区，就是分文件夹，分区字段不为某列，但是创建分区后便成为列（新字段）。
row format delimited fields terminated by ‘,’ --指定分隔符（\t：tab、\r：回车、\n：换行）
location ‘/user/hive/warehouse/表名’;–指定HDFS上文件位置
4.创建外部表：
Create external table 表名 (z int, a string, no double)
row format delimited fields terminated by ‘,’;
区别：删除数据的时候外部表仅删除表结构的元信息，不删除数据文件。
5.加载本地数据：
Load data local inpath ‘路径’ [overwrite] into table default.表名 partition(分区列=’’,分区列=’’);
HDFS加载数据：
Load data inpath ‘路径’ [overwrite] into table default.表名 partition(分区列=’’,分区列=’’);
6.针对某分区查询：select * from tab where 分区列=’’;
新增/删除分区：alter table 表名 add/drop partition(分区列=’’) partition(分区列=’’);
查看分区：show partitions tb;
查看分区结构：show formatted tb;
数据也可通过HDFS直接上传数据文件到分区文件夹下。
7.重命名表：alter table tb rename to newtb;删除表：drop table tb;查询表结构： desc formatted TB;
8.创建表一般预留字段，后期修改列名：alter table tb change old new 列类型;(不修改类型也需写)。
9.插入数据：
（1）insert overwrite table student
partition(month=‘201708’)
select id, name from student where month=‘201709’;
（2）建表插入：create table if not exists student3
as select id, name from student;
（3）导入数据： import table student2 partition(month=‘201709’)
from ‘/user/hive/warehouse/export/student’;
（4）导出格式化数据到指定目录：insert overwrite local directory —导出到HDFS上无local
‘/opt/module/datas/export/student’
ROW FORMAT DELIMITED FIELDS TERMINATED BY ‘\t’
select * from student;
或者
export table default.student to
‘/user/hive/warehouse/export/student’;
10.删除数据：truncate table student;
11.LIMIT 子句用于限制返回的行数：elect * from emp limit 5;
12.排序（四个by）：
（1）Order By：全局排序，结果只有一个 Reduce文件.
（2）Sort By：每个 Reduce 内部进行排序，对全局结果集来说不是排序。
设置 reduce 个数：set mapreduce.job.reduces=3;
不指定reduce个数：set mapreduce.job.reduces=-1;
查看设置 reduce 个数：set mapreduce.job.reduces;
结果有3个reduce文件，每个文件内部排序，随机分配数据
（3）Distribute By：类似 MR 中 partition进行分区，结合 sort by 使用，写在 SORT BY 语句之前。
（4）Cluster By：当 distribute by 和 sorts by 字段相同时，可以使用 cluster by 方式（cluster by 除了具有 distribute by 的功能外还兼具 sort by 的功能。但是排序只能是升序排序，不能指定排序规则为 ASC 或者 DESC）
13.分桶：分区针对的是数据的存储路径；分桶针对的是数据文件，是将数据集分解成更容易管理的若干部分的另一个技术。
语句如下：
create table stu_buck(id int, name string)
clustered by(id) into 4 buckets
row format delimited fields terminated by ‘\t’;
注：使用分桶表之前需开启分桶功能：set hive.enforce.bucketing=true;
针对分桶表直接LOAD数据是不行的，需要走MR任务，普通表INSERT分桶表。
使用场景：多用于抽样查询：
select * from tb tablesample(bucket x out of y on 列);
注：tablesample 是抽样语句，语法：TABLESAMPLE(BUCKET x OUT OF y)
x代表从第几个桶开始抽，桶数/y为抽几个桶的数据
如4个桶，x=1,y=4,表示从第一个桶开始抽，抽4/4=1个桶
x=1,y=8,表示从第一个桶开始抽，抽4/8=1/2个桶（一个桶一半的数据）
14.时间函数： 不同与Oracle 不加dual
select date_format(‘2019-06-29’,‘yyyy-MM-dd’);—格式化时间
select date_add(‘2019-06-29’,5);—时间加
select datediff(‘2019-06-29’,‘2019-06-24’);–两时间减
15.列转行：concat(‘hive’,rand()) 拼接hive和随机数
需求：把星座和血型一样的人放在一起，用|隔开。
字段：name ，constellation， blood_type 名字、星座、血型
实现语句：
select t1.base,concat_ws(’|’, collect_set(t1.name)) name
from(select name, concat(constellation, “,”, blood_type) base
from person_info) t1
group byt1.base;
16.行转列：
select movie,category_name
from tb
lateral view explode(列名) table_tmp as
category_name;
其他函数OVER(),rank()与Oracle一致。
17.根据用户自定义函数类别分为以下三种：
（1）UDF（User-Defined-Function）：一进一出。
（2）UDAF（User-Defined Aggregation Function）：聚集函数，多进一出，类似于：count/max/min。
（3）UDTF（User-Defined Table-Generating Functions）：一进多出，如 lateral view explore()。
18.Snappy 压缩：查看是否已支持Snappy压缩（hadoop下运行）：hadoop checknative
（1）开启 Map 输出阶段压缩：
①.开启 hive 中间传输数据压缩功能
hive (default)>set hive.exec.compress.intermediate=true;
②.开启 mapreduce 中 map 输出压缩功能
hive (default)>set mapreduce.map.output.compress=true;
③.设置 mapreduce 中 map 输出数据的压缩方式
hive (default)>set mapreduce.map.output.compress.codec=
org.apache.hadoop.io.compress.SnappyCodec;
④.执行查询语句
hive (default)> select count(ename) name from emp;
（2）开启 Reduce 输出阶段压缩：用户可能需要保持默认设置文件中的默认值false，这样默认的输出就是非压缩的纯文本文件了。用户可以通过在查询语句或执行脚本中设置这个值为 true，来开启输出结果压缩功能。
①.开启 hive 最终输出数据压缩功能
hive (default)>set hive.exec.compress.output=true;
②.开启 mapreduce 最终输出数据压缩
hive (default)>set mapreduce.output.fileoutputformat.compress=true;
③.设置 mapreduce 最终数据输出压缩方式
hive (default)> set mapreduce.output.fileoutputformat.compress.codec =
org.apache.hadoop.io.compress.SnappyCodec;
④.设置 mapreduce 最终数据输出压缩为块压缩，默认为行压缩
hive (default)> set mapreduce.output.fileoutputformat.compress.type=BLOCK;
⑤.测试一下输出结果是否是压缩文件
hive (default)> insert overwrite local directory
‘/opt/module/datas/distribute-result’ select * from emp distribute by deptno sort by empno desc;
19.Hive 支持的存储数的格式主要有：TEXT 、SEQUENCEFILE、ORC、PARQUET（TEXTFILE 和 SEQUENCEFILE 的存储格式都是基于行存储的；ORC 和 PARQUET 是基于列式存储的）。
（1）TextFile 格式 ：默认格式，数据不做压缩，磁盘开销大，数据解析开销大。可结合 Gzip、Bzip2 使用，但使用 Gzip 这种方式，hive 不会对数据进行切分，从而无法对数据进行并行操作。
（2）Orc 格式：Orc (Optimized Row Columnar)是 Hive 0.11 版里引入的新的存储格式。每个 Orc 文件由 1 个或多个 stripe 组成，每个 stripe250MB 大小，Stripe 里有三部分组成，分别是：
①．Index Data：默认是每隔 1W 行做一个索引。
②．Row Data：存的是具体的数据，先取部分行，然后对这些行按列进行存储。对每个列进行了编码，分成多个 Stream 来存储。
③．Stripe Footer：存的是各个 Stream 的类型，长度等信息。
（3）Parquet 格式：Parquet 文件是以二进制方式存储的，所以是不可以直接读取的，文件中包括该文件的数据和元数据，因此 Parquet 格式文件是自解析的。
注:在实际的项目开发当中，hive 表的数据存储格式一般选择：orc 或 parquet。压缩方式一般选择 snappy，lzo。
创建一个 SNAPPY 压缩的 ORC 存储方式：
create table log_orc_snappy(track_time string)
row format delimited fields terminated by ‘\t’
stored as orc tblproperties (“orc.compress”=“SNAPPY”);
20.优化：
（1）Fetch 抓取：Hql中的某些查询可以不使用MR计算，例如select * from table；这种情况下Hive可以简单读取table对应的存储目录下的文件，具体的操作方式：在hive/conf/hive-default.xml文件中，修改hive.fetch.task.conversion为more，这样全局查找，字段查找，filter查找，limit查找等都不走MR，直接Fetch。
（2）本地模式：Hive 可以通过本地模式在单台机器上处理所有的任务。对于小数据集，执行时间可以明显被缩短。
（3）空Key的处理：过滤和转换，对NULL值进行随机赋值。
（4）MapJoin：如果不指定 MapJoin 或者不符合 MapJoin 的条件，那么 Hive 解析器会将 Join 操作转换成 Common Join，即：在 Reduce 阶段完成 join。容易发生数据倾斜。可以用 MapJoin 把小表全部加载到内存在 map 端进行 join，避免在reducer 处理。
（5）Map 端聚合参数Group By：默认情况下，Map 阶段同一 Key 数据分发给一个 reduce，当一个 key 数据过大时就倾斜了，当选项设定为 true，生成的查询计划会有两个 MR Job。第一个 MR Job 中，Map 的输出结果会随机分布到 Reduce 中，每个 Reduce 做部分聚合操作，并输出结果，这样处理的结果是相同的 Group By Key 有可能被分发到不同的 Reduce 中，从而达到负载均衡的目的；第二个 MR Job 再根据预处理的数据结果按照 Group By Key 分布到 Reduce 中（这个过程可以保证相同的 Group By Key 被分布到同一个 Reduce 中），最后完成最终的聚合操作。
（6）Count(Distinct) 去重统计：数据量小的时候无所谓，数据量大的情况下，由于 COUNT DISTINCT 操作需要用一个Reduce Task 来完成，这一个 Reduce 需要处理的数据量太大，就会导致整个 Job 很难完成，一般 COUNT DISTINCT 使用先 GROUP BY 再 COUNT 的方式替换。
（7）开启动态分区：hive.exec.dynamic.partition=true
（8）分桶
（9）开启数据倾斜时负载均衡：set hive.groupby.skewindata=true;
（10）合理设置MAP和reduce数量、合并小文件、设置压缩。

Flink

1.Flink概念：Flink是一个框架和分布式处理引擎，用于对无界和有界数据流进行有状态计算，并且 Flink 提供了数据分布、容错机制以及资源管理等核心功能。Flink提供了诸多高抽象层的API以便用户编写分布式任务：
（1）DataSet API：将静态数据抽象成分布式的数据集，对静态数据进行批处理操作。
（2）DataStream API：将流式的数据抽象成分布式的数据流对数据流进行流处理操作。
（3）Table API：将结构化数据抽象成关系表，并通过类SQL的DSL对关系表进行各种查询操作。
2.Flink分层架构图：

（1）Deployment层：该层主要为Flink的部署模式，Flink支持多种部署模式：本地、集群（Standalone/YARN）、云（GCE/EC2）。
（2）Runtime层：提供了支持Flink计算的全部核心实现，比如：支持分布式Stream处理、JobGraph到ExecutionGraph的映射、调度等等，为上层API层提供基础服务。
（3）API层：主要实现了面向无界Stream的流处理和面向Batch的批处理API，其中面向流处理对应DataStream API，面向批处理对应DataSet API。
（4）Libraries层：该层也可以称为Flink应用框架层，根据API层的划分，在API层之上构建的满足特定应用的实现计算框架，也分别对应于面向流处理和面向批处理两类。面向流处理支持：CEP（复杂事件处理）、基于SQL-like的操作（基于Table的关系操作）；面向批处理支持：FlinkML（机器学习库）、Gelly（图处理）。
3.Flink两种在yarn上运行的模式：
（1）Session-cluster 模式：
Session-Cluster模式需要先启动集群，然后再提交作业，接着会向yarn申请一块空间后，资源永远保持不变。如果资源满了，下一个作业就无法提交，只能等到yarn中的其中一个作业执行完成后，释放了资源，下个作业才会正常提交。所有作业共享Dispatcher和ResourceManager；共享资源；适合规模小执行时间短的作业。
（2）Per-Job-Cluster 模式：
一个Job会对应一个集群，每提交一个作业会根据自身的情况，都会单独向yarn申请资源，直到作业执行完成，一个作业的失败与否并不会影响下一个作业的正常提交和运行。独享Dispatcher和ResourceManager，按需接受资源申请；适合规模大长时间运行的作业。
4.Flink运行时架构主要包括四个组件及作用：
（1）作业管理器（JobManager）：
控制一个应用程序执行的主进程，每个应用程序都会被一个不同的JobManager所控制执行。JobManager会先接收到要执行的应用程序，这个应用程序会包括：作业图（JobGraph）、逻辑数据流图（logical dataflow graph）和打包了所有的类、库和其它资源的JAR包。JobManager会把JobGraph转换成一个物理层面的数据流图，这个图被叫做“执行图”（ExecutionGraph），包含了所有可以并发执行的任务。JobManager会向资源管理器（ResourceManager）请求执行任务必要的资源，也就是任务管理器（TaskManager）上的插槽（slot）。一旦它获取到了足够的资源，就会将执行图分发到真正运行它们的TaskManager上。而在运行过程中，JobManager会负责所有需要中央协调的操作，比如说检查点（checkpoints）的协调。
（2）资源管理器（ResourceManager）:
主要负责管理任务管理器（TaskManager）的插槽（slot），TaskManger插槽是Flink中定义的处理资源单元。Flink为不同的环境和资源管理工具提供了不同资源管理器。当JobManager申请插槽资源时，ResourceManager会将有空闲插槽的TaskManager分配给JobManager。如果ResourceManager没有足够的插槽来满足JobManager的请求，它还可以向资源提供平台发起会话，以提供启动TaskManager进程的容器。另外，ResourceManager还负责终止空闲的TaskManager，释放计算资源。
（3）任务管理器（TaskManager）：
Flink中的工作进程。通常在Flink中会有多个TaskManager运行，每一个TaskManager都包含了一定数量的插槽（slots）。插槽的数量限制了TaskManager能够执行的任务数量。启动之后，TaskManager会向资源管理器注册它的插槽；收到资源管理器的指令后，TaskManager就会将一个或者多个插槽提供给JobManager调用。JobManager就可以向插槽分配任务（tasks）来执行了。在执行过程中，一个TaskManager可以跟其它运行同一应用程序的TaskManager交换数据。
（4）分发器（Dispatcher）：
可以跨作业运行，它为应用提交提供了REST接口。当一个应用被提交执行时，分发器就会启动并将应用移交给一个JobManager。由于是REST接口，所以Dispatcher可以作为集群的一个HTTP接入点，这样就能够不受防火墙阻挡。Dispatcher也会启动一个Web UI，用来方便地展示和监控作业执行的信息。Dispatcher在架构中可能并不是必需的，这取决于应用提交运行的方式。
5.任务提交过程：

Flink任务提交后，Client向HDFS上传Flink的Jar包和配置，之后向Yarn ResourceManager提交任务，ResourceManager分配Container资源并通知满足运行环境的NodeManager启动ApplicationMaster，ApplicationMaster启动后加载Flink的Jar包和配置构建环境，然后启动JobManager，之后ApplicationMaster向ResourceManager申请其他资源来启动TaskManager，ResourceManager分配Container资源后，由ApplicationMaster通知满足启动TaskManager资源的所在节点的NodeManager启动TaskManager，此NodeManager在加载Flink的Jar包和配置构建环境并启动TaskManager，TaskManager启动后向JobManager发送心跳包，JobManager生成优化后的执行计划，并以 Task 的单元调度到各个 TaskManager 去执行，TaskManager接收需要部署的 Task部署并启动后，与自己的上游建立连接，接收数据并处理。
6.所有的Flink程序都是由三部分组成的：
（1）Source负责读取数据源。
（2）Transformation利用各种算子进行处理加工。
（3）Sink负责输出。
7.Flink 三种时间语义：
（1）Event Time：是事件创建的时间。
（2）Processing Time：是每一个执行基于时间操作的算子的本地系统时间。
（3）Ingestion Time：是数据进入Flink的时间。
8.slot与parallelism：
Task Slot是静态的概念，是指TaskManager具有的并发执行能力，可以通过参数taskmanager.numberOfTaskSlots进行配置；而并行度parallelism是动态概念，即TaskManager运行程序时实际使用的并发能力，可以通过参数parallelism.default进行配置。
可以从四个不同层面设置并行度：
（1）操作算子层面(Operator Level)
（2）执行环境层面(Execution Environment Level)
（3）客户端层面(Client Level)
（4）系统层面(System Level)
优先级： 算子层面>环境层面>客户端层面>系统层面。
9.Watermark机制（水印）：
Watermark是用于处理乱序事件的，用Watermark机制结合window来实现，可以理解成一个延迟触发机制，我们可以设置Watermark的延时时长t，每次系统会校验已经到达的数据中最大的maxEventTime，然后认定eventTime小于maxEventTime - t的所有数据都已经到达，如果有窗口的停止时间等于maxEventTime – t，那么这个窗口被触发执行。
10.Flink 状态机制：
Flink内置的很多算子，包括源source，数据存储sink都是有状态的。在Flink中，状态始终与特定算子相关联。Flink会以checkpoint的形式对各个任务的状态进行快照，用于保证故障恢复时的状态一致性。Flink通过状态后端来管理状态和checkpoint的存储，状态后端可以有不同的配置选择。
11.Flink三种状态存储方式：
（1）MemoryStateBackend：基于内存的状态管理器，聚合类算子的状态会存储在JobManager的内存中。
（2）FsStateBackend：基于文件系统的状态管理器（存储于文件系统中）。
（3）RocksDBStateBackend：状态数据先写入RocksDB，然后异步的将状态数据写入文件系统。
注：性能：MemoryStateBackend>RocksDBStateBackend>FsStateBackend
12.常用的算子：
（1）Map：DataStream → DataStream，输入一个参数产生一个参数，map的功能是对输入的参数进行转换操作。
（2）Filter：过滤掉指定条件的数据。
（3）KeyBy：按照指定的key进行分组。
（4）Reduce：用来进行结果汇总合并。
（5）Window：窗口函数，根据某些特性将每个key的数据进行分组（例如：在5s内到达的数据）。
13.Flink中的窗口：
Flink 支持两种划分窗口的方式，按照时间和数量（窗口的两个重要属性：大小和间隔），如果size=interval,那么就会形成tumbling-window(无重叠数据)；如果size>interval,那么就会形成sliding-window(有重叠数据)；如果size< interval, 那么这种窗口将会丢失数据。比如每5秒钟，统计过去3秒的通过路口汽车的数据，将会漏掉2秒钟的数据。
14.Flink重启策略：
（1）固定延迟重启策略（Fixed Delay Restart Strategy）：尝试给定次数重新启动作业。如果超过最大尝试次数，则作业最终会失败。在两次连续重启尝试之间，重启策略等待一段固定的时间。
（2）故障率重启策略：在故障后重新启动作业，但是当failure rate超过（每个时间间隔的故障）时，作业最终会失败。在两次连续重启尝试之间，重启策略等待一段固定的时间。
（3）没有重启策略（No Restart Strategy）：作业直接失败，不尝试重启。
（4）Fallback重启策略（Fallback Restart Strategy）：使用群集定义的重新启动策略。这对于启用检查点的流式传输程序很有帮助。
注：默认情况下，如果没有定义其他重启策略，则选择固定延迟重启策略。
15.Flink 分区策略：
（1）GlobalPartitioner：数据会被分发到下游算子的第一个实例中进行处理。
（2）ShufflePartitioner：数据会被随机分发到下游算子的每一个实例中进行处理。
（3）RebalancePartitioner：数据会被循环发送到下游的每一个实例中进行处理。
16.Flink的分布式缓存：用户在并行函数中很方便的读取本地文件，并把它放在taskmanager节点中，防止task重复拉取。
机制（运行原理）：程序注册一个文件或者目录(本地或者远程文件系统，例如hdfs)，通过ExecutionEnvironment注册缓存文件并为它起一个名称，当程序执行，Flink自动将文件或者目录复制到所有taskmanager节点的本地文件系统，仅会执行一次。用户可以通过这个指定的名称查找文件或者目录，然后从taskmanager节点的本地文件系统访问它。
17.Flink中的广播变量：
我们知道Flink是并行的，计算过程可能不在一个 Slot 中进行，那么有一种情况即：当我们需要访问同一份数据。那么Flink中的广播变量就是为了解决这种情况。我们可以把广播变量理解为是一个公共的共享变量，我们可以把一个dataset 数据集广播出去，然后不同的task在节点上都能够获取到，这个数据在每个节点上只会存在一份。
注：广播变量和分布式缓存区别：广播变量是基于内存的,是将变量分发到各个worker节点的内存上；分布式缓存是基于磁盘的,将文件copy到各个节点上,当函数运行时可以在本地文件系统检索该文件。
18.Flink SQL的实现原理和实现SQL解析：基于Apache Calcite开源框架
（1）用户使用对外提供Stream SQL的语法开发业务应用.
（2）用calcite对StreamSQL进行语法检验，语法检验通过后，转换成calcite的逻辑树节点；最终形成calcite的逻辑计划。
（3）采用Flink自定义的优化规则和calcite火山模型、启发式模型共同对逻辑树进行优化，生成最优的Flink物理计划。
（4）对物理计划采用janino codegen生成代码，生成用低阶API DataStream 描述的流应用，提交到Flink平台执行。
19.Flink容错机制：Flink 实现容错主要靠强大的CheckPoint机制和State机制。Checkpoint 负责定时制作分布式快照、对程序中的状态进行备份；State 用来存储计算过程中的中间状态。
20.Flink的Exactly-once：通过检查点保证
（1）开始事务（beginTransaction）：创建一个临时文件夹，把数据写入到这个文件夹里。
（2）预提交（preCommit）：将内存中缓存的数据写入文件并关闭。
（3）正式提交（commit）：将之前写完的临时文件放入目标目录下。这代表着最终的数据会有一些延迟。
（4）丢弃（abort）：丢弃临时文件。
21.Flink与Spark有区别：Flink 是标准的实时处理引擎，基于事件驱动。而 Spark Streaming 是微批（Micro-Batch）的模型。
（1）架构模型：Spark在运行时的主要角色包括：Master、Worker、Driver、Executor，Flink 在运行时主要包含：Jobmanager、Taskmanager和Slot。
（2）任务调度：Spark Streaming 连续不断的生成微小的数据批次，构建有向无环图DAG，会依次创建 DStreamGraph、JobGenerator、JobScheduler；Flink 根据用户提交的代码生成 StreamGraph，经过优化生成 JobGraph，然后提交给 JobManager进行处理，JobManager 会根据 JobGraph 生成 ExecutionGraph，ExecutionGraph 是 Flink 调度最核心的数据结构，JobManager 根据 ExecutionGraph 对 Job 进行调度。
（3）时间机制：Spark支持的时间机制有限，只支持处理时间；Flink 支持了流处理程序在时间上的三个定义：处理时间、事件时间、注入时间。同时也支持 watermark 机制来处理滞后数据。
（4）容错机制：对于 Spark任务，我们可以设置 checkpoint，然后假如发生故障并重启，我们可以从上次 checkpoint恢复，但是这个行为只能使得数据不丢失，可能会重复处理，不能做到恰好一次处理语义；Flink 则使用两阶段提交协议来解决这个问题。

KAFKA

1.KAFKA概念：Kafka是一个分布式、分区的基于发布/订阅模式的消息系统（Message Queue）。
2.架构：

（1）Broker：一台kafka服务器就是一个broker。一个集群由多个broker组成。
（2）Topic：数据主题，根据业务系统将不同的数据存放在不同的topic中，一个大的Topic可以分布式存储在多个broker中，Topic可以类比为数据库中的库。
（3）Partition：每个topic可以有多个分区，通过分区的设计，topic可以不断进行扩展，即一个Topic的多个分区分布式存储在多个broker，此外通过分区还可以让一个topic被多个consumer进行消费，达到并行处理，分区可以类比为数据库中的表，kafka只保证按一个partition中的顺序将消息发给consumer，不保证一个topic的整体（多个partition间）的顺序。
（4）Producer：消息生产者，就是向kafka broker发消息的客户端。生产者负责将记录分配到topic的指定 partition（分区）中，有两个线程，主线程和Sender线程。主线程负责创建消息，然后通过分区器、序列化器、拦截器作用之后缓存到累加器RecordAccumulator中。Sender线程负责将RecordAccumulator中消息发送到kafka中。
（5）Consumer：消息消费者，向kafka broker取消息的客户端。每个消费者都要维护自己读取数据的offset。低版本0.9之前将offset保存在Zookeeper中，0.9及之后保存在Kafka的“__consumer_offsets”主题中。
（6）Consumer Group ：每个消费者都会使用一个消费组名称来进行标识。同一个组中的不同的消费者实例，可以分布在多个进程或多个机器上。
3.文件存储：

每个partition一个文件夹，包含四类文件.index、.log、.timeindex、leader-epoch-checkpoint
.index、.log、.timeindex 三个文件成对出现，前缀为上一个segment的最后一个消息的偏移，log文件中保存了所有的消息，index文件中保存了稀疏的相对偏移的索引，timeindex保存的则是时间索引，leader-epoch-checkpoint中保存了每一任leader开始写入消息时的offset 会定时更新，follower被选为leader时会根据这个确定哪些消息可用
4.ISR机制：
Leader维护了一个动态的in-sync replica set (ISR)，意为和leader保持同步的follower集合。当ISR中的follower完成数据的同步之后，leader就会给follower发送ack。如果follower长时间未向leader同步数据，则该follower将被踢出ISR，存入OSR（Outof-Sync Replicas）列表，新加入的follower也会先存放在OSR中，该时间阈值由replica.lag.time.max.ms参数设定。Leader发生故障之后，就会从ISR中选举新的leader。AR（所有副本）=ISR+OSR。
5.Kafka中的HW、LEO、LSO、LW：
（1）HW：High Watermark 高水位，取一个partition对应的ISR中最小的LEO作为HW，consumer最多只能消费到HW所在的位置上一条信息。
（2）LEO：LogEndOffset 当前日志文件中下一条待写信息的offset。
（3）LSO:Last Stable Offset 对未完成的事务而言，LSO 的值等于事务中第一条消息的位置(firstUnstableOffset)，对已完成的事务而言，它的值同 HW 相同。
（4）LW：Low Watermark 低水位, 代表所有副本集合中最小的 logStartOffset 值。
6.Kafka中消息的顺序性：kafka每个partition中的消息在写入时都是有序的，消费时，每个partition只能被每一个group中的一个消费者消费，保证了消费时也是有序的。整个topic不保证有序。如果为了保证topic整个有序，那么将partition调整为1。
7.Kafka中的分区器、序列化器、拦截器：
（1）序列化器：生产者需要用序列化器将key和value序列化成字节数组才可以将消息传入Kafka。消费者需要用反序列化器把从Kafka中收到的字节数组转化成相应的对象。
（2）分区器：如果 ProducerRecode 中没有指定 partition 字段，那么就需要依赖分区器，根据 key 这个字段来计算 partition 的值。分区器的作用就是为消息分配分区。
（3）拦截器：有两种拦截器：生产者拦截器和消费者拦截器
生产者拦截器既可以用来在消息发送前做一些准备工作，比如按照某个规定过滤不符合要求的消息、修改消息内容等，也可以用来在发送回调逻辑前做一些定制化的需求，比如统计类工作。
8.Kafka事务概念：Kafka事务机制支持了跨分区的消息原子写功能，即Kafka 生产者在同一个事务内提交到多个分区的消息，要么同时成功，要么同时失败。这一保证在生产者运行时出现异常甚至宕机重启之后仍然成立。此外，同一个事务内的消息将以生产者发送的顺序，唯一地提交到 Kafka 集群上。
9.事务流程：

（1）查找事务协调者：生产者首先会发起一个查找事务协调者 (TransactionalCoordinator) 的请求 (FindCoordinatorRequest)，Broker 集群根据 Request 中包含的 transactionalId 查找对应的 TransactionalCoordinator 节点并返回给 Producer。
（2）获取 Producer ID：生产者获得协调者信息后，向刚刚找到的 TransactionalCoordinator 发送 InitProducerIdRequest 请求，为当前 Producer 分配一个 Producer ID。分两种情况：不包含 transactionId：直接生成一个新的 Producer ID，返回给生产者客户端；包含 transactionId：根据 transactionId 获取 PID，这个对应关系保存在事务日志中（上图中的 2a 步骤）。
（3）开启事务：生产者通过方法 producer.beginTransaction() 启动事务，此时只是生产者内部状态记录为事务开始。对于事务协调者，直到生产者发送第一条消息，才认为已经发起了事务。
（4）消费-转换-生产（生产与消费配合）：存储对应关系，通过请求增加分区–》生产者发送消息–》增加消费 offset 到事务–》事务提交位移–》提交或回滚事务。

Sqoop

1.Sqoop概念：Hadoop(Hive)与传统的数据库(mysql、postgresql…)间进行数据的传递，可以将一个关系型数据库（例如 ： MySQL ,Oracle ,Postgres等）中的数据导进到Hadoop的HDFS中，也可以将HDFS的数据导进到关系型数据库中。
2.原理：将导入或导出命令翻译成mapreduce程序来实现。在翻译出的mapreduce中主要是对inputformat和outputformat进行定制。