1. 数据表
目前，神策分析的所有数据映射到事件和用户这两张数据表，在 SQL 里使用这两张数据表即可完成所有查询。同时支持将客户创建的所有 Session 映射成 Sessions_${Session_name} 命名的表。以下列举字段都为特殊字段，其他未列举且带 "$" 的属性都为神策预置属性，具体含义可参考文档预置事件与预置属性，不带 "$" 的属性都为自定义属性，具体含义需跟对应埋点人员确认。
1.1. 事件表 (events)
事件表包含了所有事件的详细信息（不包括虚拟事件），该表的每一行代表一个 track 的 Event。事件表的字段分为特殊字段和 Event 本身的 Property 两大类。其中特殊字段如下：
| 字段 | 说明 | 示例 |
|---|
| event | 事件的名称 | BuyGold |
| user_id | 神策分析为该用户分配的内部 ID，与 user 表的 id 字段相关联 | 1234 |
| distinct_id | 用户的原始 ID，track 时传入，可能是一个匿名 ID 或 登录 ID | wahaha |
| date | 事件发生的日期,属于特殊字段，上传数据时无需上传 date 字段 | 2015-09-21 |
| time | 事件发生的具体时间 | 2015-09-21 11:11:11 |
| $receive_time | 服务器接收到事件时的具体时间戳。该字段可以在自定义查询中显示，在前端的分析模块中，所有事件都无法使用该字段分析数据，因为 $receive_time 默认不会与任何事件绑定。 | 1570230586048 |
需要特别注意的是，事件表的 user_id 字段并不是 track 时传入的 distinct_id，而是由神策分析为该用户分配的内部 ID，具体的机制见2021-10-19_10-11-23_.标识用户 v1.17。
1.2. 用户表 (users)
用户表的每一行代表一个 User，类似于事件表，用户表的字段也分为特殊字段和 User 的其它 Profile 两大类，其中特殊字段的说明如下：
| 字段 | 说明 | 示例 |
|---|
| id | 神策分析为该用户分配的内部 ID，与 events 表的 user_id 相关联 | 1234567 |
| first_id | 该用户的匿名 ID，与 events 表登录前行为的 distinct_id 相关联。需要特别注意，如果某个用户 first_id 的值等于 second_id，说明该用户没有成功关联到匿名 ID，相当于未知 | 0c476090a0b2940a |
| second_id | 该用户的登录 ID，与 events 表登录后行为的 distinct_id 相关联 | wahaha |
| $update_time | 该用户最近一次更新用户表信息的时间戳 | 1570230586048 |
| $device_id_list | 开启多对一关联机制时，会记录与登录 ID 关联的匿名 ID 列表，以及关联时的时间戳 | 1570230586048:0c476090a0b2940a；1570230591000:65A71299-7139-4B4C-9B71-23A0AC9AAF7D |
1.3. Items 表
| 字段名称 | 说明 | 示例 |
| $item_type | item 表的类型 | apple |
| $item_id | 表示 item 的 id | 123 |
| $is_valid | 该 item 是否有效，不传入默认为 true | 1 |
| $receive_time | 该 item 到达时间 | 1575604527772 |
| $update_time | 该 item 的更新时间，不传入默认为写入时间 | 1575604527772 |
1.4. Session 表
每张 Session 表都对应一个 Session 的配置，命名规则为：Sessions_${Session_name}。
Session 表是对 events 表做了扩展，除了包含 events 表包含的字段，还包含 Session 属性和 Session 相关的特殊字段，Session 属性的命名规则是原始的属性名加上后缀 $Session，表示 Session 中初始事件的属性。其中特殊字段说明如下：
| 字段 | 说明 | 示例 |
|---|
| $Session_id | 标示一个 Session 的唯一 id | 2036149433405577601 |
| $Session_position | 标示一个 Session 中事件的索引，从 0 开始，依次递增。1.14 及之前版本 Session 中最后一个事件的索引是-1，如果 Session 中只有1个事件，则索引值是-2 。1.15 及之后版本，不再有特殊的 -1、-2 索引值。 | 0 |
| $Session_event_duration | Session 内事件时长，表示Session相邻两个事件发生的时间间隔，单位是秒，最后一个事件的事件时长是 null | 354 |
| $Session_duration | Session 内最后一个事件触发的时间减去 Session 内第一个事件触发的时间，单位是秒 | 234 |
| $Session_depth | Session 深度，表示 Session 内触发事件的次数 | 4 |
| $event_id$Session | Session 内第一次触发的事件的事件id | 97 |
因为 Session 表的计算量较大，所以必须加上时间注解进行使用，比如：
SELECT event, user_id, distinct_id, date FROM Sessions_default/*SESSION_TABLE_DATE_RANGE=[2018-01-01,2018-01-05]*/
SQL
注意：由于 Session 表查询比较耗时，为了提升查询效率，目前不支持使用 select * 查询 表，需要选择具体的字段名查询。
1.5. 用户分群 / 标签表
这些表为系统中分群/标签结果的存储表，表中存储的用户为此分群/标签筛选出来的用户。不同版本的表命名规则有所不同，见下表：
| 类型 | 表名规则 | 示例 |
|---|
| 分群 | user_group_${user_group_name} | user_group_abc |
| 标签 | user_tag_${user_tag_name} | user_tag_abc |
关于表中具体字段的说明如下:
| 字段 | 说明 | 示例 |
|---|
| user_id | 用户 id | -9220214159525537212 |
| distinct_id | 与事件表中的 distinct_id 相关联 | 3f840957485db9a9 |
| values | 用户分群/标签值 | 1 |
| base_time | 用户分群/标签计算的基准时间，1.14 及之后版本之后新增 | 1547015611000 |
其中 base_time 是以毫秒形式进行的存储，所以在查询的时候，用户可以通过 unix_timestamp_ms 函数将日期转化成毫秒数进行查询，例子如下：
SELECT * FROM user_group_fenqun9 WHERE base_time=unix_timestamp_ms('2019-01-17 00:00:00')
SQL
2. 数据类型
出于查询效率的考虑，自定义查询功能对不同的数据类型有不同处理，同时某些数据类型有一些使用上的限制，具体说明如下：
2.1. Number
数值类型，不区分浮点数与整数，输出的时候会根据是否有小数位自动转换输出格式。
2.2. String
字符串类型。
2.3. Date
注意：time 字段特殊，不需要经过转换即可直接使用。
日期类型，在自定义查询中表现为毫秒级的 Timestamp，例如：1442937600000。
如果有需要，可以使用 EPOCH_TO_TIMESTAMP 函数转换为 Timestamp 类型，例如：
SELECT EPOCH_TO_TIMESTAMP($signup_time / 1000) FROM users LIMIT 100;
SQL
用于条件过滤的例子如下：
SELECT COUNT(*) AS cnt FROM users WHERE EPOCH_TO_TIMESTAMP($signup_time / 1000) > '2017-01-01';
SQL
2.4. Datetime
日期时间类型，和 Date 类型一样，也使用毫秒级的 Timestamp表示，例如：1442592138000。 同样也可以使用 EPOCH_TO_TIMESTAMP 类型进行类型转换。
2.5. Bool
布尔类型，使用 0/1 表示 False/True。
2.6. List
列表类型，支持在 Where 条件里使用 CONTAINS 函数或者 LIKE 函数来进行过滤操作。例如：
SELECT FavoriteFruits from users where CONTAINS('橘子', FavoriteFruits);
SQL
