我已经开始学习云架构，发现他们都在使用柱状数据库，声称它们更有效率，因为它们存储列而不是一行来减少重复。
从数据集市的角度来看（假设某个组织部门只想监控互联网销售增长而其他部门希望关注出口业绩），我该如何设计一个能够处理数据负载并提供简便数据访问的架构。我知道如何在其上轻松设计数据集市，最终用户根本无需担心计算。
我有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）并强制用户进行他/她自己的计算。
业务分析查询通常涉及计算指标的聚合，例如总销售额和您举例说明的平均折扣。
OLAP数据结构对这些用例很有用，因为聚合可以预先计算和存储，因此在查询时需要较少的计算和I / O，并加快这些用例中使用的查询模式。
OLAP方法也获得了动力（因为）典型的关系数据库在这些场景中性能较差，而OLAP被证明是一种有效的优化。
柱状数据库方法（在面向分析的数据库中）也用于优化这些用例，主要是通过以必须从存储中读取所选列（如标签和聚合度量）的方式构建和存储数据。这需要较少的I / O，这也是列式格式为这些用例提供出色性能的主要原因之一（其他用户是复杂的分区，并行处理，压缩和元数据，如Apache Parquet）。
所以，关于你的问题，我要说你应该只担心如果你在即席查询场景中遇到低性能而在柱状数据库中预先计算聚合，并且无法以更直接的方式解决它（如缓存，正确的分区和压缩） 。但这也取决于您使用的数据库/ saas /文件格式。
至于维度建模，这是一个不同的问题。如果您使用像Parquet这样的柱状文件格式，实际上可能需要（取决于用户和用例）使用类似Hive的东西来创建文件上的（元）维模型，以便例如您可以向用户公开数据库表和SQL接口，而不是一堆文件。
关于PowerBI，与大多数报告工具一样，如果用户确实使用超过10GB的数据集，您可以在直接查询模式下使用它。
PS：在一个柱形数据库中，特定的SQL不会“扫描整个表”，它只会扫描你选择的列;这是柱状设计优化的一部分。
您的销售增长SQL没有意义。随着时间的推移监控销售增长，但您没有在SQL中定义时间部分。例如，如果企业想要监控每周或每月销售额，那么您可以创建每周Fact表或每月Fact表，并计算每周或每月销售额并保存到该Fact表中。通过这种方式，您可以将每周或每月数据附加到Fact表中，以便报表只从Fact表中读取它。在事实表中有一个代表星期/月开始和星期/月末的日期，因此报告可以使用它。使用此设计方法，报告性能会很快，因为它不会进行任何计算，但会显示汇总数据。