常見的篩選器建議問題疑難排解

篩選建議是 Looker 中功能強大的工具。瞭解這些資料的來源和運作方式非常重要，這樣一來，當篩選建議無法正常運作時，您就能有效排除問題。本頁說明篩選器建議的運作方式、為何可能出現錯誤，以及為何可能無法填入。

篩選器建議的運作方式

篩選器建議可讓使用者在篩選器中輸入值時節省時間，並確保使用者選擇資料中存在的選項。使用者選取篩選器方塊時，系統會在欄位下方顯示建議清單。在本範例中，選取「訂單」探索中「狀態」欄位的篩選器方塊後，系統會顯示下拉式清單，其中包含「已取消」、「已完成」和「待處理」等選項。

這些建議清單的來源為何？

Looker 會對資料庫執行 SELECT distinct <field> 查詢，擷取該欄位的所有可能選項。查詢類似於下列 SQL：

SELECT DISTINCT <field_name>
FROM <table>
WHERE (<field_name> LIKE '%' OR <field_name> LIKE '% %')
GROUP BY 1
ORDER BY 1
LIMIT 1000

當使用者在篩選器方塊中輸入字元時，Looker 會在 WHERE 子句中替換適當的條件，以篩選結果。接著，Looker 會在篩選器建議中顯示前 1000 個結果。

我可以變更填入的建議內容嗎？

開發人員可以使用各種 LookML 參數來變更及自訂顯示的建議內容。詳情請參閱「變更篩選建議」說明文件頁面。

系統是否會快取建議？

根據預設，Looker 會快取查詢結果一小時。您可以使用 suggest_persist_for LookML 參數，自訂篩選建議的快取長度。suggest_persist_for 參數的預設值為「6 小時」。建議內容有專屬的快取，無法從「探索」頁面手動清除。如要清除快取資料以取得建議，請參考以下做法：

  • 如果探索使用含有 sql_trigger 的datagroup進行快取，您可以在 Looker 管理面板的「資料群組」頁面中，手動重設整個資料群組的快取，但這麼做會為使用該資料群組保留的所有查詢重新整理快取。
  • 您可以在欄位層級使用 suggest_persist_for 參數，並將其設為「0 秒」，以便清除該欄位的篩選建議快取。
    快取是全域功能，所有使用者皆可使用。當使用者重新整理快取以取得建議時，會影響其他使用者看到的結果。

為什麼篩選器建議不正確？

瞭解篩選器建議的填入方式後，您就能判斷篩選器建議可能出錯的原因。最常見的原因是，在篩選建議快取的時間點和發現錯誤結果的時間點之間，資料可能已變更或更新。

舉例來說，假設使用者 A 每天早上都會執行探索。使用者 A 從建議下拉式清單中選取一些篩選器值。資料庫的 ETL 程序大約在半小時後完成。接著，使用者 B 查看使用者 A 先前執行的相同探索。使用者 B 想知道為何篩選器建議內容不正確。差異的原因是快取的建議查詢未隨著資料庫新完成的 ETL 程序更新，因此顯示不預期的結果。

在這種情況下，您可以使用本頁稍早「建議是否已快取」一節所述的方法，重新整理建議快取。

為什麼沒有顯示篩選器建議？

系統無法顯示篩選器建議的原因有很多，請按照下列疑難排解步驟找出可能的原因：

  1. 檢查篩選器類型。
  2. 檢查是否有 access_filter 或 sql_always_where 限制建議。
  3. 檢查是否有 suggest_dimension parameter。
  4. 檢查使用者在篩選器中選取或輸入文字時，系統是否會嘗試載入建議。
  5. 檢查 Chrome 網路主控台。
  6. 找出 Looker 嘗試執行的建議查詢證據。

檢查篩選器類型

如果這是 LookML 資訊主頁篩選器，請確認篩選器類型為「欄位」。其他篩選器類型不會填入建議。

  • 請確認篩選器欄位在 LookML 定義中為 type: string。number 類型欄位上的篩選器不會填入建議。
  • 是否為「符合 (進階)」篩選器？比對 (進階) 篩選器需要使用 Looker 運算式，因此系統不會顯示建議。

檢查是否有 access_filter 或 sql_always_where 限制建議

