在数据工程团队中，列表很长，取决于您的个人角色。但我的一般选择是“最终数据科学家和数据分析师糟糕的 SQL 语句”。
可能不是一个明显的答案，所以让我解释一下。
如果您正在使用数据仓库，让我们从数据工程团队的三个主要工作领域的角度来看这个问题：
构建 ETL 管道
→ 将数据导入您的仓库
构建转换→加入/转换不同的数据集
公开数据以供下游使用
→ 报告、分析、ML/AI
数据工程师还需要对元数据进行分类和组织，并定义从仓库写入和读取数据的流程。在某种程度上，他们是数据仓库的图书馆员。
然后目标是尽可能抽象和自动化。通过自动化，数据工程师可以将他们稀缺的时间用于构建与维护/修复。
您还通过向您提供的数据添加 SLA 来向业务做出承诺。
“报告将在太平洋标准时间早上 6 点之前完成”或“我们的分析环境仅比我们的生产环境晚 15 分钟”。
瞧，您已经完成了以上所有工作，将其投入生产，稍作调整，一切正常。你可以继续做别的事情。嗯，不。
变革的驱动力
事情不是一成不变的。如果您正在为一家不断发展的企业工作，那么您将不得不应对三个挑战：
数据量在 5 年内增长约 10 倍，同时出现了越来越多的新型数据源
模型的数量正在增长。随着您将更多数据引入您的仓库，您可以以无限新的方式组合这些数据。你会听到术语“DAG”（有向无环图）。
用户和工具的数量正在增长。随着业务的增长，需要/想要访问数据的人数也在增加。他们将希望使用他们选择的工具访问这些数据。
数据工程的挑战
现在你是负责这个堆栈的数据工程师。您的公司将雇用更多的数据工程师来保持运转。例如，Netflix 每个数据源都有一名数据工程师，他们的全部工作就是保持该数据源的盘子旋转。
但并非每家公司都有 Netflix 的预算。人数有上限。但是，贵公司招聘的数据科学家和分析师的数量似乎没有限制。更多的关注数据是“数据驱动的”。
因此，“数据构建者”（数据工程师）和“数据消费者”（数据分析师、科学家、机器学习应用程序等）之间的比例猛增。
我看到（数据构建者）与（数据消费者）的比率介于 1:20 到 1:40 之间。一名数据工程师必须支持 20-40 个下游用户。
这就是问题开始的地方。回到最初的三个工作领域，将会发生以下情况：
ETL 管道运行很长时间并产生错误和问题。不过，您可能只能在运行后发现，现在您必须弄清楚是什么损坏了。这是一个巨大的干扰。
现有的模型可能无法提供企业想要的答案。分析师想要快速行动，因此他们绕过您并开始添加新模型，甚至直接在您的仓库中查询原始数据。如果基础表发生变化，这会导致模型膨胀和损坏。
您的最终用户可能正在使用为他们生成 SQL 的工具。或者他们编写自己的 SQL 语句。这两种方法都可能导致糟糕的 SQL 语法使整个仓库紧张，每个人的查询速度都很慢。
然后用户向数据工程师提交支持票（“我的查询很慢”，或者“我的查询没有完成或完成”）。你会被支持请求淹没。
我们当然是在戏剧化，但从方向上讲，这是工作中最糟糕的三个部分。让我们称之为“保持盘子旋转”。
数据工程中最糟糕的部分
我书中最糟糕的一点是最后一点——处理糟糕的 SQL。
那是因为管道和模型是您可以控制的。约定、工具、监控、警报、访问权限等——有一种方法可以在事物周围设置护栏。
但是控制最终用户和他们的 SQL 是不可能的。例如，我见过没有 WHERE 子句的“SELECT *”查询，它连接两个表，每个表有 20 亿行。输出量如此之大，以至于它会填满并取下仓库。
“谁写了那个查询？？”。
不太引人注目的结果包括编写查询，例如10 分钟的执行时间，一个小的更改可能会导致 1 分钟的执行时间。这听起来可能没什么大不了的（“我会同时去喝杯咖啡”），但这是生产力的巨大损失。对于数据科学，快速迭代和测试模型就是一切。
是的，您可以设置规则来终止查询，但所做的只是增加分析师文件的支持票数，因为查询没有完成。
对于数据工程师来说，这些查询是谁编写的也不是很明显。分析师使用的工具掩盖了他们背后的用户。 Tableau、Looker 或 Mode Analytics 等仪表板工具在您的仓库中显示为一个用户。
但在他们身后，他们可能有 100-200 人在编写查询。因此，您使用“Looker”作为用户，但您不知道是“Jack”、“Anne”还是“Joe”编写了查询。因此，要找出发生了什么以及谁编写了哪个查询，需要进行大量的挖掘工作。
概括
所以你去，上面是长版本。答案的简短版本是“最终用户的 SQL 语句不佳”。
这是一个问题，原因有以下三个：
您无法控制分析师编写的 SQL 语法。您可能只有在查询运行并造成损坏后才能发现。
分析师用来编写查询的工具掩盖了他们背后的用户。在拥有数百名用户的情况下，找到编写查询的用户就像大海捞针一样。
您不能只是关闭分析师或终止他们的查询——这将导致支持票证的增加以及数据工程和数据消费者之间的摩擦。
随着数据生产者与数据消费者的比例越来越大，问题只会越来越大。您必须支持的最终用户越多，您必须处理的投诉和罚单就越多，这是一个巨大的挫败感和时间浪费。
当然，这个问题的答案是让分析师能够编写更好的 SQL，并帮助数据工程师在这方面与分析师协作。