2015年8月29日由七牛公司舉辦為期兩天主題為—數(shù)據(jù)重構(gòu)未來的七牛·數(shù)據(jù)時代峰會在上海國際時尚中心。本次大會邀請國內(nèi)外知名數(shù)據(jù)專家、互聯(lián)網(wǎng)行業(yè)、傳統(tǒng)行業(yè)數(shù)據(jù)大咖親臨現(xiàn)場，帶來一場有關(guān)數(shù)據(jù)的饕餮盛宴。

[[147652]]

芒果TV依托湖南廣電的內(nèi)容、用戶資源在2014年迅速成長，同年 7月5日周點(diǎn)擊量超過1.7億。本次七牛數(shù)據(jù)時代峰會特別邀請芒果TV數(shù)據(jù)負(fù)責(zé)人彭哲夫分享芒果TV數(shù)據(jù)處理實(shí)踐分享。

以下是演講實(shí)錄：

芒果TV團(tuán)隊從去年開始籌建，現(xiàn)在有十個人，150多個節(jié)點(diǎn)，通過數(shù)據(jù)1.5PB。整體分為三個業(yè)務(wù)系統(tǒng)分別是數(shù)據(jù)魔方—負(fù)責(zé)一些重要指標(biāo)的統(tǒng)計。第二是系統(tǒng)推薦，是芒果TV 將流量進(jìn)行轉(zhuǎn)化引導(dǎo)。第三是視頻內(nèi)容分析系統(tǒng)，很多互聯(lián)網(wǎng)的數(shù)據(jù)可以轉(zhuǎn)化成傳統(tǒng)媒體需要的數(shù)據(jù)，因此芒果TV將一些用戶的記錄可以提供給導(dǎo)演來提供精彩的內(nèi)容或者劇情發(fā)展。

現(xiàn)在芒果TV的數(shù)據(jù)部門支撐了70%-80%的業(yè)務(wù)，而今天的演講也分為三個部分：***是基礎(chǔ)篇，第二是整合篇，第三是數(shù)據(jù)管理篇。

采集是數(shù)據(jù)的生產(chǎn)方，決定了數(shù)據(jù)是否可用，而在做搜集時我們會關(guān)注一下寬帶成本，作為一家視頻公司，寬帶和版權(quán)是成本構(gòu)成的重要部分。因此我們自己開發(fā)了一個SDK把采集到的數(shù)據(jù)發(fā)送到我們自定義的系統(tǒng)上，再進(jìn)行分類一塊發(fā)到FDS上，最終會轉(zhuǎn)化成數(shù)據(jù)，形成數(shù)據(jù)庫。

在實(shí)時計算方面，主要是用于播放過程中質(zhì)量監(jiān)控。我們回到ES里面去做一些即時查詢。

在采集過程中會列出一個元素然后調(diào)用一個方法，然后把所有的參數(shù)傳送給服務(wù)商，但是弊端在于隨著采集點(diǎn)的增多，代碼需要維護(hù)，而且缺少系統(tǒng)性。因此我們做了一個抽象，在采集過程中機(jī)型一次分類，比如頁面數(shù)據(jù)、錯誤數(shù)據(jù)、播放數(shù)據(jù)。

另外就是事件問題，事件因?yàn)槭裁刺幜P？我們通過后端配置把一個元素的名稱和事件整合起來在頁面加載的時候，會把這一塊的配置加載到后端頁面，后端會根據(jù)這些加載的配置來決定什么數(shù)據(jù)需要上報，什么不需要上報。

如果我們需要一個很長的開發(fā)周期，使用這個模式時我們只需要在后臺進(jìn)行一個配置，數(shù)據(jù)馬上就會過來了。搜集方面，一般采用的是放一個像素的圖片吧一些參數(shù)帶到這個圖片后面，但是這種方式會造成寬帶成本非常大，光搜索寬帶會占到600兆左右。為了把服務(wù)器資源降低到極值，可以改為PT進(jìn)行篡數(shù)。這樣可以節(jié)省接近三分二的帶寬成本。

在傳輸方面我們遇到了一些坑，最重要的問題是占用資源過大，實(shí)際上我們隊每一塊進(jìn)行具體分析也不難解決這個問題。

在數(shù)據(jù)量過大時我們會遇到一些情況，主要是在于每隔一段時間會建一個文件夾，然而在測試時，時間就要長的很多。所以我們對其做了一個調(diào)整，使用單線程的方式做了一個很不錯的優(yōu)化，當(dāng)?shù)搅?.5 1.6之后會直接導(dǎo)致系統(tǒng)內(nèi)存膨脹的厲害，所以我們一般會加一條配置參數(shù)或者直接把位置進(jìn)行改掉。

