Question

我们有一个系统，我们根据某些条件在Redshift中进行一些聚合。我们使用复杂的连接聚合这些数据，通常需要大约10-15分钟才能完成。然后，我们在Tableau上显示此聚合数据以生成报告。最近，我们在添加新维度（通常需要与新表连接）或获取某些更具体的过滤器数据方面进行了许多更改。为了接受这些请求，我们必须每次为每个子进程更改查询。我稍微通过了OLAP。我只是想知道它在我们的用例中是否会更好，或者是否有更好的方法来设计我们的系统来接受这样的adhoc请求，这些请求不需要开发人员每次都改变事物。

提前感谢您的建议。

Answer 1

它会工作，而应该工作。效率是关键。您需要严格监控以确保系统（Redshift + Tableau）保持正常运行。

首选实时连接提取（在Tableau中）

每当有人更改过滤器或刷新报告时，实时连接都会查询系统。由于您说数据集很大且查询很复杂，因此更喜欢创建提取。当有人访问您的仪表板时，这将确保数据可用。不要忘记安排提取刷新，否则数据将永远失效。

编写有效的查询

OLAP系统应该查询大型数据集。确保编写有效的查询。最好先获取一个小数据集并加入它们，而不是将所有内容都放在内存中，然后加入/使用where子句来过滤结果。

像(select foo from table1 where ... )a left join (select bar from table2 where)这样的查询可能是您只获取小的相关数据然后加入的关键。

不要查询无限数据。

由于这是分析性而非事务性数据，因此Tableau将刷新的数据具有上限。历史数据具有重要性，但不是从产品开始时开始。分析过去3个月，6个月或9个月的数据可能是关键，而不是查询通用数据集。

创建聚合并让Tableau查询该表，而不是原始表

假设您正在分析用户特征。而不是查询每个用户每天捕获100条记录的原始表，设计一个每天每个用户只有一个（或两个）条目的表，并引入一列 - count，它会告诉您次数该事件已被触发。通过这样做，您将查询足够小的数据集，但在逻辑上等同于您之前所做的。

正如Mr Prashant Momaya所述，

"While dealing with extracts,your storage requires (size)^2 of space if your dashboard refers to a data of size - **size**"

对于您实施的任何设计都要非常谨慎，不要忘记考虑最重要的因素 - 可扩展性

Answer 2

这是一个典型问题，我们通过在Python中编写SQL生成器来解决它。如果度量的定义相同（如SET !VAR1 EVAL("var min = 75; var max = 100; var randomNumber = Math.floor(Math.random() * (max - min + 1)) + min; '%' + randomNumber / 100.0;")），但您有不同的维度和过滤器，则可以将其声明为JSON并编写将生成SQL的生成器。网页浏览的示例：

count(*)

可以相对容易地翻译成2个脚本 - 这个：

{
    metric: "unique pageviews"
   ,definition: "count(distinct cookie_id)"
   ,source: "public.pageviews"
   ,tscol: "timestamp"
   ,dimensions: [
        ['day']
       ,['day','country']
}

和此：

 drop table metrics_daily.pageviews;
 create table metrics_daily.pageviews as
 select 
  date_trunc('day',"timestamp") as date
 ,count(distinct cookie_id) as "unique_pageviews"
 from public.pageviews
 group by 1;

从这样的配置生成这样的sql所需的生成器的复杂程度非常低，但随着你需要添加新的连接等而呈指数增长。将你的维度保持在编码形式并且只使用一个宽表作为聚合源，或为您可能需要的每个联接生成视图，并将它们用作源。

用于后端redshift连接的OLAP方法

2 个答案: