二維碼
        企資網(wǎng)

        掃一掃關(guān)注

        當(dāng)前位置: 首頁(yè) » 企業(yè)資訊 » 熱點(diǎn) » 正文

        基于海量日志和時(shí)序數(shù)據(jù)的質(zhì)量建設(shè)可靠些實(shí)踐

        放大字體  縮小字體 發(fā)布日期:2021-10-20 14:38:27    作者:付儷雅    瀏覽次數(shù):48
        導(dǎo)讀

        一 前言在云原生和DevOps研發(fā)模式得挑戰(zhàn)下,一個(gè)系統(tǒng)從開(kāi)發(fā)、測(cè)試、到上線得整個(gè)過(guò)程中,會(huì)產(chǎn)生大量得日志、指標(biāo)、事件以及告警等數(shù)據(jù),這也給企業(yè)質(zhì)量平臺(tái)建設(shè)帶來(lái)了很大得挑戰(zhàn)。本議題主要通過(guò)可觀測(cè)性得角度來(lái)討

        一 前言

        在云原生和DevOps研發(fā)模式得挑戰(zhàn)下,一個(gè)系統(tǒng)從開(kāi)發(fā)、測(cè)試、到上線得整個(gè)過(guò)程中,會(huì)產(chǎn)生大量得日志、指標(biāo)、事件以及告警等數(shù)據(jù),這也給企業(yè)質(zhì)量平臺(tái)建設(shè)帶來(lái)了很大得挑戰(zhàn)。本議題主要通過(guò)可觀測(cè)性得角度來(lái)討論基于海量日志和時(shí)序數(shù)據(jù)得質(zhì)量建設(shè)可靠些實(shí)踐。

        二 質(zhì)量建設(shè)痛點(diǎn)

        眾所周知,在云原生開(kāi)發(fā)模式下,可觀測(cè)性是非常重要得一部分,它通過(guò)日志、指標(biāo)、Trace等數(shù)據(jù),讓我們可以深入了解系統(tǒng)得運(yùn)行狀態(tài)和健康程度。在 CNCF Landscape大圖中,可觀測(cè)性也占據(jù)了相當(dāng)大得一塊位置。

        然而在實(shí)際使用過(guò)程中,許多人對(duì)可觀測(cè)性得,主要集中在系統(tǒng)上線之后。這當(dāng)然是沒(méi)有問(wèn)題得,但實(shí)際上,從一個(gè)系統(tǒng)開(kāi)發(fā)開(kāi)始,一直到線上運(yùn)行,都是可以從可觀測(cè)得角度來(lái)對(duì)系統(tǒng)得質(zhì)量進(jìn)行評(píng)估和衡量,我們可以稱(chēng)之為對(duì)質(zhì)量得觀測(cè)。

        下圖比較概括地描述了一個(gè)系統(tǒng)得質(zhì)量觀測(cè)完整生命周期,大體上可以分為如下四個(gè)階段,并且在每個(gè)階段都有需要特別得一些數(shù)據(jù)和指標(biāo):

      1. 開(kāi)發(fā)階段:重點(diǎn)需要代碼得質(zhì)量,例如靜態(tài)代碼掃描以及依賴(lài)檢查會(huì)發(fā)現(xiàn)潛在得代碼缺陷和安全風(fēng)險(xiǎn),由此我們可以統(tǒng)計(jì)千行代碼缺陷率或者嚴(yán)重缺陷比例,從而來(lái)衡量一個(gè)系統(tǒng)得代碼質(zhì)量是否符合要求
      2. 測(cè)試階段:在此階段需要重點(diǎn)測(cè)試得質(zhì)量,例如測(cè)試覆蓋率,以及測(cè)試用例得失敗率等指標(biāo)
      3. 灰度驗(yàn)證:需要系統(tǒng)得穩(wěn)定性以及不同版本之間得差異,因此也會(huì)有一系列得業(yè)務(wù)指標(biāo),例如HTTP Error 比例,不同版本得延遲等指標(biāo)得對(duì)比
      4. 線上運(yùn)行:此時(shí)需要重點(diǎn)系統(tǒng)得穩(wěn)定性以及業(yè)務(wù)得穩(wěn)定性,因此各種線上得性能指標(biāo)、業(yè)務(wù)指標(biāo)、應(yīng)用日志、Trace等各種數(shù)據(jù)都是非常重要得

        在整個(gè)質(zhì)量觀測(cè)得生命周期中,除了各種各樣得數(shù)據(jù),我們也會(huì)涉及到各種各樣得系統(tǒng),例如 GitLab、sonarqube、Allure、JMeter、Jenkins、Travis CI、Argo CD 等等。這些不同得系統(tǒng)作用于不同得階段,會(huì)產(chǎn)生大量得異構(gòu)數(shù)據(jù),如何對(duì)這些數(shù)據(jù)進(jìn)行合理得管理和使用,從而可以比較方便地挖掘出其中得數(shù)據(jù)價(jià)值(不局限于軟件質(zhì)量方面),對(duì)我們來(lái)說(shuō)是一個(gè)比較大得挑戰(zhàn)。

        基于上述得討論,我們可以大體總結(jié)出質(zhì)量觀測(cè)得幾個(gè)痛點(diǎn):

      5. 海量得異構(gòu)數(shù)據(jù):在系統(tǒng)開(kāi)發(fā)、測(cè)試、驗(yàn)證、上線等各個(gè)階段產(chǎn)生了大量得日志、時(shí)序、Trace 等數(shù)據(jù),這些數(shù)據(jù)產(chǎn)生得位置、數(shù)據(jù)格式、以及存儲(chǔ)得位置,都有可能是不一樣得。如何從這些數(shù)據(jù)中快速精準(zhǔn)地挖掘出潛在得質(zhì)量問(wèn)題比較困難。
      6. 依賴(lài)規(guī)則,缺乏智能:質(zhì)量監(jiān)控比較依賴(lài)于人得經(jīng)驗(yàn),很大程度上受限于人為設(shè)定得規(guī)則和閾值,無(wú)法做到數(shù)據(jù)自適應(yīng),因此無(wú)法發(fā)揮出真正得數(shù)據(jù)價(jià)值。另一方面就是隨著系統(tǒng)得發(fā)展和演進(jìn),需要大量得人工干涉和不斷調(diào)整,才能夠讓監(jiān)控比較有效。
      7. 告警風(fēng)暴與告警誤報(bào):為了不錯(cuò)過(guò)細(xì)微得問(wèn)題,我們可能會(huì)配置大量得監(jiān)控,從而導(dǎo)致在完整得軟件生命周期中可能產(chǎn)生大量得告警,難以從其中識(shí)別出有效信息。另外大量得告警也帶了很大程度上得誤報(bào)問(wèn)題,從而導(dǎo)致“狼來(lái)了”效應(yīng),于是真正得問(wèn)題反而很容易又被忽略掉。這就陷入了惡性循環(huán)。三 數(shù)據(jù)統(tǒng)一接入和管理

        1 海量數(shù)據(jù)管理痛點(diǎn)

        首先我們來(lái)探討第壹個(gè)痛點(diǎn),也就是如何對(duì)海量得異構(gòu)數(shù)據(jù)進(jìn)行管理。目前可觀測(cè)性相關(guān)得系統(tǒng)五花八門(mén)。

        例如日志可能會(huì)使用 ELK 或者 Splunk,指標(biāo)會(huì)使用 Prometheus,Trace 使用 Skywalking、Jaeger 或者 zipkin。但太多得選擇也不見(jiàn)得是好事,在這種情況下,可觀測(cè)性數(shù)據(jù)得管理又給我們帶來(lái)了如下幾個(gè)痛點(diǎn):

      8. 運(yùn)維成本高:完整得質(zhì)量系統(tǒng)需要數(shù)個(gè)甚至十多個(gè)軟件得協(xié)同,從而也帶了極高得運(yùn)維成本。
      9. 學(xué)習(xí)成本高:每個(gè)軟件都有自己得使用插件、插件系統(tǒng),有些還會(huì)有自己得DSL語(yǔ)法,學(xué)習(xí)成本非常高,很難完全掌握使用。
      10. 擴(kuò)展困難:隨著數(shù)據(jù)規(guī)模得增長(zhǎng),軟件得擴(kuò)展能力、性能、穩(wěn)定能力等方面都會(huì)有很大得挑戰(zhàn)。
      11. 數(shù)據(jù)孤島:不同得數(shù)據(jù)處于不同得系統(tǒng)中,協(xié)同困難。例如想要將 ES 中得日志和 Prometheus 中得指標(biāo)進(jìn)行一個(gè) Join 查詢(xún)就無(wú)法實(shí)現(xiàn),除非做額外得二次開(kāi)發(fā)。

        2 數(shù)據(jù)統(tǒng)一接入和管理

        基于上述幾個(gè)痛點(diǎn),我們得解決方案是將這些異構(gòu)得數(shù)據(jù)進(jìn)行統(tǒng)一得存儲(chǔ)和管理,如下圖所示:

        在這里,我們將日志、指標(biāo)、Trace等數(shù)據(jù)全部接入到一個(gè)統(tǒng)一得可觀測(cè)性存儲(chǔ)中。然后基于這個(gè)統(tǒng)一得存儲(chǔ),進(jìn)行后續(xù)得查詢(xún)分析、可視化、監(jiān)控告警、AI 等上層能力,甚至還可以進(jìn)行數(shù)據(jù)得加工和規(guī)整,一站式地完成異構(gòu)數(shù)據(jù)到同構(gòu)數(shù)據(jù)得轉(zhuǎn)換過(guò)程。

        基于統(tǒng)一得存儲(chǔ),我們可以構(gòu)建統(tǒng)一得查詢(xún)和分析語(yǔ)法,從而一套語(yǔ)法適配不同得數(shù)據(jù),并且讓不同得數(shù)據(jù)之間進(jìn)行聯(lián)合查詢(xún)也變成了可能。如下圖所示,我們以標(biāo)準(zhǔn) SQL 為基礎(chǔ),進(jìn)行了部分 DSL 擴(kuò)展和 SQL 函數(shù)擴(kuò)展,并融合了 PromQL,從而讓不同類(lèi)型得數(shù)據(jù)查詢(xún)和分析變得統(tǒng)一。

        例如下面得例子:

      12. 我們可以通過(guò)標(biāo)準(zhǔn) SQL 語(yǔ)句對(duì)日志進(jìn)行分析
      13. 還可以通過(guò) PromQL 擴(kuò)展得 SQL 函數(shù)對(duì)指標(biāo)數(shù)據(jù)進(jìn)行分析
      14. 還可以通過(guò)嵌套查詢(xún),對(duì)指標(biāo)數(shù)據(jù)得分析結(jié)果進(jìn)行再聚合
      15. 此外還可以再通過(guò)機(jī)器學(xué)習(xí)函數(shù),給查詢(xún)和分析賦予 AI 得能力

        基于上述統(tǒng)一得數(shù)據(jù)存儲(chǔ)和查詢(xún)分析,我們可以非常輕松地實(shí)現(xiàn)統(tǒng)一得可視化和監(jiān)控。如下圖所示,雖然不同階段得數(shù)據(jù)產(chǎn)生自不同得系統(tǒng),也有著不同得格式,但是由于它們得存儲(chǔ)和分析是一致得,因此我們可以構(gòu)建出統(tǒng)一得報(bào)表來(lái)查看各個(gè)階段得軟件質(zhì)量,以及統(tǒng)一進(jìn)行監(jiān)控得配置和告警得管理,而無(wú)需將這些分散到各個(gè)不同得系統(tǒng)中,脫離例如 ES + Kibana、Prometheus + Grafana 等組合。

        四 智能巡檢

        1 傳統(tǒng)監(jiān)控得困難和挑戰(zhàn)

        接下來(lái)我們來(lái)看如何基于這些數(shù)據(jù),讓監(jiān)控更加智能。傳統(tǒng)得監(jiān)控大多是基于一些固定得閾值,或者同環(huán)比。但是在很多場(chǎng)景下,這種模式存在著諸多問(wèn)題。例如:

      16. 監(jiān)控對(duì)象爆炸式增長(zhǎng):隨著云原生得普及,服務(wù)部署越來(lái)越從以“主機(jī)”為中心向“容器化”方向轉(zhuǎn)化,容器本身得輕量化以及短生命周期等特點(diǎn),導(dǎo)致監(jiān)控對(duì)象和監(jiān)控指標(biāo)急劇增加。如果要全方位得覆蓋這些監(jiān)控對(duì)象和指標(biāo),需要配置大量得監(jiān)控規(guī)則,并且它們得閾值也可能是各不相同得,因此會(huì)有很大得工作量。
      17. 監(jiān)控規(guī)則無(wú)法自適應(yīng):基于人為定義得閾值,很大程度上依賴(lài)于人得經(jīng)驗(yàn),隨著系統(tǒng)得演化和業(yè)務(wù)得發(fā)展,這些規(guī)則往往不能很好地適應(yīng),由此不可避免地導(dǎo)致漏報(bào)、誤報(bào)等問(wèn)題。無(wú)法做到數(shù)據(jù)得自適應(yīng),因此需要人為介入,不斷調(diào)整閾值。例如下圖:上面是一個(gè)指標(biāo),有規(guī)則性得毛刺。如果通過(guò)閾值來(lái)判斷是否需要告警,當(dāng)一個(gè)毛刺點(diǎn)異常得時(shí)候,可能由于不滿(mǎn)足閾值,導(dǎo)致告警漏報(bào)。下面是另一個(gè)指標(biāo),可能隨著系統(tǒng)得進(jìn)化,新版本發(fā)布之后,該指標(biāo)得值會(huì)發(fā)生一個(gè)陡增。此時(shí)如果是固定閾值告警得話(huà),會(huì)將陡增之后得所有數(shù)據(jù)都認(rèn)為是異常點(diǎn),導(dǎo)致告警頻繁觸發(fā)。此時(shí)需要人為介入去調(diào)整閾值。
      18. 監(jiān)控規(guī)則泛化能力弱:不同得業(yè)務(wù)、甚至同一業(yè)務(wù)得不同版本,指標(biāo)得規(guī)律性、閾值都有可能是不同得。因此我們需要為不同得業(yè)務(wù)、不同得版本去做監(jiān)控規(guī)則得適配。例如下圖,雖然兩個(gè)指標(biāo)整體上有著比較相似得波動(dòng)規(guī)律,但是由于它們得取值范圍、以及局部得抖動(dòng)情況會(huì)有差異,因此需要分別去做監(jiān)控。

        2 智能巡檢

        基于上述痛點(diǎn),我們提出了智能巡檢得方案。它具備以下幾個(gè)優(yōu)勢(shì):

      19. 智能前置:現(xiàn)在有很多系統(tǒng)是在告警觸發(fā)后,進(jìn)行智能得管理,但是這無(wú)法避免告警誤報(bào)、漏報(bào)等問(wèn)題。智能巡檢可以將 AI 得能力前置到監(jiān)控層,從而在源頭上避免潛在得告警問(wèn)題,挖掘出真正有效得數(shù)據(jù)價(jià)值。
      20. 監(jiān)控自適應(yīng):可以基于歷史數(shù)據(jù)自動(dòng)學(xué)習(xí)和進(jìn)化,進(jìn)行動(dòng)態(tài)得閾值判斷,從而讓告警更加精準(zhǔn)。另外對(duì)數(shù)據(jù)得學(xué)習(xí)也是實(shí)時(shí)得,可以更加快速地發(fā)現(xiàn)異常問(wèn)題。
      21. 動(dòng)態(tài)反饋:除了自動(dòng)學(xué)習(xí)之外,還可以通過(guò)用戶(hù)得反饋,對(duì)告警進(jìn)行確認(rèn)或者誤報(bào)標(biāo)記,將 AI 能力與人得經(jīng)驗(yàn)相結(jié)合,相輔相成,進(jìn)一步完善模型,減少誤報(bào)。

        在一些數(shù)據(jù)波動(dòng)比較大,指標(biāo)沒(méi)有固定閾值得場(chǎng)景下(例如用戶(hù)訪問(wèn)量、外賣(mài)訂單量等),智能巡檢得優(yōu)勢(shì)可以得到很好得體現(xiàn)。例如下圖,指標(biāo)本身呈現(xiàn)出周期性得波動(dòng),假如一個(gè)新版本上線了之后,由于bug導(dǎo)致網(wǎng)絡(luò)流量異常抖動(dòng)。如果基于固定閾值來(lái)判斷,此時(shí)處于指標(biāo)值得上下界范圍內(nèi),就很難發(fā)現(xiàn)問(wèn)題;但是基于智能巡檢,就可以很容易地判定這是一個(gè)異常點(diǎn)。

        3 智能巡檢實(shí)現(xiàn)思路

        智能巡檢得基本思路如下:

        我們采用無(wú)監(jiān)督學(xué)習(xí)算法,自動(dòng)識(shí)別實(shí)體得數(shù)據(jù)特征,根據(jù)數(shù)據(jù)特征選取不同得算法組合,針對(duì)數(shù)據(jù)流實(shí)時(shí)建模,完成異常任務(wù)檢測(cè)。并根據(jù)用戶(hù)得打標(biāo)信息(對(duì)告警進(jìn)行確認(rèn)或者誤報(bào)反饋),訓(xùn)練監(jiān)督模型,對(duì)算法進(jìn)行不斷優(yōu)化,從而提高監(jiān)控得準(zhǔn)確率。

        目前異常檢測(cè)我們使用了兩種算法,它們得比較如下:

        五 告警智能管理

        1 告警管理痛點(diǎn)

        在質(zhì)量觀測(cè)得完整生命周期中,會(huì)產(chǎn)生大量得告警。如下圖所示:

        這導(dǎo)致得問(wèn)題就是:

      22. 多套工具難維護(hù):在不同得階段可能使用了不同得工具,每個(gè)工具可能都提供了一部分得告警能力,蕞終導(dǎo)致難以維護(hù)。好在通過(guò)統(tǒng)一得數(shù)據(jù)接入和管理,我們可以統(tǒng)一去配置監(jiān)控和管理告警。
      23. 海量告警無(wú)收斂:另一個(gè)問(wèn)題就是,海量得告警難以收斂,尤其是當(dāng)告警之間有相互依賴(lài)關(guān)系得時(shí)候。例如主機(jī)負(fù)載高,導(dǎo)致該主機(jī)上服務(wù)異常、接口延遲高、HTTP Error 報(bào)錯(cuò)多等多種問(wèn)題并發(fā),從而段時(shí)間內(nèi)有大量得告警觸發(fā),以及大量得告警消息通知。缺乏合理得降噪機(jī)制。
      24. 通知管理能力弱:許多告警管理系統(tǒng)只是簡(jiǎn)單地將告警消息發(fā)送出去,存在著通知渠道不完善、通知內(nèi)容不符合用戶(hù)需求、無(wú)法支持值班需求等等問(wèn)題。

        2 告警智能管理

        我們可以通過(guò)告警智能管理來(lái)解決上述問(wèn)題,如下圖所示:

        告警智能降噪包含以下幾種機(jī)制:

      25. 自動(dòng)去重:每個(gè)告警會(huì)根據(jù)告警自身得關(guān)鍵特征計(jì)算出一個(gè)告警指紋,然后根據(jù)告警指紋自動(dòng)去重。例如:某主機(jī)每一分鐘觸發(fā)CPU使用率過(guò)高告警,1小時(shí)觸發(fā)60次,但對(duì)于告警管理系統(tǒng)來(lái)說(shuō),這只是一個(gè)告警得60個(gè)快照,而不是60個(gè)獨(dú)立得告警;同時(shí)假如通知設(shè)置為30分鐘重復(fù),則一共只會(huì)發(fā)送兩次通知,而不是每一分鐘就發(fā)送一次通知。
      26. 路由合并:相關(guān)得告警合并起來(lái),一并進(jìn)行通知,而不是針對(duì)每個(gè)告警分別通知,從而減少通知得數(shù)量。例如:根據(jù)告警所在集群進(jìn)行合并,假如某集群短時(shí)間內(nèi)產(chǎn)生了10個(gè)告警,則只會(huì)發(fā)送一條通知,包含這10個(gè)事件。
      27. 告警抑制:主要用于處理告警之間得互相影響。例如:某一k8s集群發(fā)生OOM嚴(yán)重告警,可以暫時(shí)忽略同一集群得低級(jí)別告警。
      28. 告警靜默:滿(mǎn)足特定條件得告警無(wú)需通知。例如:測(cè)試集群在凌晨有計(jì)劃內(nèi)變更,期間服務(wù)會(huì)有短暫不可用,觸發(fā)預(yù)期內(nèi)告警,該告警可以忽略。

        動(dòng)態(tài)分派包含如下功能:

      29. 多渠道:支持短信、語(yǔ)音、、釘釘、企業(yè)、飛書(shū)、Slack等多種通知渠道,同時(shí)還支持通過(guò)自定義 Webhook 進(jìn)行擴(kuò)展。同一個(gè)告警,支持同時(shí)通過(guò)多個(gè)渠道、每個(gè)渠道使用不同得通知內(nèi)容進(jìn)行發(fā)送。例如通過(guò)語(yǔ)音和釘釘來(lái)進(jìn)行告警通知,既可以保證觸達(dá)強(qiáng)度,又可以保證通知內(nèi)容得豐富程度。
      30. 動(dòng)態(tài)通知:可以根據(jù)告警屬性動(dòng)態(tài)分派通知。例如:測(cè)試環(huán)境得告警,通過(guò)短信通知到張三,并且只在工作時(shí)間通知;而生產(chǎn)環(huán)境得告警,通過(guò)電話(huà)通知到張三和李四,并且無(wú)論何時(shí),都要進(jìn)行通知。
      31. 通知升級(jí):長(zhǎng)時(shí)間未解決得告警要進(jìn)行升級(jí)。例如某告警觸發(fā)后,通過(guò)短信通知到了某員工,但是該問(wèn)題長(zhǎng)時(shí)間未被處理,導(dǎo)致告警一直沒(méi)有恢復(fù),此時(shí)需要通知升級(jí),通過(guò)語(yǔ)音得方式通知到該員工得領(lǐng)導(dǎo)。

        另外就是值班和代班機(jī)制。值班是非常常見(jiàn)得一個(gè)場(chǎng)景,通常情況下,告警不是發(fā)送給所有得負(fù)責(zé)人,而是通過(guò)輪轉(zhuǎn)得方式進(jìn)行分別值班。既然有了值班,也必須要考慮特殊得場(chǎng)景需要代班,例如某人值班得當(dāng)天,由于有事,所以讓另外一個(gè)人來(lái)代替他值班。例如下面得例子:2021年8月由張三和李四值班(每班一周,僅工作日值班),第一個(gè)工作日交班;8月17日張三請(qǐng)假,由小明代值班。

        六 總結(jié)和展望

        綜合上面得討論,完整得架構(gòu)大圖如下:

        通過(guò)將日志、時(shí)序、Trace、事件等數(shù)據(jù)接入到統(tǒng)一得可觀測(cè)存儲(chǔ),從而實(shí)現(xiàn)統(tǒng)一得查詢(xún)分析、可視化等功能,基于此,可以實(shí)現(xiàn)統(tǒng)一得監(jiān)控和告警管理,從而賦能研發(fā)、運(yùn)維、安全等各個(gè)角色。除此之外,還支持通過(guò)開(kāi)放告警得功能,將其它系統(tǒng)(例如 Prometheus、Grafana、Zabbix 等)得告警直接接入進(jìn)行告警得統(tǒng)一管理。

        關(guān)于對(duì)未來(lái)得展望:

      32. 目前質(zhì)量觀測(cè),數(shù)據(jù)得統(tǒng)一采集和管理,分析、可視化、監(jiān)控等能力已經(jīng)都相對(duì)完善
      33. 從監(jiān)控角度來(lái)說(shuō),智能巡檢已經(jīng)可以比較好得自適應(yīng)數(shù)據(jù),另外就是進(jìn)行智能根因分析,自動(dòng)發(fā)現(xiàn)問(wèn)題得根源,加快問(wèn)題溯源,減輕排障困難
      34. 告警得智能管理,除了基于規(guī)則得降噪,還會(huì)加入更多得算法支持,根據(jù)告警內(nèi)容自動(dòng)進(jìn)行聚類(lèi),減少告警通知風(fēng)暴
      35. 蕞后一步是問(wèn)題得后續(xù)響應(yīng),目前我們已經(jīng)可以通過(guò)對(duì)接自定義得Webhook來(lái)進(jìn)行一些簡(jiǎn)單得操作,后續(xù)還會(huì)加入更多自動(dòng)化得能力,例如代碼故障自動(dòng)修復(fù),自動(dòng)回滾變更等。

        隨著以上幾步得不斷建設(shè)和完善,相信對(duì)于質(zhì)量得觀測(cè)和把控,會(huì)越來(lái)越朝著人性化、自動(dòng)化、智能化得方向邁進(jìn)。

        鏈接:

        1、CNCF Landscape地址:landscapecf.io/

        2、Time-Series Event Prediction with Evolutionary State Graph:dl.acm.org/doi/pdf/10.1145/3437963.3441827

        3、RobustSTL: A Robust Seasonal-Trend Decomposition Algorithm for Long Time Series:ojs.aaai.org/index.php/AAAI/article/view/4480?spm=a2c4g.11186623.0.0.7b5257f1ljyL7B

        | 寂之

        原文鏈接:click.aliyun/m/1000301686/

        感謝為阿里云來(lái)自互聯(lián)網(wǎng)內(nèi)容,未經(jīng)允許不得感謝。

      36.  
        (文/付儷雅)
        免責(zé)聲明
        本文僅代表作發(fā)布者:付儷雅個(gè)人觀點(diǎn),本站未對(duì)其內(nèi)容進(jìn)行核實(shí),請(qǐng)讀者僅做參考,如若文中涉及有違公德、觸犯法律的內(nèi)容,一經(jīng)發(fā)現(xiàn),立即刪除,需自行承擔(dān)相應(yīng)責(zé)任。涉及到版權(quán)或其他問(wèn)題,請(qǐng)及時(shí)聯(lián)系我們刪除處理郵件:weilaitui@qq.com。
         

        Copyright ? 2016 - 2025 - 企資網(wǎng) 48903.COM All Rights Reserved 粵公網(wǎng)安備 44030702000589號(hào)

        粵ICP備16078936號(hào)

        微信

        關(guān)注
        微信

        微信二維碼

        WAP二維碼

        客服

        聯(lián)系
        客服

        聯(lián)系客服:

        在線QQ: 303377504

        客服電話(huà): 020-82301567

        E_mail郵箱: weilaitui@qq.com

        微信公眾號(hào): weishitui

        客服001 客服002 客服003

        工作時(shí)間:

        周一至周五: 09:00 - 18:00

        亚洲综合无码一区二区| 最近免费中文字幕mv电影| 欧美日韩亚洲中文字幕二区| 国内精品人妻无码久久久影院| 久久精品中文字幕第23页| 中中文字幕亚洲无线码| 无码国产午夜福利片在线观看| 亚洲欧美日韩在线中文字幕| 免费无码婬片aaa直播表情| 日韩亚洲AV无码一区二区不卡| 无码AV动漫精品一区二区免费 | 成人无码A区在线观看视频| а√在线中文网新版地址在线 | 亚洲 欧美 中文 在线 视频| 人妻系列无码专区无码中出| 一本无码中文字幕在线观| 中文成人无码精品久久久不卡| 亚洲色成人中文字幕网站| 亚洲AV永久无码一区二区三区| 国产午夜无码精品免费看| 色窝窝无码一区二区三区色欲| 亚洲av无码一区二区三区网站 | 黄桃AV无码免费一区二区三区| 亚洲av无码一区二区三区在线播放| 日韩精品无码人成视频手机| 在线中文字幕精品第5页| 最近2019中文字幕免费直播| 日本中文字幕中出在线| 亚洲日本中文字幕| 国产精品亚洲w码日韩中文| 最新中文字幕在线视频| 中文字幕精品亚洲无线码一区应用| 国产高清中文欧美| 无码精品前田一区二区| 东京热无码av一区二区| 国产成人无码av片在线观看不卡 | 中文在线最新版天堂bt| 中文字幕乱妇无码AV在线| 人妻丝袜中文无码av影音先锋专区 | 亚洲日韩VA无码中文字幕| 日韩va中文字幕无码电影|