從0到1建立基於大數據的質量平台

接收程序員的 8 點技術早餐

隨著互聯網的快速發展，大數據與軟體質量的關係越來越密切，從源碼撰寫、持續集成、測試調試、發布運營，整個流程中大數據無所不在。每個數據關聯起來對軟體質量中的發現、度量、定位都有著重要的價值。如何從 0 到 1 建立基於大數據的質量平台，利用大數據來改善軟體質量？

來自阿里巴巴優酷事業部技術專家萬傳奇老師將在 4 月 20 - 22 日召開的 QCon 全球軟體開發大會上分享優酷大數據質量平台建設及線上質量閉環解決方案實踐。在大會開始前，我們有幸採訪了萬傳奇老師，提前了解一下優酷大數據質量平台建設背後的技術故事。

受訪嘉賓介紹

萬傳奇（花名「萬眾」），阿里巴巴優酷事業部技術專家。2014 年進入阿里，負責阿里集團持續集成平台 CISE 、AONE 實驗室等開發工作，支撐集團所有事業部的測試任務。並通過整合集團測試工具插件化，中間件 Docker 化等核心工作，積累了豐富的測試經驗。

2017 年開始，全面負責優酷質量部平台建設工作，建立起以大數據為基礎的視頻質量保障體系，高效結合了實時度量、監控、灰度、告警、定位、分析等多項功能，形成一套完整質量保障解決方案，成為優酷業務線以及阿里相關多媒體質量唯一標準。

平台搭建背景

隨著優酷技術棧和阿里不斷整合，各客戶端埋點數據參照集團的方式全部上報，但對於數據的使用，大家多是寫個離線 SQL ，或者部分數據對接集團各個橫向服務平台來使用。從優酷業務線角度看，沒有一個垂直的大數據平台來支撐各業務線，嚴重影響開發的效率以及數據對業務本應有的強力支持。基於這個背景，團隊臨危受命，開始了大數據平台的開發工作。

平台搭建過程中「坑」

從技術角度來說，優酷大數據質量平台搭建分為三大部分：實時、離線、檢索。

實時框架我們選擇了 Blink（ Flink ）和 Spark Streaming ，兩個框架都能很好處理實時需求，我們在 ETL 層面選用了 Blink ，數據計算部分選用了 Spark；

離線部分依託 ODPS 平台，這個平台相對功能強大，適合新人上手，簡單的 SQL 就能滿足業務需求；

檢索部分我們主要依賴 ELK 技術，並將數據存儲在 OTS （ HBase ）和 ElasticSearch 中用來進行實時離線度量數據查詢，也包括了上面說的聚合查詢、全文檢索等。

在平台搭建過程中遇到不少「坑」，我們也總結了一些經驗，主要分為以下兩點：

1. 成本

在開發之前，需要考慮兩個成本問題：費用成本和人力成本。

大數據是特別耗費資源的，如果這方面不加以控制，產品的性價比就大打折扣，結合優酷大數據平台的經驗，這塊一定要強關聯業務，比如說在數據預計算處理的時候，需要考慮可選維度或必選維度，亦或是哪些維護可以合併處理，這樣在存儲上能夠極大節省空間。在離線計算過程中，如何抽象出中間表，降低計算複雜程度，節省計算資源。

再說人力成本，這個在中後期表現特別明顯，隨著平台發展，業務方的需求源源不斷湧入，從鏈路上要對接數據、數據計算、存儲、後端介面封裝、前端展現等一系列開發工作，這就需要我們明確數據格式規範、對各環節的計算邏輯抽象，支持靈活的配置化工作等，有了通用化作為前提，大數據平台同學就可以專註鏈路架構上的優化，業務同學深度參與進來，這樣非常有利於平台的迭代。

2. 盲目調參

常規的參數調優，這是大數據工程師必須經歷的。對於初次進行大數據平台開發的同學，建議大家不要盲目調參，要看是哪個環節出現了瓶頸，是網路問題，計算資源問題，還是數據傾斜問題等，針對性的進行參數調整，效率會更快。

平台線上質量保證

測試領域有過幾個明顯階段，手工測試、自動化測試、再到持續集成，其實不外乎在追求更高的質量，更快的研發效率。但隨著移動互聯網高速發展，對於質量的要求要遠遠高於 PC 時代，測試人員的能力也需要隨之提升，不僅要對接常規的開發測試需求，還要關注產品效果、線上運維情況等，也就是說測試領域未來需要複合型人才。

我們都知道現在的移動互聯網產品迭代速度很快，各類設備的測試都要涵蓋到，單從通用的測試角度來說，就要考慮APP 啟動時間、頁面響應時間、頁面滑動流暢度、崩潰、卡頓、功耗等等，測試成本非常高，甚至大多數時候又回到了手工測試去驗證。那麼大數據能為測試帶來哪些幫助？

