《平安證券劉宏霞：教你如何保障大數(shù)據(jù)質(zhì)量》要點：
本文介紹了平安證券劉宏霞：教你如何保障大數(shù)據(jù)質(zhì)量，希望對您有用。如果有疑問，可以聯(lián)系我們。

作者簡介：

劉宏霞

平安證券 大數(shù)據(jù)測試組負責(zé)人

2014年加入平安證券,正值互聯(lián)網(wǎng)金融潮流興起,組織并參與大數(shù)據(jù)自動化以及監(jiān)控體系的搭建、應(yīng)用和優(yōu)化.熟悉券商核心業(yè)務(wù),對數(shù)據(jù)有著濃厚的興趣,并把相關(guān)的技術(shù)應(yīng)用到數(shù)據(jù)質(zhì)量上,不斷地探索券商數(shù)據(jù)質(zhì)量之路.

前言

這兩年對于大數(shù)據(jù)來講,大家看到有很多產(chǎn)品出來,很多公司也在利用數(shù)據(jù)做些東西,包括現(xiàn)在的一些電影.

前兩天的時候,同事給我推薦一部叫做《庭審專家》的美劇,大概花了一天時間把它看完,故事講的很簡單：在美國庭審當中包含陪審團概念,通過大數(shù)據(jù)分析陪審團行為模式,然后預(yù)測他們的想法.這樣來講,大數(shù)據(jù)應(yīng)用完全掌握在擁有數(shù)據(jù)的人身上.

那如果數(shù)據(jù)質(zhì)量本身存在問題,就會導(dǎo)致數(shù)據(jù)分析出現(xiàn)誤差,甚至錯誤的預(yù)測或者誤導(dǎo)性的描述.所以今天我給大家分享的主題是券商的大數(shù)據(jù)保障之道 .

在分享券商大數(shù)據(jù)保障之道之前,我們先看一下平安證券在大數(shù)據(jù)方面都做了哪些.

1、平安大數(shù)據(jù)做些什么

經(jīng)常使用平安證券 APP 炒股的人會發(fā)現(xiàn),我們平安證券 App 過去一年變化非常大,在剛剛過去不久,由證券日報主辦的第十二屆證券市場年會中,我們平安證券 App 被評為最佳金融 App 大獎.

我們?yōu)橛脩籼峁﹤€性化的服務(wù),比如 App 功能上有一些千人千面,猜你喜歡的內(nèi)容,推送的一些功能.其中包括資產(chǎn)收益的功能,這些數(shù)據(jù)是來自用戶大數(shù)據(jù),幫助更好為用戶推薦產(chǎn)品,也幫助用戶更方便獲取信息.

在行情方面我們也會做一些股價預(yù)警,智能選股等等,可以幫助用戶化繁為簡,準確操盤.另外是我們的資訊,炒股人都知道,資訊很重要,幫助用戶獲取最新、最全的金融資訊.

我們還有大數(shù)據(jù)產(chǎn)品,比如牛人牛股,幫助用戶追蹤牛人們在買賣什么股票.還有收益類的計算器,輔助客戶進行投資決策.

另外比如客戶不知道要買股票還是買基金,或者買其他產(chǎn)品,我們也會提供智能化服務(wù),這些都是為客戶提供個性化的服務(wù),這是一些大數(shù)據(jù)相關(guān)的產(chǎn)品.

除此之外,我們平安證券還會利用大數(shù)據(jù)為我們的業(yè)務(wù)人員做一些科學(xué)的決策,依據(jù)自動化的數(shù)據(jù)平臺.

比如自動化報表平臺,大數(shù)據(jù)自助分析平臺等.我們做了這么多事情,最大的問題是怎么保障這些數(shù)據(jù)的準確性.

我首先給大家介紹一下系統(tǒng),我們大數(shù)據(jù)的組成部分,其次我們在測試數(shù)據(jù)中面臨哪些挑戰(zhàn),之后是我們解決思路是什么,最后是總結(jié)以及未來的規(guī)劃.

2、平安大數(shù)據(jù)系統(tǒng)的組成部分

先看一個最簡單的情況,比如我現(xiàn)在有一個需求,西紅柿炒雞蛋,可能大家都比較熟悉這個場景,我給你一個需求是西紅柿炒雞蛋,你怎么做?

