從0到1建立基于大資料的品質平台受訪嘉賓介紹平台搭建背景平台搭建過程中“坑”平台線上品質保證監控告警智能分析

随着網際網路的快速發展，大資料與軟體品質的關系越來越密切，從源碼撰寫、持續內建、測試調試、釋出營運，整個流程中大資料無所不在。每個資料關聯起來對軟體品質中的發現、度量、定位都有着重要的價值。如何從 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% ），我們會把這一類的使用者進行全鍊路資料檢索（不隻是服務端日志），然後将各類特征做聚類分析，就會驚奇的發現，絕大部份使用者會有共同的特征被聚類出來，問題可能是可能關聯一個服務來自于同一台伺服器逾時引起，也有可能是來自于同樣的用戶端裝置因為頁面加載适配問題等。是以說，未來的方向重點在于資料和算法結合起來，挖掘更大的價值。

（本文轉自微信公衆号：InfoQ）