数据栈的隐藏成本

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

• 数据源层（操作/生产数据库和第三方数据源）
• 一个 ETL 层，将所有这些源数据整理到数据仓库中
• 一个存储层（数据仓库）
• 一个查询层（BI 工具）

本文并非旨在引发 FUD（恐惧、不确定性和怀疑）；我们只是觉得指出一些管理成本的机会会很有用。我们没有按任何顺序罗列这些成本，因为成本的大小因组织而异，所以您可能会选择解决某些成本，而不是其他成本。我们将首先介绍问题空间，然后探讨可以减轻这些成本的不同方法。

隐藏成本

培训和学习曲线

一个经常被忽视的成本是，您的数据栈中的工具会产生一些培训开销。或者，您为已经掌握了某个工具或数据栈层的人员支付更高的薪水。这种开销对您的 BI 工具尤其重要，因为 BI 工具——您的数据栈的窗口——将拥有最大的用户群体，每个人的经验水平各不相同。

这里需要指出的另一点是，学习曲线会带来两种不同类型的成本。第一种成本是培训员工使用这些工具所需的时间，可以通过**主动**培训（您与员工一起举办培训课程），也可以通过**自主**培训，即您期望员工阅读文档、自行摸索和边干边学。

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

迭代滞后

团队更新自己报告的速度有多快？也就是说，您可以根据新信息（无论是市场变化还是产品中新部署的事件）更新报告的速度有多快？

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

如果在进行更改后，您收到分析该数据的人员的反馈，说某些数据看起来不对，或者您需要纳入**更多**数据，那么在模型中添加或更改几个列可能会让您在工资和云成本方面付出可观的代价。

僵尸 ETL 作业和报告

人们创建并安排报告。然后他们继续创建新的报告，并安排这些报告。他们停止查看旧报告，但旧报告却仍在运行，即使您雇佣了更多的人，他们创建并安排了更多的报告……问题是，大多数云数据库提供商按查询收费，所以您最终为没有利用的分析付费。

巴士因素

虽然并非数据团队特有，但数据和团队孤岛容易在团队专家离职时发生“知识重置”。

缓存成本

缓存主要是节省成本，但有些解决方案需要将数据缓存到单独的数据库中，然后向您收取费用。也许这个成本值得，也许不值得。

缺乏可扩展性

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

维护多个单一事实来源

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

账户层级管理

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

这些分级账户的另一个问题是，由于只有某些账户类型才允许创建报告或进行更改，它们保证了您的工作流程中会出现瓶颈（例如：临时请求队列）。

如何降低数据栈成本

以下是非穷尽的您可以采取的措施清单，以缓解上述问题。每个建议都有助于降低上述一个或多个成本。

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

您肯定需要一个可以使用 SQL 的工具，但您也需要一种让不懂 SQL 的人与数据交互的方式。查询构建器越直观，人们学习 BI 工具的速度就越快，这意味着会有更多人实际**使用**您所付费的软件。

举办培训课程和数据共享

这些培训课程不必是正式的。只需召集大家，让他们通过制作与他们相关的仪表板来学习。一旦人们掌握了工具并了解了数据在哪里，您只需为新员工举办培训课程。

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

记录您的数据

说到培训：数据文档是公司核心基础设施的一部分，但是，好吧，祝你好运。您的数据可能只有在您指派人员去做时才会得到文档化；也就是说，您需要记录这项工作并实际完成。如果您还没有资源来做这项工作，您可以尝试一些强制性措施，至少可以文档化**一些**数据。例如，您可以轮流在团队或公司会议上突出显示某些模型或报告，这可以激励人们实际记录下来（例如，填写列描述，为仪表板添加上下文等）。记录数据可能看起来像西西弗斯式的任务，但每一点努力都有帮助，这些文档将在知识共享、入职培训和决策方面带来丰厚的回报。

定期清理已安排的报告

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

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

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

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

理想情况下，您有一套基础模型：由数据团队、分析师或工程师整理的干净、相对原始的数据。这些模型中的数据是干净和正确的，但尚未为特定领域进行整理。对这些模型的更改应该不频繁，因为更改的成本可能很高。

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

本节值得写一整篇文章，所以我们暂时就讲到这里。

避免使用分级账户的工具

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

分散您的数据团队

如果您有一个强大的数据团队，将分析师嵌入到团队中，以发展领域专业知识，并帮助团队学习如何自己创建报告。理想情况下，数据分析师应该像自己编写报告一样，教授和验证其他人的报告。

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

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