配置索引生命週期管理原則實現冷熱資料分離-檢索分析服務 Elasticsearch版-阿里雲

Elasticsearch 6.6.0及以上版本提供了索引生命週期管理（ILM，Index Lifecycle Management）功能，將索引生命週期分為hot、warm、cold、delete四個階段，結合冷熱叢集架構實現資料自動流轉和儲存成本最佳化。

階段	描述
hot	熱資料階段。處理時序資料的即時寫入，可根據索引的文檔數、大小、時間長度決定是否調用rollover API變換索引。
warm	溫資料階段。索引不再寫入，主要提供查詢。
cold	冷資料階段。索引不再更新，查詢頻率低，查詢速度較慢。
delete	刪除階段。索引將被刪除。

為索引添加生命週期管理原則有兩種方式：

為索引模板添加策略：策略應用到別名覆蓋的所有索引，本文以此為例。
為單個索引添加策略：只覆蓋當前索引，新滾動的索引不受該策略影響。

本文以冷熱資料情境為例，示範以下配置流程：

將索引資料即時寫入Elasticsearch，當資料增加到一定量時自動寫入新索引。
舊索引在hot階段停留30分鐘後進入warm階段。
warm階段完成Merge及Shrink操作後，索引在1小時（從變換時算起）後進入cold階段。
cold階段將資料移轉到冷資料節點，索引在2小時（從變換時算起）後被刪除。

操作流程

步驟一：建立冷熱叢集並查看節點的冷熱屬性
在建立叢集時設定節點的冷熱屬性。
步驟二：為索引配置生命週期管理原則
定義ILM策略，並將該策略應用到別名覆蓋的所有索引下。
步驟三：驗證資料分布
驗證cold階段索引的shard是否分布在冷資料節點上。
步驟四：更新ILM策略
更新已有策略。
步驟五：切換ILM策略
在不同策略間實現滾動切換。

步驟一：建立冷熱叢集並查看節點的冷熱屬性

冷熱叢集包含冷、熱兩種屬性的節點，熱節點處理即時寫入，冷節點儲存歷史資料，兩者區別如下。

節點類型	儲存資料要求	讀寫效能要求	規格要求	儲存要求
熱節點（hot）	近期資料，例如最近2天的日誌資料。	高	高，例如32核64 GB	建議使用SSD雲端硬碟。
冷節點（warm）	歷史資料，例如2天之前的日誌資料。	低	低，例如8核32 GB	建議使用高效雲端硬碟，或使用OpenStore實現海量冷資料Serverless儲存。

Elasticsearch中，冷資料節點的box_type值為warm（非cold），這是因為冷資料節點在Elasticsearch原生架構中對應warm tier。

在建立Elasticsearch執行個體時，啟用冷資料節點，即可建立冷熱叢集。
啟用冷資料節點併購買後，系統會在節點啟動參數中加入-Enode.attr.box_type參數：
- 熱資料節點：-Enode.attr.box_type=hot
- 冷資料節點：-Enode.attr.box_type=warm
只有啟用冷資料節點後，資料節點才會變成熱節點。
登入該叢集的Kibana控制台，具體操作請參見通過Kibana串連叢集。
在左側導覽列，單擊Dev Tools 。
在 Console 中，執行如下命令，查看叢集冷熱節點屬性。
```
GET _cat/nodeattrs?v&h=host,attr,value
```
返回結果中包含hot和warm節點，表示叢集已支援冷熱架構。

步驟二：為索引配置生命週期管理原則

在Kibana控制台中，執行如下命令，定義ILM策略。

