大数据-kafka学习（四）——文件存储

一、文件存储机制

topic是逻辑上的概念，而partition是物理上的概念，每个partition对应于一个log文件，该log文件中存储的就是Producer生成的数据。Producer生成的数据会被不断追加到该log文件末端，为防止log文件过大导致数据定位效率低下，Kafka采取了分片和索引机制，将每个partition分为多个segment，每个segment包括：“.index”文件、“.log”文件和.timeindex等文件。这些文件位于一个文件夹下，该文件夹的命名规则为：topic名称+分区序号，

例如：first-0

一个partition分为多个segment

.log 日志文件

.index 偏移量索引文件

.timeindex 时间戳索引文件

其他文件（partition.metadata，leader-epoch-checkpoint）

二、Log文件和Index文件详解

注意：

1、index为稀疏索引，大约每往log文件写入4KB数据，会往index文件写入一条索引。

参数log.index.interval.bytes默认4kb

2、index文件中保存到offset为相对offset，这样能确保offset的值所占空间不会过大，

因此能将offset的值控制在固定大小

三、Kafka文件清理策略

Kafka中默认的日子保存时间为7天，可以通过调整如下参数修改保存时间

• log.retention.hours，最低优先级小时，默认7天。
• log.retention.minutes,最高优先级分钟
• log.retention.ms，最高优先级毫秒
• log.retention.check.interval.ms， 负责设置检查周期，默认5分钟。

那么日志一旦超过了设置的时间，怎么处理呢？

Kafka提高的日志清理策略有delete 和 compact两种

1、delete 日志删除：将过期数据删除

log.cleanup.policy=delete  所有数据启用删除策略

1）基于时间：默认打开，以segment中所有记录中的最大时间戳作为该文件时间戳

2）基于大小：默认关闭，超过设置的所有日志总大小，删除最早的segment。

log.retention.bytes,默认等于-1，表示无穷大。

2、Compact日志压缩：对于相同的key的不同value值，只保留最后一个版本 

log.cleanup.policy = compact 所有数据启用压缩策略

压缩后的offset可能是不连续的，比如上图中没有6，当从这些offset消费消息时，将会拿到比这更offset大的offset对应的消息，实际上会拿到offset为7的消息，并从这更位置开始消费。

这种策略只适合特殊场景，比如消息的key时用户ID，value时用户的资料，通过这种压缩策略，整个消息集就保存了所有用户最新的资料。

四、高效读写数据

1、kafka本身时分布式集群，可以采用分区技术，并行度高

2、读数据采用稀疏索引， 可以快速定位要消费的数据

3、顺序写磁盘

Kafka的producer生成数据，要写入到log文件中，写的过程一直追加到文件末端，为顺序写。官网有数据表明，同样的磁盘，顺序写能到600M/s，而随机写只有100K/s。这与磁盘的机械结构有关，顺序写之所以快，是因为其省去了大量磁头寻址的时间。

4、零拷贝和页缓存

零拷贝：kafka的数据加工处理操作交由Kafka生产者和Kafka消费者处理，Kafka Broker应用层不关心存储的数据，所以就不用走应用层，传输效率高

PageCache 页缓存：Kafka重度依赖底层操作系统提高的PageCache功能，当上层油写操作时，操作系统只是将数据写入PageCache。当读操作发生时没，先从PageCache中查找，如果找不到，再去磁盘中读取。实际上PageCache是把尽可能多的空闲内存当作了磁盘缓存来使用。