Question

我已经开始学习云架构，并且发现它们都使用列式数据库，因为它们存储列而不是行以减少重复，因此它们声称效率更高。

从数据集市的角度来看（假设对于组织而言，一个部门只希望监视互联网销售增长，而其他部门则希望专注于网点性能），我如何设计可以处理数据负载和提供易于访问的数据。我知道如何轻松地在数据集市上设计数据集市，而最终用户根本不必理会计算。

我在SSAS（OLAP）方面具有丰富的经验，其中已经计算了大型数据仓库上的所有计算，并且普通业务用户可以直接连接到多维数据集并使用自助服务BI工具（如拖动和另一方面，列式数据库似乎遵循ELT方法，并将所有计算都保留在查询（视图）或报告工具上。

根据我在SQL Server中的经验，我假设我的查询（例如下面的示例）

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

将扫描完整的表，这可能会增加成本。想象一下，对于大型企业来说，上述查询一天要执行1000次以上。

因此，是否适合使用维建模在列式数据库之上创建OLAP，还是先加载数据然后在报表工具上进行过滤/转换，这是更好的选择？ BI工具已经考虑到这一点，并且限制了数据消耗的使用（例如：Power BI桌面社区版每个数据集允许10 GB），并迫使用户自己进行计算。

如果我们将数据分为多个表，则所有报告工具无论如何都需要表之间的关系以进行过滤。
如果我们保持单一表格格式，则报告工具必须先读取所有数据，然后再进行任何计算。

Answer 1

业务分析查询通常确实涉及计算指标的汇总，例如您举例说明的总销售额和平均折扣。

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

（因为）典型的关系数据库在这些情况下的性能较低，并且OLAP证明是有效的优化，因此OLAP方法获得了发展。

列式数据库方法（在面向分析的数据库中）还旨在优化这些用例，主要是通过以仅需从存储中读取选定列（例如标签和聚合度量）的方式来结构化和存储数据。这需要较少的I / O，这也是为什么列格式为这些用例提供出色性能的主要原因之一（其他格式是复杂的分区，并行处理，压缩和元数据，例如Apache Parquet）。

因此，关于您的问题，我想说的是，如果您在即席查询场景中遇到性能低下的情况，并且只想立即解决（例如缓存，适当的分区），就应该只担心在列式数据库中预先计算聚合。和压缩）。但这还取决于您使用哪种数据库/ saas /文件格式。

关于维度建模，这是一个不同的问题。如果您使用Parquet之类的列式文件格式，则实际上（根据用户和用例的不同）可能希望使用Hive之类的格式在文件上创建一个（元）尺寸模型，例如您可以向用户公开数据库表和SQL接口，而不是一堆文件。

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

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

Answer 2

您的销售增长SQL没有道理。随时间监视销售增长，但是您没有在SQL中定义时间部分。例如，如果企业要监视每周或每月销售额，则可以创建每周事实表或每月事实表，然后计算每周或每月销售额并将其保存到该事实表中。通过这种方式，您可以将每周或每月数据追加到事实表中，这样报表就可以从事实表中读取它。在事实表中确实有一个代表星期/月初和星期/月末的日期，以便报表可以使用它。使用这种设计方法，报表性能会很快，因为它不会进行任何计算，但会显示汇总数据。

柱状数据库的维度建模

2 个答案: