大数据面试--20210611

ゝ一纸荒年。 2022-10-06 05:50 115阅读 0赞

**目录**

基础题

1、flink checkpoint 与 savepoint 区别以及使用场景

思考题

2、Kafka 高效读写数据的原理

1.顺序写磁盘

2.分段日志 + 索引文件

3.零拷贝

4. Page Cache

5. 批量发送

6. 数据压缩

智力题

3、岛上有 100 个囚犯，

--------------------

# **基础题** #

## 1、flink checkpoint 与 savepoint 区别以及使用场景 ##

1.checkpoint的侧重点是“容错”，即Flink作业意外失败并重启之后，能够直接从早先打下的checkpoint恢复运行，且不影响作业逻辑的准确性。而savepoint的侧重点是“维护”，即Flink作业需要在人工干预下手动重启、升级、迁移或A/B测试时，先将状态整体写入可靠存储，维护完毕之后再从savepoint恢复现场。

2.savepoint是“通过checkpoint机制”创建的，所以savepoint本质上是特殊的checkpoint。

3.checkpoint面向Flink Runtime本身，由Flink的各个TaskManager定时触发快照并自动清理，一般不需要用户干预；savepoint面向用户，完全根据用户的需要触发与清理。

4.checkpoint的频率往往比较高（因为需要尽可能保证作业恢复的准确度），所以checkpoint的存储格式非常轻量级，但作为trade-off牺牲了一切可移植（portable）的东西，比如不保证改变并行度和升级的兼容性。savepoint则以二进制形式存储所有状态数据和元数据，执行起来比较慢而且“贵”，但是能够保证portability，如并行度改变或代码升级之后，仍然能正常恢复。

5.checkpoint是支持增量的（通过RocksDB），特别是对于超大状态的作业而言可以降低写入成本。savepoint并不会连续自动触发，所以savepoint没有必要支持增量。

# **思考题** #

## 2、Kafka 高效读写数据的原理 ##

> 出处链接：[https://blog.csdn.net/weixin\_45749011/article/details/106633114?utm\_source=app&app\_version=4.5.4][https_blog.csdn.net_weixin_45749011_article_details_106633114_utm_source_app_app_version_4.5.4]

### **1.顺序写磁盘** ###

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

时间。

### **2.分段日志 + 索引文件** ###

分段日志是通过数据的偏移量进行存储，索引文件是能快速定位所要查询数据的位置

1、Kafka把topic中一个parition大文件分成多个小文件段，通过多个小文件段，就容易定期清除或删除已经消费完文件，减少磁盘占用。

2、通过索引信息可以快速定位message和确定response的最大大小。

3、通过index元数据全部映射到memory，可以避免segment file的IO磁盘操作。

4、通过索引文件稀疏存储，可以大幅降低index文件元数据占用空间大小。

### **3.零拷贝** ###

如下图所示是普通Java读取复制文件的一个流程

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTExMTAzMDE_size_16_color_FFFFFF_t_70][]

Java程序是无法直接操作硬件的，所以Java想要操作文件的话必须得通过操作系统去读取文件。这时就会涉及大量的**读写缓存**，因为我们发送数据的时候不可能1kb的发，因此只能先缓存起来，这必定会涉及到大量的IO操作，由此可见这样的效率并不是非常高的。

零拷贝

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTExMTAzMDE_size_16_color_FFFFFF_t_70 1][]

1.在Kafka中我们的Java程序并不需要文件的内容，所以Kafka就使用了零拷贝的技术，因此Kafka当中的数据直接缓存在操作系统当中，我们读也在这里读 写也在这里写，这样的效率提高了许多。

2.所谓的零拷贝并不是真正意义上的零拷贝 实际上是缓存了一次，只是相对于普通Java读取复制文件少了许多中间的缓存

### **4****.** **Page Cache** ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTExMTAzMDE_size_16_color_FFFFFF_t_70 2][]

由上图可见

1. 传统的数据传输是先将数据缓存在内存当中，当数据达到一定的阈值再写入到文件中。

2. Page Cache 是在操作系统开了一个内存将数据直接缓存到系统内存中。

3. 虽然将数据缓存到Page Cache中会比直接缓存到Memory中效率更低，但是当数据量达到一定的阈值的时候Memory会对缓存中的数据进行溢写，这样的效率就会比直接写入Page Cache会更低，因为Page Cache对文件进行读写操作效率是非常高的，而Memory对数据进行溢写这时就需要请求操作系统，所以这样的效率会比Page Cache对文件的读写操作效率低很多。

4. 缓存到Memory我们JVM所分配到的内存是有限的，而Page Cache是利用操作系统的内存。

### **5. 批量发送** ###

kafka允许进行批量发送消息，producer发送消息的时候，可以将消息缓存在本地，等到了固定条件发送到kafka

1. 等消息条数到固定条数

2. 一段时间发送一次

### **6. 数据压缩** ###

Kafka还支持对消息集合进行压缩，Producer可以通过GZIP或Snappy格式对消息集合进行压缩。

压缩的好处就是减少传输的数据量，减轻对网络传输的压力

批量发送和数据压缩一起使用效果最好，单条做数据压缩的话，效果不明显

# **智力题** #

### 3、岛上有 100 个囚犯， ###

他们都是蓝眼睛，但是他们都只能看到别人眼睛的颜色， 并不能知道自己的眼睛颜色，而且他们之间不能去谈论眼睛颜色的话题，规定每天晚上都可 以有一个人去找守卫说出自己的眼睛颜色，如果错了被杀死，如果对了被释放。但是大家在 没有十足的把握前都不敢去找守卫，有一天，一个医生对他们说你们之中至少有一个蓝眼睛， 然后 N 天，这些人都获救了，为什么？这句话对他们有什么影响？

如果只有一个蓝眼人，那么他原本看不到蓝眼人，听到医生的话，就知道了医生说的蓝眼人就是自己，因此他在当天晚上找守卫说自己是蓝眼睛。

由此可以推出，如果有两个蓝眼人，那么他们原本都只看到一个蓝眼人，听到医生的话，都会想：对方是不是岛上唯一的蓝眼人？如果是的话，那么一天后他应该发现对方已经被释放。但过了一天没人被释放，因此两人都明白了，对方没被释放是因为岛上还有一个蓝眼人，就是自己。因此，在医生讲话的第二天晚上，这两人会一起被释放。

这是个递归逻辑。各位想想，如果有三个蓝眼睛，那第二天当晚这三个蓝眼睛就同时被释放。

如果是四个蓝眼睛，那第三天当晚这四个蓝眼睛就同时被释放。

依次类推，100个蓝眼睛，第99天当晚全部被释放。

[https_blog.csdn.net_weixin_45749011_article_details_106633114_utm_source_app_app_version_4.5.4]: https://blog.csdn.net/weixin_45749011/article/details/106633114?utm_source=app&app_version=4.5.4
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTExMTAzMDE_size_16_color_FFFFFF_t_70]: /images/20221005/e7fc951fb84643399fffd9dcfd9a9547.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTExMTAzMDE_size_16_color_FFFFFF_t_70 1]: /images/20221005/8b868e7d068a4a68a03ebca2eef7696a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTExMTAzMDE_size_16_color_FFFFFF_t_70 2]: /images/20221005/8cfdce8b4b984f2e9b438a5d9397cc10.png