首页天道酬勤算法工程师要求(高级算法工程师年薪)

算法工程师要求(高级算法工程师年薪)

admin 12-04 08:44 300次浏览

前言

在互联网公司的很多算法相关部门(比如搜索、推荐、广告),都有两个工作:“做算法”和“做工程”。这种看似自然的分工是最好的方式吗?似乎还有一些争议。

本文阐述了当前合作模式中的一个常见问题,译者认为这个问题非常重要。此外,作者还提出了一种可能的更好的合作模式,可以解决这些问题。

事先,文中的“数据科学家”可以理解为部分算法的工程师,而文中的“工程师”或“数据工程师”可以理解为部分工程或部分架构的工程师。

正文开始

“你的团队和数据科学家有什么关系[1]”?毫无疑问,这是我作为面试官在面试数据平台工程师时最常被问到的问题[2]。这是面试过程中的正常问题,是求职者评估新机会的必要过程。而且我一直很乐意回答这个问题。但我希望我不需要回答,因为这个问题的背后,反映的是怀疑和恐惧。

为什么呢?如果你看过硅谷科技公司数据科学与算法开发部的招聘广告,你可能会相信数据科学家和工程师之间的关系是高度协作、有机和创造性的。

然而,行业的真实情况并非如此。在大多数场景中,两者之间的关系实际上是在“不存在”[3]和“高度功能障碍”之间。

00-1010大多数公司将其数据科学部门分为三组:

科学家:这些家伙是那些“工程比统计好,统计比工程师好”的人。所谓“思想家”。

工程师:这些人建立数据渠道,把数据“喂”进数据科学家的嘴里,然后从数据科学家那里获得想法并实施。也就是所谓的“实干家”。

架构师:这些人维护Hadoop集群和其他大数据平台架构。所谓的“水管工”[4]。

科学家经常为工程师执行算法慢而苦恼,他们的工作流程、路线图和动机总是不同步。当他们想法的第一版进入ABTest时,第二版和第三版已经排好了队。他们的失望和不快是非常可以理解的。

数据工程师经常苦恼的是,数据科学家给出的代码总是低效难看,几乎从不考虑可维护性和工程性,会提出一些不切实际的功能需求,这样会破坏项目实施方案,还得不到任何好处。还有很多问题需要继续,但我相信你已经知道问题是什么了。

架构工程师对它们不满意,因为他们总是用任务填充集群,用数据填充硬盘。而且,他们往往远离数据科学家和工程师,这意味着他们永远不知道集群在什么场景下是如何使用的,也不知道集群用来解决什么业务或技术问题。这让他们很难摆脱目前的不愉快局面。因此,他们的反应是对集群施加更严格的限制,结果,其他人开始对他们感到不舒服。

这显然是一个恶性循环。

00-1010我们都知道这是不对的,那为什么不解决这个问题呢?为什么每个数据科学和算法开发部门似乎都陷入这样一种“功能失调”的模式?

我把这个问题的症结归结为两件事,我将在这里用一些观察来解释。

一个典型的数据科学部门

数据处理工具和技术在过去的五年里取得了巨大的进步。除非你必须每天处理几个P级数据或消耗数千亿个事件,否则现在大多数技术都可以轻松扩展到你需要的规模。

除非您需要测试这些技术的极限,否则您可能不需要由专业工程师组成的高度专业的团队来基于这些技术构建解决方案。如果你雇佣这些人,他们会感到厌烦。如果他们觉得无聊,就会离开你,去专业技能更有用的地方,比如谷歌、脸书等等。如果他们不无聊,那么他们的技能很可能非常平庸。平庸的工程师最擅长的就是造出庞大、复杂、难用的垃圾,然后称之为“解决方案”。垃圾往往需要更多的维护工作。

哪里错了?

因为听起来更酷!你可以整天坐在那里思考更好的做事方法,然后把你的思考结果扔给渴望设计它们的工程师。街上的每个人都会喜欢这个位置!科学家,尤其是刚工作,对行业了解不多的科学家,特别喜欢这个岗位。

这些都是我们引导的结果,一些大公司对此更是负有责任,尤其是那些在大数据疯狂之前就有数据情报部门的公司。

传统的数据智能部门包括三个角色:ETL工程师、报表开发人员和DBA。ETL工程师将数据传输到数据仓库。报告工程师的主要工作是在特定工具(如MicroStrategy)中设计报告。这些人是这个领域的专家。DBA(和其他工具管理团队)的工作是让一切顺利运行。

