原文链接：Engineers Shouldn’t Write ETL: A Guide to Building a High Functioning Data Science Department

“你的团队和数据科学家之间是什么关系？”这个问题是我在面试数据平台工程师时最经常被问到的问题。这是一个很好的问题——对于数据领域一个给定状态的工程师职位，这个是评估一个新机会的职能的基本问题。我总是很乐意回答这个问题。但是我希望我不必这样做，因为这个问题是出于对这种关系的怀疑和恐惧而提出的。

为什么会是这样？如果你读过valley中数据科学和算法开发部门的招聘要求，你可能会相信数据科学家和工程师之间的关系是高度协作的，有组织和创造性的。但是，事实是这种情况十分罕见已经是一个公开的秘密。很多公司在不存在和高度功能紊乱这个范围内培养工程师和科学家之间的关系。

一个典型的数据科学部门

大部分公司数据科学部门组织架构都包含三个组：

• 数据科学家：他们是“比工程师更好的统计学家，又是比统计学家更好的工程师”，又叫“思想家”。
• 数据工程师：他们一方面构建管道向数据科学家提供数据支撑，另一方面又将数据科学家提出的想法付诸实践，又被称为“执行者”。
• 基础架构工程师：他们维护Hadoop集群，以及大数据基础架构。又被称为“水管工”。

数据科学家经常对工程师总是不能很快的将他们的想法投入到生产中感到失望，同时令他们失望的还有工程师的工作周期、线路图与动机不能很好匹配。往往是他们版本2、版本3的想法都已经出来的时候，版本1的想法才刚刚进入A/B测试阶段。这样看来他们的沮丧也是很有道理的。

数据工程师对数据科学家同样也有意见，他们觉得他们总是生产一些低效的、垃圾代码。他们还抱怨数据科学家几乎不考虑想法产品化的维护成本，以及提出一些不切实际的需求，造成实现所花费的精力与收获不成正比… …等等，还有很多，但是相信你已经理解了他们的痛楚。

基础架构工程师则对所有人都有怨言，抱怨他们总是让集群过载，塞满了磁盘空间。他们被数据科学家和数据工程师疏远，这也就意味着他们永远无法知道基础架构将会如何被使用，在哪里使用，或者基础架构将被用于解决什么业务或技术问题。这使得他们对于改善环境感到相当无力。相反，他们通过增加基础架构的限制来做出响应。这样又造成了所有人都对他们又怨言。

这是一个恶性循环。

哪里出错了？

我们都知道招聘宣传就是这样，所谓的标准都是不合格的。那么，为什么我们不解决这个问题呢？为什么所有的数据科学家和算法开发团队都陷入到同样的反常模型中了呢？

我将这个归结到两件事上，在这里以观察结果的形式提供：

你可能没有大数据

数据处理工具和技术在过去5年里发展迅猛。除非你需要处理超过数PB级别的数据，或者你每天会采集数以亿计的事件，大多数技术都已经发展到能够轻松扩展到满足你需求的程度。除非你想拓展这些技术能力的边界，你可能不需要专门的工程师来组成一个高度专业化的团队来在一些已有的技术上构建解决方案。你如果设法雇佣这样的工程师，他们可能会觉得无聊。他们无聊了，可能就会选择离开去Google、Facebook、LinkedIn、Twitter等真正需要他们专业知识的地方。如果他们没有觉得无聊，那可能是因为他们很平庸。平庸的工程师真的很擅长构建巨复杂的、与其工作简直就是噩梦的他们称之为“解决方案”的东西。哈哈、制造混乱也需要专业化。

所有人都想当思想家

因为它听起来是一个很酷的职位。你可以整天坐在那儿，想怎样更好的做事情，然后将你的想法交给那些急切想把他们投入到产品中的人。去吧，把它推销给路人。我打赌他们会跳上这个机会！数据科学家，尤其是对于那些刚进入这个行业还并不了解太多的新人，他们尤其希望成为这样的角色。

那是因为我们培训他们，使他们对这个职位充满了渴望。有更大、更成熟的的公司会感谢这些行为的。那些公司在大数据火以前就已经有了商业情报部门。

一个传统的商业情报部门（Business Intelligence Department）由三种角色组成：ETL工程师、报告开发人员以及DBAs。ETL工程师负责将数据导入数据中心。他们深度依赖Kimball以及它的建模指南。另一方面，报告开发人员的职业生涯都是围绕依赖特定工具设计报告。他们是专家。DBAs（以及一些管理其他工具的组）则是尽他们所能保证所有事情都正常运转。

