定時SQL常見問題

如何保證SQL分析的資料準確性？

資料延遲寫入或執行個體的調度配置不恰當時，可能發生資料分析不準確問題。

資料寫入存在延遲。例如資料寫入Log Service延遲了5分鐘，執行個體執行時間為12:03:00，SQL時間視窗為相對一分鐘，即[12:02:00，12:03:00)，則查詢不到最新的資料。
資料寫入Log Service後才能被查詢到，這期間存在延時（一般少於3秒）。即使延時很低，也存在資料漏查的風險。例如執行個體執行時間為12:03:30，SQL時間視窗為相對一分鐘，即[12:02:30，12:03:30)，對於12:03:29秒寫入的日誌，不能保證在12:03:30肯定能夠查詢到。
同一分鐘內包含不同時間的日誌時，由於日誌索引的構建，時間較遲的日誌的索引可能落盤到較早的時間點。例如執行個體執行時間為12:03:30，SQL時間視窗為相對一分鐘，即[12:02:30，12:03:30)。如果在12:02:50寫入日誌，這些日誌時間為12:02:20、12:02:50等，那麼這些日誌的索引可能落盤在12:02:20這個時間點，導致在[12:02:30，12:03:30)期間查詢不到日誌。

使用定時SQL時，建議根據業務情況，同時兼顧資料即時性和準確性。

考慮到資料上傳Log Service存在延遲情況，您可以結合資料擷取延遲以及業務能夠容忍的最大結果可見延遲，設定執行延遲和SQL時間視窗（結束時間往前一點），避免執行個體執行時SQL時間視窗內的資料未全部到達。
建議SQL時間視窗按分鐘對齊（例如整分鐘、整小時），以保證上傳局部亂序資料時的資料準確性。

如何解決資料延遲問題？

方案一

為了避免日誌時間出現延遲，保證日誌時間與寫入時間一致，避免定時SQL計算漏掉部分資料，可以使用寫入處理器，在日誌資料寫入LogStore前對資料進行處理。

已完成建立Project web-project-test和建立LogStore website_log，且LogStore website_log已開啟管理LogStore功能，使用Logtail採集日誌或Log ServiceSDK給 test-b寫入日誌。
建立寫入處理器。
1. 登入Log Service控制台，在Project列表地區，單擊目標Project web-project-test。
2. 在左側導覽列單擊資源 > 數據處理器。
3. 在數據處理器 > 寫入處理器頁簽，單擊創建。
4. 在建立處理器面板，輸入處理器名稱和SPL語句，然後單擊確定。
  
  SPL語句：* | extend __time__=cast("__tag__:__receive_time__" as bigint)。
關聯寫入處理器。
1. 在左側導覽列，單擊日誌存儲，將滑鼠懸浮在上website_log上，單擊修改。
2. 在website_log屬性頁面，單擊右上方修改，在編輯狀態下配置寫入處理器，選擇您建立的解析日誌寫入處理器，然後單擊保存。

在LogStore查詢分析中輸入以下SQL，校正寫入時間和日誌時間結果。

* | SELECT 
    cast("__tag__:__receive_time__" as bigint) - cast(__time__ as bigint) as diff
WHERE 
    cast("__tag__:__receive_time__" as bigint) - cast(__time__ as bigint) > 0

方案二

Log ServiceLogStore支援強制重寫__time__為伺服器時間，避免延遲問題。如有需求請提工單申請。

如何防止SQL分析執行失敗？

確保輸入正確的SQL文法。
確保已為待分析的欄位建立正確的索引。例如查詢和分析語句為* | select uid，則您需要為uid欄位開啟統計功能。更多資訊，請參見建立索引。
確保已配置正確的許可權。例如執行SQL分析的許可權和讀取日誌庫資料的許可權。
確保已提供足夠的計算資源。資源限制說明請參見查詢與分析的使用限制。
避免使用邏輯過於複雜的SQL語句以及SQL時間視窗設定過大，否則將導致計算逾時（服務端逾時時間為10分鐘）。

