Lindorm：冷熱分離常見問題

Lindorm通過compaction機制非同步將冷資料從熱儲存歸檔至冷儲存，系統觸發時間預設為冷熱分界線的一半，最小為1天，最大為major compaction周期的一半，major compaction周期預設為20天。例如，冷熱分界線為3天，則預設1.5天就會自動觸發一次compaction歸檔任務；如果冷熱分界線為1天，則1天觸發一次compaction。

可以。您可以通過HBase Shell對錶執行major_compact 'tableName'來強制觸發compaction，將熱儲存中的冷資料歸檔至冷儲存中。

這是因為您寫入的資料可能還未寫入磁碟。請先執行flush操作將資料刷寫至磁碟上，再執行compaction操作，即可將資料存放區至冷儲存中。compaction操作說明如下：

• HBase Shell使用方式，請執行major_compact命令。

• Lindorm-cli串連使用方式，使用文法請參見ALTER TABLE。

• 如果出現compaction積壓，則會影響熱資料進入冷儲存的速度。此時需要通過擴容或升級配置來增加CPU資源，以解決compaction積壓的問題。

  說明

  是否出現compaction積壓可以通過查看執行個體監控資訊中的寬表引擎指標——叢集負載 > Compaction隊列長度(個)來確定。如果持續大於0且個數不斷增加，則說明已出現compaction積壓。如何查看監控資訊，請參見查看監控資訊。

• 如果您的寬表引擎不是最新版本，請升級到最新的版本，新版本最佳化了冷資料歸檔的速度。如何查看或升級目前的版本，請參見寬表引擎版本說明和升級小版本。

• 如果還有其他疑問，請聯絡支援人員。

如果更新的冷資料不是自訂時間列，那麼更新後的資料依舊是冷資料；如果更新的是自訂時間列中的資料，則需要根據新寫入的時間內容來重新劃分冷熱資料。假設一個表的主鍵列為p1，p2， 非主鍵列為c1， c2，某一行為p1=row1， p2=2023.1.28日， c1=”c1“， c2=”c2“，冷熱分界線CHS=1天，目前時間為2023.1.30日，此時這一行為冷資料。如果更新這一行中的c1，c2列的值，那麼這一行仍然為冷資料；如果將這一行中p2的值更新為2023.1.30日，那麼這一行將變為熱資料，直到2023年2月1日（2天后），才會重新變為冷資料。

不會。自訂時間列是系統對資料冷熱分離儲存的依據。如果一行資料未寫入時間，那麼這行資料會被保留在熱儲存區。

不是。由於更新後的資料重新記錄了時間戳記，因此冷資料更新後變為熱資料。

查詢語句可以通過設定HOT_ONLY/_l_hot_only_僅查詢熱資料。但由於資料歸檔至冷儲存的操作是周期性觸發的，因此有部分冷資料可能會滯留在熱儲存，導致查詢結果中包含了冷資料。可以在查詢條件中添加熱資料時間範圍，避免出現此類問題。樣本如下：

// 您需要設定_l_ts_min_(目前時間-冷熱分界線), _l_ts_max_(目前時間), 注意時間單位統一
SELECT /*+ _l_hot_only_(true), _l_ts_min_(1000), _l_ts_max_(2001) */ * FROM test WHERE p1>1;

這種情況一般發生在資料移轉或者修改表屬性為冷熱分離表後。此時系統尚未觸發資料歸檔至冷儲存，因此大量的冷資料滯留於熱儲存中，資料量的增大導致了查詢效率的降低。需要對錶執行major compaction操作來解決這一問題。具體文法，請參見ALTER TABLE。

這是因為主表和索引表的冷資料歸檔過程是獨立的，並且歸檔主表和索引表冷資料的操作是周期性觸發的，導致了主表和索引表滯留在熱儲存的資料不一致，進而出現查詢到的冷資料不一致的現象。 您可以在查詢條件中添加熱資料的時間範圍，避免此類問題的出現。

目前時間減去最舊的檔案的產生時間大於冷資料歸檔周期時，則會觸發冷資料轉存。是否立刻觸發compaction，取決於目前時間與最舊檔案產生時間的差值。

支援，您可以參考按時間戳記冷熱分離的資料查詢和按自訂時間列冷熱分離的範圍查詢Scan，在查詢時指定時間範圍來實現冷資料的查詢。需注意的是，容量型雲端儲存和歸檔型雲端儲存的讀IOPS能力相對較低，因此查詢可能會比較慢。