已关闭
Consumer API：
实际生产环境一般手动提交offset
props.put("enable.auto.commit","false")
每次消费完成后手动提交offset：
KafkaConsumer.commitAsync();
KafkaConsumer.commitSync();
KafkaConsumer.poll获取所有的数据，包含了各个分区里面的数据
创建一个线程安全的集合
Collections.singletonMap(topicPartition)
KafkaConsumer.commitSync()
第四种：自定义分区策略，不需要指定分区号，如果指定了分区号，还是会将数据发送到指定的分区里面去
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上面加载数据