最佳化 Looker 效能

這些最佳做法是根據 Looker 跨職能資深團隊分享的建議彙整而成。這些洞察資訊來自多年來與 Looker 客戶合作的經驗，從導入到長期成功。這些做法適用於大多數使用者和情況，但實施時仍應自行判斷。

盡可能提高查詢效能

您可以參考下列前端和後端提示，確保查詢能以最佳方式建構及執行：

  • 盡可能使用 many_to_one 彙整建立探索。將最詳細的檢視表分別彙整至提供整體資料的檢視表 (many_to_one)，通常能讓 Looker 發揮最佳查詢效能。
  • 充分利用快取功能，盡可能配合 ETL 政策，減少資料庫查詢流量。根據預設，Looker 會快取查詢一小時。您可以使用 persist_with 參數，在探索中套用資料群組，藉此控管快取政策，並讓 Looker 資料重新整理作業與 ETL 程序保持同步。這樣 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 執行個體的回應速度變慢。
  • 如果是合併結果查詢，請盡可能使用資料庫內合併查詢。資料庫內合併查詢會在資料庫中處理，而非在 Looker 記憶體中處理。
  • 如果檢視表檔案數量龐大，請限制模型中包含的檢視表數量。如果將所有檢視表納入單一模型，可能會降低效能。如果專案中有多個檢視表，建議只在每個模型中加入必要的檢視表檔案。建議您為檢視表檔案名稱採用策略性命名慣例，以便在模型中加入檢視表群組。includes 參數說明文件中有範例。
  • 避免在資訊主頁圖塊和 Look 圖表中預設傳回大量資料點。如果查詢傳回數千個資料點，會耗用更多記憶體。請務必盡可能限制資料，方法是在資訊主頁、Look 和探索套用前端 篩選器，並在 LookML 層級使用 required filters、conditionally_filter 和 sql_always_where 參數。
  • 請盡量避免使用「所有結果」選項下載或傳送查詢，因為部分查詢可能非常龐大，處理時會導致 Looker 伺服器不堪負荷。
  • 瞭解連線效能對整個 Looker 執行個體的影響。Looker 會使用共用資源，處理所有資料庫連線的查詢。這些資源包括 Kubernetes Pod、查詢佇列和執行緒集區。由於基礎架構是共用的，因此只要有一個資料庫連線速度緩慢或超載，就會對所有其他連線的查詢效能造成負面影響。如果發現效能普遍下降，請檢查所有資料庫連線的健康狀態，而不只是與速度緩慢的資訊主頁或探索直接相關的連線。
  • 分散排定的傳送作業，避免同時執行工作。如果有多個 Look 或資訊主頁排定在同一分鐘執行 (尤其是整點)，突然湧入的大量查詢要求可能會耗盡執行個體資源、導致佇列深度激增，並耗盡資料庫連線集區。這項並行瓶頸可能會導致排定的傳送作業和互動式探索查詢在查詢初始化階段停滯。請採用下列策略，避免並行瓶頸：
    • 將排定的工作分散在 15 分鐘或 30 分鐘的間隔內 (或非整點的分鐘，例如 :15、:30 或 :45)，而不是將所有傳送作業都排在整點。
    • 請盡可能使用資料群組，根據 ETL 完成時間 (而非時間表) 觸發傳送作業，避免對未重新整理的資料執行不必要的查詢。
    • 批次處理或限制外部指令碼和自動化 API 呼叫，這些指令碼和呼叫會執行查詢或觸發傳送作業。
    • 如果查詢量突然暴增，導致執行個體沒有回應，或查詢無限期執行，您可以重新啟動執行個體，清除處理中的工作 (如為 Looker (Google Cloud Core) 執行個體，請參閱「重新啟動 Looker (Google Cloud Core) 執行個體」)。

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