社交媒体的星型模式设计答案

【问题标题】：Star Schema Design for Social Media社交媒体的星型模式设计
【发布时间】：2018-08-28 20:34:09
【问题描述】：

我是维度建模的新手，并且阅读了很多资料（星型模式、维度/事实表、SCD、Ralph Kimball 的 - The Data Warehouse Toolkit 书等）。所以我对维度建模结构有很好的概念理解，但由于缺乏经验，我发现很难将其应用于用例，需要一些指导。

以 Twitter 为例，我想设计一个维度模型来计算 -

DAU（每日活跃用户）= 在给定日期通过网站或移动应用程序登录和访问 twitter 的用户数
MAU（月活跃用户数）= 过去 30 天内通过网站或移动应用登录并访问 twitter 的用户数，包括衡量日期
用户参与度 = 推文的总次数（点击次数 + 收藏次数 + 回复次数 + 转发次数）

一段时间（如一个月）内的这些指标是该期间每一天的这些指标的总和。

我想编写 SQL 来按地区（例如：美国和世界其他地区）计算每个季度的这些指标，并计算这些指标的同比增长（或下降）。
例如：

这是我想到的一些细节-

用户登录活动的无事实（事务）事实表，每个用户每次登录的粒度为 1 行：user_login_fact_schema（user_dim_key、date_dim_key、user_location_dim_key、access_method_dim_key）

用户活动的无事实（事务）事实表，每个用户每个活动的粒度为 1 行：user_activity_fact_schema（user_dim_key、date_dim_key、user_location_dim_key、access_method_dim_key、post_key、activity_type_key）

这听起来正确吗？我的模型应该是什么样子？我可以在此处添加哪些其他维度/事实？

想知道我是否应该将这 2 个表折叠为 1 个并将登录的活动类型设置为“登录”，但是可能有大量登录没有任何活动，因此这会扭曲数据。我还有什么遗漏吗？

【问题讨论】：

我想知道你是否可以设计你的事实表来存储用户计数而不是按最低粒度（每天为你）存储用户 ID，然后根据需要进行聚合。你能分享一下你的最终设计是什么样子（粘贴箱）吗？我很想看看。
Saurabh，你最后的启动模式是什么？您是否还包括 MAU 和 DAU/MAU 比率？
另外，当你按季度汇总 DAU 时，会是什么？你季度的平均值还是最后一个值？

标签： data-modeling data-warehouse dimensional-modeling star-schema datamart

【解决方案1】：

您的模型似乎正确，它回答了您发布的图表上的问题。

将这两个事实表聚合到一个事实表中并通过“UserAction”维度连接是有意义的，主要是因为登录可以被解释为只是另一个用户操作。

但是，将单独的事实表集中在一个指标（或流程）上可能更可取，因为它使您能够将度量/指标引入表中，即当您的事实表不再是无事实的时。它还可以让您避免与另一个维度 (UserAction) 的连接，但如今这变得不那么重要了，因为存储和数据库处理能力变得越来越便宜。

【讨论】：

【解决方案2】：

您应该将数据保存在不同的表中，以确保不会混合不同的谷物。

user_login_fact_schema 可以是基于 user_activity_fact_schema 过滤活动 type=login 并包括一些排除重复项的逻辑的实体化视图（即，如果您正在谈论每日活跃用户）

【讨论】：

@user:1098559 感谢您的回复。我不认为这会破坏谷物。我的意思是在 user_activity_fact_schema 表中将“登录”作为新的活动类型，这样他们就可以在一个表中保持一致而不会违反规定。
如果您每天有多次登录，我会考虑“登录事件”+“不同的每日登录”的混合颗粒。它可以工作，但您最终可能会使用昂贵的计数或窗口函数来计算#active users。