• 一種方式直接拿了西紅柿和雞蛋放鍋里炒,那這是不是西紅柿炒雞蛋,是的.但是你吃的時候可能有蛋殼和西紅柿皮.
• 另外一種方式通過各種工序,雞蛋和西紅柿清洗干凈,雞蛋加點鹽打散,西紅柿去到蒂部,切成塊,鍋里放油,加入材料,也是一盤西紅柿炒雞蛋；

大家會吃哪盤西紅柿炒雞蛋也就一目了然了.

同樣的道理,平安證券自己常用的系統(tǒng)大概在50個左右,另外還有數(shù)據(jù)來源于平安旗下其他子公司.如果每個分析人員都根據(jù)自己的需求直接取源數(shù)據(jù),你會發(fā)現(xiàn)同一個需求不同的人做,結(jié)果都不對等的.

另外比如重復(fù)的工作量、低效的工作,無法快速響應(yīng)業(yè)務(wù)需求等等問題,為了解決這些問題,我們實現(xiàn)了統(tǒng)一底層,對各個系統(tǒng)提供的數(shù)據(jù)都來自于統(tǒng)一底層.由統(tǒng)一底層來保障數(shù)據(jù)的質(zhì)量.

看下我們統(tǒng)一底層的框架,從下往上看,最底層是數(shù)據(jù)源,數(shù)據(jù)源來自平安證券的所有系統(tǒng)(比如賬戶系統(tǒng)、交易系統(tǒng)、基金系統(tǒng)、個股期權(quán)、融資融券等等)以及部分平安旗下其他子公司的數(shù)據(jù).

• RAW 層
  所有數(shù)據(jù)的處理都由統(tǒng)一底層進行,統(tǒng)一底層分為四層,最底層是raw層,也是數(shù)據(jù)同步層,數(shù)據(jù)采集過來會放到raw,raw層的數(shù)據(jù)與源數(shù)據(jù)一樣,不做任何的操作.
• MID 層
  數(shù)據(jù)采集完成后,會到 MID 層,MID 層是數(shù)據(jù)的清洗層,MID 層會根據(jù)源數(shù)據(jù)的特性做相應(yīng)的清洗,比如：日期類型的轉(zhuǎn)換、身份證15位到18位的轉(zhuǎn)換、空格、null 值等處理.在清洗層對于常用的清洗方式,我們會通過自定義的函數(shù)進行清洗,以保證不同的開發(fā)人員清洗后的結(jié)果一致.
• BASE 層
  數(shù)據(jù)清洗完成后,就到我們的 base 層,base 層是業(yè)務(wù)流水層,base 層根據(jù)主題進行設(shè)計,比如客戶主題,交易主題,產(chǎn)品主題等等.
• FACT&VIEW層
  Fact 層和 view 層是業(yè)務(wù)實現(xiàn)層,在這個層級上根據(jù)業(yè)務(wù)的需求進行指標的產(chǎn)生、指標的聚合、匯總等等.固化的業(yè)務(wù)數(shù)據(jù)在fact層,未固化業(yè)務(wù)數(shù)據(jù)在view層.

我們當前已完成指標有8萬多個,這些指標是指以客戶為方向,每個客戶涉及標簽有8萬多個,每天還有不斷新增的指標.

我們重點關(guān)注的是中間這部分,因為我們只有保證這部分數(shù)據(jù)準確性,我們才能保證對外提供的數(shù)據(jù)準確.

3、實施大數(shù)據(jù)面臨的挑戰(zhàn)

那我們怎么保證中間這一層數(shù)據(jù)準確性呢?同樣我們也面臨著很大的挑戰(zhàn).

挑戰(zhàn)一：指標繁多

8萬多指標,僅僅用一年把它全部加進去的,對于我們測試人員來講,8萬多個指標涉及到業(yè)務(wù),涉及到底層的很多表,那我們怎么進行處理,這是我們面臨的挑戰(zhàn).

挑戰(zhàn)二：數(shù)據(jù)的準確性

如果數(shù)據(jù)錯了,我們往外提供的數(shù)據(jù)就是有問題的,如果每天都有業(yè)務(wù)人員跟你講,指標好像有問題,如果把所有精力都在回答大家的問題,根本沒有精力做測試.

挑戰(zhàn)三：數(shù)據(jù)穩(wěn)定性

