大家下午好，我是芒果TM的數(shù)據(jù)負責人，我主要是負責數(shù)據(jù)平臺，今天主要是和大家分享一下是怎么樣解決數(shù)據(jù)采購的。首先我介紹一下我們這個團隊，我們這個團隊是從去年開始籌建的，經過了8個月的發(fā)展，目前是10個人，現(xiàn)在差不多是有150多個結點，提供了一個150多臺結點，通過1.5PB左右的數(shù)據(jù)，有三個業(yè)務系統(tǒng)，一個是一個是數(shù)據(jù)魔方，主要是一些指標的統(tǒng)計。第二個是推薦系統(tǒng)，今天上午愛奇藝的也說過了，我們如何把一些流量轉化出來，可能需要一些引導性的東西，推薦系統(tǒng)是不錯的選擇，最后是視頻內部的分析系統(tǒng)，很多互聯(lián)網的數(shù)據(jù)可以轉化成傳統(tǒng)的媒體需要的數(shù)據(jù)，我們會把一些用戶的記錄，可以提供給導演選擇一些精采的片子和劇情的發(fā)展。
我們現(xiàn)在數(shù)據(jù)的部門，支撐了70%-80%左右的數(shù)據(jù)業(yè)務。然后今天主要是說的分了三塊，一塊是基礎篇，一塊是整合篇，最后是數(shù)據(jù)管理篇?；A建設主要是分了采集，為什么要單獨的說一下采集，在做大數(shù)據(jù)的過程中，數(shù)據(jù)的準確性是非常的重要的，采集是數(shù)據(jù)的生產方，決定了數(shù)據(jù)是否可用，這一塊會單獨的說一下，第二塊是搜集，我們會關注的一個帶寬的成本，我們做視頻的公司的會非常的敏感，視頻公司主要是版權和帶寬的成本。
如果搜集這一塊的帶寬很高的話，會帶來很大的支出，然后我們的整體架構是這樣子的，前面的話，我們自己開發(fā)了一個SDK，把數(shù)據(jù)采集到了以后，會發(fā)送到我們自己定義的系統(tǒng)上，會進行一個匯聚，然后進行分類，一塊發(fā)到FDS，一個是發(fā)到我們的隊列系統(tǒng)，最終會轉化成數(shù)據(jù)，形成數(shù)據(jù)倉庫。
實時計算這一塊的話，主要是會計算一些播放過程中質量的監(jiān)控，還有一塊，我們會到ES里面去，主要是做一些即時的查詢。首先看一下采集這一塊，可能大家看到了這個會比較熟悉，比如是上面列一個元素，然后吊一個方法，把所有的參數(shù)傳送給服務商，但是會有一個弊端，隨著采集點的增多，代碼需要維護，第二個是沒有一個系統(tǒng)性。實際上我們對這一塊做了一些工作，主要是做了一個抽象，采集的過程中，我們會分為三大塊，一大塊是模板，我們采集的數(shù)據(jù)是可以進行一個分類的。比如說我們的頁面數(shù)據(jù)和播放數(shù)據(jù)，以及錯誤數(shù)據(jù)。
還有就是事件，事件是因為什么觸發(fā)。最后一塊是配置，我們多了一個類似阿里的一個東西，這一塊的話，主要是通過后端的配置，把一個元素的名稱和一個事件整合起來，在頁面加載的時候，會把這一塊的配置加載到后端，后端會根據(jù)這些加載的配置來決定什么數(shù)據(jù)是需要上報的，什么是不需要上報的。
如果是我們需要一個很長的開發(fā)周期，使用這個模式的話，我們只要在后臺進行一個配置，數(shù)據(jù)馬上就會上來了。搜集這一塊，一般我們采用的是放一個像素的圖片，把一些參數(shù)帶到這個圖片的后面，這個過程會造成帶款的成本非常的大。光是搜集帶寬會占到600兆左右。我們可以把服務器的資源降到極值，可以改為PT進行篡數(shù)，我們做了一個對比，可以看到不同的數(shù)量級下面，保持了一個比較平均的一個比例，我們使用PB的話，可以減少原有的三分之一的數(shù)量，為我們節(jié)省了差不多三分之二的帶寬的成本。
傳輸這一塊，剛才超哥已經介紹過了。這一塊的話，使用插片式的方式開發(fā)，可以很好的實現(xiàn)自己的利益。在使用的過程中，我們會踩到一些坑，最重要的是占用的資源是非常大的。實際上我們對每一塊進行一個具體的分析，也不難解決這一塊的問題，在數(shù)據(jù)量大的時候，會存在一些數(shù)據(jù)的情況。一個主要的特點每隔一段時間會建一個文件夾，實際上我們在前面做文件的時候，遠遠的會超于這個時間，所以我們會把這一塊進行一個調整。另外的話，使用了一個單線層的方式。最后一塊是做了一個很不錯的優(yōu)化，到了1.5，1.6以后，會直接導致系統(tǒng)的內存這一塊的資源膨脹的比較厲害，所以我們對這一塊有二種的解決方式，一種是會加一條配置的參數(shù)，第二條可以直接把位置去進行改掉。
一般是在類型和文件之間選擇，主要是一個效率高的問題，這個之前，網上也有人提出了比較有效的解決方案，把這二者綜合，在數(shù)據(jù)量高的情況下，使用文件。最后一塊比如是在寫FTX的時候，會導致文件關閉的狀態(tài)，會導致我們的錯誤會失敗，我們需要對這一塊進行一些監(jiān)控。另外一塊的話，可能會產生很多的小的文件，會造成比較大的壓力，所以根據(jù)自己的業(yè)務來調整，選擇合適的文件的大小，這樣子可以減少很多小的文件。最后一塊的話，因為大數(shù)據(jù)，數(shù)據(jù)量肯定是很大的，在網絡的傳輸過程中，我們也需要進行壓縮，實際上我們使用的壓縮的方式，這一塊差不多可以壓縮80%的數(shù)據(jù)量。
隊列傳輸這一塊，我們主要是用的Kafka。我們總結的經驗是這樣子的，并不是所有的分區(qū)越多越好。其實我們的分區(qū)越多的話，客戶端和服務端所使用的限制內存也就越多，一個分區(qū)會產生二個文件，這二個文件會導致具體的數(shù)會增加，最后一塊是因為Kafka的機制所導致的，如果是分區(qū)數(shù)過多的話，Kafka里面有一個頁的分區(qū)，會產生投票的過程，分區(qū)數(shù)越多的話，使用的時間越漫長，也會影響使用。
我們會選擇一臺機器，只創(chuàng)建一個分區(qū)，然后測生產和消費這二邊分別是怎么樣的，我們最關心的是吞吐量，所以TP和TC的最大值可以做我們的分區(qū)數(shù)。
然后是存儲這一塊往往我們說的存儲會比較籠統(tǒng)，我們采用的方案是多級存儲的方式。那就會有一個問題，當數(shù)據(jù)量增加的時候，會有很多的冷數(shù)據(jù)在那里，工作的壓力會比較大，我去計算的時候，這樣子會造成一些不必要的浪費，所以我們會分成三級，主要的特點是CPU和內存會比較豐富一點，第二個是少復本，這樣子的話，我們可能只需要二個復本，最后一塊是冷數(shù)據(jù)，這樣子的話，實際成本會比我們之前的集群多很多。最終會把一些冷數(shù)據(jù)丟到云存儲上面去。
那存儲這一塊，另外關心的問題就是壓縮的問題，存儲這一塊空間是一個很重要的問題，我們在做的過程中，我們也發(fā)現(xiàn)了這個問題，往往我們前期沒有規(guī)劃好的時候，我們會發(fā)現(xiàn)存儲的空間已經不夠用了，我們可能需要對存儲進行一些壓縮，這一塊的話，我們需要根據(jù)自己的業(yè)務去選擇。使用日志歸檔對小文件進整理。
計算這一塊的話，因為都是比較成熟的。象離線計算這一塊的話，有二個比較需要關注的點，一個是資源分配這一塊，最多的一塊是隊列這一塊，需要特別的做一些信心的工作，這一塊的話，有二塊，一個是二分之一CPU，摸索的是按照1核來使用的，很多的業(yè)務我們并不需要CPU這么的值，我們可以選擇二分之一的CPU，可以滿足使用內存量比較大的業(yè)務。
另外是實時計算這一塊，我們是采用的Starm的方式，我們要做一個數(shù)據(jù)平臺的話，主要是控制和資源管理，Starm是不顯示這一塊的工作的，通過這一塊可以進行一些管理的操作，包括一些日志的圖表的顯示，根據(jù)圖表來分析我們Starm上的運行的情況。
即時查詢這一塊，主要是和我們的技術人員比較相關一點，因為我們經常在開發(fā)的過程中，經常會報錯，實際上我們是需要一個比較好的產品平臺的。這塊的話，我們使用的是我們自己開發(fā)的Dek，可以做一個索引的程序。在索引的過程中，我們盡量的把復復本和falsh關掉。接下來從它的的索引的協(xié)議上做一些工作，大部分的選擇索引的過程中，如果是在我們網絡允許，或者是在比較好的情況下，可以嘗試一下TCP。
如果我們單從文本上做歸類的話，會導致內存缺失的情況，所以我們會形成一些數(shù)字型的工作，最后是要做一個比較相對開放的平臺，這一塊是必須要做的。否則的話，別人就會干掉另外一塊的索引。我們現(xiàn)在每天的索引是30TB的數(shù)據(jù)。
組建的整合，這個和我們公司的業(yè)務會比較相關，在業(yè)務的過程中，這個數(shù)字會非常的難看，而且會產生商務上的一些糾紛。我們需要把這些配置進行一個統(tǒng)一的管理。接下來就是一些權限的管理。
其實配置這一塊的話，我們主要是把配置整合起來，進行推送的工作，主要是機遇RPC的控制模型，對所有的組建進行全員的控制。我們的數(shù)據(jù)服務平臺需要支持公司很多的業(yè)務線，他們只需要一個帳號就可以進行我們的采集服務機數(shù)據(jù)傳輸服務，實時計算服務，我們也可以提供資源流量監(jiān)控的服務，包括提供資源使用的菜單。
接下來的話，主要是說一下如何管理平臺上的一些數(shù)據(jù)。主要是幾塊，一個是日志種類抽象，這個其實是和公司的業(yè)務會息息相關，我們這一塊的話，分了播放類的日志，廣告類的日志，為什么需要指標定義單獨的拿出來說一下，有一個特別有意思的地方，在芒果TV，更關心的是VV，TV，PV這些核心的指標，但是如果是我們計算的指標的方式和愛奇藝的不一樣，這個數(shù)據(jù)在行業(yè)內是沒有一個可對比性的，所以會從幾個方面去定義，一個是它的概念，運用的常理是怎么樣的，是怎么樣上報的，會導致數(shù)據(jù)統(tǒng)計出來的結果，可能會千差萬別。
最后是上報內容和計算公式。數(shù)據(jù)到了平臺以后，最重要的是對數(shù)據(jù)進行管理，為什么會要做一些管理，其實為了把這些數(shù)據(jù)進行一些分門別類，我們所產生的就是主題式的管理，某一個點為核心，你必須關注哪一些方面，我們會分為幾類，這個和我們的日志抽象會非常的相同。數(shù)據(jù)倉庫只是一個數(shù)據(jù)結合的地方，但是數(shù)據(jù)倉庫的價值需要上層利用做一些工作。
這一塊的話，主要是數(shù)據(jù)的管理，數(shù)據(jù)倉庫建立以后，別人要使用你倉庫的數(shù)據(jù)，需要一個明細，我們需要做一個數(shù)據(jù)的數(shù)據(jù)，這個原數(shù)據(jù)分了二類，一類是技術性的原數(shù)據(jù)，主要是給我們的技術開發(fā)人員使用的，包括了一些倉庫的結構，就是我們是怎么從原始性抽取的一些規(guī)則，這個是需要從公司出來的，不然的話，數(shù)據(jù)沒有質量可言。
最后為什么要做數(shù)據(jù)集市，在這個過程中，每一個公司會有多個業(yè)務部門，每一個業(yè)務部門的話，所面臨的是不一樣的，比如是從統(tǒng)計的角度，會更關注數(shù)據(jù)，分析的話，有分析的角度，但是這樣子的話，數(shù)據(jù)倉庫沒有辦法穩(wěn)定，需要數(shù)據(jù)集市進行隔離，在這個過程中，我們可以把一些數(shù)據(jù)抽出來進行一些隊列，放到我們的關系成本里面，這些集市之間的結果是可以進行分享和交換的，有利于數(shù)據(jù)的共享，更重要的是在于事實表和維表的管理和維護，這樣子有利于數(shù)字隊列的操作，謝謝我就說這些。