在一般類型文件和文件夾之間選擇，主要考慮效率問題，之前有人提出將二者綜合在數(shù)據(jù)量高的情況下使用文件。在寫FTX時會導(dǎo)致文件進(jìn)入關(guān)閉的狀態(tài)，會導(dǎo)致我們錯誤失敗，我們需要進(jìn)行監(jiān)控。另外可能會產(chǎn)生很多小文件會造成比較大的壓力。因?yàn)槭谴髷?shù)據(jù)，數(shù)據(jù)量不言而喻我們使用的壓縮方式可以壓縮80%的數(shù)據(jù)量。

在隊列傳輸方面，我們只要使用Kafka，在實(shí)踐中來看，并不是分區(qū)越多越好，如果分區(qū)越多，客戶端和服務(wù)端所使用的內(nèi)存限制也就越多，一個分區(qū)會產(chǎn)生兩個文件，這兩個文件會導(dǎo)致具體數(shù)量增加，而且Kafka本身的機(jī)制—kafka里面有一個頁面分區(qū)，會產(chǎn)生投票過程分區(qū)越多時間越長會影響使用。

我們的做法是：選擇一臺機(jī)器只創(chuàng)建一個分區(qū)，然后測試產(chǎn)生和消費(fèi)的情況如何，我們最關(guān)心的是吞吐量，所以TP和TC的***值可以做我們的分區(qū)。

在存儲這一塊，我們用的是多級存儲方式，當(dāng)然遇到的問題在于，當(dāng)數(shù)據(jù)量增加時，很多冷數(shù)據(jù)在里邊，工作壓力會比較大。所以我們會分成三級，主要特點(diǎn)是CPU和內(nèi)存會比較豐富一點(diǎn)，還可以減少副本以及把冷數(shù)據(jù)丟到云存儲上面。

在存儲方面另外一個問題就是壓縮，在前期沒有規(guī)劃好時，我發(fā)現(xiàn)存儲空間已經(jīng)不夠用了，我們會根據(jù)自己的業(yè)務(wù)進(jìn)行選擇，使用歸檔日志對小文件進(jìn)行整理。

在配置方面，我們會把配置整合起來，進(jìn)行推送，主要是基于RPC的控制模型，對所有的組進(jìn)行全員的控制。我們的數(shù)據(jù)服務(wù)平臺需要支持公司的很多業(yè)務(wù)他們只需要一個賬號就可以進(jìn)行我們采集服務(wù)器的傳輸服務(wù)、實(shí)時計算服務(wù)，我們也提供資源流量監(jiān)控服務(wù)……

主要說一下我們?nèi)绾卧谄脚_上管理數(shù)據(jù)。只要分為幾個部分。一時日志種類的抽象，這和公司的業(yè)務(wù)息息相關(guān)，我們將日志進(jìn)行分類—播放類日志、廣告類日志。在這其中有一個特別有意思的地方，在芒果TV更關(guān)心PV VV這些核心指標(biāo)，但是如果我們的計算指標(biāo)的方式和其他同行不一樣，這個數(shù)據(jù)在行業(yè)內(nèi)就沒有可對比性。所以會從幾個方面去定義：一個是它的概念—運(yùn)用的常理，如何上報，會導(dǎo)致什么樣的結(jié)果。

***上報內(nèi)容和計算公式，數(shù)據(jù)到了平臺以后最重要的就是對數(shù)據(jù)進(jìn)行管理，為什么要做管理？其實(shí)是為了把數(shù)據(jù)進(jìn)行分門別類，隨之產(chǎn)生的就是主題式管理—以某一個點(diǎn)為核心，在必須關(guān)注的方面我們再次進(jìn)行分類，這個方式與我們的日志抽象非常相似。

在數(shù)據(jù)倉庫建立之后，別人需要使用你的倉庫數(shù)據(jù)們需要一個明細(xì)，需要做一個數(shù)據(jù)的數(shù)據(jù)。這個元數(shù)據(jù)分為兩類，一類是技術(shù)性元數(shù)據(jù)主要給開發(fā)人員使用，包括一些倉庫結(jié)構(gòu)，以及原始性抽取的一些規(guī)則，不然的話數(shù)據(jù)毫無質(zhì)量可言。

***為什么需要數(shù)據(jù)集市？在這個過程中，每一個公司會有很多業(yè)務(wù)部門，每一個業(yè)務(wù)部門面臨的問題是不一樣的，比如從統(tǒng)計角度，會更關(guān)注哪些數(shù)據(jù)。但是如果這樣數(shù)據(jù)倉庫是沒法穩(wěn)定的。因此需要數(shù)據(jù)集市進(jìn)行隔離，在這個過程中我們可以把數(shù)據(jù)抽出來進(jìn)行一些隊列，放到我們的關(guān)系成本里，這些集市之間的結(jié)果是可以互相分享和交換的，更重要的是在于事實(shí)表和維表的管理和維護(hù)。