作者的话：这篇文章分享一个"做减法"的真实案例。在数据工程领域，该团队总想着怎么把更多数据接进来，但有时候，砍掉一个不稳定的数据源，比优化十个稳定的数据源更有价值。这不是技术妥协，而是架构决策。
一、背景
某医疗集团的数据中台项目需要从7个院区的数据库中采集病历、检验、处方等核心数据。7个院区中，6个部署在阿里云RDS上，1个（代号为"远郊院区"）部署在本地IDC机房。
初始架构：
| 系统 | 部署方式 | 网络 | 状态 |
|---|---|---|---|
| 城东院区 | 阿里云RDS | 内网 | ✅ 稳定 |
| 城南院区 | 阿里云RDS | 内网 | ✅ 稳定 |
| 城北院区 | 阿里云RDS | 内网 | ✅ 稳定 |
| 城西院区 | 阿里云RDS | 内网 | ✅ 稳定 |
| 中心院区 | 阿里云RDS | 内网 | ✅ 稳定 |
| 总院系统 | 阿里云RDS | 内网 | ✅ 稳定 |
| 远郊院区 | 本地IDC机房 | VPN公网 | ❌ 极不稳定 |
看起来只是1/7的问题？实际上这个1/7差点搞垮了整个项目。
二、踩坑实录
2.1 第一次翻车：VPN链路抖动
远郊院区通过VPN连接到数据中台，网络延迟在50ms~5000ms之间随机跳动。第一次跑增量同步，在采集远郊数据时直接超时：
2026-03-15 02:15:33 - ERROR - 从 suburban 获取增量数据失败: (2013, 'Lost connection to MySQL server during query')
2026-03-15 02:15:33 - ERROR - 增量同步失败
整个同步流程在凌晨2点15分就挂了，后面6个云上院区的数据一个都没采。
2.2 第二次翻车：重试机制也救不了
加了重试机制，最多重试3次，每次间隔5秒：
max_retries = 3
for attempt in range(max_retries):
try:
data = fetch_from_source('suburban')
break
except Exception as e:
if attempt < max_retries - 1:
time.sleep(5)
else:
raise
结果3次重试全部失败，因为VPN链路一旦抖动，通常持续10-30分钟，5秒的重试间隔根本等不到恢复。
2.3 第三次翻车：容错隔离后依然痛苦
把远郊院区改为容错模式——失败了跳过，不影响其他院区：
try:
data = fetch_from_source('suburban')
except Exception as e:
failed_regions.append('suburban')
continue
同步流程不卡了，但新的问题来了：
- 远郊院区数据经常缺失，下游报表对不上数
- 每次补数据都要手动连VPN，运维成本极高
- 凌晨同步失败后，白天门诊高峰期不敢重跑（影响HIS系统性能）
- 院长每周追问"远郊院区数据什么时候能稳定"
一个月下来，30天里有22天远郊院区数据采集失败，成功率仅26.7%。
三、决策过程
3.1 数据价值评估
| 指标 | 远郊院区 | 其余6个院区合计 |
|---|---|---|
| 病历数据量 | 约8000条/月 | 约12万条/月 |
| 数据占比 | 6.25% | 93.75% |
| 采集成功率 | 26.7% | 99.2% |
| 运维投入占比 | 约40% | 约60% |
结论：远郊院区数据仅占6.25%，但消耗了40%的运维精力，投入产出比极低。
3.2 技术方案对比
| 方案 | 投入 | 预期效果 | 风险 |
|---|---|---|---|
| A. 专线接入 | 约15万/年 | 网络稳定 | 成本高，需IDC配合 |
| B. 消息队列中转 | 约3万/年 | 解耦采集 | 需改造HIS系统 |
| C. 离线文件传输 | 约0.5万/年 | 避开实时网络 | 数据时效性差 |
| D. 暂时剔除 | 0 | 消除不稳定因素 | 数据缺失6.25% |
3.3 最终决策
选择方案D：暂时剔除远郊院区。
决策依据：
- 6.25%的数据缺失不影响核心业务决策
- 消除不稳定因素后，剩余93.75%的数据采集稳定性从85%提升到99%+
- 节省的运维精力可以用来优化核心数据链路
- 等远郊院区迁移上云后，再重新接入
四、实施效果
4.1 代码变更
# Before: 7个源院区
self.source_regions = ['east', 'south', 'north', 'west', 'central', 'main', 'suburban']
# After: 6个源院区，远郊院区暂时排除
self.source_regions = ['east', 'south', 'north', 'west', 'central', 'main']
# 注：远郊院区待迁移上云后重新接入
4.2 效果对比
| 指标 | 剔除前 | 剔除后 |
|---|---|---|
| 日均同步成功率 | 73.3%（22/30天失败） | 99.2%（几乎不失败） |
| 运维工单数 | 约15单/月 | 约2单/月 |
| 数据完整性 | 93.75%（远郊经常缺） | 93.75%（稳定缺失） |
| 团队精力分配 | 40%处理远郊问题 | 100%聚焦核心链路 |
关键洞察：剔除前后数据完整度都是93.75%，但质量完全不同——之前是"时有时无"的不确定缺失，之后是"确定缺失"，下游可以明确标注并处理。
五、反思与总结
5.1 什么时候该"做减法"
- ❌ 不该砍：数据占比大（>20%）、有替代方案、短期可修复
- ✅ 应该砍：数据占比小、根因在基础设施、短期无法解决、运维成本远超数据价值
5.2 "确定缺失"优于"不确定完整"
这是这篇文章最核心的观点。在数据工程中：
确定缺失的数据 → 下游可以标注、降级、兜底处理
不确定完整的数据 → 下游永远不知道今天的数据能不能用，这才是最大的问题
5.3 剔除不是放弃
在代码中保留了远郊院区的配置，只是暂时注释掉。等远郊院区迁移上云后，取消注释即可重新接入，零代码改动。
💡 一句话总结：在数据工程中，有时候最好的优化不是加机器、加代码，而是勇敢地砍掉那个一直在拖后腿的数据源。确定性的缺失，远比不确定的完整更有价值。
如果这篇文章让你有所启发，点赞收藏是对作者最大的鼓励~ 评论区聊聊你遇到过类似的"做减法"决策吗？
世局板块
1.【俄乌冲突】扎波罗热核电站遇袭，核安全红线再受挑战 当地时间5月30日，扎波罗热核电站遭遇自2024年4月以来首次厂区无人机袭击。一架乌克兰无人机攻击了6号发电机组电机房，导致墙体破损，所幸未造成人员伤亡及核心设备损坏。目前电站运行正常，辐射水平稳定。国际原子能机构已要求进入现场检查，俄方强烈谴责此次触碰核安全红线的行为。
2.【科技环保】谷歌拟在美释放3200万只蚊子遏制病毒 谷歌旗下Verily公司计划未来两年在美国加州和佛罗里达州释放3200万只携带特殊细菌的雄性蚊子。通过“昆虫不相容技术”，使野生雌蚊后代无法孵化，从而从源头遏制西尼罗河病毒等疾病传播。该方案此前在新加坡试点成效显著。目前，该计划正等待美国环保署（EPA）的最终实验许可。
3.【中东局势】黎以边境战火升级，以北部遭密集袭击 5月30日，黎以边境冲突急剧恶化。黎巴嫩真主党为回应以军军事扩张，对以色列北部加利利地区发动22次袭击，发射数十枚火箭弹及无人机，以军证实部分被拦截，当地有建筑受损。目前，以军已越过利塔尼河向北推进，并将宰赫拉尼河以南划为“战区”，双方处于持续交战状态。
4.【中国制造】国产LNG运输船打破垄断，核心技术自主可控 我国最新一代大型LNG运输船“乔治敦”号正式交付，标志着大型LNG船核心货舱系统实现100%国产化配套，整船国产化率提升至80%，彻底打破海外垄断。该船建造周期压缩至16个月，单船可满足330万户家庭一月用气。目前中国船企手持近60艘订单，排期已至2030年。
