我們先來(lái)看一下什么是DMP系統(tǒng)。DMP系統(tǒng)的全稱(chēng)叫作數(shù)據(jù)管理平臺(tái)（Data tform），目前廣泛應(yīng)用在互聯(lián)網(wǎng)的定向（AdTargeting）、個(gè)性 通常來(lái)說(shuō)，DMP通過(guò)海量聯(lián)網(wǎng)數(shù)據(jù)機(jī)器算法一個(gè)標(biāo)注上各種各樣的。然后，在我們做個(gè)性化推薦和投放的時(shí)候，再利用這些這些標(biāo)簽，去做實(shí)際的排序、推薦等工作。無(wú)論是的搜索、淘寶里千面的商品信息，還是里面的信息流推薦，背后都會(huì)有一個(gè)P那么，一個(gè)DMP系統(tǒng)應(yīng)該怎么搭建呢？對(duì)于外部使用DMP的系統(tǒng)或者用戶(hù)來(lái)說(shuō)，可以單地把DMP看成是一個(gè)鍵-值對(duì)（Key-Value）數(shù)據(jù)庫(kù)。我們的系統(tǒng)或者推薦系統(tǒng)可以通過(guò)一個(gè)客戶(hù)端輸入用戶(hù)的唯一標(biāo)識(shí)（ID），然后拿到這個(gè)用戶(hù)的各種信這些信息中，有些是用戶(hù)的人口屬性信息（emographc），比如、；有些是非常具體的行為（Br），比如用戶(hù)最近看過(guò)的商品是什么，用戶(hù)的型號(hào)是什么；有一些是我們通過(guò)算法系統(tǒng)計(jì)算出來(lái)的（Intts），比用戶(hù)喜歡、聽(tīng)音樂(lè)；一些完全機(jī)器算法的用量，面的算法作為數(shù)據(jù)輸入?；诖?，對(duì)于這個(gè)KV數(shù)據(jù)庫(kù)，我們的期望也很清楚，那就是：低響應(yīng)時(shí)間（LowResponseTime）、高可用性（HighAvailability）、高并發(fā)（HighConcurrency）、海量數(shù)據(jù)（BigData），同時(shí)我們需要付得起對(duì)應(yīng)的成本（AffordableCost）。如果用數(shù)字低響應(yīng)時(shí)間：一般的系統(tǒng)留給整個(gè)投放決策的時(shí)間也就是10ms左右，所以對(duì)于DMP獲取用戶(hù)數(shù)據(jù)，預(yù)期的響應(yīng)時(shí)間都在1ms之內(nèi)。高可用性：DMP常常用系統(tǒng)里面。DMP系統(tǒng)出問(wèn)題，往往就意味著我們整個(gè)的收入在不可用的時(shí)間就沒(méi)了，所以我們對(duì)于可用性的追求可謂是沒(méi)有上限的。28年的收入是60億，折合到每一分鐘的收入是2使我們做到9%的可用性，也意味著每個(gè)月我們都會(huì)損失00萬(wàn)。高并發(fā)：還是以系統(tǒng)為例，如果每天我們需要響應(yīng)100億次的請(qǐng)求，那么們每秒的并發(fā)請(qǐng)求數(shù)就在100億/(86400)~=12K次左右，所以我們的DMP需要支數(shù)據(jù)量：如果我們的產(chǎn)品針市場(chǎng)，那么我們需要有10億個(gè)Key，對(duì)應(yīng)的假設(shè)每個(gè)用戶(hù)有500個(gè)，有對(duì)應(yīng)的分?jǐn)?shù)。和分?jǐn)?shù)都用一個(gè)4字節(jié)（Bytes）的整數(shù)來(lái)表示，那么一共我們需要10億x500x(4+4)Bytes=400TB的數(shù)據(jù)了。低成本：我們還是從系統(tǒng)的角度來(lái)考慮。系統(tǒng)的收入通常用CPM（CostMille），也就是千次來(lái)統(tǒng)計(jì)。如果千次的利潤(rùn)是$0.10，那么每天100億次的就是100萬(wàn)的利潤(rùn)。這個(gè)利潤(rùn)聽(tīng)起來(lái)非常高了。但是反過(guò)來(lái)算一下，你會(huì)發(fā)現(xiàn)，DMP每1000次的請(qǐng)求的成本過(guò)$0.10。最好只有$0.01，甚至更低，這五個(gè)因素一結(jié)合，聽(tīng)起來(lái)是不是就不那么簡(jiǎn)單了？不過(guò)，更復(fù)雜的還在后面雖然從外部看起來(lái)，DMP別簡(jiǎn)單，就是一個(gè)KV據(jù)庫(kù)，但是生成這個(gè)數(shù)據(jù)庫(kù)需要做的在這個(gè)系統(tǒng)中，我們關(guān)心的是藍(lán)色的數(shù)據(jù)管道、綠色的數(shù)據(jù)倉(cāng)庫(kù)和KV數(shù)據(jù)為了能夠生成這個(gè)KV數(shù)據(jù)庫(kù)我們需要有一個(gè)在客戶(hù)端或者Web端的模塊，斷用戶(hù)的行為，向后端的服務(wù)器發(fā)送數(shù)據(jù)。服務(wù)器端接收到數(shù)據(jù)，就要把這份數(shù)據(jù)放到數(shù)據(jù)管道（ataPipele數(shù)據(jù)倉(cāng)庫(kù)（DataWarehouse），把所有的這些數(shù)據(jù)結(jié)構(gòu)化地起來(lái)。后續(xù)，我們就可以通過(guò)程序除了這個(gè)數(shù)據(jù)倉(cāng)庫(kù)之外，我們還會(huì)有一個(gè)實(shí)時(shí)數(shù)據(jù)處理模塊（RealtimeData實(shí)時(shí)計(jì)算，然后把需要的結(jié)果寫(xiě)入到DMP的KV數(shù)據(jù)庫(kù)里面去。MongoDB面對(duì)這里的KV數(shù)據(jù)庫(kù)、數(shù)據(jù)管道以及數(shù)據(jù)倉(cāng)庫(kù)，這三個(gè)不同的數(shù)據(jù)的需求，最合理的我共事過(guò)的不少不錯(cuò)的Web程序員，面對(duì)這個(gè)問(wèn)題的時(shí)候，常常會(huì)說(shuō)：“這有什么難的，用MongoDB就好了呀！”如果你也選擇了MongoDB，那最終的結(jié)果一定是一場(chǎng)。DB的設(shè)計(jì)起來(lái)特別厲害，不需要預(yù)先數(shù)據(jù)a，速度很快，還能夠無(wú)限水平擴(kuò)展。作為KVBPKV數(shù)據(jù)庫(kù)；除DBDB要一種數(shù)據(jù)庫(kù)，技術(shù)棧也變得簡(jiǎn)單了?？雌饋?lái)，oB個(gè)選擇真是相但是，作為一個(gè)老程序員，第一次聽(tīng)到MongoDB這樣“萬(wàn)能”的解決方案，我的第一反上面我們已經(jīng)講過(guò)DMP的KV數(shù)據(jù)庫(kù)期望的應(yīng)用場(chǎng)景和性能要求了，這里我們就數(shù)據(jù)管道和數(shù)據(jù)倉(cāng)庫(kù)的性能取舍對(duì)于數(shù)據(jù)管道來(lái)說(shuō)，我們需要的是高吞吐量，它的并發(fā)量雖然和KV數(shù)據(jù)庫(kù)差不多，但是在響應(yīng)時(shí)間上，要求就沒(méi)有那么嚴(yán)格了，1-2秒甚至再多幾秒的延時(shí)都是可以接受的。而且，和KV數(shù)據(jù)庫(kù)不太一樣，數(shù)據(jù)管道的數(shù)據(jù)讀寫(xiě)都是順序讀寫(xiě)，沒(méi)有大量的隨機(jī)讀寫(xiě)的需數(shù)據(jù)倉(cāng)庫(kù)就更不一樣了，數(shù)據(jù)倉(cāng)庫(kù)的數(shù)據(jù)的量要比管道大得多。管道的數(shù)據(jù)就是我們當(dāng)時(shí)寫(xiě)入的數(shù)據(jù)，一天有BB塊的數(shù)據(jù)，再加上個(gè)2的B是B，數(shù)庫(kù)的分析要數(shù)據(jù)大多一方我們要分周、一個(gè)月乃至一個(gè)季度的數(shù)據(jù)。這一次分析要的數(shù)據(jù)可不是B是BB1是巨。另面，們據(jù)倉(cāng)面的，也數(shù)據(jù)一樣放幾個(gè)小時(shí)、最多一天的數(shù)據(jù)，而是往往要存上3個(gè)月甚至是1B至B樣的空間。我把KV據(jù)庫(kù)、數(shù)據(jù)管道和數(shù)據(jù)倉(cāng)庫(kù)的應(yīng)用場(chǎng)景，總結(jié)成了一個(gè)表格，放在這里。你可以對(duì)照著看一下，想想為什么MongoDB在這三個(gè)應(yīng)用場(chǎng)景都不合適。在KV數(shù)據(jù)庫(kù)的場(chǎng)景下，需要支持高并發(fā)。那么MongoDB需要把的數(shù)據(jù)放在內(nèi)存里在數(shù)據(jù)管道的場(chǎng)景下，我們需要的是大量的順序讀寫(xiě)MongoDB是一個(gè)文檔數(shù)據(jù)庫(kù)那我們?cè)撨x擇什么樣的解決方案拿著我們的應(yīng)用場(chǎng)景去找方案，其實(shí)并不難找。對(duì)于KV數(shù)據(jù)庫(kù)，最佳的選擇方案自然是使用SSD硬盤(pán)，選擇Aeroe這樣的KV數(shù)據(jù)庫(kù)。高并發(fā)的隨機(jī)并不適合HDD的機(jī)械硬盤(pán)，而400TB的數(shù)據(jù)，如果用內(nèi)存的話(huà)，成本又會(huì)顯得太高。對(duì)于數(shù)據(jù)管道，最佳選擇自然是Kafka。因?yàn)槲覀冏非蟮氖峭掏侣?，采用了Zero-CopyDMA機(jī)制的Kafka最大化了作為數(shù)據(jù)管道的吞吐率。而且，數(shù)據(jù)管道的讀寫(xiě)都是順序讀寫(xiě)，所以我們也不需要對(duì)隨機(jī)讀寫(xiě)提供支持，用上HDD硬盤(pán)就好了。到了數(shù)據(jù)倉(cāng)庫(kù)，存放的數(shù)據(jù)量更大了。在硬件層面使用HDD硬盤(pán)成了一個(gè)必選項(xiàng)。否則，我們的成本就會(huì)差上10倍。這么大量的數(shù)據(jù)，在上我們需要定義清楚Schema，使得每個(gè)字段都不需要額外元數(shù)據(jù)，能夠通過(guò)Avro/Thrift/ProtoBuffer這樣的二進(jìn)制序列化的方下來(lái)，或者干脆直接使用Hive這樣明確了字段定義的數(shù)據(jù)倉(cāng)庫(kù)產(chǎn)品。很明顯，MongoDB那樣不限制Schema的數(shù)據(jù)結(jié)構(gòu)，在這個(gè)情況下并不好用。2年前后做系統(tǒng)的時(shí)候，我們也曾經(jīng)嘗試使用MongoB，盡管只是用作DMP中的數(shù)據(jù)報(bào)表部分。事實(shí)證明，即使是已經(jīng)做了數(shù)據(jù)層面的匯總的報(bào)表，oBPB，而只在Web應(yīng)用里用用B。事實(shí)證明，我最初的是正確的，并沒(méi)有什么萬(wàn)能的解決方案。地從底層的系統(tǒng)的特性和原理去考慮問(wèn)題。一旦能夠從這個(gè)角度去考慮問(wèn)題，那因?yàn)榈脱訒r(shí)、高并發(fā)、寫(xiě)少讀多的DMP的KV數(shù)據(jù)庫(kù)，最適合用SSD硬盤(pán)，并且采用專(zhuān)門(mén)的KV數(shù)據(jù)庫(kù)是最合適的。我們可以選擇之前文章里提過(guò)的Aeroe，也可以用開(kāi)源的Cassandra來(lái)提供服務(wù)。對(duì)于數(shù)據(jù)管道，因?yàn)橹饕琼樞蜃x和順序?qū)?，所以我們不一定要選用SSD硬盤(pán)，而可以用HDD硬盤(pán)。不過(guò)，對(duì)于最大化吞吐量的需求，使用zero-copy和DMA是必不可少的，所以現(xiàn)在的數(shù)據(jù)管道的標(biāo)準(zhǔn)解決方案就是Kafka了。考慮成本問(wèn)題。于是，一方面，我們會(huì)用HDD硬盤(pán)而不是SSD硬盤(pán)；另一方面，我們往往會(huì)預(yù)先給數(shù)據(jù)規(guī)定好Schema，使得單條數(shù)據(jù)的序列化，不需要像存JSON或者M(jìn)ongoDB的BSON那樣，冗余的字段名稱(chēng)這樣的元數(shù)據(jù)。所以，最常用的解決方案是，用Hadoop這樣的集群，采用Hive這樣的數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)，或者采用Avro/Thrift/ProtoBuffer這樣的二進(jìn)制序列化方案。在大型的DMP系統(tǒng)設(shè)計(jì)當(dāng)中，我們需要根據(jù)各個(gè)應(yīng)用場(chǎng)景的實(shí)際情況，選擇不同的硬如果通過(guò)這一講的內(nèi)容，能讓你對(duì)大型數(shù)據(jù)系統(tǒng)的設(shè)計(jì)有了，那就再好不過(guò)了。我推薦你去讀一讀《數(shù)據(jù)密集型應(yīng)用系統(tǒng)設(shè)計(jì)》這本書(shū)，深入了解一下，設(shè)計(jì)數(shù)據(jù)系統(tǒng)需要關(guān)注的各個(gè)要點(diǎn)。這一