工作这五年，学数学的变成了搞技术的。抱着「学好数理化，走遍天下都不怕」的心态，忐忑地步入了社会。从广州到杭州再回到北京，机缘巧合下进入了大数据应用领域，先后服务于游戏、金融、广告行业。业务理解一直没什么进步，但对大数据体系的认识在一步步完善。职业发展要求从点到面地整体思考，可我的性格仍然爱钻研一个个技术细节，还是要努力走出属于自己的职业道路。

每一段的细节，记录在 我的职业生涯 里。

我从哪里来：从数学到技术

其实直到毕业前一年，我都以为会沿着数学这条路走下去，因为自己除了数学，别的什么也不会。然而数学学多了容易陷进深渊，研究生时我陷入了迷茫。虽然最后有了醒悟的迹象，但三次博士资格考试都没有通过，这条路就这样被堵住了，戛然而止。学生时代经历了那么多场考试，最后却因为考试而不能继续学下去，想想也有点讽刺。其实以我的资质，和身边优秀的同学相比，也没有信心能做出好的研究，虽然理解数学的「罗塞塔石碑」本身也是一种乐趣。人生总是起起伏伏，生活还要继续，得先找个工作混口饭吃。这段经历写在 我的数学生涯 里。

除了数学，我一直对科技比较感兴趣，于是重新选择了技术方向。数学学不懂了，但后端、算法、前端、数据这些知识，半年时间足够自学了。为了全身心投入，我还放弃了当助教的一笔收入，全力准备那个让我大展拳脚的时机。可现实很快给我浇了一盆冷水：凭学历能拿到面试机会，但你得证明自己比别人优秀的地方，而我只是一个没有任何经验的菜鸟，也不够聪明，还不背八股文、不刷算法题，只能慢慢打怪升级。一次次失败很痛苦，但只要抓住一个机会，就会否极泰来。抱着「综合利用各种工具，做出些有价值的工作」的想法，我开启了职业生涯。

我是谁：经历造就自我

学历给了我一个还算不错的起点，但工作后要靠能力说话，必须抓紧把差距追上来。最开始交给我的是两个算法问题，可我没有引路人，又缺少实际经验，只有一些理论知识，最终没做出什么成绩。也许题目确实太难了，但这道题我是真的不会呀，算法的门槛还是有点高！这时部门正好成立了数据中台项目，我有机会接触到各种大数据技术，就此走上了大数据应用之路。

让专业的人做专业的事

部门之前没有做过大数据，所以一开始做数据，是先从日志系统把数据拉到本地分析。后来才用上公司内的各种大数据平台：先把日志采集接入数据仓库，再用 SQL 做离线数仓分层开发，形成了一个极简版的数仓。现在大数据平台都很成熟，上手大数据开发只要学会 SQL 就够了，很简单。但对当时处在创业阶段的项目来说，重要的是证明数据能带来价值。幸好有充足的资源支持，渐渐形成了一支麻雀虽小、五脏俱全的专业团队，数据、分析、算法、后端、前端角色齐全。解决了项目的价值问题后，项目进入了快速发展的快车道。

其实第一个离线数仓场景的成功，更多在于挖掘出了之前没人重视的数据，真正的数仓建设能力我只学到一点皮毛。离线 SQL 写了几个月也厌倦了，刚好项目有了更多实时场景，可以学新的语言和框架，提升技术能力。实时和离线有很大不同：实时处理的输入不是事先确定好的，实时平台也不如离线平台成熟，于是有了很大的自由探索空间，在不断踩坑中慢慢形成了最佳实践。数据最终要服务用户，需要低延迟的体验，我又去研究了各种 OLAP 引擎。那段时间工作很开心，每天都能学点新技术（见 我所了解的 Flink）。但随着降本增效到来，业务停止了扩张，找不到有意思的活了；毕竟也不是在专业的数据团队里，是时候去看看更大的世界了。

