大数据平台学习及相关技术介绍可参考:https://zhuanlan.zhihu.com/p/26545566
大数据工程师的日常工作内容:https://www.zhihu.com/question/299830109/answer/1788219176
目录
HDFS
1.基本操作:
2.Hdfs的优缺点有哪些?
(1)HDFS的优点
(2)HDFS的缺点
3.HDFS整体架构介绍
DataNode的工作机制?
什么是机架感知?什么时候会使用机架感知?
4.HDFS数据写入(上传)流程是怎样的?
5.HDFS数据读取(下载)流程是怎样的?
hdfs-site.xml的3个主要属性是?
NN和2NN工作机制
MR
MapReduce工作流程
YARN
YARN的核心组件
YARN工作流程
YARN默认的调度器分别是什么,及他们区别:
Hive
1、Hive架构
2、三大组件
3.Hive 内部表和外部表区别?:
4.Hive与关系型数据库区别:
5.order by ,sort by , distribute by , cluster by 的区别?
6.hive函数:
窗口函数:
常用日期函数
日期处理函数实例
常用取整函数
7.Hive的数据管理:
hive分区
hive分桶:
8.Hive实战数据分析
Sqoop实战
一. Mysql数据导入HDFS上.
1. 全量导入:
2.增量导入:
3.减量导入:
4.SQL语句查找导入HDFS
二. Mysql数据导入Hive上.
三.Sqoop的数据导出
Hbase--分布式列存储NOSQL数据库
散列原则:
有序原则:
Hbase shell 基础
Flume实战
1、采集目录到HDFS
2、采集文件到HDFS
更多source和sink组件:
Kafka介绍
Apache Kafka简介
kafka常用术语
Kafka架构
kafka分区和副本机制
Kafka的优势
查看所有命令 hadoop fs
1、查看所有目录及其文件 hadoop fs -ls /
2、hdfs文件系统创建目录 hadoop fs -mkdir /input(用于测试代码)
2.1、hdfs文件系统创建目录(批量)
hadoop fs -mkdir -p /inout/tmp 在input文件夹内创建tmp文件夹
3、hdfs文件系统创建文件 hadoop fs -touchz /a.txt
4、hdfs文件系统删除文件
hadoop fs -rmr /a.txt
hadoop fs -rmr -skipTrash /a.txt(跳过回收站彻底删除)
5.hdfs上传本地文件 (注意:必须先建好hdfs上目录再put)
hadoop fs -put t.txt /test 将本地文件t.txt上传至hdfs上test文件夹内;
hadoop fs -put /a.txt
6.查看hdfs文件内容
hadoop fs -cat /a.txt
hadoop fs -tail /a.txt (从尾部开始看)
hadoop fs -text /a.txt (查看二进制数据)
7、hdfs下载文件
hadoop fs -get /a.txt .
注意最后有一点,这个.代表下载到本地命令行所在目录;
8、递归删除目录
hadoop fs -rmr /input/tmp
9、查看hdfs文件的大小
hadoop fs -du -h /b.txt
-du -s或者-du -h
10、查看hdfs文件行数
hadoop fs -cat /b.txt | wc -l
最后是字母l
cat或者text 都可以
实战:
查看集群ip情况 cat /etc/hosts
查看hadoop版本
echo $HADOOP_HOME/
which $HADOOP_HOME/
运行集群脚本
sh -x run.sh
运行run脚本,最好是 -X调试模式
高容错性
①:数据自动保存多个副本。它通过增加副本的形式,提高容错性
②:某一个副本丢失以后,它可以自动恢复
适合批处理即就近原则
①:移动计算而非非数据,数据位置暴露给计算机框架
②:本地化,数据不移动,代码(任务)移动。
适合处理大数据
①:数据规模:能够处理数据规模达到GB、TB、甚至PB级别的数据
②:文件规模:能够处理百万规模以上的文件数量,数量相当之大
可构建在廉价机器上,通过多副本机制,提高可靠性
不适合低延时数据访问,比如毫秒级的存储数据,是做不到的。寻址时间长,适合读取大文件,低延迟与高吞吐率。
不适合小文件存储
占用NameNode大量内存,寻找时间超过读取时间
不支持并发写入,文件随机修改
①:一个文件只能有一个写,不允许多个线程同时写
②:仅支持数据append(追加),不支持文件的修改
1)Client:就是客户端。
(1)文件切分。文件上传HDFS的时候,Client将文件切分成一个一个的Block,然后进行存储;
(2)与NameNode交互,获取文件的位置信息;
(3)与DataNode交互,读取或者写入数据;
(4)Client提供一些命令来管理HDFS,比如启动或者关闭HDFS;
(5)Client可以通过一些命令来访问HDFS;
2)NameNode:就是Master,它是一个主管、管理者。
(1)管理HDFS的名称空间;namespace
(2)管理数据块(Block)映射信息;
(3)配置副本策略(默认);3
(4)处理客户端读写请求。
3) DataNode:就是Slave。NameNode下达命令,DataNode执行实际的操作。
(1)存储实际的数据块;
(2)执行数据块的读/写操作。
4) SecondaryNameNode:并非NameNode的热备。当NameNode挂掉的时候,它并不能马上替换NameNode并提供服务。
(1)辅助NameNode,分担其工作量;
(2)定期合并Fsimage和Edits,并推送给NameNode;
(3)在紧急情况下,可辅助恢复NameNode。
一个数据块在DataNode上以文件形式存储在磁盘上,包括两个文件,一个是数据本身,一个是元数据包括数据块的长度,块数据的校验和,以及时间戳。
DataNode启动后向NameNode注册,通过后,周期性(1小时)的向NameNode上报所有的块信息。
心跳是每3秒一次,心跳返回结果带有NameNode给该DataNode的命令如复制块数据到另一台机器,或删除某个数据块。如果超过10分钟没有收到某个DataNode的心跳,则认为该节点不可用。
通俗的来说就是NN(NameNode)通过读取我们的配置来配置各个节点所在的机架信息,数据的流水线复制和HDFS复制副本时候。
一 HDFS读流程概括:
client跟namenode通信查询元数据,namenode通过查询元数据,找到文件块所在的datanode服务器
挑选一台datanode(就近原则,然后随机)服务器,请求建立socket流
datanode开始发送数据(从磁盘里面读取数据放入流,以packet为单位来做校验,大小为64k)
客户端以packet为单位接收,现在本地缓存,然后写入目标文件
详细流程
Client 发起文件上传请求,通过 RPC 与 NameNode 建立通讯,NameNode检查目标文件是否已存在,父目录是否存在,返回是否可以上传;
Client 请求第一个 block 该传输到哪些 DataNode 服务器上;
NameNode 根据配置文件中指定的备份数量及副本放置策略进行文件分配,返回可用的 DataNode 的地址,如A,B,C
Client 请求 3 台 DataNode 中的一台 A 上传数据(本质上是一个 RPC 调用,建立 pipeline),A 收到请求会继续调用 B,然后 B 调用 C,将整个pipeline 建立完成,后逐级返回 client;
Client 开始往 A 上传第一个 block(先从磁盘读取数据放到一个本地内存缓存),以 packet 为单位(默认 64K),A 收到一个 packet 就会传给 B,B 传给 C;A 每传一个 packet 会放入一个应答队列等待应答
数据被分割成一个个 packet 数据包在 pipeline 上依次传输,在pipeline 反方向上,逐个发送 ack(命令正确应答),最终由 pipeline中第一个 DataNode 节点 A 将 pipeline ack 发送给 client;
当一个 block 传输完成之后,client 再次请求 NameNode 上传第二个block 到服务器
HDFS写流程概括
客户端跟namenode通信请求上传文件,namenode检查目标文件是否已存在,父目录是否存在,用户是否有权限等
namenode返回是否可以上传
client请求第一个 block该传输到哪些datanode服务器上
namenode返回3个datanode服务器ABC
client请求3台dn中的一台A上传数据(本质上是一个RPC调用,建立pipeline),A收到请求会继续调用B,然后B调用C,将整个pipeline建立完成,逐级返回客户端
client开始往A上传第一个block(先从磁盘读取数据放到一个本地内存缓存),以packet为单位,A收到一个packet就会传给B,B传给C;A每传一个packet会放入一个应答队列等待应答
当一个block传输完成之后,client再次请求namenode上传第二个block的服务器。
写流程详细:
Client 发起文件读取请求通过RPC与NameNode建立通讯,nameNode检查文件位置,来确定请求文件 block 所在的位置
NameNode会视情况返回文件的部分或者全部block列表,对于每个block,NameNode 都会返回含有该 block 副本的 DataNode 地址;
这些返回的 DN 地址,会按照集群拓扑结构得出 DataNode 与客户端的距离,然后进行排序,排序两个规则:网络拓扑结构中距离 Client 近的排靠前;心跳机制中超时汇报的 DN 状态为 STALE,这样的排靠后;
Client 选取排序靠前的 DataNode 来读取 block,如果客户端本身就是DataNode,那么将从本地直接获取数据
底层上本质是建立 Socket Stream(FSDataInputStream),重复的调用父类 DataInputStream 的 read 方法,直到这个块上的数据读取完毕;
当读完列表的 block 后,若文件读取还没有结束,客户端会继续向NameNode 获取下一批的 block 列表;
读取完一个 block 都会进行 checksum 验证,如果读取 DataNode 时出现错误,客户端会通知 NameNode,然后再从下一个拥有该 block 副本的DataNode 继续读。
Read 方法是并行的读取 block 信息,不是一块一块的读取;NameNode 只是返回Client请求包含块的DataNode地址,并不是返回请求块的数据;最终读取来所有的 block 会合并成一个完整的最终文件。
dfs.name.dir→决定的是元数据存储的路径和DFS的存储方式(磁盘或远端)
dfs.data.dir→决定的是数据存储的路径
fs.checkpoint.dir→用于 SecondaryNameNode
1. 第一阶段:NameNode启动
第一次启动NameNode格式化后,创建Fsimage和Edits文件。如果不是第一次启动,直接加载编辑日志和镜像文件到内存。
客户端对元数据进行增删改的请求。
NameNode记录操作日志,更新滚动日志。
NameNode在内存中对数据进行增删改。
2. 第二阶段:Secondary NameNode工作
Secondary NameNode询问NameNode是否需要CheckPoint。直接带回NameNode是否检查结果。
Secondary NameNode请求执行CheckPoint。
NameNode滚动正在写的Edits日志。
将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode。
Secondary NameNode加载编辑日志和镜像文件到内存,并合并。
生成新的镜像文件fsimage.chkpoint。
拷贝fsimage.chkpoint到NameNode。
NameNode将fsimage.chkpoint重新命名成fsimage。
NN和2NN工作机制详解:
Fsimage:NameNode内存中元数据序列化后形成的文件。
Edits:记录客户端更新元数据信息的每一步操作(可通过Edits运算出元数据)。
NameNode启动时,先滚动Edits并生成一个空的edits.inprogress,然后加载Edits和Fsimage到内存中,此时NameNode内存就持有最新的元数据信息。Client开始对NameNode发送元数据的增删改的请求,这些请求的操作首先会被记录到edits.inprogress中(查询元数据的操作不会被记录在Edits中,因为查询操作不会更改元数据信息),如果此时NameNode挂掉,重启后会从Edits中读取元数据的信息。然后,NameNode会在内存中执行元数据的增删改的操作。
由于Edits中记录的操作会越来越多,Edits文件会越来越大,导致NameNode在启动加载Edits时会很慢,所以需要对Edits和Fsimage进行合并(所谓合并,就是将Edits和Fsimage加载到内存中,照着Edits中的操作一步步执行,最终形成新的Fsimage)。SecondaryNameNode的作用就是帮助NameNode进行Edits和Fsimage的合并工作。
SecondaryNameNode首先会询问NameNode是否需要CheckPoint(触发CheckPoint需要满足两个条件中的任意一个,定时时间到和Edits中数据写满了)。直接带回NameNode是否检查结果。SecondaryNameNode执行CheckPoint操作,首先会让NameNode滚动Edits并生成一个空的edits.inprogress,滚动Edits的目的是给Edits打个标记,以后所有新的操作都写入edits.inprogress,其他未合并的Edits和Fsimage会拷贝到SecondaryNameNode的本地,然后将拷贝的Edits和Fsimage加载到内存中进行合并,生成fsimage.chkpoint,然后将fsimage.chkpoint拷贝给NameNode,重命名为Fsimage后替换掉原来的Fsimage。NameNode在启动时就只需要加载之前未合并的Edits和Fsimage即可,因为合并过的Edits中的元数据信息已经被记录在Fsimage中。
Application运行流程:
mr程序最先启动MRAppMaster(AM),AM启动后根据本次application的信息,计算出需要的maptask实例数量,然后向RM申请机器启动相应数量的maptask进程,RM通过心跳感知目前集群container(容器)的工作繁忙情况,分配相应的container资源,相应containers的nodemanagr在各自节点上启动container。
1、inputformat:MR框架基础类之一,包含数据分割(Data Splits)和记录读取器(Record Reader)两部分。每个split包含后一个Block中开头部分的数据可以解决记录跨Block问题,每读取一条记录,调用一次map函数。
2、Map:每一个切片对应一个map,map输出的数据,放入环形溢写缓冲区,缓冲区默认100M,达到80M进行溢写,写入到本地文件。
3、Shuffle:shuffle是MapReduce计算框架的核心,包括了Partion, Sort, Spill, Meger, Combiner, Copy, Memery, Disk等分组动作;
3.1、partition对map的内容根据kv对进行分区
3.2、sort(快速排序),溢写到磁盘
3.3、数据合并combiner(①减少数据写入磁盘的数据量 ② 减少网络传输的数据量 , 数据压缩)
AM监控到所有maptask进程任务完成之后,会根据客户指定的参数启动相应数量的reducetask进程,并告知reducetask进程要处理的数据范围(数据分区)。Reducetask进程启动之后,根据MRAppMaster告知的待处理数据所在位置,从若干台maptask运行所在机器上获取到若干个maptask输出结果文件,并在本地进行重新归并排序,然后按照相同key的KV为一个组,调用客户定义的reduce()方法进行逻辑运算,并收集运算输出的结果KV,然后调用客户指定的outputformat将结果数据输出到外部存储。
3.4、fetch (通过RM,reduce找到指定的map主动fetch数据)
3.5、溢写,排序(归并排序)
3.6、merger(数据合并①减少数据量 ② 提高执行效率)
4、reduce(汇总,聚合的过程)
5、output(hdfs)
在Shuffle过程中涉及两次排序:快速排序和归并排序;
快速排序:sort阶段,环形缓冲区达到80%时,对数据进行快速排序,排序按照key的索引进行字典顺序排序,然后开始进行溢写,从内存缓冲区不断溢出本地磁盘文件,可能会溢出多个文件 。
(1)算法步骤
1.从数列中挑出一个元素,称为 “基准”(pivot);
2.重新排序数列,所有元素比基准值小的摆放在基准前面,所有元素比基准值大的摆在基准的后面(相同的数可以到任一边)。
在这个分区退出之后,该基准就处于数列的中间位置。这个称为分区(partition)操作;
3. 递归地(recursive)把小于基准值元素的子数列和大于基准值元素的子数列排序;
归并排序在小的文件merge成大文件时采用,归并排序在map端和reduce端都可能出现。
算法步骤:
1.申请空间,使其大小为两个已经排序序列之和,该空间用来存放合并后的序列;
2.设定两个指针,最初位置分别为两个已经排序序列的起始位置;
3.比较两个指针所指向的元素,选择相对小的元素放入到合并空间,并移动指针到下一位置;
4.重复步骤 3 直到某一指针达到序列尾;
5.将另一序列剩下的所有元素直接复制到合并序列尾。
MR流程中涉及的快排、归并排序,可参考以下文章
https://blog.csdn.net/weixin_45666566/article/details/105383306
解决方案:首先是将这一天,并且是访问百度的日志中的IP取出来,逐个写入到一个大文件中。注意到IP是32位的,最多有个2^32个IP。同样可以采用映射的方法,比如模1000,把整个大文件映射为1000个小文件,再找出每个小文中出现频率最大的IP(可以采用hash_map进行频率统计,然后再找出频率最大的几个)及相应的频率。然后再在这1000个最大的IP中,找出那个频率最大的IP,即为所求。
解决方案:顺序读文件中,对于每个词x,取hash(x)%5000,然后按照该值存到5000个小文件(记为x0,x1,...x4999)中。这样每个文件大概是200k左右。如果其中的有的文件超过了1M大小,还可以按照类似的方法继续往下分,直到分解得到的小文件的大小都不超过1M。 对每个小文件,统计每个文件中出现的词以及相应的频率(可以采用trie树/hash_map等),并取出出现频率最大的100个词(可以用含100个结点的最小堆),并把100个词及相应的频率存入文件,这样又得到了5000个文件。下一步就是把这5000个文件进行归并(类似与归并排序)的过程了。
方案1: 顺序读取10个文件,按照hash(query)%10的结果将query写入到另外10个文件(记为)中。这样新生成的文件每个的大小大约也1G(假设hash函数是随机的)。 找一台内存在2G左右的机器,依次对用hash_map(query, query_count)来统计每个query出现的次数。利用快速/堆/归并排序按照出现次数进行排序。将排序好的query和对应的query_cout输出到文件中。这样得到了10个排好序的文件(记为)。
对这10个文件进行归并排序(内排序与外排序相结合)。
方案2: 一般query的总量是有限的,只是重复的次数比较多而已,可能对于所有的query,一次性就可以加入到内存了。这样,我们就可以采用trie树/hash_map等直接来统计每个query出现的次数,然后按出现次数做快速/堆/归并排序就可以了。
方案3: 与方案1类似,但在做完hash,分成多个文件后,可以交给多个文件来处理,采用分布式的架构来处理(比如MapReduce),最后再进行合并。
方案1:可以估计每个文件安的大小为5G×64=320G,远远大于内存限制的4G。所以不可能将其完全加载到内存中处理。考虑采取分而治之的方法。通读文件a,对每个url求取hash(url)%1000,然后根据所取得的值将url分别存储到1000个小文件(记为a0,a1,...,a999)中。这样每个小文件的大约为300M。通读文件b,采取和a相同的方式将url分别存储到1000小文件(记为b0,b1,...,b999)。这样处理后,所有可能相同的url都在对应的小文件(a0vsb0,a1vsb1,...,a999vsb999)中,不对应的小文件不可能有相同的url。然后我们只要求出1000对小文件中相同的url即可。求每对小文件中相同的url时,可以把其中一个小文件的url存储到hash_set中。然后遍历另一个小文件的每个url,看其是否在刚才构建的hash_set中,如果是,那么就是共同的url,存到文件里面就可以了。
方案2:如果允许有一定的错误率,可以使用Bloom filter,4G内存大概可以表示340亿bit。将其中一个文件中的url使用Bloom filter映射为这340亿bit,然后挨个读取另外一个文件的url,检查是否与Bloom filter,如果是,那么该url应该是共同的url(注意会有一定的错误率)。
方案1:申请512M的内存,一个bit位代表一个unsigned int值。读入40亿个数,设置相应的bit位,读入要查询的数,查看相应bit位是否为1,为1表示存在,为0表示不存在。
方案2:因为2^32为40亿多,所以给定一个数可能在,也可能不在其中;这里我们把40亿个数中的每一个用32位的二进制来表示假设这40亿个数开始放在一个文件中。然后将这40亿个数分成两类: 1.最高位为0 2.最高位为1 并将这两类分别写入到两个文件中,其中一个文件中数的个数<=20亿,而另一个>=20亿(这相当于折半了);与要查找的数的最高位比较并接着进入相应的文件再查找再然后把这个文件为又分成两类: 1.次最高位为0 2.次最高位为1,并将这两类分别写入到两个文件中,其中一个文件中数的个数<=10亿,而另一个>=10亿(这相当于折半了); 与要查找的数的次最高位比较并接着进入相应的文件再查找。 ....... 以此类推,就可以找到了,而且时间复杂度为O(logn),方案2完。
附:这里,再简单介绍下,位图方法: 使用位图法判断整形数组是否存在重复 判断集合中存在重复是常见编程任务之一,当集合中数据量比较大时我们通常希望少进行几次扫描,这时双重循环法就不可取了。位图法比较适合于这种情况,它的做法是按照集合中最大元素max创建一个长度为max+1的新数组,然后再次扫描原数组,遇到几就给新数组的第几位置上1,如遇到5就给新数组的第六个元素置1,这样下次再遇到5想置位时发现新数组的第六个元素已经是1了,这说明这次的数据肯定和以前的数据存在着重复。这种给新数组初始化时置零其后置一的做法类似于位图的处理方法故称位图法。它的运算次数最坏的情况为2N。如果已知数组的最大值即能事先给新数组定长的话效率还能提高一倍。
1.RM(ResourceManager)资源管理器
RM是一个全局的资源管理器,负责整个系统的资源管理和分配。
它主要由两个组件构成:调度器(Scheduler)和应用程序管理器(Applications Manager,ASM),通俗讲是用于管理NodeManager节点的资源,包括cup、内存等。
2.NodeManager(NM)+ (DataNode 硬盘 CPU 内存)
NM是每个节点上的资源和任务管理器,一方面,它会定时地向RM汇报本节点上的资源使用情况和各个Container的运行状态;另一方面,它接收并处理来自AM的Container启动/停止等各种请求。
3.Applications Manager(应用程序管理器)new ApplicationMaster 监控所有job的任务运行结果的监控 --> 客户端
负责管理整个系统中所有应用程序,包括应用程序提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动它等。是AM的AM。
4.ApplicationMaster(AM)job过程监控
ApplicationMaster 管理在YARN内运行的每个应用程序实例。每个应用程序对应一个ApplicationMaster。ApplicationMaster 负责协调来自 ResourceManager 的资源,并通过 NodeManager 监视容器的执行和资源使用(CPU、内存等的资源分配),通俗讲是管理发起的任务,随着任务创建而创建,任务的完成而结束。
5.Container(重要) --> 资源接口 --> map reduce mapContainer reduceContainer spark --> sparkContainer
Container是YARN中的资源抽象,它封装了NodeManager节点上的多维度资源,如内存、CPU、磁盘、网络等,当AM向RM申请资源时,RM为AM返回的资源便是用Container表示的。YARN会为每个任务分配一个Container,且该任务只能使用该Container中描述的资源。(Container的具有优先级别,包括:队列 普通用户 VIP会员, 权重高的一定是先执行)
概括:
步骤1:用户将应用程序提交到 ResourceManager 上;
步骤2:ResourceManager 为应用程序 ApplicationMaster 申请资源,并与某个 NodeManager 通信启动第一个 Container,以启动ApplicationMaster;
步骤3:ApplicationMaster 与 ResourceManager 注册进行通信,为内部要执行的任务申请资源,一旦得到资源后,将于 NodeManager 通信,以启动对应的 Task;
步骤4:所有任务运行完成后,ApplicationMaster 向 ResourceManager 注销,整个应用程序运行结束。
详细流程:
- client向RM提交应用程序,其中包括启动该应用的ApplicationMaster的必须信息,例如ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等
- ResourceManager启动一个NodeManager的一个container用于运行ApplicationMaster
- 启动中的ApplicationMaster向ResourceManager注册自己,启动成功后与RM保持心跳
- ApplicationMaster向ResourceManager发送请求,申请相应数目的container
- 申请成功的container,由ApplicationMaster进行初始化。container的启动信息初始化后,AM与对应的NodeManager通信,要求NM启动container
- NM启动container
- container运行期间,ApplicationMaster对container进行监控。container通过RPC协议向对应的AM汇报自己的进度和状态等信息
- 应用运行结束后,ApplicationMaster向ResourceManager注销自己,并允许属于它的container被收回
YARN调度器主要分为三类:
- 1、FIFO :先进先出,同一个队列中现先提交的先执行,后面等待
- 2、Capacity Scheduler(容量调度器): 允许创建多个任务队列,每个队列使用所有资源的一部分。多个任务队列可 以同时执行。但是一个队列内部还是先进先出。
- 3、Fair Scheduler(公平调度): 第一个程序在启动时可以占用其他队列资源(100%占用),当其他队列有 任务提交时,占用资源的队列需要将资源还给该任务。还资源的时候,效率 比较慢。
参考我的这篇文章:https://blog.csdn.net/qq_36816848/article/details/113106315
Hive:基于Hadoop一个数据仓库工具,可以将结构化的数据文件映射为一张数据库表,并提供简单的 sql 查询功能,可以将 sql 语句转换为 MapReduce 任务进行运行。适合数据仓库的统计分析。
1、用户接口:包括 CLI、JDBC/ODBC、WebGUI。
CLI(command line interface)为 shell 命令行,进行交互式执行SQL:直接与Driver进行交互。CLI启动的时候,会同时启动一个 Hive 副本
JDBC/ODBC 驱动是 Hive 的 JAVA 实现,作为JAVA的API:JDBC是通过Thift Server来接入,然后发送给Driver
WebGUI 是通过浏览器访问 Hive。
HiveServer2基于Thrift, 允许远程客户端使用多种编程语言如Java、Python向Hive提交请求
2、Metastore:存储元数据
Hive 将元数据存储在数据库中,如MySQL、derby
Hive 中的元数据包括表的名字、表的列、分区及其属性、表的属性(是否为外部表等)、表的数据所在目录等。
3、Driver(驱动模块):包括解释器、编译器、优化器、执行器
通过该模块对输入进行解析编译,对需求的计算进行优化,然后按照指定的步骤进行(通常启动多个MR任务来执行)
解释器、编译器、优化器、执行器完成 HQL 查询语句从词法分析、语法分析、编译、优化以及查询计划的生成。生成的查询计划存储在 HDFS 中,并在随后由 MapReduce 调用执行
(1)是否直接通过external
(2)删除外部表,元数据得到删除,但是数据不会真正删除,针对内部表,元数据和数据都被删除
(3)在导入数据到外部表,数据并没有移动到自己的数据仓库目录下,也就是说外部表中的数据并不是由它自己来管理的!而内部表则不一样
注意:内部表和外部表场景:
内部表:逻辑处理的中间过程生成的中间表,或者一些临时表,直接删除即可
外部表:可以用户存储一些日志信息,数据不会被删除
Hive表示纯逻辑,只有表定义,不存数据。读多写少,不支持数据的改写和删除
1.Order by会对所给的全部数据进行全局排序,只启动一个reduce来处理。
Sort by是局部排序,它可以根据数据量的大小启动一到多个reducer来工作,并在每个reduce中单独排序。
3.Distribute by 类似于mr中的partition,采用hash算法,在map端将查询结果中hash值相同的结果分发到对应的reduce中,结合sort by使用。
4.Cluster by 可以看作是distribute by 和sort by的结合,当两者后面所跟的字段列名相同时,效果就等同于使用cluster by,但是cluster by最终的结果只能是降序,无法指定升序和降序。
注:不带count,sum这些聚合函数的,都不会走mapreduce。
UDF:普通函数:1对1的关系,select语句,例如:数据格式
UDAF:聚合函数:多对1的关系,结合group by联合使用
UDTF:生成函数:1对多
用 UDF 函数解析公共字段;用 UDTF 函数解析事件字段。
自定义 UDF:继承 UDF,重写 evaluate 方法
自定义 UDTF:继承自 GenericUDTF,重写 3 个方法:initialize(自定义输出的列名和类型),
process(将结果返回 forward(result),close 。
为什么要自定义 UDF/UDTF,因为自定义函数,可以自己埋点 Log 打印日志,出错或者数据异常,方便调试。
Hive命令行窗口查看函数定义 :desc function 函数名;
HIve窗口函数实战可参考:https://blog.csdn.net/Abysscarry/article/details/81408265
unix_timestamp:返回当前或指定时间的时间戳
from_unixtime:将时间戳转为日期格式
current_date:当前日期
current_timestamp:当前的日期加时间
to_date:抽取日期部分
year:获取年
month:获取月
day:获取日
hour:获取时
minute:获取分
second:获取秒
weekofyear:当前时间是一年中的第几周
dayofmonth:当前时间是一个月中的第几天
months_between: 两个日期间的月份
add_months:日期加减月
datediff:两个日期相差的天数
date_add:日期加天数
date_sub:日期减天数
last_day:日期的当月的最后一天
1)date_format函数(根据格式整理日期)
hive (gmall)> select date_format('2019-02-10','yyyy-MM');
2019-02
2)date_add函数(加减日期)
hive (gmall)> select date_add('2019-02-10',1);
2019-02-11
hive (gmall)> select date_add('2019-02-10',-1);
2019-02-09
3)next_day函数
(1)取当前天的下一个周一
hive (gmall)> select next_day('2019-02-12','MO');
2019-02-18
说明:星期一到星期日的英文(Monday,Tuesday、Wednesday、Thursday、Friday、Saturday、Sunday)
(2)取当前周的周一
hive (gmall)> select date_add(next_day('2019-02-12','MO'),-7);
2019-02-11
4)last_day函数(求当月最后一天日期)
hive (gmall)> select last_day('2019-02-10');
2019-02-28
round: 四舍五入
ceil: 向上取整
floor: 向下取整
常用字符串操作函数
upper: 转大写
lower: 转小写
length: 长度
trim: 前后去空格
lpad: 向左补齐,到指定长度
rpad: 向右补齐,到指定长度
regexp_replace: SELECT regexp_replace('100-200', '(\\d+)', 'num') ;
使用正则表达式匹配目标字符串,匹配成功后替换!
集合操作
size: 集合中元素的个数
map_keys: 返回map中的key
map_values: 返回map中的value
array_contains: 判断array中是否包含某个元素
sort_array: 将array中的元素排序
1)内表外表(2)Partition辅助查询,缩小查询范围,加快数据检索速度(3)Bucket 控制reduce数量
参考我的这篇文章:https://mp.csdn.net/editor/html/113782028
分桶是将整个数据内容按照某列属性值去hash值进行区分,对取得的hash再做模运算(columnValue.hashCode % 桶数),具有相同结果的数据进入同一个文件中。
参考我的这两篇文章:https://blog.csdn.net/qq_36816848/article/details/106665176
将mysql表中全部数据都导入HDFS,如果HDFS中存在这个目录的话就会报错,默认存储的HDFS目录是 /user/root/XXX.
bin/sqoop import (在sqoop的安装目录内,import表名是导入)
--connect jdbc:mysql://192.168.52.130:3306/userdb (连接:协议:数据库类型://ip地址:端口号/数据库)
--username root (用户名 root)
--password 123456 (密码 123456)
--table emp (表 emp)
--m 1 (--num-mappers:使用几个mapper,写1就可以)
若要导入到HDFS指定目录下,并指定字段之间的分隔符:
使用参数 --target-dir 来指定导出目的地,
使用参数 --delete-target-dir 来判断导出目录是否存在,如果存在就删掉.
使用参数 --fields-terminated-by '\t' 使用''\t''来切割字段,sqoop默认是使用','逗号进行分割的.
bin/sqoop import (在sqoop的安装目录内,import表名是导入)
--connect jdbc:mysql://192.168.52.130:3306/userdb (连接:协议:数据库类型://ip地址:端口号/数据库)
--username root (用户名 root)
--password 123456 (密码 123456)
--table emp (表 emp)
--delete-target-dir (如果指定目录存在就删除它)
--target-dir /sqoop/emp (导入到指定目录)
--fields-terminated-by '\t' (指定字段分割符为\t)
--m 1 (--num-mappers:使用几个mapper,写1就可以)
将数据库中某一字段,增加的导入,在HDFS上单独形成一个文件.
注意:增量导入的时候,一定不能加参数--delete-target-dir否则会报错
bin/sqoop import
--connect jdbc:mysql://192.168.52.130:3306/myhive
--username root
--password 123456
--table emp
--incremental append (表明增量导入)
--check-column id (检查哪个字段,这里检查的是mysql数据库表中的id字段)
--last-value 4 (id字段最后一个id是4,那增量导入的话就是从id=5开始往后导入)
--m 1
设置where条件,通过条件可以判断减少的数据或增加的数据,控制更加灵活一些,例如可以通过表创建时间来判断数据是哪一天生成的等,每个表均设置3个字段,create_time(表创建时间),update_time(表更新时间),is_delete(是否删除)
注意:where条件的地方需要使用“”双引号引起来,否则where条件失效
bin/sqoop import \
--connect jdbc:mysql://192.168.52.130:3306/userdb \
--username root \
--password admin \
--table emp \
--incremental append \
--where "create_time > '2019-02-14 00:00:00' and is_delete='1' and create_time < '2019-02-14 23:59:59'" \
--target-dir /sqoop/incement \
--check-column id \
--m 1
我们还可以通过 –query参数来指定我们的sql语句,通过sql语句来过滤我们的数据进行导入
bin/sqoop import
--connect jdbc:mysql://192.168.52.130:3306/userdb
--username root
--password 123456
--delete-target-dir
--query 'select phno from emp_conn where 1=1 and $CONDITIONS'
--target-dir /sqoop/emp_conn
--m 1
注意事项:
使用sql语句来进行查找是不能加参数--table
并且必须要添加where条件,
并且where条件后面必须带一个$CONDITIONS 这个字符串,
并且这个sql语句必须用单引号,不能用双引号.
1.将我们mysql表当中的数据直接导入到hive表中的话,需要将hive的一个叫做hive-exec-1.1.0-cdh5.14.0.jar的jar包拷贝到sqoop的lib目录下
cp /export/servers/hive-1.1.0-cdh5.14.0/lib/hive-exec-1.1.0-cdh5.14.0.jar /export/servers/sqoop-1.4.6-cdh5.14.0/lib/
2.将我们mysql当中的数据导入到hive表当中来,需要准备hive数据库与表
hive (default)> create database sqooptohive;
hive (default)> use sqooptohive;
hive (sqooptohive)> create external table emp_hive(id int,name string,deg string,salary int ,dept string) row format delimited fields terminated by '\t';
3.导入语句
bin/sqoop import
--connect jdbc:mysql://192.168.52.130:3306/userdb
--username root
--password 123456
--table emp
--fields-terminated-by '\t' (字段之间的分隔符)
--hive-import (将数据从mysql数据库中导入到hive表中)
--hive-table qooptohive.emp_hive (后面接要创建的hive表,数据库中的某个表,使用"."连接)
--hive-overwrite (覆盖掉在hive表中已经存在的数据)
--delete-target-dir
--m 1
注意:我们还可以导入关系表到hive并自动创建hive表,导入
bin/sqoop import
--connect jdbc:mysql://192.168.52.130:3306/userdb
--username root
--password 123456
--table emp_conn
--hive-import
--hive-database sqooptohive (--hive-database 后面直接接数据库名)
--m 1
将数据从HDFS把文件导出到mysql数据库,导出前,目标表必须存在于目标数据库中。
数据是在HDFS当中的如下目录/sqoop/emp,数据内容如下
1201,gopal,manager,50000,TP,2018-06-17 18:54:32.0,2018-06-17 18:54:32.0,1
1202,manisha,Proof reader,50000,TP,2018-06-15 18:54:32.0,2018-06-17 20:26:08.0,1
1203,khalil,php dev,30000,AC,2018-06-17 18:54:32.0,2018-06-17 18:54:32.0,1
1204,prasanth,php dev,30000,AC,2018-06-17 18:54:32.0,2018-06-17 21:05:52.0,0
1205,kranthi,admin,20000,TP,2018-06-17 18:54:32.0,2018-06-17 18:54:32.0,1
1.创建mysql表
CREATE TABLE `emp_out` (
`id` INT(11) DEFAULT NULL,
`name` VARCHAR(100) DEFAULT NULL,
`deg` VARCHAR(100) DEFAULT NULL,
`salary` INT(11) DEFAULT NULL,
`dept` VARCHAR(10) DEFAULT NULL,
`create_time` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
`update_time` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`is_delete` BIGINT(20) DEFAULT '1'
) ENGINE=INNODB DEFAULT CHARSET=utf8;
2.执行导出命令:通过export来实现数据的导出,将hdfs的数据导出到mysql当中去
bin/sqoop export
--connect jdbc:mysql://192.168.52.130:3306/userdb
--username root
--password 123456
--table emp_out
--export-dir /sqoop/emp
--input-fields-terminated-by ","
3.验证mysql表数据
1、Hbase数据存储在hdfs,少量存内存
2、hbase适合海量稀疏数据存储
hbase属于nosql数据库,列存储
3、与传统关系型数据库对比:
行存储:传统关系型数据mysql、oracle
优点:保证数据完整性,写入检查
缺点:读的过程会产生冗余信息
列存储:Nosql数据库
优点:读的过程不会产生冗余
缺点:写入效率差,不保证完整性
4、Hbase优点:
(1)存储海量数据
(2)快速随机访问
(3)进行大量的改写操作
Hbase的优点及应用场景:
对于数据结构字段不够确定或杂乱无章非常难按一个概念去进行抽取的数据适合用HBase,因为HBase支持动态添加列。
RDBMS的行有多少列是固定的。为null的列浪费了存储空间。HBase为null的Column不会被存储,这样既节省了空间又提高了读性能。
依据Row key和Column key定位到的Value能够有随意数量的版本号值,因此对于须要存储变动历史记录的数据,用HBase是很方便的。比方某个用户的Address变更,用户的Address变更记录也许也是具有研究意义的。
对于数据存储事务的要求不像金融行业和财务系统这么高,只要保证最终一致性就行。(比如HBase+elasticsearch时,可能出现数据不一致)
WAL解决高可用,支持PB级数据,put性能高
不需要太多的关系型数据库特性,列入交叉列,交叉表,事务,连接等。
Hbase的缺点:
5、Hbase结构:rowkey -> Column Family -> Column Qualifer列族具体列
rowkey行键
table的主键,table中的记录按照rowkey 的字典序进行排序
Column Family列族
hbase表中的每个列,都归属与某个列族。列族是表的schema的一部分(而列不是),必须在使用表之前定义。
Timestamp时间戳
每次数据操作对应的时间戳,可以看作是数据的version number版本号
Column列
列族下面的具体列
属于某一个ColumnFamily,类似于我们mysql当中创建的具体的列
cell单元格
由{row key, column( =
cell中的数据是没有类型的,全部是以字节数组进行存储
6、Hbase逻辑模型:三维有序
Rowkey -> Column Family -> Column Qualifier -> Timestamp
rowkey行(正序, 从小到大)、column列(正序从小到大)、timestamp时间(倒叙从大到小)
面试点:为什么说hbase表的列族不宜超过3个?
a、列族数量决定store, 一个store至少有一个memstore,而memstore占内存
b、如果列族越多的话,造成更多的flush会产生更多IO
flush的最小单位是region, 一个region中的某个列族做flush , 其余的列族也会做flush
频繁的flush产生更多的storeFile,storeFile增多就会产生更多compaction操作
compaction操作和flush都是重IO操作
c、列族过多,split操作会出现数据不均匀的情况
前提:服务器的配置不是很好并且对查询速度要求不是很高
rowkey设计为:random+时间
目的:防止某一个或某几个regionserver成为热点
前提:服务器本身的配置要高一些, 会出现一个或是多个region热点效应
rowkey设计为:时间+random
list_namespace 查看所有数据,类似于show database;
scan 'hbase:meta' 查看元数据信息
--创建表 'cf1','cf2' 表示列族
create 'badou_20_a','cf1','cf2'
-- 查看表的结构
describe 'badou_20_a'
-- 删除cf1列族
alter 'badou_20_a',{NAME=>'cf1',METHOD=>'delete'}
-- 查看存在哪些表
list
exists 'badou_20_a'
-- 保留两个版本的数据, IN_MEMORY数据保存到内存中
alter 'badou_20_a',{NAME=>'cf2',VERSIONS=>2,IN_MEMORY=>true}
-- 删除表
disable 'badou_20_a' : 将表转换为去激活的状态
drop 'badou_20_a' : 删除表
-- 激活表
enable 'badou_20_a'
-- 插入记录
put 'badou_20','1003','cf2:name','root'
put 'badou_20','1004','cf2:name','scott'
-- 获取记录
scan 'badou_20' 注意 hbase表的数据量特别大的时候, scan 慎用
-- 根据rowkey 查询
get 'badou_20','1001'
-- 根据列族获取
get 'badou_20','1001',{COLUMN=>'cf2:name'}
-- 根据列族和指定的时间戳进行获取
get 'badou_20','1001',{COLUMN=>'cf2:name',TIMESTAMP=>1615465406738}
-- 查询表的记录
count 'badou_20'
-- 强制刷出内存的数据到HDFS
flush 'badou_20'
-- 清除表的数据,保留表的结构
truncate 'order'
9、hbase shell 进阶
-- 修改 badou_20 版本为2
put 'badou_20','1001','cf2:name','max'
put 'badou_20','1001','cf2:name','avg'
alter 'badou_20',{NAME=>'cf2',VERSIONS=>2}
如何显示两个版本?
scan 'badou_20',{VERSIONS=>2}
get 'badou_20','1001',{COLUMN=>'cf2:name',VERSIONS=>2}
get 'badou_20','1001',{COLUMN=>'cf2',VERSIONS=>2}
-- 修改表的版本
alter 'badou_20',{NAME=>'cf2',VERSIONS=>3}
alter 'badou_20',{NAME=>'cf2',VERSIONS=>4}
-- TTL 按照规定的时间对数据进行超时间设置
TTL => 'FOREVER' 表示数据永不过期
TTL => '60 SECONDS 表示一分钟之前的数据会过期
create 'tt_table',{NAME=>'cf1',TTL=>60}
1616311193758
put 'tt_table','rowkey001','cf1:age','30',1616311993900
采集需求:某服务器的某特定目录下,会不断产生新的文件,每当有新文件出现,就需要把文件采集到HDFS中去
根据需求,首先定义以下3大要素
采集源,即source——监控文件目录 : spooldir
下沉目标,即sink——HDFS文件系统 : hdfs sink
source和sink之间的传递通道——channel,可用file channel 也可以用内存channel
配置文件编写:
#定义三大组件的名称
agent1.sources = source1
agent1.sinks = sink1
agent1.channels = channel1
# 配置source组件
agent1.sources.source1.type = spooldir
agent1.sources.source1.spoolDir = /home/hadoop/logs/
agent1.sources.source1.fileHeader = false
#配置拦截器
agent1.sources.source1.interceptors = i1
agent1.sources.source1.interceptors.i1.type = host
agent1.sources.source1.interceptors.i1.hostHeader = hostname
# 配置sink组件
agent1.sinks.sink1.type = hdfs
agent1.sinks.sink1.hdfs.path =hdfs://hdp-node-01:9000/weblog/flume-collection/%y-%m-%d/%H-%M
agent1.sinks.sink1.hdfs.filePrefix = access_log
agent1.sinks.sink1.hdfs.maxOpenFiles = 5000
agent1.sinks.sink1.hdfs.batchSize= 100
agent1.sinks.sink1.hdfs.fileType = DataStream
agent1.sinks.sink1.hdfs.writeFormat =Text
agent1.sinks.sink1.hdfs.rollSize = 102400
agent1.sinks.sink1.hdfs.rollCount = 1000000
agent1.sinks.sink1.hdfs.rollInterval = 60
#agent1.sinks.sink1.hdfs.round = true
#agent1.sinks.sink1.hdfs.roundValue = 10
#agent1.sinks.sink1.hdfs.roundUnit = minute
agent1.sinks.sink1.hdfs.useLocalTimeStamp = true
# Use a channel which buffers events in memory
agent1.channels.channel1.type = memory
agent1.channels.channel1.keep-alive = 120
agent1.channels.channel1.capacity = 500000
agent1.channels.channel1.transactionCapacity = 600
# Bind the source and sink to the channel
agent1.sources.source1.channels = channel1
agent1.sinks.sink1.channel = channel1
Channel参数解释:
capacity:默认该通道中最大的可以存储的event数量
trasactionCapacity:每次最大可以从source中拿到或者送到sink中的event数量
keep-alive:event添加到通道中或者移出的允许时间
采集需求:比如业务系统使用log4j生成的日志,日志内容不断增加,需要把追加到日志文件中的数据实时采集到hdfs
根据需求,首先定义以下3大要素
采集源,即source——监控文件内容更新 : exec ‘tail -F file’
下沉目标,即sink——HDFS文件系统 : hdfs sink
Source和sink之间的传递通道——channel,可用file channel 也可以用 内存channel
配置文件编写:
agent1.sources = source1
agent1.sinks = sink1
agent1.channels = channel1
# Describe/configure tail -F source1
agent1.sources.source1.type = exec
agent1.sources.source1.command = tail -F /home/hadoop/logs/access_log
agent1.sources.source1.channels = channel1
#configure host for source
agent1.sources.source1.interceptors = i1
agent1.sources.source1.interceptors.i1.type = host
agent1.sources.source1.interceptors.i1.hostHeader = hostname
# Describe sink1
agent1.sinks.sink1.type = hdfs
#a1.sinks.k1.channel = c1
agent1.sinks.sink1.hdfs.path =hdfs://hdp-node-01:9000/weblog/flume-collection/%y-%m-%d/%H-%M
agent1.sinks.sink1.hdfs.filePrefix = access_log
agent1.sinks.sink1.hdfs.maxOpenFiles = 5000
agent1.sinks.sink1.hdfs.batchSize= 100
agent1.sinks.sink1.hdfs.fileType = DataStream
agent1.sinks.sink1.hdfs.writeFormat =Text
agent1.sinks.sink1.hdfs.rollSize = 102400
agent1.sinks.sink1.hdfs.rollCount = 1000000
agent1.sinks.sink1.hdfs.rollInterval = 60
agent1.sinks.sink1.hdfs.round = true
agent1.sinks.sink1.hdfs.roundValue = 10
agent1.sinks.sink1.hdfs.roundUnit = minute
agent1.sinks.sink1.hdfs.useLocalTimeStamp = true
# Use a channel which buffers events in memory
agent1.channels.channel1.type = memory
agent1.channels.channel1.keep-alive = 120
agent1.channels.channel1.capacity = 500000
agent1.channels.channel1.transactionCapacity = 600
# Bind the source and sink to the channel
agent1.sources.source1.channels = channel1
agent1.sinks.sink1.channel = channel1
Flume支持众多的source和sink类型,详细手册可参考官方文档
http://flume.apache.org/FlumeUserGuide.html
Kakfa最初由Linkedin公司开发,使用 Scala 编写,拥有高吞吐、可持久化、可水平扩展的基于发布/订阅模式的分布式消息队列,支持分区策略、多副本策略,基于zookeeper协调的分布式消息系统,主要应用于大数据的实时或离线数据处理、日志收集以及实时指标监控等领域。
消息:message,消息是kafka的基本数据单元,代表着一条一条的数据,为了提高网络和存储的利用率,生产者会批量发送消息到Kafka,并在发送之前对消息进行压缩。
主题:topic,主题是kafka对消息的分类,是一个逻辑概念,可以看作消息集合,用于接收不同业务的消息。
分区:partition,类似数据库的分区表,通常topic下会多个分区,每个分区内的数据是有序的,同一个topic的多个分区kafka不保证消息的顺序性,一个分区在逻辑上对应一个Log,对应磁盘上的一个文件夹。
偏移量:offset,偏移量是表示消息在分区中的位置,kafka存储的文件是按照offset.log的格式来命名的,便于快速查找。
副本:replicas,副本是针对分区而言的,kafka对消息做了冗余备份,目的就是为了容灾,每个分区可以指定多个副本来冗余数据,分为leader partition和follower partition,只有leader partition对外提供服务,follower partition单纯是从leader partition同步数据,因此会存在多份相同的数据。
生产者:producer,生产者是kafka集群的上游,顾名思义就是往kafka输入数据的客户端。
消费者:comsumer,消费者是kafka集群的下游,与生产者相辅相成,kafka类似一个仓库,生产者负责生产消息往仓库放,自然得有消费者从仓库里拿消息,不然仓库容易爆满。
消费者组:Comsumer Group,简称CG,这个比较容易理解,就是将多个消费者捆绑起来,组团消费消息,一个Consumer只能属于一个Consumer Group,Kafka还通过Consumer Group实现了消费者的水平扩展和故障转移。
节点:broker,一个broker就是一个kafka server实例,多个broker组成kafka集群,主要用于接收生产者发送过来的消息,写入磁盘,同时可以接收消费者和其他broker的请求。
重新负载均衡:rebalance,当消费者组的消费者实例出现变化时,例如新增消费者或者减少消费者,都会触发kafka的Rebalance机制,这个过程比较耗性能,要尽量避免这个过程被触发。
我们把架构分主从架构和对等架构,主从架构就是分为管理节点和工作节点,职责不同,如HDFS 、spark、flink;对等架构则不区分节点属性,所有的实例职责都是一样的,kafka的架构有点类似于对等架构,但又不完全是。Kafka的设计理念之一就是同时提供离线处理和实时处理。
Kafka ACK消息确认机制有三个值,分别为1,0和-1,默认是1,对应不同的状态:
ack=1,意味着producer要等待leader成功收到数据并得到确认,才发送下一条message,安全性较高但是性能相对较低。
ack=0,意思就是说,我只管发送消息,不用你给我回复,成就成,不成我也不管,这种策略的性能是最高的,但是容易丢失数据。
ack=-1,这种情况下,生产者只有收到所有副本写入成功的通知后,才会认为消息写入成功,安全性最高,但是性能是三者里面最差的。
kafka分区机制:
实现kafka高吞吐量的重要手段,实现流量分发和负载均衡,试想一下,如果所有的消息都往同一个数据写,对于服务器来说会造成极高的负载,特别是出现热点数据的时候容易崩溃,对于多个生产者和多个消费者来说,只有一个分区可以用于生产和消费,这显然是非常受限的。
kafka提供了三种分区策略:
轮询策略:Round-robin,轮询策略是Kafka默认的分区策略,根据主题分区数量从头到尾进行轮询,目的就是为了将消息均匀地分布在分区中,保证消息最大限度地被平均分配到所有分区上。
随机策略:Range Strategy,所谓随机就是我们随意地将消息放置到任意一个分区上,随机分发,这样有可能会造成消息分发不均匀,相比之下,轮询策略显得更加合理,旧版本默认是用随机策略,新版本默认用的是轮询策略。
按key分发策略:顾名思义就是根据消息的key指定分区写入,这种方式主观性比较强,相对比较灵活。
除此之外,kafka支持自定义分区器,实现更多复杂的逻辑处理消息。
kafka副本机制:
为了提供数据冗余、数据备份的安全策略,等同于备份,实际上,基本所有的分布式消息队列都会存在副本机制,不光是消息队列,HDFS也是如此。
前面在kafka常用术语中说到,Kafka 是有主题概念的,主题下划分成若干个分区,副本是分区的逻辑概念,分区可以指定多个副本。本质上副本就是一个只能不断追加的日志文件,在实际的生产中,为了保障数据安全,通常会配置多个副本,根据算法分散在不同的broker上,一份数据(leader和副本)不会同时出现在一台服务器上,这样当服务器出现故障时,能够最大程度保证数据不丢失,如下图。
其中leader partition和 follower partition的工作原理如下,正常情况下,只有leader partition对外提供服务,follower partition负责从leader partition拉取数据,当leader发送故障时,follower拥有被选举为新leader的权利。
支持数据离线和实时处理
能保证消息的可靠性传递
支持消息的持久化存储,并通过多副本分布式的存储方案来保证消息的容错
高吞吐率,每秒处理百万级的消息量
高并发,支持数千个客户端同时读写
支持在线水平扩展
kafka为什么能实现读写都这么快呢?
答:离不开kafka顺序读写机制和零拷贝数据传输,减少了寻址的时间消耗,降低了读写延迟,同时有利于快到定位消息偏移量,零拷贝机制可以提高数据传输的效率,减少IO资源的占用。
Spark实战例子参考:https://blog.csdn.net/qq_36816848/article/details/113833103