-1

Redshift我们一个我们称之为entity_ hierarchy_id_下一个)。 因此: 此外,该表是根据 分布和排序的。entity_timestampthierarchy_idABC
hierarchy_id == A.a_id || '-' || B.b_id || '-' || C.c_id
DISTKEY(hierarchy_id)COMPOUND SORTKEY(hierarchy_id, entity_timestampt)

在这张表上,我们需要生成多个报告,其中一些被固定到层次结构的深度级别,而另一些将被更高的部分过滤,并按较低的部分对结果进行分组。但是,层次结构的第一层A维度)定义了我们的安全模型,用户永远无法访问A他们所属的维度以外的其他维度(这是我们的租户信息)
当我们用纯SQL对报告进行原型设计时,当前的设计被证明是有用的,因为我们可以为深度查询做这样的事情:

WHERE
  entity.hierarchy_id = 'fixed_a_id-fixed_b_id-fixed_c_id' AND
  entity.entity_timestampt BETWEEN 'start_date' AND 'end_data'

或者像这样通过层次结构的其他点进行过滤:

WHERE
  entity.hierarchy_id LIKE 'fixed_a_id-%' AND
  entity.entity_timestampt BETWEEN 'start_date' AND 'end_data'

即使我们仅针对层次结构的部分路径进行过滤,它仍然可以利用DISTKEY&设置。SORTKEY

现在我们想使用QuickSight使用嵌入功能创建和共享这些报告。但是我们还没有找到一种方法来过滤我们想要的分析数据。
我们尝试通过标签对匿名用户使用RLS,但我们发现了两个问题:

  1. 如何在 API 中以安全的方式(即用户无法更改它)A.a_id注入生成嵌入 URL 的查询部分,同时允许他们配置层次结构的其他部分。最后在过滤器中组合这些独立的部分;无需在每次用户更改其他部分时生成新的 URL。(但是,我们可能会忍受这种限制,但是)
  2. 如何进行部分过滤;即看起来像的那些LIKE 'fixed_a_id-fixed_b_id-%'因为看起来RLS总是一个相等的条件。

有什么方法可以让QuickSight在我们当前的表格设计中按照我们想要的方式工作?还是我们需要改变设计?
对于后者,我们考虑将三个维度 id 保留为单独的列,这样我们可以为列添加 RLSA.a_id并为其他列使用参数,问题在于按层次结构的较低部分分组的报告,目前尚不清楚我们如何定义DISTKEYandSORTKEY以便正确优化查询。

4

1 回答 1

1

COMPOUND SORTKEY(hierarchy_id, entity_timestampt)

您知道您只对hierarchy_id?的前八个字节进行排序。区域图区分块的能力完全基于字符串的前八个字节?

我怀疑拥有三个单独的列会做得更好。

即使我们只过滤层次结构的部分路径,它仍然可以利用 DISTKEY 和 SORTKEY 设置。

我可能是错的 - 我需要检查 - 但我认为如果您在排序键上使用任何类型的运算符(例如函数,或LIKE,甚至加法或减法),则区域映射不起作用并且您读取所有块。

同样在您的情况下,它可能是 - 我还没有尝试使用它 - 如果您启用了 AQUA,因为您正在使用LIKE,您的整个查询正在由 AQUA 处理。我完全不知道这对性能的影响,无论是积极的还是消极的。

在使用区域地图时,您是否一直在使用系统表来验证您对查询的预期?

问题在于按层次结构的较低部分分组的报告,不清楚我们如何定义 DISTKEY 和 SORTKEY 以便正确优化查询。

您现在正面临排序列存储的基本性质;您选择的排序定义了您可以发出的查询,因此也定义了您不能发出的查询。

您可以以某种方式更改您的数据设计,使您想要的成为可能,或者您可以复制有问题的表,其中每个副本都有不同的排序顺序。

第一个是艺术,第二个有明显的成本。

顺便说一句,虽然我从未使用过 Quicksight,但我对所有 SQL 生成器的经验是它们完全没有排序,因此它们发出的 SQL 不能用于大数据(因为排序是大数据可以使用的方法)及时处理)。

如果你没有大数据,你会没事的,但问题是你为什么要使用 Redshift?

如果您确实有大数据,我所知道的唯一解决方案是为每个仪表板创建一个聚合表,大约 10 万行,并使用给定的仪表板并且只使用那个表。仪表板通常应该简单地读取整个表,这很好,然后您可以避免它通常会产生的噩梦 SQL。

于 2021-08-22T08:38:30.247 回答