代码之家 › 专栏 › 技术社区 › Zerotoinfinity HLGEM

柱状数据库的维建模

dimensional-modeling olap data-warehouse reporting database-design

Zerotoinfinity HLGEM · 技术社区 · 6 年前

我已经开始学习云架构,发现它们都在使用柱状数据库,因为它们存储列而不是行来减少重复,所以效率更高。

从数据集市的角度来看(比方说,对于一个组织来说,一个部门只想监控互联网销售增长,而另一个部门则希望关注销售业绩)。 如何设计一个能够处理数据加载并提供简单数据访问的体系结构。 我知道如何在上面轻松地设计数据集市,最终用户根本不必费心计算。

我在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 desktop community edition允许每个数据集使用10gb),并强制用户自己进行计算。

如果我们将数据分为多个表,那么无论如何,所有报表工具都需要表之间的关系来进行筛选。
如果我们保持单表格式,那么报表工具必须在进行任何计算之前读取所有数据。

0 回复 | 直到 6 年前

jmng 6 年前

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

olap数据结构对于这些用例非常有用,因为聚合可以被预计算和存储,因此在查询时需要较少的计算和i/o,并加快了在这些用例中使用的查询模式。

olap方法获得了发展势头(也是因为典型的关系数据库在这些场景中的性能较差),olap被证明是一种有效的优化方法。

Columnar数据库方法(在面向分析的数据库中)也旨在优化这些用例,主要是通过结构化和存储数据的方式,只有选定的列(如标签和聚合度量)才能从存储中读取。这需要更少的I/O,这也是Columnar格式为这些用例提供良好性能的主要原因之一(其他的是复杂的分区、并行处理、压缩和元数据,如 Apache Parquet )

所以,关于您的问题,我想说,如果您在特殊查询场景中遇到性能低下的情况,并且无法以更直接的方式(如缓存、适当的分区和压缩)来解决,那么您应该只担心在列数据库中预计算聚合。但这也取决于您使用的数据库/saas/文件格式。

至于尺寸模型,那是另一个问题。如果使用像parquet这样的列文件格式,那么实际上可能需要(取决于用户和用例)使用 Hive 在文件上创建一个(元)维模型,以便您可以向用户公开数据库表和SQL接口,而不是一堆文件。

关于powerbi,与大多数报告工具一样,如果用户确实要使用10gb以上的数据集,则可以在直接查询模式下使用它。

PS:在一个列数据库中,特定的SQL语句不会“扫描整个表”,它只扫描您选择的列;这是列设计优化的一部分。

-1

Sam Kaz 6 年前

你的销售增长SQL没有意义。随着时间的推移,销售增长受到监控,但您没有在sql中定义时间部分。例如,如果业务部门希望监视每周或每月的销售,则可以创建每周事实表或每月事实表,然后计算每周或每月的销售并保存到该事实表中。通过这种方式,您可以将每周或每月的数据附加到事实表中,这样报表就可以从事实表中读取数据。在事实表中有一个表示周/月开始和周/月结束的日期,以便报表可以使用它。使用这种设计方法,报表性能将很快,因为它不进行任何计算,而是显示汇总数据。