首先，我們將業務關注的數據進行埋點，可以是功能、性能、用戶體驗、用戶行為等等，這樣就保證了我們測試的結果和用戶感受基本一致，釋放了大部分的常規測試手段，如 UI 、性能、介面等。

其次，我們將數據流程分成：線下、灰度、線上三個階段進行保障，逐級利用真實設備的數據來保證質量，間接釋放了多機型測試不充分的問題。拿優酷播放卡頓指標問題來說，用戶觀看視頻出現一個等待圓圈開始到結束，就是一次卡頓，此時數據埋點紀錄這個卡頓時長並上報到大數據平台。這樣大數據平台就可以對這一指標做出各類質量方面的工作，比如：

一次播放中出現了多少次卡頓、卡頓平均時長是多少

卡頓超過多少的時候會導致用戶退出 App

卡頓分布在哪個網路是否有故障

新上線的版本卡頓是否有增加

對應大數據質量平台的功能，就大致分為實時度量、監控告警、數據分析、定位排查、灰度驗證等幾大部分。

監控告警

傳統的監控手段，對於伺服器性能指標、調用鏈路等已經相對成熟，一般發現異常就能夠確定原因。在移動互聯網時代，質量這個詞涵蓋的不單單是線上的故障，更多的是體驗。如果讓用戶感知的問題發現不及時或者沒有發現，所有的努力都會付之東流。

所以我們的重頭放在了客戶端埋點數據上，把播放體驗相關的埋點數據（卡頓、播放成功率）、性能指標數據（啟動時間、 Crash ）、關鍵服務返回數據（ CDN 節點數據）、用戶行為數據（點擊行為、停留行為）等進行分類計算抽象形成 CUBE ，把能夠反應在現象上的問題做成監控，來衡量我們的質量到底好還是壞。

在大數據質量平台，涉及到多維度計算，比如一次播放成功率下跌，具體是發生在安卓還是 iOS ？是全國範圍還是具體某一個省？是所有移動用戶還是聯通用戶出的問題？這就涉及到了我們如何對維度切片、鑽取，維度大了發現了問題也不好定位出原因，粒度小了對於存儲計算都是極大浪費。

這就需要結合業務來看，定義必選監控維度，然後將錯誤數據流通過 ETL 單獨切分，落盤到有聚合功能 ElasticSearch 、Druid 中，做到維度進一步細化，把告警從「大面」縮減到「小面」。比如說北京市聯通出現了播放成功率下跌，通過聚合發現，出錯 CDN IP 高度集中，告警層面就可以直接交給網路服務定位系統去處理了。此外，監控從實時性、準確性、告警條件模型都有一些探索，我們將在 QCon 的分享中和大家做進一步交流。

智能分析

現在各大公司都在做 Trace 相關工作，阿里優酷大數據平台也不例外。在原有的服務端日誌收集的基礎上，融合了客戶端埋點日誌、客戶端遠程 Debug 日誌、服務變更操作、以及規範了第三方服務日誌（ CDN 等）。這樣操作有利於統一收集已發現問題的數據；當數據在手，被明確告知是有問題的，我們該如何分析？

首先，如果是錯誤碼，我們一層一層看下去也能解決，但是有一些問題，不是錯誤導致的。舉個例子，某天，我們這收到一個客訴反饋說看視頻特別卡，突然出現的，我們查了日誌沒有任何報錯，最後是一位細心的同學發現，用戶網路 IP 在北京，CDN IP 被打到了廣州。對於這類問題，就是兩個 IP 字元串提取並作地域解析匹配即可。

其次，我們結合數據，要建立起一個定位知識庫，把歷史故障、線上 Bug 、badcase 抽象成我們的定位診斷庫。

第三，也是我們現在正在做的一些事情，知識庫是人建立起來的，其實這就好比監督學習，但我們想能不能用無監督學習的方式把問題定位出來呢？再舉個例子，我們會做一些大型活動，但是有時發現從第一個頁面跳轉到第二個頁面的用戶轉化率發出警報（只有 10% ），我們會把這一類的用戶進行全鏈路數據檢索（不只是服務端日誌），然後將各類特徵做聚類分析，就會驚奇的發現，絕大部份用戶會有共同的特徵被聚類出來，問題可能是可能關聯一個服務來自於同一台伺服器超時引起，也有可能是來自於同樣的客戶端設備因為頁面載入適配問題等。所以說，未來的方向重點在於數據和演算法結合起來，挖掘更大的價值。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！