優酷背後的大數據祕密

在本文中優酷數據中臺的數據技術專家門德亮分享了優酷從Hadoop遷移到阿里雲MaxCompute後對業務及平臺的價值。

本文內容根據演講視頻以及PPT整理而成。

你們好，我是門德亮，如今在優酷數據中臺作數據相關的事情。很榮幸，我正好見證了優酷從沒有MaxCompute到有的這樣一個歷程，由於剛恰好我就是入職優酷差很少5年的時間，咱們正好是在快到5年的時候，去作了從Hadoop到MaxCompute的這樣一個升級。這個是2016年5月到2019年如今的5月優酷的發展歷程，上面是計算資源，下面是儲存資源。你們能夠看到整個用戶數，還有表的數據，其實是在呈一個指數式增加的。可是在2017年5月，當優酷完成了整個Hadoop遷移MaxCompute後，優酷的計算消耗，還有儲存的消耗其實是呈降低趨勢的，整個遷移獲得了一個很是大的收益。

下面說一下優酷的業務特色。

第一個特色從大數據平臺整個的用戶複雜度上面，不止是數據的同窗和技術的同窗在使用，還會包括一些BI同窗，測試同窗，甚至產品運營均可能去使用這個大數據的平臺。

第二個特色就是業務複雜，優酷是一個視頻網站，它有很是複雜的業務場景，從日誌分類上，除了像頁面瀏覽，還會有一些播放相關的數據、性能相關的數據。從整個的業務模式上，有直播、有會員、有廣告、有大屏等這樣一些很是不同的場景。

第三個特色，就是數據量是很是巨大的，一天的日誌量會達到千億級別，這是一個很是旁大的數據量，並且會作很是複雜的計算。

第四個是比較有意思的，不論是小公司、大公司，對成本的意識是很是高的。優酷也是有很是嚴格的預算，包括在阿里集團內是有很是嚴格的預算系統的，可是咱們也常常會去作一些重要的戰役，像雙十一戰役，像咱們暑期的世界盃戰役，還有春節也會搞各類戰役。這樣的話，其實對計算資源的彈性要求是很是高的。

基於上面的優酷的業務特色，我整理了MaxCompute能夠完美的支持咱們業務的幾個特色。

第一個，簡單易用。
第二個，完善的生態。
第三個，性能很是強悍。
第四個，資源使用很是彈性。

第一個特色，簡單易用。MaxCompute有一個很是完整的鏈路，不論是從數據開發，仍是數據運維，包括數據集成，數據質量的管控，還有整個數據地圖，數據安全。當年優酷從Hadoop遷到MaxCompute以後，咱們最大的體會是本身不用半夜常常起來去維護集羣了，不用去跑任務了，寫一個任務，別人以前提一個需求過來，我可能要給他排幾周，而如今我能夠告訴他，我給你立刻跑一下，就能夠出來了。包括以前像分析師BI還要登陸客戶端，寫腳本，本身寫調度，常常會說個人數今天爲何沒出來？包括高層看的數，可能要到12點鐘才能出來。而如今基本上全部重要的數據都會在7點鐘產出，包括一些基本的業務需求，其實分析師或者產品，他們本身均可以實現了，不須要全部需求都提到數據這邊。

第二個特色，完整的生態。優酷在2017年以前是徹底基於Hadoop的生態，遷到MaxCompute以後，是基於阿里雲提供的Serverless大數據服務的生態。你們能夠在開源上看到的組件，在整個的MaxCompute上都是有的，並且比開源的要更好用、更簡單。從架構圖上能夠看到，咱們中間是MaxCompute，左側依賴的Mysql、Hbase、ES、Redis這些都是由同步中心去作一個雙向的同步。右側會有資源管理、資源監控、數據監控，包括數據資產，還有一些數據規範。咱們下層的數據輸入，包括一些集團的採集工具，再往上邊，有提供給開發人員用的DataWorks，包括一些命令行的工具；有提供給BI人員用的QuickBI及數據服務。