大家可能會看到,對于大數(shù)據(jù)來講,每個指標都是數(shù)據(jù),這個指標你測試之前可能它都是正確的,但是如果某一天有新的數(shù)據(jù)進來,因為每天都會有新的數(shù)據(jù)在進來的過程中,你還能保證你的指標結(jié)果的正確性嗎,怎么保證這是我們需要考慮的.

挑戰(zhàn)四：口徑一致性

因為我們業(yè)務(wù)人員很多,每個業(yè)務(wù)人員口徑都是不一樣的,比如場外基金,對于有些業(yè)務(wù)人員指的場外基金就是場外基金,有些業(yè)務(wù)人員認為場外基金就是場外的公募基金,所以我們怎么保證對外提供的口徑的一致性.

挑戰(zhàn)五：規(guī)模化服務(wù)

8萬多指標,如果不對外提供服務(wù),其實它都是一堆死的東西,沒有任何意義的,你要讓它產(chǎn)生效益,就要對接平安所有的平臺.

挑戰(zhàn)六：人力

我們平安證券測試團隊有一百多人,看起來人力還是很多的,但是我們這些人力都分散在各個子系統(tǒng)下,比如交易系統(tǒng)、基金系統(tǒng),這些都是一個個的子系統(tǒng),這些人力都分散在各個子系統(tǒng)上,對于統(tǒng)一底層僅有十個人力,十個人力要對接8萬多個指標,這是我們當前面臨的挑戰(zhàn).

4、我們的解決思路和方案

4.1 我們的解決思路

為了解決這些問題,我們的解決思路是：圍繞數(shù)據(jù)本身,需要相關(guān)的規(guī)范和流程去保證每個環(huán)節(jié)的準確性,規(guī)范和流程需要工具去管控.

規(guī)范、流程、工具應(yīng)用到開發(fā)、測試、監(jiān)控各個環(huán)節(jié)來保證最后指標數(shù)據(jù)的準確性.

在數(shù)據(jù)開發(fā)平臺會有 DSP 數(shù)據(jù)服務(wù)平臺,和 CM 公共服務(wù)平臺,這兩個平臺保證開發(fā)過程中數(shù)據(jù)的準確性；然后數(shù)據(jù)到自動化測試平臺.

我們團隊最初的時候,三個人力測試一百張底表,幾乎花了一周時間.最后我們狀態(tài)是什么,所有人把表分析完了,再也不想看數(shù)據(jù)了,因為那個數(shù)據(jù)看的自己都想吐的過程.

所以通過自動化平臺減少我們的重復(fù)勞動,把精力花在分析數(shù)據(jù)上.數(shù)據(jù)上線后 ,通過監(jiān)控系統(tǒng)來每天監(jiān)控數(shù)據(jù)的準確運行.

我們先看一下在開發(fā)平臺當中怎么保證數(shù)據(jù)一致性的,在我們平臺每天會運行幾千個腳本,那怎么保證所有開發(fā)人員它的操作是同步一致性的,我們是從這幾個方面保證的.

4.2 DSP數(shù)據(jù)服務(wù)平臺解決方案

所有開發(fā)人員在創(chuàng)建調(diào)度會保證創(chuàng)建調(diào)度一致性,調(diào)度創(chuàng)建之后開發(fā)人員進行執(zhí)行,執(zhí)行之后會進行比對,比對完成之后會由相關(guān)人員進行審核,審核完成之后,這些數(shù)據(jù)才能合并到主表當中.

4.3 創(chuàng)建調(diào)度如何保證

創(chuàng)建調(diào)度這個環(huán)節(jié)我們是怎么保證的呢?我們主要分成下面幾個層面來處理.

• DB 到 RAW 層
  數(shù)據(jù)從 DB 到 RAW 層,也就是同步層,我們會看一下我們的數(shù)據(jù)來源于哪個數(shù)據(jù)庫,因為我們有幾十個數(shù)據(jù)庫.這時大家都可以選擇相應(yīng)的數(shù)據(jù)庫和模式,輸入表名,會自動檢測出來這張表當中有多少字段,以及這些字段轉(zhuǎn)化的類型,數(shù)據(jù)到 RAW 層的時候,類型是需要處理的.有些開發(fā)人員可能會發(fā)現(xiàn),生成的字段類型不符合預(yù)期, 是可以修改的.
