查看事件日志存储结构与入库失败数据：事件日志发送第4篇

Hive Analytics · 2026年10月29日 · 阅读约 5 分钟

发送到 Hive Analytics 的事件中，符合采集标准的事件存储在各公司 BigQuery 数据集的 t_raw_event_log 中，不符合标准的事件则连同原始 JSON 和隔离原因存储在 t_raw_event_log_rescue 中。如果在正常表中找不到事件，可通过 rescue 表的 errorReason、errorStackTrace、rawData 查看隔离原因。例如，eventTime 不符合 RFC 3339 格式时，事件会因 201（DATETIME_INVALID）错误被隔离。此时修正时间格式并重新发送事件，再确认事件已存入正常表即可。

查看已发送事件的存储结果

《将游戏数据作为事件日志发送：事件日志发送第3篇》介绍了如何将实际游戏数据作为事件日志发送。本篇将介绍已发送事件的存储结构，以及未能正常存储的事件的隔离原因和查看方法。

接入日志发送功能后，需要确认事件是否已正常存储。符合必填属性、值格式等采集标准的事件会存入正常表，不符合标准的事件则会存入单独的隔离表。

如果在正常表中找不到已发送的事件，不应简单判断为采集延迟，而应同时确认事件是否被隔离以及隔离原因。

Hive Analytics 的事件存储结构

事件数据

被 Hive Analytics 正常采集的事件会存储在各公司 BigQuery 数据集的 t_raw_event_log 表中。该表以 dateTime 为基准按天分区，同时存储事件的基本信息和属性。

字段	数据类型	说明	生成方式
`userId`	STRING	按账号识别用户的值	作为必填属性发送
`identifierProvider`	STRING	签发用户标识符的系统	作为必填属性发送
`deviceId`	STRING	按设备识别用户的值	作为必填属性发送
`appId`	STRING	识别事件所在应用的值	作为必填属性发送
`appIdGroup`	STRING	将多个应用归为同一款游戏（项目）的值	根据 `appId` 自动生成
`dateTime`	TIMESTAMP	将 `eventTime` 转换为 UTC 后的事件发生时间	解析 `eventTime` 后自动生成
`eventName`	STRING	区分事件的名称	作为必填属性发送
`checksum`	STRING	根据事件数据生成的哈希值	根据事件数据自动生成
`bigqueryRegistTimestamp`	TIMESTAMP	事件存入 BigQuery 的时间	存储时自动生成
`attributes`	JSON	存储自定义属性和自动采集属性的区域	将发送的属性按结构自动生成

contents_success 事件被正常采集后，事件的基本信息和属性值会如下图所示存储在同一行中。同一事件被重复发送时，可能会存入重复数据。直接查询原始数据时，建议以 checksum 为基准去重。

在 BigQuery 中查询 t_raw_event_log，contents_success 事件的基本信息与 attributes 存储在同一行的结果界面 — `t_raw_event_log` 中，事件的基本信息与属性值存储在同一行。

事件属性的存储结构

随事件发送或自动采集的属性以 JSON 格式存储在 attributes 字段中。attributes 内部按属性的采集方式分为 hiveAttributes 和 eventAttributes。

分类	说明	主要值
`hiveAttributes`	Hive Analytics 在数据处理过程中自动添加的属性	`_dataSource`
`eventAttributes`	随事件发送或由客户端自动采集的属性	原始 `eventTime`、自定义属性、SDK 自动采集属性

通过 hiveAttributes 中的 _dataSource，可以区分事件是经由 Hive SDK、游戏服务器等哪条路径发送的；在 eventAttributes 中，可以查看游戏直接发送的自定义属性及其实际值。通过 Hive SDK 自动采集的客户端属性也包含在该区域中。详情请参阅开发者网站的数据存储结构。

隔离数据

不符合必填属性、值格式等采集标准的事件会入库失败，并被隔离到各公司 BigQuery 数据集的 t_raw_event_log_rescue 中。隔离表会同时存储发送的原始 JSON 和隔离原因。如果在正常表中找不到事件，请在 rescue 表中确认该事件是否被隔离。

主要隔离原因	说明
缺少必填属性	缺少日志发送所需的属性，或属性值为空
使用保留字	使用 `attributes`、`eventAttributes`、`hiveAttributes` 作为自定义属性名，或使用以 `_` 开头的属性名
不支持的数据类型	以 JSON 对象或数组作为自定义属性值发送
`eventTime` 格式错误	无法将 `eventTime` 解析为包含时区的 RFC 3339 格式
`eventTime` 超出允许范围	事件发生时间超出可采集的范围（过去 10 年至未来 5 年）
JSON 格式错误	无法将发送的日志解析为有效的 JSON