第三個特色，強悍的性能，MaxCompute支撐了優酷EB級的數據存儲，千億級的數據樣本分析，包括千億級的數據報表，10W級實例的併發、任務。這些在以前維護Hadoop的時候，是想都不敢想的。

第四個特色，資源使用的彈性。咱們在2016年遷移以前，其實優酷的Hadoop集羣規模已經達到了一千多臺，這個當時仍是一個比較大的規模。當時咱們遇到了不少問題，包括像NameNode 這種內存的問題，機房沒有辦法再擴容的問題，當時是很是痛苦的，包括一些運維管理上面的問題。咱們不斷的去問運維要資源，運維告訴說，說大家已經花了多少多少資源，花了多少多少錢。咱們面臨的問題是計算資源如何按需使用，夜裏的時候做業不少，到了下午以後，個人整個集羣都空下來了，沒有人用，形成了浪費。其實MaxCompute完美的解決了這個問題。

第一個，它是按用量計費的，不是說給你多少臺機器，而後就收你多少錢的，真的是你用了多少資源收多少錢的，這個在成本上來講，比本身去維護集羣，多是一個砍半（降50%）這樣的收益。

第二個，實際上MaxCompue計算資源是能夠分時的，好比說生產隊列，凌晨的時候會調高一些，保證報表可以儘快出來。到白天時候，讓開發的計算資源高一些，可讓分析師、開發去臨時跑一些數據，會更順暢一些。

第三個，MaxCompute快速的擴容能力，好比說忽然有一個比較強的業務需求，發現數據跑不動了，計算資源不夠，全部的隊列都堵死了，這個時候其實能夠直接跟運維說一聲，幫忙一鍵擴容，他兩秒鐘敲一個命令就搞定了。這樣的話，全部的資源能夠迅速的消化下去。

上面是優酷爲何採用MaxCompute，下面是在優酷的業務場景下，咱們一些典型的方案、應用。這張圖其實是優酷，包括可能如今阿里集團內部一些很是典型的技術架構圖。中間能夠看到，MaxCompute在中間核心的位置，左側主要是一個輸入，右側是一個輸出的趨向，綠色的線是一個實時的鏈路，包括如今咱們從整個的數據源上，好比DB也好或者服務器的本地日誌Log也好，咱們經過TT&Datahub存儲到MaxCompute上面作分析。固然如今很是火的Flink實時計算，實際上是做爲一個實時處理的鏈路。

包括DB的同步，除了實時的鏈路，DB也會去經過按天/按小時，把數據同步到MaxCompute，數據計算結果也能夠同步到Hbase、Mysql這種DB上面。再經過統一的服務層對應用提供服務。下面這個是機器學習Pai作的一些算法訓練，再把訓練的結果經過OSS傳到一個算法的應用上面去。

這張圖可能也是業界比較流行的一個數倉分層的圖，由於咱們這邊是數據中臺，全部的數據都是統一從ods層cdm層，而後ads層，去一層一層的往上去作精細，再到最上面，經過接口服務、文件服務、SQL服務，去提供多樣化的服務。再往上面，提供對內的一些數據產品，對高管、對小二，可能還有一些對外的，好比說像優酷的播放數，包括熱度這些對應用的數據。

這張圖其實就是咱們從Hadoop遷到MaxCompute平臺上以來，兩個很是經典的案例。咱們經過數據中臺對不一樣場景的用戶打通，來去賦能到兩個不一樣的場景，提高業務價值。

第二個，多是內部的，咱們經過優酷，還有集團內部的一些BU去作換量，咱們經過統一的標籤去作樣本放大，把優酷的量導給其它的BU，把其它BU的量導給優酷，這樣去達到一個雙贏的效果。

這張圖大部分互聯網公司不太會涉及到，就是關於反做弊的問題。這個是咱們在MaxCompute作的一個反做弊的架構，經過原始的數據去提取它的特徵，而後再經過算法模型，包括機器學習、深度學習、圖模型去支持流量反做弊、渠道反做弊等等。再經過業務場景上反做弊的監控工具，把監控到的做弊信息去打一個黑白樣本，再把這個黑白樣本跟特徵一塊兒來不斷的迭代優化算法模型。同時針對算法模型，作一個模型的評價，不斷來完善反做弊體系。