• RAW 層到 MID 層
  創(chuàng)建都是自動的,只需要點擊一個按鈕就可以自動生成 MID 層,并且生成相應(yīng)的清洗 sql,對于一些常用的字段會有一些自定義函數(shù),生成的 sql 會自動套用自定義函數(shù).比如日期類型等.在我們 MID 層,會統(tǒng)一處理成一樣的方式,比如客戶是十五位身份證,需要把這些身份證做18位轉(zhuǎn)化,這些都是我們通過自定義函數(shù)在 MID 層做清洗的.

  有些開發(fā)人員可能會覺得有些字段清洗方式還不夠的情況下,你可以在外圍增加清洗的方式,但是不能更改當前的清洗方式,這是流程會監(jiān)控到的.

• BASE 層
  然后是 BASE 層,BASE 完成之后到 fact 層,對于指標系統(tǒng),我們會涉及到對應(yīng)的指標,以及我需要對這些指標做一些相應(yīng)的聚合、匯總或者求一些值,這些都是在相應(yīng)系統(tǒng)里自動配置,然后生成相應(yīng)的腳本,是不存在人工處理的方式.

4.4 測試如何執(zhí)行

我們在創(chuàng)建調(diào)度環(huán)節(jié),通過自動化的方式,來保證我們在開發(fā)過程當中,所有的生成的調(diào)度是一樣的.

這時候調(diào)度創(chuàng)建成功了,需要進行驗證,也就是我們測試執(zhí)行的過程,在這個過程當中,我們開發(fā)人員需要進行自測,因為這個版本是待上線版本,需要驗證,選擇執(zhí)行的日期,比如一些存量表要執(zhí)行一天.

對于增量表可能需要執(zhí)行很多天,執(zhí)行以后這些數(shù)據(jù)會放在臨時位置上,需要對臨時數(shù)據(jù)進行校驗.

4.5 測試如何比對

我們還有一個測試比對環(huán)節(jié),在測試比對環(huán)節(jié)所有模板都已設(shè)置,在模板當中我們會完成哪些功能呢?

第一, 我們字段里表結(jié)構(gòu),這些最基本的,我們會進行全面的驗證.

第二, 一些 count、max、min、sum,還有空值、空格、NULL 值,長度、頻度診斷,還有數(shù)據(jù)比對.

這樣我們在整個開發(fā)流程當中,可以保證 RAW、MID 層不用再轉(zhuǎn)測試,BASE 層和 fact 層,因涉及業(yè)務(wù)邏輯,需要測試人員進行驗證.

4.6 我們的測試方法

在我們測試的時候,常用的方法有很多,最重要的一點是我們需要對源數(shù)據(jù)進行分析,這就是數(shù)據(jù)診斷過程.

1. 我們會進行 DT 分布診斷,比如對于全量表,dt 分布應(yīng)該是曲線上升的,如果某天變成曲線波動,就說明出現(xiàn)了問題.
2. 我們會做重復(fù)觀測診斷,重復(fù)觀測診斷可以判斷,來確定這張表的組件是什么,如果數(shù)據(jù)主鍵存在重復(fù)數(shù)據(jù)的情況下,就要確認這張表是不是遷移的時候就有問題還是源數(shù)據(jù)有問題,這是需要分析的.
3. 單變量診斷,這里有頻度、長度、截取前XX位的.
4. 數(shù)據(jù)類型分布診斷,有 sum、均值、標準差、max、min、分位數(shù)、中位數(shù)等.

其次,我們會做業(yè)務(wù)診斷.我們對業(yè)務(wù)診斷過程中,大家會發(fā)現(xiàn)對于底層表可能有幾十個,我們需要分析字段和字段之間存在一對一,還是一對多,還是多對一的關(guān)系,避免數(shù)據(jù)虛增；

數(shù)據(jù)關(guān)系映射,表間映射關(guān)系,診斷通過哪些字段進行關(guān)聯(lián)；

另外我們還會進行表間 HITRATE 診斷,不同表間 ID 類字段的匹配率,來確定哪張表是主表.

只有通過診斷,才能發(fā)現(xiàn)哪些數(shù)據(jù)或者業(yè)務(wù)存在問題,不是說業(yè)務(wù)告訴我什么樣子就是什么樣的情況.大家可能會很奇怪,你們做這么多診斷,你們在項目中是怎么做的.

舉個例子,經(jīng)常使用平安證券 App 的人會知道,我們頁面上會有收益額,比如收益額 = 期末市值 – 期初市 + 賣出 – 買入.

