我已经开始学习云架构，发现他们都在使用列式数据库，这些数据库声称更高效，因为它们存储列而不是行以减少重复。
从数据集市的角度来看(比方说，对于一个组织来说，一个部门只想监控互联网销售增长，而其他一些部门想要关注销售业绩)，我如何设计一个架构来处理数据负载和提供简单的数据访问。我知道如何在其之上轻松设计数据集市，最终用户根本不必为计算而烦恼。
我有过 SSAS (OLAP) 的经验，其中大型数据仓库上的所有计算都已经计算完毕，普通业务用户可以直接连接到多维数据集并使用自助服务 BI 工具(就像拖放一样简单)分析数据drop) 另一方面，列式数据库似乎遵循 ELT 方法，并将所有计算都留在查询( View )或报告工具上。
由于我有 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)并强制用户进行他/她自己的计算。
如果我们将数据分离到多个表中，那么所有报告工具无论如何都需要表之间的关系以进行过滤。
如果我们保持单表格式，那么报告工具必须在进行任何计算之前读取所有数据。
最佳答案
业务分析查询通常涉及计算指标的聚合，例如您举例说明的总销售额和平均折扣。
OLAP 数据结构对这些用例很有用，因为可以预先计算和存储聚合，从而在查询时需要更少的计算和 I/O，并加快这些用例中使用的查询模式。
OLAP 方法(也)获得了动力，因为典型的关系数据库在这些场景中性能较低，而 OLAP 被证明是一种有效的优化。
列式数据库方法(在面向分析的数据库中)也旨在优化这些用例，主要是通过以一种只需要从存储中读取选定列(如聚合的标签和度量)的方式来构建和存储数据.这需要更少的 I/O，并且是列式格式为这些用例提供出色性能的主要原因之一(其他是复杂的分区、并行处理、压缩和元数据，如 Apache Parquet 中所示)。
所以，关于你的问题，我想说的是，如果你在临时查询场景中遇到低性能，并且不能以更直接的方式解决它(比如缓存，适当的分区)，你应该只担心列式数据库中的预计算聚合和压缩)。但这也取决于您使用的数据库/saas/文件格式。
至于维度建模，那是另一回事。如果您使用像 Parquet 这样的列式文件格式，实际上可能需要(取决于用户和用例)使用像 Hive 这样的格式。在文件上创建(元)维度模型，例如您可以向用户公开数据库表和 SQL 接口(interface)，而不是一堆文件。
关于 PowerBI，与大多数报告工具一样，如果用户确实要处理超过 10GB 的数据集，您可以在直接查询模式下使用它。
PS:在列式数据库中，特定的SQL不会“扫描完整表”，它只会扫描您选择的列；这是柱状设计优化的一部分。
关于reporting - 列式数据库的维度建模，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/54861462/