下次再遇到 Spark 任务没报错但死活不往下走的情况，先去打一下执行计划，看看是不是代码里又藏了一棵“几十层的树”吧！

aoto-gptq目前好像只支持cuda11.7和11.8。我的cuda11.6重装了(虽然并没有很麻烦)python -m bitsandbytes验证。最佳方案就是使用text—webui把环境下好。安装 bitsandbytes。auto-gptq库下载。

下次再遇到 Spark 任务没报错但死活不往下走的情况，先去打一下执行计划，看看是不是代码里又藏了一棵“几十层的树”吧！

最近线上遇到一个发票明细匹配状态异常的问题。但是也就是说，数据明明已经存在关联关系，却仍然被系统判断为“未关联”。这个字段又会影响主表的all_match计算，最终导致主表匹配状态异常。代码修完之后，我原本以为要重新打包、发布、重启服务。但运维说了一句：这个可以用 Arthas 发到线上。一开始我没太理解。于是就有了这次实践。

处理 OpenSSL 兼容性• 备份系统自带；• 强制安装 CentOS7 的；• 还原 1.1 的库文件，确保 ssh 和系统正常；• 确认存在且被ldd找到。在 CM 初始化前准备好国产 OS 专用的 manifest + parcel• 重命名为；• 修改，增加unknown的 parcel 条目；• 确保 HTTP 仓库能正确暴露这些文件。启动/安装• 启动（嵌入式 PostgreSQL）

如果只能用一句话概括单机数据库与分布式数据库在异常处理上的最大差异，我会这样说：单机系统里的一个语法错误通常只会引发一条隔离的红色报错日志，而在分布式系统的元数据管理节点中，一个未经严密捕获的边界异常，足以让整个集群的控制平面陷入不可逆的死锁。近期在 Doris 2.1 候选版本环境中排查的一起极端 DDL 挂起事件，剥开了并发锁管理脆弱的一面。问题的表象是一条普通的建表语句迟迟无法返回结果。通过