这张照片来自 John Schnobrich 拍摄，来自 Unsplash

我在科技领域工作了25年，其中最后15年担任过各个阶段的分析领导者，涉及亚马逊、eBay、VMware等公司。在此期间，我经常看到非技术出身的领导者要求为相关方提供更多自助式的数据获取。他们的要求并非没有道理，很多时候，自助服务是以仪表板或自动化报告的形式实现的。但是，一些非技术背景的领导者无意中将自助服务推向风险领域，建议相关方能够通过编写SQL来自助获取数据。

启用这种自助服务存在风险，大多数非技术背景的领导者和利益相关者对此并不了解。我对此很有信心，因为我见过很多类似的情况，即使是数据专家也不一定了解这些风险。不应该轻率地让利益相关者访问SQL。以下是一些常被忽视的方面，你需要了解。

首先值得注意的是这一点，缺乏培训。每次当领导提议为利益相关者启用SQL访问时，我都会召集那些需要写SQL的利益相关者。

有些利益相关者可能有分析背景，但大多数利益相关者从未从事过分析工作。由于缺乏经验，利益相关者最好接受培训，学习使用SQL并理解数据环境，然后再被允许编写和运行SQL语句。虽然这听起来很合理，但它常常被忽视。只需问问任何在业界工作的数据分析师就知道了。

分析师很少会在工作中接受正式培训，大多数都是在执行任务时边做边学。或者他们从某个稍微资深一点的人那里学习，而这些人很可能也是用同样的方式学习的。从某种角度来看，这可能会让你觉得“这看起来很简单，任何人都能做”。但事实上并不简单，尽管看起来很简单。

仅仅因为分析师在做这份工作，并不意味着他们的工作每次都是准确的。这并不是针对分析师的批评，而是强调系统中存在的问题和不足，以及如何理解和支撑数据分析。

如果分析师没有接受过培训，我们还能期望非数据分析师比他们更出色，或者至少接受同样的培训吗？

如果你曾经写过 SQL，作为数据分析师，你就会知道，完全有可能写出一个没有运行时错误但结果不准确的 SQL 语句。事实上，这种情况经常发生。无论是 10 行代码还是长得多的脚本，在你第一次尝试编写代码时，几乎总是会出现错误。无论你从事这项工作多久，写过多少行代码，接受了多少培训，这个事实始终不变。问题在于，你知道有错误吗？

认为没有 bug 是不理智的。这些 bug 可能是当前导致错误结果的实际 bug，或者将来运行代码时才会出现问题的逻辑错误。虽然许多相关方认为或希望他们的所有报告准确无误，但实际上当前的生产报告和数据集中可能存在很多不准确的地方。

为了避免错误，有一些措施。但这些措施很脆弱，容易出问题，往往被忽视。

如果你能在没有错误抛出的情况下生成不准确的结果，你又怎么知道输出的结果是不准确的呢？

为了防止不准确的数据流入生产报告或输出，我们可以进行质量保证（QA）检查。这听起来很简单，但实际上通常不是这样。

在简单的例子中，我们可以这样理解 QA 检查：假设在 Excel 中有一行数据有两个值（每个值为 2），我们想将这两行相加。如果和是 10，我们知道有问题。这是显而易见的，因为数据集很小，我们可以心算出正确结果。如果和是 4，我们就认为数据是正确的，没有问题。但是这样的代码是正确的吗？

虽然计算结果是 2+2=4，但我们并没有查看这段代码。代码可能并没有写成如 “value_1 plus value_2” 这样的形式，而是写成了如 “value_1 times value_2” 这样的形式。只是在这一个情况下，两种逻辑恰好产生了相同的结果。质量检查通过了，但这并不足以证明逻辑的准确性。

对于一名分析师而言，质检变得困难、耗时且成本高昂。由于缺乏培训、系统复杂加上大量的紧急请求，许多数据分析师往往会忽略必要的质检步骤。例如，在亚马逊，我的团队涉及多个包含数百亿行的数据表，这使得质检工作异常棘手。

处理大型数据集时，快速查询数据并直观地检查输出常常是一项挑战，有时甚至感觉几乎无法做到。作为一名前软件质量保证工程团队的领导者，我最惊讶的是，公司数据工具并不是为了高效的质量保证而设计的。

