我已经使用 AWS Firehose -> S3/Glue -> Athena 堆栈设置了一个时间序列/事件数据库。它被用于跟踪我们许多产品中的各种用户操作 - 会话启动、执行的操作等。我的问题是关于如何最好地在这个系统中存储不同类型的 ID。
现有架构是一个大的"事实数据表"，其中包含一堆不同的列。其中两个最重要的列是event_type_id和object_id。以 StackOverflow 为例，两个事件可能是：
- question_asked - 在这种情况下，我将问题 ID 存储在object_id列中。
- tag_created - 在这种情况下，我将标签 ID 存储在object_id列中。
我的问题是 - 在同一列中存储多个不同类型的 ID 是不是一种不好的做法吗？目前它对我们来说工作正常，但它确实需要执行查询的人员/系统根据他们正在查询的事件知道object_id列引用的对象类型。
如果做法不好，还有什么其他方法可能更好？如果与该行中的事件无关，则为空的多列？或者这是维度表更适合的地方？
这不一定是不好的做法，这取决于你如何使用它。
听起来您已经意识到这种方法的潜在缺陷(即数据用户必须了解上下文 - 在本例中为"事件类型" - 才能正确使用值(，因此当您使用 Athena 时，您可以通过为不同的事件类型在源表上创建视图、在事件类型上插入 WHERE 子句过滤器并可能将object_id重命名为更特定于上下文的内容(例如question_id(。
这使用户能够更轻松地处理数据并准确了解他们正在使用的值。
在大数据环境中，如果可以避免，我不建议创建维度表，因为表之间的 JOIN 开始变得昂贵。可以为不同的 id 设置多个列，但随后会给用户带来新的问题，例如必须考虑 Id 列中的 NULL 值，这也可能会使添加新的事件类型和 ID 变得更加困难，因为您必须更改架构以适应它们。