时间戳

首页 > 解决方案 > 数据仓库/湖中的单个与多个 ID 列

data-warehouse - 数据仓库/湖中的单个与多个 ID 列

问题描述

我已经使用 AWS Firehose -> S3/Glue -> Athena 堆栈设置了一个时间序列/事件数据库。它被用于跟踪各种用户操作——我们的许多产品中的会话启动、执行的操作等。我的问题是关于如何在这个系统中最好地存储不同类型的 ID。

现有的模式是一个包含一堆不同列的大“事实表”。两个最重要的列是event_type_id和object_id。以 StackOverflow 为例，两个事件可能是：

  1. question_asked - 在这种情况下，我会将问题 ID 存储在object_id列中。
  2. tag_created - 在这种情况下，我会将标签 ID 存储在object_id列中。

我的问题是 - 在同一列中存储多种不同类型的 ID 是不好的做法吗？目前它对我们来说工作正常，但它确实需要执行查询的人员/系统根据他们正在查询的事件知道object_id列所指的对象类型。

如果做法不好，还有什么其他方法可能更好？如果与该行中的事件无关，它们为 NULL 的多列？或者这是尺寸表更适合的地方？

标签： data-warehouseparquetamazon-athenaaws-gluestar-schema

解决方案

这不一定是不好的做法，具体取决于您如何使用它。

听起来您已经意识到这种方法的潜在缺陷（即数据的用户必须了解上下文 - 在本例中为“事件类型” - 才能正确使用这些值），所以当您使用Athena 您可以通过在源表上为不同事件类型创建视图、在事件类型上插入 WHERE 子句过滤器以及可能将object_id重命名为更具体的上下文来缓解这种情况，例如question_id。

这使用户可以更轻松地处理数据并准确了解他们正在使用的值。

在大数据环境中，如果可以避免创建维度表，我不建议创建维度表，因为表之间的 JOIN 开始变得昂贵。为不同的 id 设置多个列是可能的，但是您会为用户创建新问题，例如必须在 Id 列中考虑 NULL 值，这也可能使添加新事件类型和 id 变得更加困难，因为您必须更改架构来容纳他们。

推荐阅读