轉載：http://gitbook.cn/books/57107c8976dc085d7a00cb04/bookSource/1461911087389.html
我是吳瑞誠，來自鬥魚，很高興能有機會和大家分享鬥魚TV實時計算平臺的演進。
做一個簡單的自我介紹。我之前在淘寶幹過三年，主要做HBase，目前在鬥魚TV做大數據開發。
鬥魚典型直播間介紹
這是鬥魚非常典型的直播間，55開，遊戲打得好，牛吹得好，在鬥魚比較好，大家看到密密麻麻的字，就是彈幕，視頻直播最火的場景，彈幕。很火的時候，上面會有禮物，用戶給主播贈送火箭，鯊魚騎着火箭的禮物飄過，這個火箭價值還挺高。
右下角這些圖標是禮物，用戶贈送給主播的禮物，魚翅可以充值購買，魚丸贈送，右邊是土豪的貢獻排行榜，貢獻越多排名越高，右邊是彈幕區。內容和形態就是這樣，但是現在很火，有時候我們沒辦法預料現象級現象。
主要分享內容
第一，日誌檢索，日誌全局檢索。後面會展開，這個地方主要是以NginxPHP日誌做事例。
第二，實時CEP系統，類KV的處理系統。
第三，實時流計算，流計算。 strong text
一、日誌檢索
這是一個現在的大數據的架構圖，這個圖最近才整理出來，越整就覺得體會越深，這個圖裏面看一下紅紅綠綠有一些方塊，看PPT看得多的同學，可能司空見慣了，大數據架構圖到最後可能都是這個樣子，但是圖上的每一個塊都是踩過無數個坑，付出了血的教訓才成爲現在這樣。
我加入鬥魚，當時是一個人負責整個這一大塊的東西，後來就是因爲網站量上來了，個人吞吐量到了上限，招了第一批人。我第一批是組內培養的，會有一些java開發，生拉硬拽湊到大數據團隊，從最開始的小系統越做越大，做到現在這個架構。
最下面一層是數據源一層，Nginx、PHP日誌，公司技術棧比較多，處理起來會越來越蛋疼，現在統一接入層是是Kafka，現在還沒有完全接入。
上面一層就是數據清洗和格式轉換包括初步的結算。
再上面一層就包括依賴MySQL實現的歸檔數據，最大一塊是離線計算基於Hadoop，YARN。去年上線Spark，現在應用的範圍還比較小，主要還是在風控和個性推薦這一塊。
另外實時計算是Hbase，是之前經驗比較熟悉，Hbase大家覺得有很多替代的產品，我覺得Hbase在第一層兜住海量熱數據，我覺得Hbase的優勢還是非常明顯的。所以我這一塊一直會保持Hbase在這個地方使用，在快速查詢，可以相對於自助查詢走的presto。
右側實時計算主要基於Storm，今年大目標把spark作爲重點引入。對於新框架的考量，小公司二次的開發能力或者定製能力弱一些，我們現在主要應用短平快的一些方式，比如，主流的有一些大公司BAT、京東、美團把坑踩完了我們再上，這樣我們成本會小很多，我們會跟進spark，spark社區活躍得讓人沒辦法忽視它，它現在活躍程度比Hadoop強一個量級。
最右邊是Elastic，最開始引入的時候只是做一個搜索引擎，後來越用越覺得爽，真的是一個神器，後面會具體展開。
再就是上面的服務數據層，前端網站和服務層使用，再就是Dashboard，監控、個性推薦、用戶行爲分析、風控系統、搜索引擎、其它數據應用。
平臺監控非常重要。
這是Lambda架構，這三層架構，P處理層，再是上面的加速層到服務層，這三層架構，應該可以覆蓋絕大多數的大數據團隊架構的場景。
我們最開始，只有幾個PHP實例，出了問題，我就上去grep、awk，然後規模上來了，機器和應用實例突增，就用rsync和HiveUDF的方式，把日誌收集起來，按照時間粒度切碎了拖過來，然後用Hive進行一些匹配，形成這麼一個非常初級的系統。
到了現在，ELK，用的很爽的系統，能支持的量很大，可擴展，全文檢索，很多時候包括技術團隊定位問題非常方便，有這幾個特性能滿足基本使用。如果再能夠幫他們做一些告警，包括量的告警，文本的告警，有更好，這也是我們現在在做的。
這是實時日誌檢索的架構圖，大家可以看到應用場景，當時flume用得最多，應用場景變得比較快，我們的業務調整也非常迅猛，新場景中發現flume有兩個場景沒辦法滿足，一個場景是C++場景，它的量太大，他們的日誌按實例文件夾寫本地；一個是，Java太耗資源，包括CPU、包括內存，後來我們覺得這一塊要做一些改變。
最開始的方案，因爲我們有C++的團隊做服務化，他們覺得我們可以自己造輪子，這個輪子比較簡單，後來我做了一圈對比，發現Logstash新版本中，有一個Beats組件，是golang實現的。
架構圖中間以Elastic技術棧爲主，包括中間匯聚層在不久將來會被替換掉，但是現有的一些場景，如果一直穩定的話先保持現狀。因爲我們在這個階段它比較穩定。
Flume 的Memory channel在量大的時候會OOM，這個時候把溢出的量落地到disk上面，這樣可以在保證效率的同時能增大Flume能承受的吞吐量，這樣讓flume很穩定，一直沿用到現在。
現在還是用Flume做了匯聚層，我們後續會使用Kafka做匯聚層，有很多場景，有些日誌可能回頭還要再消費或者說要做Pub-sub，現在模式很難實現，必須要用到Kafka。
日誌數據在圖的下方走了Elastic，用Kibana做的UI，Kibana 2.0以後使用上會有很多不順暢，我這一塊其實建議大家二次開發，二次開發的成本不大，比較容易上手，所有的接口都可以走API，定製起來方便，圖上方是走的Hdfs出報表。
再說一下踩過的一些坑。
首先Flume的選型。我最開始看中還是因爲他是Apache的產品，覺得它穩定，在很多公司PPT裏面，我稍微估計一下，flume出現的概率比其它產品出現頻率高很多，所以做一些壓測做了對比，差不太多，就選了flume，現在要新用或者要換型需要更詳細的壓測。
channel這一塊，最開始內存到disk到現在兩個方案混搭在一起，但是佔資源特別耗資源。
flume的監控，一定要先考慮監控再上新的技術棧。
在Elastic上，我們跟Solr做對比，大家可以看一下純開源的組建跟有商業團隊支撐的開源產品，社區活躍度和產品迭代不是在一個量級上，Elastic現在已經開始注重使用體驗了，這一點是Solr還沒有納入考量的點。
因爲Elastic除了我們最開始最傳統的搜索引擎、文本搜索，現在更大的一塊可以當作我們的多維自助查詢，水平擴展能力非常強，因爲數據結構的天熱優勢，就有一些場景，包括多維的及時查詢這一塊有非常強悍的性能。
ES插件上，我們使用了Kopf做監控，head來操作索引。
ES讀寫分離。ES集羣拓撲越來越大，如果按照默認的拓撲來使用的話，可能量上沒法滿足很多場景，比如，如果讀寫不做分離，查詢極有可能把線上寫的節點直接壓垮，這樣就建議有一個專門的節點來負責讀。
對於資源隔離，我們使用了幾個小的Elastic的集羣來滿足各個功能。因爲，Elastic是P2P的，無主。無主有一個問題，有時候沒有辦法很強的控制某些節點行爲，這時候要做一些隔離，最見效的方式就是按照小集羣直接做隔離。
避免索引過大。這一點大家如果能注意把不必要的字段建到索引能解決大部分。
最熱的查詢中避免用range查詢。
JVM heapsize設置，我們現在一直使用32G，Hbase集羣也是這樣，儘管集羣配置很高，Hbase的配置還是32G。
GC方面，我們使用的是CMS，在線上使用、壓測表現看的話，G1穩定性和用戶體驗看來都會差一些。
二、實時CEP系統
最開始我們做一個指標統計，大家把數據推到我們這邊來做一些統計，然後藉助redis做統計並最後把結果數據保存在Redis，簡單的統計場景OK了，後來業務場景複雜了，產品線多了，redis單個實例肯定不夠，可擴展性和數據規模是redis暫時無法越過的門檻，所以我們又很自然用到了Hbase。
Hbase使用有兩大點需要注意：
第一，rowkey的設計，Hbase中除了rowkey沒有索引可供使用。
第二，數據壓縮，歷史數據的壓縮很關鍵。一個指標兩個指標做抽樣做一些歸檔很好做，但是怎麼做到統一，而且還很簡單，我們能直接拿來用，這個時候碰到open TSDB，一個時間序列存儲方案。
最開始也用了InfluxDB，感覺有時候只要壓力上來了之後，它可以沒有徵兆掛機，後來乾脆就考慮到open TSDB。數據揣拽產生圖形，基於OpenTSDB，能滿足很大的量。
這個系統中真正性能考驗的其實還是Hbase，Hbase OK，opentTSDB也就沒有問題，我們會一直把這個方案做下去，基於open TSDB，我們可以很靈活做定製，它本身就是基於Hbase做了定製的特性，包括我剛剛說到對rowkey的設計。
對數據壓縮，每一個指標每一個小時會有一個row，open TSDB幫我們做了。後面有定製需求我們從頭開始做，這一塊是比較簡單的，底層Hbase性能是沒有問題，越往後看，Hbase有很多地方它會做得越來越通用。因爲它的性能這一塊顯性能沒有問題，後面卡頓的問題會有明顯的提升。
回到剛剛上面的圖這是CEP系統，這個圖上面，大家可以看一下。
從數據收集，第一個parser會走到Kafka，從spark走到Hbase，走到這一步就走到了業務系統，包括我們的監控系統，這是有一個業務流程，現在可以簡單理解成某些指標大於閾值就覺得它的是一個嫌疑事件，需要告警的，簡單理解就是這樣，這一塊馬上引入規則引擎，這一塊業務變化頻率太快了，發佈速度拖了後腿，在已經測試上了。
到後面有一些結果的存儲，再有告警的推送，這個地方也是直接走到Hbase。後面有一些統計好的指標可以拿來用的，這個地方我們走到了open TSDB，這個圖就沒有重新再畫，直接從Cloudera Blog上面借用，這個架構圖和我們的系統是一模一樣的。
Open TSDB，業務指標非常靈活，我們現在有一些CPU指標，打出來我們收集起來，各個指標彙集在一起，而且是秒級的力度，這個力度因爲指標量大，時間粒度比較細，我們服務機器的服務數越來越大，現在還碰不到瓶頸。
關於Hbase使用。現在用Hbase的公司越來越多，2011年淘寶這一塊就已經開始在線上大規模使用，Hbase這一塊很穩定，從0.96之後就已經可以說到非常穩定，1.0有一些變化，1.0之後的Hbase是值得大家使用的。
rowkey設計可以寫一本書，這裏只做簡單介紹。Hbase沒有索引，所以rowkey非常關鍵，我們通過rowkey定位到數據，如果通過rowkey能約精確定位到數據，查詢效率越高，用這個思路看看業務場景和看看使用，可以做一些相應的優化，做一些提升。
HBase不適宜的場景，包括多維度索引、需要事務、穩定性要求極高。
關注寫熱點，一般，按照默認的Region Split方案，上線後如果寫壓力比較大，都會有寫熱點的問題，這時需要考慮預建region。再就是寫壓內考慮writebuffer、WAL、autoflush，我寫的要求很高，數據一致性要求很高那這事就不好辦，只有做權衡，寫性能上和數據一致上做權衡，下面三個參數只要你調了或者關了，可用性就會丟，有這個風險擇，這是預先告訴大家。
對日誌類的表化考慮關閉compact，手動觸發GC。
Open TSDB表設計和原數據和數據表。這是官方圖，講得非常透，大家看一下怎麼保證維的很多，數據量很大的時候，能夠基於open TSDB把這麼一個系統做得高效，就是通過一套rowkey，還有右圖按照時間力度做row的壓縮，我覺得主要這兩個特性保證它的性能。
這是跟open TSDB密切相關的兩個點。
三、實時流計算
這一塊我們現在鬥魚用得規模比較大，和大公司比可能就有一點小巫見大巫，但是我還是想分享一下，從0到1的過程，包括第三點，從1到1.1的過程。
流計算。比如，我們上了一個專題或者我剛開始提到，英雄聯盟有一個決賽，線上有量，量有多大，只能根據卡不卡，只能主觀上感覺卡不卡做一個評估。後臺服務器的一些數據指標比較延時，剛開始靠猜，靠感覺，感覺要上機器了，要調一些流或者壓力到另外一部分機上，靠感覺。
包括有一些上專題，比方說有一些活動，錘子或者魅族、樂視新品發佈，他們的量，有時候沒有能想象的大，有時候會非常大，但是我們沒有辦法做一些預案，所以這個時候我們就慢慢有了這個，這是我們最開始的一個迫於壓力有了這樣一個方案，redis實時統計的量。
用戶多了，鳥就多了，各種羊毛黨就越多，這一塊有了一個風控，再一個個性推薦，用戶多了之後，用戶羣體戶越來越多樣化，這一塊就考慮個性推薦，千人千面，這一塊是後來第二階段的需求。就有了現在storm加spark Streaming的方案在跑。
這是數據流的架構，最開始只有最上面的架構，web、APP，在Nginx Lua，這是錘子2發佈會捐贈的一個項目，他把世界上最快的兩個系統，一個是Nginx和Lua，加在一起性能非常好強悍。基於Lua和redis，性能好，又好用又穩定，又不喫資源。
到了Kafka這一層，就有了另外的一些數據，比方用戶行爲數據接入進來，關係表MySQL，我們沒有其它的關係存儲。到了Kafka出來之後就是storm，是線上規模用得最大，我剛纔說的數據產品都是基於storm，後面簡單介紹一下storm踩過一些坑。
Spark吞吐量是非常好的，因爲兩個數據模型就決定了他們兩個側重業務場景是不一樣的，後面離線計算，這個中間有一個是數據應用層，我們可以從實時計算到數據應用層，會寫到中間離線層，又有另外一批數據到前面的應用層，實時數據監控和其它應用。
剛剛講了數據收集這一塊，尤其用戶行爲數據，包括另外有一些服務層的服務，開始堆PHP，太耗資源，我們就發現OpenResty。
再用Storm，我先把這個羅列在這個地方，Storm優化主要就是基於這兩個邏輯對象圖。
Storm的新版本中，已經剝離了對ZK的依賴。我們所有的調優調這幾個對象的參數，比方提高並行度，我們要提高時間時效，就是基於這個圖。
這個圖中，數據流怎麼從這個流程裏面最快的流入，最快流出，這就是實時流計算的初衷或者說包括最終的解決方案，也就是一直在優化。就比方說我們在第一級Kafka或者redis出來之後進到storm，越簡單越快把消息弄進來最好。弄進來之後越快把消息處理完統計完把數據推走，越快推走對壓力越小，處理時效吞吐量越大。
如果我們做優化，會去分析在第一個bolt1或者bolt2，如果裏面有堆積，是在哪一個邏輯裏面堆積，會考慮增加並行度或簡化它的邏輯，讓數據流儘快從第一級到 第二級到第三級，流出數據流程，我們整個優化的思路就是這樣。
bolt1、2到bolt3，想跟大家分享，我們很多時候優化Storm忽略一個點，Storm依賴外部資源會成會我們的瓶頸，我們的數據沒辦法往外面推，沒辦法落地，後面一層堆積也會直接制約我們優化的一個瓶頸。
我們最後往redis寫，性能強悍，你一個storm沒問題，當時用一個redis做一些hush，做分散，還是解決不了，後來把redis替換掉。
這是我們在storm優化整體的思路，比較簡單，主要幾大塊。spout數和Kafka中的話題的partition數相匹配。監控每一個執行的時效，去做監控，及時發現某一些componet要不要做優化。
我們最開始上storm就有了spark流，流利用在時空監控的場景，這是今年2016年的大方向。
這是流的簡單使用有一些心得，踩過一些坑。批處理時間。換粗需要經常的使用的數據。集羣task並行度，使用Kryo序列化。
這是我們踩過的巨坑，最後和大家強調一下。
第一個踩過的巨坑就是監控。
我們有很多量，現象級的，百萬級的用戶立馬在一秒到十秒用湧入一個直播間，這個直播間放在和其它直播間放在一個server上面，立馬卡頓不卡用，如果在監控這一塊，可以解決很多的一些告警和預警。包括有一些業務的指標監控，監控這一塊非常重要。
今年做了比較大的一塊，就是在做統一監控平臺，現在我們也是在花主要的開發資源做這一塊，因爲我們前端有網站端後端有C++服務端，語言異構排查起來就存在，沒法定位，第一反應大家很本能甩鍋，就需要統一監控平臺。
第二，安全。
最開始太粗放，我們最開始做網絡隔離，我們的集羣是第一次做了網絡上的隔離，然後後來就包括人員越來越大，因爲不可能是我一個人幹，也不可能做這麼多業務場景，用的人越來越多，包括其它團隊，業務分析師做數據分析用到線上環境，這個地方安全非常重要。
第三，一定的餘量。
預估業務、提需求，上機器這麼一套下來，就一兩個月，小公司不要扣這部分的成本，起碼預留20%的量。
探索式數據集市、推薦系統、風控系統，這是我們今年最大的三塊目標。