在成熟的数据团队里，数据早已证明了自己的价值，需求源源不断，来自分析、算法、业务等各个部门，可一不留神就容易变成「取数工具人」。这时就需要理解业务，找准业务的重点方向发力。作为数据人员，不太可能比业务人员更懂业务，要做的是沉淀数据能力，高效率、高质量地支持业务发展。每当面对「数据建设得好不好」的灵魂拷问时，却很难给出客观的回答：可以定义很多套评价体系，能满足业务发展阶段就好（我的思考写在 我的数据体系 里）。另一方面，快速支持业务时也会出现很多「烟囱」式的重复建设，需要做很多数据治理，还要平衡开发效率和数据质量、安全之间的矛盾。不过这些基本都发生在离线链路上，实时开发依然是单独的一条链路，两者的结合还有很大的机会。

现在，我应该算是专业做数据的了：就像整理图书馆的书籍一样把数据准备好，为随时翻开它的人做好准备。

不仅仅是 SQL Boy

从需求类型看，最基础的是提供一张表，下游再按需加工。但离业务越来越近之后，需求更多是按场景划分的：

现在的大数据应用开发都是 SQL 走天下，但只做执行是没有前途的，更重要的是自己的思考和实践：

• 结果可不可以不预先算好，而是在查询时再算，更灵活一些？

• 代码可不可以不写死，而是变成自定义配置，更自由一些？（Flink Dynamic SQL）

• 数据可不可以不暴力扫描，而是增量计算，更高效一些？（消灭暴力扫描，世界属于渐进）

提出问题并解决问题才是核心竞争力，而这要靠时间的积累和能力的沉淀。

同时，数据建设越来越复杂，治理也随之而来：

• 计算和存储资源治理：「包产到户」，明确个人的责任，避免吃大锅饭；

• 数据模型治理：最好先定义、后开发，完善元数据和数据质量规则，保证数据一致，防止误用；

• 研发规范治理：建立健全的开发、上线、运维、变更流程，排除明显的风险；

• 数据时效治理：通过完善的上下线机制和链路优化等手段，杜绝半夜被叫醒！

治理工作一般吃力不讨好，最好当成一个专项来做，并不断完善机制、持续监控。快速增长能掩盖一切问题，但降本增效的大环境来了，这也算是程序员的个人修养：开发和维护一样重要。

往前再走一步

究竟什么才算技术？在工作被应用层开发和历史包袱治理填满时，我常问自己这个问题。但一个人的性格很难改变，我还是喜欢研究新东西，不断探寻最优解。这和实时场景比较契合，实时组件还在快速发展，有很多可以探索的机会：

• 想实现动态加载 UDF，就去研究了 Flink 的类加载机制；

• 想提升实时任务的开发效率，就引入了 Flink SQL；

• 想和 Python 生态联动，就引入了 PyFlink，甚至研究了怎么实现跨语言通信（Java 调用 Python）；

• 想实现机器学习全流程管理，就尝试了基于事件调度的 AIFlow。

探索难免会失败，有时甚至会陷在一个细节里不能自拔。很多工作看起来没什么价值，但引发思考并付诸实践的过程，也值得纪念。

另一方面，流批一体的口号喊了很多年，真正落地的场景却很少，也算不上最佳实践。但我想，以后不会再区分实时开发和离线开发，本质都是从一张表加工到另一张表。业界也在往这个方向发展：

• 数据湖的出现，让状态可以外置，降低了实时任务的开发和运维成本；

• 面向分析的流存储出现，可以不必再向分钟级的延迟妥协（Fluss：重塑实时开发）；

• 增量批计算的出现，统一了计算模型，并能通过调整计算频率来平衡延迟和成本。

这些努力都朝着更简洁、更统一的架构演进，希望自己也能参与其中，重塑实时开发。到了真正成熟的那一天，也许「SQL Boy」就不再是一句自嘲了。

要到哪里去：为何而工作

听说，工作就是在社会需要的技能里，找一个自己不厌恶、而且做得到的。但我理想中的工作是基于自己的爱好：读书时喜欢数学，就一直读了下去；找工作时喜欢技术，转眼就靠它工作了五年。然而数学最终因为不够热爱而终止了，现在也感觉到了「为了工作而工作」的日子，失去了当初快乐工作的感觉。

也许应该学会向上管理，安心卷一个好绩效；也许应该学会生活，为了更好的生活而工作；也许仍然可以去寻找喜欢的事情，实现自己的理想和价值。人是善变的，不同阶段会有不同的想法，但人生没有 OKR，尽情去感受和尝试就好。

哎哎，这人一看就是工作不饱和，天天想东想西的，得给他上些强度，溜了溜了～