我们在Mixpanel遇到的一个更愉快的问题就是随着客户的增长而增长。随着规模的扩大，他们想要分析的数据量也在不断增加，以构建优秀的产品；随着这些产品的规模不断扩大，我们的基础设施成本也在不断增加。我们处理的数据量庞大，每年超过26000家企业和超过9万亿个数据点。对于我们的客户来说，即时洞察力和最终洞察力之间的差异是巨大的。作为基础设施团队的技术主管，我的主要职责是确保这些见解快速、经济地出现。这就是为什么我们构建了一个分布式的、面向列的数据库Arb，在这里有更详细的概述。我们基础设施的可扩展性一直是我们在销售过程和留住客户方面的一大优势，因此保持这种优势至关重要。与大多数数据库相比，我们的数据工作负载的一个独特方面是查询和数据的灵活性。灵活的查询意味着客户可以使用任意复杂的过滤器进行查询，从而实时深入了解数十亿个事件。这意味着，如果客户希望查看根据他们跟踪到Mixpanel的任何属性筛选到他们刚刚定义的特定用户群的事件，他们可以。在数据方面，由于我们允许灵活的模式以便于集成，事件可以具有混合类型的属性，有时还没有定义字段。我们使用Linux性能计数器分析了查询引擎在特别慢的查询上的性能，发现过滤器性能是非常普遍的瓶颈。我们对其他高比例分析数据库中常用的技术做了一些研究，如Cloudera的Impala、Facebook的Presto和HP的Vertica，以期对解决这个问题有所启发。我们发现了我们决定在自己的数据库中实现的两大类优化：矢量化和谓词下推。在这里，我们将深入研究如何集成这些思想，使我们的核心查询引擎对于这些复杂、灵活的查询更具性能。批处理事件意味着更好的性能Mixpanel在每个事件中计算一次输入的过滤器。如果你想过滤城市等于旧金山，操作系统是Mac OS X，浏览器是Chrome，我们将扫描相关数据集中的每一个事件，将这些过滤器应用到其中，并删除不符合相关标准的事件，只发出查询者正在寻找的事件。带有过滤器的Mixpanel查询虽然这对于小型/简单的过滤器表达式来说很好，但是树遍历中涉及的函数调用和分支对于较大的客户来说是一个巨大的开销。更少、更复杂的查询是查询Mixpanel的更有效的方法，因此我们的性能必须准备好处理客户向我们抛出的每一个可能的查询。为了保持这一优势，我们转向了计算机科学中的一个经典优化：批处理。我们没有一次读取和过滤单个事件，而是修改了查询引擎，以便一次对多个事件进行操作。这使得我们可以在一批事件中分摊昂贵的读取和过滤。这将某些大型查询的查询吞吐量提高了2倍，为我们最大的客户带来了更快的查询延迟。但是，它有一个限制：矢量化要求所有查询属性的数据具有相同的数据类型（它们必须都是字符串、数字或日期时间）。我们实现了一个灵活的模式，因为这一层可以防止大量的数据矢量化。在混乱中寻找一致性我们不能完全解决变量数据的问题。但是，我们可以尝试从查询中的筛选器推断查询实际需要的数据类型。通过查看筛选器树的子表达式，我们可以确定即使给定的属性可能是混合类型，我们也可以在筛选器表达式的更高层对其类型做出一些保证。这最好用例子来说明。采用以下过滤器：编号（event["video_id"]）==1234，event["video_size"]=="中"假设video_id是一个混合类型的属性，这意味着有时被分类为数字，有时被分类为字符串。但是，过滤器将其强制转换为一个数字；这意味着"谓词"数字（event["video_id"]）保证是一个数字。类似地，假设"video_size"有时是数字，有时是字符串。但是，我们必须知道，布尔运算符必须产生一个等式。因此，我们知道谓词event["video_size"]=="Medium"保证是布尔值，而不管视频大小的实际类型是什么。这样，我们就可以将混合类型属性上的筛选器转换为统一类型的"谓词"（如强制转换或相等）的筛选器。这使得矢量化能够发挥作用，并使吞吐量提高2倍。为了实现这一点，我们将过滤器分解为这些谓词，并将这些信息提供给事件读取逻辑。当我们阅读混合类型的事件属性时，我们使用这个谓词信息将这些属性转换为统一类型的谓词。因为我们的过滤器现在对统一类型的数据进行操作，它们可以按照上面描述的方式进行批处理，并且我们能够在更多类型的查询上实现2倍的改进！性能是一个特点我们为Mixpanel在可靠性和速度方面的记录感到非常自豪，并将其与其他任何公司的记录相媲美。我们也很高兴能够不断发现诸如矢量化和谓词下推等前沿改进，这些改进将继续允许我们继续为客户提供更快、更具成本效益的体验。与此同时，这些改进的结果已经得到了回报，并帮助我们以MTU定价模型的形式将这些好处传递给我们的客户，我们将于下周在Signal上撰写该模型。