GMG实时计算SaaS部署的5个误区

近期不少团队在把GMG实时计算引擎接入现有SaaS栈时，遇到吞吐量抖动和计费异常，排查后发现往往不是引擎本身的问题，而是部署阶段几个基础参数选得随意。这里盘点五个高频误区，帮后续项目少走弯路。

误区一：窗口粒度照搬批处理习惯

批处理时代习惯用小时级甚至天级窗口，但GMG的高并发场景下，过大的窗口会让状态快速膨胀，导致checkpoint耗时增加。正确做法是从业务真实时效倒推——如果下游看板只要求分钟级刷新，窗口就设1到5分钟，再按key的基数评估状态大小。

误区二：多源连接不做水位线对齐

GMG支持同时接入数据库CDC、日志流和第三方API推送，但不同源的数据延迟差异可能达数十秒。若直接在JOIN时使用处理时间而非事件时间，结果会静默错配。部署前应为每个源单独配置水位线容忍度，并在测试环境注入延迟样本验证。

误区三：状态后端选了默认RocksDB不调内存

默认配置适合小规模验证，一旦状态超过可用内存，频繁的磁盘读写会让p99延迟飙升。建议上线前按峰值状态量估算block cache和write buffer，必要时拆分为多个作业或启用增量checkpoint。

误区四：忽略SaaS层的出站流量计费

GMG的聚合结果推送给SaaS侧BI或告警模块时，若未开启压缩或批量发送，出站流量成本可能比计算资源还高。正确做法是启用protobuf序列化，并设置至少200条或2秒的批量窗口。

误区五：把调试日志全量打开

开发环境为排查问题常开启debug级别日志，直接沿用会造成磁盘和CPU浪费。生产部署前应分级配置：默认info，仅对特定connector开启debug，并设置日志保留期与轮转策略。