有一件事就是，ETL工程师、报告开发人员以及DBAs都是执行者。所以，当10年前大数据和数据科学家开始站在风口时，这些成熟的商业情报部门（BI department）有很多的执行者，但是缺乏思想家。所以，他们设定了“思想家”这个角色。他们将数据科学家和成熟的商业情报部门结合在一起，并承诺数据科学家可以依赖数据，并且可以改变业务流程。但是事实上这些都没有成为现实。这些数据科学家偶尔也能够创造出一些很酷且高效的解决方案，但是大多数情况下他们还是专注于执行一些比报告开发人员稍微高级一点的针对业务的分析（很大程度上他们还忽略了报告开发人员的建议）。

但是这个角色听起来真的很好，而且它还很容易招聘。因此产生了传统的、现在的数据科学部门：数据科学家（对应报告开发人员，又称“思想家”），数据工程师（对应ETL工程师——执行者），基础架构工程师（对应DBAs——水管工）。

糟糕！看起来商业情报部门没有实质上的改变，我们只是开始使用Hadoop集群，然后给了它一个新的名字。

真的有那么糟糕吗？

事实上，这取决于你想达到的程度。如果你接纳了上面的观点，那么你也得接受好多年前——从有BI部门开始就已经存在了。但是，我觉得如果你想你的数据科学部门真正的做一些除了PPT和海报之类的事情——这是一个非常低效的模型。防止思想家和执行者模型陷入招聘简介的根本缺陷就是：有很多没有过多想法的又出色的执行者，他们渴望将数据科学家的想法和远景实现出来。这听起来是不是像任何你所知道的有才华的工程师的简介？

在这个模型中，执行者默默的尝试、实现以及支撑其他人的想法，但是思想家却独享了他们成功的回报。这是团队之间竞争、不一致的核心。它创建了一个IT组，而不是一个工程师团队。

为了吸引有才华的工程师进入这样一个角色，你需要一些真正的大规模问题来让他们疲于奔命而无暇有其他的想法最终成为一个你所期望的顺从的执行者。你需要的这类问题产生于大数据。但是，抱歉，好像你没有大数据。

相反，你将雇佣一些平庸的工程师。他们将创造异常复杂的混乱出来。这又会进一步加剧争论。欢迎进入恶性循环！最终的结果就是数据科学家获得的授权只比报告开发人员多那么一点点，因为缺乏坚实的，创新的数据平台对他们提供支撑。

如果你的招聘宣言让他们向报告开发人员倾斜，他们将以另一种方式执行。毕竟他们是思想家，不是执行者。

另一种数据科学家部门

我们应当创新、发展模型而不是模仿大公司的结构（这些公司将BI部门转换成了DS部门。不要过多的尝试去设计更快的马（No more trying to design faster horses…这里应该是再如何重新设计，马的框架极限也是不能突破改变的，而应该尝试去发现更快的其他动物）.

出于这个目的，多年前我换到了Stitch Fix工作。在Stitch Fix的日子，我们致力于将我们的算法、分析做成全世界最好的。我们致力通过我们的产出去领导业务，而不仅仅是影响。除非你愿意勇敢的重新思考、挑战一些你觉得不合理的东西，否则要做到这些，真的很难！

看着部门过去两年的成长、发展，我有信心分享一些我们是如何做的。

给定一个领导而不是仅仅是影响的目标，我想推荐给你的方式是一个我相信的更好的构建数据科学家部门的方法。这个方法给予角色充分的自主权，对产品真正的ownership，以及对产出负责。这个方法适合于一个需要快速演进业务（或数据）模型的公司。

接下来就是构建一个可以快速响应的数据科学团队的蓝图。应当从对产品的领导、创新、接口以及代码出发，而不是仅仅对变化做出反应，以及用通过PPT这种令人绝望的尝试去转移直觉。

让每一个人在世界上都是最好的

让我们忘记传统的角色，相反，想想每天早上能让人兴奋的想要来工作的原始动机。无论角色如何，平庸的人和伟大的人的根本区别在于他们对创造性的渴望和天赋。伟大的人能够发现并创造性的解决那些困扰平庸的人的问题。他们擅长并且渴求一个自主的、有所有权的以及能够专注的环境。