这意味着很少有人实际在代码块之间做质量检查。分析师通常只是对最终结果进行质量检查。在许多情况下，这些检查只是汇总的抽查。很少有像经验丰富的质量检查员那样进行一对一的验证。

如果负责这项工作的分析师没有合适的工具或培训来进行有效的质量保证检查，我们能否期望利益相关者做得更好？

注：此处的"shifting"保留英文原样，因为它是专有名词或特定上下文中的关键术语，直接翻译可能无法准确传达原意。如果"shifting"在此处并非专有名词，而是描述地面移动的概念，可以翻译为“移动”或“变化”，具体翻译需根据上下文进一步确定。根据现有信息，保留英文原样更准确。

改为：

即使代码完全准确且无bug，仍然可能存在问题或bug的风险。因为底层的数据集和系统一直在变，昨天管用的方法今天可能不管用了，而你自己可能都不知道。

比如说，在我在 eBay 工作时，我的一个合作伙伴的分析团队有一个用于计算损失的指标。计算本身并不复杂，但涉及九个不同的字段。遗憾的是，代码和数据结构并不合理，这意味着当其他团队（比如我们团队）需要计算损失时，我们无法通过查询单一表格中的单一值来获取结果。我们只能复制他们的代码和逻辑。虽然这不算难，但仍然是一个大问题。

这是因为每当合作伙伴改变了他们的公式，我却无法得知这一变化。损失团队可以在他们的代码中更改逻辑，但这对我和其他人来说怎么办？我的代码可能会继续正常运行，但结果却可能是错误的。事实确实如此。但是即使采用了正确的工程实践，问题依然会出现。这通常发生在生产表被修改或弃用时。

随着时间的推移，数据工程和分析团队将会弃用某些表。有时他们会移除这些表，有时则会留下它们，但停止向该表中添加数据。理想情况下，表的所有者会通知所有用户即将弃用该表，并应相应更新所有相关查询。但就像我之前说的，这只是理想情况，现实生活中我们并不生活在这样的世界里。

在许多情况下，表的管理员通常会发封邮件给相关部门，告知有些变更即将发生。很少有保障措施确保需要了解变更的人都能看到通知。同样，也很少有保障措施确保变更被真正执行。再次，之前准确的查询和输出仍会被认为是准确的，但实际上已经不准确了。

如果数据分析师难以维持稳定的工程基础以避免基础变化，并且他们不知道如何处理 bug，那么非分析师又如何应对？

（注释：保持“bug”为英文原词）

即使每个人都经过了 SQL 编写的培训，进行了适当的质量保障，采用了最佳的架构实践方法，也及时了解了变更信息，还有一个问题：他们可能会对混乱的环境有所贡献。

由数据分析团队维护的分析环境通常显得比较混乱。我不确定每个分析师都会同意这种观点，但我认为我对这个问题有相当的了解。我曾在软件开发和质量保证团队工作，这些团队里有明确的标准和惯例。这些标准很少被应用到数据分析环境中。

在过去15年中，我一直处理这些分析架构问题。这些公司包括亚马逊、eBay、VMware等。请记住，这些公司在分析成熟度模型中处于领先地位。我从未遇到过一个已经存在足够高效和高质量的数据分析环境的情况。由于分析师面临的挑战，当非分析师进入这个环境时，问题往往会加剧。

以亚马逊为例，许多产品经理都有编写 SQL 和创建预定任务的能力。他们在这个环境中操作，就像分析师一样。不幸的是，他们并没有遵循我们团队开发的任何实践或规范。这导致系统使用中出现不一致、混乱和认知负担。这也带来了一系列其他问题。

如果分析师都难以营造一个干净一致的实践环境，我们还能期望那些在外部环境工作的非专业人士做得更好吗？

在亚马逊，一些产品经理可以自行使用自助服务，无意中承担了所有提到的风险。当这些表格被弃用或删除，或者系统发生变化时，有时相关方才会被告知这个变化。当他们得知情况时，并不是每次都修改代码或解决问题。相反，这项责任常常被转嫁给分析师。

