最佳做法：編寫可維護且可持續使用的 LookML

這些最佳做法反映了由多個跨職能團隊的資深 Looker 提供的建議。這些洞察資料是我們與 Looker 客戶合作多年，從導入到長期成功的經驗所得。這些做法適用於大多數使用者和情況，但如往常，請在實作本頁任何建議時，務必謹慎評估。

本頁面提供撰寫可維護且可持續使用的 LookML 的建議。以下各節將詳細說明這些建議：

使用替換運算子

所有 LookML 檔案都應使用替換運算子。LookML 模型應只包含單一參照點，指向實體資料模型中的任何物件。後續定義如需參照該物件，應指向已定義的 LookML 物件。

對於直接從基礎資料庫欄位擷取資料的所有基礎維度，請在參照基礎資料庫資料表時使用 ${TABLE}.field_name 語法。如果結構定義或資料表名稱有所變更，開發人員就能在一個位置 (sql_table_name 參數內) 更新結構定義或資料表名稱，並讓名稱散佈至其他程式碼。

如要參照已在 LookML 中定義的維度或指標，請使用 ${field_name} 語法。如果資料欄名稱有所變更，您只需要在基礎維度或指標的 sql 參數中更新該變更。系統會自動將該變更套用至參照該欄的所有其他欄位。舉例來說，如果資料庫中的資料欄名稱從 usersid 變更為 users_id，您就需要變更 Looker 中的參照。使用 ${field_name} 表示您只需更新一行。

如果有多個維度和指標使用 ${TABLE}.field_name 參照現有的 LookML 欄位，就需要進行許多變更。舉例來說，請參考下列 LookML 程式碼範例中的 this_week_count 和 this_month_count 指標：

dimension: usersid {
  type: number
  sql: ${TABLE}.usersid ;; # Change here
}

measure: this_week_count {
  type: count_distinct
  sql: ${TABLE}.usersid ;; # Change here
  filters: [created_date: "7 days"]
}

measure: this_month_count {
  type: count_distinct
  sql: ${TABLE}.usersid ;; # Change here
  filters: [created_date: "1 month"]
}

由於 this_week_count 和 this_month_count 都會在 sql 參數中使用 ${TABLE}.usersid 語法，因此必須為所有三個欄位更新 sql 參數。

使用參考 ${field_name} 時，只需要進行一個變更：

dimension: usersid {
  type: number
  sql: ${TABLE}.usersid ;; # Change here
}

measure: this_week_count {
  type: count_distinct
  sql: ${usersid} ;;       #Using ${field_name} to reference the LookML field `usersid`
  filters: [created_date: "7 days"]
}

measure: this_month_count {
  type: count_distinct
  sql: ${usersid} ;;       #Using ${field_name} to reference the LookML field `usersid`
  filters: [created_date: "1 month"]
}

如要進一步瞭解替換運算子的用途，請參閱「納入 SQL 並參照 LookML 物件」說明文件頁面。

定義欄位組合

使用集合，在模型中維護可重複使用的欄位清單。無論是使用 fields 參數或鑽研欄位，只要是重複的欄位清單，都應納入集合中，以便在模型中建立單一位置，可用於更新該欄位清單或變更欄位參照。如要進一步瞭解集合，請參閱 set 參數的說明文件頁面。

避免重複程式碼

請將 LookML 物件視為構件，並使用 extends 參數以不同方式結合物件，而無需重複程式碼。如要瞭解重複使用程式碼的詳細資訊和範例，請參閱「使用 extends 重複使用程式碼」說明文件頁面。如需其他範例，請參閱 extends (針對觀看次數) 和 extends (針對探索) 參數說明文件頁面，以及「使用擴充功能定義匯入」社群貼文。

請勿在多個位置重複程式碼，以便在 Explore 中維持一致性。如要進一步瞭解如何達成這項目標，請參閱 Looker 社群的這篇文章，瞭解如何避免探索中出現不一致的情況。

合併地圖圖層和值格式等項目

在名為 map_layers.lkml 的 LookML 檔案中集中定義自訂地圖圖層，您可以按照 Looker 的專案檔案說明文件建立此檔案。接著，您可以視需要在各模型中加入這個檔案。或者，您也可以直接將 JSON 檔案新增至存放區，方法是將資料檔案拖曳至 LookML 專案，然後在模型中參照這些檔案。

舉例來說，假設您有一個地圖圖層檔案 map_layers.base.lkml，其中包含下列 LookML 程式碼：

map_layer: example_africa {
  file: "africa_file_name.json"
  property_key: "geounit"
}

map_layer: example_asia {
  file: "asia_file_name.json"
  property_key: "geounit"
}

map_layer: example_europe {
  file: "europe_file_name.json"
  property_key: "geounit"
}

您可以將 LookML 程式碼 include: "map_layers.base.lkml" 新增至所需的模型檔案，藉此在專案中的任何模型中加入地圖圖層檔案 map_layers.base.lkml。

在模型中集中設定任何自訂值格式。使用 named_value_format 參數設定模型中的任何自訂格式，然後在維度和資料表中使用 value_format_name 參數參照這些格式。

建立開發指南

定義開發指南，方便開發人員開發及擴充 LookML 模型。請參閱 Looker 社群的「LookML 開發指南範例」文章，瞭解開發指南範例清單的操作步驟。常見的規範包括：

  • 清楚整理 LookML 檔案，確保一致性並方便瀏覽
  • 在檢視區塊和模型中使用註解，為所撰寫的 LookML 新增上下文
  • 使用 Markdown 檔案在 Looker 中建立文件