Mixpanel 的分析 UI 由内部数据库 Arb 提供支持，该数据库专为实时提取、存储和查询数万亿个事件而构建。本页介绍了我们设计的核心方面、它为用户消除的痛点以及它与其他系统的比较。

以事件为中心

Mixpanel 专为采集、存储和查询事件而构建。每个事件都有一个名称、一个时间戳、一个唯一标识符、一个用于标识执行事件的实体的 distinct_id 以及一个 JSON 属性 blob。

{ "event": "Signed up", "properties": { "time": 1618716477000, "distinct_id": "alice@mixpanel.com", "$insert_id": "29fc2962–6d9c-455d-95ad-95b84f09b9e4", "Referred by": "Friend", "URL": "mixpanel.com/signup", }}

事件是一种简单而强大的数据收集和存储方式，原因如下：

事件与现实世界的行为清晰对应。当用户在某个时间点发生某事时，您可以利用所了解的有关该事件的所有背景信息来跟踪该事件。事件是细粒度的。任何有关用户参与度、转化率或留存率的问题都可以建模为用户事件流的聚合。事件数据模型不会对可能收到的查询做出任何假设，因此它可作为支持任意查询的灵活基础。事件可以完全即时地按任何属性汇总（以形成指标）或按任何属性细分（以深入研究指标）。事件是不可变的，并且只能追加。当现实世界中发生某事时，它永远不会“不发生”。不变性使得以高性能和经济高效的方式设计事件原生系统成为可能。事件非常灵活。它们可以模拟超出用户活动范围的操作：支持票证、拉取请求、Slack 消息、付款、来自数据库的 CDC 等。

这消除了：预先计算，汇总或索引。

针对交互式用户加入进行了优化

Mixpanel 的 UI 专为基于事件的指标的交互式探索而构建。我们必须在几秒钟内响应查询，才能让大规模数据探索变得令人愉悦。

我们的查询引擎采用了常用的 CPU 性能技术：列式存储、字典编码、查询优化器和用 C/C++ 专门构建的查询引擎。

我们还根据事件的“distinct_id”（用于标识执行事件的参与者的属性）对其进行分片，并按“时间”排序。这与我们的内存查询引擎相结合，使行为查询（漏斗、流程、保留）能够以高并行度计算，无需改组，也无需昂贵的事实连接，从而降低查询延迟。

最后，我们受益于云经济：1 个 CPU 使用 100 秒的成本与 100 个 CPU 使用 1 秒的成本相同，但后者的查询响应速度要快 100 倍。多租户使这种方法能够大规模实现，并支持对数十亿个事件进行快速查询。

这消除了：数据采样、事实连接和仪表板的手动刷新。

即时的

事件到达我们的采集服务器后，几秒钟内即可在 Mixpanel 中进行分析。Arb 利用 lambda 架构以行格式收集近期事件，同时以按时间分区的列格式存储历史事件。这可以实现快速、实时的分析和高效的历史分析。

这消除了：等待定期的 ETL 作业或缓存填充。

读时模式

事件包含一组任意的 JSON 属性。与给定事件类型关联的属性通常是稳定的，但当新功能添加到被跟踪的产品时，它们可能会偶尔发生变化。在收集时强制执行架构的系统需要进行某种架构升级才能实现这一点，这可能非常耗时，尤其是在从客户端设备收集事件时。也就是说，架构对于向执行分析的人员提供属性自动完成等功能非常有用。

Mixpanel 使用读取时模式解决了这两个问题。事件以任意 JSON 格式提取和存储，我们实时推断模式以支持 UI 中的自动完成菜单。我们的模式推断还考虑了新近性，因此陈旧的模式会自然过时。

这消除了：模式迁移。

星型模式

Mixpanel 的数据模型基本上是星型模式：事件是事实，用户资料/查找表是维度。事件通常从客户端设备和服务器日志中流式传输，而维度数据则定期从记录系统加载，并为事件提供丰富的信息以供分析。

