深刻淺出計算機組成原理學習筆記：第五十二講

1、原理篇總結回顧

若是你一講一講跟到如今，那首先要恭喜你，立刻就看到勝利的曙光了。過去的50多講裏，我把計算機組成原理中的各個知識點，一點一點和你拆解了。對於其中的不少知識點，
我也給了相應的代碼示例和實際的應用案例。

不過呢，相信你和我同樣，以爲只瞭解這樣一個個零散的知識點和案例還不過癮。那麼從今天開始，咱們就進如應用篇。我會經過兩個應用系統的案例，串聯起計算機組成原理的兩大塊知識點，一個是咱們的整個存儲器系統，另外一個天然是咱們的CPU和指令系統了。

咱們今天就先從搭建一個大型的DMP系統開始，利⽤組成原理⾥⾯學到的存儲器知識，來作選型判斷，從⽽更深⼊地理解計算機組成原理。

2、DMP：數據管理平臺

咱們先來看一下什麼是DMP系統。DMP系統的全稱叫做數據管理平臺（Data?Management?Platform），目前普遍應用在互聯網的廣告定向（Ad?Targeting）、個性化推薦（Recommendation）這些領域。

一般來講，DMP系統會經過處理海量的互聯網訪問數據以及機器學習算法，給一個用戶標註上各類各樣的標籤。而後，在咱們作個性化推薦和廣告投放的時候，再利用這些這些標籤，去作實際的廣告排序、推薦等
工做。不管是Google的搜索廣告、淘寶裏千人千面的商品信息，仍是抖音裏的信息流推薦，背後都會有一個DMP系統。

一個DMP系統應該怎麼搭建呢？

那麼，一個DMP系統應該怎麼搭建呢？對於外部使用DMP的系統或者用戶來講，能夠簡單地把DMP當作是一個鍵-值對（Key-Value）數據庫。咱們的廣告系統或者推薦系統，能夠經過一個客戶端輸如用戶的惟一標識（ID），而後拿到這個用戶的各類信息。

這些信息中，有些是用戶的人口屬性信息（Demographic），好比性別、年齡；有些是很是具體的行爲（Behavior），好比用戶最近看過的商品是什麼，用戶的手機型號是什麼；有一些是咱們經過算法系統計
算出來的興趣（Interests），好比用戶喜歡健身、聽音樂；還有一些則是徹底經過機器學習算法得出的用戶向量，給後面的推薦算法或者廣告算法做爲數據輸入。

基於此，對於這個KV數據庫，咱們的指望也很清楚，那就是： 低響應時間（Low Response?Time）、 高可用性（High Availability）、 高併發（High Concurrency）、 海量數據（Big Data），同時咱們須要付得起對應的成本（AffordableCost）。若是用數字來衡量這些指標，那麼咱們的指望就會具體化成下面這樣。

對於這個KV數據庫，咱們的指望以下

1.低響應時間：通常的廣告系統留給整個⼴告投放決策的時間也就是10ms左右，因此對於訪問DMP獲取用戶數據，預期的響應時間都在1ms以內。

2.高可用性：DMP經常用在廣告系統裏面。DMP系統出問題，每每就意味着咱們整個的廣告收入在不可用的時間就沒了，因此咱們對於可用性的追求可謂是沒有上限的。Google?2018年的⼴告收⼊是1160億美
元，摺合到每一分鐘的收入是22萬美圓。即便咱們作到99.99%的可用性，也意味着每月咱們都會損失100萬美圓。

3.高併發：仍是以廣告系統爲例，若是天天咱們須要響應100億次的廣告請求，那麼咱們每秒的併發請求數就在100億/(86400)~=12K次左右，因此咱們的DMP須要支持高併發。

4.數據量：若是咱們的產品針對中國市場，那麼咱們須要有10億個Key，對應的假設每一個用戶有500個標籤，標籤有對應的分數。標籤和分數都用一個4字節（Bytes）的整數來表示，

那麼一共咱們須要10億x500x(4+4)Bytes=400TB的數據了。

