四月上旬新内容速递丨技术深潜、图表进阶与AI热词

春意正浓,学习升温!四月上旬更新聚焦技术拓展、图表新解、AI热点与实战任务,助你在数据探索之路上步步为营,智取未来!

一、场景应用精选

【热力图】数据的“温度计”与分布探测器》→热力图在业务分布与浓度识别中的实战应用。
【数析课堂】排序法:业务人员的“数据理线器”》→排序法助力业务数据梳理,提升分析效率。
【关系图】解锁数据背后的“隐形网络”与关联密码》→关系图在复杂关联分析中的深度应用。
【数析课堂】让数据开口说话:职场人的“图形法”生存指南》→图形法职场实战指南,轻松驾驭数据表达。

二、技术经验分享

降维打击!Smartbi仪表盘隐藏ECharts玩法大揭秘》→解锁仪表盘高阶玩法,用ECharts实现可视化降维创新。
“数”转乾坤:数据转换规则变形记》→深入数据转换规则,掌握数据变形与流转的核心技巧。

三、AI知识更新

【AI每日一学】简要介绍一下最近AI圈很火的“养龙虾”话题》→每日一学,快速理解AI圈热门话题“养龙虾”。
【AI每日一学】讲一下最近AI圈很火的“养龙虾”话题中一直被提及的skill》→深度解析“养龙虾”中的关键技能概念,紧跟AI前沿。

四、全新素材上线

指标元素动态图(二)》→新增指标动态图素材,丰富仪表盘视觉表现力。

五、官方通知更新

2026年「月更日志」社区更新合集 3.1 - 3.31》→回顾三月社区更新动态,掌握平台最新进展。
春日如约而至:2026年第一季度任务通关排行榜请查收!》→揭晓Q1任务通关榜单,激励持续学习与挑战。

六、任务持续上线

【AI知识巩固】简要介绍一下最近AI圈很火的“养龙虾”话题》→追踪AI圈最新热词,轻松入门“养龙虾”现象。
【图表应用】热力图:数据的“温度计”与分布探测器》→学习热力图制作,让数据热度一目了然。
【BI知识闯关】降维打击!Smartbi仪表盘隐藏ECharts玩法大揭秘》→实战闯关,巩固仪表盘隐藏技能。
【数析课堂】排序法知识巩固》→掌握排序分析法,梳理数据层级关系。
【图表应用】关系图:挖掘数据背后的“隐形关系网”》→学习关系图绘制,发现数据间的隐秘关联。
【BI知识闯关】重生之如何找SQL看数据不对问题(上)》→SQL排错实战,提升数据校验能力。
【BI知识闯关】“数”转乾坤:数据转换规则变形记》→闯关巩固数据转换规则应用。
【AI知识巩固】讲一下最近AI圈很火的“养龙虾”话题中一直被提及的skill》→深入“养龙虾”背后的技能概念,拓展AI认知。
【数析课堂】图形法知识巩固》→强化图形化分析方法,让数据表达更直观。

麦粉社区
>
帖子详情

[系统运维] Smartbi磁盘空间告急?这篇清理指南让你轻松腾出几十GB!

动态中心 发表于 2026-2-3 09:20
发表于 2026-2-3 09:20:13

最近运维同事小陈发现,Smartbi服务器磁盘空间频频告急,系统响应越来越慢,甚至定时任务失败。一查才发现,某个组件的日志文件竟然占了上百GB!事实上,Smartbi在长期运行中,各个服务组件会持续产生日志、缓存、临时文件等,若不定期清理,不仅拖慢性能,还可能引发系统崩溃。
今天,我们就来盘一盘Smartbi中哪些组件容易‘囤积’磁盘空间,以及如何安全高效地清理它们。


一、快速诊断——磁盘告警信号与定位命令


在开始动手清理之前,我们首先需要确认系统是否真的面临磁盘压力,并精准定位是哪个“大家伙”占用了空间。


当磁盘空间不足时,您可能会遇到以下情况:



  • SmartBI 应用报错:在界面上传文件、执行数据挖掘任务、导出报表时失败,提示“写入文件失败”、“磁盘空间不足”或类似报错

  • Tomcat 相关错误:应用无法启动,启动日志中看到"No space left on device"

  • 数据库/MPP 错误:高速缓存库(如 ClickHouse)写入失败,报错“Disk is full”或“Too many parts”

  • 第三方监控平台告警:服务器接入的第三方监测平台,发出的磁盘不足或占用高的告警


如果出现上面的情况,那我们基本库确认是磁盘空间问题,接下来我们将进入最重要的环节——如何安全、有效地清理各组件,既释放空间又不影响业务运行。


