編者按：大資料的題目看起來好寫，因為大家似乎都懂，但是其實也難寫，因為太大了，沒有具體的問題很難寫出有營養的東西，是以今天選取兩個qcon比較典型的例子來管中一窺大資料的魅影。
有的同學很困惑米國人不看知乎怎麼知道那麼多知識呢？米國人當然看quora啦，quora是一個問答社交軟體，問答社交的特點就是有各種各樣的計數器，比如文章的支援、反對、評論數量，使用者的關注、粉絲數量等等，随着使用者量的增加、文章的增多、以及帶來的互動的增長，quora處理的資料也是爆炸式增長。quora從第一天開始就長在雲上（aws），生産環境使用mysql和hbase做存儲，使用refshift和spark用來做資料分析，在這些元件的基礎上quora做了一個資料服務叫quanta，quanta的設計限制是：
a：資料更新之後不能丢失，要求持久化到disk
b：有billion級别的counter，單機放不下，是以需要分布式叢集
c：每秒寫>10w次，每秒讀>100w次，隻能用追加寫
d：讀寫都要很快
e：資源和負載能夠線性擴充，而且能夠擴充到目前負載的50倍
f：成本越低越好
quora還有很多基于時間序列資料計算，比如：
a：過去t時間内發生了什麼，基于滑動視窗
b：過去y時間内每隔x該事件發生了多少次，需要通路曆史存儲資料
c：x和y可以是任意的
還有比較複雜的計算是關系圖引入的多層聚合，如：
對于圖有兩種計算方式，一種是lazy update，隻更新單個節點，關聯節點在有讀操作發生時再觸發，一種是eager update，每次update都觸發整個關聯圖的更新，quora最終采用的是eager update，理由是：每次讀的時候都去做一次更新會加大延遲，不可接受；更新即使慢也沒關系，因為是異步的；圖更新比起讀操作還是極少的。當然有向無環圖dag有多種形狀，有線性的、菱形的，每種圖上的counter更新算法也略有不同，不再贅述。
整個quora的架構大概是這樣子的：
用戶端寫日志到一個journal系統，資料處理processor從journal系統不停pull資料然後分别更新圖和counter存儲服務，用戶端從counter服務讀資料，寫操作是追加資料到journal服務，update操作是以thrift message的形式來封裝的，是以可以支援各種各樣的client；processor是stateless的異步服務，可以批量讀取資料并做處理；counter存儲服務用的是hbase，理由是每個計數都可以利用column family字段來儲存若幹個時間視窗的資料，比如一天的、一周的等等，而且schema還可以随時改變，當設定ttl的時候資料還可以自動過期，吞吐量也足夠大；圖服務用的也是hbase，每一個row就是圖的一個edge，column family存儲的是入邊和出邊，而且通過設定bloom filter還可以實作negative查詢，這些模型都比較适合圖運算。
目前存在的問題是當processor處理update資料的時候可能會存在兩個job處理同一個圖的不同vertex的問題，quora對這個問題的解法也比較巧妙，就是通過簡單的算法将整個連通圖隔離出來，這個子圖中的所有節點都隻會在一個job中去運算，這樣就解決了沖突的問題。
總結下來quora将資料做了很好的model，主要分為兩大類，有計數的、有圖的，然後對兩類資料分治處理，尤其是在處理圖資料的時候通過将圖分割來解除依賴，是以不需要加鎖，極大提升了并行度；對系統也做了很好的設計，比如寫和更新解耦、更新可彈性伸縮、存儲采用hbase更為靈活，當然前提是要對業務有深度思考并對限制有清晰的判斷。
接下來的案例是spotify，spotify的問題是成長太快，在流量和使用者快速增長的時候，系統服務依賴也成指數級别增長，由于整個架構缺乏體系的思考和設計，是以在服務多了之後就出了一系列的問題，如隔三差五的小故障、hadoop挂掉、資料重複處理、很多資料流水線上的bug無法追查等等，針對這些問題，spotify做了一系列的改造。
首先是先暴露問題，做早期報警，然後做了一個有領域程式設計語言支援的監控工具datamon，datamon不僅僅做報警，更重要的是對資料的所有權進行了劃分，這是一個比較大的進步，報警大家都會做，但是把報警發給誰是一個更有挑戰的問題；針對排程和計算不好debug的問題做了一套叫styx的服務，styx的每一個job都用docker來做隔離，也暴露了更多的debug資訊出來，易用性上也比之前有很大提升，具體實作細節沒有多講；最後一步為了實作彈性擴縮容利用kubernetes做了一套系統叫gabo，不再贅述。
從spotify這個例子可以看出如果一個架構師或者cto沒有從體系上和整體架構上去思考問題，業務發展越快跪得越快，給飛機換輪子聽着很英勇但是能避免的還是盡量提前避免。
通過上面這兩個例子我們也能看出無論目前有了什麼樣的工具、多麼牛逼的産品，定義問題、提煉需求、确定問題邊界反而比直接去寫代碼更有價值，這才是我們的核心競争力，這些技能也就是我們平時所倡導的調研和思考，用在思考上的時間多了用在擦屁股上的時間也就少了，與君共勉。