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

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

其实直到毕业的前一年，我都以为会沿着数学这条路走下去，因为自己除了数学其他啥也不会。然而数学学多了容易落入深渊，研究生的时候陷入了迷茫，虽然最后有醒悟的迹象，但由于三次博资考的失利，这条路就暂时被堵住了，戛然而止。学生时代经历了那么多场考试，最后却因为考试而不能继续学习了，想想也有点讽刺的迹象。其实以我的资质，对比周围优秀的同学，也缺乏信心能做出好的研究 ，虽然理解数学的罗塞塔石碑本身也是一种乐趣。人生总起起伏伏，生活还要继续，要找个工作先混口饭吃。

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

我是谁：经历造就自我

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

让专业的人做专业的事

由于部门之前没有做过大数据，所以最开始做数据时候，还是先从日志系统上拉取数据到本地分析。后来才开始利用公司内各种大数据平台，先将日志采集接入到数据仓库，然后利用SQL进行离线数仓分层开发，形成了极简版的数仓建设。现在各种成熟的大数据平台，上手大数据开发只需学会SQL就可以了，很简单。但对于当时处于创业阶段的项目而言，重要地是说明数据带来的价值。辛亏在充足的资源支持下，渐渐形成了麻雀虽小五脏俱全的专业团队，数据、分析、算法、后端、前端角色都在其中，解决了项目的价值问题后，项目进入了快速发展的快车道。

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

在成熟的数据团队中，数据早已体现了它的价值，需求源源不断，来自分析、算法、业务等部门，但稍不注意就容易变成取数工具人。这个时候就需要理解业务，找准业务重点方向发力。而作为数据人员，不太可能比业务人员更懂业务，需要做的是沉淀数据能力，高效率高质量地支持业务发展。然后每当面临数据建设好坏的灵魂拷问时候，却很难给出一个客观的回答，可以定义很多套评价体系, 能够满足业务发展阶段就好。另一方面，在快速支持业务中，也面临很多烟囱建设的问题，需要做很多数据治理的工作，同时也需要平衡开发效率和数据质量/安全之间的矛盾。但这基本上都是在离线数据建设链路上，实时开发依然在单独的链路上，两者结合还是有很大的机会.

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

不仅仅是SQL Boy

从数据需求类型来讲，最基础的就是提供一张表，下游再按需加工。但随着与业务走得越来越近，更多是按照场景划分：自定义分析场景，提供数据集；算法场景，拼接特征和样本；人群投放场景，丰富的标签建设支持；数据产品场景，开发数据查询接口。现在的大数据应用开发都是SQL走天下，但只做执行是没有前途的，更重要地是自己的思考和实践：结果可不可以不先预处理前置计算好，而变成查询时后置计算，更灵活些？代码可不可以不写死，而变成自定义配置，更自由些？数据可不可以不进行暴力扫描，而改成增量计算，更高效些？提出问题并解决问题才是核心竞争力，而这些都要靠时间积累以及能力沉淀。

同时，随着数据建设的愈趋复杂，治理也随之而来：计算和存储资源治理， 通过包产到户，明确个人的责任，避免吃大锅饭；数据模型治理，最好先定义后开发，完善元数据及数据质量规则管理，保证数据一致性, 防止使用误解；研发规范治理，建立健全的开发、上线、运维、变更流水线，排除显著风险；数据时效性治理，通过完善的上下线机制及链路合作优化等手段，杜绝打扰美梦！治理的工作一般都是吃力不讨好，最好可以当成一个专项来做，且需要不断完善机制, 进行持续监控治理。其实快速增长能掩饰一切问题，但随着降本增效的大环境来临，这也算是程序员的个人修养，开发和维护一样重要~

往前再走一步

究竟什么才算是技术？在工作被应用层开发和历史包袱治理充斥时常问这个问题，但一个人的性格还是难以改变的，我还是喜欢研究些新东西，不断探寻最优解。这就与实时场景比较吻合了，实时组件还在不断快速发展中，这里就有很多可以探索的机会：想实现个动态加载UDF的功能，就去研究了下Flink的类加载机制；想提升实时任务的开发效率，就引入了Flink SQL；想与Python生态联动，就引入了PyFlink，甚至研究下如何实现跨语言通信；想实现机器学习的全流程管理，就尝试了基于事件调度的AIFlow。探索就难以避免失败，有时甚至会深陷一个细节而不能自拔，虽然看起来很多工作都没什么价值，但触发思考并实践的过程也值得纪念。

另一方面，流批一体的口号已经说了多年，却很少有实际落地的场景，同时也不能算得上是最佳实践。但我想以后不会再区分实时开发和离线开发，本质其实都是从一张表到另外一张表间的加工，业界也在往这方面发展：数据湖的出现，使得状态可以外置，降低实时任务开发运维成本；面向分析的流存储出现，可以不必向分钟级延迟妥协；增量批计算的出现，统一计算模型，并能够调整计算频率来平衡延迟和成本。这些努力都朝向更简洁与统一的架构演进，希望自己也可以参与到进程当中，重塑实时开发。 到了真正成熟的一天，也许SQL Boy就不再是一句自嘲的话语吧。

要到哪里去：为何而工作

听说工作是在社会需要的技能中，找到不厌恶反感，并且能够做到的。但我理想的工作是基于自身爱好，读书时喜欢数学，就一直读了下去，找工作时喜欢技术，转眼就以此工作了5年。然而数学最终由于不够热爱而终止了，现在也感觉到了为了工作而工作的日子，失去了当初快乐工作的感受。也许也应该学会向上管理，安心卷一个好绩效就行了；也许也应该学会如何生活，为了更好的生活而工作；也许仍可以去找寻喜爱的事情，实现自己的理想和价值观。人是善变的，在不同的阶段会有不同的想法，但人生没有OKR，尽情去感受和尝试就好~

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