2016年4月23日下午，華為開發(fā)者社區(qū)攜手51CTO在魔都上海啟動了“華為開發(fā)者匯”的第一場沙龍。本次活動共邀請了華為公司、星網(wǎng)信通、優(yōu)酷土豆的五位講師做了分享。其中，來自優(yōu)酷土豆大數(shù)據(jù)平臺的高級架構(gòu)師楊大海分享了他在優(yōu)土所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展歷程。里面從前后端的技術(shù)選型一直講到自己遇到的Hadoop問題和挑戰(zhàn)。讓大家領(lǐng)略到大型視頻網(wǎng)站在數(shù)據(jù)處理方面的不易之處，相信大家在看到楊老師填過的坑之后，能少走很多彎路。

現(xiàn)場實錄如下：

楊大海：感謝大家。我先介紹一下我今天分享的內(nèi)容。因為我這個團隊是從12年開始去做，經(jīng)過將近五年的時間，從零開始，做到支撐整個集團的數(shù)據(jù)平臺團隊。我目前為止還是在優(yōu)酷，現(xiàn)在的話給我們一個合作伙伴，然后獨立出來一家公司，現(xiàn)在還沒有開始推廣，也是一家做大數(shù)據(jù)的公司，包括數(shù)據(jù)平臺、用戶精準運營、網(wǎng)站流量運營這一塊的東西，算是一個硬廣吧。然后這一塊，我拿PPT，就是上周在背景之上，51CTO一次的技術(shù)論壇，我給他們分享的模板，但是內(nèi)容是重新又開始做的。

我先介紹一下我們這個團隊的情況。我們是一個做技術(shù)平臺的團隊，因為前面兩位老師已經(jīng)介紹過，第一是搭建了這么一套內(nèi)部的類似于github的管理平臺。莊老師也介紹了一些軟件管理、軟件開發(fā)的一些系統(tǒng)管理方面的經(jīng)驗。我這邊就是一個實現(xiàn)，就是非?？啾频囊粋€實現(xiàn)。我們這個團隊主要支撐的是，整個優(yōu)酷、土豆視頻的日志收集。這個日志包括網(wǎng)站前端所有的點擊日志，就是你點了哪些按紐，瀏覽了哪些頁面。另外一些是視頻播放，你看了什么視頻，看了多長時間，什么時間開始看的，然后在什么時間點了拖拽，快進了，還是又拖回來了，然后什么節(jié)點的廣告等等，就是所有的行為日志，大概每天30個T左右。然后現(xiàn)在的集群規(guī)模，現(xiàn)在做了存儲，整個集群現(xiàn)在也做了一千多臺了。整個存儲一千多臺的機器，整個存儲擴到38T，現(xiàn)在用到的存儲將近30個T，其實使用率還是蠻高的。另外支撐服務(wù)，第一是日志收集的服務(wù)，需要把網(wǎng)站這么多的日志收集過來，第二這些日志需要很快的存儲到不同平臺上去。第一個，就是我剛才說的(02：40英語)平臺，需要把這些日志給存上去。另外有一些我們有實時計算的東西，所以需要類似于卡夫卡的消息隊列里面。然后計算模型的話，這一塊是指我們會基于(02：55英語)等等這些開源的系統(tǒng)，在它上面搭建一些平臺和一些管理系統(tǒng)運營，來支撐其他團隊的業(yè)務(wù)開發(fā)。

我先介紹一下這個前提，因為當一個業(yè)務(wù)團隊去開發(fā)一個業(yè)務(wù)系統(tǒng)的時候，你不能要求他，你這邊團隊需要一個懂hadoop的人去搭建一套hadoop平臺。再需要一些懂緩存的人，搭建一套緩存系統(tǒng)，當然這個在這樣的公司，是不現(xiàn)實的，在團隊內(nèi)部也是不現(xiàn)實的，所以才有我們這個團隊出現(xiàn)。然后我們提供了一堆平臺，然后你們用的話，就是在我們內(nèi)部系統(tǒng)里面申請一個賬號接入，然后申請直接去用就好了，服務(wù)器什么都不用管。緩存就是我們自己搭建的一套緩存系統(tǒng)，每天就是支持的QPS將近兩千億左右。隊列的話，也是基于開源卡夫卡去做的。監(jiān)控的話，剛開始我們自己開發(fā)了一個名字叫天眼鏡(音)的監(jiān)控系統(tǒng)，可以接入所有這些分布式平臺的監(jiān)控，包括業(yè)務(wù)監(jiān)控、流量監(jiān)控等等，但是后來做著發(fā)現(xiàn)，我們做了一件和外面一個開源的系統(tǒng)非常像的一件東西，所以我們現(xiàn)在又重建搭了一套?，F(xiàn)在支撐的業(yè)務(wù)系統(tǒng)，有廣告系統(tǒng)、推薦系統(tǒng)，來瘋就是我們現(xiàn)在優(yōu)酷的直播，類似于六間房的直播。移動就是我們APP的業(yè)務(wù)，openApi前面智勇提到過，其實就是公司對外的一個數(shù)據(jù)接口的平臺，其實量還蠻大的。然后云娛樂，就是優(yōu)酷最近做的廣告盒子，游戲?qū)Я鬟@塊的業(yè)務(wù)。其實我們這個平臺，基本上支撐了，優(yōu)酷80%以上的團隊。