PUT /_ilm/policy/game-policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_size": "1GB",
            "max_age": "1d",
            "max_docs": 1000
          }
        }
      },
      "warm": {
        "min_age": "30m",
        "actions": {
          "forcemerge": {
                "max_num_segments":1
              },
          "shrink": {
                "number_of_shards":1
              }
        }
      },
      "cold": {
        "min_age": "1h",
        "actions": {
          "allocate": {
            "require": {
              "box_type": "warm"
            }
          }
        }
      },
      "delete": {
        "min_age": "2h",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

參數	說明
hot	索引滿足任一條件（資料達到1 GB、使用超過1天、文檔數超過1000）時觸發變換。舊索引在變換後等待30分鐘進入warm階段。rollover支援max_docs、max_size、max_age三種條件，滿足任一即觸發。
warm	將索引收縮到1個分區，強制合并為1個段。完成後，索引在1小時（從變換時算起）後進入cold階段。
cold	將索引從hot節點遷移到warm（冷資料）節點。完成後，索引在2小時後進入delete階段。
delete	索引被刪除。

策略名稱建立後無法更改。通過Kibana控制台也可以建立策略，但Kibana上max_age最小單位為小時，API方式最小單位為秒。

建立索引模板，在settings中指定冷熱屬性，資料寫入後儲存在hot節點上。

PUT _template/gamestabes_template
{
  "index_patterns" : ["gamestabes-*"],
  "settings": {
    "index.number_of_shards": 5,
    "index.number_of_replicas": 1,
    "index.routing.allocation.require.box_type":"hot",
    "index.lifecycle.name": "game-policy",
    "index.lifecycle.rollover_alias": "gamestabes"
  }
}

參數	說明
index.routing.allocation.require.box_type	指定索引建立時分配的節點類型。
index.lifecycle.name	指定生命週期策略名稱稱。
index.lifecycle.rollover_alias	指定rollover別名。

基於序號建立初始索引。

PUT gamestabes-000001
{
"aliases": {
    "gamestabes":{
       "is_write_index": true
        }
      }
}

也可以基於時間建立索引，詳情請參見using date math。

通過別名寫入資料。當資料達到rollover條件並觸發ILM檢測周期後，索引將進行變換。

PUT gamestabes/_doc/1
{
    "EU_Sales" : 3.58,
    "Genre" : "Platform",
    "Global_Sales" : 40.24,
    "JP_Sales" : 6.81,
    "Name" : "Super Mario Bros.",
    "Other_Sales" : 0.77,
    "Platform" : "NES",
    "Publisher" : "Nintendo",
    "Year_of_Release" : "1985",
    "na_Sales" : 29.08
}

ILM預設10分鐘檢測一次符合策略標準的索引。可通過indices.lifecycle.poll_interval參數修改檢測周期。

（可選）在Kibana中查看索引生命週期狀態。
1. 在左側導覽列，單擊 Management 。
2. 在 Elasticsearch 地區中，單擊 Index Management 。
3. 單擊 Lifecycle phase 下拉式清單，選擇生命週期階段過濾索引。
4. 單擊過濾後的索引名稱，查看索引詳細配置。

步驟三：驗證資料分布

當索引進入cold階段後，驗證其shard是否已分布在冷資料節點上。

在Kibana控制台中，查詢進入cold階段的索引名稱。
執行以下命令，查詢該索引的shard分布情況。將shrink-gamestables-000012替換為實際的索引名稱。
```
GET _cat/shards/shrink-gamestables-000012
```
返回結果中，如果shard所在節點的box_type為warm，表示cold階段的索引資料已分布在冷資料節點上。

步驟四：更新ILM策略

執行以下命令更新已有的ILM策略。以修改game-policy的delete階段時間為例：

PUT /_ilm/policy/game-policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_size": "1GB",
            "max_age": "1d",
            "max_docs": 1000
          }
        }
      },
      "warm": {
        "min_age": "30m",
        "actions": {
          "forcemerge": {
                "max_num_segments":1
              },
          "shrink": {
                "number_of_shards":1
              }
        }
      },
      "cold": {
        "min_age": "1h",
        "actions": {
          "allocate": {
            "require": {
              "box_type": "warm"
            }
          }
        }
      },
      "delete": {
        "min_age": "3h",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

查看更新後的策略版本。
1. 在左側導覽列，單擊 Management 。
2. 在 Elasticsearch 地區中，單擊 Index Lifecycle Policies 。
3. 查看策略版本號碼。更新後版本號碼增加1，當前正在滾動寫入的索引仍使用舊版本原則，新策略在下次變換時生效。

步驟五：切換ILM策略

建立新策略。

PUT /_ilm/policy/game-new
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_size": "3GB",
            "max_age": "1d",
            "max_docs": 1000
          }
        }
      },
      "warm": {
        "min_age": "30m",
        "actions": {
          "forcemerge": {
                "max_num_segments":1
              },
          "shrink": {
                "number_of_shards":1
              }
        }
      },
      "cold": {
        "min_age": "1h",
        "actions": {
          "allocate": {
            "require": {
              "box_type": "warm"
            }
          }
        }
      },
      "delete": {
        "min_age": "2h",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

為模板綁定新策略。

PUT _template/gamestabes_template
{
  "index_patterns" : ["gamestabes-*"],
  "settings": {
    "index.number_of_shards": 5,
    "index.number_of_replicas": 1,
    "index.routing.allocation.require.box_type":"hot",
    "index.lifecycle.name": "game-new",
    "index.lifecycle.rollover_alias": "gamestabes"
  }
}

常見問題

如何調整ILM策略檢查頻率？

ILM預設每10分鐘檢查一次符合策略的索引，在此期間資料量可能超出設定閾值。例如設定max_docs為1000，實際文檔數可能在超過1000後才觸發變換。

通過修改indices.lifecycle.poll_interval參數可控制檢查頻率：

重要

檢查頻率過高會增加節點負載，建議根據業務需求謹慎設定。

PUT _cluster/settings
{
  "transient": {
    "indices.lifecycle.poll_interval":"1m"
  }
}