鸿蒙工程师跨界创业：18年数仓老兵的资源整合实战

　　去年过年时，我原以为能安生歇几天，结果被个鸿蒙工程师拉去当“资源整合顾问”——他创业搞了个IoT平台，数据侧全乱套了。这哥们干了六年鸿蒙开发，去年突然说要跨界，我第一反应是“你丫连ETL都没摸过，搞数仓？”。他倒理直气壮：“我找了三个外包团队，结果他们连实时同步都搞不定，现在数据延迟俩小时，用户投诉都炸了。”

　　我去了他办公室，风扇一直在转，屏幕上的行数跳得比心跳还快。他指着监控大屏说：“你看，设备上报的数据全卡在Kafka，消费组积压了八百万条。”我凑近瞅了眼，消费组状态是“REBALANCING”——这他妈是典型的消费者崩溃后重平衡卡死。我转头问他：“你们谁写的消费者代码？”他挠头：“外包写的，说是参考了Spring Cloud Stream的官方示例。”我冷笑：“官方示例是单线程消费，你设备量一上来，积压不卡才怪。”

文章配图，仅供参考

　　改完参数，积压数开始往下掉，但速度慢得离谱。我查了消费组的线程数——默认单线程。我让他把`spring.cloud.stream.kafka.binder.configuration.concurrency`调成“16”，结果他直接改成“100”。我骂：“你当这是并发测试啊？消费者线程数超过分区数，多余的线程只会空转！”他反驳：“分区数不是能动态扩容吗？”我指了指Kafka集群监控：“你集群总共才二十个分区，扩容要重启Broker，现在生产环境敢动？”他缩了缩脖子：“那…那调成20？”

　　窗外天黑了，外卖凉了，积压数终于清零。鸿蒙工程师松了口气：“还是你们数仓老兵厉害，这要是靠外包，估计得卡到明年。”我撇嘴：“厉害个屁，优胜劣汰懂吗？你们这项目要是早让我介入，根本不会有这堆破事。”他点头：“是是是，下次一定。”我补刀：“还有下次？你数仓侧连个备份策略都没有，万一主库挂了，数据全丢，哭都来不及。”

　　他愣住：“备份？我们没做啊，主从同步不是自动的吗？”我差点摔键盘：“主从同步是防硬件故障的，不是防人为误操作的！上周你们开发是不是删了个测试表？结果同步到从库，把线上数据也删了？”他挠头：“好像是有这事…但后来恢复了。”我冷笑：“恢复？那是运气好，主从延迟低，删表操作还没同步过去。要是延迟高，或者从库挂了，你拿什么恢复？”他小声问：“那…现在补备份来得及吗？”我叹气：“来得及，但得改架构——主从同步+定时全量备份+binlog增量备份，三重保险。”他点头：“行，你写方案，我让外包改。”我瞪他：“外包改？他们连备份策略都写不明白，还是我亲自来吧。”

　　第二天，我让他把所有数据表的结构导出来，结果发现字段类型乱得离谱——有的设备ID用`VARCHAR(32)`，有的用`BIGINT`；时间戳有的用`DATETIME`，有的用`TIMESTAMP`，还有的用`UNIX_TIMESTAMP`。我指着屏幕骂：“你们这是数仓还是垃圾场？字段类型不统一，查询怎么优化？ETL怎么跑？”他辩解：“外包说这样方便，不同设备的数据格式不一样。”我拍桌子：“不一样就统一转换！数仓的核心是标准化，不是迁就原始数据！”他低头：“那…现在改还来得及吗？”我叹气：“来得及，但得重新设计ETL流程，把字段转换逻辑写死。”他问：“要多久？”我算了算：“至少两周，还得测。”他挠头：“两周…用户等不及啊。”我翻白眼：“早干嘛去了？现在知道急了？”

　　改完字段类型，我让他把历史数据重新加载一遍，结果加载到一半，主库突然挂了。运维小哥冲进来：“CPU 100%！连接数爆了！”我查了下慢查询日志——全是全表扫描。原来外包写的ETL脚本里，有个`SELECT FROM device_data`，没加任何条件。我骂：“这他妈是ETL还是自杀？全表扫描几亿条数据，不挂才怪！”鸿蒙工程师擦汗：“那…现在怎么办？”我咬牙：“先杀掉慢查询，再优化脚本——加分区键，加索引，限制查询范围。”他问：“能恢复吗？”我点头：“能，但得停机维护。”他犹豫：“停机…用户会骂的。”我瞪他：“不停机，数据全丢，用户骂得更凶！”

　　停机维护了两小时，数据终于恢复正常。鸿蒙工程师松了口气：“还是你们数仓老兵靠谱，这要是靠外包，估计得凉。”我冷笑：“靠谱？优胜劣汰懂吗？你们这项目要是早按数仓的规矩来，根本不会有这堆破事。”他点头：“是是是，下次一定。”我补刀：“还有下次？你们数仓侧连个监控都没有，万一再出问题，连根因都找不到。”他愣住：“监控？我们没做啊，外包说没必要。”我差点吐血：“没必要？你们这是创业还是过家家？监控是数仓的生命线，没有监控，出了问题只能抓瞎！”他小声问：“那…现在补监控来得及吗？”我叹气：“来得及，但得改架构——Prometheus+Grafana，实时监控CPU、内存、磁盘、连接数、慢查询，报警规则得写死。”他点头：“行，你写方案，我让外包改。”我瞪他：“外包改？他们连监控指标都搞不明白，还是我亲自来吧。”

　　现在回头看，这鸿蒙工程师跨界创业，最大的问题不是技术，是认知——他以为数仓就是“存数据”，没意识到是“管数据”。优胜劣汰的规则在数仓里更残酷：你糊弄数据，数据就糊弄你。至于下一步？我打算让他把所有ETL脚本都过一遍，把慢查询全杀了——但我知道，他大概率还是会找外包，然后等我来救火。算了，谁让我是18年数仓老兵呢？救火，也是我的命。

（编辑：站长网）

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