其實現(xiàn)在我來分享的目的是，告訴大家我們組建這么一個團隊，把這個經(jīng)驗分享給大家，因為我自己獨立出來做這個數(shù)據(jù)公司的時候，因為我現(xiàn)在還沒有完全離職。到下一周的周五，可能是我工作的最后一天。剛剛?cè)A為的兩位老師已經(jīng)說了，他們可能是僅代表的是個人觀點，然后星網(wǎng)的這位哥們說了，他代表的是公司觀點，如果我講的對的話，可以代表公司的觀點，如果講的不對的話，僅代表個人觀點。然后這個問題是因為，我自己做公司的時候發(fā)現(xiàn)之前有過一些培訓(xùn)機構(gòu)，包括51CTO、(05：34英語)等一些做大數(shù)據(jù)的開源社區(qū)里面，有一些合作，他們這邊會推薦我跟客戶去解釋一些問題，但是我發(fā)現(xiàn)客戶一些問題是非常多的。因為他們從一個做傳統(tǒng)企業(yè)的應(yīng)用團隊，突然間接了一些大數(shù)據(jù)的項目，需要做大數(shù)據(jù)的工作，然后發(fā)現(xiàn)第一就是技術(shù)儲備不足。為什么說技術(shù)儲備不足?我跟他講過你要用hadoop，要用這些東西可以解決現(xiàn)在的問題，他告訴我這些東西我們都沒玩過，突然你給我介紹這么十幾套開源的系統(tǒng)進來，然后在后面完全是一個黑匣子，我不敢用。包括很大的企業(yè)，像中電普華開源下面的一家國企，挺大的一個企業(yè)，他們營銷處的主任這么跟我說的，另外一個他接到項目以后，時間周期是非常有限的。他沒有時間再去，從一個零都沒有的團隊，從研究這個技術(shù)到市場投入使用，是這么一個情況。

然后技術(shù)選型上面，現(xiàn)在基于大數(shù)據(jù)的技術(shù)越來越多了，這些技術(shù)也是非常雜亂，其實每個技術(shù)都有它自己的特點，但是我們拿了這個方案去和客戶講了的時候，客戶會覺得，我之先就用一個java，或者用一個.net什么，就開發(fā)一套系統(tǒng)，頂多有一套數(shù)據(jù)庫、緩存技術(shù)，但是你現(xiàn)在突然間告訴我，我用這么一堆的開源東西，我真不敢用。其實就是一個技術(shù)種類繁雜，他們在選擇的時候，出現(xiàn)迷茫，就是說這個查詢，我可以用ES去實現(xiàn)，也可以用(07：15英語)，也可以用HB實現(xiàn)，我深知可以用(07：14英語)實現(xiàn)，我怎么去選擇的一個問題，其實每個技術(shù)都有它自己的特點，當然這里面不排除，比如說(07：23英語)都能干成同樣的事情，但是你的團隊更適用于哪些技術(shù)，你的團隊哪些技術(shù)里面有特長，出了問題我們更好解決，這是一方面。另外一個就是適應(yīng)場景。有的技術(shù)，大家用來解決相同的問題，但是有的技術(shù)架構(gòu)比較艱難，用來解決數(shù)據(jù)量不是太大的問題。有些技術(shù)他搭建這么一套系統(tǒng)，他的系統(tǒng)本來設(shè)計也特別復(fù)雜，因為分布式系統(tǒng)越完善，他設(shè)計越復(fù)雜，因為他要為他分布式，包括為他的高可用、高并發(fā)來付出很大的精力去這些這塊的東西，就造成他的系統(tǒng)非常復(fù)雜。所以在這一塊，使用場景你是不是需要這么一套更復(fù)雜的系統(tǒng)?因為你的數(shù)據(jù)量非常大，其實就是根據(jù)我們不同的業(yè)務(wù)場景，不同的數(shù)據(jù)場景去來挑選的。

另外一塊，就是服務(wù)的挑戰(zhàn)。為什么說服務(wù)的挑戰(zhàn)?就是說之前的話，比如說華為和移動做了一套(08：18英語)系統(tǒng)，上線之后現(xiàn)場需要運維在那兒運維著，大部分的開發(fā)就撤出來了，但是你上這么一套系統(tǒng)，給客戶上了之后，這個hadoop的玩意兒，Stor指不定哪天掛了一個節(jié)點，或者你需要處理了，這些東西我們專業(yè)做服務(wù)運維的團隊，不一定能去解決，甚至是需要開發(fā)，就是更專業(yè)的一些做開發(fā)的去解決這些問題。然后并不是說你重啟一下就能解問題的。另外一個，就是我剛才提到的易控、簡單，找最適合，最簡單的方案。因為越復(fù)雜的話，出了問題之后其實坑是越大。

然后系統(tǒng)特征，基于大數(shù)據(jù)的系統(tǒng)特征，往往有一個，就是分布式，為什么我們一直在推廣分布式?因為分布式可以橫向拓展、縱向拓展。它的拓展能夠滿足你，數(shù)據(jù)量日益遞增的需求，能滿足你的吞吐量的需求，但是它做到分布式之后，這個系統(tǒng)在設(shè)計的時候，因為要滿足分布式，滿足你本身業(yè)務(wù)需求的情況下做了很多基于分布式這塊的設(shè)計。因為它要跨多個虛擬機甚至多個服務(wù)器來做，甚至多個機房來做這件事情。假如說我舉一個例子，本來這個系統(tǒng)在一個機房都能搞定的，你類似于阿力的ODPS，現(xiàn)在他們要跨多個機房，機房之間的帶寬問題怎么解決等等，這 問題基于分布式的特性，需要去考慮的。

