数据堆栈的隐性成本

我们在此列出与维护数据堆栈相关的部分隐藏成本。这里所说的数据堆栈，我们大致指的是由以下部分组成的现代数据堆栈：

• 数据源层（运营/生产数据库和第三方数据源）
• ETL 层，用于将所有源数据整理到数据仓库中
• 存储层（数据仓库）
• 查询层（BI 工具）

本文并非旨在引起恐慌、不确定和怀疑；我们只是认为突出一些管理成本的机会会很有用。我们没有按任何顺序列出这些成本，因为成本的大小因组织而异，因此您可以选择解决某些成本，而不是其他成本。我们将首先介绍问题领域，然后探讨降低这些成本的不同方法。

隐藏成本

培训和学习曲线

一个经常被忽视的成本是，您堆栈中的工具会产生一些培训开销。或者，您可以为已经掌握某些工具或堆栈层的人支付更高的薪水。这种开销与您的 BI 工具尤其相关，因为 BI 工具（数据堆栈的窗口）将拥有最多的用户群，每个用户都有不同程度的经验。

这里要指出的另一点是，学习曲线会带来两种不同类型的成本。第一种成本是培训员工使用这些工具所需的时间，无论是通过主动培训（您正在为人们举办培训课程），还是自学培训，您都希望人们阅读文档、弄清楚问题并从实践中学习。

第二种成本，采用失败，可能更微妙：如果该工具难以学习，人们就不会费心以使其高效的方式学习该产品。或者，更糟糕的是，他们根本不会费心学习该产品，最终您为组织产生零价值的许可证付费。

迭代滞后

团队可以多快地迭代自己的报告？也就是说，您可以多快地根据新信息更新报告（无论新信息来自市场变化，还是产品中新近检测到的事件）？

具体来说，我们的意思是，如果对于数据堆栈的每个“构建”（这里我们指的是“构建”数据仓库的 ETL 层），您都需要处理整个表，那么迭代更改该构建的成本是不可忽视的。

如果在做出更改后，您从分析该数据的人员那里收到反馈，指出某些数据看起来不正常，或者您需要合并更多数据，那么向模型添加或更改几列可能会花费您相当可观的工资和云成本。

僵尸 ETL 作业和报告

人们创建和安排报告。然后他们继续创建新报告，并安排这些报告。他们停止查看旧报告，但旧报告仍在运行，即使您聘请更多人，他们也会创建和安排更多报告……问题是，大多数云数据库提供商按查询收费，因此您最终为自己不利用的分析付费。

巴士系数

虽然并非数据团队特有，但当这些团队的专家离开公司时，数据和团队孤岛很容易发生“知识重置”。

缓存成本

缓存在很大程度上是一种节省成本的方法，但某些解决方案需要将您的数据缓存在单独的数据库中，然后向您收费。也许这个成本是值得的，也许不是。

缺乏可扩展性

BI 工具应该能够与您的团队已经熟悉的工具良好协作。例如，您可以使用 Metabase 对您的数据进行建模，然后让人们使用他们想要的任何工具来创建报告。如果有些人更习惯于使用电子表格软件，他们可以直接从 Metabase 导出数据并在他们选择的电子表格软件中进行分析，这完全没问题。问题是工具强迫您使用它们。

维护多个事实来源

在多个位置存储大致相同的数据可能会导致两个问题：第一个问题是您最终可能会浪费时间来弄清楚您可以依赖哪些数据。第二个相关且更具破坏性的问题是，您最终可能会根据错误或不正确的数据做出决策（错误是指您应该使用其他更相关的数据，而不正确是指数据本身不准确或不完整）。

帐户层级调整

虽然很小，但仍然很麻烦。由于某些计划提供不同类型的帐户，在不同的价格点具有不同的能力，因此您必须处理如何分配这些能力。某些创建者许可证可能是基本帐户的 10 倍，因此您必须花费时间来弄清楚谁获得许可证以及原因，以及何时随着业务变化增加或减少许可证数量。

