最佳化 Looker 效能

這些最佳做法反映了由多個職能團隊的資深 Looker 分享的建議。這些洞察資料是我們與 Looker 客戶合作多年，從導入到長期成功的經驗所得。這些做法適用於大多數使用者和情況，但在導入時，請務必根據自身情況做出最佳判斷。

盡可能提高查詢效能

您可以透過下列前端和後端提示，確保查詢能以最佳方式建構並執行資料庫：

  • 盡可能使用 many_to_one 彙整建立探索。從最精細層級到最高精細層級 (many_to_one) 的彙整檢視畫面通常可提供最佳查詢效能。
  • 盡可能充分運用快取功能，以便與 ETL 政策同步，進而減少資料庫查詢流量。根據預設，Looker 會快取查詢一小時。您可以使用 persist_with 參數，在探索中套用 datagroups，藉此控制快取政策，並透過 ETL 程序同步 Looker 資料更新。這可讓 Looker 更緊密地與後端資料管道整合，進而盡可能提高快取使用率，且不會有分析過時資料的風險。命名的快取政策可套用至整個模型和/或個別的探索和持久衍生資料表 (PDT)。
  • 請使用 Looker 的匯總認知功能，盡可能建立可供 Looker 用於查詢的匯總或摘要表格，特別是針對大型資料庫的常見查詢。您也可以利用匯總認知度，大幅提升整個資訊主頁的成效。如需更多資訊，請參閱匯總感知教學課程。
  • 使用 PDT 加快查詢速度。將含有許多複雜或效能不佳的彙整作業，或含有子查詢或子選取的維度，轉換為 PDT，讓檢視畫面在執行階段前先行彙整並準備就緒。
  • 如果資料庫方言支援漸進式 PDT，請設定漸進式 PDT，以縮短 Looker 重建 PDT 資料表所需的時間。
  • 請勿將檢視畫面與 Looker 中定義的連接主鍵彙整在一起。請改為彙整檢視畫面中組成連結主索引鍵的基礎欄位。或者，您也可以將檢視表重新建立為 PDT，並使用資料表 SQL 定義中預先定義的連結主鍵，而非檢視表的 LookML。
  • 利用 SQL Runner 中的 Explain 工具進行基準測試。EXPLAIN 會針對特定 SQL 查詢產生資料庫查詢執行計劃的概覽，讓您偵測可最佳化的查詢元件。如需進一步瞭解，請參閱「如何使用 EXPLAIN 最佳化 SQL」社群貼文。
  • 宣告索引。您可以直接在 Looker 中查看每個表格的索引，方法是從 SQL Runner 中按一下表格中的齒輪圖示，然後選取「Show Indexes」。

    最常見的索引欄通常是重要日期和外鍵。為這些資料欄新增索引，幾乎可提升所有查詢的效能。這也適用於 PDT。您可以適當套用 LookML 參數，例如 indexes、sort keys 和 distribution。
  • 如果資料庫的硬體或必要的佈建資源 (例如 AWS) 不足，無法處理大型資料集，請增加記憶體、核心和 I/O (輸入/輸出)，以提升查詢效能。

最佳化 Looker 伺服器效能

您也可以採取措施，確保 Looker 伺服器和應用程式能發揮最佳效能：

  • 限制個別資訊主頁中的元素數量。我們沒有明確的規則來定義這個數量，因為每個元素的設計會根據各種因素影響記憶體用量；不過，如果資訊主頁的資訊方塊超過 25 個，效能通常會出現問題。
  • 請有策略地使用資訊主頁自動重新整理功能。如果資訊主頁使用自動重新整理功能，請確認重新整理速度不會比幕後執行的 ETL 程序還快。
  • 請妥善運用樞紐，並避免在資訊主頁資訊方塊和 Look 中過度使用樞紐。含有樞紐維度的查詢會耗用更多記憶體。轉換的維度越多，載入內容 (探索、Look 或資訊主頁) 時所耗用的記憶體就越多。
  • 請謹慎使用合併結果、自訂欄位和資料表計算等功能。這些功能可做為概念驗證，協助您設計模型。 建議您在 LookML 中為所有常用的計算和函式設定硬式編碼，系統會產生 SQL 以便在資料庫中處理。 過多的運算可能會爭奪 Looker 執行個體的 Java 記憶體，導致 Looker 執行個體回應速度變慢。
  • 當有大量的檢視檔案時，請限制模型中包含的檢視次數。在單一模型中納入所有檢視畫面可能會降低效能。如果專案中有多個檢視畫面，建議您只在各個模型中加入所需的檢視畫面檔案。建議您為檢視畫面檔案名稱採用策略性的命名規則，方便在模型中加入一組檢視畫面。如需範例，請參閱 includes 參數說明文件。
  • 請避免在資訊主頁資訊方塊和 Look 中，預設傳回大量資料點。傳回數千個資料點的查詢會耗用更多記憶體。請將前端 篩選器套用至資訊主頁、Look 和 Explore，並在 LookML 層級使用 required filters、conditionally_filter 和 sql_always_where 參數，確保資料盡可能受到限制。
  • 請謹慎使用「All Results」選項下載或提交查詢，因為某些查詢可能非常龐大，在處理時會讓 Looker 伺服器不堪負荷。

如需進一步瞭解如何找出成效問題的來源，請參閱「成效總覽」最佳做法頁面。