然后高吞吐量，因為這些系統(tǒng)往往一天需要處理多大的數(shù)據(jù)量，這樣的一個系統(tǒng)，我們需要對它進行不斷的優(yōu)化。為什么呢?可能我們一套系統(tǒng)在一千臺機器或者兩千臺機器上去搭建，如果我們提供10%的性能，我們可能剩了兩百臺服務(wù)器，這一點是非常樂觀的。另外一點高可用，因為高可用的話，也就是說我平臺越大，我的業(yè)務(wù)越多，那就需要保證我這個平臺足夠的穩(wěn)定，如果這個平臺出現(xiàn)某一天宕機或者有一個小時不可用，這個帶來的問題是非常大的。其實在一個月前，美團的緩存系統(tǒng)，他用的是淘寶(10：33英語)緩存系統(tǒng)出現(xiàn)問題，整個持續(xù)恢復(fù)了一個過程，好好壞壞的過程，持續(xù)了將近一周，這個影響是非常大的。所以就需要做高可用，高可用這塊，我們需要做多機房，多活等等的方案，這里面我對系統(tǒng)的設(shè)計提高更高的要求，所以就導(dǎo)致分布式系統(tǒng)非常復(fù)雜。另外一個就是大規(guī)模。大規(guī)模的話，也就是說這個系統(tǒng)，可能去滿足我們比如說整個網(wǎng)站等等這些非常大規(guī)模的業(yè)務(wù)，或者是數(shù)據(jù)這種需求。最后這個不穩(wěn)定，我加了引號，并不是說這個系統(tǒng)不穩(wěn)定，因為他加了這么多因素，這么多業(yè)務(wù)額外的工作在系統(tǒng)里面，就導(dǎo)致這個系統(tǒng)出現(xiàn)問題的可能性比較大。我舉一個例子，如果你這個系統(tǒng)基于一臺服務(wù)器去部署的，這個服務(wù)器很可能兩年、三年，甚至五年、十年都不會宕機一次，但是如果你這個系統(tǒng)基于一萬臺服務(wù)器基于部署的話，可能這一萬臺服務(wù)器里面每天都會有十臺、八臺服務(wù)器去宕機重啟的，這個不穩(wěn)定需要我們不斷的有人去完善它，去維護它，所以就造成需要我們使用這些技術(shù)的團隊，去對這個技術(shù)更了解，然后做更多的跟蹤，并不是說我們把系統(tǒng)給你部署，就OK了，這么一個工作。當然現(xiàn)在有一些自動化，我們也想盡辦法去做一些，把人脫離出來，交給我們系統(tǒng)去干的一件事情，但其實這一部分還是沒法往前脫離的。

然后我這邊覺得這么一個做大數(shù)據(jù)開發(fā)的團隊，需要這么幾點特質(zhì)：第一點，就是經(jīng)驗、前輩。我說經(jīng)驗、前輩并不是說我花五十萬的年薪，去其他公司招一個大牛過來，這個對于很多公司來說眼前不能很快的實現(xiàn)，也不是這個意思。我的意思是，我們在研究一門技術(shù)的時候，我們這個團隊要引入這個技術(shù)，要使用這個技術(shù)的時候，是不是找一個人專門去研究它，這個人到兩年系統(tǒng)上線之后，是不是能夠成為這一方面技術(shù)的專家?然后推進我們其他團隊去使用。其實這也是就是一個專業(yè)、專注的問題。我們團隊并不大，我們支撐整個公司的數(shù)據(jù)平臺也就七八個人。比如說緩存出了問題，我知道這個人能解決，OK，我找他。然后，我們平臺出了問題，我說這個人能解決，我找他。每個人都有自己的特長，然后能非常快速的解決問題。學(xué)習(xí)能力我指的，因為社區(qū)迭代非?？斓模鐓^(qū)基于大數(shù)據(jù)是非?？斓模泻芏嘈聰?shù)據(jù)出來，并不是說老的技術(shù)不用了，但是這些新的技術(shù)可能在一定程度上，可以替代我們老的技術(shù)，或者說是它的性能各方面會更好，我們花一定的，在團隊里面抽出來一部分精力，去嘗試，去解決這個，就是說一些更好的技術(shù)方案，引進一些更好的技術(shù)方案進來。另外就是思考，就是我們做一個階段之后，我們思考一下這個階段得到了什么，如果覺得我們是有問題的，或者說我們迭代比較慢的話，是不是我們的方向不對等等。然后責(zé)任心，因為我覺得做大數(shù)據(jù)的是比較苦逼的，特別苦逼，苦逼到什么程度。晚上可能告訴你一個數(shù)據(jù)有問題，然后你出來需要解決。另外一點責(zé)任心的話，因為基于大數(shù)據(jù)，大家都知道這里面有一個非常不好的問題，我們的數(shù)據(jù)來自互聯(lián)網(wǎng)，互聯(lián)網(wǎng)上的數(shù)據(jù)是非常亂的，因為我們對外的協(xié)議大部分都是(14：12英語)誰都可以給你發(fā)，給你發(fā)什么內(nèi)容都可以，現(xiàn)在反作弊我們也在做。責(zé)任心就是說，很可能因為某一個程序的問題，或者你程序?qū)懙牟缓玫膯栴}，造成(14：26英語)任務(wù)有問題等等，你需要起來去處理，而不是說我把這個任務(wù)掛上之后，我再也不管了，這個其實是特別重要的，就是團隊里面成員的責(zé)任心。然后溝通、分享和影響，這塊的話，我這個人我對這塊技術(shù)研究OK了，我覺得可以用了，我把這個平臺給搭建起來了，我去推廣了，然后我是不是在內(nèi)部進行一些公開會議，去推廣一下?教大家怎么去使用這個東西。因為推廣并不是說，讓大家知道我們的東西，你讓大家知道的，大家都知道，但是大家都不知道怎么去用，也不行。就是我們需要舉行一些內(nèi)部分享的機制。告訴其他團隊，用了我這個東西有什么好處，然后怎么去使用我這個東西，最重要的是怎么去使用，能給你帶來好處，這樣的話對這個平臺推廣有非常大的好處。

