对于Mixpanel，客户的数据是我们支付的最昂贵的东西。存储它，运行查询……维护最稳定、最可靠、最快速的用户分析平台，这就是基础设施团队的工作。这是一个乏味但必不可少的工作，使灯一直亮着。很多时候，当事情需要解决时，我们的团队来处理。因此，当我们在Mixpanel认识到我们并不真正知道客户的数据使用成本是多少时，我们很兴奋地找到了答案。当然，在宏观层面上，我们知道在月底谷歌云和SoftLayer向我们发送账单。但我们需要更多的颗粒。每个顾客用了多少钱？这和我们向他们收取Mixpanel的费用有什么关系？一般来说，我们有一个感觉：一个客户运行了多少个查询？他们收集了多少事件？他们创建了多少个人档案？就代理人而言，这些还可以，但代理人都一样。我们知道有可能得到更好的答案，作为一家数据驱动型公司，我们认为在这种情况下，从最简单的解决方案转向最合理的解决方案是势在必行的。因为在基础设施层面上，客户对Mixpanel成本的实际驱动因素不仅仅是人员配置文件的数量，而是三个因素。首先，是数据摄取。当最终用户访问我们的API时，数据必须从我们的边缘服务器流向我们的数据库。第二部分是数据存储。简单地说，持有数据要花钱。这两个成本的属性非常简单：它们与客户发送给我们的数据量成正比。第三个，也是最复杂的成本组成部分是计算，它用于服务查询。在这里，基于卷的方法由于Mixpanel的查询灵活性而失败；不同的查询可能需要截然不同的计算资源。我们曾经有两种观点来解释这些成本。首先，一天中每个客户的负载都很高，当我们的客户联机并运行查询时，CPU从零上升到最大。第二，我们预先为集群提供资源，以处理通常由最大客户引起的峰值负载。根据大数定律，对于我们大多数较小的客户来说，单个突发事件在一天中都很好地传播开来。但由于我们提供了峰值，而峰值主要是由较大的客户造成的，所以我们需要一种方法来确定峰值的属性。我们直接在Mixpanel中跟踪许多系统指标，包括每个查询使用的CPU量。为了确定一个项目对我们"峰值"的贡献，我们将一天分成2分钟的时段，并确定每个时段的峰值客户。考虑到googlecloud的定价，我们可以说2分钟的CPU成本是X美元，从这里可以简单地将每个bucket分配给控制它的项目。这对更大的项目非常有效，因为这些项目尤其是我们的成本。对于我们较小的项目，我们使用简单的、基于容量的方法来衡量它们对总体使用率的贡献，因为我们有太多这样的项目，平均值很好。一个简单的查询基础设施成本，按客户分类一旦我们将问题分解到这个问题，我们编写了一个简单的JQL查询来从Mixpanel中提取数据，并将计算出的成本导入Mixpanel中，以便在整个公司中方便地可视化和共享。作为Mixpanel用户，我们可以从这些数据中量化出一个可能有用的见解，那就是运行一个或两个复杂的查询要比运行几十个较小的查询便宜得多，即使它们都在服务于回答同一个问题。回答每个查询都有一个固定的成本，当您查询我们的API时，将许多较小的查询组合成一个更复杂的查询，无论是性能还是成本都更好。将这些数据保存在Mixpanel中有助于我们以多种方式运营我们的业务。首先，它帮助我们的支持/解决方案团队量化客户成本，而不是依赖于不精确的启发式方法，比如查询数量。其次，它使基础设施团队能够以整个公司都理解的方式，优先考虑效率改进，以最大限度地影响我们的底线。最后，它有助于我们的业务团队测试各种定价模型，以找到一个能使我们的利润与客户价值保持最佳一致的模型。在一个可共享、易于理解的Mixpanel项目中拥有这些知识，可以让整个公司的团队深入了解我们的成本，而不会被基础设施团队所阻碍。数据民主化可以让我的团队重新开始做重要的事情。