大数据技术研发：那些年，我们踩过的坑与意外的惊喜
搞大数据技术研发快十年了，说实话，很多时候感觉自己就像个在迷雾里搭积木的人——好不容易搭稳了一层，底层又告诉你存储格式要换，或者计算引擎又双叒叕升级了。累吗？当然。但有意思吗？也确实有。
最近跟几个老伙计喝酒，聊起各自公司在大数据上的折腾，发现大家的心路历程出奇地相似。从 Hadoop 的黄金时代到 Spark 的异军突起，再到现在 Flink 满天飞、数据湖遍地开花……哦对了，还有 AI 像个不讲理的邻居，随时踹门闯进来要跟大数据联姻。
今天不是要写什么技术选型指南，那种东西网上已经烂大街了。就想随意聊聊，在研发一线摸爬滚打时那些真实的、有时候让人想骂街、有时候又觉得“哎哟不错哦”的瞬间。
大数据实时流处理Flink任务监控界面
不过话说回来，实时计算也有它高光的时刻。有一次我们上线了一个实时异常检测模型，成功预警了羊毛党的批量刷单行为，给公司挽回了大几百万的损失。那一刻，所有熬过的夜都值了。但冷静下来想想，这种场景真的需要全链路实时吗？很多业务其实还没到那个份上，强行实时，反而会引入不必要的复杂度和成本。
数据湖技术架构中Hudi小文件合并过程示意图
我还发现一个怪象：很多团队上了数据湖之后，反而把数据治理搞得更乱。以前在数仓里，表的归属、生命周期、元数据管理好歹有套规矩；到了湖里，因为“灵活性”被无限放大，结果变成数据沼泽，找数据比写代码还费劲。所以啊，技术本身没有原罪，但脱离了组织和流程的配套，再时髦的架构也只是空中楼阁。
AI 和大数据联姻，生出来的是怪物还是贵子？
现在没人能绕开 AI 谈大数据。尤其是大模型火了之后，我们这帮搞数据研发的突然又被推到了舞台中央——因为模型训练需要海量高质量数据。说实话，这感觉挺复杂的。一方面，我们的工作价值被空前认可；另一方面，数据工程的压力直接拉满。
以前我们给分析师出报表，延迟个把小时可能还没人太在意。但现在给模型供特征，延迟超过一分钟，训练任务可能直接就失败了。而且对数据质量的要求严苛到了变态的程度：特征不能有半点缺失，分布必须稳定，甚至字段的中文别名不一致都能导致模型效果抖动。我们被迫搞起了数据版本化和特征存储（Feature Store），把特征像代码一样管理起来，每次变更都要走 CI/CD。
不过也有惊喜。有一次我们利用大模型自动生成 SQL 脚本，把原本需要两天的手工ETL开发压缩到了两个小时，准确率竟然高达90%以上。那一刻我突然觉得，AI 不是来砸饭碗的，而是来把我们从重复劳动里解放出来的。但前提是，你得自己先学会驾驭这头猛兽。未来，不会用 AI 的数据工程师，可能真的会被淘汰。
技术这条路，永远不会有终点。刚以为踩实了一块地，下一脚就可能踏空。但正是这种不确定性，让研发这件事始终保持着某种危险的魅力。深夜一个人对着监控大盘发呆时，偶尔会有种错觉：我们不是在建系统，而是在摸索一整个数字世界的底层脉动。
管它呢，先搞定这周的 oncall 再说。
都在谈实时，但实时真的那么美吗？
我记得特别清楚，2018年的时候，老板在一个大会上听了某大厂的分享，回来就跟打了鸡血似的，说我们要 all in 实时计算。当时我们连批处理链路都还没完全理顺，就要上 Flink 搞实时数仓。那段时间，团队几乎住在机房，因为实时链路的数据一致性简直是个玄学——上游 Kafka 一条消息迟到三分钟，下游指标就全歪了；状态后端偶尔来个反压，整个 job 像便秘一样卡住，然后突然又洪水般涌出，直接把下游冲垮。 最搞笑的是一次大促，实时大屏的 GMV 突然比离线报表少了整整 20%，整个业务方都炸了。我们排查了一夜，最后发现是窗口触发机制在极端流量下漏算了一批数据。你看，实时计算最骗人的地方就是那个“实时”二字——它让你以为一切尽在掌握，但其实数据的准确性、一致性，在 lambda 架构下依然是笔糊涂账。大数据实时流处理Flink任务监控界面
不过话说回来，实时计算也有它高光的时刻。有一次我们上线了一个实时异常检测模型，成功预警了羊毛党的批量刷单行为，给公司挽回了大几百万的损失。那一刻，所有熬过的夜都值了。但冷静下来想想，这种场景真的需要全链路实时吗？很多业务其实还没到那个份上，强行实时，反而会引入不必要的复杂度和成本。
数据湖就一定是灵丹妙药？别扯了
这两年“数据湖”三个字真是听得耳朵起茧。似乎不建个湖，就不好意思说自己是做数据的。特别是湖仓一体的概念被炒热之后，更是一堆厂商跟风推方案。但真正落地做过的人都知道，那里面坑多得能养鱼。 我们公司当初选型数据湖，看中了 Apache Hudi 的 upsert 能力和流读支持。结果呢？第一次做全量初始化，就遇到了小文件问题——几百万个小文件躺在湖底，查询性能比传统数仓慢了不止一个数量级。后来用 compaction 拼命合并，结果合并任务本身又引发了资源争抢，简直是个死循环。更头疼的是模式演化（schema evolution），当一个上游业务表加了字段，下游所有用到这张表的作业都得小心翼翼地适配，稍有不慎就整个 pipeline 雪崩。数据湖技术架构中Hudi小文件合并过程示意图
我还发现一个怪象：很多团队上了数据湖之后，反而把数据治理搞得更乱。以前在数仓里，表的归属、生命周期、元数据管理好歹有套规矩；到了湖里，因为“灵活性”被无限放大，结果变成数据沼泽，找数据比写代码还费劲。所以啊，技术本身没有原罪，但脱离了组织和流程的配套，再时髦的架构也只是空中楼阁。
AI 和大数据联姻，生出来的是怪物还是贵子？
AI 和大数据联姻，生出来的是怪物还是贵子？
现在没人能绕开 AI 谈大数据。尤其是大模型火了之后，我们这帮搞数据研发的突然又被推到了舞台中央——因为模型训练需要海量高质量数据。说实话，这感觉挺复杂的。一方面，我们的工作价值被空前认可；另一方面，数据工程的压力直接拉满。
以前我们给分析师出报表，延迟个把小时可能还没人太在意。但现在给模型供特征，延迟超过一分钟，训练任务可能直接就失败了。而且对数据质量的要求严苛到了变态的程度：特征不能有半点缺失，分布必须稳定，甚至字段的中文别名不一致都能导致模型效果抖动。我们被迫搞起了数据版本化和特征存储（Feature Store），把特征像代码一样管理起来，每次变更都要走 CI/CD。
不过也有惊喜。有一次我们利用大模型自动生成 SQL 脚本，把原本需要两天的手工ETL开发压缩到了两个小时，准确率竟然高达90%以上。那一刻我突然觉得，AI 不是来砸饭碗的，而是来把我们从重复劳动里解放出来的。但前提是，你得自己先学会驾驭这头猛兽。未来，不会用 AI 的数据工程师，可能真的会被淘汰。
技术这条路，永远不会有终点。刚以为踩实了一块地，下一脚就可能踏空。但正是这种不确定性，让研发这件事始终保持着某种危险的魅力。深夜一个人对着监控大盘发呆时，偶尔会有种错觉：我们不是在建系统，而是在摸索一整个数字世界的底层脉动。
管它呢，先搞定这周的 oncall 再说。