大数据架构师必懂的5个实时计算技术要点

　　去年清明节，我蹲在公司茶水间改 Flink SQL，手机弹出备案驳回通知——不是我的，是客户那个实时风控链路的域名。客服说“审核周期预计七到十个工作日”，我心想七天？我昨天刚把 Kafka 从 2.8 升到 3.5，今天它就吐了两万条重复 offset，连 ConsumerGroup 都懒得重平衡。我原以为换云厂商能躲过超售，结果新集群里三个 broker 跑着四个业务方的实时作业，YARN UI 上 Resourcemanager 直接飘红，CPU 图形跟心电图似的，一跳一停。

　　提交工单那天下午三点十七分，孩子突然撞开茶水间门，举着半块化掉的雪糕问我“爸爸你手机怎么一直在响”，我顺手按掉，再点进去填工单表单，第三步卡在“问题分类”下拉框——里面没“实时计算任务莫名被 YARN 杀掉”这个选项，只有“实例异常”“费用问题”“备案协助”。我点了“实例异常”，又退回重选，鼠标垫左边翘起来了，手指蹭过去毛刺扎得慌。窗外开始下雨，雨点砸在玻璃上斜着往下淌，像 Kafka 消费者 lag 的曲线图。

　　工单写完点了提交，页面转圈五秒，弹出“已受理”，底下小字：“您的问题将由智能客服优先响应”。我盯着那行字盯了四十秒，点开聊天窗口，机器人说：“亲，检测到您咨询的是实时计算相关问题，请问是否需要了解 Flink on YARN 部署最佳实践？”我回：“不，我要查为什么十分钟前刚提交的作业被自动 kill。”它回：“为您推荐知识库第721条：《如何优雅地处理 TaskManager OOM》。”我没点开，直接关了。外卖盒搁在桌面右下角，汤面早凉透，浮着一层油皮。

　　第二天早上九点，运维老张甩来截图：他们自建的 Flink 集群昨晚凌晨两点触发了 checkpoint 超时，CheckPointing failed due to timeout, but the job is still running —— 就这句日志，跑满三台机器的 metrics 界面。老张说：“他们家控制台连失败原因都不标红，灰扑扑写着‘checkpoints in progress’，看着像还活着。”我截图发给客户技术负责人，他回了个“？？？”，三分钟后又补一句：“你们之前不是说用的是托管版 Flink 吗？”

文章配图，仅供参考

　　我原以为托管版至少能屏蔽掉 TaskManager 的 JVM 参数魔改风险。结果上个月客户想加个 window function，我们调优调到凌晨一点，发现平台默认给每个 TM 分配的堆外内存只有 512MB，而下游 Redis 实例连的是公网 endpoint——连 DNS 解析都要耗掉三百毫秒。我没敢说，只让测试同事复现三次，每次都在 window 触发那一刻断连。测试同事说：“就像你在电梯里按关门键，门刚动，断电。”

　　还有快照备份要另外收费这事，去年十一我就踩过。客户临时要回溯三天前的实时埋点流量，我提了 restore 请求，后台显示“快照不可用”，联系客服，对方说：“哦，您没开通冷备加速包。”我说：“冷备加速包是啥？”她说：“就是让快照读取速度更快的服务。”我说：“可我只是要还原一个 checkpoint。”她顿了三秒：“那…您也可以选择基础冷备，但恢复时间大概在八小时左右。”我挂了电话，顺手删了邮件草稿里那句“建议贵司开放 checkpoint 原始存储路径权限”。

　　上上周，代理商王总请吃饭，在西直门那家铜锅涮肉，他说：“咱们这系统，跑得比备案审核快，死得比实名认证快。”旁边新来的实习生听愣了，筷子上羊肉片掉进蘸料碗里，溅起一点麻酱。我笑了下，没接话。倒想起98年第一次买虚拟主机，付完款等了两天，客服打电话来说：“您网站上线啦！”我说：“在哪看？”他说：“打开 IE，输 ftp:// 加您域名。”我说：“……那不是 FTP 列表吗？”他说：“对啊，咱不支持 HTTP。”

　　现在轮到我听客户讲类似的话。前天电话里，客户CTO说：“你们能不能把 Flink Dashboard 的 /joboverview 页面，别强制走他们家的 SSO？我们用 Keycloak。”我嗯了一声，挂了之后翻文档，发现他们的 API Gateway 硬编码了 /flink/login 路由，连 OAuth2 redirect_uri 都不允许自定义。我原以为这种事早淘汰了，结果去年底还有人在生产环境配 nginx 做 header 注入去绕过 SSO 验证。我试过一次，configmap 里写错个空格，整个作业管理页白屏，错误提示是“network error”，F12 看 Network 标签页，果然是请求 /api/flink/login 返回了 404，但状态码显示为 200。

　　最绝的是迁移限制。客户想把实时用户行为流迁到自建 K8s，我导出作业配置 JSON，发现里面硬写了 vendor-specific 的 connector 插件类名：com.xxx.cloud.flink.connector.kafka.XxxKafkaSource。我把 Xxx 换成 Apache，作业直接报 NoClassDefFound。我发工单问能不能提供 open connector 标准实现，客服回复：“感谢您的反馈，该需求已进入排期池。”我查了他们官网更新日志，上一次“排期池”相关变更，是前年夏天。

　　跑路倒是没跑，但有两次续费涨价涨了两百多。账单邮件里写“因底层资源优化调整”，附链接指向一篇叫《关于实时计算资源动态分配机制升级的说明》的文档——点进去前三段全是“致力于”“赋能”“闭环”，第四段才提了一句：“计费粒度由每小时细化为每五分钟。”我没截图，怕传群里被当成段子。隔壁组老李看到后说：“他们上次‘优化’，是把 Spark 作业日志压缩从 gzip 换成 lzo，然后说‘大幅降低存储成本’。”他当时笑得饭粒喷到键盘上。

　　我其实不确定是不是该全切出去。上周五和架构部开会，讨论要不要把实时链路全抽出来，用裸 Flink + 自建 Prometheus + AlertManager。技术上当然行。可谁扛审核周期？谁陪客户对着工信部那个破备案系统填二十遍法人身份证正反面？谁半夜三点接客服电话听“正在为您转接智能语音…”？我不知道。我只知道明年到期就迁走，哪怕自己搭一套裸机集群，装完 JDK 再装 Hadoop，最后把 flink-conf.yaml 里的 state.checkpoints.dir 改成本地路径——至少 checkpoint 不会某天早上突然“不可用”。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!