因為交易處理方式是不一樣的,比如晚上我們要做清算,可能有些公司不是這樣的情況,我們要跟交易所做清算,跟 TA 公司做清算等,這些清算規(guī)則也是不一樣的,不同基金清算方式不一樣的.

并且我們數(shù)據(jù)來自不同系統(tǒng),比如賬戶系統(tǒng)、交易系統(tǒng)、基金系統(tǒng)、融資融券等.

我們看算一個收益指標是怎么做的.

• DT分布
  先是 RAW 層和 MID 層,這兩個層的數(shù)據(jù)基本與原數(shù)據(jù)保持一致的,唯一不同是我們的清洗層會對相應(yīng)數(shù)據(jù)進行處理,比如 dt 分布診斷.可以判斷每天的數(shù)據(jù)是不是存在問題.另外還可以判斷底層為了上層進行匯總的時候,第一天數(shù)據(jù)起始日期是否一致,因為數(shù)據(jù)來源于不同系統(tǒng),而且我們所有系統(tǒng)開始日期都是不一樣的.

  比如交易股票,可能很早之前就有數(shù)據(jù)了,但是我們場外基金是最近幾年才有的,如果拉歷史數(shù)據(jù)少拉一年或者少拉一天數(shù)據(jù),算出客戶最終收益都是不對的.

  只有把底表歷史數(shù)據(jù)拉出來以后看開始日期是不是正確的,這樣才能保證上層匯總的數(shù)據(jù)是不是正確的.

• 重復(fù)觀測
  重復(fù)觀測,比如一個客戶同一天有多筆交易,需要判斷客戶是因為買了這么多次交易,還是因為交易流水本身出現(xiàn)問題,客戶是否是一模一樣的交易記錄,這兩種方式最終處理方式是不一樣的.
• 單變量的診斷
  我們會做單變量的診斷,一般情況下,業(yè)務(wù)人員或者研發(fā)人員會告訴你市值從哪里獲取,但是獲取的時候會發(fā)現(xiàn)市值有空的情況,那就要分析這個客戶有沒有股票,如果客戶有股票,市值為空的話,那就是有問題,就需要重新在判斷.
• 數(shù)據(jù)診斷
  數(shù)據(jù)診斷,如果說不對數(shù)據(jù)進行診斷,就不清楚這個業(yè)務(wù)什么樣子,可能有些人會認為,業(yè)務(wù)人員都很資深的,對這些都很了解,那是否還知道十年前的數(shù)據(jù)是什么樣的嗎,只有通過深入分析,才能對數(shù)據(jù)上層進行匯總,保證它的質(zhì)量.以我的資金為例,可以看到這個客戶的資金流水是在哪個范圍之內(nèi),才能確保上層匯總出來的數(shù)據(jù)是否正確.如果已經(jīng)對客戶總資產(chǎn)算出來一個范圍,在上層匯總的時候,發(fā)現(xiàn)明顯有大的變化,那只能說明在實現(xiàn)業(yè)務(wù)的過程中數(shù)據(jù)數(shù)出現(xiàn)了問題.
• 業(yè)務(wù)診斷
  業(yè)務(wù)診斷,另外還有根據(jù)業(yè)務(wù)的行為,確認上層怎么進行匯總.經(jīng)過診斷之后,才能根據(jù)這樣的情況做上層,就是 BASE 層,BASE 會根據(jù)客戶和產(chǎn)品粒度進行匯總,比如客戶買了哪支股票,他的收益額是什么情況,或者不同的股票,不同的基金等等.BASE 層匯總,還是一樣要做相關(guān)的數(shù)據(jù)診斷和業(yè)務(wù)診斷,我們也會根據(jù)原始業(yè)務(wù)診斷結(jié)果,確定上層業(yè)務(wù)場景是不是做了全部覆蓋.

BASE 層之后是業(yè)務(wù)實現(xiàn)層,這時候就比較簡單了,我們可以根據(jù)客戶粒度進行匯總,客戶收益是什么樣的,這種情況下,除了做診斷之外,還會做一些比較,只有這樣才能算出真正收益是什么樣的.

只有在不同層級保證之后,才能保證最頂層數(shù)據(jù)是不是正確的.那要做這么多數(shù)據(jù)診斷,純粹靠人工做是不現(xiàn)實的事情.

