我已经阅读了 DW/BI kimball design v3，一切对我来说似乎都是合乎逻辑的，但有一点我正在努力解决。我在一家流媒体公司 (OTT) 工作。我们对业务流程有不同的星型模式，例如： fact_user_subscription（这是一个临时事实表，定义用户订阅、激活日期、到期日期和订阅相关的度量/维度）和第二个类似 vod_watch_fact 的表，其中我们还具有与订阅（例如用户）合并的维度，两个表中的粒度都是每个事务一行，或每个浏览会话一行。
我关心的是如何在BI层面结合这些数据，我们正在使用Looker。 我 100% 确定企业用户会希望根据订阅数据（例如购买地点或购买方式）过滤某些查找事件。而我们公司的几乎所有流程都与用户订阅相关。我知道联接不是一个好主意，但 Looker 不支持多通道，而且我不想在 ELT 数据表单级别创建大型事实表以简化更新和维护。也许我在这里遗漏了一些东西。
我尝试使用关系在查看器的探索级别创建连接规则。但不确定处理方法是否正确。
Looker 不直接支持多通道 SQL，您可以使用 LookML 的关系和联接、反规范化技术以及可能的 PDT 或聚合表实现跨星型模式的有效数据集成。通过仔细设计 Looker 探索并利用数据库优化，您可以为业务用户提供集成见解，同时保持 BI 环境的性能和可扩展性。