技術(shù)挑戰(zhàn)，我覺得就是這幾個方面，因為對于一個傳統(tǒng)的小團隊做項目的團隊來說，因為我這邊也在優(yōu)酷面試過很多人。你問他，多線程了解嗎?了解。你問他虛擬機了解嗎?了解，但是你解決過這一方面的問題嗎?沒有，這種人非常多，但是你去做大數(shù)據(jù)的技術(shù)，你必須去解決這些問題，你做一個平臺之前這些問題每天是有的，你必須解決這些問題。因為你做一個面向全公司或者是全集團的一個平臺，然后你這些問題，第一他們本來的數(shù)據(jù)量就很大，所以你遇見這些問題的概率是非常大的，你不知道他們什么業(yè)務(wù)，都在你這個平臺上去跑，甚至更令人恐怖的，之前我們平臺初期不完善，我見過一個人寫過一個(16：16英語)語句，一個java信息占了一百個G的內(nèi)存，這一方面需要我們自己更專業(yè)的人去做管理、去做處理。服務(wù)器底層的原理，我們既然去做平臺，我們需要快速派發(fā)一些問題，我們需要做壓力測試，我們在做壓力測試的時候，究竟是為什么?是什么原因?qū)е挛覀兊耐掏铝可喜蝗?，程序的性能不?這需要我們?nèi)Ψ?wù)器的底層原理去做一些理解。比如說我這個人本來只會java，那OK，現(xiàn)在問題解決不了，我現(xiàn)在這個人懂操作系統(tǒng)，現(xiàn)在CPU使用百分之百了，或者CPU使用90%，或者IO非常高等等這些問題，就需要團隊去融入其他一些技術(shù)進來。另外就是數(shù)據(jù)除噪，其實剛才有提到，我們的數(shù)據(jù)是面向互聯(lián)網(wǎng)的，誰都可以發(fā)任何的數(shù)據(jù)給我們，其實對于ETR這塊，每天都會收到日志里面。我們的日志當然不是直接存到數(shù)據(jù)庫，當然日志里面每天都會大量收到大量的(17：22英語)注入到日記里面，這個非常多，雖然是非常低級的工具手段，但是每天都會有。所以這個數(shù)據(jù)除噪，第一面向web的攻擊，另一方面是數(shù)據(jù)的質(zhì)量。因為數(shù)據(jù)除噪做的好，做的不好，對你后面數(shù)據(jù)分析，包括數(shù)據(jù)挖掘的模型，最后的解決其實造成蠻大的影響。另外一個，就是我們莊老師又講過，也有嘉賓提到過，我們用開源的時候遇到一些坑怎么辦?其實這些坑蠻多的，特別多，有的坑甚至大到我們這個團隊無法接受的，都有很多，都有遇見過。所以這些其實開源的bug，其實我覺得總結(jié)出來方案有兩種。第一種是我們索性不解決，繞過去，等到下一個版本，他就解決了。另外一個，就是如果覺得我們可以接受的話，我們花一個人或者兩個人在兩周之內(nèi)把這個bug給攻堅，給搞定，把這部分的源碼給運維那邊，然后把bug一搞定，原理解決，也是一種解決方式。

這塊的痛點，主要是說現(xiàn)在對于好多，我接觸過很多客戶，很多做架構(gòu)的，都告訴我，我現(xiàn)在需要一個十億級或者二十億級量的數(shù)據(jù)庫，而且我需要支持多維查詢。這么一個系統(tǒng)是有的，但是這么一個系統(tǒng)其實它基于好幾套系統(tǒng)搭建起來的，并不是給你安裝一個就可以這么干了，并不是去的?？赡芾锩嬗玫揭恍┧饕?、緩存等等一些東西去做。甚至說，因為我們?nèi)A為其實也是開源了一個基于(19：00英語)索引一個解決方案，其實代碼也已經(jīng)開源出來了，我們之前也有在用。這塊根據(jù)以前的開源東西自己去實現(xiàn)一些東西，才能滿足你的需求，并不是說直接開源拿來就能用。然后吞吐量這塊，可能很多系統(tǒng)在上線初期支持每天幾十萬或者幾百萬、上千萬的請求，但是上線之后也沒問題，運行一年也沒問題，突然間運行兩年公司規(guī)模壯大了，因為優(yōu)酷的日志量從之前的12年每天幾百億，到現(xiàn)在的每天上千億，其實也是上升了一個指數(shù)級。這樣有很多問題會在后面的數(shù)據(jù)量增長的過程當中暴露出來。實時的話，對于報表分析，我之前是我們國內(nèi)另外一家做電信的公司，可能在座的下面有華為的同事的話，有的可能會了解雅信聯(lián)創(chuàng)(音)，做商業(yè)BI的。之前BI方式基于數(shù)據(jù)倉庫，直接在倉庫上面建模，去做一些固定的報表分析出來就OK了。但是對于現(xiàn)在的互聯(lián)網(wǎng)監(jiān)測，一些數(shù)據(jù)也好，要看到實時的數(shù)據(jù)，對于報表的要求越來越高了，實時這塊需要更多的技術(shù)去支持。每一種方案都有優(yōu)缺點，選擇自己最合適的方案。

