【pyspark】广播变量のdestroy...

今天发现用户的 pyspark 程序 driver 所在的母机的磁盘告警了，进去 pyspark driver pod 一看，发现有个目录数据多达1T了。一开始怀疑是 shuffle 文件没有清理干净，但通过 lsof 等命令查看是哪些文件被打开了在写，但是提供的信息有限，也没看出来是哪个地方有问题。但是通过 lsof 至少能看到 /tmp/liblz4xxx 这个库一直被打开。

block-man    16  8928 root  mem       REG                8,4   215696     1267847 /tmp/liblz4-java4987830414110761690.so
block-man    16  8928 root  mem       REG                8,4    32768  4297391491 /tmp/hsperfdata_root/16
block-man    16  8929 root  DEL       REG                8,4              1268838 /tmp/libzstd-jni912902033510074820.so
block-man    16  8929 root  mem       REG                8,4   215696     1267847 /tmp/liblz4-java4987830414110761690.so
block-man    16  8929 root  mem       REG                8,4    32768  4297391491 /tmp/hsperfdata_root/16

有了这些信息之后，大概可以猜到应该是哪里的序列化文件没有被删除掉。咨询了用户之后发现用户代码有一个循环，每次循环都会广播一个变量，而这个广播变量并没有删除。
到这个临时目录下一看，发现这些文件都几乎是一个大小的，大概可以定位到，应该是广播变量没有清理的原因。

/pyspark-bf13f29c-5544-4374-b82b-52e90d797371# du -sh *
22M	tmp1r3tmb5k
22M	tmp464ovce6
22M	tmp49w6ra9c
22M	tmp4pfdxa8h
22M	tmp4wl7g9yu
22M	tmp4xa6f6qu
22M	tmp57kvshok
22M	tmp6m7ze7lg
22M	tmp_fn7rfy5
22M	tmpdnh3vl_z
22M	tmpdr2k0jkl
22M	tmpepoj7grz
22M	tmpf5hskspm
22M	tmphyubnq18
22M	tmpidy_u4q3
22M	tmpii6mx4yr
22M	tmpiki0d_xa
22M	tmpjciox5b7
22M	tmpjqcgf5u4
22M	tmpjtedq89i
22M	tmpl9bfu31j
22M	tmplnq0f83k
22M	tmpnz29ptj_
22M	tmpon_xxhxl
22M	tmppnh_vb9a
22M	tmpqnod7870
22M	tmpqrsv52y1
22M	tmpsfq3ixiu
22M	tmpsvpev157
22M	tmpthjqyvw9
22M	tmpttmjtoqa
22M	tmpvxxwb_je
22M	tmpyqa05ag_
22M	tmpz80h7w_i
22M	tmpz9uajqpf

当然了，pyspark 没什么日志，排查问题比较麻烦，总是靠猜…找下 pyspark 源码，可以发现广播变量的文件是不会被删除的。

不过好在，这个广播变量是可以被删除的，用户用完之后可以选择 destroy()。

总结一下，解决方案建议有两个：

1. 磁盘使用 quota，这样 driver 写满了，自然会退出，由用户自行重启
2. 用完的广播变量及时 destroy