合肥有钱兔信息科技有限公司的大数据平台，从最初支撑单一业务场景的批处理集群，到如今承载日均亿级请求的实时计算架构，中间经历过多次推倒重来的阵痛。尤其是当数据节点扩展到上百台规模后，资源调度不均、任务堆积和运维告警风暴成了最棘手的三个瓶颈。这篇文章不聊虚的，只讲我们在架构演进和运维提效上踩过的坑和最终落地的解法。

一、架构演进：从Lambda到批流一体

早期我们采用经典的Lambda架构，离线批处理跑T+1报表，实时链路用Storm处理点击流。但维护两套代码的成本实在太高，而且数据口径经常对不齐。后来我们逐步迁移到Flink + Iceberg的批流一体架构，用同一套SQL引擎处理离线和实时数据，存储层则统一落地到Iceberg的湖表格式。这个改动让开发效率提升了约40%，但真正的挑战在于状态后端和checkpoint的调优——初期我们曾因为RocksDB的block缓存配置不当，导致大窗口聚合任务频繁反压。

核心参数配置参考

• Flink作业并行度：按Kafka分区数的1.5倍设置，避免子任务间数据倾斜；
• Checkpoint间隔：生产环境建议120秒，同时开启增量checkpoint，减少对TTL的依赖；
• Iceberg表压缩：每天凌晨对快照文件执行rewrite，清理过期数据文件，否则元数据查询会越来越慢；
• 内存分配：TaskManager堆外内存占比不低于30%，否则网络缓冲和序列化容易成为瓶颈。

除了架构层面的调整，运维效率的提升更多靠规范化。我们接入了Prometheus + Grafana监控体系，但刚开始告警规则太粗放，一个节点抖动就全员打扰。后来把告警分级：P0级（数据丢失或任务失败）直接电话通知值班人，P1级（延迟超过5分钟）走IM群，P2级（资源使用率超阈值）只记录不推送。这样调整后，有效告警比例从原来的12%提升到接近70%。

二、运维自动化：把重复工作交给脚本

平台上线初期，扩容一个节点组需要手动改配置、同步jar包、重启任务，全程要花掉一个运维工程师大半天时间。现在我们把常见操作封装成Ansible Playbook和自研的CLI工具，一条命令即可完成节点上下线、配置热更新和任务漂移。举个例子，当某个broker的磁盘使用率超过85%时，系统会自动触发分区迁移并调整生产者的acks策略，整个过程无需人工介入。

常见问题与应对策略

1. 数据倾斜导致某个子任务OOM怎么办？ 先查Key分布，用自定义Partitioner打散热点键，同时开启Flink的SkewedJoin优化（仅限Flink 1.14+版本）；
2. Kafka rebalance频繁发生？ 检查消费组里的心跳线程和max.poll.interval.ms配置，通常建议将session.timeout.ms设为25秒，max.poll.records降到500条；
3. Iceberg快照文件爆炸式增长？ 设置表属性write.delete.mode=merge-on-read，并定期执行expire_snapshots清理，保留最近3天的快照即可。

在合肥有钱兔信息科技有限公司内部，我们始终强调“可观测性优先”的工程文化。无论是大数据服务还是商务信息处理，每个作业都必须暴露核心指标（处理延迟、吞吐量、错误率），否则不允许上线。这套机制落地后，线上故障的平均恢复时间从45分钟缩短到12分钟，而团队要做的，就是每天花半小时看下趋势图，提前发现问题苗头。

数字服务这块，我们也在尝试用AIOps的思路来做根因分析——把日志、链路追踪和指标数据关联起来，自动定位异常节点。虽然目前准确率只有八成左右，但已经能省下不少排查时间。互联网平台业务迭代快，技术底座如果不稳，上层再花哨的功能也是空中楼阁。运维的本质不是救火，而是通过架构设计和自动化手段，让系统自己保持健康。希望这些实践能给同行一些参考，少走点弯路。