然后我下面介紹一下我們公司內(nèi)部的hadoop平臺成長的一個過程，和它升級的case。在12年的時候，我剛進公司，這個時候公司已經(jīng)有一個集群了，當時有30多臺，我去了之后擴到了50臺左右。當時這個集群是裸奔的，為什么叫裸奔呢?就是阿帕奇直接部署駕起來，跑起來，什么也沒給，什么控制也沒做，就是給我們一個推薦團隊來用。我當時應(yīng)聘的團隊就是推薦團隊，給他們在用，幫他們做這件事情。然后用著用著發(fā)現(xiàn)，別的團隊需要我們推薦團隊的數(shù)據(jù)，后來我們就自己思考了，其實我非常感謝我遇到了一個好的領(lǐng)導(dǎo)，就是我提前轉(zhuǎn)正了。在他那邊他是(21：26英語)，但是對于我來說，我已經(jīng)是全力在干這件事情了，這件事情是很好的，就是他給了我尊嚴，讓我去做這件事情，所以就是說我們當時有這么一個打算，就是說做一套全公司開放的平臺出來，然后當時是在這個50臺的基礎(chǔ)上，推廣其他團隊去用，當時那幾年團隊還不多，就是四五個團隊的時候，已經(jīng)有很多團隊在質(zhì)疑了。就是說，假設(shè)我們的數(shù)據(jù)被別人刪了怎么辦?所以在13年時候，我們這個集群做到兩百臺規(guī)模的時候，我加入了權(quán)限控制等等，包括用戶的目錄規(guī)劃、空間規(guī)劃，因為你不能保證你的用戶突然間存一個，今天存?zhèn)€1P的數(shù)據(jù)過來，我要對他的目錄做配合，我要對他的數(shù)據(jù)權(quán)限做控制等等，這些控制，我在13年的時候全部做完了。這個時候，其實挺穩(wěn)定，挺好了，看起來什么問題都沒有，但是后來又發(fā)現(xiàn)問題了。在13到14年的時候，做了一次版本升級，因為在12年到13年的時候是1.0到1.3的版本，然后在13年的時候，因為發(fā)現(xiàn)1.0.3版本，社區(qū)里面很多東西無法支持了，類似于(22：42英語)等等，他們新版本升級的時候，對于hadoop老的版本不支持了，都直接二點幾的版本了。所以這次做了一次升級，其實也有辦法去解決，當時因為我覺得，直接升級，但其實也是低估了這個升級的代價是非常大的。然后升級當時升了2.3的版本，其實我們升級還有一個，我當時因為覺得使用團隊的越來越多了，我們需要做高可用，所以在1.0.3的(23：10英語)存儲的主節(jié)點還不支持HN的，然后升級2.3主要解決這個問題，但其實沒有解決。因為升級2.3之后，我們的文件讀寫太頻繁了，導(dǎo)致阿帕奇的版本2.3的一個bug，HN只有一次耗時，就是一個掛了這個可以切過去，掛了這個再也起不來了。當時其實是花了將近兩周時間，把這個問題給解決了，然后也反饋到社區(qū)了，他們在2.4其實都已經(jīng)修復(fù)了，他們其實當時打了一個快捷出來給我們，其實已經(jīng)解決了。

在14年到15年的時候，從14年下半年到16年這段時間，公司的數(shù)據(jù)規(guī)模和團隊是越來越多。當時13年底的時候，優(yōu)酷全公司只有大概不到兩千人，現(xiàn)在整個公司五六千人了，所以對于團隊來說越來越多，業(yè)務(wù)來說越來越多，數(shù)據(jù)也是越來越多。整個數(shù)據(jù)漲了好幾倍。你看這個集群到13年的時候是兩百臺，12年是五十臺，其實也沒增長多少，但是從14年年底到16年直接奔一千臺去了，而且我們中間還做了很多刪數(shù)據(jù)等等控制數(shù)據(jù)規(guī)模的一些控制用戶存儲數(shù)據(jù)規(guī)模，包括給他數(shù)據(jù)設(shè)定一些數(shù)據(jù)周期等等一些運營策略，還漲這么快。就是說這中間遇到了很多用戶的問題。

下面一張PPT會介紹說整個數(shù)據(jù)平臺在不同的生長階段面臨的問題。到現(xiàn)在為止，已經(jīng)超過一千臺了，每天將近有三四萬作業(yè)在這個平臺上運行，就是(24：54英語)等等這些作業(yè)在這個平臺上運行。

問題演變，其實50臺左右的時候，我們暴露了什么問題就是生態(tài)圈的完善。當時生態(tài)圈什么(25：04英語)全部涌出來了，但是這些問題其實本身也不完善，踩的坑比較多，bug比較多。當時我們團隊技術(shù)功底還可以，但是你推薦給其他團隊用，其他團隊沒有這方面的技術(shù)功底，所以他們需要去學(xué)習(xí)，需要引入這方面的人來解決這方面的問題。所以當時面臨的問題是這樣。但當時不存在集群管理的問題，因為使用特別少。主要問題是，這個人給我發(fā)一個(25：36英語)，我應(yīng)該怎么寫，你能不能告訴我，我覺得這個問題太簡單了。所以當時主要是這種問題，到兩百臺的時候，就是權(quán)限控制，需要控制我的權(quán)限了，用戶管理，就是說我需要有單獨的賬號，需要保證我的文件只有我自己能看到。然后資源管理，就是說我不能因為某一個人提交了一個非常大的任務(wù)，跑了一整個晚上，占了五百臺服務(wù)器，導(dǎo)致其他團隊任務(wù)沒法跑，就是調(diào)度的問題，因為我們基于云去做這件事情，一千臺機器在一個大池子里面，誰都可以占用這個資源，所以這個資源需要做一些更好的調(diào)度處理。