属性名中的保留字不区分英文大小写。例如 Attributes 或 HIVEATTRIBUTES 同样会被视为保留字，因此不要将其用作自定义属性名。

隔离表的存储结构

t_raw_event_log_rescue 会存储可从原始日志中读取的事件基本信息、原始数据以及隔离原因。

字段	数据类型	说明
`userId`	STRING	可从原始日志中读取的用户标识符
`identifierProvider`	STRING	签发用户标识符的系统
`deviceId`	STRING	可从原始日志中读取的设备标识符
`appIdGroup`	STRING	事件所属游戏（项目）的标识值
`dateTime`	STRING	发送的原始 `eventTime` 值
`eventName`	STRING	区分事件的名称
`bigqueryRegistTimestamp`	TIMESTAMP	事件存入 BigQuery 的时间
`checksum`	STRING	根据事件数据生成的哈希值
`rawData`	STRING	所发送事件的原始 JSON
`errorReason`	STRING	表示事件隔离原因的代码
`errorStackTrace`	STRING	缺失字段等隔离原因的详细信息

正常表的 dateTime 存储的是由 eventTime 转换而来的 TIMESTAMP 值；隔离表的 dateTime 则以字符串形式存储原始 eventTime，便于排查发送值的问题。

查看 contents_success 的隔离原因

下面是发送 contents_success 事件后，在 BigQuery 中查看被隔离数据的过程。

申请 BigQuery 查询权限
查看隔离原因需要 BigQuery 原始数据查询权限。要使用 BigQuery，请先获得 Hive Analytics 管理员权限，再在 Hive Analytics 的账号菜单中申请 BigQuery 查询权限。权限生效后，进入 Google Cloud 的 BigQuery 控制台，在“探索器”中找到已授予查询权限的 Hive Analytics 项目和各公司数据集，然后查询该数据集的 t_raw_event_log_rescue。BigQuery 使用方法详见开发者网站的BigQuery 设置。

在 BigQuery 中查询 t_raw_event_log_rescue 的 errorReason、errorStackTrace 与 rawData 的界面 — 查询隔离数据，查看错误代码与原始数据。

在 BigQuery 中查询 t_raw_event_log_rescue 后，errorReason 显示为 201。查看 errorStackTrace 和 rawData 可以发现，eventTime 以 2026-10-26T17:51:57+09:00+09:00 发送，时区重复。该值不符合 RFC 3339 格式，因此无法解析为用于存储的 dateTime。

隔离代码与处理方法

errorReason	处理方法
100	发送的消息不是有效的 JSON。请先校验 JSON 格式再发送。
200	以包含时区的 RFC 3339 格式发送 `eventTime` 字段，并确保 `eventTime` 的时间值在允许范围（过去 10 年～未来 5 年）内。
201	以包含时区的 RFC 3339 格式发送 `eventTime` 字段。
300	`attributes`、`eventAttributes`、`hiveAttributes` 是由数据管道自动生成的保留字段，请勿直接放入事件中。以 `_` 开头的字段名预留给管道内部使用，请勿使用。
400	确认已包含全部必填字段（`userId`、`identifierProvider`、`deviceId`、`appId`、`eventName`、`eventTime`）后再发送。
401	事件属性值中包含 JSON 对象（`{}`）或数组（`[]`）。所有属性均需以单层扁平结构（字符串／数字）发送。JSON 字符串（`"{...}"`、`"[...]"`）同样会被拒绝。

确认 eventTime 的正确格式和允许范围后，将其修改为只包含一次时区的值（如 2026-10-26T17:51:57+09:00）并重新发送。随后以相同条件查询数据，确认修正后的事件已正常存入 t_raw_event_log。

开始使用 Hive Analytics

正常采集的事件存储在 t_raw_event_log 中，不符合采集标准的事件则连同原始数据和错误信息被隔离到 t_raw_event_log_rescue 中。同时查看这两张表，就能区分事件的存储结果，找出日志未被正常采集的原因并修改发送代码。

Hive Analytics 是一款面向游戏的专业分析解决方案，不仅能分析已采集的游戏事件，还能查看未被正常处理的事件日志的隔离原因和原始数据，帮助定位问题根源。现在就前往 Hive Analytics，在 BigQuery 数据集中查看事件的发送状态吧。