数据工程师的没落

点击查看全文

尽管这篇文章的标题有点标题党，内容很悲观，但请牢记，我对数据工程非常有信心——我只是需要一个和我之前的文章对比强烈的标题。理解并揭露这一职位正面临的逆境是寻找解决方案的第一步。

同时提请读者注意的是这里陈述的所有观点都是我个人的，并且是基于我在与很多来自硅谷的数据科学团队的人们交流时所做的了解。这些观点并不是我老板的想法，与我现在的职位也没有之间的联系。

变革管理

由于有用的数据集被广泛使用，并且是通过会导致庞大复杂的有向非循环图(DAGs)的方法获得的，变化的逻辑或源数据可能会打破下游结构，和/或使其变得无效。下游结点比如派生数据集、报告、仪表盘、服务项目和机器学习模型便可能需要被改变来反映上游的变化。通常来说，数据传输线附近的元数据是不完整的或被掩藏在代码中，只有极少数人有能力耐心阅读。上游的变化将不可避免地以错综复杂的方式打破下游实体或使其无效。取决于你的机构如何权衡稳定性与精确性，这种变化可能是十分可怕的，并可能导致管道堵塞。如果数据工程师的工作目标是稳定性，他们很快就会认识到不打破任何东西的最好方法就是不改变任何东西。

由于管道通常是巨大且昂贵的，适当的单元测试或集成测试应当在某种程度上达到均衡。问题在于：利用抽样数据和试运行，你能确认的只有这么多。如果你认为一个单一环境的混乱程度已经超出了你能处理的范畴，那么在使用到了不同的复杂代码和数据的开发和生产环境时，请努力保持理智。凭我个人的经验，在大数据的世界里，很难找到体面地开发或测试环境。在很多情况下，你能找到的最好的就是一些人们用来支持任何他们认为合适但还未公开的进程的空间“沙盒(Sandbox)”。

数据工程已经错过了“devops运动”这只大船。devops是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。 并且现代工程师很少受益于devops运动带来的理智和安心。他们没登上这艘大船不是因为他们没出现，而是因为船票对于他们的货物来说太昂贵了。

整个团队中最不利的角色

现代团队发展得很快，不管你的机构是工程驱动、项目管理驱动或是设计驱动，也不管它是否把自己想成是数据驱动的，数据工程师并不会起太大的驱动作用。你得把数据工程想成是基础设施的角色，是一种人们认为理所当然的东西。只有当它坏了或者是没有达到人们的预期时，它才会受到人们的关注。

如果团队人员中有数据工程师，他的工作可能是帮助数据科学家和分析师收集他们需要的数据。如果需要的数据不能在数据仓库的结构化部分得到，分析师可能会查找一些原始数据来做出短期的解决方案。此时数据工程师就需要适当地处理数据并最终把这些数据加入仓库中。很多情况下答案必须及时给出，因而当新的维度和指标被填充到数据仓库中时，它们早已是过时的新闻了，所有人都已经忘了这件事儿了。数据分析师会因其洞察力而获得荣誉，而其他所有人都可能会质疑把这一部分新信息并入数据仓库这一缓慢的后台进程是否还有必要。

虽然“冲击/影响力（impact）”——这暗示着速度与改变——是员工在其业绩评估中最希望看到的词，数据工程却被谴责为几乎没有短期影响的缓慢的后台进程。数据工程师离那些能产生积极影响的形象还有些距离。

来源：Mc顽固份子