我们不需要数据工程师，我们需要为数据科学家提供更好的工具
来源：CPDA数据分析师网 / 时间：2021-05-08
通常这意味着翻译或生产数据科学家编写的笔记本和脚本， 可以用更好的数据科学家工具代替数据工程师的大部分角色，从而使数据工程师有更多的精力进行更具影响力（和可扩展）的工作，为什么这很重要？再次有一种想法出现在互联网上：我们不需要数据科学家，我们需要数据工程师，数据工程师”与“数据科学家”头衔的可用职位数量，让我们撇开一个事实，发布这些职位的招聘经理通常不知道这两个职位之间的区别，并且不能互换使用（或使用目前风格的任何东西）。
可用数据工程师职位的过剩仅仅是人事问题吗？
数据科学之所以混乱是因为它反映了现实世界，数据科学家是领域专家（除了了解统计信息之外），并且他们通常没有很强的编程背景，软件工程师和其他“技术人员”提出了这样的问题：“他们为什么不只是学习Spark？” 这种思维方式完全错过了这样一个事实，即数据科学家已经可以使用现有工具以较小的规模完成他们想做的事情，数据科学家希望获得见解，而不用担心建立优雅的管道，公司想要一些可行的东西，而不是美丽的东西。
洞察力比优雅的管道更为重要
流行的数据科学工具也受到更多技术人员和学者的批评，为什么有人会使用熊猫？ 熊猫必须是没用的人的仇恨工具，但是每天使用它的数据科学家都喜欢（或至少赞赏）它，如果熊猫是如此糟糕，为什么没有什么东西可以取代它作为Python数据科学的标准数据框架呢？为什么采用率每年都在继续增长？它不是快的，也不是强大的，那为什么呢？
数据工程师必须处理可伸缩工具无法处理的混乱情况
对于生产使用而言足够强大的可伸缩系统（例如Apache Spark）无法照原样处理现实世界的混乱情况，如果没有明确和简单的假设，很难进行扩展，问题越麻烦，扩展就越困难。数据工程师无法处理可伸缩性，因为可伸缩工具无法处理，在这种情况下，混乱可能意味着：
组/加入键偏斜
分区
调试分布式系统
集群配置和资源调配
对于小规模的系统，这些都不是您需要担心的事情。在湾区以外，大多数数据工程师花费时间进行调试并转换为分布式系统（通常是Spark）。
要使一次见解转化为生产作业，必须进行多次重写
我们真的不能在这里责骂任何人。如今开发使用可伸缩工具的人们正在为像他们自己这样的技术含量高的用户而建。技术含量高的人不需要他们的工具来处理他们的混乱情况，他们通常希望旋钮进行调整。 Dogfooding 在系统工程中是一个流行的概念：“构建它的人也使用它。” 我认为对狗食问题的过分担心会在一定程度上引起我们今天在数据科学中所看到的局面：“只有像构建系统的技术人员 才能 使用它。”
那么，数据工程师应该做什么？
数据科学生态系统需要的系统 不仅要 关注构建它的人的问题，在过去的10多年中，数据科学家大多被困在使用相同或相似的工具上，对此有两种解释：
（1）数据科学家之所以喜欢使用现有工具，是因为他们了解这些工具。
（2）那些能够构建大型系统的人在很大程度上（无意间）忽略了技术水平低于他们的问题。
我们需要数据工程师来帮助构建可扩展的工具，以增强数据科学家的能力，而不是将熊猫翻译成Spark，谁能比当今的数据工程师更好地帮助构建下一代数据科学工具？
用备忘单在SQL中进行数据准备！
如果您的原始数据位于基于SQL的数据湖中，为什么要花时间和金钱将数据导出到新的数据准备平台中？一个基本的问题是如何以及在何处进行数据准备。有充分的理由选择不同的工具和方法：
您的员工/同行熟悉哪种工具或语言？
您需要定期执行的可重复过程吗？
您的大部分数据当前位于哪里？
您正在处理什么数据量和速度？
存在哪些当前的云服务或本地资源来运行该过程？
哪些工具与您组织中的当前体系结构兼容？
您的数据集是否包含需要特殊保护的私有元素（HIPA，FERPA和GDPR）？
对于许多组织而言，这些问题的答案将导致出现SQL。SQL不仅在大多数组织中广为人知和使用，而且还利用了现有的数据库资源，安全性和管道。如果您的原始数据位于基于SQL的数据湖中，为什么要花时间和金钱将数据导出到新的数据准备平台中？
数据准备中的每个步骤提供SQL方法的样本
这并不是要详尽列出SQL函数或选项，而只是一个起点，SQL视图允许您以干净，安全，模块化的格式包装许多数据准备步骤的复杂性，您可以创建一个视图，以简单，可重用的格式访问该代码，而不是在Python或R代码中嵌入冗长而复杂的查询，通过屏蔽或隐藏模型访问，视图也是在私有数据元素上应用安全性的好方法，如果您已经在购买高性能的数据库许可证，为什么不通过在SQL中进行数据准备将它们用于数据科学呢？