总会，在利益相关方面临压力并有紧急请求时，修复代码的需求就会出现。这会将紧急请求转化为分析师的紧急请求，导致与分析团队合作的任何人的时间表都受到影响。这也是一种低效的代码更新方式。但这还不是唯一的麻烦。

当我们在后端系统上做重大更改时，我们的副总会收到我称之为“黑名单”的通知。如果有一些本应在截止日期前迁移的数据集未能迁移，这些邮件就会发给我们的副总。

不幸的是，由于利益相关者在分析环境中私下进行工作，编写自己的代码并安排任务，最终是分析团队，而不是出现问题的利益相关者，被追究责任。这对我们的团队品牌形象产生了负面影响。此外，分析团队还不得不追查利益相关方，确认他们的代码是否可以弃用还是需要维护。同样，更新不仅仅是修改一行代码那么简单，每次更新时都必须进行质量保证检查。

如果利益相关方无法支持自己的工作，您的数据分析团队是否已经准备好应对额外的工作量以及紧急的请求？

然后还有实际的成本。运行一个查询其实会花公司的钱。不幸的是，即使大多数分析师也没有意识到他们的查询实际上会花多少钱，使得表达更流畅且贴近口语。虽然分析师可能耐心等待查询结果，但人看到的时间和数据环境中实际处理时间是不一样的。

CPU和系统的使用量会根据多种因素动态变化。此外，关于使用情况的大多数数据显示并不明确，也不容易直接量化为具体的美元成本。

再说一次，根据我在亚马逊的工作经验，我不得不自己搭建报告和仪表板来帮助我的团队了解他们运行查询的成本。我们既没有现成的系统，也没有简单的方法来计算所有环境下的成本。这种缺乏透明度和架构问题常常导致即使没有人需要数据，预定任务也会被触发。

这种情况在某个部门发生过，该部门允许利益相关方访问SQL。当团队审计了计划任务时，我得知他们发现了超过1,000个利益相关方未使用的任务。但这些任务仍在定期执行，为公司带来了数千元的成本。

如果数据分析师不了解他们工作对财务的影响，非数据分析师会为公司造成多少成本？

接下来，我们面临的是多个真相来源的问题。减少或消除报告和仪表板中的多个真相来源是领导层经常提到的三大关注点之一。然而，考虑到我之前提到的情况，让更多的用户访问SQL会增加出现多个真相来源的风险。

当这事发生时，通常是数据分析和工程团队会被指责任。再说，这会让数据团队的形象受损，并让数据团队多查查非技术人员写的代码。

如果多个真相来源本身就已是个棘手的问题，你们的组织准备好面对更多的真相来源了吗？

作为一个数据分析师，不仅仅是编写查询和获取数据。几乎任何人都可以做到这点。但是，拥有数据并不保证它准确无误，更别提在特定使用情境下的准确性。在我工作过的每一家公司中，我都遇到过很多由于缺乏适当背景知识而导致的数据误用和误读的例子。

鉴于投入的时间和资金在推动数据驱动的决策上，以及因错误信息做出决策的后果，确保数据被正确解读是明智的。同样，在编写任何代码之前确保提出正确的问题也很明智。不幸的是，教会团队正确的需求收集和商业洞察力是提升分析团队最具挑战性的部分之一。但利益相关者也面临着同样的挑战。

如果分析師在處理利益相關者的請求時都難以獲得足夠的背景信息和細節，利益相關者又怎會知道他們使用的數據是否適合他們的背景？

非技术人员的领导经常希望增加自助服务功能，其中一些请求包括为非数据分析师提供SQL访问权限。虽然我对此并不完全反对，但在采取这种做法之前，必须先解决重大风险。

没有充分了解数据分析团队的运作方式、当前面临的挑战以及潜在的风险，负面结果很可能发生，。如果你打算开放访问权限，第一步是提升你团队的操作支持。

Brandon Southern，MBA，是高级分析总监，也是Analytics Mentor的创始人。在科技行业拥有25年的经验，Brandon在数据分析、软件开发、项目管理等领域都有卓越表现。他曾带领分析团队在亚马逊、eBay、VMware、GameStop等公司工作。

你可以了解更多关于布兰登和Analytics Mentor的信息，网址是_ http://www.analyticsmentor.io/。

原文发布于:https://www.analyticsmentor.io/blog/should-stakeholders-be-writing-sql