了解数据工程师和数据科学家之间的差异非常重要。 误解或不了解其差异，会导致团队在处理大数据时失败或者表现不及预期。
一个核心的误解是每个职位各自的优点和弱点。 我认为，其中一些误解来源于描述数据科学家和数据工程师的图表。
图1.关于数据科学家和数据工程师过度简化的维恩图。 来自Jesse Anderson的插图
像图1这样的维恩图，过度简化了岗位的复杂性，以及岗位的区别之处。它使两个岗位看上去可以互换。 是的，这两个岗位都处理大数据。 不过，每个岗位利用大数据，无论是创造价值，还是创造数据管线的做法都是截然不同的。这种差异来自每个岗位的基本技能。
何为数据科学家和数据工程师?
当我与组织机构合作，处理它们的团队架构时，我不用维恩图去描述一名数据工程师和一名数据科学家之间的关系。 我绘制的图如图2所示。
图2.显示数据科学家和数据工程师的核心能力及其重叠技能的图表。 Jesse Anderson和大数据研究所的插图
数据科学家的技能
数学与统计学(有时物理也可以)是数据科学家的核心。 在基于这种数学背景，他们正创建高级分析能力。 他们通过数学应用来创建机器学习模型和人工智能模型。
如同软件工程一样，数据科学家将不得不与业务端进行交流。 这包括充分了解领域，以获得洞察力。 数据科学家通常负责分析数据以帮助业务，这需要一定的商业敏锐度。 最后，他们的结果需要以可理解的方式提供给业务方。这要求数据科学家有能力用口述和视觉结果的形式，与业务方交流那些复杂的结果和观察情况，以似的业务方能够理解并且基于此展开决策。
关于数据科学家，我一言以概之的定义是：数据科学家是通过编程来强化他们的数学和统计背景能力来进行分析数据、创造数学模型的人。
数据科学家的一个常见特征是，他们不得不选择了编程，以实现他们除了编程以外无法做到的事情。 当我与数据科学家交谈时，他们经常向我倾诉的一件事情。 为了完成更复杂的分析，或者由于其他方面难以克服的问题，他们学会了如何编程。 他们的编程和系统搭建技能达不到你从程序员或数据工程师那里会看到的水平 – 他们也没必要达到。
数据工程师的技能
编程能力是数据工程师的核心。这种能力背景通常是Java，Scala或Python的编程经验。 他们的工作重点或专业能力主要在分布式系统和大数据方面。 数据工程师具有高级编程和系统构建技能。
对于数据工程师，我对其一言以蔽之的定义是：数据工程师是在围绕大数据建立创建软件解决方案上具备专业技能的人。
利用这些工程技能，他们可以创建数据管线。 创建数据管线可能听起来很简单或微不足道，但在大数据这种规模上，这意味着将10-30种不同的大数据技术整合在一起。 更重要的是，数据工程师是理解并选择“适合处理某种工作的工具”的人。 数据工程师深入了解各种技术和框架，以及如何将它们组合在一起以创建解决方案，从而使公司的业务流程具备数据管线。
在我的经验中，数据工程师只是尽可能低限度地参与集群的运维(与此处讨论有关数据工程师的说法相反)。 虽然某些数据科学技术确实需要设置一个运维或者数据运维岗位，不过绝大多数技术都没有。 就像大多数程序员一样，我不允许他们直接访问生产系统。 这主要是系统管理员或运维人员的工作。
重叠技能
数据科学家和数据工程师技能之间存在重叠。 然而，重叠永远发生在每个人能力的不规则边缘。
比方说，这两个岗位在“分析”上重叠了。 但是，数据科学家的分析技能将远远超过数据工程师的分析技能。 数据工程师可以执行一些基本到中级的分析，但很难进行数据科学家所做的高级分析。
数据科学家和数据工程师在编程能力上有所重叠。 不过，数据工程师的编程技能远远超出了数据科学家的编程技能。 让数据科学家创建数据管线早已远离了他们技能优势边界，但却是数据工程师的优势所在。 在这种情况下，这两个角色是互补的，数据工程师对数据科学家的工作起支持作用。
您会注意到，数据科学家和数据工程师之间还存在一个大数据方面的重叠。 通过更好地了解每个岗位的技能，您现在可以更好的理解这种技能重叠。 数据工程师使用他们的编程和系统构建技能来创建大数据管线。 数据科学家利用他们更加有限的编程技能，运用他们的高级数学技能， 利用已经存在的数据管线创建高级数据产品。 “创建和使用”之间的这种差异，是在处理大数据时，团队失败或者表现不佳的核心之处。一个团队，如果期望他们的数据科学家创建数据管线，最后将会极其失望。
当机构把事情搞错了
不幸的是，一个机构误解每个岗位的核心技能和职位角色相当常见。一些机构认为数据科学家可以创建数据管线。 数据科学家可以将就地创建数据管线。 数据科学家创建数据管道的问题有几个方面。 请记住，数据科学家只是不得不学习编程和大数据。 他们是聪明的人，最终确实可以解决问题，但创建数据管线并不是他们的核心竞争力。
从管理角度来看，数据科学团队将陷入困境。 您将环顾四周或听取其他团队的意见，并将他们的进度与本团队的进度进行比较。 看起来，好像数据科学团队根本没有产出，或者表现不佳。 这是一种基于对数据科学家核心竞争力的误解，所产生的不公平的评估。
数据科学家从事数据工程
我见过公司要求数据科学家们做数据工程师所做的事情。 数据科学家的效率为20-30%。 数据科学家并不知道数据工程师所知道的事情。 创建数据管道并非易事 – 它需要高级编程技能，大数据框架理解和系统创建。 这些不是普通数据科学家所拥有的技能。 数据科学家可以获得这些技能; 然而，这段时间的投资回报率(ROI)非常低。 不要误解我：数据科学家确实需要编程和大数据技能，而不是数据工程师需要的水平。
在数据管线创建中，相对来说业余的数据科学家也会碰到这种问题：数据科学家会在选择工具上犯错误、进行错误的选择，而数据工程师则不会。 数据科学家通常不清楚或者不理解处理一个任务所需要的合适工具。对于所有任务都使用单一工具(往往是一个错误的工具)，最终把一切都搞砸。现实情况是，为了处理不同的工作，需要许多不同的工具。 合格的数据工程师会知道这些，数据科学家通常不会知道这些。
最近的一个例子是，数据科学家使用Apache Spark处理几十GB数据集。 的确，Spark可以处理这么多数据。 但是，一个小型数据程序会更快，也会执行的更好。他们的Spark任务需要10-15分钟才能执行，然而小数据的关系型数据库只需要0.01秒来完成同样的事情。 在这种情况下，数据科学家解决了这个问题，但却不明白这项工作的正确工具是什么。 在一天内完成这种消耗15分钟时间的工作16次，(这是低端的数据分析)，你的数据科学家每天就要花四个小时等待，因为他们正在使用错误的工具来完成这个任务。
在另一个机构中，他们的数据科学家没有任何数据工程资源。 数据科学家会处理这些问题，直到他们遇到无法解决的数据工程问题并且卡住。 他们向业务部门报告说，他们无法完成任务，就在那里让工作只完成了一半就停了下来。这导致数据科学家们截止到那个时刻都在浪费时间，并且据他们估计，就只因为无法完成工作，数百万美元的价值在那里悬而未决。
如果让一位数据科学家做数据工程师工作，一个更令人担忧的表现是数据科学家会感到沮丧并辞职。 我在许多机构中，和处理数据工程师工作的许多数据科学家交谈过。 对话总是一样的 ：数据科学家抱怨他们来公司是为了从事数据科学工作，而不是数据工程工作的。 他们把事情做完就需要完成数据工程工作，但让数据科学家做数据工程师的工作会让他们发疯。 他们会选择辞职，而您将会需要用3-6个月的时间来完成数据工程。 我在另一篇文章中更多地讨论了这些问题。
数据工程师与数据科学家的比率
决定数据工程师和数据科学家的比率是一个常见问题。在确定这个比率时，常见需要考虑的问题包括数据管线有多复杂，数据管线有多成熟，以及数据工程团队需要拥有多少经验。
拥有比数据工程师更多的数据科学家通常是个问题。 它通常意味着，机构正在让他们的数据科学家进行数据工程工作。 正如我之前所说的，这会进而导致各种各样的问题。
为每个数据科学家搭配2-3位数据工程师是一个常见配置。 对于一些具有更复杂数据工程要求的机构，这个数字可以是每个数据科学家配备4-5名数据工程师。 这包括那些数据工程和数据科学处于不同汇报组织结构中的机构。 您需要更多的数据工程师，因为创建数据管线需要比创建ML / AI部分花费更多的时间和精力。
我在《数据工程团队》一书中，更多地讨论了数据工程和数据科学团队应该如何相互交流。
数据工程师从事数据科学研究
一个远非常见的情况是数据工程师开始进行数据科学工作。 随着数据工程师开始提高他们的数学和统计技能，这是一个向上的推动力。 随着数据科学变得更加标准化，这种向上的推动力变得越来越普遍。 它导致了一种全新的工程师类型出现。
对机器学习工程师的需求
让我们直面这个事实：数据科学家来自学术背景。 他们通常拥有博士学位或硕士学位。 问题在于，他们宁愿写一篇关于问题的论文，而不是将某些东西投入生产。 其他时候，他们的编程能力只会扩展到在R中创建一些东西。把用R编写的东西放到生产中本身就是一个问题。 他们不像工程师那样思考如何建立系统。
数据科学家面临的一般问题是，他们不是将工作投入生产、创建数据管线以及公开这些AI / ML结果的工程师。
为了应对学术思维与“投入生产的需求”之间的差异，我们观察到了一种新型的工程师。 现在，这位工程师大多可以在美国看到。他们的头衔是机器学习工程师。
图3.显示机器学习工程师与数据科学家和数据工程师的匹配情况的图表。 Jesse Anderson和大数据研究所的插图
机器学习工程师主要来自数据工程背景。 他们经历了足够多的交叉培训，变得同时熟练掌握数据工程和数据科学。 一种不常见的途径是数据科学家在数据工程方面进行交叉训练。
对机器学习工程师，我一言以蔽之的定义是：机器学习工程师是坐在数据科学和数据工程的十字路口，并且熟练掌握数据工程和数据科学两方面的人。
如图2所示，您可能想知道在数据科学与数据工程之间存在的差距里会发生什么。 这正是机器学习工程师所处的位置，如图3所示。它们是数据工程师创建的数据管线与数据科学家所创造东西之间的桥梁。 机器学习工程师负责获取数据科学家发现或创造的内容，并使其在生产环境中发挥价值(值得注意的是，数据科学家创建的大部分内容并非在生产上有价值， 并且大部分被用技巧拼凑起来能够工作)。
机器学习工程师的工作，主要是创建数据科学管线的最后一步。 这可能需要几个部分。 它可能是将数据科学家的代码从R / Python重写为Java / Scala。 它可能是从软件工程的角度优化ML / AI代码，保证数据科学家写的代码能够运行良好(或者干脆就是能够运行)。 机器学习工程师具有足够的工程背景，可以在一个领域(数据科学)保障所必需的工程规范，这些领域以并不遵循良好的工程原理而著称。
在生产环境中运行的模型需要维护和输入，而普通的软件并不需要。 机器学习模型可能过时，并开始给出不正确或扭曲事实的结果。 这可能来自数据属性的改变，新数据的增加，或恶意性质的攻击。 无论是哪种方式导致的，机器学习工程师都需要时刻注意他们的模型中需要修改的部分，这可能导致模型的重新训练或调整。
机器学习工程师和数据工程师
数据工程师向机器学习工程师的过渡是一个缓慢的过程。 坦率来讲，我们将看到，变成机器学习工程师需要作出什么变化和变成数据科学家需要作出什么变化是非常相似的。
为了解释我的“缓慢变化”的意思，我将分享那些我见过的从数据工程师转变为机器学习工程师的人的经验。 他们花了数年时间做软件工程师和数据工程师的开发工作。 他们一直对统计学或数学感兴趣。 其他时候，他们只是厌倦了作为一名数据工程师所遇到的限制。 无论哪种方式，这种转变需要数年时间。 参加初级统计课程或初级学习机器课程之后，我没发现人们能立刻成为机器学习工程师。
正如我将数据科学家视为偏学术一样，数据工程师也不刚好是适合做机器学习工程师的。 一个工程师喜欢世界里的真和假，黑和白，以及1和0。他们不喜欢不确定性。 通过机器学习，模型的猜测存在一定程度的不确定性(工程师也不喜欢猜测)。 与大多数工程师不同，机器学习工程师可以跨越数据工程的确定性和数据科学的不确定性。
机器学习工程师日益增加的价值
进行数据科学的门槛正在逐渐降低。优秀实践正在逐步充实。 最常见的算法变为共识。 更好的消息是，有人已经编码并优化了这些算法。
这种不断增长的成熟性，使得数据科学家和机器学习工程师更容易将算法投入生产而无需编码。 我们也看到，数据科学变得更加自动化，有着更为自驱动的过程。 Google的AutoML就代表了这样一种趋势，工具会自动为您找到优秀算法，无需成熟数据科学家的工作即可获得结果。 DataRobot是另一种自动化技术，它为数据寻找优秀的数据科学算法。 它还将帮助机器学习工程师将算法投入生产。
这些工具不会取代硬核的数据科学，但它将使数据科学家能够专注于数据科学中更困难的部分。 它将使机器学习工程师变得越来越有生产力。 我们将逐渐看到，机器学习工程师的负担会越发减少，自动化算法越发增加。
未来应该期望机器学习工程师达到何种水平的生产力?我对这一点感到左右为难。简单来说，机器学习工程师是否要为他们的Web开发人员做Wordpress配置员? 在这种场景下，机器学习工程师可以通过众所周知的标准用例来提高工作效率，只有数据科学家才能处理真正的自定义工作。 或者，机器学习工程师会重新成为数据库管理员吗? 在对模型已知的深入了解，他们可以使用已知的、千篇一律的方法来配置模型，在50-80%的时候获得正确的结果，并且这足以满足所有需求。 要获得真正准确的结果，您会需要一位数据科学家。
机器学习工程师和数据科学家的生产力的关键，将会是他们的工具。 现在工具缺乏成熟度，这就是为什么我会好奇他们将来会有多么高效。
我希望数据科学的入门门槛继续降低。 这将使机器学习工程师能够在不大量增加知识的情况下完成更多的数据科学工作。 我希望机器学习工程师的角色在美国和全世界范围内变得越来越普遍。
该怎么做?
现在您已经看到了数据科学家和数据工程师之间的差异，您需要环顾整个机构，看看您需要在哪些地方作出改变。 这是我帮助其他机构完成的一项变革，他们已经看到了巨大的成果。 在数据科学小组似乎陷入困境、无法有作为的情况下，我们创建了数据工程团队，向数据科学和数据工程团队展示了如何协同工作，并制定了正确的流程。
这些变化使数据科学团队的生产力从20%提高到90%。 团队能够用相同数量的人做更多事情。 数据科学家们更开心，因为他们没有进行数据工程。 管理层可以开始基于备受期待的大数据提供价值。
您也许还会遇到一个新岗位，机器学习工程师。 随着您的数据科学和数据工程团队的成熟，您需要检查团队之间的差距。 您可能需要提拔一位数据工程师，在他的努力路径上让他成为机器学习工程师，或直接聘请一位机器学习工程师。
最后，大数据的绝大多数问题都是人和团队的问题。 它们不是技术问题(至少在最初阶段不是)。 技术通常会受到指责，因为责怪技术要比团队自省容易得多。 在您解决人事问题之前，您不会遇到真正棘手的技术问题，也不会创造出您所期望的大数据能够带来的价值。 诚实地审视您的团队和您的机构，看看您需要在哪里作出改变。
