作者簡介：

劉巨集霞

平安證券 大資料測試組負責人

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、總結

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

自動化測試完成後確認指令碼沒有問題之後，可以上線，測試人員評審，評審通過之後，就意味著排程是可以進行上線的，就釋出到預上線過程，通知運維人員排程已經完成測試，可以進行上線，後面的操作就會由運維人員進行處理。

上線之後監控平臺監控排程、資料、業務是否存在問題，如果存在問題，就會快速通知到相關的開發人員或者運維人員進行相應的處理，這是目前已經實現的情況。

對於未來我們有什麼考慮呢？第一我們會考慮平臺互通，目前我們開發平臺、測試平臺、監控平臺，都是相對獨立的。

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

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

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

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

另外當前我們做的資料都是離線資料，每天晚上交易結束之後，會把資料進行遷移，對於實時資料目前沒有驗證，後續我們也要考慮怎麼保證實時資料的準確性。

原文來自——微信公眾號（高效運維）