工程师要不要写ETL?——教你构建高效的算法/数据科学部门

作者：张相於

前言

在很多互联网公司的算法相关部门(例如搜索、推荐、广告)里，都有“做算法的”和“做工程的”两个工种。这个看似天经地义的分工方式是否就是最优的方式?这似乎还是存在一些争议的。

这篇文章阐述了一种当前较为普遍合作模式下的问题，译者觉得说得很在点上。更宝贵的是，作者同时也提出了一种可能会更好的合作模式，能够解决这些问题。

需要提前说明的一点，文中的“数据科学家”可理解为我们常说的偏算法的工程师，而文中的“工程师”或者“数据工程师”可理解为我们常说的偏工程或者偏架构的工程师。

正文开始

“你的团队和数据科学家们[1]之间的关系是怎样的”?毫无疑问，这是我作为面试官，面试数据平台工程师[2]时最常被问到的一个问题。这在面试过程中是一个很正常的问题，属于求职者评估新机会的必要流程。而我也经常很乐于回答这个问题。但是我希望我不需要回答，因为这个问题的背后，折射出的是怀疑和恐惧。

为什么呢?如果你阅读一下硅谷科技公司里数据科学与算法开发部门的招聘启事，你或许会相信数据科学家和工程师之间的关系是高度协作、有机并且富有创造性的。

但是，行业里的真实情况却并非如此。大多数场景下，这两者的关系其实是介于“不存在”[3]和“高度功能失调”之间的。

一个典型的数据科学部门

大多数公司将他们的数据科学部门划分为三个组：

1. 数据科学家：这些家伙就是那些“工程比统计学家好&统计比工程师好”的人。也就是所谓的“思考者”。
2. 数据工程师：这些人构建数据通道，将数据“喂”到数据科学家“嘴里”，然后从数据科学家手里拿到idea并且实现它们。也就是所谓的“执行者”(Doer)。
3. 架构工程师：这些人维护Hadoop集群以及其他大数据平台架构。也就是所谓的“水管工”[4]。

数据科学家们经常不爽的是，工程师们实现算法的速度太慢，以及他们之间的工作流程，路线图以及动机总是同步不到位。当他们想法的版本1进入ABTest的时候，版本2和版本3早就已经排好队了。他们的失望和不爽是非常可以理解的。

数据工程师们经常不爽的是，数据科学家们给出的代码总是效率低下，代码丑陋，几乎从不考虑可维护性和工程化问题，而且会提出一些不现实的功能需求，结果是破坏了工程实现方案，但也没有得到什么好处。这种问题继续下去还有很多，但是相信你已经懂了问题在哪里。

而架构工程师们对他们都不爽，因为他们总是将集群上塞满任务，将硬盘里塞满数据。而且他们常常与数据科学家和工程师们都离得比较远，这意味着他们从来不知道集群是在什么场景下被如何使用的，也不知道集群被用来解决什么业务或技术问题。这让他们在很难摆脱当前不爽的境地。所以，他们的应对方法就是对集群做更严格的限制，这样做的结果，就是其他人都开始对他们感到不爽。

这显然是个恶性循环。 36大数据（http://www.36dsj.com/）

哪里错了? 36大数据（http://www.36dsj.com/）

我们都知道这样做是不对的，那我们为什么不解决这样的问题呢?为什么每个数据科学和算法开发部门似乎都会滑落到这样“功能失调”的模型中?

我将这其中的症结归于两件事情，在这里用一些观察来做出阐述。

你或许并没有“大数据”

数据处理的工具和技术在过去五年间发生了巨大的进步。除非你要处理几个P级别的数据，或者每天需要消费千亿级的事件，那么大多数技术现在都可以轻松扩容到你所需要的规模。

除非你有试探这些技术的极限的需求，你或许并不需要一只高度专业的专业工程师团队来在其基础上构建解决方案。如果你雇佣了这些人，他们会感到无聊。如果他们感到无聊，他们就会离你而去，去到他们的专业技能更能发挥作用的地方，例如Google，Facebook等等。如果他们不感到无聊，那么他们的技能很可能非常平庸。平庸的工程师最擅长的事情，就是构建巨大无比、过于复杂、难以使用的垃圾，然后称之为“解决方案”。而垃圾往往需要更多的维护工作。

每个人都想做“思考者”

因为这听起来更酷!你可以整天坐在那里，思考做事情更好的方式，然后把你的思考结果甩给那些急于将它们工程化的工程师们。大街上每个人都会喜欢这个职位的!数据科学家们，尤其是那些刚刚工作、对行业了解不多的，对这样的职位尤其喜欢。

这些都是我们引导的结果，而一些大公司更要为此负责，尤其是那些在大数据疯狂之前就已经有了数据智能部门的公司。

一个传统的数据智能部门包括三种角色：ETL工程师，报告工程师(report developer)，以及DBA。ETL工程师把数据转移到数据仓库中。报告工程师的主要工作是在特定工具(例如MicroStrategy)中设计报告，这些人是领域内的专家。DBA(和其他工具管理团队)的工作就是让这一切都流畅运行。 36大数据（http://www.36dsj.com/）

这里的问题在于，ETL工程师，报告工程师还有DBA全部是执行者，所以，当十年前“大数据”和“数据科学家”这些词汇刚刚兴起的时候，这些传统的BI部门面临着执行者太多，而缺乏思考者的问题。所以他们制造了“思考者”这样一个职位。我们向数据科学家许下承诺，承诺他们可以随便折腾数据，进而改变世界。但事实上并非如此。这些数据科学家有时会创造出一些很酷并且有用的方案，但是在大多数时间里，他们做的工作并不比报告工程师高明多少。

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

呵呵，看起来数据智能(BI)部门从来就没有改变，我们只是加了个Hadoop集群然后换了个新名字。 36大数据（http://www.36dsj.com/）

真的那么糟糕吗?

这个问题取决于我们的目的是什么。如果你同意上面的观点，那么你得承认，自从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]。

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

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

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

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

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

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

所以，所有的工作都被数据科学家们干了吗? 36大数据（http://www.36dsj.com/）

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

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

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

一条极富挑战性的路

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

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

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

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

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

不要惧怕效率问题

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

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

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

未来

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

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

参考资料：

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

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

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

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

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

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

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

End.