优酷背后的大数据秘密
在本文中優(yōu)酷數(shù)據(jù)中臺(tái)的數(shù)據(jù)技術(shù)專家門德亮分享了優(yōu)酷從Hadoop遷移到阿里云MaxCompute后對業(yè)務(wù)及平臺(tái)的價(jià)值。
本文內(nèi)容根據(jù)演講視頻以及PPT整理而成。
大家好,我是門德亮,現(xiàn)在在優(yōu)酷數(shù)據(jù)中臺(tái)做數(shù)據(jù)相關(guān)的事情。很榮幸,我正好見證了優(yōu)酷從沒有MaxCompute到有的這樣一個(gè)歷程,因?yàn)閯倓偤梦揖褪侨肼殐?yōu)酷差不多5年的時(shí)間,我們正好是在快到5年的時(shí)候,去做了從Hadoop到MaxCompute的這樣一個(gè)升級。這個(gè)是2016年5月到2019年現(xiàn)在的5月優(yōu)酷的發(fā)展歷程,上面是計(jì)算資源,下面是儲(chǔ)存資源。大家可以看到整個(gè)用戶數(shù),還有表的數(shù)據(jù),實(shí)際上是在呈一個(gè)指數(shù)式增長的。但是在2017年5月,當(dāng)優(yōu)酷完成了整個(gè)Hadoop遷移MaxCompute后,優(yōu)酷的計(jì)算消耗,還有儲(chǔ)存的消耗實(shí)際上是呈下降趨勢的,整個(gè)遷移得到了一個(gè)非常大的收益。
下面說一下優(yōu)酷的業(yè)務(wù)特點(diǎn)。
第一個(gè)特點(diǎn)從大數(shù)據(jù)平臺(tái)整個(gè)的用戶復(fù)雜度上面,不止是數(shù)據(jù)的同學(xué)和技術(shù)的同學(xué)在使用,還會(huì)包括一些BI同學(xué),測試同學(xué),甚至產(chǎn)品運(yùn)營都可能去使用這個(gè)大數(shù)據(jù)的平臺(tái)。
第二個(gè)特點(diǎn)就是業(yè)務(wù)復(fù)雜,優(yōu)酷是一個(gè)視頻網(wǎng)站,它有非常復(fù)雜的業(yè)務(wù)場景,從日志分類上,除了像頁面瀏覽,還會(huì)有一些播放相關(guān)的數(shù)據(jù)、性能相關(guān)的數(shù)據(jù)。從整個(gè)的業(yè)務(wù)模式上,有直播、有會(huì)員、有廣告、有大屏等這樣一些非常不一樣的場景。
第三個(gè)特點(diǎn),就是數(shù)據(jù)量是非常巨大的,一天的日志量會(huì)達(dá)到千億級別,這是一個(gè)非常旁大的數(shù)據(jù)量,而且會(huì)做非常復(fù)雜的計(jì)算。
第四個(gè)是比較有意思的,不管是小公司、大公司,對成本的意識(shí)是非常高的。優(yōu)酷也是有非常嚴(yán)格的預(yù)算,包括在阿里集團(tuán)內(nèi)是有非常嚴(yán)格的預(yù)算系統(tǒng)的,但是我們也經(jīng)常會(huì)去做一些重要的戰(zhàn)役,像雙十一戰(zhàn)役,像我們暑期的世界杯戰(zhàn)役,還有春節(jié)也會(huì)搞各種戰(zhàn)役。這樣的話,其實(shí)對計(jì)算資源的彈性要求是非常高的。
基于上面的優(yōu)酷的業(yè)務(wù)特點(diǎn),我整理了MaxCompute可以完美的支持我們業(yè)務(wù)的幾個(gè)特點(diǎn)。
第一個(gè),簡單易用。
第二個(gè),完善的生態(tài)。
第三個(gè),性能非常強(qiáng)悍。
第四個(gè),資源使用非常彈性。
第一個(gè)特點(diǎn),簡單易用。MaxCompute有一個(gè)非常完整的鏈路,不管是從數(shù)據(jù)開發(fā),還是數(shù)據(jù)運(yùn)維,包括數(shù)據(jù)集成,數(shù)據(jù)質(zhì)量的管控,還有整個(gè)數(shù)據(jù)地圖,數(shù)據(jù)安全。當(dāng)年優(yōu)酷從Hadoop遷到MaxCompute之后,我們最大的體會(huì)是自己不用半夜經(jīng)常起來去維護(hù)集群了,不用去跑任務(wù)了,寫一個(gè)任務(wù),別人之前提一個(gè)需求過來,我可能要給他排幾周,而現(xiàn)在我可以告訴他,我給你馬上跑一下,就可以出來了。包括之前像分析師BI還要登錄客戶端,寫腳本,自己寫調(diào)度,經(jīng)常會(huì)說我的數(shù)今天為什么沒出來?包括高層看的數(shù),可能要到12點(diǎn)鐘才能出來。而現(xiàn)在基本上所有重要的數(shù)據(jù)都會(huì)在7點(diǎn)鐘產(chǎn)出,包括一些基本的業(yè)務(wù)需求,其實(shí)分析師或者產(chǎn)品,他們自己都可以實(shí)現(xiàn)了,不需要所有需求都提到數(shù)據(jù)這邊。
第二個(gè)特點(diǎn),完整的生態(tài)。優(yōu)酷在2017年之前是完全基于Hadoop的生態(tài),遷到MaxCompute之后,是基于阿里云提供的Serverless大數(shù)據(jù)服務(wù)的生態(tài)。大家可以在開源上看到的組件,在整個(gè)的MaxCompute上都是有的,而且比開源的要更好用、更簡單。從架構(gòu)圖上可以看到,我們中間是MaxCompute,左側(cè)依賴的Mysql、Hbase、ES、Redis這些都是由同步中心去做一個(gè)雙向的同步。右側(cè)會(huì)有資源管理、資源監(jiān)控、數(shù)據(jù)監(jiān)控,包括數(shù)據(jù)資產(chǎn),還有一些數(shù)據(jù)規(guī)范。我們下層的數(shù)據(jù)輸入,包括一些集團(tuán)的采集工具,再往上邊,有提供給開發(fā)人員用的DataWorks,包括一些命令行的工具;有提供給BI人員用的QuickBI及數(shù)據(jù)服務(wù)。
第三個(gè)特點(diǎn),強(qiáng)悍的性能,MaxCompute支撐了優(yōu)酷EB級的數(shù)據(jù)存儲(chǔ),千億級的數(shù)據(jù)樣本分析,包括千億級的數(shù)據(jù)報(bào)表,10W級實(shí)例的并發(fā)、任務(wù)。這些在之前維護(hù)Hadoop的時(shí)候,是想都不敢想的。
第四個(gè)特點(diǎn),資源使用的彈性。我們在2016年遷移之前,其實(shí)優(yōu)酷的Hadoop集群規(guī)模已經(jīng)達(dá)到了一千多臺(tái),這個(gè)當(dāng)時(shí)還是一個(gè)比較大的規(guī)模。當(dāng)時(shí)我們遇到了很多問題,包括像NameNode 這種內(nèi)存的問題,機(jī)房沒有辦法再擴(kuò)容的問題,當(dāng)時(shí)是非常痛苦的,包括一些運(yùn)維管理上面的問題。我們不斷的去問運(yùn)維要資源,運(yùn)維告訴說,說你們已經(jīng)花了多少多少資源,花了多少多少錢。我們面臨的問題是計(jì)算資源如何按需使用,夜里的時(shí)候作業(yè)很多,到了下午之后,我的整個(gè)集群都空下來了,沒有人用,造成了浪費(fèi)。其實(shí)MaxCompute完美的解決了這個(gè)問題。
第一個(gè),它是按用量計(jì)費(fèi)的,不是說給你多少臺(tái)機(jī)器,然后就收你多少錢的,真的是你用了多少資源收多少錢的,這個(gè)在成本上來說,比自己去維護(hù)集群,可能是一個(gè)砍半(降50%)這樣的收益。
第二個(gè),實(shí)際上MaxCompue計(jì)算資源是可以分時(shí)的,比如說生產(chǎn)隊(duì)列,凌晨的時(shí)候會(huì)調(diào)高一些,保證報(bào)表能夠盡快出來。到白天時(shí)候,讓開發(fā)的計(jì)算資源高一些,可以讓分析師、開發(fā)去臨時(shí)跑一些數(shù)據(jù),會(huì)更順暢一些。
第三個(gè),MaxCompute快速的擴(kuò)容能力,比如說突然有一個(gè)比較強(qiáng)的業(yè)務(wù)需求,發(fā)現(xiàn)數(shù)據(jù)跑不動(dòng)了,計(jì)算資源不夠,所有的隊(duì)列都堵死了,這個(gè)時(shí)候其實(shí)可以直接跟運(yùn)維說一聲,幫忙一鍵擴(kuò)容,他兩秒鐘敲一個(gè)命令就搞定了。這樣的話,所有的資源可以迅速的消化下去。
上面是優(yōu)酷為什么采用MaxCompute,下面是在優(yōu)酷的業(yè)務(wù)場景下,我們一些典型的方案、應(yīng)用。這張圖實(shí)際上是優(yōu)酷,包括可能現(xiàn)在阿里集團(tuán)內(nèi)部一些非常典型的技術(shù)架構(gòu)圖。中間可以看到,MaxCompute在中間核心的位置,左側(cè)主要是一個(gè)輸入,右側(cè)是一個(gè)輸出的趨向,綠色的線是一個(gè)實(shí)時(shí)的鏈路,包括現(xiàn)在我們從整個(gè)的數(shù)據(jù)源上,比如DB也好或者服務(wù)器的本地日志Log也好,我們通過TT&Datahub存儲(chǔ)到MaxCompute上面做分析。當(dāng)然現(xiàn)在非常火的Flink實(shí)時(shí)計(jì)算,其實(shí)是作為一個(gè)實(shí)時(shí)處理的鏈路。
包括DB的同步,除了實(shí)時(shí)的鏈路,DB也會(huì)去通過按天/按小時(shí),把數(shù)據(jù)同步到MaxCompute,數(shù)據(jù)計(jì)算結(jié)果也可以同步到Hbase、Mysql這種DB上面。再通過統(tǒng)一的服務(wù)層對應(yīng)用提供服務(wù)。下面這個(gè)是機(jī)器學(xué)習(xí)Pai做的一些算法訓(xùn)練,再把訓(xùn)練的結(jié)果通過OSS傳到一個(gè)算法的應(yīng)用上面去。
這張圖可能也是業(yè)界比較流行的一個(gè)數(shù)倉分層的圖,因?yàn)槲覀冞@邊是數(shù)據(jù)中臺(tái),所有的數(shù)據(jù)都是統(tǒng)一從ods層cdm層,然后ads層,去一層一層的往上去做精細(xì),再到最上面,通過接口服務(wù)、文件服務(wù)、SQL服務(wù),去提供多樣化的服務(wù)。再往上面,提供對內(nèi)的一些數(shù)據(jù)產(chǎn)品,對高管、對小二,可能還有一些對外的,比如說像優(yōu)酷的播放數(shù),包括熱度這些對應(yīng)用的數(shù)據(jù)。
這張圖其實(shí)就是我們從Hadoop遷到MaxCompute平臺(tái)上以來,兩個(gè)非常經(jīng)典的案例。我們通過數(shù)據(jù)中臺(tái)對不同場景的用戶打通,來去賦能到兩個(gè)不同的場景,提升業(yè)務(wù)價(jià)值。
第二個(gè),可能是內(nèi)部的,我們通過優(yōu)酷,還有集團(tuán)內(nèi)部的一些BU去做換量,我們通過統(tǒng)一的標(biāo)簽去做樣本放大,把優(yōu)酷的量導(dǎo)給其它的BU,把其它BU的量導(dǎo)給優(yōu)酷,這樣去達(dá)到一個(gè)共贏的效果。
這張圖大部分互聯(lián)網(wǎng)公司不太會(huì)涉及到,就是關(guān)于反作弊的問題。這個(gè)是我們在MaxCompute做的一個(gè)反作弊的架構(gòu),通過原始的數(shù)據(jù)去提取它的特征,然后再通過算法模型,包括機(jī)器學(xué)習(xí)、深度學(xué)習(xí)、圖模型去支持流量反作弊、渠道反作弊等等。再通過業(yè)務(wù)場景上反作弊的監(jiān)控工具,把監(jiān)控到的作弊信息去打一個(gè)黑白樣本,再把這個(gè)黑白樣本跟特征一起來不斷的迭代優(yōu)化算法模型。同時(shí)針對算法模型,做一個(gè)模型的評價(jià),不斷來完善反作弊體系。
最后一點(diǎn),其實(shí)還是跟成本相關(guān),在日常使用中,一定是有小白用戶或者一些新來的用戶去錯(cuò)誤的使用或者不在乎的使用一些資源,比如經(jīng)常會(huì)有一些實(shí)習(xí)生或者是非技術(shù)的同學(xué),如分析師,一個(gè)SQL消費(fèi)比較高,這個(gè)其實(shí)是非常浪費(fèi)資源,而且可能他一個(gè)任務(wù),讓其他所有人的任務(wù)都在這兒等著排隊(duì),實(shí)際上我們會(huì)去對整個(gè)的資源做一個(gè)治理。
從節(jié)點(diǎn)的粒度上,通過大數(shù)據(jù)來治理大數(shù)據(jù),我們可以算出哪些表產(chǎn)出來之后,多少天沒有被讀取的,包括它的訪問跨度可能沒有那么大的,我們會(huì)去做下線或者去做治理,有一些業(yè)務(wù)場景可能并不是非常的重要或者它的時(shí)間要求沒有那么高,比如一些算法訓(xùn)練,可以去做一些錯(cuò)峰的調(diào)度,保證水位不要太高。從MaxCompute任務(wù)的角度,可以算出哪些任務(wù)有數(shù)據(jù)傾斜、哪些數(shù)據(jù)可能會(huì)有相似計(jì)算,哪些任務(wù)需要去做MapJoin,哪些任務(wù)需要去做一些裁剪,然后來節(jié)省它的IO。還有哪些任務(wù)會(huì)去做暴力掃描,掃一個(gè)月、掃一年的數(shù)據(jù),哪些數(shù)據(jù)可能會(huì)有這樣一個(gè)數(shù)據(jù)膨脹,比如說它做了CUBE之類的這種復(fù)雜計(jì)算,一些算法模型的迭代;我們通過數(shù)據(jù)計(jì)算出來的這些跡象,去反推用戶,來去提高它的這樣一個(gè)數(shù)據(jù)的質(zhì)量分,來去達(dá)到我們降低整個(gè)計(jì)算資源的目的。
在計(jì)算平臺(tái)的角度,我們也持續(xù)的在使用MaxCompute推出的一些非常高級的用法,比如我們這邊的HBO、Hash Cluster、Aliorc,HBO就是我們基于一個(gè)歷史的優(yōu)化,這樣避免了用戶不知道怎么調(diào)參,我可能為了自己任務(wù)快一點(diǎn),就調(diào)一個(gè)特別大的參數(shù),這樣的話,對集成的資源是非常浪費(fèi)的。通過這個(gè)功能,用戶就不用去調(diào)參數(shù),集群自動(dòng)調(diào)好,用戶就寫好自己業(yè)務(wù)邏輯就好了。
第二塊,可能就是最近兩年推出的Hash Cluster,當(dāng)時(shí)在使用Hadoop的時(shí)候經(jīng)常會(huì)出現(xiàn),兩個(gè)大表Join的時(shí)候計(jì)算不出來,這個(gè)Hash Cluster其實(shí)是一個(gè)優(yōu)化的利器。大表跟小表Join,可以做一些分發(fā),做一些優(yōu)化。大表跟大表就涉及到一個(gè)排序的問題。這個(gè)Hash Cluster,實(shí)際上就是提前把數(shù)據(jù)排好,中間省掉很多計(jì)算環(huán)節(jié),來達(dá)到效率提升的目的。
第三個(gè),Aliorc,在一些固定的場景上面,可以穩(wěn)定的提升20%的計(jì)算效率。
第四個(gè),Session。對一些比較小的數(shù)據(jù),直接就放到SSD或緩存里面,一個(gè)節(jié)點(diǎn)下游有100個(gè)葉子場景,是非常友好的,因?yàn)榈脱舆t秒出結(jié)果。同時(shí),優(yōu)酷也在使用Lightning解決計(jì)算加速,這個(gè)是在一個(gè)計(jì)算架構(gòu)方案上的優(yōu)化,它是一個(gè)MPP的架構(gòu)。
最后一頁是存儲(chǔ)的優(yōu)化,因?yàn)橄褚恍╆P(guān)鍵的原始數(shù)據(jù)或者是需要審計(jì)的數(shù)據(jù)是不能刪的,永久不能刪的。實(shí)際上就會(huì)造成我們數(shù)據(jù)存儲(chǔ)的趨勢是一直往上不減的,計(jì)算會(huì)在某一個(gè)時(shí)間點(diǎn)達(dá)到一個(gè)平衡。當(dāng)前用這么多的計(jì)算資源,再往后,其實(shí)應(yīng)該也不會(huì)再大漲了,比如說舊的業(yè)務(wù)邏輯下掉了,會(huì)換新的業(yè)務(wù)邏輯,這樣會(huì)保持在一個(gè)相對平穩(wěn)的波動(dòng)上面。但是儲(chǔ)存,因?yàn)樗幸恍v史的數(shù)據(jù)是永遠(yuǎn)不能刪的,可能會(huì)出現(xiàn)一直在增長,而且是指數(shù)級的。所以我們也會(huì)持續(xù)關(guān)注存儲(chǔ)的情況,我們主要有四個(gè)手段。
第一個(gè),還是通過大數(shù)據(jù)來治大數(shù)據(jù),去看哪些表它的訪問不夠或者它的訪問跨度不夠。就是對一些生命周期的優(yōu)化,來去控制它的增速。包括下面的,剛才提到的Aliorc,實(shí)際上是做壓縮的,我們會(huì)去做一些大字段的拆分,來提高壓縮的比例。
OK,這個(gè)是優(yōu)酷在MaxCompute中的一些應(yīng)用場景,感謝大家的聆聽。
原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容,未經(jīng)允許不得轉(zhuǎn)載。
總結(jié)
以上是生活随笔為你收集整理的优酷背后的大数据秘密的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Spark Relational Cac
- 下一篇: 闲鱼如何利用端计算提升推荐场景的ctr