柱状数据库的尺寸建模

Question

我已经开始学习云体系结构，并发现它们都在使用列数据库，这些数据库声称在存储列而不是一行时效率更高，以减少重复。

从数据集市的角度来看(比方说，对于一个部门来说，一个部门只想监控互联网销售增长，而其他部门只想关注插座的性能)，如何设计出一种能够处理数据加载并提供方便数据访问的体系结构。--我知道如何在其之上轻松地设计数据集市，最终用户根本不必费心计算。

我有过SSAS (OLAP)方面的经验，在这种情况下，大型数据仓库上的所有计算都已经计算出来，正常的业务用户可以直接连接到多维数据集，并使用自助服务BI工具(像拖放一样简单)来分析数据。另一方面，柱状数据库似乎遵循ELT方法，将所有的计算都放在查询(视图)或报告工具上。

由于我在Server方面有经验，我假设我的查询(例如，下面)

SELECT 
  region,
  state,
  City,
  Country,
  SUM(Sales_Amount),
  AVG(Discount_Sale),
  SUM(xyz)
  ....
FROM Columnar_DataTable

要扫描完整的表格，这样会增加成本。想象一下，如果一个大型企业在一天内执行超过1000次以上的查询。

因此，在柱状数据库之上使用维度建模创建OLAP是合适的，还是最好先加载数据，然后在报表工具上过滤/转换？考虑到大多数自助服务BI工具已经考虑到了这一点，并限制了数据消耗的使用(例如: Power桌面社区版本允许每个数据集10 GB )，并强制用户自己计算。

• 如果我们将数据隔离到多个表中，那么所有的报表工具，无论如何，都需要表之间的关系进行过滤。
• 如果我们保持单一的表格格式，那么报告工具必须在进行任何计算之前读取所有数据。

Answer 1

业务分析查询通常涉及计算度量的聚合，例如销售总额和您所演示的平均折扣。

OLAP数据结构对于这些用例非常有用，因为聚合可以预先计算和存储，因此在查询时需要更少的计算和I/O，并加快了这些用例中使用的查询模式。

OLAP方法获得了发展势头(也是因为一个典型的关系数据库在这些场景中性能较差)，并且OLAP被证明是一种有效的优化。

柱状数据库方法(在面向分析的数据库中)也是为了优化这些用例，主要是通过构造和存储数据的方式，只有选定的列，如标签和聚合度量，才能从存储中读取。这需要较少的I/O，也是列式格式为这些用例提供良好性能的主要原因之一(其他的是复杂的分区、并行处理、压缩和元数据，如Apache Parquet)。

因此，关于您的问题，我想说的是，如果您在临时查询场景中的性能很低，并且不能以更直接的方式解决它(比如缓存、适当的分区和压缩)，那么您只应该担心列型数据库中的预计算聚合。但这也取决于您所使用的数据库/saas/文件格式。

至于维度建模，这是另一个问题。如果您使用像Parquet这样的列文件格式，那么实际上可能希望(取决于用户和用例)使用类似蜂巢的方法在文件上创建(元)维度模型，这样您就可以向用户公开数据库表和SQL接口，而不是一堆文件。

关于PowerBI，与大多数报告工具一样，如果用户使用超过10 in的数据集，您可以在直接查询模式下使用它。

PS:在特定SQL部分不会“扫描完整表”的柱状数据库中，它只扫描您选择的列；这是优化列设计的一部分。

Answer 2

您的销售增长SQL没有意义。随着时间的推移，销售增长会被监控，但是您没有在SQL中定义时间部分。例如，如果企业希望监视每周或每月的销售额，则创建每周事实表或每月事实表，计算每周或每月的销售额并保存到该事实表中。通过这种方式，您可以将每周或每月的数据添加到事实表中，因此报告只需从事实表中读取。在事实表中确实有一个日期，表示周/月的开始和周/月的结束，因此报表可以使用它。使用这种设计方法，报表性能将是快速的，因为它不进行任何计算，而是显示汇总的数据。