所以搭建了自動化平臺,會對 RAW、MID、BASE 層做各種診斷,把相應(yīng)的診斷sql錄入到自動化平臺,后續(xù)所有執(zhí)行都是由自動化平臺執(zhí)行的,執(zhí)行出來的結(jié)果再作分析.比如現(xiàn)在有一個新的指標,需要對哪些字段進行相應(yīng)診斷的時候,只要運行下自動化腳本,看一下結(jié)果圖就可以了.

這樣大大方便了測試人員,降低了手工測試成本,只需要維護測試腳本就可以了.在運行結(jié)果之后,可以看到這次運行多少個,失敗多少個,看下失敗的是什么造成的.

5、平安大數(shù)據(jù)監(jiān)控平臺

除了測試,數(shù)據(jù)是要進行上線的,上線之后不可能每天再進行測試,也沒有那么多精力,對已經(jīng)上線的指標通過監(jiān)控平臺進行監(jiān)控數(shù)據(jù)運行情況.

監(jiān)控平臺主要從幾個方面進行監(jiān)控.

我們會對每個層級進行監(jiān)控,監(jiān)控主要分為幾個部分.

一是,調(diào)度監(jiān)控,因為所有大數(shù)據(jù)實現(xiàn)的業(yè)務(wù)邏輯都是通過調(diào)度實現(xiàn)的,我們就會對調(diào)度進行監(jiān)控.

二是,數(shù)據(jù)相關(guān)的監(jiān)控指標,對數(shù)據(jù)指標進行監(jiān)控.

三是,還有業(yè)務(wù)口徑相關(guān)的監(jiān)控指標,這個是IT人員業(yè)務(wù)口徑.

四是,還有是業(yè)務(wù)人員自己要監(jiān)控的一些業(yè)務(wù)指標,通過設(shè)置要監(jiān)控的參數(shù),放到監(jiān)控平臺里面.

如果說每天跑完之后,有異常數(shù)據(jù),會由告警平臺發(fā)出相關(guān)郵件,通知大家要進行相應(yīng)的處理.

我們現(xiàn)在看一下調(diào)度監(jiān)控都會監(jiān)控哪些東西?

5.1 任務(wù)狀態(tài)運行的監(jiān)控

目前我們運行的調(diào)度大概在1300多個,每天都會監(jiān)控運行的情況,還有一部分存在依賴關(guān)系的調(diào)度,如果之前調(diào)度沒有運行完的話,會定時發(fā)送郵件告訴開發(fā)人員調(diào)度是延時了,這是業(yè)務(wù)運行狀態(tài)進行監(jiān)控.

可能很多人會覺得,一個調(diào)度運行一個小時,兩個小時覺得是很正常的事情.但在我們平臺上,一個調(diào)度運行超過十分鐘就要分析,這個調(diào)度的代碼是否是有問題的.

有些開發(fā)人員可能說寫的結(jié)果是對的,它能夠跑出結(jié)果就可以.但是調(diào)度運行時間長了,往往會影響到后面整個運行的過程,那就會導(dǎo)致今天一天數(shù)據(jù)可能都沒有辦法算完.

所以我們對于每個腳本運行時間是有限制的,如果超過十分鐘,開發(fā)人員就要檢測是不是代碼是否存在問題.

5.2 依賴關(guān)系監(jiān)控

我們還有一種監(jiān)控,就是依賴關(guān)系監(jiān)控,大家可以看出,我們一個調(diào)度可能你的上層依賴很多調(diào)度,你的下層也依賴很多調(diào)度,那調(diào)度和調(diào)度之間是存在依賴關(guān)系的,一個調(diào)度失敗可能會影響到其他調(diào)度的失敗.

那么怎么監(jiān)控?我們會監(jiān)控到你上層依賴多少調(diào)度,下層依賴多少調(diào)度,因為這個腳本比較特殊,依賴特別多,原因它是我們最后一個調(diào)度,它需要向我們數(shù)據(jù)庫推送8萬個指標的,所以它的依賴特別大.

在我們調(diào)度依賴會有一些設(shè)置,如果它依賴的上層調(diào)度或者下層調(diào)度存在問題的話,就會立即停止運行,由運維人員進行處理.

5.3 數(shù)據(jù)規(guī)則監(jiān)控

