如何提升Looker项目性能？PDT等优化方案咨询

一、无自定义SQL情况下的PDTs实现 #

• 基于Explore自动生成PDT：无需编写自定义SQL，在模型文件中针对目标视图定义derived_table块，通过explore_source关联目标Explore并指定所需字段，Looker会自动生成对应的SQL并创建PDT。示例：

view: optimized_pdt {
  derived_table: {
    explore_source: target_explore {
      columns: [user_id, order_date, total_sales]
    }
    datagroup_trigger: daily_refresh_datagroup
  }
}

• 复用现有Look生成PDT：直接利用已保存Look的查询逻辑生成PDT，在derived_table中使用looker_source参数指定Look的ID即可，无需手动编写SQL。示例：

view: look_based_pdt {
  derived_table: {
    looker_source: 456 # 替换为目标Look的ID
    datagroup_trigger: daily_refresh_datagroup
  }
}

• 自动维护PDT生命周期：只要配置datagroup_trigger关联数据组，Looker会按照数据组的刷新规则自动更新PDT，无需额外维护。

二、8字段慢加载Look的深度优化 #

• 分析底层SQL执行计划：通过Looker的「查看SQL」功能导出查询语句，在数据库端执行并查看执行计划，重点排查：
  • 是否存在隐式类型转换（如字符串与数字字段关联导致索引失效）
  • 关联字段、过滤字段是否缺少索引
  • 是否存在意外的笛卡尔积（即使删除了无关关联，可能仍有隐藏的多对多关联逻辑）
• 精简关联逻辑：检查剩余关联是否为必要的左连接，业务允许的情况下改为内连接；对于大表关联，可在数据库层面创建预关联的物化视图或视图，减少Looker实时关联的计算量
• 排查动态逻辑影响：如果Look使用了动态参数、用户属性驱动的维度，这类逻辑会增加查询编译时间，尝试替换为固定维度
• 优化过滤条件：即使仅展示8个字段，过滤条件可能触发大表全表扫描，尝试将过滤条件改为基于分区字段或索引字段
• 切换至PDT数据源：将Look的数据源替换为已创建的PDT，避免实时关联原始表的计算开销

三、其他通用性能优化措施 #

• 数据库端优化：
  • 为关联字段、高频过滤字段添加索引
  • 对大表按时间或业务维度进行分区
  • 开启数据库自带的查询缓存（如PostgreSQL的pg_prewarm、BigQuery的查询缓存）
• Looker模型优化：
  • 在视图层面使用sql_always_where添加全局过滤，减少扫描的数据范围
  • 避免使用嵌套过深的CASE WHEN维度，尽量在数据库端预计算这类字段
  • 对使用sql_distinct的度量，替换为数据库中预计算的去重字段
• 查询级别优化：
  • 优先使用聚合后的度量，避免查询全量明细数据
  • 添加TOP N过滤限制结果集行数，减少数据传输量

内容的提问来源于stack exchange，提问作者Пётр