另外就是數(shù)據(jù)安全。數(shù)據(jù)安全特別重要，對于一些核心團隊來說，比如說我們的廣告團隊，他們的團隊是不允許任何的團隊看到的，但是我們還需要幫他去做這件事情。

目錄規(guī)范是指，如果你只給他做權(quán)限處理，你給他制定一些規(guī)范進去的話，這些用戶亂放，最后你的GPS都不知道放的什么，整個文件數(shù)亂七八糟的，哪一些文件有用，哪一些沒用，你怎么對用戶的目錄去做大小的控制，這些都沒法去做了，所以用戶規(guī)范也在這個時間點去做了。

然后參數(shù)規(guī)范，當時我們的hadoop集群沒改什么參數(shù)，后來做了一些參數(shù)的優(yōu)化。然后也做了一些自動化運維的工具進去了。等到一千臺規(guī)模左右的時候，暴露的問題更高級了。用戶水平都高了，他給你提的問題真的是問題，需要花一周甚至兩周時間去解決。比如說用戶(27：16英語)的bug，比如說我現(xiàn)在平臺需要升級(27：18英語)版本，其實從1.6到1.7是有問題的，但是版本內(nèi)存是沒有問題的，但是這些問題真的是問題，需要解決。就是用戶高級了，我們遇到的問題也高級了。

可用性要求更高了，不允許平臺去管。你想我們網(wǎng)站每天那么多日志進來，那么多推薦系統(tǒng)，都從這個數(shù)據(jù)里面算數(shù)據(jù)，假如說這個平臺掛了，然后第二天大家都不用干活了，直接就是在重跑你的任務(wù)就好了。小文件的問題，做這個hadoop的都知道，hadoop會把這個文件結(jié)構(gòu)、目錄結(jié)構(gòu)等等塊的信息，全部存在一個java進程里面，這個java進程不能無限大，我們現(xiàn)在這個java已經(jīng)開到120G內(nèi)存了。就是用到256G的內(nèi)存，現(xiàn)在已經(jīng)開到120G了，我們可想而知它觸發(fā)一臺(28：05英語)就是幾分鐘了。然后這個問題，我們現(xiàn)在有很多方式，也有很多運行策略，就是我們合并小文件，或者壓縮文件，減少文件塊等等這些方式去處理，但是其實現(xiàn)在在社區(qū)還是一個瓶頸，我覺得hadoop這個東西，可以允許你發(fā)展幾百臺的規(guī)模，但是你像阿里這種，上萬臺的規(guī)模還是需要自己去做很多改造的。因為阿里多機房，做多(28：33英語)這套方案。

這個問題另外一個就是數(shù)據(jù)遷移。這個數(shù)據(jù)遷移，我是指的有些系統(tǒng)可能用的(28：46英語)這個數(shù)據(jù)已經(jīng)跑了很久了，在這個目錄里面，但是突然間告訴他，我這個目錄需要開放，但是這個目錄里面另外一些數(shù)據(jù)不需要開放，所以就需要在這個目錄規(guī)范上再做一些處理，去滿足其他團隊的數(shù)據(jù)需求。任務(wù)問題，就是任務(wù)越來越多了，一天三四道任務(wù)在上面運行，就像一個高速通道一樣，然后一百個沒問題、兩百個車沒問題，一天幾萬個車在上面運行，會出現(xiàn)堵的問題。但是堵你不能一直擴容，你擴容也解決不了堵的問題。因為不排除我們有一些專業(yè)的分析師，非常專業(yè)的分析師，不是非常專業(yè)的技術(shù)，但是他會寫(29：26英語)，比如說直接查詢一年、兩年、三年的VA，你這個查詢需求一天那么幾十T的數(shù)據(jù)，一下查詢好幾年的數(shù)據(jù)，誰也沒法控制你，所以我們還是要控制他。我也沒法說直接擴容能辦法你的需求，我只能說我控制你了，你跑的慢一點，你只能占50臺機器跑，讓你跑半個月，只要你跑出來就行了。這種需求，就是給任務(wù)劃一個優(yōu)先級。存儲計劃需要去做，我現(xiàn)在基本上一天30T的話，做三副本的話就是100T左右，100T的話，也就是將近一臺服務(wù)器來做。一天需要擴容一臺，一個月就是三十臺，一個G就是一臺。其實這個規(guī)模還蠻大，我需要去做一些存儲規(guī)劃，就是說多長時間的日志需要刪除，究竟需要擴多少服務(wù)器出臺。因為我們的運營團隊也需要提前給他報備。