5.低成本：咱們仍是從廣告系統的角度來考慮。廣告系統的收入一般用CPM（Cost Per Mille），也就是千次曝光來統計。若是千次曝光的利潤是$0.10，那麼天天100億次的曝光就是100萬美圓的利潤。這個利
潤聽起來很是高了。可是反過來算一下，你會發現，DMP每1000次的請求的成本不能超過$0.10。最好只有$0.01，甚至更低，咱們才能儘量多賺到一點廣告利潤。

這五個因素一結合，聽起來是否是就不那麼簡單了？不過，更復雜的還在後面呢。雖然從外部看起來，DMP特別簡單，就是一個KV數據庫，可是⽣成這個數據庫須要作的事情更多。
咱們下面一塊兒來看一看。

 

 

爲了可以生成這個KV數據庫，咱們須要有一個在客戶端或者Web端的數據採集模塊，不斷採集用的行爲，向後端的服務器發送數據。服務器端接收到數據，就要把這份數據放到一個 數據管道（DataPipeline）裏面。數據管道的下游，須要實際將數據落地到 數據倉庫（Data Warehouse），把全部的這些數據結構化地存儲起來。後續，咱們就能夠經過程序去分析這部分日誌，生成報表或者或者利用數據運算各類機器學習算法。

除了這個數據倉庫以外，咱們還會有一個實時數據處理模塊（Realtime Data Processing），也放在數據管道的下游。它一樣會讀取數據管道里面的數據，去進行各類實時計算，而後把須要的結果寫入到DMP的KV
數據庫裏面去。

3、MongoDB真的萬能嗎？

面對這裏的KV數據庫、數據管道以及數據倉庫，這三個不一樣的數據存儲的需求，最合理的技術方案是什麼呢？你能夠先本身思考一下，我這裏先賣個關子。

我共事過的很多不錯的Web程序員，面對這個問題的時候，經常會說：「這有什麼難的，用MongoDB就行了呀！」若是你也選擇了MongoDB，那最終的結果必定是一場災難。我爲何這麼說呢？

MongoDB的設計聽起來特別厲害，不須要預先數據Schema，訪問速度很快，還可以無限水平擴展。做爲KV數據庫，咱們能夠把MongoDB看成DMP裏面的KV數據庫；除此以外，MongoDB還能水平擴展、跑
MQL，咱們能夠把它看成數據倉庫來用。至於數據管道，只要咱們可以不斷往MongoDB裏面，插入新的數據就行了。從運維的角度來講，咱們只須要維護一種數據庫，技術棧也變得簡單了。看起來，MongoDB這
個選擇真是至關完美！

可是，做爲一個老程序員，第一次聽到MongoDB這樣「萬能」的解決方案，個人第一反應是，「天底下哪有這樣的好事」。全部的軟件系統，都有它的適用場景，想經過一種解決方案適應三個差別很是大的應用場
景，顯然既不合理，也不現實。接下來，咱們就來仔細看一下，這個「不合理」「不現實」在什麼地方。

一、數據管道和 數據倉庫的性能取捨

上面咱們已經講過DMP的KV數據庫指望的應用場景和性能要求了，這裏咱們就來看一下 數據管道和 數據倉庫的性能取捨。

對於數據管道來講，咱們須要的是高吞吐量，它的併發量雖然和KV數據庫差很少，可是在響應時間上，要求就沒有那麼嚴格了，1-2秒甚至再多幾秒的延時都是能夠接受的。並且，和KV數據庫不太同樣
，數據管道的數據讀寫都是順序讀寫，沒有大量的隨機讀寫的需求。

數據倉庫就更不同了，數據倉庫的數據讀取的量要比管道大得多。管道的數據讀取就是咱們當時寫如的數據，一天有10TB日誌數據，管道只會寫如10TB。下游的數據倉庫存放數據和實時數據模塊讀取的數據，
再加上個2倍的10TB，也就是20TB也就夠了。

可是，數據倉庫的數據分析任務要讀取的數據量就大多了。一方面，咱們可能要分析一週、一個月乃至一個季度的數據。這一次分析要讀取的數據可不是10TB，而是100TB乃⾄1PB。
咱們一天在數據倉庫上跑的分析任務也不是1個，而是成千上萬個，因此數據的讀取量是巨大的。另外一方面，咱們存儲在數據倉庫裏面的數據，也不像數據管道同樣，存放幾個小時、最多一天的數據，
而是每每要存上3個月甚至是1年的數據。因此，咱們須要的是1PB乃至5PB這樣的存儲空間。

