Log Service提供定時SQL功能，用於定時分析資料、儲存彙總資料、投影與過濾資料。本文介紹定時SQL功能的背景資訊、功能簡介、基本概念、調度與執行情境、使用建議等資訊。
背景資訊
基於時間的資料（日誌、指標）在日積月累後的數量是驚人的。例如每天產生1000萬條資料，則一年為36億條資料。一方面，長時間的資料存放區需要巨大的儲存空間，而通過減少儲存周期的方式減少儲存空間，雖然降低了儲存成本，但也丟失了有價值的資料。另一方面，大量的資料將造成分析上的效能壓力。
資料的儲存和分析具備以下特徵：
大部分時序資料具有時效性特徵。歷史資料可以為分鐘或小時層級的精度，而新產生的資料需要更高的精度。
資料使用者（例如資料營運、資料科學家）需要儲存全量的資料以備分析。
在資料分析階段，需同時兼顧全量資料和快速查詢響應。
針對上述特徵，Log Service推出定時SQL功能，用於將高精度的歷史資料壓縮為低精度資料後，長期儲存。使用定時SQL功能後，您可以根據業務需求為源庫設定較低的儲存周期（例如15天），將目標庫的儲存周期設定為永久儲存。實現長時間範圍資料的低延遲分析、低成本儲存。
功能簡介
定時SQL支援標準SQL92文法、Log Service查詢和分析文法，按照調度規則周期性執行，並將運行結果寫入到目標庫（Logstore或Metricstore）中。
定時分析資料：根據業務需求設定SQL語句或查詢分析語句，定時執行資料分析，並將分析結果儲存到目標庫中。
全域彙總：對全量、細粒度的資料進行彙總儲存，匯總為儲存大小、精度適合的資料，相當於一定程度的有損壓縮資料。例如：
按照秒層級對36億條資料進行彙總儲存，儲存結果為3150萬條資料，儲存大小為全量資料的0.875%。
按照分鐘層級對36億條資料進行彙總儲存，儲存結果為52.5萬條資料，儲存大小為全量資料的0.015%。
投影與過濾：對未經處理資料的欄位進行篩選，按照一定條件過濾資料並儲存到目標Logstore中。
該功能還可以通過資料加工實現，資料加工的DSL文法比SQL文法具備更強的ETL表達能力。更多資訊，請參見加工原理。
基本概念
任務：一個定時SQL任務配置包括計算配置、調度配置等資訊。
執行個體：一個定時SQL任務按照調度配置按時產生執行個體。每一個執行個體對未經處理資料進行SQL計算並將計算結果寫入目標庫。
執行個體ID：執行個體的唯一標識。
建立時間：執行個體的建立時間。一般是按照您配置的調度規則產生，在補運行或追趕延遲時會立即產生執行個體。
執行時間：執行個體開始執行的時間。如果重試任務，則表示最後一次開始執行的時間。
結束時間：執行個體執行結束的時間。如果重試任務，則表示最後一次執行結束的時間。
調度時間：由調度規則決定，不會受到上一個執行個體執行逾時、延遲、補運行等情況的影響。
大部分情境下，連續產生的執行個體的調度時間是連續的，可處理完整的資料集。
SQL時間視窗：定時SQL任務運行時，Log Service僅分析該時間範圍內的資料。SQL時間視窗基於調度時間計算而得，左閉右開格式，且與執行個體的建立時間、執行時間無關。例如調度時間為2021/01/01 10:00:00，SQL時間視窗的運算式為[@m - 10m, @m)，則實際的SQL時間視窗為[2021/01/01 09:50:00, 2021/01/01 10:00:00)。
執行狀態：定時SQL執行執行個體的執行狀態，包括運行中（RUNNING）、重試中（STARTING）、成功（SUCCEEDED）、失敗（FAILED）。
順延強制：定時SQL任務中的配置參數，表示在執行個體的調度時間點上，往後延遲N秒才真正開始執行執行個體。主要用於避免資料延遲等情況導致計算結果不精確問題。如果不需要使用延遲時間來保證結果正確性，您可以將順延強制設定為0秒。
例如，您設定調度間隔為每小時、順延強制為30秒，那麼一天產生24個執行個體，其中某執行個體的調度時間為2021/4/6 12:00:00，執行時間為2021/4/6 12:00:30。
調度與執行情境
一個任務可產生多個執行個體，無論是正常被調度還是您觸發異常執行個體重試的情況，同時只有一個執行個體處於運行中，不存在多個執行個體並發執行的情況。主要的調度與執行情境如下：
情境一：執行個體順延強制
無論執行個體是否順延強制，執行個體的調度時間都是根據調度規則預先產生的。雖然前面的執行個體發生延遲時，可能導致後面的執行個體也順延強制，但通過追趕執行進度，可逐漸減少延遲，直到恢複準時運行。
情境二：從某個記錄點開始執行定時SQL任務
在目前時間點建立定時SQL任務後，按照調度規則對歷史資料進行處理，從調度的開始時間建立補啟動並執行執行個體，補啟動並執行執行個體依次執行直到追上資料處理進度後，再按照預定計劃執行新執行個體。
情境三：固定時間內執行定時SQL任務
如果需要對指定時間段的日誌做調度，則可設定調度的時間範圍。如果設定了調度的結束時間，則最後一個執行個體（調度時間小於調度結束時間）執行完成後，不再產生新的執行個體。
情境四：修改調度配置對產生執行個體的影響
修改調度配置後，下一個執行個體按照新配置產生。一般建議同步修改SQL時間視窗、調度頻率等配置，使得執行個體之間的SQL時間範圍可以連續。
情境五：重試失敗的執行個體
正常情況下，一個定時SQL任務按照調度時間的遞增順序產生執行執行個體。如果執行個體執行失敗（例如許可權不足、源庫不存在、目標庫不存在、SQL文法不合法），系統支援自動重試，當重試次數超過您配置的最大重試次數或重試時間超過您配置的最大已耗用時間時，重試結束，該執行個體狀態被置為失敗，然後系統繼續執行下一個執行個體。
您可以對失敗的執行個體設定警示通知並進行手動重試。您可以對最近7天內建立的執行個體進行查看、重試操作。調度執行完成後，系統會根據實際執行情況變更執行個體狀態為成功或失敗。如何重試，請參見重試定時SQL任務執行個體。
使用建議
使用定時SQL時，建議根據業務情況，同時兼顧資料即時性和準確性。
考慮資料上傳Log Service存在延遲情況，您可以結合資料擷取延遲以及業務能夠容忍的最大結果可見延遲，設定執行延遲和SQL時間視窗（結束時間往前一點），避免執行個體執行時SQL時間視窗內的資料未全部到達。
建議SQL時間視窗按分鐘對齊（例如整分鐘、整小時），以保證上傳局部亂序資料時的資料準確度。