列式数据库的维度建模
Dimensional modeling on columnar databases
我已经开始学习云架构，发现他们都在使用列式数据库，这些数据库声称更高效，因为它们存储列而不是行以减少重复。
从数据集市的角度来看（比方说，对于一个组织来说，一个部门只想监控互联网销售增长，而其他一些部门想要关注销售业绩），我如何设计一个架构，它可以处理数据加载并提供简单的数据访问。 我知道如何在其之上轻松设计数据集市，最终用户根本不必为计算而烦恼。
我有过 SSAS (OLAP) 的经验，其中已经计算了大型数据仓库上的所有计算，普通业务用户可以直接连接到多维数据集并使用自助服务 BI 工具分析数据（简单到拖放）另一方面，列式数据库似乎遵循 ELT 方法并将所有计算留给查询（视图）或报告工具。
由于我在 SQL 服务器方面有经验，我假设我的查询（例如下面）
SELECT
region,
state,
City,
Country,
SUM(Sales_Amount),
AVG(Discount_Sale),
SUM(xyz)
....
FROM Columnar_DataTable
将扫描完成 table 这会增加成本。想象一下，对于一家大型企业，如果上述查询在一天内执行超过 1000 次。
那么，在具有维度建模的列式数据库之上创建 OLAP 是否合适，还是先加载数据然后 filter/transform 在报告工具上加载数据更好？ 考虑到大多数自助服务 BI 工具已经考虑到这一点并限制数据消耗的使用（例如：Power BI 桌面社区版允许每个数据集 10 GB）并强制用户进行 his/her 自己的计算。
如果我们将数据分成多个 table，那么所有报告工具无论如何都需要 table 之间的关系进行过滤。
如果我们保持单一 table 格式，那么报告工具必须在进行任何计算之前读取所有数据。
您的销售增长 SQL 没有意义。随着时间的推移监控销售增长，但您没有在 SQL 中定义时间部分。例如，如果企业想要监控每周或每月的销售额，那么您可以创建每周事实 table 或每月事实 table 并计算每周或每月销售额并保存到该事实 table .通过这种方式，您可以将每周或每月的数据附加到事实 table 中，这样报告就可以从事实 table 中读取它。在事实 table 中确实有代表 week/month 开始和 week/month 结束的日期，以便报告可以使用它。使用这种设计方法，报表性能会很快，因为它不进行任何计算，而是显示汇总数据。
业务分析查询通常涉及计算指标的聚合，例如总销售额和您举例说明的平均折扣。
OLAP 数据结构对这些用例很有用，因为聚合可以预先计算和存储，因此在查询时需要更少的计算和 I/O 并加快这些用例中使用的查询模式。
OLAP 方法获得了发展势头（也）因为典型的关系数据库在这些场景中性能较低，而 OLAP 被证明是一种有效的优化。
列式数据库方法（在面向分析的数据库中）也旨在优化这些用例，主要是通过以仅 selected 列（如标签和聚合度量）的方式构建和存储数据, 必须从存储中读取。这需要更少 I/O 并且是列格式为这些用例提供出色性能的主要原因之一（其他是复杂的分区、并行处理、压缩和元数据，如 Apache Parquet）。
所以，关于你的问题，我想说的是，如果你在临时查询场景中遇到性能低下，并且无法以更直接的方式解决它（如缓存，适当的分区和压缩）。但这也取决于您使用的 database/saas/file 格式。
至于维度建模，那是一个不同的问题。如果您使用像 Parquet 这样的列式文件格式，实际上可能需要（取决于用户和用例）使用 Hive 之类的东西在文件上创建（元）维度模型，例如您可以向用户公开数据库表和 SQL 界面，而不是一堆文件。
关于 PowerBI，与大多数报告工具一样，如果用户确实要使用超过 10GB 的数据集，您可以在直接查询模式下使用它。
PS：在列式数据库中，SQL的特定部分不会"scan the complete table"，它只会扫描您select的列；这是柱状设计优化的一部分。
我已经开始学习云架构，发现他们都在使用列式数据库，这些数据库声称更高效，因为它们存储列而不是行以减少重复。
从数据集市的角度来看（比方说，对于一个组织来说，一个部门只想监控互联网销售增长，而其他一些部门想要关注销售业绩），我如何设计一个架构，它可以处理数据加载并提供简单的数据访问。 我知道如何在其之上轻松设计数据集市，最终用户根本不必为计算而烦恼。
我有过 SSAS (OLAP) 的经验，其中已经计算了大型数据仓库上的所有计算，普通业务用户可以直接连接到多维数据集并使用自助服务 BI 工具分析数据（简单到拖放）另一方面，列式数据库似乎遵循 ELT 方法并将所有计算留给查询（视图）或报告工具。
由于我在 SQL 服务器方面有经验，我假设我的查询（例如下面）
SELECT
region,
state,
City,
Country,
SUM(Sales_Amount),
AVG(Discount_Sale),
SUM(xyz)
....
FROM Columnar_DataTable
将扫描完成 table 这会增加成本。想象一下，对于一家大型企业，如果上述查询在一天内执行超过 1000 次。
那么，在具有维度建模的列式数据库之上创建 OLAP 是否合适，还是先加载数据然后 filter/transform 在报告工具上加载数据更好？ 考虑到大多数自助服务 BI 工具已经考虑到这一点并限制数据消耗的使用（例如：Power BI 桌面社区版允许每个数据集 10 GB）并强制用户进行 his/her 自己的计算。
如果我们将数据分成多个 table，那么所有报告工具无论如何都需要 table 之间的关系进行过滤。
如果我们保持单一 table 格式，那么报告工具必须在进行任何计算之前读取所有数据。
您的销售增长 SQL 没有意义。随着时间的推移监控销售增长，但您没有在 SQL 中定义时间部分。例如，如果企业想要监控每周或每月的销售额，那么您可以创建每周事实 table 或每月事实 table 并计算每周或每月销售额并保存到该事实 table .通过这种方式，您可以将每周或每月的数据附加到事实 table 中，这样报告就可以从事实 table 中读取它。在事实 table 中确实有代表 week/month 开始和 week/month 结束的日期，以便报告可以使用它。使用这种设计方法，报表性能会很快，因为它不进行任何计算，而是显示汇总数据。
业务分析查询通常涉及计算指标的聚合，例如总销售额和您举例说明的平均折扣。
OLAP 数据结构对这些用例很有用，因为聚合可以预先计算和存储，因此在查询时需要更少的计算和 I/O 并加快这些用例中使用的查询模式。
OLAP 方法获得了发展势头（也）因为典型的关系数据库在这些场景中性能较低，而 OLAP 被证明是一种有效的优化。
列式数据库方法（在面向分析的数据库中）也旨在优化这些用例，主要是通过以仅 selected 列（如标签和聚合度量）的方式构建和存储数据, 必须从存储中读取。这需要更少 I/O 并且是列格式为这些用例提供出色性能的主要原因之一（其他是复杂的分区、并行处理、压缩和元数据，如 Apache Parquet）。
所以，关于你的问题，我想说的是，如果你在临时查询场景中遇到性能低下，并且无法以更直接的方式解决它（如缓存，适当的分区和压缩）。但这也取决于您使用的 database/saas/file 格式。
至于维度建模，那是一个不同的问题。如果您使用像 Parquet 这样的列式文件格式，实际上可能需要（取决于用户和用例）使用 Hive 之类的东西在文件上创建（元）维度模型，例如您可以向用户公开数据库表和 SQL 界面，而不是一堆文件。
关于 PowerBI，与大多数报告工具一样，如果用户确实要使用超过 10GB 的数据集，您可以在直接查询模式下使用它。
PS：在列式数据库中，SQL的特定部分不会"scan the complete table"，它只会扫描您select的列；这是柱状设计优化的一部分。