HDFS
一、MR和Spark的区别：
1.计算速度
Spark除了需要Shuffle的计算之外，其他是将中间结果持久化到内存中，而MR是都需要落盘的，故Spark用于频繁读写中间结果的迭代计算
2.磁盘IO
MR的map端将中间输出结果和结果存储在磁盘上，reduce端有需要将从磁盘中读取中间结果，会造成磁盘IO成为瓶颈。而Spark将中间结果存储在内存中，reduce端从内存中拉取中间结果，避免了大量的磁盘IO
3.并行度
Spark会增加任务的并行度从而提高速度。由于将中间结果写到磁盘与从磁盘读取结果属于不同的环节，MR只是将他们简单的通过串行衔接起来。Spark把不同的环节抽象为Stage，允许多个Stage既可以串行执行，又可以并行执行。
4.资源分配
MR是基于进程，Spark是基于线程，MR是多进程单线程模型，而Spark是多进程多线程模型。
MR是由多个独立的Task进程组成，每个task相互独立地申请资源和申请数据，再到计算完成结果储存都是独立的
Spark是由多个独立的executer进程构建的临时资源池构建的，每个executer又分为多个task进程，拥有独立的map shuffle，reduce shuffle，同一个executer中的数据可以进行复用，大大提高了数据和资源的利用率，节省了大量调用数据和频繁申请资源所浪费的性能
Spark的多个task都在同一个进程上，这个进程会伴随spark应用程序的整个生命周期，及时没有作业进行，进程也是存在的。MR的每一个task都是一个进程，当task完成时候，进程也会结束。
MR启动就会进行更细粒度的资源申请，需要时候就申请资源，用完就销毁，缺点是申请销毁都是需要时间，并且不存在任务的并行
Spark把进程拿到以后，这个进程会一直存在，即使没有job在跑，后边的job可以直接启动，不需要再重新申请资源
二、spark 在 client 与在集群运行的区别
在client和在cluster的区别就在于driver所在的位置，client的driver运行在client端，cluster的driver运行在Application Manager内
三、设计 hbase 表需要注意的点
Hbase中表的索引是通过rowkey实现的；
在表中是通过rowkey的字典顺序来对数据进行排序，表中Region的划分是通过起始Rowkey和结束Rowkey在决定的
所有存储在Hbase中的数据都是二进制字节，没有数据类型
四、数据同样存在 hdfs，为什么 hbase 支持在线查询
Hbase能提供实时计算服务主要原因是由其架构和底层的数据结构决定的，即由LSM-Tree+HTable+Cache决定的，客户端可以直接定位到要查数据所在的HRegionserver服务器，然后直接在服务器的一个region上查找要匹配的数据
五、Hive怎么查看表结构，表创建语句？怎么查看表有哪些分区？怎么查看分区对应 hdfs路径？怎么计算某个分区的数据量大小？怎么计算某个分区的文件总数？
查看表结构：show table
查看表的分区：show partitions
查看对应分区的hdfs路径：show table
计算某个分区的数据量大小：desc extended databaseName.tableName;
六、有一 hive sql，怎么计算这个 sql 会产生多少个 map 数？
Hive底层就是MR，实际问题就是确定如何确定map和reduce的数量
map数量=split数量；split数量=文件大小/split size；split size=Math.max(minSize, Math.min(maxSize, blockSize))；默认的split size大小是128M
七、hive 支持哪些基木数据类型？
TINYINT;SMALLINT;INT;BIGINT;BOOLEAN;FLOAT;DOUBLE;STRING;BINARY;TIMESTAMP;DECIMAL;CHAR;VARCHAR;DATE;
复杂数据类型：
ARRAY：是由一系列相同数据类型的元素组成，这些元素可以通过下标来访问。
MAP：map包含k-v键值对，可以通过key来访问元素
STRUCT：可以包含不同的数据类型，通过点语法访问
八、reduceByKey()、groupByKey()有什么区别？
groupByKey：只能分组，不能聚合；
reduceByKey：有分组聚合的功能；
九、DataFrame 和 RDD 有什么区别？
RDD：是整个spark平台的存储、计算以及任务调度的逻辑基础，要具有通用性，适用于各类数据源。
DataFrame：是只针对结构化数据源的高层数据抽象，其中在dataframe对象的创建过程中必须指定数据集的结构信息
[图片]
十、Hadoop高可用原理
为了保证两个NameNode的元数据信息同步，Hadoop官方设计了两种模式，分别是NetWork
File System(NFS)和 Quorum Journal Manager(QJM)，工作流程如下：
1.NameNode Active会把记录写到本地配置目录中，文件名以edits_xxxx，并将这些文件上传到NFS或者QJM中
2.NameNode Standby会定期读取NFS或QJM中最近的edits_xxxx文件， 然后把这些文件和fsimage_xxxx文件合并为一个新的fsimage_xxxxx文件，
3.当合并工作完成以后，NameNode Standby会通知NameNode Active获取最新合并的fsimage_xxx文件，并替换掉原有的fsimage_xxx文件
NFS实现方式：由NameNode Active将最新的edits_xxxx文件写入NFS，然后NameNode Standby会从NFS中将数据读取出来。缺陷是：这种传输方式是通过网络来实现的，只要有一方存在网络问题，会导致信息不同步
QJM实现方式：解决NFS容错机制不足的问题，NameNode Active 和 NameNode Standby 之间元数据信息共享通过集群中的 JournalNode 来实现。
NameNode Active 会把最近产生的 edits_xxxxxx 文件写到 2m+1 个 JournalNode 中，只要保证有 n+1 个 JournalNode 写入成功即可认定本次操作有效。然后 NameNode Standby 就可以读取 JournalNode 中的数据进行合并操作。
十一、Hadoop中的容错性设计
1.NameNode单点故障
HDFS为Active NameNode分配了多个Standby NameNode，防止单个NameNode宕机导致集群崩溃
2.DataNode故障
DataNode保存了实际的数据，并且这些数据块在其他节点中也存有相同的副本。DataNode的心跳机制保证了在一定时间内像NameNode上报数据块的存储信息，以保证每个文件的副本数在正常水平线上
3.数据块损坏
DataNode保存数据块时候，会同时生成一个校验码
当存取数据块时候，如果发现校验码不一致时候，则认为数据块已经损坏，NameNode会通过其他节点上的正常副本重构损坏的数据块。
十二、HDFS如何删除数据
NameNode节点不存储实际的数据，所以元数据在执行delete时候，只需要标记哪些数据块需要删除。当标记删除的数据块NadeNode节点向NameNode节点发送心跳时候，NameNode节点会给当前的DataNode节点下达删除命令，删除DataNode节点中对应的数据块
十三、HDFS解决小文件问题
1.用户程序合并
1）HadoopArchive
hadooparchive为特殊的档案格式，一个hadooparchive对应一个文件系统目录，扩展名为*.har，存档的过程实际上是一个MapReduce过程，所以需要Hadoop的MapReduce支持
2）SequenceFile
SequenceFile 是hadoop提供的一种对二进制文件的支持，二进制文件直接将<k,v>对序列化到文件中，通过SequenceFile将小文件合格并起来，获得更高效的存储计算
3）CombineFileInputFormat
是一种新的inputformat，用于将多个文件合并成一个单独的split
2.机制上支持小文件合并
十四、Hadoop序列化
1.什么是序列化
序列化就是把内存中的对象，转换成字节序列以便于存储和网络传输
反序列化就是将接受到的字节序列或者硬盘的持久化数据，转换成内存中的对象
2.为什么不用Java的序列化
Java的序列化是一个重量级的框架，一个对象被序列化以后，会附带很多额外的信息，不便于在网络中高效传输
3.为什么序列化对Hadoop很重要
hadoop在集群之间进行通讯或者RPC调用的时候，需要序列化，而且要求序列化要快，并且体积要小，占用带宽要小，所以必须理解hadoop的序列化机制
十五、Hadoop RPC
在分布式网络中通常会采用远程调用（RPC）来作为通信协议。RPC在分布式计算中可以理解为一个客户端/服务端模式
十六、Hadoop中Block的存储策略
三副本的放置策略：
第一个副本写到同节点的DataNode上，另外两个副本写到另一个相同机架的不同DataNode上
若客户端与DataNode不同节点：HDFS会随机选择一个DataNode作为第一个副本放置节点，其他两个副本写到另一个相同机架的不同DataNode上
第一副本：防止在上传文件的DataNode上，如果是集群提交，则随机挑选台磁盘不太慢、CPU不太忙的节点
第二副本：放置在与第一个副本不同的机架的节点上
第三副本：与第二个副本相同的机架的不同节点上
十七、HDFS的负载均衡策略
若某个DataNode节点上的空闲空间低于特定的临界值，按照均衡策略就会自动地将数据从这些个DataNode移动到其他空闲的DataNode。当对某个问暗金的请求突然增加，那么也可能启动一个计划创建文件新的副本，并且同时重新平衡集群中的其他数据
启动负载均衡：$HADOOP_HOME/bin/start-balancer.sh -threshold
十八、HDFS的支持存储
1.ARCHIVE：高存储密度但耗电较少的存储介质，通常用来存储冷数据
2.DISK：磁盘介质，这是HDFS的默认存储介质
3.SSD：固态硬盘，是一种新型的存储介质
4.RAM_DISK：数据被写入内存中，同时会往该存储介质中异步再写一份
十九、HDFS中的集中式缓存管理
HDFS允许用户将一部分目录或文件缓存在of-heap内存中，以加速对这些数据的访问效率。该机制被称为集中式缓存管理
二十、HDFS的启动流程
当NameNode启动时候，从本地文件系统中读取edits和FSimage文件，将所有edits中的事务作用在内存中的FSimage上，并将这个新版本的FSimage从内存中写入到本地文件上，然后删除旧的edits，最后等待各个DataNode向NameNode汇报文件块的信息来组装block id中的映射关系
DataNode启动时候会扫描本地文件系统，产生一个本地文件对应HDFS文件块的列表，然后作为报告发送到NameNode
NameNode在接收到每个DataNode块汇报信息后，将其和所在的DataNode信息等保存在内存中
二十一、HDFS在两个集群之间传输数据
distcp是hadoop自带的分布式复制程序，可以在hadoop文件系统间复制大量数据，也可以将大量的数据复制到hadoop中。
distcp是作为一个MR作业来实现的，该复制作业是通过集群中并行运行的map来完成的，没有reduce
hadoop distcp hdfs://namenode1/foo hdfs://namenode2/bar
MR
一、MR是什么
是一个编程模型，用以进行大数据量的计算，MR是一种简化了的并行计算编程模型。Map代表并行计算，Reduce代表聚合
二、MapReduce编程模型
思想就是分而治之，map负责切分，把复杂的任务分解为若干个简单的，耦合度低，且可以并行计算的子任务来处理，通过分解之后，每个子任务的数据和计算规模都不太大，这些子任务通常会分配到数据所在的节点上运行
reduce负责对map姐u但的结果进行汇总，并将最终结果输出到HDFS
map函数以k-v键值对作为输入，产生另外一系列k-v键值对作为中间输出接入本地磁盘，mapreduce框架会自动将这些中间数据按照key值相同的数据统一交给reduce函数处理
reduce函数以k以及对应的v列表作为输入，经合并k相同的v值后，产生另外一系列k-v对作为最终输出写入HDFS，
Map 阶段
由一定数量的 MapTask 组成
输入数据格式解析: InputFormat (把输入文件进行分片)
输入数据处理: Mapper
数据分组: Partitioner
Reduce 阶段
由一定数量的 ReduceTask 组成数据远程拷贝(从 MapTask 的输出拷贝部分数据)
数据按照 key 排序和分组( key 相同的都挨在一起，按照 key 进行分组操作，每一组交由 Reduce 进行处理)
处理处理: Reduce
数据输出格式: OutputFormat (输出文件格式，分隔符等的设置)
三、MR的淘汰
使用场景受限：
1.实时计算，MR无法像mysql一样，在毫秒级内返回结果
2.流式计算：流式计算的输入数据式是动态的，而MR的输入数据是静态的
3.DAG计算：多个应用程序存在依赖关系，后一个应用程序的输入为前一个输出。MR并不是不能做，二十使用之后，每个MR作业的输出结果都会写入到磁盘中，会造成大量的磁盘IO，降低使用性能
高昂的维护成本
时间性能达不到用户的期待
四、MR如何解决数据倾斜的问题
数据倾斜就是数据的key的额分化严重不均，造成一部分数据很多，一部分数据很少
常见的数据倾斜有几类：某一个区域的数据量要远远大于其他区域。部分记录的大小远远小于平均值
数据倾斜发生的原因：1.在map端和reduce端都有可能发生数据倾斜。在map端的数据倾斜会让多样化的数据集的处理效率更低。在reduce端的数据倾斜常常来源于MR的默认分区器
数据倾斜调优：
set hive.map.aggr=true；在map中会做部分聚合操作，效率更高但需要更多的内存
set hive.groupby.skewindata=true;
常用的优化手段：减少job数，设置合理的task数，能有效提升性能，数据量大，慎用count，对小文件进行合并
YARN
一、YARN的工作流程
1.用户将应用程序提交到RM上
2.Rm为应用程序申请资源，并与某个NM通信启动第一个Container，以启动AM
3.AM与NM注册进行通信，为内部要执行的任务申请资源，一旦得到资源以后，将与NM通信，以启动对应的Task
4.所有的任务完成以后，AM向RM注销，整个应用程序运行结束
完整版：
1.客户端程序向 ResourceManager 提交应用并请求一个 ApplicationMaster 实例；
2.ResourceManager 找到一个可以运行一个 Container 的 NodeManager，并在这个Container 中启动 ApplicationMaster 实例；
3.ApplicationMaster 向 ResourceManager 进行注册，注册之后客户端就可以查询 ResourceManager 获得自己 ApplicationMaster 的详细信息，以后就可以和自己的 ApplicationMaster 直接交互了（这个时候，客户端主动和 ApplicationMaster 交流，应用先向 ApplicationMaster 发送一个满足自己需求的资源请求)；
4.在平常的操作过程中，ApplicationMaster 根据 resource-request 协议向 ResourceManager 发送 resource-request 请求；
5.当 Container 被成功分配后，ApplicationMaster 通过向 NodeManager 发送 container-launch-specification 信息来启动 Container，container-launch-specification 信息包含了能够让 Container 和 ApplicationMaster 交流所需要的资料；
6.应用程序的代码以 task 形式在启动的 Container 中运行，并把运行的进度、状态等信息通过 application-specific 协议发送给 ApplicationMaster;
7.在应用程序运行期间，提交应用的客户端主动和 ApplicationMaster 交流获得应用的运行状态、进度更新等信息，交流协议也是 application-specific 协议；
8.一旦应用程序执行完成并且所有相关工作也已经完成，ApplicationMaster向 ResourceManager 取消注册然后关闭，用到所有的 Container 也归还给系统。
二、YARN中的调度器
1.FIFO Scheduler
FIFO（first input first output）,把应用按照顺序提交排成一列，这是一个先进先出队列，在进行资源分配的时候，先给队列中最上头的应用进行分配资源，等最上头的应用需求满徐后再给下一个分配
2.Capacity Scheduler
3.FairS cheduler
三、YARN中解决高可用
在YARN中，也有和NM一样的高可用，也有Active/Standby RM,通过冗余解决RM单点故障，当Active RM出现故障时候，Standby RM可通过Zookeeper选举成为Active RM，通过RM Recovery机制恢复状态
Zookeeper
一、何为Zookeeper
是一个分布式协调服务的开源框架，主要用来解决分布式集群中应用系统的一致性问题。本质上是一个分布式的小文件存储系统，提供基于类似于文件系统的目录树的方式存储数据。监控数据的变化状态，提供统一的命名服务、分布式配置管理、分布式消息队列、分布式锁、分布式协调等功能。
二、Zookeeper的选举机制
ZK为了保证各个节点的协调工作，在工作时候需要一个leader角色，单个节点的投票数大于半数则胜出
服务器ID：在配置集群时候设置的myid参数，编号越大，表示在投票机制中的权重就越大
选举状态：共有四种，竞选状态、随从状态（同步leader状态，参与投票）、观察状态（同步leader，不参与投票）、领导者状态
事务ID：这是服务器中存放最新数据的版本号，该值越大，说明数据越新，在选举过程中数据越新，权重越大
Epoch：每个leader任期的代号，没有leader时同一轮投票过程中的逻辑时钟是相同的，每投完一次票这个数据就会增加。
[图片]
Zookeeper选举机制——非第一次启动
1.服务器1启动，发起一次选举，服务器1投自己一票。此时服务器1票数为1票，不够半数以上，选举无法完成，服务器1保持为竞选状态
2.服务器2启动，再发起一次选举，服务器1和服务器2分别投自己一票并交换选票信息，此时服务器1和服务器2分别为1票，此时服务器1发现服务器2的myid比自己目前投票推举的服务器1大，更改选票为推举服务器2，此时服务器1票数为0票，服务器2票数为2票，没有达到半数以上，选举无法完成，两者保持竞选状态
3.服务器3启动，发起一次选举，此时服务器1、2都会更改选票为服务器3，此时服务器3为3票，并且票数超过半数，服务器3当选Leader，服务器1、2更改状态为Following，服务器3更改状态为Leading
4.服务器4启动，发起一次选举，此时服务器1，2，3已经不是loking状态，不会更改选票信息，此时服务器3为3票，服务器4为4票，服务器4服从多数，更改选票信息为服务器3，更改状态为following
5，服务器5启动，结果同服务器4
Zookeeper选举机制——非第一次启动
集群中确实不存在Leader。
假设Zookeeper由5台服务器组成，SID（服务器ID）分别为1，2，3，4，5。ZXID（事务ID）分别为8，8，8，7，7。并且此时SID为3的服务器是Leader，某一时刻3和5服务器出现故障，因此开始进行Leader选举。
此时的选举规则：①EPOCH大的直接胜出，②EPOCH相同，事务ID大的胜出，③事务ID相同，服务器ID大的胜出
HIVE
一、hive详解
是基于hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供sql查询功能，可以将sql语句转换为mr任务进行运行
hive是建立在hadoop上的数据仓库基础架构，它提供了一系列的工具，可以用来进行数据提取转化加载。适合用来做海量离线数据统计分析
hive的优点：操作接口采用类sql语法，避免了去写MR，hive支持用户自定义函数
hive的缺点：不支持记录级别的增删改操作，hive的查询延时很重，hive不支持事务
二、Hive的系统架构
1.用户接口：CLI、JDBC/ODBC，CLI是shell终端命令行，是最常用的方式。
2.Thrift Server：用来进行可扩展且跨语言的服务
3.底层的驱动引擎Driver：用于完成HQL查询语句从词法分析、语法分析、编译、优化以及查询计划的生成，生成的查询计划存储在HDFS中，并在虽有由MR调用执行；Hive的底层计算引擎可选为MR、Spark、Tez
4.元数据存储系统 Metastore：元数据通常包括表名、列、分区及其相关属性，表数据所在的目录位置信息，Metastore默认存在自带的Derby数据库中，但通常将数据存储在mysql中
三、Hive中的数据模型
1.数据库
2.表
3.分区：在Hive存储上的体现就是在表的主目录下的一个子目录，这个子目录的名字就是定义的分区列的名字，分区列不是表里的某个字段，而是独立的列，根据这个列查询存储表中的数据文件
4.桶表：把表或者是分区组织的桶表的主要目的是为了获得更高的查询效率，尤其是抽样查询更加便捷。桶表是hive数据模型中最小单元，数据加载到桶表时候，会对字段的值进行哈希取值，然后除以桶个数得到余数进行分桶。在物理上，每个桶表via哦就是表或者分区的一个文件。
分桶是相对分区进行更细粒度的划分
分桶将整个数据内容按照某列属性值取hash值进行区分，具有相同hash值的数进入到同一个文件中
Hive分桶表是否可以通过直接load将数据导入？
不可以，直接load数据的话，hdfs下只会有一个文件无法完成分桶的效果，分桶和mapreduce中的分区是一样的道理
分区和分桶的区别？
分区是指按照表的某列划分为多个分区，分桶是相对分区进行更细力度的划分。分区就是在HDFS大行分目录，分桶就是分文件
四、Hive内部表与外部表的区别
外部表在创建的时候需要加上external关键字
创建内部表时候，会将数据移动到数仓库指向的路径，若创建外部表，仅记录数据所在的路径，不对数据的位置做任何改变
删除表时候，内部表删除后，表的元数据和真是数据都被删除了。外部表删除后，仅仅只是把该表的元数据删除了，真实数据还在，这样外部表相对来说更加安全一点，数据组织也更加灵活，方便共享源数据
五、将数据直接上传到分区目录HDFS上，让hive分区表和数据产生关联的方式有哪些
1.上传数据后修复表
hdfs dfs -mkdir -p 分区目录
hdfs dfs -put 分区目录
hive> msck repair table 表名
2.上传数据后添加分区
hdfs dfs -mkdir -p 分区目录
hdfs dfs -put 分区目录
hive> alter table 表名 add partition();
若直接将数据上传至HDFS上，因为hive没有对应的元数据所以是无法查询到数据的，所以要进行表修复或者添加分区
六、几种排序的比较、
1.ordey by
会对所给的全部数据进行全局排序，不管来多少数据，都只会启动一个reduce来处理
2.sort by
是全局排序，sort会根据数据量的大小启动一个或者多个reducer来干活，并且，它会在进入reduce之前为每个rduce都产生一的排序文件
3.distribute by
控制map结果的分发2，它会将具有相同字段的map输出分发到一个reduce节点上做处理
4.cluster by
理解为distribute 和sort的结合，当distribute 和sort后面所跟的列名相同时，就等等同于直接使用cluster跟上该列名，但是被cluater指定的列最终的排序结果只能是降序，无法指定asc和desc
七、SQL的执行顺序
from->on->join->where->group by->(sum,count,max,min,avg)->having->select->distinct->order by->limit
八、hive的SerDe是什么
serde是serializer和deserializer的简写，hive使用serde进行对象的序列化与反序列化，最后实现把文件内容映射到hive表中的字段数据类型
九、hive调优
1.Fetch抓取
是指，hive中某些情况的查询可以不必使用MR计算，hive.fetch.task.conversion默认是minimal，可修改为more，在全局查找、字段查找、limit查找等都不走MR。若设置为none，然后执行查询语句，都会走MR程序
2.本地模式
在hive客户端测试时候，默认情况下是启用hadoop的job模式，把任务提交到集群中运行，这样会导致计算非常缓慢。hive可以通过本地模式在单台机器上处理任务，对于小数据集，执行时间可以明显被缩短
–开启本地模式，并执行查询语句
set hive.exec.mode.local.auto=true;//开启本地mr
–设置local mr的最大输入数据量，当输入数据量小于这个值时采用local mr的方式，
–默认为134217728，即128M
set hive.exec.mode.local.auto.inputbytes.max=50000000;
–设置local mr的最大输入文件个数，当输入文件个数小于这个值时采用local mr的方式，
–默认为4
set hive.exec.mode.local.auto.input.files.max=5;
–执行查询的sql语句
select * from employee cluster by deptid;
3.表的优化
1）小标、大表join
将key相对分散，并且数据量小的表方法join左边，这样可以有效减少内存溢出错误发生的几率，再进一步，可以使用map join让小的维度先进内存，在map端完成reduce（新版本做了优化，放在左边和右边已经没有明显区别）
2）大表join大表
空key过滤：有时候join超时是因为某些key对应的数据太多了，而相同key对应的数据都会发送到相同的reducer上，从而导致内存不够。需要仔细分析这些key对应的数据是否是异常数据，我们需要在sql语句中进行过滤
空key转换：虽然某个key为空对应的数据很多，但是相应的数据不是异常数据，必须要包含在join的结果中，此时我们可以表a中的key为空的字段赋值一个随机值，按照随机值均匀地分不到不同的reducer上
3）map join
如果不指定map join或者不符合map join条件，那么hive解析器会将join操作转换成common join，在reduce阶段完成join容易发生数据倾斜。可以用map join把小标全部加载到内存在map端进行join，避免reducer处理
set hive.auto.convert.join = true;
4.使用股分区裁剪、列裁剪
尽可能早地过滤掉尽可能多的数据量，避免大量数据流入外层sql。
列裁剪：只获取需要的列的数据，减少数据输入
分区裁剪：分区在hive实质上目录，分区裁剪可以方便直接地过滤掉大部分数据，尽量使用分区过滤，少用select *
5.并行执行
把一个sql语句中没有相互依赖的阶段并行去运行，提高集群资源利用率
6.严格模式
hive提供了一个严格模式，可以防止用户执行那些可能意想不到的不好的影响的查询，通过hive.mapred,mode值为默认是非严格模式
1）对于分区表，除非where语句中含有分区字段过滤条件来限制范围，否则不允许执行
2）对于使用了order by语句的查询，要求必须使用limit语句
3）限制笛卡尔积的查询
7.jvm重用
jvm重用是hadoop调优参数的内容，其对hive的性能具有非常大的影响，特别是对于很难避免小文件的场景或者task特别多的场景，这类场景大多数执行时间都很短，jvm重用可以使得jvm实例在同一个job中重新使用n次，减少进程的启动和销毁时间
8.数据倾斜
合理设置map数量：
通常情况下，作业会通过input的目录产生一个或者多个map任务，并不是map数量越多越好，如果一个任务有很多小文件，则每个小文件也会被当作一个块，用一个map任务来完成，而一个map任务启动和初始化的时间远远大于逻辑处理的事件，就会造成很大的资源浪费，同时执行的map数是受限的
小文件合并：
在map执行前合并小文件，减少map数量
复杂文件增加map数量：
当input的文件都很大，任务逻辑复杂，map执行非常慢的时候，可以考虑增加map数，来使得每个map处理的数据量减少，从而提高任务的执行效率
HBASE
一、hbase特点
hbase是基于bigtable的论文的开源实现的，是建立在hdfs之上的，提供高可靠性、高性能、列存储、可伸缩、实时读写的分布式数据库系统，在需要实时读写随机访问超大规模的数据集时候，可以使用hbase
特点：
海量存储——存储大批量数据
列式存储——hbase表的数据是基于列族进行存储的，列族实在列的方向上进行的划分
极易扩展——底层依赖hdfs，磁盘不足时候，增加datanode节点就好了
高并发——支持高并发的读写请求
稀疏——针对hbase列的灵活性，列数据为空的情况下不会占用存储空间
数据多版本——数据可以有多个版本，默认情况下是根据版本号去区分
数据类型单一——所有的数据在hbase中是以字节数进行存储
二、hbase和RDBMS相比有什么区别
1.数据类型
hbase只有简单的字符串类型，所有的类型都是交由用户自己处理，它只保存字符串
2.数据操作
hbase只有很简单的增删改查操作，表和表之间是分离的，没有复杂的表和表之间的关系，所以不能，也没有必要实现表和表之间的关联操作
3.存储模式
hbase是居于列族存储的，每个列由几个文件保存，不同列的文件是分离的
4.数据维护
hbase的更新操作不应该叫做更新，虽然一个主键或列对应新的版本，但是它的旧版仍然会保留，实际上是插入了新的数据
5.可伸缩性
因为Hbase分布式数据库就是为了此目的开发出来的，所以它能够轻松地增加或减少硬件数量，并且对错误的兼容性比较高
三、hbase架构
基于zookeeper的高可用，保存了hbase的元数据信息，是所有hbase表的寻址入口，对hmaster和hregionserver实现了监控
1.HMaster
为HRegionServer分配Region、维护整个集群的负载均衡、维护集群的元数据信息、发现失效的Region，并将失效的Region分配到正常的HRegionServer上
2.HRegionServer
Hbase集群中的小弟、负责关联Region、接受客户端的额读写数据请求、切分在运行过程中变大的Region
3.Region
hbase集群中分布式存储的最小单元，region有点像关系型数据库中的分区，数据存放在region中，当然region下面还有很多结构。确切来说数据存放在memstore和hfile中，
四、Hbase表的数据模型
1.rowkey
行键，table的主键，table中记录按照rowkey的字典顺序进行排序
2.column family
列族，hbase表中每个列，都归属于某个列族，列族是表的schema的一部分，必须在使用表之前定义
3.Timestamp
时间戳，每次数据操作对应的时间戳，可以看作是数据的version版本号
4.column
列，列族下面的具体列，属于某一个column family，类似于我们mysql当中创建的具体列
5.cell
单元格，由rowkey、column、version唯一确定的单元，cell中的数据是没有类型的，全部是以字节数进行存储
五、Hbase的存储原理
一个HRegionServer会负责管理很多个region，一个region包含很多个store，一个store里面只有一个memstore，一个sotre里面有很多个storeFile，最后数据是以很多个HFile这种数据结构的文件保存在HDFS上
划分规则：
一个列族就划分成一个store，如果一个表中只有一个列族，那么每一个region中只有一个store
memstore是一块内存区域，数据会先写入到memestore进行缓冲中，然后再把数据刷到磁盘
storefile是HFile的抽象对象，如果说到storefile就等于Hfile，每次memstore刷写数据到磁盘，就生成对应的一个新的HFile文件出来
[图片]
六、HBase的flush机制和compact机制
flush机制
当memstore的大小超过默认的flush刷写阈值128m时候，会flush到磁盘
当menstore中的数据时间超过默认的时间1小时，会flush到磁盘
HRegionServer的全局memstore的大小，超过该大小会触发flush到磁盘，默认是堆大小的40%
compact机制
HBase防止小文件过多，以保证查询效率，hbase需要在必要的时候将这些小的store file合并成相对较大的store file，合格过程就称之为compaction
hbase中主要有两种类型的compaction
1）minor compaction小合并
将store中多个HFile合并为一个HFile，整个过程中，达到TTL会被移除，并且删除和更新数据仅仅只是做了标记，没有物理移除，这种合并的触发频率很高
2）major compaction大合并
合并store中所有的HFile为一个HFile，这个过程中有删除标记的数据会被真正移除，同时超过单元格max version的版本也会被删除，合并频率比较低，默认7天执行一次
七、HBase 的 region 拆分机制
Region 中存储的是大量的rowkey数据，当region中的数据条数过多的时候，直接影响查询效率
当region过大的时候，hbase会拆分region，这也是hbse的一个优点
八、Hbase中的热点
热点：检索hbase的记录首先要通过row key来定位数据行，当大量的client访问hbase集群的一个或者少数几个节点，造成少数region server的读写请求过多、负载过大，而其他regionserver负载却很小，就造成了热点现象
解决热点现象：
预分区：预分区的目的让表的数据可以均衡的分散在集群中，而不是默认只有一个region分布在集群的一个节点上
加盐：这里所说的加盐，不是密码学中的加盐，而是在rowkey的前面增加随机数，具体就是给rowkey分配一个随机前缀可以使得它和之前的rowkey的开头不同
哈希：哈希会使同一行永远用一个前缀加盐，哈希也可以使负载分散到整个集群，但读确实可以预测的，
反转：反转固定长度·或者数字格式的rowkey，这样可以使得rowkey中经常改变的部分放在前面，这样可以有效随机rowkey
九、Hbase的读写流程
1.读操作
1）首先从zookeeper找到meta表的region位置，然后读取hbase：mate表中的数据，hbase:meta表中存储了用户表的region信息，
2）根据要查询的namespace、表名和rowkey信息，找到写入数据对应的region信息
3）找到这个region对应的regionserver，然后发送请求
4）查找对应的region
5）先从memstore查找数据，如果没有，再从blockcache上读取
6）如果blockcache中也没有找到，再到storeFile上进行读取
7）从storefile中读取数据之后，不是直接把结果数据返回给客户端，而是把数据先写入到blockcache中，目的是为了加快后续查询，然后在返回结果给客户端
HBase上regionserver的内存分为两个部分，一部分了memstore，主要用来写，另外一部分作为blockcache，主要用来读数据
2.写操作
1）首先从zookeeper找到hbase:meta表的region位置，然后读取hbase:meta表中的数据，hbase:meta表中存储了用户表的region信息
2）根据namespace、表名和rowkey信息找到写入数据对应的region信息
3）找到这个region对应的regionserver，然后发送请求
4）把数据分别写入到HLog和MemStore各一份
5）MemStore达到阈值后把数据刷到磁盘，生成sotreFile文件
6）删除HLog中的历史数据
十、BlockCache
Hbase读缓存结构–blockcache
客户端读取某个block，首先会检查该block是否存在于blockcache，如果存在就直接加载出来，如果不存在则到HFile文件中加载，加载后放到blockcache中，后续相同情况，可以直接从内存中获取，避免昂贵的io操作
block是hbase中最小的数据读取单元，即数据从hfile中读取都是以block为最小单元执行的。
一个regionserver只有一个blockcache
十一、Coprocessor
HBase使用coprocessor机制，使用户将自己编写的程序运行在regionserver上
分为两类：observer、endpoint
1）observer类似于mysql中的触发器。提供钩子使用户代码在特定事件发生之前或者之后得到执行
[图片]
十二、BulkLoad
业务需要用户将海量数据导入到hbase中，以执行随机查询和更新操作，为了避免较大的写入压力，使用bulkload
bulkload首先使用MR将待写入集群数据转换为HFile文件，再将这些HFile文件加载到在线集群中，不经过regionserver处理。
十三、Hbase怎样负载均衡
在实际的生产环境中，负载均衡机制最重要的一个应用场景是系统扩容，分布式系统通过增加节点实现扩展性
扩容操作分为两部分：需要增加节点让系统感知到节点的加入，其次，需要将系统中已有节点负载迁移到新加入的节点上
负载均衡策略–SimpleLoadBalancer、StochasticLoadBalancer
SimpleLoadBalancer：能够保证每个regionserver的region个数基本相等，假设集群中一共有n个regionserver，m个region，那么集群的平均负载就是m/n，可以有效保证所有regionserver上的region个数都在[floor(m/n),ceil(m/n)]之间，故SimpleLoadBalancer中负载就是region的个数
StochasticLoadBalancer：对于负载的定义不再是region的个数简单，而是由多种独立负载加权计算的复合值，这些独立负载包括：
Region 个数( RegionCountSkewCostFunction )
Region 负载
读请求数( ReadRequestCostFunction )
写请求数( WriteRequestCostFunction )
Storefile 大小( StoreFileCostFunction )
MemStore 大小( MemStoreSizeCostFunction )
数据本地率( LocalityCostFunction )
移动代价( MoveCostFunction )
经过加权计算得到一个代价值，使用代价值评估当前region分布是否均衡，越均衡代价值越低，不断挑选随机迭代找到一组region迁移计划，使得代价值最低
十四、hbase如何避免Full GC
若zookeeper检测regionserver节点是否存活时候，若很久没回应，则判定为宕机。等regionserver结束了full GC后，查看zookeeper时候发现自己已经被标记为宕机，为了防止脑裂的发生，它会自我停止，称之为regionserver自杀。
- 串行回收器（SerialGC）。
- 并行回收器（ParallelGC），主要针对年轻带进行优化（JDK8 默认策略）。
- 并发回收器（ConcMarkSweepGC，简称 CMS）,主要针对年老带进行优化。
- G1 GC回收器，主要针对大内存（32GB以上才叫大内存）进行优化。
Flume
是一个高可用、高可靠、分布式海量日志采集、聚合、传输系统。
高度定制化各个组件：source、channel、sink
一、flume架构
flume核心是把数据从数据源收集过来，再送到目的地，为了保证传输成功，在送到目的地之前，会先缓存数据，待数据真正到达目的地后，删除自己缓存的数据。
flume分布式系统中最核心的角色是agent，flume采集系统就是由一个个agent所连接起来形成的
flume中将数据流水线中传递的数据称为event，每个evet由头部和字节数组两部分构成，可由专门的客户端程序产生，这些客户端程序将要发送的数据封装成event对象，并调用flume提供的sdk发送给agent
1.soucre
采集组件，用于跟数据源对接，获取数据，flume数据流中接取event的组件，从client程序或者上一个agent接收数据，并写入一个或者多个channel
2.channel
传输通道组件，缓存数据，用于从source将数据传递到sink。channel是一个缓存区，它暂存source写入的event，直到被sink发送出去
3.sink
下沉组件，数据发送给最终存储系统或者下一级agent中
二、flume的可靠性级别有哪些
1.End-To-End
只要发送端是活跃的，发送到flume的event就一定能到达另一端，为实现这个级别的可靠性，接受event数据的agents会把数据以预写日志的方式写入磁盘。当event数据达到预定的终端时候，会发送一个收条给gent，然后agent才会移除这条数据
2.Store on failure
event数据经过不同的agent跳转event的发送方agent只会在接收方agent发生故障时候才能将数据保存到磁盘
3.Best-effort
可靠性是最弱的，event不经写入磁盘而直接被转发给下一条，也不依赖下一个agent的收条，读者可以根据自身的应用需求来选择正确的可靠性级别
三、flume实现断点续传
当一个flume挂掉之后重启的时候还是可以额接着上一次的数据继续收集
本质就是：记录下每一次的消费的位置，把消费信息的位置保存到文件中，后续程序挂掉了再重启的时候，可以接着上一次消费的数据位置继续拉取。
四、flume的使用场景
1.从各种source获取数据并存储到hadoop中
2.高速地处理大量数据到hadoop中
3.可靠地传输数据到目的地
4.可扩展的解决方案，当数据涌入速度和数量增加时候，只需增加机器可以实现扩展
5.架构中各个组件可以动态配置，无需暂停服务
KAFKA
基于Scala和Java开发的一个开源的流式数据处理平台，实时高效的传输海量数据
一、kafka存在价值
1.解耦
允许独立的扩展或修改两边的处理过程，只要确保他们遵守同样的接口约束
2.冗余
消息队列把数据进行持久化直到他们已经被完全处理，规避了数据丢失风险
3.削峰
在访问量剧增的情况下，应用仍然需要继续发挥作用，为了能够处理峰值数据，使用消息队列能够使关键组件顶住突发的访问压力，不会因为突发的超负荷请求而完全崩溃
4.可恢复性
系统的一部分组件失效后，不会影响到整个系统，消息队列降低了进程间的耦合度，即使处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理
5.缓冲
有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况
6.异步通信
提供异步处理机制，允许用户把一个消息放入队列，但不允许立即处理它，想向队列中放入多少消息就放入多少，在需要的时候进行处理
二、Kafka架构
1.record
kafka是消息引擎，消息就是值kafka处理的主要对象
2.producer
消息生产者，发布消息到kafka集群的终端或服务
3.broker
Kafka集群中包含的服务器
4.topic
每条发布到kafka集群的消息属于的类别，kafka是面向topic的，主题是承载消息的逻辑容器
5.partition
partition是物理上的概念，每个topic包含你一个或者多个partition，kafka分配的的单位是partition，
6.offset
表示分区中每条消息的位置信息，是一个单调增且不变的值
7.consumer offset
表征消费者的消费进度，每个消费者都有自己的消费者位移
8.consumer
从kafka集群中消费信息的终端或服务
9.consumer group
每个consumer都属于一个consumer group，每条消息只能被consumer group中的一个consumer消费，但可以被多个consumer group 消费
10.replication
partition的副本，保障partition的高可用，kafka中同一条消息能够被拷贝到多个地方提供数据冗余，这些地方就是所谓的副本
三、Kafka的ACKS三种机制
1.ACKS=0
producer不管写入broker的消息到底成功没，发送一条消息出去，立马就可以发送下一条消息，这是吞吐量最高的方式，数据丢失率高
2.ACKS=all或ACKS=-1
这个leader写入成功以后，必须等待其他的ISR中的副本都写入成功，才可以返回相应这条消息写入成功，收到一个回调通知
3.ACKS=1
只要leader写入成功，就认为消息成功了，可能会导致数据丢失
四、保证kafka数据的有序性
1.只设置一个partition分区
默认保证同一个partition分区内的消息是有序的，则可以设置topic只使用一个分区，这样消息就是全局有序的，缺点是性能降低，不适用于高并发的情况
2.producer将消息发送到指定的partition分区
kafka默认保证同一个partition分区内的消息是有序的，则producer可以在发送消息时候可以指定保证顺序的几条消息发送到同一个分区，保证数据有序性
五、kafka处理积压消息
处理消息积压方法：生产者——>提升吞吐量，消费者——>扩容，扩分区，增加consumer
如果是单位时间发送的消息增多（大促），唯一的方式是通过扩容消费端的实例数来提升总体的消费能力。如果短时间没有足够的服务器资源进行扩容，将系统降级，关闭一些不必要的业务，减少发送方发送的数据量，最低限度让系统运行
六、Kafka分区机制
自带的producer会根据murmur2算法计算得到消息key的哈希值，然后对总分区数求模得到消息要被发送到的目标分区号
七、生产者压缩算法
1.为什么要压缩
数据压缩显著降低磁盘和带宽占用，从而有效地提升了IO密集型应用的性能。引入压缩同时会额外消耗CPU的时钟周期，
producer端能够将一批消息压缩成一条消息发送，broker端将这条压缩消息写入本地日志文件。当consumer获取到压缩消息时候，会自动地对消息进行解压缩，还原成初始消息集合返回给用户
八、kafka的幂等性
1.为什么需要幂等性
producer在生产发送消息时候，难免会重复发送消息，Producer进行retry时产生重试机制，发送消息重复发送，引入幂等性后，重复发送只会产生一条有效的消息
用空间去换事件的优化思路，在broker端多保存一些字段，当producer发送了具有相同字段值的消息后，brokeer能够自动知晓这些消息已经重复了，于是在后台丢弃
FLINK
一、入门
flink是实现流处理和批处理时，与传统方案完全不同，flink是完全支持流处理，也就是作为流处理看待输入数据流是无界的，批处理被作为一种特殊的流处理，只是它的输入数据被定义为有界的
flink在流式计算方面无人能及
二、flink架构
1.client
flink作业在哪台机器上提交，当前机器就称之为client，用户开发的程序代码，会构建出dataflow graph，然后通过client提交给jobmanager
2.jobmanager
主节点，对比yarn中的resourcemanager，生产环境中一般可以做HA高可用，jobmanager会将任务进行拆分，调度到taskmanager上面执行
3.taskmanager
从节点，是真正实现task的部分
4.执行过程
当flink系统启动时候，首先启动jobmanager和taskmanager，jobmanager负责协调flink系统，taskmanager则是执行并行程序的worker，当一个程序被提交以后，系统会创建一个client来进行预处理，将程序转变成一个数据流的形式，交给jobmanager和taskmanager执行
三、flink中的窗口（重点）
对于流式数据，我们往往需要对到来的数据进行计算，但数据又在源源不断的产生，故产生的窗口的概念，对某一时间段内的数据进行计算，这便是窗口
window是一种可以把无限数据切割为有限数据块的手段，窗口是以时间驱动的或者事件驱动
1）窗口类型：滚动窗口、滑动窗口、会话窗口
2）time三兄弟：event time–事件产生时间，ingestion time–事件进入flink时间，processing time–事件被处理时当前系统时间
四、水位线watermark
watermark是处理乱序事件的，而正确的处理乱序事件，使用watermark机制结合window实现，watermark用来触发window进行计算
1.watermark解决迟到数据
如果基于event time构建window，但是对于迟到数据，又不能持续等待下去，有一个机制来保证一个特定的时间后，触发window进行计算
对于有序流watermark：watermark就是一个简单的周期性标记
对于无序流watermark：告知oparator比watermark更早的事件已经到达，operator可以将内部事件事件提前到watermakr的事件戳
2.迟到数据处理
1）直接丢弃
2）指定一个允许延迟的时间间隔，提供一个宽容时间，在执行延迟时间内到达的数据还是可以触发window执行计算逻辑
3） 侧输出流收集迟到数据，
五、状态保存和恢复
如果没有状态管理，那么一个task在处理过程中挂掉了，它在内存中的状态都会丢失，所有的数据都需要重新计算，故引入state、checkpoint
1.state、checkpoint
state是指一个具体的task、operator的状态
checkpoint：可以理解为把state数据持久化存储了，表示在一个flink job在一个特定的时刻的一份全局状态快照
flink中有两种基本类型的state，keyed state、operator state，针对两种state，每种state都有两种方式存在，原始状态、托管状态
托管状态是由flink管理的状态。而原始状态是由用户自行管理状态具体的数据结构。通常在datastream上的状态推荐使用托管状态，当实现一个用户自定义的operatoe时候，会使用到原始状态
2.keyedstate状态
基于keyedstream上的状态，是跟特定的key绑定的，对keyedstream流上的每一个key，都对应一个state
3.operator state状态
对于与key无关的datastream可以进行状态托管，与算子进行绑定
4.checkpoint
是flink实现容错机制的最核心的功能，能够周期性地基于stream中各个operator的状态来生成快照，从而将这些数据定期持久化存储下来，一旦崩溃，可以重新运行快照进行恢复
KYLIN
一、cube技术
cube是MOLAP中使用额一种技术，MOLAP表示基多维数据组织的OLAP实现，以多维世俗据组织方式为核心，MOLAP使用多维数组存储数据，多维数据在存储中形成立方块的结构。会将细节数据和聚合后的数据保存在cube中，以空间换效率
二、Kylin的特性
1.可扩展超快的基于大数据的分析性数据仓库；为了减少计算延迟而设计
2.hadoop ansl sql接口；支持标准sql的部分查询功能
3.交互式查询；用户可以与hadoop数据及逆行亚秒级交互，性能强于hive
4.多维立方体；能够在kylin里为百亿以上数据集定义数据模型并构建立方体
5.kylin和CK称为OLAP领域双子星
三、kylin的工作流程
1.指定数据模型，定义维度和度量
2.预计算cube，计算所有cuboid并保存为物化视图
3.执行查询时候，读取cuboid，运算，产生查询结果
Kylin的查询过程不会扫描原始记录，而是通过预计算先完成表的关联、聚合等运算，利用预计算的结果来执行查询
SPARK
一、spark发展背景
1.为了更好的数据复用，所以创建了分布式内存抽象-RDD
2.RDD可以高效表达多种计算模型
3.通过lineage（血缘）可以实现高效容错
4.spark支持多种编程语言，支持scala的REPL
spark-client：driver在客户端机器上面
二、RDD的弹性解释
1.第一个是数据存储上，数据不再是存放在硬盘上，而是可以缓存在内存中，只有当内存不足的时候，才会存储在硬盘上，同时，数据的持久化，也支持硬盘，序列化后的内存存储，以及序列化后java对象的内存存储三种形式，每一种都比另一种占用更多的内存，但计算速度更快
2.第二个是选择把什么数据输出到硬盘上，spark会根据数据计算的血缘，来判断某一个RDD对于前置数据是宽依赖还是窄依赖，如果是宽依赖，意味着一个节点的故障，可能会导致大量的数据要进行重新计算，乃至数据网路传输的要求。那么，它就会把数据计算的中间结果存储到硬盘上
三、宽依赖和窄依赖
如果上游一个分区的数据全部流入下游的一个分区，那么就是窄依赖，否则就是宽依赖
窄依赖就是说数据在一个节点上面的内存里面就能完成所有计算。宽依赖就是说单个节点还不行，必须得走网络传输
788
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
