建站
咨詢
售后
建站咨詢
新聞中心
大規(guī)模日志全局分析的需求
成都創(chuàng)新互聯(lián)公司自成立以來，一直致力于為企業(yè)提供從網(wǎng)站策劃、網(wǎng)站設(shè)計(jì)、成都做網(wǎng)站、成都網(wǎng)站制作、成都外貿(mào)網(wǎng)站建設(shè)、電子商務(wù)、網(wǎng)站推廣、網(wǎng)站優(yōu)化到為企業(yè)提供個(gè)性化軟件開發(fā)等基于互聯(lián)網(wǎng)的全面整合營銷服務(wù)。公司擁有豐富的網(wǎng)站建設(shè)和互聯(lián)網(wǎng)應(yīng)用系統(tǒng)開發(fā)管理經(jīng)驗(yàn)、成熟的應(yīng)用系統(tǒng)解決方案、優(yōu)秀的網(wǎng)站開發(fā)工程師團(tuán)隊(duì)及專業(yè)的網(wǎng)站設(shè)計(jì)師團(tuán)隊(duì)。
數(shù)據(jù)大規(guī)模與時(shí)效性
基于時(shí)間的數(shù)據(jù)（日志、指標(biāo)）在日積月累后的數(shù)量是驚人的。以 SLB 七層訪問日志為例，每一個(gè)HTTP/HTTPS 訪問請(qǐng)求會(huì)記錄一條 access log，假設(shè)每天產(chǎn)生1000萬條數(shù)據(jù)，則一年為36億條數(shù)據(jù)。一方面，長時(shí)間的數(shù)據(jù)存儲(chǔ)需要巨大的存儲(chǔ)空間，而通過減少存儲(chǔ)周期的方式降低存儲(chǔ)空間，雖然控制了存儲(chǔ)成本，但也丟失了有價(jià)值的歷史數(shù)據(jù)。另一方面，大量的數(shù)據(jù)將造成分析上的性能壓力。
大部分時(shí)序數(shù)據(jù)具有時(shí)效性特征。歷史數(shù)據(jù)可以接受分鐘或小時(shí)級(jí)別的精度，而新產(chǎn)生的數(shù)據(jù)需要更高的精度（例如監(jiān)控、線上問題調(diào)查）。數(shù)據(jù)運(yùn)營、分析師需要存儲(chǔ)全量的數(shù)據(jù)以備分析，歷史數(shù)據(jù)直接 TTL 刪除是可能最差的選擇。
例如 Elasticsearch rollup、時(shí)序數(shù)據(jù)庫的降精度用于解決這部分問題。
一份數(shù)據(jù)在多種場景使用
對(duì)于同一份日志，可能被多種用戶角色在多種場景下使用到：
實(shí)時(shí)的數(shù)據(jù)，需要支持關(guān)鍵詞告警、時(shí)序數(shù)據(jù) ML 巡檢、日志上下文查詢。
亞秒級(jí)延遲粒度上，有全文關(guān)鍵詞的查詢、交互式 SQL 統(tǒng)計(jì)分析的需求。
以天為單位，需要對(duì)日志做運(yùn)營分析，計(jì)算轉(zhuǎn)化率、設(shè)計(jì)運(yùn)營策略。
一周前的產(chǎn)生的數(shù)據(jù)，大部分時(shí)候不再會(huì)被觸碰到，在支持偶爾的歷史指標(biāo)查看以外，審計(jì)場景下對(duì)全量日志的存儲(chǔ)也是必須項(xiàng)。
一份數(shù)據(jù)，多處使用，既要滿足業(yè)務(wù)需求，成本也是需要關(guān)心的。
自定義業(yè)務(wù)分析
云上日志設(shè)施面對(duì)的客戶群呈現(xiàn)多樣化，自定義的業(yè)務(wù)需求舉例如下：
電商：計(jì)算七日留存率，業(yè)務(wù)訪問 SQL 審計(jì)日志對(duì)用戶信息脫敏，等等。
在線教育：多平臺(tái)終端（android、ios、PC）埋點(diǎn)數(shù)據(jù)的規(guī)整，直播課堂生命周期內(nèi)的異常診斷，等等。
游戲：按游戲的數(shù)據(jù)分發(fā)存儲(chǔ)，全文搜索支持工單調(diào)查，等等。
阿里云 SLS 是云原生觀測分析平臺(tái)，為Log/Metric/Trace等數(shù)據(jù)提供大規(guī)模、低成本、實(shí)時(shí)平臺(tái)化服務(wù)，一站式提供數(shù)據(jù)采集、加工、分析、告警可視化與投遞功能。我們將以業(yè)務(wù)為目標(biāo)的數(shù)據(jù)處理歸納為兩類需求：
ETL：將非結(jié)構(gòu)化的日志做預(yù)處理，為日志信息添加業(yè)務(wù)字段，數(shù)據(jù)脫敏與分發(fā)等。
分析：全局?jǐn)?shù)據(jù)大表上的查詢和 SQL 分析，支持布爾搜索、window、aggregate 操作等。
SLS 上的典型分析方案
對(duì)于 ETL、分析這兩類計(jì)算任務(wù)，除了交互式分析以外，還需要常駐作業(yè)模式來處理結(jié)果落盤。
根據(jù)不同的業(yè)務(wù)需求，這里總結(jié)了幾種常見的 SLS 數(shù)據(jù)分析方案。
數(shù)倉 "T+1"
對(duì)于結(jié)果實(shí)時(shí)性不敏感的業(yè)務(wù)，有較多采用數(shù)倉方案：
數(shù)據(jù)通過 SLS 實(shí)時(shí)入庫，集中化存儲(chǔ)。
全托管數(shù)據(jù)投遞到 MaxCompute。
業(yè)務(wù)規(guī)劃小時(shí)級(jí)或天級(jí)的計(jì)算任務(wù)，生成下游表，產(chǎn)出業(yè)務(wù)報(bào)表等結(jié)果。
流計(jì)算
以 Flink、Spark Streaming（continuous mode）、Kafka Streams 為代表的實(shí)時(shí)計(jì)算系統(tǒng)，在數(shù)據(jù)處理語義（exactly-once）、計(jì)算結(jié)果修正上的能力強(qiáng)大。該方案會(huì)用到 SLS 百 ms 秒級(jí)端到端延遲的 pub/sub 能力：
數(shù)據(jù)實(shí)時(shí)推送到 SLS 日志庫。
啟動(dòng)流計(jì)算任務(wù)，從多個(gè) shard 實(shí)時(shí)消費(fèi)數(shù)據(jù)。
流計(jì)算任務(wù)根據(jù)算子組合情況（stateless、statefull、groupby 等）切分多個(gè)拓?fù)鋱?zhí)行，可能涉及到數(shù)據(jù) shuffle、watermark、state store 等機(jī)制。
這個(gè)方案在算子豐富度、實(shí)時(shí)能力、性能上綜合表現(xiàn)全面，是一把牛刀，例如在電商實(shí)時(shí)大屏場景上是非常好的選擇。
如果抱著挑刺的眼光來看：
計(jì)算引擎層面做得均衡，但缺乏存儲(chǔ)層的優(yōu)化。例如：一個(gè) logstore 上運(yùn)行 10 個(gè)流計(jì)算作業(yè)，無論實(shí)際需要納入計(jì)算范圍的數(shù)據(jù)有多少，最終需要 10 遍全部數(shù)據(jù)流量的訂閱，從業(yè)務(wù)角度上看存在網(wǎng)絡(luò)、計(jì)算資源上的浪費(fèi)。
對(duì)于日志用戶來說，在參數(shù)配置、性能調(diào)優(yōu)、問題 Debug 有復(fù)雜性（復(fù)雜常常是通用、強(qiáng)大的另一面）。在復(fù)雜場景下，DevOps-er 理解業(yè)務(wù)需求后，需要設(shè)置好高級(jí)參數(shù)、選擇好 state store 等。
計(jì)算集群部署方式，尤其對(duì)于自建集群、數(shù)據(jù)稀疏的應(yīng)用，其成本上有影響，例如 JobManager/TaskManager 等角色資源需要攤銷。
自建程序做流式消費(fèi)
還是圍繞 SLS 的 pub/sub 能力，以 SLS SDK 方式調(diào)用 PullData API，例如：
通過 Logstash/Flume 等開源軟件，加載 SLS source connector。
通過函數(shù)計(jì)算（SLS 提供 FC 觸發(fā)器），好處是 Serverless 的 runtime，極致彈性計(jì)費(fèi)。
通過 SLS 的 consumer group library 處理數(shù)據(jù)，自動(dòng)負(fù)載均衡、failover。
以上對(duì)于行處理場景是適用的，適用面上則需要關(guān)注：
該方案在絕大部分情況下都不涉及全局計(jì)算（窗口、聚集），即使能實(shí)現(xiàn)也很復(fù)雜。
自建程序、開源軟件需要運(yùn)維人力以及固定機(jī)器投入的成本。
自建程序做查詢、分析
在 SLS 的流式存儲(chǔ)之上，開啟了索引分析功能，帶來了全文索引、列式下推、SQL 計(jì)算能力加持。
該方案調(diào)用 SLS GetLogs API，部署一個(gè)常駐程序，設(shè)置定時(shí)觸發(fā)器，周期調(diào)度任務(wù)執(zhí)行：
調(diào)用 API 讀取 SLS 索引并計(jì)算數(shù)據(jù)。
讀取計(jì)算結(jié)果寫出到目標(biāo)做存儲(chǔ)。
用戶除了需要運(yùn)維程序，還需要考慮以下需求：
SQL 運(yùn)行可能因計(jì)算量巨大而超時(shí)，失敗時(shí)需調(diào)度層的重試支持。
執(zhí)行延遲時(shí)告警支持。
調(diào)度元信息（schedule_time 等）持久化。
web console 管理的需求。
如何將 SQL 計(jì)算結(jié)果 exactly-once 入庫。
本文后續(xù)重點(diǎn)介紹的 Scheduled SQL，從本質(zhì)上來講，是對(duì)該方案的服務(wù)化，對(duì)以上問題有更全面的考慮。
SLS 告警
對(duì)，你沒看錯(cuò)。有少數(shù)用戶用 SLS 告警曲線救國，圖的是一個(gè)全托管、免運(yùn)維。
SLS 告警功能支持設(shè)置定時(shí)策略，執(zhí)行多個(gè) SQL 獲取結(jié)果，并將結(jié)果編排后發(fā)送到內(nèi)置 logstore（internal-alert-history）或自定義的網(wǎng)關(guān)/webhook。
需要說明的是，告警的主要設(shè)計(jì)場景是面向小的計(jì)算結(jié)果，按觸發(fā)策略、值班表，將事件傳達(dá)給接收者。對(duì)于嚴(yán)苛的業(yè)務(wù)，不推薦這種做法（可以關(guān)注 Scheduled SQL 功能做遷移）：
告警的結(jié)果寫出可能出現(xiàn)寫出數(shù)據(jù)大小截?cái)啵? MB 內(nèi)）、 exactly-once 等問題。
告警 1.0 是串行調(diào)度，某一次計(jì)算發(fā)生延遲后，多次執(zhí)行實(shí)例的 SQL 時(shí)間窗口會(huì)出現(xiàn)空洞。
SLS 原生數(shù)據(jù)處理方案
用一張圖描述 SLS 原生數(shù)據(jù)處理功能如下，接下來分別按存儲(chǔ)模型展開介紹：
stream 模型
例如通過 Flink、自建消費(fèi)組程序進(jìn)行 SLS 數(shù)據(jù)分析，都基于 stream 模型。這是 SLS 最基礎(chǔ)的存儲(chǔ)形式（也稱 LogHub），可以理解為 append-only 的 log 結(jié)構(gòu)，通過 多個(gè) shard 組合實(shí)現(xiàn) IO 和存儲(chǔ)的水平擴(kuò)展。
LogHub 與開源軟件 Kafka 是類似的功能形態(tài)，SLS 底層是共享分布式存儲(chǔ)（盤古），這避免了 Kafka 在機(jī)器磁盤空間 re-balance、機(jī)器替換、存儲(chǔ)規(guī)模的一些缺陷。
stream 存儲(chǔ)模型在機(jī)器數(shù)據(jù)場景下有多重優(yōu)勢：
寫入模型簡單，不需要 commit 機(jī)制，天生支持流式寫入，客戶端（移動(dòng)端設(shè)備、Agent）友好。
append-only 保證了寫入吞吐的設(shè)計(jì)上限，滿足業(yè)務(wù)高并發(fā)、高吞吐需求。
FIFO 的 changelog 模式，滿足大多數(shù)日志、指標(biāo)類數(shù)據(jù)的生成與使用場景。
針對(duì)流式數(shù)據(jù) ETL 場景，SLS 支持?jǐn)?shù)據(jù)加工功能，可以實(shí)現(xiàn)按量付費(fèi)、全托管的行處理需求，本文不多介紹，可以參考SLS 數(shù)據(jù)加工的設(shè)計(jì)與實(shí)踐。
table 模型
當(dāng) stream 數(shù)據(jù)寫入后，對(duì)于 shard 內(nèi)的數(shù)據(jù)，可以同時(shí)構(gòu)建一份包括倒排、列存、bitmap 等信息的索引數(shù)據(jù)。shard 內(nèi) stream 數(shù)據(jù)相當(dāng)于是正文，索引到今天有兩種形式：
Logstore (with index)：適用于日志模型，形式上是表結(jié)構(gòu)，一條數(shù)據(jù)由多組 key-value pair 組成。
Metricstore：對(duì)于指標(biāo)類型數(shù)據(jù)有針對(duì)性優(yōu)化，有序排列存儲(chǔ)支持快速指標(biāo)計(jì)算，高壓縮率低存儲(chǔ)成本。
例如 Logstore，在計(jì)算時(shí)稱為 append-only Table 模型。在 SLS 場景下有以下優(yōu)勢：
計(jì)算效率高，時(shí)間（一級(jí)索引）過濾、計(jì)算下推都可以直接利用 index 進(jìn)行，節(jié)省網(wǎng)絡(luò)、計(jì)算的性能開銷與計(jì)算成本。當(dāng)然，index 會(huì)有構(gòu)建費(fèi)用，SLS 的一份 index 數(shù)據(jù)可以服務(wù)于多個(gè)業(yè)務(wù)場景（告警、儀表盤、全文搜索、監(jiān)控）來攤銷成本。
OLAP 解決確定性問題，按照條件過濾取到數(shù)據(jù)后，直接進(jìn)行計(jì)算即可，不需要考慮流計(jì)算中 watermark、trigger 與 window 配合、state store 數(shù)據(jù)膨脹（特定場景）等復(fù)雜問題。
Scheduled SQL 讓 SQL 可調(diào)度
SLS 的每一次 SQL 計(jì)算針對(duì)預(yù)定的一片數(shù)據(jù)做處理，因此，對(duì)全部時(shí)間區(qū)間（從現(xiàn)在開始一直到未來）數(shù)據(jù)的 SQL 分析依賴于上層調(diào)度，也就是將要介紹的新功能 Scheduled SQL，它支持標(biāo)準(zhǔn)SQL、SLS 查詢和分析語句，按照調(diào)度規(guī)則周期性執(zhí)行，并將運(yùn)行結(jié)果寫入到目標(biāo)庫中?？捎糜谝韵聢鼍埃?/p>
定時(shí)分析數(shù)據(jù)：根據(jù)業(yè)務(wù)需求設(shè)置分析語句，定時(shí)執(zhí)行，并將分析結(jié)果存儲(chǔ)到目標(biāo)庫中。
全局聚合：對(duì)全量、細(xì)粒度的數(shù)據(jù)進(jìn)行聚合存儲(chǔ)，匯總為存儲(chǔ)大小、精度適合的數(shù)據(jù)，相當(dāng)于一定程度的有損壓縮數(shù)據(jù)。例如按照秒級(jí)別對(duì) 36 億條數(shù)據(jù)進(jìn)行聚合存儲(chǔ)，存儲(chǔ)結(jié)果為 3150 萬條數(shù)據(jù)，存儲(chǔ)大小為全量數(shù)據(jù)的0.875%。
投影與過濾：對(duì)原始數(shù)據(jù)的字段進(jìn)行篩選，按照一定條件過濾數(shù)據(jù)并存儲(chǔ)到目標(biāo)Logstore中。該功能還可以通過數(shù)據(jù)加工實(shí)現(xiàn)，數(shù)據(jù)加工的DSL語法比SQL語法具備更強(qiáng)的ETL表達(dá)能力，更多信息請(qǐng)參見加工原理。
Scheduled SQL 相比于自建程序調(diào)用 SLS API 而言，有以下優(yōu)勢：
SQL 運(yùn)行 timeout 提升至 600 秒，單次最大處理百億級(jí)數(shù)據(jù)。
計(jì)算資源池可選：免費(fèi)（project 級(jí) 15 并發(fā)）、付費(fèi)（彈性擴(kuò)展，參考SQL 獨(dú)享實(shí)例）。
最小 1 分鐘周期執(zhí)行，支持常駐或固定時(shí)間區(qū)間內(nèi)調(diào)度運(yùn)行。
支持靈活的查詢時(shí)間窗口參數(shù)配置，滿足多樣化需求。
exactly-once 寫入目標(biāo)庫。
完善的作業(yè)實(shí)例查看、重試支持（控制臺(tái)、API）。
全托管運(yùn)行，自動(dòng)處理多種異常，調(diào)度不收費(fèi)。
實(shí)例執(zhí)行失敗集成 SLS 告警通知。
Scheduled SQL 功能介紹
工作機(jī)制
Scheduled SQL 涉及以下幾個(gè)重要概念：
作業(yè)：一個(gè) Scheduled SQL 任務(wù)對(duì)應(yīng)一個(gè)作業(yè)，包括調(diào)度策略、計(jì)算規(guī)則等信息。
實(shí)例：一個(gè) Scheduled SQL 作業(yè)按照調(diào)度配置按時(shí)生成執(zhí)行實(shí)例。每一個(gè)實(shí)例對(duì)原始數(shù)據(jù)進(jìn)行 SQL 計(jì)算并將計(jì)算結(jié)果寫入目標(biāo)庫。實(shí)例ID 是其唯一標(biāo)識(shí)。
創(chuàng)建時(shí)間：實(shí)例的創(chuàng)建時(shí)間。一般是按照您配置的調(diào)度規(guī)則生成，在補(bǔ)運(yùn)行或追趕延遲時(shí)會(huì)立即生成實(shí)例。
調(diào)度時(shí)間：由調(diào)度規(guī)則生成，不會(huì)受到上一個(gè)實(shí)例執(zhí)行超時(shí)、延遲、補(bǔ)運(yùn)行等情況的影響。大部分場景下，連續(xù)生成的實(shí)例的調(diào)度時(shí)間是連續(xù)的，可處理完整的數(shù)據(jù)集。
流計(jì)算里有大量篇幅用于處理數(shù)據(jù)計(jì)算的一致性、完整性問題，Scheduled SQL 則是一種以 small-batch 模擬常駐計(jì)算的方案，針對(duì)這兩個(gè)問題的設(shè)計(jì)是：
1.計(jì)算一致性
SQL 每次執(zhí)行會(huì)對(duì)應(yīng)到確定的時(shí)間窗口，由此得到確定數(shù)據(jù)集再調(diào)度 SQL 計(jì)算。Scheduled SQL 實(shí)例運(yùn)行時(shí)，SQL 查詢的時(shí)間窗口是基于調(diào)度時(shí)間渲染得到，左閉右開格式，與實(shí)例的創(chuàng)建時(shí)間、執(zhí)行時(shí)間無關(guān)。例如調(diào)度時(shí)間為2021/01/01 10:00:00，SQL時(shí)間窗口的表達(dá)式為[@m - 10m, @m)，則實(shí)際的SQL時(shí)間窗口為[2021/01/01 09:50:00, 2021/01/01 10:00:00)。
SQL 計(jì)算的結(jié)果在插入目標(biāo)時(shí)，需要考慮數(shù)據(jù)重復(fù)可能帶來的業(yè)務(wù)影響。對(duì)于 append 模式寫，例如 Scheduled SQL 結(jié)果寫 Logstore，寫入客戶端與 SLS 服務(wù)端實(shí)現(xiàn)了 exactly-once 協(xié)議。對(duì)于 overwrite 模式寫，更容易做到原子性，未來會(huì)規(guī)劃 Scheduled SQL 寫數(shù)據(jù)庫的支持。
2.數(shù)據(jù)的完整性
作業(yè)上設(shè)置延遲執(zhí)行參數(shù)從業(yè)務(wù)上給與指導(dǎo)，在實(shí)例的調(diào)度時(shí)間點(diǎn)上，往后延遲 N 秒才真正開始觸發(fā)實(shí)例運(yùn)行，而實(shí)例查詢的時(shí)間范圍不受延遲參數(shù)影響。例如設(shè)置調(diào)度間隔為每小時(shí)、延遲執(zhí)行為30秒，那么一天生成24個(gè)實(shí)例，其中某實(shí)例的調(diào)度時(shí)間為2021/4/6 12:00:00，執(zhí)行時(shí)間為2021/4/6 12:00:30。這個(gè)設(shè)計(jì)在大部分場景下可以解決數(shù)據(jù)遲到問題，但對(duì)于寫 logstore 存儲(chǔ)（數(shù)據(jù)寫入后將無法更新）來說，完全避免延遲問題是難以實(shí)現(xiàn)的。極端情況下，數(shù)據(jù)遲到問題可通過事后的實(shí)例重試來補(bǔ)結(jié)果。
將 SQL 查詢的時(shí)間窗口按分鐘對(duì)齊（例如整分鐘），以保證在 SLS 索引模型優(yōu)化（batch log-group 組成倒排 doc）時(shí)依然能保證絕對(duì)的計(jì)算準(zhǔn)確。
調(diào)度場景
Scheduled SQL 作業(yè)依次調(diào)度多個(gè)實(shí)例執(zhí)行，無論是正常被調(diào)度還是被動(dòng)異常實(shí)例重試的情況，同時(shí)只有一個(gè)實(shí)例處于運(yùn)行中，不存在多個(gè)實(shí)例并發(fā)執(zhí)行的情況。
在 SLS 數(shù)據(jù)場景下，主要的幾種調(diào)度場景如下：
場景一：實(shí)例延遲執(zhí)行
無論實(shí)例是否延遲執(zhí)行，實(shí)例的調(diào)度時(shí)間都是根據(jù)調(diào)度規(guī)則預(yù)先生成的。雖然前面的實(shí)例發(fā)生延遲時(shí)，可能導(dǎo)致后面的實(shí)例也延遲執(zhí)行，但通過追趕執(zhí)行進(jìn)度，可逐漸減少延遲，直到恢復(fù)準(zhǔn)時(shí)運(yùn)行。
場景二：從某個(gè)歷史時(shí)間點(diǎn)開始執(zhí)行Scheduled SQL作業(yè)
在當(dāng)前時(shí)間點(diǎn)創(chuàng)建Scheduled SQL作業(yè)后，按照調(diào)度規(guī)則對(duì)歷史數(shù)據(jù)進(jìn)行處理，從調(diào)度的開始時(shí)間創(chuàng)建補(bǔ)運(yùn)行的實(shí)例，補(bǔ)運(yùn)行的實(shí)例依次執(zhí)行直到追上數(shù)據(jù)處理進(jìn)度后，再按照預(yù)定計(jì)劃執(zhí)行新實(shí)例。
場景三：固定時(shí)間內(nèi)執(zhí)行Scheduled SQL作業(yè)
如果需要對(duì)指定時(shí)間段的日志做調(diào)度，則可設(shè)置調(diào)度的時(shí)間范圍。如果設(shè)置了調(diào)度的結(jié)束時(shí)間，則最后一個(gè)實(shí)例（調(diào)度時(shí)間小于調(diào)度結(jié)束時(shí)間）執(zhí)行完成后，不再產(chǎn)生新的實(shí)例。
場景四：修改調(diào)度配置對(duì)生成實(shí)例的影響
修改調(diào)度配置后，下一個(gè)實(shí)例按照新配置生成。一般建議同步修改SQL時(shí)間窗口、調(diào)度頻率等配置，使得實(shí)例之間的SQL時(shí)間范圍可以連續(xù)。
場景五：重試失敗的實(shí)例
正常情況下，一個(gè)Scheduled SQL作業(yè)按照調(diào)度時(shí)間的遞增順序生成執(zhí)行實(shí)例。如果實(shí)例執(zhí)行失?。ɡ鐧?quán)限不足、源庫不存在、目標(biāo)庫不存在、SQL語法不合法），系統(tǒng)支持自動(dòng)重試，當(dāng)重試次數(shù)超過您配置的最大重試次數(shù)或重試時(shí)間超過您配置的最大運(yùn)行時(shí)間時(shí)，重試結(jié)束，該實(shí)例狀態(tài)被置為失敗，然后系統(tǒng)繼續(xù)執(zhí)行下一個(gè)實(shí)例。
您可以對(duì)失敗的實(shí)例設(shè)置告警通知并進(jìn)行手動(dòng)重試。您可以對(duì)最近7天內(nèi)創(chuàng)建的實(shí)例進(jìn)行查看、重試操作。調(diào)度執(zhí)行完成后，系統(tǒng)會(huì)根據(jù)實(shí)際執(zhí)行情況變更實(shí)例狀態(tài)為成功或失敗。
Scheduled SQL 在訪問日志上的應(yīng)用
場景需求
在阿里云上，SLB/OSS 的被用到很多的基礎(chǔ)計(jì)算、存儲(chǔ)服務(wù)。在使用過程中如果要得到細(xì)粒度可觀察性，都繞不過訪問日志，在深度使用后您可能會(huì)有體感：
訪問日志與 request 數(shù)一比一關(guān)系，數(shù)據(jù)量很大，造成存儲(chǔ)成本增加并拖慢計(jì)算。
訪問日志有時(shí)效性，近 15 天日志需要交互式查詢分析支持，歷史數(shù)據(jù)需要具備降精度的指標(biāo)查詢能力。
訪問日志有留存的需求，需要長期存儲(chǔ)以備審計(jì)。
整體方案
以 SLB 七層訪問日志為例，這里介紹一種實(shí)踐：
基于 Scheduled SQL 功能，將歷史原文數(shù)據(jù)壓縮為低精度數(shù)據(jù)，支持長期的索引存儲(chǔ)并大大提升分析效率。
根據(jù)業(yè)務(wù)需要，原文數(shù)據(jù)支持全局搜索和無損的 SQL 分析，可以設(shè)置存儲(chǔ)周期為 15天。
歷史數(shù)據(jù)原文投遞到 OSS，支持極低成本存儲(chǔ)，低頻的審計(jì)撈數(shù)據(jù)操作也是方便的。
整體方案圖如下：
OSS投遞操作步驟參考將日志服務(wù)數(shù)據(jù)投遞到OSS。
Scheduled SQL 配置使用增強(qiáng)型資源池，默認(rèn) STS 角色授權(quán)，最終計(jì)算結(jié)果寫同區(qū)域 Logstore：
使用Scheduled SQL時(shí)，建議根據(jù)業(yè)務(wù)情況，同時(shí)兼顧數(shù)據(jù)實(shí)時(shí)性和準(zhǔn)確性。
考慮數(shù)據(jù)上傳日志服務(wù)存在延遲情況，您可以結(jié)合數(shù)據(jù)采集延遲以及業(yè)務(wù)能夠容忍的最大結(jié)果可見延遲，設(shè)置執(zhí)行延遲和SQL時(shí)間窗口（結(jié)束時(shí)間往前一點(diǎn)），避免實(shí)例執(zhí)行時(shí)SQL時(shí)間窗口內(nèi)的數(shù)據(jù)未全部到達(dá)。
建議SQL時(shí)間窗口按分鐘對(duì)齊（例如整分鐘、整小時(shí)），以保證上傳局部亂序數(shù)據(jù)時(shí)的數(shù)據(jù)準(zhǔn)確度。
在這里每分鐘調(diào)度一次 SQL 計(jì)算最近一分鐘窗口的數(shù)據(jù)，并設(shè)置延遲執(zhí)行（如果對(duì)于實(shí)時(shí)性要求不高，建議這個(gè)值設(shè)置大一些）：
Scheduled SQL 寫出到目標(biāo) Logstore 數(shù)據(jù)的結(jié)果如下圖，其中 tag 字段是系統(tǒng)默認(rèn)添加的信息，用于數(shù)據(jù)的搠源。
Scheduled SQL 調(diào)度生成的實(shí)例信息在任務(wù)管理頁面可以查看，對(duì)于失敗的任務(wù)可以做重試。
方案效果
功能體驗(yàn)上：
熱、溫?cái)?shù)據(jù)存儲(chǔ)、分析，支持交互式查詢、分析的能力，保留了靈活性。
冷數(shù)據(jù)分析，支持分鐘粒度的自定義指標(biāo)查詢（例如本文是 host、method、status 維度統(tǒng)計(jì)），可以快速實(shí)現(xiàn)問題分析，同樣查詢范圍延遲降低兩個(gè)數(shù)量級(jí)。
冷數(shù)據(jù)存儲(chǔ)，以壓縮格式投遞到 OSS 存儲(chǔ)，保留了審計(jì)能力。
存儲(chǔ)成本上：在永久存儲(chǔ)的背景下，存儲(chǔ)量降低到之前的 1/1000，OSS 上的壓縮格式存儲(chǔ)且做到極低的單價(jià)。
名稱欄目：ScheduledSQL：SLS大規(guī)模日志上的全局分析與調(diào)度
文章網(wǎng)址：http://m.fisionsoft.com.cn/article/codecee.html