另外是對于數(shù)據(jù)規(guī)則的監(jiān)控,一個是基本規(guī)則的監(jiān)控,第二自定義規(guī)則監(jiān)控,基本規(guī)則監(jiān)控相對比較簡單,大家在測試和開發(fā)過程當中會做的一些長度診斷或者頻度診斷等,這是作為基本功能的監(jiān)控.

我們會在監(jiān)控平臺進行設(shè)置,還有一些是測試人員,或者我們業(yè)務(wù)人員他有自己的想法,他不想按照常規(guī)的方式,可能常規(guī)方式也不符合需求,因為這是大體上的監(jiān)控,并不能保證里面的數(shù)據(jù)是不是存在問題.

5.4 自定義監(jiān)控

在自定義監(jiān)控上,開發(fā)人員和業(yè)務(wù)人員可以根據(jù)自己的需求設(shè)置相應(yīng)的指標,這個平臺相對而言,它靈活性比較高一些,可以被我們所有相關(guān)人員進行使用,根據(jù)需求進行監(jiān)控.

除了數(shù)據(jù)監(jiān)控之外,我們業(yè)務(wù)人員會根據(jù)自己的需求,從業(yè)務(wù)角度制定相關(guān)的監(jiān)控.比如一些核心指標,可以在監(jiān)控平臺進行設(shè)置,也可以通過報表的方式進行監(jiān)控,關(guān)注了哪些指標,這是業(yè)務(wù)人員可以根據(jù)自己的方式進行相關(guān)監(jiān)控.

6、總結(jié)

最后總結(jié)下,我們是從開發(fā)階段、測試階段、監(jiān)控階段,來保證大數(shù)據(jù)的數(shù)據(jù)準確性,在開發(fā)階段主要是一站式服務(wù),從創(chuàng)建到執(zhí)行,到比對,開發(fā)階段完成之后,才能夠轉(zhuǎn)測試,在測試階段,我們會進行數(shù)據(jù)診斷,自動化測試.

自動化測試完成后確認腳本沒有問題之后,可以上線,測試人員評審,評審?fù)ㄟ^之后,就意味著調(diào)度是可以進行上線的,就發(fā)布到預(yù)上線過程,通知運維人員調(diào)度已經(jīng)完成測試,可以進行上線,后面的操作就會由運維人員進行處理.

上線之后監(jiān)控平臺監(jiān)控調(diào)度、數(shù)據(jù)、業(yè)務(wù)是否存在問題,如果存在問題,就會快速通知到相關(guān)的開發(fā)人員或者運維人員進行相應(yīng)的處理,這是目前已經(jīng)實現(xiàn)的情況.

對于未來我們有什么考慮呢?第一我們會考慮平臺互通,目前我們開發(fā)平臺、測試平臺、監(jiān)控平臺,都是相對獨立的.

目前開發(fā)平臺和監(jiān)控平臺之間還有一些關(guān)聯(lián)關(guān)系,但是我們自動化平臺是沒有跟它們進行打通的.后面會考慮,比如說開發(fā)完一個調(diào)度之后,自動到自動化平臺進行運行,可以快速保證,完成測試的過程.

另外還有一個部分,我們會考慮自動化平臺和監(jiān)控平臺打通,打通的目的比如一個指標出現(xiàn)問題,可能并不清楚是哪個客戶指標出現(xiàn)問題了,如果和監(jiān)控打通的話,快速知道是哪個客戶的指標出現(xiàn)問題.

第二部分,我們會對我們的平臺進行豐富,后續(xù)我們會把很多東西加入到自動化平臺來,真正的產(chǎn)品化.另外是監(jiān)控體系,目前監(jiān)控體系有一部分是由數(shù)據(jù)分析人員分析出來一些值和數(shù)據(jù)提供給我們,進行監(jiān)控.

但是這些是被動的,我們后期會把一些統(tǒng)計分析其機器學(xué)習(xí)方法運用到監(jiān)控當中,豐富監(jiān)控指標.

另外當前我們做的數(shù)據(jù)都是離線數(shù)據(jù),每天晚上交易結(jié)束之后,會把數(shù)據(jù)進行遷移,對于實時數(shù)據(jù)目前沒有驗證,后續(xù)我們也要考慮怎么保證實時數(shù)據(jù)的準確性.

原文來自——微信公眾號(高效運維)

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.snjht.com/jiaocheng/4320.html