Event-User模型

数据驱动四个步骤，数据采集、数据建模、数据分析、指标体系，这里对应的是数据建模。目前数据开发中最常用的数据建模其实就是维度建模，本文中所参考的神策分析的数据建模也不例外，其架构就是简化了的维度建模，其中event表存储的是用户的一个个行为，是一张事实表，user表和item表是维度表，存储的是事实表中user对象和item对象的扩展信息，在进行分析时通过join进行关联查询分析。

神策分析的数据模型设计

在介绍数据导入模块与数据存储模块之前，我们需要先讨论一下神策分析的数据模型设计。

前面已经提到，神策分析主要解决的是用户行为分析这么一个特定领域的数据分析需求，并且期望尽量简化数据模型以降低 ETL 代价。最终，我们选择了业内非常流行的 Event + User 模型，可以覆盖客户的绝大部分分析需求，并且对于采集到的数据不需要有太多的 ETL 工作。

Event 主要是描述用户做了什么事情。每一条 Event 数据对应用户的一次事件，由 用户 ID、Event 名称、自定义属性三部分组成。Event 名称主要是对 Event 的一个分类，例如“PageView”、“Search”、“PayOrder”等等。我们在客户端会默认采集设备 ID 或者 Cookie ID 作为用户 ID，客户也可以自己设置一个合理的用户 ID。而我们最多可以支持一万个自定义属性，并且开发者并不需要事先告之系统，系统会自动从接收的数据中解析发现新的字段并且进行相应的处理。Event 数据以追加为主，不可修改，这也符合事件这一概念的实际物理意义。不过，为了方便后续系统的运维以及客户的使用，我们特别为 Event 数据提供了有限的数据删除能力，这一点会在后续存储部分更详尽地描述。

User 则主要描述用户是个什么样的人。它由用户 ID 与自定义属性两部分组成。自定义属性是年龄、所在地、Tag等。在神策分析中，它的来源主要有三类，一类是使用者自己采集并且通过接口告之系统的，例如用户的注册信息；一类是基于使用者的第一方数据挖掘得到的用户画像数据；还有一类则是通过第三方供应商得到的用户在第三方行为所体现出来的属性和特质。在神策分析中，User 数据，是每一行对应一个用户，并且可以任意修改的。

模型扩展：从 Event-User 到 Event-Item-User

所有的数据模型本质上都是对现实世界的抽象，而在抽象之后必然会损失一些对现实世界的还原能力。

所以 Event-User 模型虽然在电商、金融、在线教育、互联网娱乐、企业服务等不同的行业上都发挥了很好的价值，但是随着客户需求的不断深入，尤其是在和具体行业业务的深入融合中，我们也逐渐发现了这个模型的一些缺点。

例如在 Event-User 模型中，出于性能和可解释性等各方面的考虑，Event 是被设计为不可变的。从逻辑上看似乎没有问题，因为 Event 代表的是历史上已经发生过的事件，一般来说不应该需要进行更新。

但是，在实际的应用过程中，并不一定是这么理想的状态。

为了满足上述需求，我们在新版的神策分析中对 Event-User 模型进行了扩展，引入了 Item 的概念。这里的所谓 Item，在严格意义上是指一个和用户行为相关联的实体，可能是一个商品、一个视频剧集、一部小说等等。

如果不严格约束的话，理论上它也可以存储其它任意的扩展维度信息。

扩展

其中值得注意的是，event表的所有变量都是横向扩展到的，即埋点中每增加一个对象，event表就要扩张一列，这样做是为了方便后续自助式分析场景下event和user、item的关联，减少复杂度。

对于user表，由于涉及到用户画像的人群圈选与保存，我们注意到神策是将画像新建的每一个人群存储为一张表，并不存储在user表中，大大减少了user表关联的复杂度。