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

作者簡介：

劉宏霞

平安證券 大數據測試組負責人

2014年加入平安證券,正值互聯網金融潮流興起,組織并參與大數據自動化以及監控體系的搭建、應用和優化.熟悉券商核心業務,對數據有著濃厚的興趣,并把相關的技術應用到數據質量上,不斷地探索券商數據質量之路.

前言

這兩年對于大數據來講,大家看到有很多產品出來,很多公司也在利用數據做些東西,包括現在的一些電影.

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

那如果數據質量本身存在問題,就會導致數據分析出現誤差,甚至錯誤的預測或者誤導性的描述.所以今天我給大家分享的主題是券商的大數據保障之道 .

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

1、平安大數據做些什么

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

我們為用戶提供個性化的服務,比如 App 功能上有一些千人千面,猜你喜歡的內容,推送的一些功能.其中包括資產收益的功能,這些數據是來自用戶大數據,幫助更好為用戶推薦產品,也幫助用戶更方便獲取信息.

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

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

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

除此之外,我們平安證券還會利用大數據為我們的業務人員做一些科學的決策,依據自動化的數據平臺.

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

我首先給大家介紹一下系統,我們大數據的組成部分,其次我們在測試數據中面臨哪些挑戰,之后是我們解決思路是什么,最后是總結以及未來的規劃.

2、平安大數據系統的組成部分

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

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

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

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

另外比如重復的工作量、低效的工作,無法快速響應業務需求等等問題,為了解決這些問題,我們實現了統一底層,對各個系統提供的數據都來自于統一底層.由統一底層來保障數據的質量.

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

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

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

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

3、實施大數據面臨的挑戰

那我們怎么保證中間這一層數據準確性呢?同樣我們也面臨著很大的挑戰.

挑戰一：指標繁多

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

挑戰二：數據的準確性

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

挑戰三：數據穩定性

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

挑戰四：口徑一致性

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

挑戰五：規模化服務

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

挑戰六：人力

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

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

4.1 我們的解決思路

為了解決這些問題,我們的解決思路是：圍繞數據本身,需要相關的規范和流程去保證每個環節的準確性,規范和流程需要工具去管控.

規范、流程、工具應用到開發、測試、監控各個環節來保證最后指標數據的準確性.

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

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

所以通過自動化平臺減少我們的重復勞動,把精力花在分析數據上.數據上線后 ,通過監控系統來每天監控數據的準確運行.

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

4.2 DSP數據服務平臺解決方案

所有開發人員在創建調度會保證創建調度一致性,調度創建之后開發人員進行執行,執行之后會進行比對,比對完成之后會由相關人員進行審核,審核完成之后,這些數據才能合并到主表當中.

4.3 創建調度如何保證

創建調度這個環節我們是怎么保證的呢?我們主要分成下面幾個層面來處理.

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

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

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

4.4 測試如何執行

我們在創建調度環節,通過自動化的方式,來保證我們在開發過程當中,所有的生成的調度是一樣的.

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

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

4.5 測試如何比對

我們還有一個測試比對環節,在測試比對環節所有模板都已設置,在模板當中我們會完成哪些功能呢?

第一, 我們字段里表結構,這些最基本的,我們會進行全面的驗證.

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

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

4.6 我們的測試方法

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

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

其次,我們會做業務診斷.我們對業務診斷過程中,大家會發現對于底層表可能有幾十個,我們需要分析字段和字段之間存在一對一,還是一對多,還是多對一的關系,避免數據虛增；

數據關系映射,表間映射關系,診斷通過哪些字段進行關聯；

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

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

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

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

并且我們數據來自不同系統,比如賬戶系統、交易系統、基金系統、融資融券等.

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

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

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

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

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

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

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

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

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

5、平安大數據監控平臺

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

監控平臺主要從幾個方面進行監控.

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

一是,調度監控,因為所有大數據實現的業務邏輯都是通過調度實現的,我們就會對調度進行監控.

二是,數據相關的監控指標,對數據指標進行監控.

三是,還有業務口徑相關的監控指標,這個是IT人員業務口徑.

四是,還有是業務人員自己要監控的一些業務指標,通過設置要監控的參數,放到監控平臺里面.

如果說每天跑完之后,有異常數據,會由告警平臺發出相關郵件,通知大家要進行相應的處理.

我們現在看一下調度監控都會監控哪些東西?

5.1 任務狀態運行的監控

目前我們運行的調度大概在1300多個,每天都會監控運行的情況,還有一部分存在依賴關系的調度,如果之前調度沒有運行完的話,會定時發送郵件告訴開發人員調度是延時了,這是業務運行狀態進行監控.

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

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

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

5.2 依賴關系監控

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

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

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

5.3 數據規則監控

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

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

5.4 自定義監控

在自定義監控上,開發人員和業務人員可以根據自己的需求設置相應的指標,這個平臺相對而言,它靈活性比較高一些,可以被我們所有相關人員進行使用,根據需求進行監控.

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

6、總結

最后總結下,我們是從開發階段、測試階段、監控階段,來保證大數據的數據準確性,在開發階段主要是一站式服務,從創建到執行,到比對,開發階段完成之后,才能夠轉測試,在測試階段,我們會進行數據診斷,自動化測試.

自動化測試完成后確認腳本沒有問題之后,可以上線,測試人員評審,評審通過之后,就意味著調度是可以進行上線的,就發布到預上線過程,通知運維人員調度已經完成測試,可以進行上線,后面的操作就會由運維人員進行處理.

上線之后監控平臺監控調度、數據、業務是否存在問題,如果存在問題,就會快速通知到相關的開發人員或者運維人員進行相應的處理,這是目前已經實現的情況.

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

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

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

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

但是這些是被動的,我們后期會把一些統計分析其機器學習方法運用到監控當中,豐富監控指標.

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

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

轉載請注明本頁網址：
http://www.fzlkiss.com/jiaocheng/4320.html