社交媒体的明星架构设计

Question

我是维度建模的新手，并阅读了大量材料（星型模式，维度/事实表，SCD，Ralph Kimball＆＃39; s - 数据仓库工具包等）。因此，我对维度建模结构有一个很好的概念性理解，但由于缺乏经验并需要一些指导，因此难以应用于用例。

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

1. DAU（每日活跃用户数）=在指定日期通过网站或移动应用登录和访问Twitter的用户数
2. MAU（每月活跃用户数）=在过去30天内通过网站或移动应用登录和访问Twitter的用户数量，包括测量日期
3. 用户互动=推文上的总计（点击+收藏+回复+转发）

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

我想编写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）

这听起来不错吗？我的模型应该怎么样？我可以在这里添加哪些其他维度/事实？

不知道我是否应该将这两个表折叠为1并将登录的activity_type设置为＆＃39; login＆＃39;，但是可能存在大量没有任何活动的登录，因此这会使数据产生偏差。我错过了什么吗？

Answer 1

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

将这两个事实表汇总到一个与＆＃34; UserAction＆＃34;加入的事实表中是有意义的。维度，主要是因为登录可以解释为另一个用户操作。

但是，将单独的事实表集中在一个指标（或流程）上可能更为可取，因为它使您能够将度量/指标引入表中，即当您的事实表停止无效时。它还使您与另一个维度（UserAction）保持联接，但现在这种情况变得不那么重要了，因为存储和数据库处理能力正在变得越来越便宜。

Answer 2

您应该将数据保存在不同的桌子上，以确保不要混合不同的颗粒。

user_login_fact_schema 可以是基于 user_activity_fact_schema 过滤活动类型=登录的物质化视图，并包含一些排除重复项的逻辑（即每个用户每天登录一次，如果你正在谈论每日活跃用户）