二、爲何MongoDB在這三個應用場景都不合適?

我把KV數據庫、數據管道和數據倉庫的應用場景，總結成了一個表格，放在這裏。你能夠對照着看一下，想一想爲何MongoDB在這三個應用場景都不合適。

在KV數場據庫的景下，須要支持高併發。那麼MongoDB須要把更多的數據放在內存裏面，可是這樣咱們的存儲成本就會特別高了。

在數據管道的場景下，咱們須要的是大量的順序讀寫，而MongoDB則是一個文檔數據庫系統，並無爲順序寫入和吞吐量作過優化，看起來也不太適合。

而在數據倉庫的場景下，主要的數據讀取時順序讀取，而且須要海量的存儲。MongoDB這樣的文檔式數據庫也沒有爲海量的順序讀作過優化，仍然不是一個最佳的解決方案。並且文檔數據庫是老是會有不少冗餘的字段的元數據，還會浪費更多的存儲空間。

三、那咱們該選擇什麼樣的解決方案呢？

拿着咱們的應用場景去找方案，其實並不難找。對於KV數據庫，最佳的選擇方案天然是使用SSD硬盤，選擇AeroSpike這樣的KV數據庫。高併發的隨機訪問並不適合HDD的機械硬盤，而400TB的數據，
若是用內存的話，成本又會顯得過高。

對於數據管道，最佳選擇天然是Kafka。由於咱們追求的是吞吐率，採用了Zero-Copy和DMA機制的Kafka最大化了做爲數據管道的吞吐率。並且，數據管道的讀寫都是順序讀寫，
因此咱們也不須要對隨機讀寫提供支持，用上HDD硬盤就行了。

到了數據倉庫，存放的數據量更大了。在硬件層面使用HDD硬盤成了一個必選項。不然，咱們的存儲成本就會差上10倍。這麼大量的數據，在存儲上咱們須要定義清楚Schema，使得每一個字段都不
須要額外存儲元數據，可以經過Avro/Thrift/ProtoBuffer這樣的二進制序列化的方存儲下來，或者乾脆直接使用Hive這樣明確了字段定義的數據倉庫產品。很明顯，MongoDB那樣不限制
Schema的數據結構，在這個狀況下並很差用。

2012年先後作光告系統的時候，咱們也曾經嘗試使用MongoDB，儘管只是用做DMP中的數據報表部分。事實證實，即便是已經作了數據層面的彙總的報表，
MongoDB都沒法很好地支撐咱們須要的複雜需求。最終，咱們也不得不選擇在整個DMP技術棧裏面完全廢棄MongoDB，而只在Web應用裏面用MongoDB。
事實證實，我最初的直覺是正確的，並無什麼萬能的解決方案。

4、延伸總結

好了，相信到這裏，你應該對怎麼從最基本的原理出發，來選擇技術債有些感受了，你應該更多地從底層的存儲系統的特性和原理去考慮問題。一旦可以從這個角度去考慮問題，那麼你對各種新的技術項目和產品的公關稿，天然會有必定的免疫力了，而不會輕易根據商業公司的宣傳來作技術選型了

由於低延時、高併發、寫少讀多的DMP的KV數據庫，最適合用SSD硬盤，而且採用專門的KV數據庫是最合適的，咱們能夠選擇以前文章裏提過的AeroSpike ，也能夠用開源的Cassandra來提供服務

對於數據倉庫、咱們一般是一次寫入、屢次讀取。而且，因爲存儲的數據量很大，咱們還要考慮成本的問題因而、一方面，咱們會用HDD硬盤而不是SSD硬盤；另外一方面，咱們每每會預先給數據規定好Schema，使得單條數據的序列化，不須要像存JSON或者MongoDB的BSON那樣，存儲冗餘的字段名稱這樣的元數據。

因此，最多見的解決方案是，而Hadoop這樣的集羣，採用Hive這樣的數據倉庫系統，或者採用Avro/Thrift/ProtoBuffer這樣的⼆進制序列化方案。

在大型的DMP系統設計當中，咱們須要根據各個應用場景面臨的實際狀況，選擇不一樣的硬件和軟件的組合，來做爲整個系統中的不一樣組件。