最後一點，其實仍是跟成本相關，在平常使用中，必定是有小白用戶或者一些新來的用戶去錯誤的使用或者不在意的使用一些資源，好比常常會有一些實習生或者是非技術的同窗，如分析師，一個SQL消費比較高，這個實際上是很是浪費資源，並且可能他一個任務，讓其餘全部人的任務都在這兒等着排隊，實際上咱們會去對整個的資源作一個治理。

從節點的粒度上，經過大數據來治理大數據，咱們能夠算出哪些表產出來以後，多少天沒有被讀取的，包括它的訪問跨度可能沒有那麼大的，咱們會去作下線或者去作治理，有一些業務場景可能並非很是的重要或者它的時間要求沒有那麼高，好比一些算法訓練，能夠去作一些錯峯的調度，保證水位不要過高。從MaxCompute任務的角度，能夠算出哪些任務有數據傾斜、哪些數據可能會有類似計算，哪些任務須要去作MapJoin，哪些任務須要去作一些裁剪，而後來節省它的IO。還有哪些任務會去作暴力掃描，掃一個月、掃一年的數據，哪些數據可能會有這樣一個數據膨脹，好比說它作了CUBE之類的這種複雜計算，一些算法模型的迭代；咱們經過數據計算出來的這些跡象，去反推用戶，來去提升它的這樣一個數據的質量分，來去達到咱們下降整個計算資源的目的。

在計算平臺的角度，咱們也持續的在使用MaxCompute推出的一些很是高級的用法，好比咱們這邊的HBO、Hash Cluster、Aliorc，HBO就是咱們基於一個歷史的優化，這樣避免了用戶不知道怎麼調參，我可能爲了本身任務快一點，就調一個特別大的參數，這樣的話，對集成的資源是很是浪費的。經過這個功能，用戶就不用去調參數，集羣自動調好，用戶就寫好本身業務邏輯就行了。

第二塊，可能就是最近兩年推出的Hash Cluster，當時在使用Hadoop的時候常常會出現，兩個大表Join的時候計算不出來，這個Hash Cluster實際上是一個優化的利器。大表跟小表Join，能夠作一些分發，作一些優化。大表跟大表就涉及到一個排序的問題。這個Hash Cluster，實際上就是提早把數據排好，中間省掉不少計算環節，來達到效率提高的目的。

第三個，Aliorc，在一些固定的場景上面，能夠穩定的提高20%的計算效率。

第四個，Session。對一些比較小的數據，直接就放到SSD或緩存裏面，一個節點下游有100個葉子場景，是很是友好的，由於低延遲秒出結果。同時，優酷也在使用Lightning解決計算加速，這個是在一個計算架構方案上的優化，它是一個MPP的架構。

最後一頁是存儲的優化，由於像一些關鍵的原始數據或者是須要審計的數據是不能刪的，永久不能刪的。實際上就會形成咱們數據存儲的趨勢是一直往上不減的，計算會在某一個時間點達到一個平衡。當前用這麼多的計算資源，再日後，其實應該也不會再大漲了，好比說舊的業務邏輯下掉了，會換新的業務邏輯，這樣會保持在一個相對平穩的波動上面。可是儲存，由於它有一些歷史的數據是永遠不能刪的，可能會出現一直在增加，並且是指數級的。因此咱們也會持續關注存儲的狀況，咱們主要有四個手段。

第一個，仍是經過大數據來治大數據，去看哪些表它的訪問不夠或者它的訪問跨度不夠。就是對一些生命週期的優化，來去控制它的增速。包括下面的，剛纔提到的Aliorc，其實是作壓縮的，咱們會去作一些大字段的拆分，來提升壓縮的比例。

OK，這個是優酷在MaxCompute中的一些應用場景，感謝你們的聆聽。

---

本文做者：隱林

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。