Arb 的查询和存储引擎可以动态运行星型架构连接。这意味着事件和维度可以随时加载而无需任何协调，而不必在提取时进行连接。这种查询时方法还可以追溯地进行事件和维度的回填。

这会消除：摄取时丰富。流式传输和批处理系统之间的协调。

幂等

Mixpanel 的摄取管道是幂等的，这意味着意外多次发送的事件不会影响分析。这简化了将 Mixpanel 集成到您自己的流式或批量数据管道中的过程，因为它将一次摄取转变为至少一次摄取。与其他在摄取时在短时间窗口内进行重复数据删除的系统不同，我们采用一种新颖的查询时间重复数据删除方法。这使我们能够检测到重复项，即使它们在几个月后才到达。

这样可以消除：保留您已发送到 Mixpanel 的状态。

云原生

Mixpanel 是一款完全托管的云应用程序，由 Mixpanel 团队维护并部署在 Google Cloud 上。与其他云原生数据库一样，它将计算与存储分离，从而降低了大规模成本。

使用 Google Cloud 还让我们能够利用云原语更快地交付功能、在负载增加时无缝扩展，并利用 Google 提供的企业级安全性。

这消除了：服务器维护，升级和容量配置。

开放 API

集成 Mixpanel 的方法有很多，但都基于我们的 JSON-over-HTTP API。我们相信，使用您已经使用的任何工具（无论是 CDP、数据管道还是简单的 cURL），将数据导入或导出 Mixpanel 应该很容易。

这种方法使我们能够接入更广泛的数据生态系统，从而可以轻松地将实时事件流传输到 Mixpanel 中，也可以从数据仓库等真实来源系统加载数据。这是一个参考，即通过我们的 API 将数据引入 Mixpanel 的混合架构。

这消除了：复杂的集成和专有数据格式。

与其他系统的比较

Mixpanel 做出了一系列权衡以实现上述设计目标。在这里，我们将 Mixpanel 与其他流行的数据库系统进行比较，以便将这些权衡放在上下文中：

Mixpanel 不是像 MySQL、Postgres 或 DynamoDB 这样的 OLTP 系统。我们不支持 ACID 事务、索引、点查找或任意 SQL。话虽如此，Mixpanel 可以从 OLTP 数据库中提取变更数据捕获事件以提供行为分析。Mixpanel 不是像 Snowflake 或 BigQuery 这样的数据仓库。数据仓库提供关系模型和与之配合的 SQL 语义。它们是您收集的所有业务数据的可扩展记录系统的绝佳选择，并支持各种查询。然而，这种通用性在提取实时事件和回答产品分析问题时会带来较差的性能和人机工程学。Mixpanel 可以通过仓库连接器从数据仓库中提取数据。Mixpanel 与 Clickhouse、Druid 或 Pinot 等 OLAP 系统类似。它们都针对不可变数据的快速自助分析进行了优化，并支持实时或批量提取。后者是开源系统，支持类似 SQL 的方言。这意味着它们可以插入开源或现成的收集或可视化工具。但是，它们需要开发人员的时间来维护，成本高昂，因为它们没有解耦计算和存储，而且由于无法从多租户中受益，因此速度也会更慢。最后，对于行为分析所需的用户连接类型，它们的速度很慢。Mixpanel 是完全托管的，从 UX 到数据库垂直集成，并且专为用户连接而构建。

归根结底，Mixpanel 专注于在大规模、不可变的事件流的基础上回答有关用户行为（渠道、流程、留存）的问题。我们通过专注于此用例实现了性能、成本和易用性的阶跃函数改进，并提供开放 API 以插入数据生态系统中的任何其他工具。

作者:Vijay Jayaram

出处:https://engineering.mixpanel.com/under-the-hood-of-mixpanels-infrastructure-0c7682125e9b