通過定時SQL任務寫入資料到目標庫時，是否進行索引檢查？

Log Service將定時SQL的計算結果寫入目標庫時，不做索引檢查。如果目標庫未配置索引，則您無法進行SQL分析，但這不影響日誌消費和查詢操作。

建議您在建立定時SQL任務前，完成目標庫的索引配置。如果未提前配置索引，可通過重建索引功能為歷史資料配置索引。具體操作，請參見重建索引。

某個執行個體執行逾時，是否會影響後續的執行計畫？

某個執行個體執行逾時不會影響後續的執行計畫的產生。新執行個體的調度時間是延續上一個執行個體的調度時間，但是後續執行個體的建立時間和執行時間會延遲，並且需要花費時間來追趕原定的執行計畫，逐步縮減結果資料的延遲。

一般來說，追趕固定的資料量時，調度周期越大，追趕速度越快。例如：

追趕一天的資料量，調度周期為1分鐘時，需要執行1440個執行個體，每個執行個體運行20秒。
追趕一天的資料量，調度周期為1小時時，需要執行24個執行個體，每個執行個體運行2分鐘。

Log Service提供服務分散式查詢和分析能力，在面對更多資料時將使用更多的計算資源。

寫入到目標庫的資料如何溯源？

通過定時SQL寫入到目標庫的資料，預設被添加如下__tag__欄位，用於資料溯源。

__tag__:__instance_id__:2b****06a：執行個體的ID
__tag__:__job__:from_now：任務名稱
__tag__:__project__:ali-sls-etl-staging：任務所屬於的Project
__tag__:__schedule_time__:1618474200：任務的調度時間，Unix時間戳記，單位：秒。
__tag__:__trigger_time__:1618474259：任務的執行時間，Unix時間戳記，單位：秒。

如何自訂定時SQL任務寫入日誌到目標庫的日誌時間？

根據業務情況，如果需要通過日誌時間進行查詢分析等操作，且不希望日誌時間值是預設指定的，那麼您可以通過如下案例來自訂任務將日誌寫入目標庫的日誌時間值。

說明

__time__為指定的日誌時間，您可以在日誌庫中查看日誌時間。
current_timestamp函數用於返回當前日期、時間和時區。

定時SQL任務寫入日誌到目標庫的日誌時間值是什嗎？

建立定時SQL任務時，SQL代碼不包含__time__欄位（* | select * 預設包含__time__欄位）,定時SQL任務寫入日誌到目標庫的日誌時間值預設會指定為資料時間的開始時間。

如圖所示：系統預設會把SQL查詢區間資料時間的開始時間2024-09-14 15:31:00指定為該執行個體查詢的結果日誌寫入目標庫的日誌時間值。

案例一：指定源日誌庫的日誌時間為寫入到目標日誌庫的日誌時間

在建立定時SQL任務時，SQL中除了需要寫入到目標庫的必要欄位，加入__time__欄位，則當日誌從源日誌庫寫入到目標日誌庫時，系統會把該語句執行結果__time__值作為寫入日誌到目標庫的日誌時間值。

案例二：指定目前時間為寫入到目標庫的日誌時間值

在建立定時SQL任務時，SQL中除了需要寫入到目標庫的必須欄位，加入cast(to_unixtime(current_timestamp) as bigint) AS __time__欄位，則指定目前時間為寫入到目標庫的日誌時間值。關於to_unixtime函數更多資訊，請參見to_unixtime函數。關於cast函數更多資訊，請參見cast函數。

案例三：指定源日誌其他時間欄位值為寫入日誌到目標庫日誌的日誌時間值

如圖所示：將配置在SQL代碼中的start_time替換為您日誌中的真實欄位，且欄位值應為timestamp類型，系統會把該語句執行結果__time__值作為寫入日誌到目標庫的日誌時間值。