一般來說，使用 sql_always_where 或 access_filter 時，系統會限制該 Explore 的篩選建議。這樣一來，使用者就不會看到無法存取的篩選器建議。如果您確定特定維度或篩選器欄位中沒有可能洩漏敏感資訊的值，可以使用 bypass_suggest_restrictions 重新啟用篩選器建議。

檢查是否有 suggest_dimension parameter

使用 suggest_dimension 參數時，除非在探索中參照建議的維度，並將該維度的檢視畫面定義為探索的基本檢視畫面，否則系統不會填入篩選器建議。

如果探索工具中建議維度的檢視畫面不是基本檢視畫面，請新增 suggest_explore 參數，參照該檢視畫面為基本檢視畫面的探索工具。

檢查在篩選器中選取或輸入文字時，系統是否會嘗試載入建議

請確認在篩選框中選取或輸入文字時，Looker 是否會嘗試載入建議。Looker 應在篩選器方塊的右側顯示旋轉的載入圓圈。

如果不是，則表示 Looker 並未嘗試填入建議。請確認第一個步驟中所述的條件已滿足，且在 LookML 中，field、view 或「探索」層級 (使用 sql_always_where 或 access_filter) 未關閉建議。請注意，Hadoop 方言會根據預設在所有檢視檔案上新增 suggestions: no。

如果系統嘗試載入建議，請按照這篇文章的操作說明檢查 Chrome 網路主控台。

查看 Chrome 網路主控台

Chrome 網路主控台可能會標示查詢本身的錯誤，或顯示是否有從快取傳回的結果。

  1. 使用快速鍵 Ctrl + Shift + J (Windows) 或 Command + Option + J (Mac) 開啟瀏覽器的「Network」分頁，或是從瀏覽器頂端的 Chrome 選項列依序選取「View」 >「Develop」 >「Developer tools」。
  2. 在 Look、探索或資訊主頁的篩選器方塊中選取項目。
  3. 開發人員工具面板應會顯示篩選器建議的請求，您可以選取該請求以取得更多資訊。
  4. 標頭會顯示 Looker 提出的內部 API 要求，以便擷取建議值。在這個範例中，假設 Looker 提出以下 API 要求，其中 <yourinstance> 代表執行個體的網址： 

    <yourinstance>/api/internal/models/the_look/views/order_items/fields/users.state/suggestions?term=
  5. 在 API 要求中，確認 /models/ 後方列出的模型是否存在。在本例中，模型名為 the_look。
  6. 雖然網址顯示 /views/，但這指的是欄位所屬的探索。檢查 /views/ 後方列出的 Explore 是否存在。在本例中，探索功能稱為 order_items。
  7. 請確認 /fields/ 後方列出的欄位是否存在。在本例中，欄位為 users.state。

這個 API 要求的回應會顯示確切的錯誤訊息。舉例來說，建議內容的狀態碼為 404 Not Found：

選取這項要求的回應，即可瞭解詳情。

在這種情況下，您會發現系統無法根據要求的回應找到欄位，因此無法提供建議：

{"class":"FieldNotFound","text":"Field not found."}

如果沒有錯誤，但沒有預期的建議，請檢查建議查詢是否從快取 (Network Console 中的 cache: true) 提取，這可能表示快取需要破解，請在提供建議的維度上使用 suggest_persist_for 參數。

找出 Looker 嘗試執行的建議查詢證據

您可以查看 Looker 管理面板中的「查詢」頁面，確認產生篩選器的查詢 (「查詢」頁面上的「來源」欄位會顯示「篩選建議」) 是否會產生錯誤。選取查詢的「Details」 按鈕，然後選取「Open in SQL Runner」選項。確認 SQL 語法正確無誤。如果您發現異常情形，例如缺少欄位名稱或錯誤的特殊字元，請確認您並未使用 Liquid 參數或範本篩選器。

  • 如果查詢需要範本篩選器輸入內容才能執行，系統就不會填入篩選器建議。
  • 如果查詢使用含有 default_value 的參數，系統會將該值插入篩選器建議查詢中。在這種情況下，篩選器建議查詢不會根據使用者輸入內容動態更新。視預設值而定，這可能會導致系統沒有提供篩選器建議，或提供錯誤的篩選器建議。建議您改為在資訊主頁中使用連結篩選器。