这里的问题是,ETL工程师、报表工程师和DBA都是执行者。因此,当“大数据”和“数据科学家”这两个词在十年前刚刚出现的时候,这些传统的BI部门面临着执行者太多、思想者缺乏的问题。所以他们创造了“思想者”的地位。我们向数据科学家承诺,他们可以随意修改数据,改变世界。但事实并非如此。这些数据科学家有时会创造出一些很酷且有用的解决方案,但大多数时候,他

们做的工作并不比报告工程师高明多少。

但是这个职位听起来很酷,而且比较容易招聘。所以就诞生了当代传统的数据科学部门:数据科学家(以前的报告工程师,现在的“思考者”),数据工程师(以前的ETL工程师,现在的“执行者”),以及架构工程师(以前的DBA,现在的“水管工”)。

呵呵,看起来数据智能(BI)部门从来就没有改变,我们只是加了个Hadoop集群然后换了个新名字。

真的那么糟糕吗?

这个问题取决于我们的目的是什么。如果你同意上面的观点,那么你得承认,自从BI兴起之日,很多公司使用这样的模式使用了很多年。但是如果你希望你的数据科学团队能够产出PPT以外的更多成果,那么我认为这是一个非常低效率的模型。

上面的“思考者”+“执行者”模式想要成功的一个基本假设是:需要有一群出色的工程师,他们没有自己的灵魂,只是积极地将“思考者”的想法实现落地。但是,这样的工程师,会是出色的工程师吗?

在这个模型中,执行者们需要为其他人思想的实现和失败负责,而思考者则因为成功而受到奖赏。这就是团队中争论和嫌隙的核心。

如果你希望为数据工程师岗位招聘到有天赋的优秀人才,你需要一些更大规模的、更NB的问题来让他们解决,好让他们的工作中不只是毫无灵魂地实现别人的想法。你需要的是大数据催生的大规模问题,但问题是,你并没有大数据。

所以,你只能雇到中庸的工程师。他们会制造出大量的烂摊子,进一步加重问题,让你走上恶性循环。最终的结果,就是数据科学家并不比传统的报告工程师厉害多少,因为他们缺乏一个创新、坚固的数据平台支持。进一步,如果你把他们定位为报告工程师,数据科学家们就该跑路了,毕竟,他们可是“思考者”,不是“执行者”!

一种不同的数据科学部门

在这个问题上,我们不应该去一味地效仿那些大公司的做法,而是应该想办法去革新这个模型。别再试图去设计更快的马了[5]……

几年以前,当我我加入Stitch Fix也正是这个原因。在Stitch Fix,我们努力在算法和分析方面做到世界最好。我们的方法是通过输出来领导行业,而不是把结果简单地告知(inform)[6]。所以要想达到目的,必须从心底认为当前的模式是不对的,这样才能全身心投入地创造更好的新模式。

在见证了过去两年中我们部门发展壮大的过程后,我有信心将这些与大家分享。既然我们的目的是通过输出来领导,而不是告知,我希望分享一种我认为更好的数据科学部门的组织方式。这是一种完全“自治”的角色,一种从头到尾负责到底的责任感和ownership,并且要为结果负责。这是一种更加适合快速发展和迭代的公司的做法。

让每个人都成为最好的

让我们忘掉传统角色的分别,来思考一下工作中真正让人兴奋的地方。

不管什么角色,普通和优秀之间最大的差异之一就是对创新的渴望和能力。优秀的人能够识别并创造性地解决普通人无法解决的问题,他们更适合,也更渴望一种自治、ownership和专注的环境。

从数据科学家到工程师的流水线完全是这种环境的反方向(事实上数据科学家们也不喜欢如此依赖“执行者”)。所以诀窍就在于为每个人都创造足够自治、ownsership和专注的环境。

但需要注意的是,能让数据科学家和工程师们兴奋的点是完全不一样的:

数据科学家

数据科学家们喜欢的问题是与业务紧密相关,能够通过自己努力直接影响项目或者组织的成败的。他们对某些事情或者流程进行优化,或者从头创造一个东西。这些都是针对性很强的问题,所以他们的solution也会是这样。这些solution涉及到各种商业逻辑的混合,对运行流程的深入思考,以及大量的创造性。因此,这需要对业务逻辑中某个部分的深刻理解,以及对业务过程的纵向深入参与。