从数据科学家到工程师这条线上，其实是完全相反的两种环境。（即使数据科学家厌恶不得不依赖工程师）。解决这个问题的诀窍就是创造一个让所有人都能够完全自主的，有所有权以及专注的环境。但是，重点是首先要认识到数据科学家和工程师的激情在不同的任务上：

• 数据科学家：

  数据科学家喜欢处理与业务一致的问题，并通过他们的努力对项目/组织的成功产生巨大影响。他们开始优化一些确定的事情，或者处理，或从头开始创造某物。实际中问题通常是面向点的，所以他们的解决方案也是面向点的。他们通常需要涉及复杂的组合业务逻辑，他们会重新考虑怎样完成，并有创造性的完美的做到。因此他们需要深入了解业务的具体部分是如何运作的，以及与业务方面高度合作。

• 工程师：

  工程师擅长抽象、范化，以及在需要的地方找到有效的解决方案。这些问题通常是面向面的。在应用广泛时他们表现得尤其有影响力。他们需要对业务如何操作有一个良好的全局了解，但是解决方案的抽象性质意味着他们对业务逻辑的轻依赖，并且不需要对一些业务逻辑的垂直领域的深度理解和紧密合作。

思想家和执行者的结合

在数据领域，一个工程师担心的通常是：不管你的职位描述或招聘简介讲的是什么，你实际是在偷偷的招聘一个ETL工程师。这种情况下，你确实没有意识到：没有人喜欢写或者维护数据管道或者ETL。这是业界烫手山芋的终极boss。你真的不用惊讶，ETL工程师就是平庸的繁衍地。

工程师不应该写ETL。出于对数据这一神圣行业的爱，这真的不应该是一个专门的职位。没有什么比写、维护、修改和支持ETL去生产一些你自己永远都不用的的数据更折磨灵魂的了。

相反，应该让人们对产品从端到端有完全的自主权和责任。对于数据科学家来说，意味着他们对ETL的ownership。也意味着数据科学家同样对数据分析和产出有ownership。数据科学家许多努力的最佳结果是产生对计算机有意义的组件，而不是对人。这些组件可能是一类算法、集成在工程栈中的API等从根本上改变业务运行的东西，而不是报告、面板、PPT等。自主性意味着数据科学家还需要自己负责代码的部分。到产品的整条路径都需要负责。他们应该能够在不需要征得工程师同意的情况下开发和部署，还要负责支持、负责性能，控制延迟，保证SLA需求等。

这使得垂直领域的责任和重点被放在了数据科学家手中。但是数据科学家通常不是经过培训、有很高技巧的软件工程师。你可能会说他们最多就是足够应付这些工作。这样你可能会预感到他们会制造大的混乱。这也是为什么ETL和API/产品算法的开发工作在流水线风格的开发模式中会被交给软件工程师的原因。但是所有这些工作天生就是面向垂直业务（面向业务点）的。数据领域的有才华的工程师几乎总是注重面向面的应用。

所以这样子的话，在平面世界中一个新的工程师角色是什么？总结一些就是：工程师必须部署平台、服务、抽象层、框架等让数据科学家可以自主的构思、开发以及部署他们的想法。（例如工程师需要部署ETL构建、调度以及执行组要的相关的工具、基础框架以及服务等。）我喜欢将这种形式类比于乐高积木。工程师设计一些新的乐高积木，数据科学家以一种创造性的方式将他们聚合来创造新的数据科学。这绝对是说起来比做起来容易，但是：

• 工程师的工作完全平面化。这样允许他们能更专注于构建一些能被广泛使用于多中数据科学问题的技术。这样最大化了工程师的产出。这非常的棒，因为在你的数据科学部门中你的数据科学家数量远多于你的工程师数量。
• 工程师能够专注在他们最擅长的事情上：在需要的地方抽象、范化、创造效率、扩展解决方案等。
• 工程师获得了自主操作权。以这种方式部署的工程师团队的生产应该看起来就像“魔法”一样。对于数据科学家来说，事情只是“落实到位”，因为他们的需求是可以预期的，只要他们使用的平台、服务、框架等的扩展、弹性伸缩被照顾好即可。
• 为了使这种模式工作良好，大多数时间工程师需要预测数据科学家的需求。他们的开发需要早于数据科学家很多步。
• 对于非常有才华的工程师和数据科学家来说，这是一个有很多乐趣的“地狱”。

数据科学家做了所有工作？