这些分层帐户的另一个问题是，由于只有某些帐户类型被允许创建报告或进行更改，因此它们保证您会在工作流程中构建瓶颈（想想：临时请求队列）。

如何降低数据堆栈成本

以下是您可以采取的非详尽措施列表，以减轻上述问题。每个建议都可以帮助降低上述一项或多项成本。

使用不需要 SQL 来查询数据的工具

您肯定希望拥有一个可以使用 SQL 的工具，但您还需要一种让不懂 SQL 的人与数据交互的方式。查询构建器越直观，人们就可以越快地掌握 BI 工具，这意味着更多人会真正使用您付费的软件。

举办培训课程和数据共享

这些培训课程不必是正式的。只需将人们聚集在一起，让他们通过制作与其相关的仪表板来学习。一旦人们掌握了该工具，并了解了数据的位置，您只需为新员工举办培训课程即可。

您不能仅仅培训工具；您必须向人们展示他们可以使用哪些数据以及数据的位置。如果该工具足够好，它应该有大量的文档和学习资源。但是，如果人们不知道在哪里找到与其领域相关的数据，那么这些知识就浪费了。

记录您的数据

说到培训：数据文档是公司核心基础设施的一部分，但是，是的，好吧，祝您好运。只有在您分配人员来做这件事时，您的数据才有可能被记录下来；也就是说，您需要为这项工作开工单，并真正完成它。如果您还没有资源来做这项工作，您可以尝试一些强制功能，这些功能至少可以使部分数据被记录下来。例如，您可以轮流在团队或公司会议上重点介绍某些模型或报告，这可以激励人们实际写下内容（例如，填写列描述、向仪表板添加上下文等）。记录您的数据可能看起来像西西弗斯式的徒劳之举，但每一点帮助都至关重要，这些文档将在知识共享、入职培训和决策方面带来回报。

定期修剪计划的报告

某些工具附带审计工具，可以告诉您计划的报告运行的频率。如果您怀疑人们没有查看某些报告，请将其存档，看看是否有人抱怨。即使他们抱怨，也请与他们讨论降低报告运行频率，或完全关闭报告，而只需在需要时让人们运行它。

使构建、维护和修改模型更容易

让每个团队都可以轻松地管理自己的数据集。这些团队了解数据描述的领域，因此他们可以很好地识别哪些数据是相关的，哪些是不相关的。

这里一个有用的区分是基础模型和报告模型之间的区别。

理想情况下，您应该拥有一组基础模型：您的数据团队或分析师或工程师整理的清理过的相对原始的数据。这些模型中的数据是干净且正确的，但尚未针对特定领域进行管理。对此模型的更改应该很少见，因为它们可能很昂贵。

报告模型是下游模型，团队可以构建和更新这些模型以响应他们需要回答的问题。这些模型是轻量级且灵活的。它们的制作成本更低，虽然可以由分析师验证，但不受分析师的限制。

本节值得写一整篇文章，因此我们现在就此打住。

避免使用分层帐户的工具

如果您想收紧对谁可以做什么的控制，那应该是权限问题，而不是定价问题。我们（Metabase）采用分层产品模型（免费与企业版/专业版）的原因之一是因为我们认为帐户层级模型很烦人。Metabase 并非独一无二，但总的来说，如果您避开那些不会让您弄清楚您想为哪些人支付更多费用的软件，您将减少开销。

分散您的数据团队

如果您有一个深厚的数据人才储备，请将分析师嵌入到团队中以发展领域专业知识，并帮助团队学习如何自己创建报告。理想情况下，数据分析师应该在教授和审查他人的报告方面投入与编写报告本身一样多的精力。

谨慎升级（或让其他人为您做）

仅当您从新功能中受益时才升级工具。或者（更好）通过将升级外包给服务来降低风险并节省时间。如果出现问题，那不是您的问题。