工程师

工程师们擅长将问题抽象、泛化,然后找到优雅有效的解决方案。与数据科学家们感兴趣的问题不同,这些问题一般都是横向的,也就是说,他们在被广泛应用时能够发挥最大作用。这需要对业务运转整体流程的整体深入理解,由于这些解决方法都是高度抽象的,因此并不要求工程师对业务的某一部分有非常深入的了解和参与度。

(译者注:我觉得这个概括非常的好,说出了两种工作的一个非常本质的区别)

知行合一(Hybrid Thinker-Doer)

数据工程师们最害怕的事,就是尽管你的JD写得非常炫酷,但是你心中真正想要招的,还是ELT工程师。

如果你还没有意识到,那我可以告诉你:没有人喜欢简单地编写和维护数据管道或者ETL。这是这个行业里最烫手的山芋。因此,这个职位成为孕育平庸的温床也就不足为奇了。

工程师不应该写ETL。这不应该是一个专门的职位,没有什么比编写、修改、维护、支持一堆自己从来不用的ETL更让人沮丧的了。

相反,应该将工作整体的端到端的所有权交给员工。对于数据科学家来说,这意味着对ETL的所有权,对分析和最终产出的所有权。数据科学家们工作的最好产出应该是面向机器的,而不是面向人的。最好的产出物不是PPT或者报告,而是一个算法的API,可以通过调用这些API来改变业务。自治权同时也意味着对代码的所有权。从开始开发一直到生产上线。他们应该可以独立部署应用,并对其性能、效果和其他支持负责。

但是数据科学家们一般来说在软件开发方面并不是非常专业,最多算是合格。所以他们可能会在工程方面制造很多混乱。这也是为什么数据的ETL和算法的落地开发通常都会交给专业工程师来做。这些任务本质上都是垂直(纵向)聚焦的,但有天赋的工程师们最擅长的往往是应用的横向扩展[7]。

那么在这种场景下,工程师的职责应该是什么呢?综合来说,他们需要部署平台、服务、框架,使得数据科学家们可以自主的快速开发、部署他们的想法。可以将这些工作类比为乐高积木:工程师们设计乐高积木块,数据科学家们通过组装这些积木块来实现新的想法。这样做的好处非常明显:

工程师们的工作变成了完全横向的。这让他们可以专注于设计开发能够横跨多种算法应用的技术。这样做可以将工程技术的输出最大化。

工程师们可以专注于他们最擅长的:抽象、泛化,然后构建有效的,可扩展的技术方案。

工程师们可以自主工作。这样运作的工程团队工作起来就像变魔术,数据科学家们所期待的所需要的东西全部是可以提前预料到的,扩展性和健壮性全部交给了平台、服务和框架,而这些正是工程师们的工作。

为了让这套机制能够正常运转,大多数时候工程师们需要能预料到数据科学家们的需求,他们需要提前提前若干步进行开发。

对于有天赋的工程师和数据科学家来说,这显然有趣多了。

所以,所有的工作都被数据科学家们干了吗?

完全不是。相反,工程师们在这个系统中承担的职责要比传统方式中更加具有挑战性,也更加被需要,对于数据科学家来说也是一样。我们这套机制并不是在优化效率,而是在强调自治性。这套机制的产物是明确的自治权和对结果负责的明确责任。

这对富有创业精神的人来说是非常有吸引力的。它打开了快速开发和颠覆式创新(disruptive innovation)的大门。但它的代价是一定程度的专业度,也就是一定的效率。

我们并不期待数据科学家们忽然变成有天赋的工程师,我们同样也不希望工程师们完全不了解业务逻辑,丢掉垂直深入的主动性。事实上,团队合作(partnership)才是这个模型可以工作的核心。工程师们应该将自己看作“钢铁侠的裁缝”,他们的使命是建造出强大的钢铁战衣,防止数据科学家们落入方案不可扩展或者方案不可靠的陷阱。

一条极富挑战性的路

看到这里,你或许在怀疑这样的机制能否真正建立起来。但是这样做带来的收益完全值得去冒险。下面是一些可能会阻碍这个甚至会逆转这个过程的问题:

