唯品會IT運維數(shù)據(jù)處理技術(shù)實踐深度分析

前言

在it運維中我們會碰到各種各樣的問題，但有些問題我們經(jīng)常重復(fù)遇到，并且形成了一些提問范式，如：

“有問題或故障發(fā)生嗎？”，這個提問轉(zhuǎn)換成數(shù)學(xué)問題就是建立“異常檢測”模型；

當(dāng)我們確認(rèn)有問題時，我們本能地會問“哪里出了問題”，這便是一個“根因分析”問題；

對于一家電商公司來說，促銷前總是要對線上系統(tǒng)進行容量評估和擴容，這里便有一個“預(yù)測”模型需要被建立；

當(dāng)我們每做完一個項目，需要對項目需要達成的目標(biāo)進行定量的評估，這便是一個“績效分析”的問題。

目前各類數(shù)學(xué)模型的輸出在我們的具體工作中主要被用作輔助決策來使用，有兩個原因使我們還不能直接把結(jié)果自動地用于決策：一是我們對數(shù)據(jù)的使用能力還不能做到面面俱到，很多業(yè)務(wù)知識還無法用算法描述；二是算法的輸出結(jié)果一般都是有概率的，在很多需要“絕對正確”的場合只能作為參考。在實際工作中，算法和業(yè)務(wù)規(guī)則庫都會進行建設(shè)，用來幫助it運維人員更容易和正確地做出決定。

講師介紹

吳曉光，唯品會it運維部開發(fā)經(jīng)理、20年一線奮斗經(jīng)驗，10年以上互聯(lián)網(wǎng)企業(yè)it運維領(lǐng)域研發(fā)經(jīng)驗。曾在騰訊、卓望、唯品會等互聯(lián)網(wǎng)公司任職，對數(shù)據(jù)在it運維領(lǐng)域的應(yīng)用有著深刻的理解，現(xiàn)致力于唯品會智能化it運維平臺的建設(shè)工作。

It運維數(shù)據(jù)處理技術(shù)應(yīng)用

對于數(shù)據(jù)處理技術(shù)來說，我們主要是需要解決以下五個方面的問題：

數(shù)據(jù)的準(zhǔn)確性、及時性

海量數(shù)據(jù)的實時計算

多維數(shù)據(jù)的實時監(jiān)控

多維數(shù)據(jù)的展示

A/B測試實現(xiàn)方法

這里有些問題在行業(yè)里已有比較成熟的解決方案，有些可能就不是每個公司都會碰到。

今天就看唯品會的數(shù)據(jù)采集，對唯品會來說，我們主要是兩類數(shù)據(jù)，一類是日志數(shù)據(jù)，一類是數(shù)據(jù)庫數(shù)據(jù)。

對于it運維日志數(shù)據(jù)來說，我們有兩類采集，一類是客戶端的日志采集，一類是服務(wù)器端的日志采集。對于服務(wù)器端的日志采集，實際上是比較簡單的，一般來說就是落到本地盤之后，通過Flume傳送到公司的Kafka集群，然后大家在上面消費。對于客戶端行為的采集，分成兩種，一種是Web端的采集，一般來說就是通過異步請求在Nginx上落日志；第二個是APP端的采集，一般是通過一個接口調(diào)用的方式，把這些數(shù)據(jù)落到服務(wù)端，再由服務(wù)端把這個數(shù)據(jù)收集起來。對于數(shù)據(jù)庫的采集，實際上我們也是有兩種方法的，一種是直接在從庫上來做這種指標(biāo)的計算，還有一種就是對于復(fù)雜的應(yīng)用，我們會把DB的Binlog做一些解析，解析完了之后放到一個消息總線上，實際上就放到Kafka上，然后讓大家來進行一個消費，每個應(yīng)用都是根據(jù)自己的特點，重構(gòu)自己的數(shù)據(jù)結(jié)構(gòu)。有些會還原數(shù)據(jù)庫，有些就直接用消息來計算指標(biāo)，具體要根據(jù)情況進行分析。

It運維數(shù)據(jù)計算是比較重要的一環(huán)，實際上要兼顧性能和靈活性兩個方面。對it運維日志的處理，會有一個日志解析程序來消費Kafka的消息，“日志解析”實現(xiàn)一個實時ETL的過程，我們會根據(jù)配置（基本配置也跟ETL差不多）去生成預(yù)定義的標(biāo)準(zhǔn)格式，后續(xù)就交給Spark做聚合。“日志解析”由于日志之間沒有相關(guān)性，可以Map之后并行計算，吞吐量和資源的投入是成正比的，這樣效率就沒有什么太多的問題。

對于Spark的聚合配置，一般來說我們會把日志解析完的數(shù)據(jù)進行定義，定義各個字段是維度或是指標(biāo)，然后會做一個全維度的聚合。這里面實際上也是有個要求的，我們要求所有的指標(biāo)在各個維度上都具有累加性，如果不具備累加性（比如百分比這種指標(biāo)），我們在Spark里是不做聚合的，只是在展現(xiàn)的時候重新計算。計算好的數(shù)據(jù)會放到一個OLAP和MOLAP的數(shù)據(jù)庫里。

還有一種情況，是通過腳本在數(shù)據(jù)庫從庫上直接進行指標(biāo)的計算，一般用于只有時間維度的指標(biāo)計算，配置好的計算腳本，我們會用公司開源的一個產(chǎn)品Saturn來進行一個分布式調(diào)度。Saturn這個東西還是不錯的，推薦大家去嘗試一下。對于日志的詳細(xì)查詢，我們還是放到ES里，通過全文檢索的方式來查詢。

It運維數(shù)據(jù)展現(xiàn)是最終的結(jié)果輸出，實際工作中，我們對結(jié)果數(shù)據(jù)的查詢效率要求比較嚴(yán)苛。因為這些結(jié)果數(shù)據(jù)不僅用于前端，還用于告警輸出等各個方面。對于告警的數(shù)據(jù)我們需要做到毫秒級響應(yīng)，前端界面一般要求是在3秒內(nèi)渲染完成。為了完成這個要求，我們構(gòu)建了一個ROLAP數(shù)據(jù)庫，還有一個MOLAP的數(shù)據(jù)庫，在ROLAP的數(shù)據(jù)庫里，一般只存當(dāng)天的多維數(shù)據(jù)，而在MOLAP的數(shù)據(jù)庫里，會存歷史數(shù)據(jù)。對于MOLAP數(shù)據(jù)庫的檢索，由于應(yīng)用主要是切片方面的需求，基本上都是K-value模式的一個檢索，所以它比較快。MySQL里一般是存放單維度指標(biāo)，應(yīng)該這么講，它不是多維數(shù)據(jù)。Redis緩沖里，一般會存放我們的秒級數(shù)據(jù)，還有一些配置信息。這個架構(gòu)中，最后通過Application  Server進行一個數(shù)據(jù)的整合，來滿足前端數(shù)據(jù)的一個展示要求。

以上就是我們對it運維數(shù)據(jù)應(yīng)用在未來一個時期內(nèi)的定義，也是想在未來大約半年到一年能夠看到更多成果的一個實踐。今天分享就到這里，謝謝大家！