二、SmartBI各组件磁盘清理指南


1、磁盘查询


在各个组件的清理正式开始前,我们先简单的了解一些磁盘占用排查基础,Windows服务器可以很直观地从文件管理器中观察的,此处主要是以Linux服务器为主要说明:


(1)通过运维命令排查磁盘空间情况,检查服务器机器磁盘空间是否已满


命令:df -hl


IMG_256


 


(2)定位磁盘占用高的大目录


# 查看根目录下哪个文件夹最大


命令:du -sh /* 2>/dev/null | sort -rh | head -10


IMG_257


2、BI主应用磁盘清理


(1)Tomcat日志文件清理(最常见问题)

Tomcat应用运行过程中,catalina.out作为标准输出和标准错误输出的默认日志文件,会持续记录控制台信息。该文件在默认配置下不具备自动轮转机制,所有运行期日志均以追加方式持续写入同一文件。随着SmartBI系统长期运行,特别是存在高频操作或异常调试时,该文件会线性增长,累积占用大量存储空间。






































日志文件



典型大小



是否可清理



风险等级



catalina.out



可能达到 10-100GB



可清理





localhost.log



通常1-5GB



可清理





manager.log



通常<1GB



可清理





host-manager.log



通常<1GB



可清理





如果有需要我们也可以参考一些网络资料,用shell脚本或第三方工具等实现catalina.out日志切割以及tomcat日志的定时清理。


(2)备份文件清理

备份文件积累是SmartBI系统磁盘空间占用的重要原因,通常包括以下两类:



  • 系统更新WAR包备份文件清理


版本升级或补丁安装过程中,旧版本WAR包通常被重命名保留作为回滚备份。这些文件体积较大(通常200-500MB),多次更新后如果不进行清除,会有多个历史版本会累积占用数GB空间。备份文件常存放于Tomcat的webapps目录或其子目录(项目的其他指定备份目录)中。所以日常我们更新运维时,可以备份同时删除掉历史的备份,保留近期1~2个的备份文件即可。


IMG_258



  • 自动化备份知识库文件清理


系统配置的定时备份任务(如每日知识库备份)会默认每日凌晨5点备份文件,在启动目录下的“应用名_repoBackup”。


IMG_259


通常自动备份的知识库文件,默认是留存30个,超出范围的会进行文件清理,删除最旧的历史备份文件。我们也可以在系统内置的【自动备份知识库】任务脚本中调整maxCount即留存的最大文件数量,尤其是一些集群环境中,计划可能随机一个节点执行,也可以按需调整单个节点上的最大备份文件个数。例如,BI有4个节点时,每个节点默认备份30个,环境总备份量可达120个,这种情况下,我们就可以考虑适当调小下单个节点的最多的备份数量,减少备份文件累计。


IMG_260


(3)内存溢出文件清理

在系统运行中,我们会推荐配置“ -XX:+HeapDumpOnOutOfMemoryError”这个JVM参数,当发生内存溢出时,该参数用于存储堆信息,堆文件会与系统异常时的运行内存一样大(如下文件名称通常为xxxx.hprof),因此异常时未及时发现或清理也会导致磁盘空间大量占用。


若出现宕机问题,将文件发回支持小伙伴分析后,服务器上遗留的历史久远的堆转储文件,也可进行删除清理。


IMG_261


3、知识库日志表清理


系统在运行期间会持续生成各类日志文件,包括操作日志、数据抽取日志、电子表格回写日志等。系统中包含的日志表、可在【备份知识库】-【仅备份日志表】中的提示悬浮框中查看。


IMG_262


其中,尤其操作日志,若缺乏定期清理机制,会随系统长时间运行不断累积,导致记录数量显著增加。这不仅影响日志检索效率,还会造成知识库存储空间的不必要占用,进而影响系统整体性能与稳定性。操作日志记录了用户在Smartbi中的操作,为系统运维、排查问题提供依据。那日常我们可以如何清理操作日志报表呢?



  • 在【运维设置-操作日志】打开后,可在操作区选择指定范围的日志删除。此操作不建议在系统业务时间段操作,或是仅涉及小批量的日志数据删除


IMG_263



  • 可使用数据库工具,连接上知识库后,删除指定范围的操作日志记录,操作日志数据表结构可参考wiki文档:操作日志

  • 同时也可考虑通过系统的计划任务定时清理系统操作日志,如仅保留近30天的操作日志记录,参考示例任务代码如下(如操作日志较多,如有近几年的操作日志,不建议首次清理使用该任务代码,且日常执行时请在业务空闲时间段执行):删除系统日志脚本.txt (1.54 K)


需要说明的是,针对磁盘空间清理:


(1) 在Mysql的InnoDB存储引擎下,常规的DELETE删除操作仅为仅对数据行进行逻辑标记删除,这些被标记的空间会保留在表内供后续插入操作复用,但并不会实际缩小表文件的大小。因此,即使删除了大量数据,数据库文件占用的磁盘空间依然保持不变。


(2)TRUNCATE操作能立刻释放表内的空间,但由于InnoDB引擎的机制,这部分空间可能仍被保留在数据库系统内,未必能立即归还给操作系统。这两种方式都难以实现彻底的空间回收。


(3)最彻底有效的方法是:在停止Smartbi服务后,对目标表进行重建操作。具体流程为:



  • 首先记录下原表的完整建表语句,包括所有结构、索引与约束定义;

  • 随后删除原表,此操作会立即释放其占用的全部磁盘空间;

  • 最后使用之前备份的建表语句重新创建该表。

  • 如果需要保留数据,则必须在删除前将数据备份至临时表或文件,在重建完成后将数据导回。


4、SmartbiMpp磁盘空间清理


SmartbiMpp作为SmartBI的高速缓存库,负责存储数据,其数据存储机制具有显著特点。系统长期运行下,数据目录与核心目录会持续积累存储文件,可能占用大量磁盘空间。


(1)数据存储目录磁盘空间占用高


数据存储目录用来存储SmartbiMpp的数据文件,数据文件存储文件默认是存储在/var/lib/clickhosue,部署时如需修改数据存储目录可参考文档:安装部署SmartbiMpp 5.3 修改数据目录。若抽取数据量越大占用磁盘空间越大,故通常是建议指定数据存储目录在磁盘空间较大的目录下。


IMG_264


那如果数据存储空间目录占用高的情况下,我们可以如何清理呢?



  • SmartbiMpp查询并清理磁盘空间,通常可能是一些“id_bak”带“_bak”后缀的抽取备份表,如何清理抽取备份表可参考wiki文档:Clickhouse中如何查询落地到磁盘中的表的大小

  • 缓存库的存储目录会存储数据集抽取后的目标表,系统默认会备份存储5个目标表,可修改系统选项的 BACKUP_TAB_RETAIN_NUM=5 配置,减少备份数量。


IMG_265



(2)Coredump文件占用


在启用core文件打印的时候,Linux系统程序由于异常崩溃时,会记录下来的core文件,通常SmartbiMpp生成的core文件会存储在/var/lib/clickhouse/cores下。而且core文件体积通常很大(动辄数G),若未及时发现或者分析清理,core文件会堆积占用磁盘空间。当然,cores目录存储的是ch服务异常崩溃时生成的核心转储文件,而非业务数据,清理它们不会影响ClickHouse的正常运行。我们可以直接清理掉一些历史异常的core文件。


5、ETL磁盘空间清理


etl的磁盘空间占用主要是在spark处理数据存储的数据文件,spark在接收到的实验任务不会区分是否已保存,系统默认清除机制是按单个etl默认保存70条历史以及超过70天的会被清除。因每个历史实验会落地100行的数据,存储到磁盘中,ETL较多,磁盘占用较大,想减少历史这块的存储 。


IMG_267



  • 支持在【系统选项->高级设置】中通过变量来控制保留历史的条数(此配置项针对V10.5.8及以上版本,build日期是24年及以后版本才生效)
    MAXIMUM_NUMBER_OF_MINING_HISTORY=70 表示挖掘和ETL最大历史数为70
    MAXIMUM_NUMBER_OF_JOBFLOW_HISTORY=70 表示作业流最大历史数为70


IMG_268



  • 也可以在【运维设置-ETL/数据挖掘配置-执行引擎】中配置节点缓存数据留存天数


IMG_269


通过以上对各组件的分析,相信您已经掌握了SmartBI磁盘空间管理的关键技巧。磁盘清理就像给系统做定期"体检",及时发现问题并处理,才能保障SmartBI长期稳定高效地为您服务。


 


如果您在清理过程中遇到问题,或想了解更多运维技巧,欢迎在评论区留言交流!


恭喜你已阅读完全文,来做做题巩固下学习内容,答题可赢取麦豆哦——>点击领取任务


 

发表于 2026-3-4 08:33:31
非常棒
回复

使用道具 举报

高级模式
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 | 立即注册

1回帖数 1关注人数 7467浏览人数
最后回复于:2026-3-4 08:33

社区

指南

AI

搜索

快速回复 返回顶部 返回列表