Zer*_*ity 4 olap reporting data-modeling data-warehouse dimensional-modeling
我已经开始学习云架构，发现它们都使用列式数据库，该数据库声称效率更高，因为它们存储列而不是行以减少重复。
从数据集市的角度来看（假设对于一个组织来说，一个部门只想监控互联网销售增长，而其他一些部门想要关注销售业绩），我如何设计一个可以处理数据负载并提供轻松数据访问的架构。我知道如何在其之上轻松设计数据集市，并且最终用户根本不必费心计算。
我有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不会“扫描整个表”，它只会扫描您选择的列；这是柱状设计优化的一部分。