新人数据技术如何快速提升

与数据同行 2022-05-08

The following article is from 晓阳的数据小站 Author 晓阳的数据小站

傅一平荐语：

讲数据新人如何成长的文章，很务实，我概括下来有四点;

1、熟悉平台、工具、语言和环境，具备基本的生存能力，天花板是60分

2、参加需求管理，熟悉业务，所谓独当一面，天花板是80分

3、技能进阶，无论是数据建模、平台优化、系统架构等等，都属于自我选择和挑战，天花板是90分

4、通识能力提升，才能突破前面三个天花板，跟技术已经没有多大关系

希望于你有启示！

正文开始

新人数据技术如何快速提升

很多时候，新人技能并不局限于刚参加工作的年轻人，换一份新工作时，也能够根据一些技巧，来快速的熟悉和学习新公司的技术体系。

|0x00 初来乍到

对于数据技术而言，基础的技能有三种，一个是熟悉你所使用的数据平台和工具，一个是熟悉开发过程中的流程与规范，最后一个是熟练使用开发使用的语言。

对于数据平台和工具而言，一般情况下都是在Hadoop生态下做开发，但对于一些有特殊要求的团队，Spark和Flink已经得到了成熟的应用，这时候在熟悉平台的操作前，先通过官方文档，熟悉这种技术框架的设计原理，对于后续理解程序的编程方法，很有帮助。一些商业化的工具，比如ODPS是，在Hadoop上做的一些工具升级，熟悉这些工具的应用，对于工作熟练度提升，帮助也很大。

其次，任何团队都需要有相对应的操作流程和注意事项，因为这些经验大多是踩了坑，甚至是踩了很多坑之后才总结下来的，它一定不是你可以忽略的缘由。新人融入团队初期，想的并不是如何“争战功”，而是如何“活下来”，尽量避免了线上故障，才有更多的精力和能力，来实现更高层的目标。

开发语言相对而言不是非常重要的一环，比如大公司的数据开发普遍SQL化了，但Python或者是Java仍旧是需要做平台维护工作的一些岗位，所必须的技能，这里只要掌握如何快速学习一门语言的技巧就好。通常情况下，熟悉一门之前不熟练的语言，三天时间足够了。

|0x01 业务提升

当基础的数据能力掌握的差不多了，接下来就会进入一段比较痛苦的时期，也就是“业务熟悉”的阶段。

业务学习通常不是针对一个需求做了解，或者是过去的文档做整理，而是要针对一个知识体系，做全面的了解和熟悉。如今单纯的技术开发已经不能满足公司的要求，而掌握某些业务知识的开发人员，在日常工作中，竞争的优势会更大。

比如做营销相关的，互联网数字化营销有一套自己的东西，CPC、GMV之外，DPA/OCPX/OCPM这些进阶的术语，至少都要了解相关的知识含义。除此之外，在该方向上，公司有哪些产品、相关业务有什么黑话，多学多问一些，不至于做需求的时候感觉自己很“傻”，基本的话术都听不懂。

绝大多数公司不会有什么新人培养机制，大家的业务都在野蛮生长的时候，1-2年就是一个很长的周期了，招聘的目的也大多数为了快速补充劳动力，所以适应性的工作，还是需要依靠自己。

当对阶段性的知识有了一个总结后，可以试着自己把对于业务体系的理解写下来，不需要带太多的技术思考，只需要把业务的框架整理清楚，就算是成功。

接下来，我们就需要参加一次完整的需求开发周期了。

通常情况下的需求沟通过程如下，但很多非常“敏捷”的团队，通常口头讲讲也是有可能的。

第一步是产品需求的讨论，通常由产品经理发起，通过PRD来讲解需求的设计。

第二步是PRD的评审，通常由项目经理组织，对PRD的问题进行充分的讨论，并确定初步的项目排期。

第三步是技术方案的评审及排期的最终确定，需要有详细的技术方案设计、关键路径拆解和里程碑事件。

第四步是正常的开发节奏了，如代码开发、测试、补需求及上线的过程。

在这其中，我们需要能够对需求进行合理性的评估，并对存在疑问的地方提出自己的看法和设计方案，最后再根据需求提出自己的技术方案和相应的排期。

很多团队要求不光是能够完成相应的需求，还能够独当一面的负责，因此如何cover住整个“场子”，就需要你的专业知识来“镇场”。

|0x02 技能进阶

除了应对提倡的需求开发，接下来就就是考虑如何自我提升的问题了。毕竟，能够把需求做好只是完成了基本工作，而如果想要晋升的话，就需要在技术上作出一些突破，反过来赋能业务。

所谓的“赋能”，基本上就集中在两点，一个是“降本提效”，一个是“提升收入”。由于技术工作本身就是在一直做“降本提效”的事情，因此这种类型的贡献，也是比较“内卷”的，而且很容易讲不清楚对公司的贡献到底有多少。而“提升收入”，尤其是可以量化的目标，这种就会非常受到欢迎，权重也会更大一些。

除开我之前文章提到的四个可以提升的“技术点”，本文额外增加两个技能进阶的指引。

一个是数据建模的能力。数据建模是数据开发的一个基本功，也是区分于其他岗位的重要标志。但数据建模是一个长期的基本功，不仅需要对各种理论、方法论有掌握，更要求有实际的应用经验，毕竟这是一门“实践”出来的学问。因此，如果做不到“数据量足够大”，或者是“数据业务足够复杂”，那么即便是工作时间再久，技能上也不会有本质的提升。

对应到具体的工作，“数据量足够大”，可以对应到“大促”的业务场景下，当数据量极端到一定的程度，跑个简单SQL都需要计算很久的时候，你对于各种参数的应用、SQL代码顺序的问题、数据倾斜的理解，才能够更深刻的体会。很多时候，压力会给你动力，你会非常有把Hadoop底层、MR原理重新复习一遍的冲动，后续换新工作的时候，这些面试题对你而言就不仅仅是讲个方法了，你的经验会足够写一篇论文。

“数据业务足够复杂”，可以映射到“银行”、“业财”、“物流”这一类业务逻辑高度复杂、但数字化程度又不够高的场景上，你会对于“方法论”有一种别样的体会。别的不讲，如果一个业务横跨几个业务域、十几个业务过程、上百个业务细节，你会如何设计模型，又如何跟业务讲清楚数据结果为什么是正确的呢？这其实就是对业务的理解和抽象能力。像SAP做的工作，大多数非常标准化和逻辑严谨的那一部分，而更多的个性化、非标准的内容，则以“接口”的形式来介入主系统和做扩展。因此，从某种意义上讲，“微服务”也是我们设计数据业务系统的一种思路，其核心就是如何做好“严谨而标准”的核心组件。

另一个能力，就是数据技术架构的设计工作，其实不光是数据模型的建设，对于一些技术框架的设计能力，也影响了数据价值的产出。

举个最典型的例子，调度系统，当某个特定的业务场景有一些额外的要求，在正常的数据流程之外，加入跨时区、人工审批等节点要求时，通用引擎就无法满足我们的要求，而需要设计一些特定的调度规则系统了。

对于架构能力的培养，除了组内讨论和评审外，定期也需要有阶段性的文档产出，详细记录业务抽象的过程，以及完整的架构设计文档，包括了流程图、表结构定义、建模过程等内容。

最后，做好架构设计和模型设计的基础上，通用那么一两个标准业务场景，给到业务，“价值产出”的事情，才有实现的可能性。比如“数据埋点” + “AB测试”，感兴趣的就可以试着自己做设计。