不，不是所有的。如果有任何事情，工程师比他们在标准模型中做会遇到更多的挑战和苛刻的角色。数据科学家可能也会遇到类似的问题。我们并不是在优化组织效率，我们在优化自主权。自主权是对想法的参与感和对交付的责任感。

这些角色对那些拥抱创业思想的人来说非常有吸引力。它允许快速移动、消除了建立不必要共识的需求，并且为破坏性创新打开了一扇大门。但是它确实是以专业性和效率为代价的。（这里的效率应该是类似数据科学家不具备必要的软件技能造成的效率低下，专业性也是从这点出发）。

然而，也并不是期望数据科学家马上就成为有才华的工程师。也不是工程师就完全不需要了解业务逻辑以及产品的垂直领域。事实上，伙伴关系是这个模型成功的关键。工程师应当把自己当做是“钢铁侠的裁缝”，构建铠甲防止数据科学家陷入陷阱产生不可扩展、不可靠的解决方案。

在没有用于产生解决方案的抽象和框架的情况下，工程师和数据科学家合作创建解决方案。但是不是通过传递的方式。相反，工程挑战之一是构建自服务组件，在这个上面数据科学家可以自主的迭代业务逻辑和算法，交付他们的想法到业务中去。原始版本的解决方案构建出来后，谁拥有什么变得很清晰。工程师拥有他们构建的基础框架，数据科学家拥有他们实现的业务逻辑和算法。不需要紧密的耦合来迭代。

充满挑战之路

在这个点上，你可能会怀疑是否能以这种方式做一些事情。但是我觉得收到的回报是值得冒这个风险的。这里有几件事需要注意，因为它们可能会阻碍或逆转进度：

人们总是反对改变。人们总是想要重建一个他们已经习惯的工作环境。这会制造压力回到Thinker-Doer模型。新员工需要快速的到新的组织结构报道。当项目遇到问题时尤其需要保持警惕，例如一个API断掉，或者一个算法提供不良输出等。在这种情况下，人们会表现得过激。他们会坚持工程师应该接手问题。但是，他们这样只能解决一个症状而不是整个问题。工程师应该建立更好的支持平台，提供可见性、抽象性以及伸缩性。并且，人们也应该意识到工程师也会把事情搞砸，没有人能避免犯错误和对产品造成破坏。

必须要保证平台工程师领先于数据科学家。你需要非常敏锐的平台工程师，他们可以做出直观的判断哪些服务、框架、功能需要在迫切需要它们前就位。缺乏从科学家到工程师的转换意味着工程师不能享有响应科学家提出的需求的权利。

记住，是工程师创造乐高积木，数据科学家团队组装积木。如果数据科学家没有合适的积木组装，他们将继续前进创造一个解决方案。他们可能会用错误的积木进行组装（将一个方的积木塞到圆形的洞中），或他们自己创造一个。通常情况下他们会制造大的麻烦。而且一旦被创造出来了就很难再重来了。

不要害怕效率低下

让数据科学家掌握这样广泛的技术技术栈的结果就是，他们不太可能向工程师一样有效的生产代码和解决方案。我们牺牲技术效率来获取速度和自主性。所以意识到这是一个深思熟虑后的折中非常重要。

然而，这种端到端的ownership也会获得一些不太明显的效率。数据科学家是他们正在生产、实现的领域的专家。因此，他们有能力在技术和支持成本和需求之间做出权衡。例如，他们可以决定在哪些地方采样数据，在有意义的地方使用进似方法，并做出是否抛弃一些功能的决定，这些可能只会对业务产生微小的影响，但是确需要极高的开发和支持成本。这种情况在传统的流水线似的科学家和工程师相互传递需求、数据的模型中就很少发生（当他们要这样做时，相互之间通常需要大量的谈判）。

总的来说，希望允许数据科学家复杂全栈的自主性和创新所产生的结果带来的优势能够超过缺乏专业技术造成的技术低效的劣势。

未来

我不会声称我们已经发现了构建数据科学部门的最好方式，或者说这是适合你的组织的最佳结构。但是，这绝对不仅仅是一次重新造一匹更快的马的尝试，我强烈的觉得这是对Stitch Fix的一个更好的解决方案。

我真诚的希望，通过分享我们所做的一切能够鼓励其他的非传统结构的部门也能将他们经验分享出来。还能够激励处于形成阶段的数据科学部门的领导能够跳出成见思考，找到挑战传统的勇气。也希望能够告知那些对传统角色感到沮丧的数据科学家和工程师其实还有不同类型的有可操作性的环境。