人们不愿意改变。人们总是倾向于重建他们习惯的环境,这会导致他们倾向于返回到传统的思考者-执行者模型。新雇佣的人更容易习惯新的组织架构。当发生问题时应该尤其警觉,例如当API出了问题或者算法效果不好。

人们会坚持认为工程师应该为此负责,但是他们往往说的只是症状,而不是问题本身。工程师们应该做的是为平台提供更好的支持、可视化、抽象以及健壮性。同时应该认识到,工程师本来就有可能破坏东西,没人可以保证不犯错误,不破坏任何东西。

平台工程师们一定要走在数据科学家们前面。团队里需要非常敏锐的工程师,能够提前预料到数据科学家们需要哪些服务、框架和功能。数据科学家不再把想法交给工程师来实现的一个后果就是,工程师们不再能够针对数据科学家的需求来做出反应,因此就需要能够提前预判。

记住,工程师们是在建造乐高积木,而数据科学家们是在组装积木。如果数据科学家们没有合适的积木可用,他们就会找出其他的解决方案。他们要么会使用错误的积木(在圆形的洞里填一个方形的积木),要么会自己造一个。通常来讲,由于这种自己造轮子的过程缺乏系统性和全局性考虑,所以会造成一团混乱。而这种混乱一旦被创造出来就很难收拾,正所谓覆水难收。

不要惧怕效率问题

鼓励数据科学家肩负如此广阔任务栈的后果之一,就是他们可能无法生产出和专业工程师一样专业高效的代码和方案。我们是在用效率来交换速度和自治性。对这个复杂权衡的认识是非常重要的。

但与此同时,这种端到端的自治性也有一些不那么明显的高效之处。在他们所实现的领域,数据科学家们是专家,所以他们能够做出一些需求和技术代价之间的权衡。例如,他们可以决定在某些合适的地方使用抽样数据,或者近似方法,他们可以决定砍掉一些实现和维护代价很高,但是收益有限的功能。这些在传统的思考者-执行者模型中是基本不会发生的,即使发生了,也是以反复沟通谈判为代价的。

综合来说,我们希望这种自治性带来的效率和创新会大于数据科学家“全栈开发”带来的一些低效。

未来

我不会声称我们发现了组织数据科学部门的最好方式,或者说这就是最适合你所在的组织的方式。但是这一定不是一种试图建造“更快的马”的尝试,而且我觉得这是更加适合我们的一种方式。

我真诚地希望,通过分享我们的尝试,能够鼓励其他非传统数据科学部门做出同样的尝试;能够激发正在组建新部门的负责人的灵感,让他们能够脑洞大开,挑战传统;能够告诉被传统组织架构所“伤害”的工程师和数据科学家们,还有其他可以工作的模式和环境存在。

参考资料:

[1] 本文中的“数据科学家”可对应到国内更常用的“算法工程师”或“算法研究院”的角色。

[2] 本文中的“工程师”、“数据工程师”或“数据平台工程师”可对应到国内更常用的“偏工程”或“偏架构”的工程师角色。

[3] 问一下你的(数据平台工程师)面试官,他知不知道数据科学家坐在哪里(或者反之)。如果他们不知道,你就赶紧跑吧……

[4] 因为这些人的主要工作是保证数据通道的畅通,就像管道工人一样。

[5] 福特汽车的创始人福特曾经说过一句话:“如果(发明汽车时)去问人们想要的是什么的话,他们会说想要的是更快的马”。比喻默守lldbm,在既有框架下做改进。

[6] 这里的通知(inform)指的是在传统的行业中,BI很多时候只是将自己分析的结果告诉、通知业务部门,但是是否采纳并还是由业务部门决定,这也反映出了传统BI部门略显尴尬的地位。

[7] “横向”指的是开发具有可扩展性,高可复用性的应用或者组件。

本文作者:

张相於,现任58集团转转事业部算法架构师,负责转转的推荐系统相关工作。曾任当当网推荐系统开发经理,多年来主要从事推荐系统以及机器学习相关工作,也做过反垃圾、反作弊相关工作,并热衷于探索大数据技术&机器学习技术在其他领域的应用实践。

全面提升企业的主动防御能力理解对象存储云分发网络有什么用处?Python中xlsx文件转置操作详解(行转列和列转行)el-table表格组件中插槽scope.row如何使用Python Scala中怎么使用def语句定义方法
大数据分析平台的搭建(大数据实时平台搭建) 数据仓库实现了银行的什么业务(银行营销)
相关内容