資源增強然后資源分類，就是說我剛才提到的，這個資源基于平臺上面跑的任務(wù)越來越多了，然后大家相互爭搶資源，他說我的優(yōu)先級比較高，我說我的優(yōu)先級比較高，我不能讓你倆打架吧，但是我還得讓你倆都跑，怎么辦?我自己會對集群做一些管理系統(tǒng)，我讓集群看出來，我讓你們看出來，在哪個時段，我的集群比較顯，你們可以很快的跑完，就是讓用戶自己選擇時段。另外的話，任務(wù)的優(yōu)先級不能用戶自己設(shè)定了，讓你自己設(shè)定已經(jīng)不OK了，我需要有一些機制控制這件事情。假如說我給你們團隊優(yōu)先級任務(wù)高的，就100個資源，一百臺機器讓你們跑，同時你們占有100臺機器，再多的話，需要你們內(nèi)部自己協(xié)調(diào)了，這個太復(fù)雜了，我不能一直通過擴容來滿足你的手段。服務(wù)器如果這么做的話，最后這個集群擴到一發(fā)不可收拾了。然后任務(wù)監(jiān)控，現(xiàn)在用戶發(fā)現(xiàn)我的任務(wù)報錯了，現(xiàn)在日志是能看到，但是我要知道我為什么報錯。比如說內(nèi)存(31：32英語)的監(jiān)控，這樣的話剛開始我們監(jiān)控，只是說這個節(jié)點掛了，這個服務(wù)器的內(nèi)存用了多少，然后我們這邊是有，但是用戶要看到自己的任務(wù)，或者某一個(31：46英語)用的內(nèi)存整個情況，沒有的，所以我們之前開發(fā)的那套監(jiān)控系統(tǒng)還在用著，但是現(xiàn)在又搭了一個(31：55英語)加了一個插件，在跑的過程中會采集一些(32：00英語)系統(tǒng)里面，給它展現(xiàn)。等等這些問題，到現(xiàn)在為止處理的差不多了，但是后面有一張PPT我會講到，就是整個升級過程和面臨的挑戰(zhàn)。

整個平臺升級，升級的必要性分為兩部分：第一次升級是為了保養(yǎng)，其實可以不升的，但是升了，是為了保養(yǎng)。第二次升級，其實就是為了治病，不升不行了，面臨了很多問題，需要去升級了，必須要升了。然后準備的話，準備這塊調(diào)研、測試、包括修改、適應(yīng)現(xiàn)在的環(huán)境等等這些問題都小，最主要的是你怎么讓用戶接受你這個升級。因為hadoop的升級，可能并不是想像的說我換一個新版本，把文件系統(tǒng)升級，就OK了。我們公司所有的(32：42英語)程序，里面有30%是需要修改的，它和API是不兼容的。所以我們考慮到兩種方式，就是說我們盡最大的努力，讓它做到兼容，我們?nèi)バ薷乃徊糠諥PI，修改它一部分插件，讓他做到兼容。另外一部分的話，真的需要修改程序了，所以這個需要給我們的團隊去溝通。

方案的話，就是說制定升級方案，哪些系統(tǒng)先升級，哪些系統(tǒng)后升級，系統(tǒng)之間的依賴需要處理明白，究竟哪些系統(tǒng)，別遺漏了。因為當時最后一次升級，我們處理了大概有五六十個業(yè)務(wù)系統(tǒng)，你像我一次升級，牽扯到這么多系統(tǒng)需要改程序，現(xiàn)在想想其實也是一件挺好玩的事情。升級的過程中，我們做的還是比較謹慎的，整個文件樹的結(jié)構(gòu)，就(33：43英語)鏡像文件，如果這個一丟，相當于整個公司的存儲丟完，雖然說存儲沒丟，但是數(shù)據(jù)已經(jīng)找不回來了，這個備份我們做了一級防備份，全做了，包括回滾的代碼都已經(jīng)寫好了，腳本全部寫好了，基本上可以避免所有的意外發(fā)生了。無非是宕機時間的問題，其實在升級當天晚上遇到的一些問題，還是比較突發(fā)性的問題。第一個問題是觸發(fā)了操作系統(tǒng)(34：18英語)的一個bug，測試那天沒有測出來的。另外一個問題是，升級時間我們把安裝包，安裝包將近有一個G，就GDK安裝包，包括hadoop安裝包，整個包將近一個T，從一臺機器往下分發(fā)的時間，我算算這個帶寬，分完之后需要分發(fā)兩個小時。本來升級只需要40分鐘都能搞定，分發(fā)包的過程需要兩個小時。都是在之前沒有考慮到的。然后再接下來，就是我們這個坐享成果了，升級完了，其實也沒這么爽。升級完之后，一周的時間還是在解決測試時間沒有測到的bug。那一周我們很苦逼，但是過了這一周，我們很爽了，集群再也沒有出現(xiàn)過宕機了，高可用也OK了，我們省心多了，能睡著覺了。

然后這個集群面臨的挑戰(zhàn)，其實我覺得這個挑戰(zhàn)，就是我剛剛提到一點Nmenode瓶頸，因為我們現(xiàn)在在做多機房方案了，一個機房現(xiàn)在在青島那個機房，將近有一千五百臺服務(wù)器，現(xiàn)在沒有機架了，需要做多機房的方案了。另外一個日志系統(tǒng)，對于大小的控制，我需要滿足Nmenode瓶內(nèi)存的要求。集群規(guī)模大小，Nmenode瓶性能瓶頸，一直都是在圍繞Nmenode瓶。因為它這個性能瓶頸，并不是說內(nèi)存的瓶頸，就是說它對于HDF分布式的東西來說，它對于存儲是分布式的，它對于計算是分布式的，但是對于我去找一個文件，這個文件下面有哪些文件，這個瓶頸是落在Nmenode瓶主節(jié)點上的，這個節(jié)點是管理總文件數(shù)的。所以我們查找的服務(wù)，類似于(36：04英語)的服務(wù)非常多，造成Nmenode性能瓶頸，它一個節(jié)點已經(jīng)搞不定了，我現(xiàn)在已經(jīng)用到40核的CPU，256G的內(nèi)存了，他已經(jīng)搞不定了怎么辦?我還是需要想辦法處理。另外就是議案的問題，議案調(diào)度還是不夠個性化。因為我們現(xiàn)在跑到議案上面的任務(wù)，有(36：28英語)等等，我們還有開發(fā)一些自定義的應(yīng)用，也是基于議案去做的。也就是跑在上面的任務(wù)這么復(fù)雜，我就需要一個更牛逼的系統(tǒng)去做。但是hadoop2.7支撐基于標簽的調(diào)度，但是它這個東西一點都不完善，只有一個調(diào)度，它內(nèi)置了三種調(diào)度器，只有一個調(diào)度器支持，其他兩種調(diào)度器都不支持。而且他最支持的調(diào)度器是最原始的。因為資源調(diào)度器是非常傻的一個調(diào)度器。

