用于数据仓库的OBT (一个大表)与星型模式
当我来自一家规模小得多的公司时，我正努力准备在一家FAANG公司接受一些面试。面试过程的一部分包括数据建模和ETL设计。Kimball的“数据仓库工具包”描述了一个维度模型，它代表了一家公司，比如塔吉特( Target )或沃尔玛( Walmart )，零售额及其相关尺寸。然而，Kimball似乎认为，虽然维度(日期、存储、客户、产品等)是高度非规范化的，但事实表与FKs的相关维度是标准化的。
我听说过像我这样的公司使用OBT或"One Big“方法，通过消除对JOIN的需求，使分析师的生活更加轻松，并提高查询性能。此外，如今存储成本如此之低，而且大多数现代DWs (Redshift、BiqQuery等)都采用了基于柱状结构的体系结构，我认为我们可以安全地抛开对额外冗余的担忧(在两个表中出现两次相同的数据)，但是，在为大型应用程序进行架构设计时，冗余成为一个问题吗？为每个用例设计数据仓库的正确方法是什么？
回答 2
Database Administration用户
发布于 2022-11-09 16:33:23
我不知道什么是最佳实践，但在我看来，似乎没有一张大桌子能让分析师的工作变得更容易。
在我以前的分析师工作中，我们与dwh开发人员密切合作，并使用了kimball模型。在我们的报告工具/data应用工具中，表格的连接是自动的。80%的时间，我们可以使用现有的表，要求新的功能非常容易，模型是灵活和透明的。
在我目前的工作中，维度模型没有暴露给分析师。80%的时间，你实际上需要的一个大表是不存在的。因此，分析人员使用随机文件夹或存储过程中的一些随机脚本从源表中创建自己的数据集，并将数据集存储在与我们的dwh相同的服务器上，并且没有用于测试、文档、数据沿袭或治理的例程。当然，服务器没有被缩放，基于查询的报告工具变得非常慢，我们有数千个版本的真相。简直是噩梦。
Database Administration用户
发布于 2023-04-06 09:38:35
恒星模式以一张大桌子的形式开始生活，这并非闻所未闻。“一个大表”的优点是您可以更快地将数据提供给分析人员，而不必在设计和实现维度模型时出现开发滞后。稍后，随着平台的发展，您可能会迭代到一个合适的星型模式。
正如您已经注意到的，您可以从体系结构和实现的角度来评估星型架构，例如规范化、存储成本、柱状dbs等等。然而，Kimball的想法比实现更广泛，包括需求收集、逻辑和物理设计、治理和最终用户体验等方面。维度建模首先是一种方法。
如果操作得当，星型模式对于分析师来说是非常直观的。当维度模型反映组织的过程、语言和心智模型时，分析人员将减少数据争论的时间，并且他们的代码将更干净和更好地理解。在我看来，Kimball方法的更广泛的好处超过了任何性能的缺点。
Gitlab是使用较新的ELT/Cloud方法(想想dbt)构建的Kimball风格数据仓库的一个主要例子。请注意，它们是从现有的事实表和维度表(称为Mart表)创建OBT的：
MART表：`mart`_ =联接维度和事实表以及最小过滤器和聚合。由于mart表具有最小的筛选器和聚合，因此可以用于各种报告目的。
https://about.gitlab.com/handbook/business-technology/data-team/platform/edw/#naming-standards
https://dba.stackexchange.com/questions/310308
复制相似问题
腾讯云开发者
