第四种：自定义分区策略，不需要指定分区号，如果指定了分区号，还是会将数据发送到指定的分区里面去

implements Partitioner

bin/kafka-topics.sh回车

可以查看帮助文档的操作指令

kafka当中的数据是有顺序的，只是说的是分区里面的顺序，每个分区里面的数据都是有顺序的

保证kafka当中的数据消费也是有序的，生产是有序的。

设置一个分区（相当于单机版），不建议使用；

producerRecode：

如果指定了分区号，直接将数据发送到指定的分区里面去；

如果没有指定分区号，数据带了发送的key，通过key取还是从的决定数据究竟发送到哪一个分区里面去；

如果既没有指定分区号，也没有指定数据key，使用round-robin fashion 轮询策略

如果使用key作为分区的依据，key一定要是变化的，保证数据发送到不同的分区里面去

总结-分区方式：

第一种：既没有指定key，也没有指定分区号，使用轮询的方式；

第二种：指定数据key，使用key的hashcode码值来进行分区，一定要注意，key要变化；

第三种：指定分区号来进行分区；

第四种：自定义分区策略。

面试题：

kafka五个分区：由于某种原因，0、1、2分区里面的数据太多，3、4分区里面的数据太少，

一个topic有多个partition；

一个partition里面有多个segment文件段；

每个segment文件段里面包含了两个文件：

.index文件，存放的是.log文件数据的索引值，

.log文件，存放的是真实的数据，一旦.log文件达到1GB的时候，就会产生一个新的segment

kafka的基本架构：

生产者：producer主要负责生产数据到topic里面去

topic：虚拟的概念，某一类消息的主题，某一类消息都是存放在某一个topic当中

一个topic有多个partition：一个partition里面有多个segment段，每个segment默认1GB

一个segment：一个.index文件 + 一个.log文件

.log：存放用户真实的产生的数据

.index：存放的是.log文件的索引数据

消费者：consumer，主要就是消费topic里面的数据

consumer消费到哪一条数据需要进行记录：offset来进行记录，数据的偏移量，每条数据都有唯一的

kafka需要依赖zk保存一些节点信息，kafka紧耦合zookeeper

kafka当中数据消费的时候，消费者都需要指定属于哪一个消费组

任意时刻，一个分区里面的数据，只能被一个消费组里面的一个线程进行消费

如果调大分区的个数，可以增加分区数据的并行消费的粒度

问：kafka当中的数据消费出现延迟：

加大消费者线程数量，加大分区的个数

partition的个数与线程的个数：

partition个数=线程的个数，刚刚好，一个线程消费一个分区；

partition个数>线程的个数，有线程需要去消费多个分区里面的数据

partition<线程的个数，有线程闲置

kafka当中副本的策略：使用isr这种策略来维护一个副本列表

is synchronize replication：同步完成的副本列表

主分区：可以有多个副本，为了最大程度的同步完成数据，使用多个副本，每个副本都启动线程去复制主分区的数据，尽量保证副本当中的数据与主分区当中的数据一致

如果副本分区当中的数据与主分区当中的数据差别太大，将副本分区移除ISR列表；

如果副本分区的心跳时间比较久远，也会将副本分区移除ISR列表。

kafka使用scala语言编写，kafka是一个分布式、分区的，多副本的，多订阅者的日志系统

kafka是一个分布式的消息队列系统

分布式是由多个节点组成，一个节点就是一个服务器

在kafka当中节点叫做broker，一个节点就是一个broker，一个broker就是一个服务器

磁盘顺序读写

kafka应用场景：

流式处理：实时处理，数据从出现到产生，在一秒钟以内能够处理完成

流式计算：程序一旦启动，就会一直运行下去，一旦有数据，就能够马上被处理掉

生产者生产数分局到kafka里面去，然后通过一些实时处理的框架例如storm或者sparkstreaming或者flink等等实时处理的框架去处理kafka里面的数据

