最佳化 Looker 效能

這些最佳做法彙整了經驗豐富的 Looker 跨職能團隊提供的建議。這些深入分析結果來自於多年來與 Looker 客戶合作的經驗，從導入到長期成功，我們都參與其中。這些做法適用於大多數使用者和情況，但實作時請依據自身判斷。

盡可能提高查詢效能

您可以參考下列前端和後端提示，確保查詢作業的建構和執行方式符合資料庫的最佳做法：

  • 盡可能使用 many_to_one 聯結來建構探索。將最詳細的檢視表分別彙整至提供整體資料的檢視表 (many_to_one)，通常能讓查詢發揮最佳效能。
  • 請盡可能充分利用快取功能，配合 ETL 政策，減少資料庫查詢流量。根據預設，Looker 會快取查詢一小時。您可以使用 persist_with 參數，在探索中套用資料群組，藉此控管快取政策，並讓 Looker 資料重新整理作業與 ETL 程序保持同步。如此一來，Looker 就能與後端資料管道更密切整合，在充分利用快取的同時，避免分析到過時資料。具名快取政策可套用至整個模型，以及/或是個別探索和永久衍生資料表 (PDT)。
  • 使用 Looker 的匯總感知功能建立匯總或彙整資料表，讓 Looker 盡可能用於查詢，特別是大型資料庫的常見查詢。您也可以利用匯總認知度，大幅提升整個資訊主頁的成效。詳情請參閱匯總認知度教學課程。
  • 使用 PDT 加快查詢速度。將含有許多複雜或效能不佳的聯結，或是含有子查詢或子選取的維度的探索，轉換為 PDT，以便在執行階段前預先聯結並準備好檢視畫面。
  • 如果資料庫方言支援永久累加型衍生資料表，請設定永久累加型衍生資料表，縮短 Looker 重建衍生資料表的時間。
  • 請避免將檢視區塊彙整到探索中，並使用 Looker 中定義的串連主鍵。請改為在檢視區塊中，加入組成串連主鍵的基本欄位。或者，您也可以將檢視區塊重新建立為 PDT，並在資料表的 SQL 定義中預先定義串連的主鍵，而不是在檢視區塊的 LookML 中定義。
  • 使用在 SQL Runner 中說明工具進行基準化。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 和探索的資料，並使用 required filters、conditionally_filter 和 sql_always_where 參數限制 LookML 層級的資料。
  • 請盡量不要使用「所有結果」選項下載或傳送查詢，因為部分查詢可能非常龐大，處理時會對 Looker 伺服器造成負擔。
  • 瞭解連線效能對整個 Looker 執行個體的影響。Looker 會使用共用資源處理所有資料庫連線的查詢。這些資源包括 Kubernetes Pod、查詢佇列和執行緒集區。由於基礎架構共用，單一緩慢或過度負載的資料庫連線可能會對所有其他連線的查詢效能造成負面影響。如果發現效能大幅降低，請調查所有資料庫連線的健康狀態，而不只是與速度緩慢的資訊主頁或探索相關的連線。

如需更多有助於找出成效問題來源的資訊，請參閱「成效總覽」最佳做法頁面。