TOP100summit：【分享實錄-Microsoft】基於Kafka與Spark的實時大數據質量監控平臺

本篇文章內容來自2016年TOP100summit Microsoft資深產品經理邢國冬的案例分享。
編輯：Cynthia

邢國冬（Tony Xing）：Microsoft資深產品經理、負責微軟應用與服務集團的大數據平臺構建，數據產品與服務.

導讀：微軟的ASG (應用與服務集團）包含Bing,、Office,、Skype。天天產生多達5 PB以上數據，如何構建一個高擴展性的data audit服務來保證這樣量級的數據完整性和實時性很是具備挑戰性。本文將介紹微軟ASG大數據團隊如何利用Kafka、Spark以及Elasticsearch來解決這個問題。

一．案例簡介

本案例介紹了微軟大數據平臺團隊設計和部署的基於開源技術（Kafka、Spark、ElasticsSearch、Kibana）的大數據質量監控平臺，這個平臺具備實時、高可用、可擴展、高度可信的特性，成爲微軟Bing、Office36五、Skype等年收入270+億美圓的業務在監控數據質量方面的可靠技術保障。同時，基於業務須要，咱們在設計和實現中達成下面一系列的目標：

● 監控流式數據的完整性與時延；
● 須要監控的數據管道(pipeline)具備多個數據生產者、多處理階段、多數據消費者的特性；
● 數據質量的監控須要近實時(near real time)；
● 數據質量發生問題的時候，須要提供相應的診斷信息來幫助工程師迅速解決問題；
● 監控平臺的服務自己須要超級穩定和高可用, 大於99.9%在線時間；
● 監控與審計自己是高度可信；
● 平臺架構能夠水平擴展 (Scale out)。

2、背景以及問題的引入

爲了服務微軟的Bing、Office 365以及Skype業務，咱們的大數據平臺須要處理天天高達十幾PB級別的海量大數據，全部的數據分析、報表、洞見以及A/B測試都依賴於高質量的數據，若是數據質量不高的話，依賴數據作決策的業務都會受到嚴重影響。

與此同時，微軟業務對於實時數據處理的需求也日益增長，之前監控批處理數據（batch data）的不少解決方案已經再也不適用於實時的流式數據的質量監控。

在另一個層面，基於歷史緣由，各個業務集團每每使用不一樣的技術、工具來作數據處理，怎麼整合這樣異構的技術、工具以及在此之上的數據質量監控也是一個急需解決的問題。

圖1是咱們數據處理平臺的一個概念性架構。從數據生產者這端，咱們經過在客戶端以及服務端使用通用的SDK，按照通用的schema來產生數據，數據經過分佈在全世界的數據收集服務(collectors)來分發到相應的Kafka,而後經過pub/sub模式由各類各樣的計算以及存儲框架來訂閱。

這樣各類團隊就能夠選擇他們最熟悉或者一直以來使用的工具來作處理。例如，從實時處理的角度，各個業務團隊能夠選用好比Spark或者微軟的USQL streaming處理框架，以及其餘第三方的工具來作一些特定場景的分析，好比日誌分析的Splunk、交互式分析的Interana等。在批處理框架上，用戶能夠選用開源社區的Hadoop,、Spark或者微軟的Cosmos等。

如圖2所示，咱們在遷移大數據到圖1架構的過程當中，也看到實時流式數據的快速增加。天天峯值消息高達一萬億個以上，每秒處理一百三十萬個消息， 天天處理3.5PB流式數據。

3、數據監控的場景以及工做原理

3.1數據監控場景

基於業務需求，咱們總結歸納了須要被監控的數據處理管道特性（如圖3）
● 多數據生產者（multiple data producers），數據來自客戶端和服務端；
● 多個數據消費者(multiple data consumers)，這裏特指各類數據處理框架；
● 多數據監控階段（multiple stages），從數據產生到數據處理，數據每每流經多個數據管道的組件，咱們須要經過監控確保每一個階段數據都不會發生丟失、高時延、以及異常。

3.2工做原理

基於圖3的數據管道，咱們把問題具體化爲如何確保基於Kafka的數據管道上下游的數據完整性、實時性、數據異常的監測。圖4是一個抽象化的監控架構以及工做原理。

藍色組件是數據管道里數據流經的各個處理階段；綠色組件是本文中實時數據質量監控的核心服務Audit Trail。在數據流經各個組件的同時，相應的審計(audit)數據也會同時發到Audit Trail, 這個審計數據能夠看做是一種元數據(meta data)，它包含關於數據流的信息，例如該消息是在哪一個數據中心、哪臺機器產生；該消息包含幾條記錄、大小、時間戳等。Audit Trail彙總了各個數據處理組件發來的元數據後，就能夠實時作各類數據質量的評估，好比數據在此時刻的完整性如何、實時性如何、有無異常。

基於圖5的審計元數據，一旦發生數據質量問題，工程師能夠快速定位是哪一個數據中心的哪臺服務器在什麼時間段發生了問題，而後快速採起相應行動來解決或緩解問題，並把對下游數據處理的影響降到最低。

可被監控的數據質量問題能夠分爲以下幾類：
● 數據時延超出規定的SLA (service level agreement)

工程師能夠經過如圖6所示的時延狀態圖快速瞭解在數據質量時延這個維度是否正常，這對於對實時性要求比較嚴格的數據產品及應用很是重要，若是數據延遲到來，不少時候就失去了意義。

須要注意的是，圖表在這裏起到的只是輔助做用，在真正的生產環境中是經過系統API調用來按期檢查SLA的符合狀況，一旦超出時延閾值，會經過電話、短信等手段通知值班的工程師來實時解決問題。

● 數據在移動中發生丟失致使完整性不知足SLA (service level agreement)

工程師能夠經過圖7中所示簡單圖表來了解數據完整性的狀態，圖7所示包含兩個數據處理階段：一個數據生產者和兩個數據消費者的應用案例。因此圖表中其實是三條線，綠色是生產者的實時數據量，藍色和紫色線是兩個數據消費者處理的數據量。若是在理想狀況下，數據完整性沒有問題，這三條線是徹底重合。本例中在最後一個點出現了分叉，表明數據完整性出現問題，須要工程師進行干預。

● 數據自己發生異常-經過異常檢測來實時監控

數據自己發生異常，咱們由相應的基於統計元數據的異常檢測（如圖8）來作實時監控。異常檢測是一個在工業界很是廣泛的問題和挑戰，幾乎每一個互聯網公司都會有作異常檢測的服務或平臺，可是作好很不容易，這是一個能夠單獨寫一篇文章的大題目，這裏只是單闢一個章節作簡單的算法介紹。

本例是經過對於數據量的異常檢測來發現上游寫log問題，或者其餘數據生產的邏輯問題。

3.3異常檢測

3.3.1異常檢測算法1

咱們採用了Holt-Winters算法（圖9）來訓練模型和作預測，並在此之上作了不少改進來增長算法的強健性和容錯能力。

強健性上的改進包括：
● 使用Median Absolute Deviation (MAD) 獲得更好的估值；
● 處理數據丟點和噪聲 (例如數據平滑)。
功能上的改進包括：
● 自動獲取趨勢和週期信息；
● 容許用戶人工標記和反饋來更好的處理趨勢變化。
經過比較預測值和實際值，咱們採用GLR (Generalized Likelihood Ratio) 來發現異常點。在這上面咱們也作了相應的改進，包括：
● Floating Threshold GLR, 基於新的輸入數據動態調整模型；
● 對於噪聲比較大的數據作去除異常點。

3.3.2異常檢測算法2

這是一個基於Exchangeability Martingale的在線時間序列的異常檢測算法，其核心就是假設數據的分佈是穩定的。若是新的數據點的加入致使數據的分佈(distribution)發生比較大的變化，咱們就認爲異常發生了。因此基於歷史數據，咱們須要定義一個新值異常公式（New value strangeness）。下面是這些公式的構成，對數學不感興趣的讀者能夠略去。

在某個時刻t, 咱們收到一個新的數據點，對於歷史每一個數據i：
s[i] = strangeness function of (value[i], history)
Let p[t] = (#{i: s[i] > s[t]}+ r*#{i: s[i]==s[t]})/N, where r is uniform in (0,1)
Uniform r makes sure p is uniform
Exchangeability Martingale: Mt=i=1tϵpiϵ-1
EMtp1,p2,…pt-1=Mt-1
Integrate ϵpiϵ-1 over [0,1] and pi is uniform
報警觸發門檻經過Doob’s maximal inequality控制
Prob (∃ t :Mt>λ)<1λ
對於異常點，Martingale的值就會大於門檻值。

3.3.3異常檢測算法3

這是一個簡單而很是有效的基於歷史數據的指數平滑算法。
它首先基於歷史數據生成動態上下界：

Threshold (width) = min(max(M1Mean, M2Standard Deviation), M3*Mean) (M1<M3)
Alert: |Value – predicated value| > Threshold
預測值 = S1+12S2+14S3+18S4+116S51+12+14+18+116
優勢在於處理週期性數據的異常檢測很好，而且容許用戶反饋和標記來調整動態上下界。

4、系統設計概述

基於業務場景的須要，咱們在設計和實現中須要達成一系列的目標以及處理相應的挑戰：
● 監控流式數據的完整性與時延；
● 須要監控的數據管道(pipeline)具備多個數據生產者、多處理階段、多數據消費者的特性；
● 數據質量的監控須要近實時(near real time)；
● 數據發生問題的時候，提供相應的診斷信息來幫助工程師迅速解決問題；
● 監控平臺的服務自己須要超級穩定和高可用, 99.9%以上在線時間；
● 監控與審計自己是高度可信；
● 平臺架構能夠水平擴展 (Scale out)。

4.1高可用可擴展的架構

如圖10所示，審計元數據經過前端服務（front end web service）到達Kafka, 咱們利用Kafka來實現高可用的臨時存儲（transient storage）, 這樣，咱們的數據生產者和消費者在發送審計數據的同時，就不會發生阻塞進而影響更重要的數據流。

經過Spark streaming的應用，把審計數據按照時間窗口聚合，同時有相應的邏輯處理去重，晚到以及非順序到來的數據，同時作各類容錯處理保證高可用。

ElasticsSearch做爲存儲聚合的審計數據，經過Kibana作報表展現，進而經過Data Analysis service對外提供API來使得用戶獲取各類數據質量信息。

Data Analysis Service做爲最終的API端，提供各類數據完整性、實時性、異常的信息。
上述組件，每一個都設計成能夠獨立水平擴展(Scale out), 而且在設計上保證高容錯已實現高可用性。

4.2異地雙活的可靠性保障

經過雙數據中心Active-Active災備（Disaster recovery）如圖11所示，來進一步保證高可用高可靠的服務。總體架構保證數據流同時經過兩個同構的審計處理管道進行處理，即便一個數據中心由於各類緣由下線，總體服務仍是處於可用狀態，進而保證全天候的數據質量審計與監控。

4.3高度可信的審計與監控服務

對於任何監控服務來講，常常被質疑的就是是否監控服務自己的結果是準確可信的。爲了保證這一點，咱們經過兩種方式來保證服務的可信度：
● 用來審計自身（Audit for audit）（圖12）；
● Synthetic probe。

在基於Kafka/Spark/ES的管道以外，咱們還有一套獨立的經由ES的審計元數據的處理管道，經過比較上述兩個管道的結果，咱們就能保證審計數據的可靠性。
另外，基於synthetic probe的方式，咱們每分鐘會發送一組synthetic數據進入前端服務（front end web service）, 而後試圖從Data Analysis web service 讀出，經過這種方式進一步保障數據的可靠性。

4.4輔助數據質量問題的診斷

當數據質量發生問題，Audit Trail提供了原始的審計元數據來幫助工程師進一步作問題的診斷。工程師可使用這些元數據和他們本身的trace來進一步JOIN, 來提供一種交互式的診斷，如圖13。

5、效果評估和總結

經過上述系統架構的設計與部署，咱們實現了一系列支持公司Bing,、Office,、Skype業務發展的數據質量監控目標：
● 監控流式數據的完整性與時延；
● 須要監控的數據管道(pipeline)具備多個數據生產者、多處理階段、多數據消費者的特性；
● 數據質量的監控須要近實時(near real time)；
● 數據發生問題的時候，須要提供相應的診斷信息來幫助工程師迅速解決問題；
● 監控平臺的服務自己須要超級穩定和高可用, 99.9%在線時間
● 監控與審計自己是高度可信；
● 平臺架構能夠水平擴展 (Scale out)。

11月9-12日，北京國家會議中心，第六屆TOP100全球軟件案例研究峯會，Microsoft Principal Product Designer Bill Zhong將分享《微軟OneNote的敏捷UX轉型實踐》；微軟 data scientist Kirk Lee將分享《reinforcement learning in azure customer engagement》；微軟 亞洲研究院資深研究員鄭宇將分享《用大數據和AI驅動智能城市》。

TOP100全球軟件案例研究峯會已舉辦六屆，甄選全球軟件研發優秀案例，每一年參會者達2000人次。包含產品、團隊、架構、運維、大數據、人工智能等多個技術專場，現場學習谷歌、微軟、騰訊、阿里、百度等一線互聯網企業的最新研發實踐。

大會開幕式單天體驗票申請入口