消息：在应用系统之间，传递的数据，叫做消息

应用系统之间：需要解耦合比较好

标准的消息队列实现：

主要基于pub/sub  publish 、subscribe发布与订阅模型

RabbitMQ:rabbit message queue

ActiveMQ:支持消息队列当中事务处理

RocketMQ:阿里开源的消息队列rocket

消息队列模型：主要是基于push、poll  推送与拉取

kafka不是标准的消息队列的实现

kafka：吞吐量非常高，而且消息处理速度非常快

消息队列的应用场景：

应用解耦

异步并行处理

限流削峰

消息驱动的系统

消息系统的两种模式：

点对点：两个人之间互相通信，都是点对点这种模型

发布与订阅：群聊，

kafka:消息队列

clouderamanager：图像化的界面管理工具，可以用于安装管理集群 

集群当中能够存储多少数据，取决于namenode的内存大小

hadoop联邦联盟

hadoop的基础环境增强：

hadoop的ha模式：

一般实际工作都要求7*24h的可用

oozie当中的定时任务

coordinator:oozie当中的协作器，主要适用于定时任务的执行，通过配置coordinator可以实现我们的任务

定时的任务调度

第一种：基于时间的任务调度

第二种：基于数据的任务调度

主要涉及三个配置文件

第一个：workflow.xml工作流于的定义

第二个：coordinator.xml定义定时任务，定时执行workflow.xml

oozie是分布式调度框架：

如果写一个hive的脚本，没法确定这个hive的脚本究竟会在哪一台机器上面执行

oozie启动失败解决方案

1.杀死进程kill -9  boostrap

2.进入哦哦紫萼目录，删除tmp/下所有内容或者pid文件夹 

 echo 1 >/proc/sys/vm/drop_caches

释放内存

解决process information unavailable

1.cd /tmp

2.rm -rf hsperfdata_impala

oozie：

任务调度的框架，调度过程主要是通过启动一个mr的任务，来执行其他的任务

定义语言使用xml语言

架构：

1.client客户端，提交任务到oozie的服务端

2.oozie-server服务端，运行一个Tomcat实例，主要用于接收客户端提交的任务

3.db数据库，服务端将客户端提交的任务都保存在db里面，默认使用的db是h2

oozie的主要三大组件

1.workflow定义工作流，从哪一个开始执行，到哪一个最终结束，最后定义完成之后，形成一个有向无环图DAG;

2.Coordinator协作器，就是一个任务调度的模块，可以设置定时任务

3.bundle捆绑器，可以将多个coordinator绑定到一起

impala：

是一个SQL查询工具

组件：

主节点：

impala-statestore：状态存储区，主要存储SQL执行的状态、进度等信息；

impala-catalog：存储impala的元数据信息

从节点：

impala-server：主要负责任务的计算

基本使用：

不进入impala-shell的一些常见参数

impala-shell -q  “select * from xxx”

impala-shell -f  执行xxx.sql脚本

impala-shell -f  全量刷新元数据信息，不推荐使用

进入impala-shell的一些常见信息

refresh dbname.tablename  

      刷新某张表的元数据信息，适用于表已经存在的情况，例如分区信息改变

invalidate metadata

     刷新元数据信息，全量刷新元数据信息，适用于hive当中新建数据库或者数据库表的情况

hive当中新建的数据库或者数据库表，需要刷新元数据信息，impala当中新建等等数据库与数据库表不需要刷新元数据信息，主要通过catalog来实现

hue：hadoop user experience

主要用于与其他框架集成，做到可视化，允许我们通过浏览器界面操作其他框架

distCp 从一个集群上面拷贝数据到另一个集群上面去

hue的主体架构：

UI:前端的管理界面

hue server：运行的一个Tomcat

hueDB：数据库存储，存放提交的一些任务信息，保存一些执行信息

hue的

impala只支持从hdfs上面加载数据

impala-shell  -q "select * from xxx"

    l