（本文档仅供参考，因涉及到清理数据库的数据，如不确认查询是否正确可将根据文档查询到的信息反馈至官方支持）
问题
经常有客户咨询MPP占用了很多的磁盘空间，该怎么清理MPP占用的空间？
解决方案
如若是和bi相关的，通常是由于以下几种原因生成：
1、生成的抽取自动备份的表太多，占用的空间较多；
2、历史遗留的一些数据异常的表没来及得清除；
3、抽取临时表没有及时清理掉。
方案一
1、使用jdbc连接方式的数据库工具先连接mpp，然后执行DLL语句操作。
1.1先从smartbi.war/smartbi/WEB-INF/lib获取到连接CH所需的驱动（可能不同版本后面jar的小版本号会有点不一样，前面名字是一样的）
1.2在dbeaver中配置驱动信息
1.3、配置连接CH信息
2.对于CH的版本为21及以上版本，可先运行下述sql查询Clickhouse中smartbimpp数据库的每个表的占磁盘的空间大小：
select database, table , rows, FLOOR( bytes_on_disk / 1024 / 1024) as MB_on_disk, FLOOR( data_compressed_bytes / 1024 / 1024) as MB_data_compressed, FLOOR( data_uncompressed_bytes / 1024 / 1024) as MB_data_uncompressed from system.parts p where database = 'smartbimpp' order by bytes_on_disk DESC
如下图红框所示表示占用的磁盘空间，可以找到后缀为“_bak”的表，此类后缀的表名表示的是自动备份的表，可直接运行drop命令删除不用的备份表：
（系统默认会备份存储5个目标表，可删除备份的目标表（bak后缀）并 修改系统选项的 BACKUP_TAB_RETAIN_NUM=5 配置，减少备份数量。）
另外，drop table后，clickhouse会有个后台进程来删除表的数据，要这个进程完成后，数据才会被删除，空间才会被释放，也可以通过show processlist查看是否有正在运行的服务。
如是通过上述sql查询到的表占的空间都不大，也将where条件去掉后查询每个库的空间占用情况，看看哪个库占用的内存大，再反馈具体的占用情况再作下一步的分析：
select database, table , rows, FLOOR( bytes_on_disk / 1024 / 1024) as MB_on_disk, FLOOR( data_compressed_bytes / 1024 / 1024) as MB_data_compressed, FLOOR( data_uncompressed_bytes / 1024 / 1024) as MB_data_uncompressed from system.parts p order by bytes_on_disk DESC
方案二
1、进到Mppdata/data的目录下，执行以下命令：
du -h --max-depth=1|sort -rh
执行上述命令，可以对表目录大小进行排序，如下所示，是从大到小排序，并将结果输出到文件中方便分析：
du -h --max-depth=1|sort -rh >table_size.txt
2、将输出的文件打开进行分析。
（1）大表清理：系统上可以查下这些数据集id（下划线前面的），和用户确认下是否还在使用：
（2）临时表清理：以上述数据为模版，从生成的文件中过滤出表名中带下划线的，表名带I8a的，不带_temp的进行删除：
可将需要删除的表通过执行sql文件的方式进行删除，sql文件内容示例如下：
将上述内容保存在sql文件后，在clickhouse服务器上，用clickhouse-client命令行，执行sql文件清除：
clickhouse-client --user 登录名 --password 密码 -d 数据库 --multiquery < /usr/local/drop_tables.sql
或者如果清理后过一段时间还是发现持续增长，那么需要在数据目录里面，每个目录都查询一下，看看哪个目录占用比较大的空间。将对应的占用情况发回继续分析。数据目录里面，每个目录都查询一下，看看哪个目录占用比较大的空间数据目录里面，每个目录都查询一下，看看哪个目录占用比较大的空间。
如若是有备份功能的版本，建议是删除了上述占用空间较多的备份文件外，也可以一并减少备份数量，避免后续出现类似的问题，具体可参考该文档中的方式处理：缓存库的数据存储目录占磁盘空间太多，能否清理