資源隔離的話，這塊我想說一下，因為我現(xiàn)在做的內(nèi)存控制了，做到資源控制了，但是我沒法完全做到資源控制。我說的這塊就是虛擬化，可想而知大家這么一堆任務(wù)都跑在一千臺服務(wù)器上。這一千臺服務(wù)器，有一臺服務(wù)商同時起到十個java進程，是屬于十個用戶的。我能分配你這個java只占兩個G的內(nèi)存，這是沒有問題的，但是我沒法保證你的java內(nèi)存只能用一個CPU，如果不基于虛擬化去做的話?；蛘呤?37：34英語)策略去做的話，我沒法保證CPU的完全隔離，其實這個也是一個挑戰(zhàn)，因為現(xiàn)在發(fā)現(xiàn)，你要做平臺做到最后就是資源的問題，你怎么把這些資源控制好，怎么把這個平臺的權(quán)限控制好，讓用戶更好的去用，就完了。

然后數(shù)據(jù)倉庫的必要性。我想說一下我們集群為什么出現(xiàn)這么多任務(wù)阻塞的情況，就是大家都在爭搶資源的情況?其實我們少一個數(shù)據(jù)倉庫，沒有一個非常牛逼的數(shù)據(jù)倉庫團隊來做數(shù)據(jù)倉庫。也就是說我需要一個數(shù)據(jù)就拿，這個架構(gòu)肯定是不OK的，所以我需要一個數(shù)據(jù)倉庫。

更加強大的監(jiān)控平臺，就是說我需要監(jiān)控到甚至說某一個任務(wù)，某一個用戶，某一個任務(wù)的(38：14英語)的情況，對于磁盤讀寫的情況或者說他突然發(fā)現(xiàn)，我這個任務(wù)本來每天都半個小時都運行完，今天怎么走了兩個小時，是不是讓他發(fā)現(xiàn)他讀文件的節(jié)點剛好出現(xiàn)(38：30英語)問題，需要這方面的支持。

另外客戶端，我的打算是，因為現(xiàn)在我們團隊有幾十個，我們的客戶端有幾十個，每個團隊有一個或者兩個hadoop客戶端，就是提交任務(wù)的機器，不運行任務(wù)，就是我只提交的機器就將近一百臺了。然后我每次升級這個問題是非常頭疼的，就是說有一部分客戶端管理權(quán)限在我這兒，有一部分人客戶自己裝的，我只能匯總，但是肯定會有漏的，所以我現(xiàn)在基于(39：00英語)去做這種無狀態(tài)的客戶端工作，我就發(fā)一個(39：04英語)的鏡像，升級的話你自己重新裝就完了。

配置問題，我需要一套自動化運維的工具，因為不可能說這一千多臺機器，每天還是寫這么多腳本，我給一個(39：15英語)寫個腳本下發(fā)，通過一個腳本直接拷到每臺機器上，還是需要一些自動化運維的工具在里面，來幫助完成這件事情。業(yè)務(wù)依賴升級的問題，盡量想辦法去，就是我們怎么盡量想辦法去避免，因為你的系統(tǒng)升級造成業(yè)務(wù)也需要升級呢?

行，我的分享基本上就到這里，謝謝大家。

嘉賓：我想問一下，就是我們有一個數(shù)據(jù)庫平臺，轉(zhuǎn)成hadoop平臺的話，有沒有可能?

楊大海：其實我覺得你單純說一個數(shù)據(jù)庫轉(zhuǎn)化hadoop平臺，因為它們在兩個不同的戰(zhàn)線上?；趆adoop平臺上能夠滿足你某些數(shù)據(jù)查詢的這些要求，比如說(40：09英語)等等可以滿足你數(shù)據(jù)查詢的需求，但是這個平臺干的事情和你現(xiàn)在數(shù)據(jù)庫，就是單純hadoop來說干的事情和你數(shù)據(jù)庫干的事情，是完全兩碼事，你數(shù)據(jù)庫是滿足一下業(yè)務(wù)需求的查詢。比如說我點一下前端就要出來了，但是hadoop這個，我要寫一些(40：29英語)語句兩個小時算出結(jié)果的。

嘉賓：就是現(xiàn)在有很多產(chǎn)品，本身是(40：38英語)語句的一些產(chǎn)品，那么對這個支持?

楊大海：我?guī)腿A為宣傳一下，其實華為基于(40：49英語)方案，而且在(40：55英語)社區(qū)里面基于(40：59英語)查詢的一個東西，這些都可以去做(41：02)的多位查詢。因為(41：02英語)本身是KV的查詢，基于這些方案可以做多余的查詢，而且滿足你這個數(shù)據(jù)量的需求，因為(41：10英語)其實對存儲的數(shù)據(jù)量是沒有要求的，它只對并發(fā)吞吐量有要求，每秒鐘是多少KOBS這種是有要求的，他能支撐到服務(wù)是有限的，但是你只要有足夠大的硬盤，你有多大的數(shù)據(jù)，你都可以往里面寫，這個對他性能是沒什么影響的。