前沿
今天的文章是大数据提高班中的一个同学的真实分享。
为什么我必须让这个同学分享个人经历，很重要的一个原因是，个人接触过非常多的前来咨询的同学，语言中充斥着不自信，没有作出改变的决心，那么没人帮得了你。
我不明白，为什么大家都在谈论着我个人背景、履历不好，彷佛这个行业对你个人注定了凶多吉少。我经常反问对方的一个问题是，你个人为未来的改变作出过哪些努力和下定了哪些决心？
我们小组的其他老师在这个过程中真是被这个小哥卷到了，经常到凌晨还在群里讨论问题，结果是应得的，下面👇是本次分享的全部内容。
天崩开局
「我曾深深爱过你，但那只是过去的事。」
首先讲一下我的个人背景：双非二本&考研失败，春招时由于年少无知错选了一家项目外包的公司。由于一些个人原因，在当初加入这家公司的时候，实际上我是做过一些与DMC数据建模相关的工作。但在试用期结束之后公司方面也没有经过我的个人同意，直接给我分到了一个运维的岗位上。
当时被领导画饼，在这个岗位上能够接触到很多"先进"的大数据技术栈，并且后期会安排很多研发类的工作，有利于个人的晋升。出于摆烂心理+第一次参加工作，我在2022下半年~2024上半年一直就在这个岗位做运维，而实际上答应的晋升、加薪，包括一些研发类的画饼仅仅被一句"部门预算紧张，要多为公司着想"就被一笔带过。
和大家讲这些的目的是什么呢，我相信很多正在求职或者有求职想法的同学，一定或多或少有过与我类似的经历。我希望大家在这个阶段先坚定一下自己的想法，即在"去"或者"留"上做个决断。一份工作，如果对个人发展、薪资晋升没有任何帮助的话，站在我的视角去看这份工作是没有意义或者价值的。衡量好去或者留的问题，然后逐步就要开始准备学习的资源。
初次接触
「世界奔流不息，而你止步不前。」
8月考完OCP相关的证书，开始重新思考未来的发展问题。SRE or 数据BP？基于我当前的情况来讲，首先在我前东家工作的时间内，对于ELK 链路追踪相关的技术是完全不了解的。何为草台班子呢，大概就是那种服务出现故障，只能通过awk截获日志然后百度的那种（笑）。而且从年限上来说，一个两年的SRE，在就业市场上也是完全不吃香的，所以SRE这条路只能放弃。那么问题又来了，数据BP，我完全没有实施经验。我对数仓建设的印象还停留在本科期间竞赛的经历里，对于技术栈&业务sense基本上是没有概念的。
所以问题显而易见：
从哪里学习一套成熟的企业解决方案？
我如何证明我的工作对于公司是存在价值的？
抱着以上两个问题，我在B站搜索数仓相关的学习资料。得到的结果大多也是以demo、轮子相关的居多。要知道社招这件事，我们不只是要证明，我用过某某技术栈，我hive sql写的多溜那么简单。我们需要具备一套闭环的思维，按照论文的结构：什么场景、做了什么、取得什么成效,用以上方式去阐述我们的工作，才是站得住脚的。最后经过我一番搜罗，发现了这个视频，也成为了这段经历开始的地方。感兴趣的小伙伴可以点击这个视频进行学习，尽管是22年的视频，但是好的思路是永远不会过时的（这里的视频是我发在B站和视频号的视频，B站直接搜：大数据卷王_王知无）。
视频中对于简历和面试回答的一些锐评和见解，简直完美戳中我的痛点。我相信能够形成一套自己的闭环思路的，绝不是培训班引流那么简单。抱着试试看的想法，我加了王老师的微信并发送了简历过去。王老师当天晚上和我在视频会议里简单聊了一下相关的问题。即：从一个数据开发周期去出发，你需要去了解哪些，去补充哪些知识，来论证你的简历和项目，有去实施和迭代的必要性，以及如何评估。基于以上问题，王老师针对性的对我的简历提出了修改意见和学习建议。我的履历基本上分成三块去进行论述：xx，作为基本盘，是必须拿下的得分;xx，作为技术亮点，按照王老师的项目以及学习路线，封装成自己的一套场景解决方案;xx，作为拔高点，需要体现出自己的技术视野比较前沿(内容涉及部分提高班项目和业务，xx代替)。
学习经历
「我的道路没有岔口，因为未来早已笃定。」
经过王老师对我个人情况制定了个人的学习计划之后，按照给出的资料，就要开始进行项目学习了。我这边采用的模式是one by one的思路。即学习完一个项目，根据自己的业务背景+提高班项目中提到的关键建设点，从0到1自己设计一版简易的数据模型+技术链路。
这里以我第一个项目进行举例。
在学习第一个xx相关项目的时候，对数仓架构、模型设计、数据质量、元数据管理、数据服务几个方面，按照项目中问题-方案-成效三段式的方式记好笔记。然后结合自己的实际业务背景来分析，当前公司内对数据建设的现状，有哪些是与xx项目中的方向是一样的，有哪些是缺失的。如果是方向一致的，都实现了具体哪些的建设，哪些没有做到。如果是缺失的，考虑是否有建设的必要性，以及该如何去实现。整体按照1级-2级-3级的模式对建设方向需要的工作进行逐步拆解，并且结合自己的业务分析矩阵。确定自己的主题域、事实维度、颗粒度、度量值这些考虑因素，从业务+技术双方面拿捏xx。
项目二和三内容深度上更加深入，不详细展开了。
简历编写
「我掌中的不止是力量，也是打破桎梏的钥匙。」
当我们把自己的项目，按照技术+业务两个方面进行整合之后，就可以开始对初步的简历内容进行编辑。第一个阶段我们要做的是"多"。即我在我的项目中，我都做了什么工作，我对自己的要求就是一条一条全部都列出来。
然后，根据我列出来的这些点，要学会自我拷打这个过程，因为你做得出来做不出来，实际上只有你心里最清楚。根据自己简历内容，提出问题，并且尝试根据课上的笔记以及实际情况去解答这个问题。如此循环2-3次，基本上对于自己的项目也就熟悉了。
之后，我们需要让自己的简历"精"。因为在实际投递的时候，我们简历呈现到面试官面前必须要做到让面试官最短时间内明白我们的工作量与我们的数据价值。如何精简我们的简历，还记得我们前面提到的三段式吗？问题-方案-成效（价值），将每一部分的工作量融合到一句话里面。再按照不同的建设方向，将内容分成不同的部分。这样，我们能做到每个简历项目，体现出4-6条自己的工作成果。并在每一条中针对业务设计、技术实现、问题排查三个方面再复盘自己准备的QA，基本上能涵盖60%的问题。剩下的40%，就需要通过面经还有王老师团队的各位大佬们帮我总结和整理了（说真的，从提出问题到提供解决问题的思路，是一个人功底最好的体现。不要试图用自己的两三年经验去挑战头部一线的大佬们!）
投递&面试
「你们逃避，我征服！」
当项目和简历都准备好，并且已经经过老师们对简历拷打的模拟面之后。我们的准备工作基本上就算收尾，剩下的就交给实战去做。
这里要先给各位同学提个醒，一开始投递简历时，一周到一个月没有面试是很正常的事情，刚开始我也不信，所以在11月初的时候几度深夜破防，也是靠老师们在小群里加油打气帮我提升信心过来的。
言归正传，投递这一块，如果说你的期望base是计划在北京。那我建议你先将投递平台上的期望base改成上海、杭州、广州等地区作为你的试炼场。当你经过三次实战的试炼，你会对面试官可能提问的问题与期望你回答得角度有一个更加清晰得认知。
前三次面试可以为2小厂1大厂，前面两次是为了方便你对自己的情况进行一个摸底，同时也是防止一开始强度太大会让你失去信心（我在面试某大厂的时候被搞得心态破碎）。而后面之所以要面一下大厂，是你要对自己当前的水平上限也要做好估计，确定好你的能力的上下界，再针对性的根据自己的面经与简历，复盘自己答过的，以及没答上来的问题。
一般来说，答过的问题，可能在后续面试中会进一步和面试官探讨，比如说在面试中，实时项目涉及到Flink State相关的问题，不要只局限于了解你在项目中你是怎么用的state。通过状态，我们可以引申出checkpoint、状态后端、甚至针对你当前场景是解决的什么状态的场景，不适用于解决哪些场景，这些都是可能根据你的简历中一个知识点继续深挖的，这里也是面试官特别喜欢考察的一项指标，即你对于自己的工作有无想法和思考。
另一方面，没有回答上来的，要考虑如何将当前的问题，放到自己的业务场景中，前因后果以及技术上的原理要梳理清楚。比如这里拿数据倾斜来举例，如果你只是给出网上流出的那些泛泛的说法，我相信就算你自己是面试官，你也不会认可这个说法。回答此类问题，需要按照现象—排查过程（Spark WebUI）—定位taskid对应的sql与表—按key聚合排序—处理倾斜数据（手动二阶段随机分区 or AQE）以上流程去回答问题，才使你的解决方案真正做到丰满，能站得住脚。其实涉及到Spark AQE DPP相关的部分，也是面试官在听完解决方案后，大概率会继续追问的一个点（我的实战经验中，不管大小厂，追问率是100%），这一部分我是通过王老师的大数据通关手册，对RBO CBO涉及到逻辑执行计划、shuffle function的优化点对面试官回答的，效果也是屡试不爽。
可能也会有同学会问，从一面到最终面，各轮面试都有什么区别？这里以我最后oc的一段面经作为蓝本进行一些分享：一面的时候一般会是同级 or +1，主要关注的是你的实践能力是否过关，一般是会问项目的一些设计和实现细节，整体来说偏业务层面，技术上考察的点并不多。二面是你部门的leader，主要关注的是你们整体的方案设计，你是怎么利用某项技术解决某一场景的问题，当前的解决方案是否存在一定的弊端，你们的合作模式有哪些？更多的是从协作和整体的方案上去考察你的业务sense和对整体项目的思考。你需要证明，你的这些工作，是如何为你的下游带来价值，是二面的核心。三面我这边是交叉面，更多是对技术层面的拷打，会详细问你具体技术实现的原理（回撤流、AQE、Region合并分裂），基本上都是会与你简历中具体的工作内容涉及到的技术点进行讨论和深挖，考察的核心是你是否对技术选型，实现原理有自己的思考和见解，如果不存在CBO RBO，你该如何通过手动去处理这些问题的思路。
最后聊聊
「迈向光明之路，注定荆棘丛生。」
在我当初刚参加工作的时候，由于遇人不淑，对于职业生涯的发展方面也走了不少歪路。曾经和某些人讨论技术岗的发展的时候，听了不少诸如："做业务没有意义纯打灰，研究技术才是铁饭碗"之类的暴论。
而在这几个月的学习和与老师们的探讨中发现，单一的面向业务或者技术都是不可取的。
一个项目，从最初的立项到最后的落地，它的目的都是为了更好实现商务价值，说俗点就是为了更好更快的捞钱。既然涉及到捞钱，那业务这一环就不可避免。如何更好的通过技术实现来反哺业务，助力自己产品的迭代的同时减少额外的成本，提升最终的年终营收。才是一个技术岗，甚至说公司里的任何一名员工需要思考，并长期投入实践的事情。没有业务背景，再高大上的技术栈也是没有投入意义的；没有技术托底，即使你有再好的业务sense，你无法将它落地，也无法实现自己的价值。
可以说，这段学习与面试经历，我认为并不只是单一的，为了准备面试去包装去应付面试官，然后进去继续当一个sql boy。更多的是，通过学习以及老师们的帮助，去培养自己的业务sense以及技术视野，最后提升对于数据的全局视角和建设的方法论。
希望这段经历对大家有帮助。