本文為您介紹Hologres計算資源管理最佳實務，協助您更高效、更智能、更具性價比地承載業務複雜多樣的讀寫請求。
背景資訊
本文以某電商公司資料中台為例，中台團隊負責資料加工，多個業務團隊均需資料查詢。各團隊業務情境、業務特點如下。
團隊 | 職責 | 業務情境 | 業務特點 |
資料中台 | 負責全部業務團隊的資料寫入與加工，含即時鏈路、近即時鏈路和離線鏈路。 | 即時/近即時鏈路：
離線鏈路：
|
|
分析業務方 | 面向營運、門店和銷售等多類角色，負責公司銷售資料分析。 |
|
|
推薦業務方 | 面向智能推薦業務，負責商品千人千面推薦。 | 線上推薦：基於主鍵查詢使用者特徵，下遊推薦演算法基於使用者特徵返回推薦商品。 | 每晚為使用者使用電商平台流量波峰時段。 |
最佳化原理
如果業務請求始終穩定，則僅需購買一定數量的訂用帳戶計算資源，即可滿足業務負載需要。但大部分情況下，業務均存在高並發請求波峰，或存在極端大任務，導致計算資源持續打滿，影響執行個體穩定性。此時，可按如下決策樹選擇資源最佳化方案。
極端大任務（例如：大量歷史資料回刷、無過濾條件的全表掃描、10+表的複雜關聯查詢、多層子查詢嵌套的複雜計算等）推薦開啟自適應Serverless計算，直接使用Serverless Computing解決，避免影響本執行個體資源正在執行的其他Query。
經過Fixed Plan最佳化的請求不支援使用Serverless Computing資源執行，也不進入查詢隊列（即不支援限流），因此只能通過擴容計算群組解決，其中，寫入請求波峰無法通過計算群組自動彈性解決。
其他請求可根據業務延時需求、波峰時段特徵、請求類型特徵來選用合適的資源最佳化方案。
對於使用Serverless Computing的業務請求，可參見資源管理最佳化實踐，選取合適的使用方式。
資源管理最佳化實踐
將從以下業務痛點出發，為您推薦最優的解決方案。
痛點一：不同業務之間資源擠占，互相影響
資料中台的資料加工任務、下遊各業務方的資料查詢任務可能會互相擠占對方的計算資源，受到其他業務的影響。
推薦使用Hologres計算群組型執行個體，建立如下計算群組，以保證不同團隊之間負載隔離。計算群組型執行個體請參見計算群組執行個體架構。
主計算群組（init_warehouse）：中台團隊使用，負責資料寫入與加工。
唯讀計算群組1：分析業務方使用。
唯讀計算群組2：推薦業務方使用。
痛點二：業務有固定高峰，資源擴縮容複雜
本文樣本情境中，如下業務情境可能存在該難題，可通過分時彈性（Beta）功能，對計算群組定時擴、縮容。相比於全部使用訂用帳戶計算資源的方案，分時彈性每天彈出16小時內即可降低成本。
資料中台的即時寫入任務：
即時寫入任務會經Fixed Plan最佳化，僅支援計算群組擴縮容的方式解決資源問題。
每晚為流量波峰時段，可配置分時彈性，每晚對主計算群組定時擴縮容。
分析業務方的BI分析任務：結合流量波峰時段（白天工作時間）特點，配置分時彈性，對唯讀計算群組進行定時擴縮容。
推薦業務方的線上推薦任務：
線上推薦任務屬於點查，會經Fixed Plan最佳化，只可選擇對計算群組擴縮容的方式解決資源問題。
結合流量波峰時段（每晚），可配置分時彈性，每晚對唯讀計算群組定時擴縮容。
痛點三：大任務OOM頻率高並長期佔用資源，影響其他任務
本文樣本情境中，如下業務情境可能存在“大任務”難題：
資料中台的T+1離線加工任務：單任務的計算量可能非常大，任務本身容易OOM，還可能長期佔用計算資源，阻塞其他任務。
方案一（穩定性優先）：所有T+1離線加工任務均使用Serverless Computing資源執行，可通過SQL層級配置，或對執行離線鏈路的使用者層級配置。詳情請參見使用Serverless Computing資源執行讀寫任務。
方案二（穩定性與成本兼顧）：如果離線鏈路存在大小不一的表的寫入與加工任務，可以將小型任務保留在主計算群組中執行。
資料中台的Dynamic Table近即時加工任務：每張表每分鐘執行一次增量重新整理任務，任務計算量與增量資料量相關，存在不穩定因素。
方案一（穩定性優先）：Dynamic Table近即時加工任務均使用Serverless Computing資源執行。詳情請參見CREATE DYNAMIC TABLE。
方案二（穩定性與成本兼顧）：將Dynamic Table中大表或存在較巨量資料量波動的表的重新整理任務使用Serverless Computing執行，其餘任務保持在主計算群組中執行。
分析業務方的BI分析大屏：大屏數量多，任務存在大小差異，大任務可能長期佔用計算資源，從而阻塞小任務。
方案一（穩定性、成本與開發量兼顧）：DB層級或使用者層級（大屏資料來源對應使用者）開啟自適應Serverless計算功能，可以將大屏中的“大任務”自動指向Serverless資源，小任務仍在本計算群組中執行。
方案二（穩定性與成本兼顧）：提取大屏中“大任務”的SQL指紋（具體看板的SQL指紋通常不變），形成一個查詢隊列，配置該查詢隊列的請求均使用Serverless資源執行。該方案可通過如下流程實現：
測試大屏，使Hologres執行完大屏中的全部請求。
在Hologres慢Query日誌中，按cpu_time_ms欄位篩選出“大任務”，提取對應的digest欄位，即SQL指紋。詳情請參見慢Query日誌查看與分析。
將這些“大任務”的SQL指紋配置成一個單獨的查詢隊列。詳情請參見配置分類器匹配規則。
配置該查詢隊列的請求均使用Serverless資源執行。詳情請參見使用Serverless Computing資源執行查詢隊列的查詢。
方案三（成本優先）：所有請求均優先在本計算群組中執行，同時對查詢隊列開啟“大查詢自動重跑”功能，使用Serverless資源重跑逾時查詢和OOM查詢，同時使用者對逾時和OOM無感知。詳情請參見大查詢控制。
痛點四：突發性大任務直接打滿資源集區，影響系統穩定性
分析業務方的營運人員自助分析任務：該類任務可能出現突發性大任務，單個請求可能產生較大開銷，影響執行個體穩定性。
方案一（穩定性優先）：使用者層級配置該自助分析人員的全部請求均使用Serverless Computing執行，詳情請參見使用者層級配置。
方案二（穩定性與成本兼顧）：使用者層級開啟自適應Serverless計算功能，可以將該使用者發起的“大任務”自動指向Serverless資源，小任務仍在本計算群組中執行。
方案三（成本優先）：所有請求均優先在本計算群組中執行，同時對查詢隊列開啟“大查詢自動重跑”功能，使用Serverless資源重跑逾時查詢和OOM查詢，同時使用者對逾時和OOM無感知。詳情請參見大查詢控制。
痛點五：不同情境資料時效性、穩定性要求不同
分析業務方的BI分析大屏：企業多類角色（資料開發人員、營運人員、銷售人員、企業高層等）均可能訪問大屏，同時訪問大屏的渠道也有差異（對客展示、內部查看等）。
針對效能要求高的角色/情境：
方案一（穩定性優先）：如果該情境請求量穩定，可為其單獨建立計算群組以承載其請求。
方案二（穩定性與成本兼顧）：可使用上文方案一（穩定性優先），全部請求均通過Serverless Computing執行，或使用自適應Serverless計算功能。
針對可接受一定延時的角色/情境：
如果大屏的請求類型固定，比如該類角色只會訪問一個報表，可在充分壓測計算群組對該報表的承載能力後，配置手動限流（基於查詢隊列配置固定數量的並發度上限），詳情請參見建立查詢隊列。
如果大屏的請求類型不固定，比如該類角色數量多且報表數量也多，可開啟自動限流功能。Hologres會根據負載情況自動調整查詢隊列的並發度上限，詳情請參見自動限流（Beta）。
痛點六：突發大量請求，影響計算群組穩定性
分析業務方夜間也可能存在非預期查詢波峰。該類波峰無分類特徵（使用者、表、SQL均不確定），難以分類路由到Serverless Computing中。也無分時特徵，無法通過分時彈性提前自動擴容。
方案：開啟計算群組自動彈性功能，計算群組負載高時自動橫向擴充增加計算資源，負載低時自動減少計算資源，參見Multi-cluster與自動彈性（Beta）。
進階操作
配置Serverless Computing中任務的優先順序
由於多個業務均需使用Serverless Computing計算資源，可以在使用者層級對不同使用者發送至Serverless Computing中的請求配置優先順序。詳情請參見設定Serverless Computing任務的優先順序。樣本如下：
效能要求高的角色的查詢請求：配置優先順序為5，Serverless資源緊張時優先執行。
離線T+1寫入與加工任務：配置優先順序為1，Serverless資源緊張時排隊等待。
其他任務：使用預設優先順序3。
配置Serverless Computing日累計用量限制
由於多個業務均可使用Serverless Computing計算資源，可能產生額外費用。Hologres支援配置執行個體每日可用的Serverless Computing資源量限制，同時支援對不同使用者配置不同的上限，可協助使用者靈活高效地使用Serverless計算資源。詳情請參見日累計用量限制。
配置唯讀計算群組的查詢高可用
針對唯讀計算群組，尤其是唯讀計算群組承載的線上推薦業務，推薦配置Shard層級多副本，可實現在有計算節點Failover時查詢無損。詳情請參見單一實例Shard級多副本，