我是吳瑞誠，來自斗魚，很高興能有機會和大家分享斗魚TV實時計算平臺的演進。 做一個簡單的自我介紹。我之前在淘寶干過三年，主要做HBase，目前在斗魚TV做大數據開發(fā)。

這是斗魚非常典型的直播間，55開，游戲打得好，牛吹得好，在斗魚比較好，大家看到密密麻麻的字，就是彈幕，視頻直播最火的場景，彈幕。很火的時候，上面會有禮物，用戶給主播贈送火箭，鯊魚騎著火箭的禮物飄過，這個火箭價值還挺高。

右下角這些圖標是禮物，用戶贈送給主播的禮物，魚翅可以充值購買，魚丸贈送，右邊是土豪的貢獻排行榜，貢獻越多排名越高，右邊是彈幕區(qū)。內容和形態(tài)就是這樣，但是現在很火，有時候我們沒辦法預料現象級現象。

主要分享內容

第一，日志檢索，日志全局檢索。后面會展開，這個地方主要是以NginxPHP日志做事例。

第二，實時CEP系統(tǒng)，類KV的處理系統(tǒng)。

第三，實時流計算，流計算。 strong text

一、日志檢索

這是一個現在的大數據的架構圖，這個圖最近才整理出來，越整就覺得體會越深，這個圖里面看一下紅紅綠綠有一些方塊，看PPT看得多的同學，可能司空見慣了，大數據架構圖到最后可能都是這個樣子，但是圖上的每一個塊都是踩過無數個坑，付出了血的教訓才成為現在這樣。

我加入斗魚，當時是一個人負責整個這一大塊的東西，后來就是因為網站量上來了，個人吞吐量到了上限，招了第一批人。我第一批是組內培養(yǎng)的，會有一些java開發(fā)，生拉硬拽湊到大數據團隊，從最開始的小系統(tǒng)越做越大，做到現在這個架構。

最下面一層是數據源一層，Nginx、PHP日志，公司技術棧比較多，處理起來會越來越蛋疼，現在統(tǒng)一接入層是是Kafka，現在還沒有完全接入。

上面一層就是數據清洗和格式轉換包括初步的結算。

再上面一層就包括依賴MySQL實現的歸檔數據，最大一塊是離線計算基于Hadoop，YARN。去年上線Spark，現在應用的范圍還比較小，主要還是在風控和個性推薦這一塊。

另外實時計算是Hbase，是之前經驗比較熟悉，Hbase大家覺得有很多替代的產品，我覺得Hbase在第一層兜住海量熱數據，我覺得Hbase的優(yōu)勢還是非常明顯的。所以我這一塊一直會保持Hbase在這個地方使用，在快速查詢，可以相對于自助查詢走的presto。

右側實時計算主要基于Storm，今年大目標把spark作為重點引入。對于新框架的考量，小公司二次的開發(fā)能力或者定制能力弱一些，我們現在主要應用短平快的一些方式，比如，主流的有一些大公司BAT、京東、美團把坑踩完了我們再上，這樣我們成本會小很多，我們會跟進spark，spark社區(qū)活躍得讓人沒辦法忽視它，它現在活躍程度比Hadoop強一個量級。

最右邊是Elastic，最開始引入的時候只是做一個搜索引擎，后來越用越覺得爽，真的是一個神器，后面會具體展開。

再就是上面的服務數據層，前端網站和服務層使用，再就是Dashboard，監(jiān)控、個性推薦、用戶行為分析、風控系統(tǒng)、搜索引擎、其它數據應用。

平臺監(jiān)控非常重要。

這是Lambda架構，這三層架構，P處理層，再是上面的加速層到服務層，這三層架構，應該可以覆蓋絕大多數的大數據團隊架構的場景。

實時日志檢索

從前：grep + awk

演進：rsync + Hive UDF

現在：ELK

我們最開始，只有幾個PHP實例，出了問題，我就上去grep、awk，然后規(guī)模上來了，機器和應用實例突增，就用rsync和HiveUDF的方式，把日志收集起來，按照時間粒度切碎了拖過來，然后用Hive進行一些匹配，形成這么一個非常初級的系統(tǒng)。

到了現在，ELK，用的很爽的系統(tǒng)，能支持的量很大，可擴展，全文檢索，很多時候包括技術團隊定位問題非常方便，有這幾個特性能滿足基本使用。如果再能夠幫他們做一些告警，包括量的告警，文本的告警，有更好，這也是我們現在在做的。

這是實時日志檢索的架構圖，大家可以看到應用場景，當時flume用得最多，應用場景變得比較快，我們的業(yè)務調整也非常迅猛，新場景中發(fā)現flume有兩個場景沒辦法滿足，一個場景是C++場景，它的量太大，他們的日志按實例文件夾寫本地;一個是，Java太耗資源，包括CPU、包括內存，后來我們覺得這一塊要做一些改變。

最開始的方案，因為我們有C++的團隊做服務化，他們覺得我們可以自己造輪子，這個輪子比較簡單，后來我做了一圈對比，發(fā)現Logstash新版本中，有一個Beats組件，是golang實現的。

架構圖中間以Elastic技術棧為主，包括中間匯聚層在不久將來會被替換掉，但是現有的一些場景，如果一直穩(wěn)定的話先保持現狀。因為我們在這個階段它比較穩(wěn)定。

Flume 的Memory channel在量大的時候會OOM，這個時候把溢出的量落地到disk上面，這樣可以在保證效率的同時能增大Flume能承受的吞吐量，這樣讓flume很穩(wěn)定，一直沿用到現在。

現在還是用Flume做了匯聚層，我們后續(xù)會使用Kafka做匯聚層，有很多場景，有些日志可能回頭還要再消費或者說要做Pub-sub，現在模式很難實現，必須要用到Kafka。

日志數據在圖的下方走了Elastic，用Kibana做的UI，Kibana 2.0以后使用上會有很多不順暢，我這一塊其實建議大家二次開發(fā)，二次開發(fā)的成本不大，比較容易上手，所有的接口都可以走API，定制起來方便，圖上方是走的Hdfs出報表。

FLUME

選項

Channel

Flume 監(jiān)控

再說一下踩過的一些坑。

首先Flume的選型。我最開始看中還是因為他是Apache的產品，覺得它穩(wěn)定，在很多公司PPT里面，我稍微估計一下，flume出現的概率比其它產品出現頻率高很多，所以做一些壓測做了對比，差不太多，就選了flume，現在要新用或者要換型需要更詳細的壓測。

channel這一塊，最開始內存到disk到現在兩個方案混搭在一起，但是占資源特別耗資源。

flume的監(jiān)控，一定要先考慮監(jiān)控再上新的技術棧。

ERK

ES vs Solr

ES 插件：KOPF集群監(jiān)控：hesd 索引操作;

ES 讀寫分離

獨立小集群解決慢查詢;

避免索引過大

最熱的查詢中避免使用 Range 查詢;

JVM heapsize 設置;

CMS vs G1

在Elastic上，我們跟Solr做對比，大家可以看一下純開源的組建跟有商業(yè)團隊支撐的開源產品，社區(qū)活躍度和產品迭代不是在一個量級上，Elastic現在已經開始注重使用體驗了，這一點是Solr還沒有納入考量的點。

因為Elastic除了我們最開始最傳統(tǒng)的搜索引擎、文本搜索，現在更大的一塊可以當作我們的多維自助查詢，水平擴展能力非常強，因為數據結構的天熱優(yōu)勢，就有一些場景，包括多維的及時查詢這一塊有非常強悍的性能。

ES插件上，我們使用了Kopf做監(jiān)控，head來操作索引。

ES讀寫分離。ES集群拓撲越來越大，如果按照默認的拓撲來使用的話，可能量上沒法滿足很多場景，比如，如果讀寫不做分離，查詢極有可能把線上寫的節(jié)點直接壓垮，這樣就建議有一個專門的節(jié)點來負責讀。

對于資源隔離，我們使用了幾個小的Elastic的集群來滿足各個功能。因為，Elastic是P2P的，無主。無主有一個問題，有時候沒有辦法很強的控制某些節(jié)點行為，這時候要做一些隔離，最見效的方式就是按照小集群直接做隔離。

避免索引過大。這一點大家如果能注意把不必要的字段建到索引能解決大部分。

最熱的查詢中避免用range查詢。

JVM heapsize設置，我們現在一直使用32G，Hbase集群也是這樣，盡管集群配置很高，Hbase的配置還是32G。

GC方面，我們使用的是CMS，在線上使用、壓測表現看的話，G1穩(wěn)定性和用戶體驗看來都會差一些。

二、實時CEP系統(tǒng)

從前： Redis

演進：HBase

現在：TSDB

最開始我們做一個指標統(tǒng)計，大家把數據推到我們這邊來做一些統(tǒng)計，然后借助redis做統(tǒng)計并最后把結果數據保存在Redis，簡單的統(tǒng)計場景OK了，后來業(yè)務場景復雜了，產品線多了，redis單個實例肯定不夠，可擴展性和數據規(guī)模是redis暫時無法越過的門檻，所以我們又很自然用到了Hbase。

Hbase使用有兩大點需要注意：

第一，rowkey的設計，Hbase中除了rowkey沒有索引可供使用。

第二，數據壓縮，歷史數據的壓縮很關鍵。一個指標兩個指標做抽樣做一些歸檔很好做，但是怎么做到統(tǒng)一，而且還很簡單，我們能直接拿來用，這個時候碰到open TSDB，一個時間序列存儲方案。

最開始也用了InfluxDB，感覺有時候只要壓力上來了之后，它可以沒有征兆掛機，后來干脆就考慮到open TSDB。數據揣拽產生圖形，基于OpenTSDB，能滿足很大的量。

這個系統(tǒng)中真正性能考驗的其實還是Hbase，Hbase OK，opentTSDB也就沒有問題，我們會一直把這個方案做下去，基于open TSDB，我們可以很靈活做定制，它本身就是基于Hbase做了定制的特性，包括我剛剛說到對rowkey的設計。

對數據壓縮，每一個指標每一個小時會有一個row，open TSDB幫我們做了。后面有定制需求我們從頭開始做，這一塊是比較簡單的，底層Hbase性能是沒有問題，越往后看，Hbase有很多地方它會做得越來越通用。因為它的性能這一塊顯性能沒有問題，后面卡頓的問題會有明顯的提升。

回到剛剛上面的圖這是CEP系統(tǒng)，這個圖上面，大家可以看一下。

從數據收集，第一個parser會走到Kafka，從spark走到Hbase，走到這一步就走到了業(yè)務系統(tǒng)，包括我們的監(jiān)控系統(tǒng)，這是有一個業(yè)務流程，現在可以簡單理解成某些指標大于閾值就覺得它的是一個嫌疑事件，需要告警的，簡單理解就是這樣，這一塊馬上引入規(guī)則引擎，這一塊業(yè)務變化頻率太快了，發(fā)布速度拖了后腿，在已經測試上了。

到后面有一些結果的存儲，再有告警的推送，這個地方也是直接走到Hbase。后面有一些統(tǒng)計好的指標可以拿來用的，這個地方我們走到了open TSDB，這個圖就沒有重新再畫，直接從Cloudera Blog上面借用，這個架構圖和我們的系統(tǒng)是一模一樣的。

關于 Open TSDB：

周期 IO 波動問題：①禁用 OpenTSDB 的Compation機制;②數據壓縮過速度

Open TSDB，業(yè)務指標非常靈活，我們現在有一些CPU指標，打出來我們收集起來，各個指標匯集在一起，而且是秒級的力度，這個力度因為指標量大，時間粒度比較細，我們服務機器的服務數越來越大，現在還碰不到瓶頸。

關于HBase：

Rowkey 設計是關鍵;

不適宜多維度索引、需要事務、穩(wěn)定性要求極高;

關注寫熱點;

writebuffer，WAL,Autoflush;

關閉compact/split、手動觸發(fā)GC

關于Hbase使用?，F在用Hbase的公司越來越多，2011年淘寶這一塊就已經開始在線上大規(guī)模使用，Hbase這一塊很穩(wěn)定，從0.96之后就已經可以說到非常穩(wěn)定，1.0有一些變化，1.0之后的Hbase是值得大家使用的。

rowkey設計可以寫一本書，這里只做簡單介紹。Hbase沒有索引，所以rowkey非常關鍵，我們通過rowkey定位到數據，如果通過rowkey能約精確定位到數據，查詢效率越高，用這個思路看看業(yè)務場景和看看使用，可以做一些相應的優(yōu)化，做一些提升。

HBase不適宜的場景，包括多維度索引、需要事務、穩(wěn)定性要求極高。

關注寫熱點，一般，按照默認的Region Split方案，上線后如果寫壓力比較大，都會有寫熱點的問題，這時需要考慮預建region。再就是寫壓內考慮writebuffer、WAL、autoflush，我寫的要求很高，數據一致性要求很高那這事就不好辦，只有做權衡，寫性能上和數據一致上做權衡，下面三個參數只要你調了或者關了，可用性就會丟，有這個風險擇，這是預先告訴大家。

對日志類的表化考慮關閉compact，手動觸發(fā)GC。

Open TSDB表設計和原數據和數據表。這是官方圖，講得非常透，大家看一下怎么保證維的很多，數據量很大的時候，能夠基于open TSDB把這么一個系統(tǒng)做得高效，就是通過一套rowkey，還有右圖按照時間力度做row的壓縮，我覺得主要這兩個特性保證它的性能。

這是跟open TSDB密切相關的兩個點。

三、實時流計算

這一塊我們現在斗魚用得規(guī)模比較大，和大公司比可能就有一點小巫見大巫，但是我還是想分享一下，從0到1的過程，包括第三點，從1到1.1的過程。

實時流計算

以前：靠猜

演進：Redis

現在：Storm + Spark Streaming

流計算。比如，我們上了一個專題或者我剛開始提到，英雄聯(lián)盟有一個決賽，線上有量，量有多大，只能根據卡不卡，只能主觀上感覺卡不卡做一個評估。后臺服務器的一些數據指標比較延時，剛開始靠猜，靠感覺，感覺要上機器了，要調一些流或者壓力到另外一部分機上，靠感覺。

包括有一些上專題，比方說有一些活動，錘子或者魅族、樂視新品發(fā)布，他們的量，有時候沒有能想象的大，有時候會非常大，但是我們沒有辦法做一些預案，所以這個時候我們就慢慢有了這個，這是我們最開始的一個迫于壓力有了這樣一個方案，redis實時統(tǒng)計的量。

用戶多了，鳥就多了，各種羊毛黨就越多，這一塊有了一個風控，再一個個性推薦，用戶多了之后，用戶群體戶越來越多樣化，這一塊就考慮個性推薦，千人千面，這一塊是后來第二階段的需求。就有了現在storm加spark Streaming的方案在跑。

這是數據流的架構，最開始只有最上面的架構，web、APP，在Nginx Lua，這是錘子2發(fā)布會捐贈的一個項目，他把世界上最快的兩個系統(tǒng)，一個是Nginx和Lua，加在一起性能非常好強悍。基于Lua和redis，性能好，又好用又穩(wěn)定，又不吃資源。

到了Kafka這一層，就有了另外的一些數據，比方用戶行為數據接入進來，關系表MySQL，我們沒有其它的關系存儲。到了Kafka出來之后就是storm，是線上規(guī)模用得最大，我剛才說的數據產品都是基于storm，后面簡單介紹一下storm踩過一些坑。

Spark吞吐量是非常好的，因為兩個數據模型就決定了他們兩個側重業(yè)務場景是不一樣的，后面離線計算，這個中間有一個是數據應用層，我們可以從實時計算到數據應用層，會寫到中間離線層，又有另外一批數據到前面的應用層，實時數據監(jiān)控和其它應用。

關于數據收集

以前：堆PHP

現在：OpenResty

剛剛講了數據收集這一塊，尤其用戶行為數據，包括另外有一些服務層的服務，開始堆PHP，太耗資源，我們就發(fā)現OpenResty。

再用Storm，我先把這個羅列在這個地方，Storm優(yōu)化主要就是基于這兩個邏輯對象圖。

Storm的新版本中，已經剝離了對ZK的依賴。我們所有的調優(yōu)調這幾個對象的參數，比方提高并行度，我們要提高時間時效，就是基于這個圖。

這個圖中，數據流怎么從這個流程里面最快的流入，最快流出，這就是實時流計算的初衷或者說包括最終的解決方案，也就是一直在優(yōu)化。就比方說我們在第一級Kafka或者redis出來之后進到storm，越簡單越快把消息弄進來最好。弄進來之后越快把消息處理完統(tǒng)計完把數據推走，越快推走對壓力越小，處理時效吞吐量越大。

如果我們做優(yōu)化，會去分析在第一個bolt1或者bolt2，如果里面有堆積，是在哪一個邏輯里面堆積，會考慮增加并行度或簡化它的邏輯，讓數據流盡快從第一級到 第二級到第三級，流出數據流程，我們整個優(yōu)化的思路就是這樣。

bolt1、2到bolt3，想跟大家分享，我們很多時候優(yōu)化Storm忽略一個點，Storm依賴外部資源會成會我們的瓶頸，我們的數據沒辦法往外面推，沒辦法落地，后面一層堆積也會直接制約我們優(yōu)化的一個瓶頸。

我們最后往redis寫，性能強悍，你一個storm沒問題，當時用一個redis做一些hush，做分散，還是解決不了，后來把redis替換掉。

關于 Storm 優(yōu)化

Spout數和Kafka中Topic 的 Partition 數相匹配

根據excute latency，找出各個 componet 的 process cost

讓 spout nextTuple 盡量簡單

提升 Storm Topology的性能要注意外部資源

這是我們在storm優(yōu)化整體的思路，比較簡單，主要幾大塊。 spout數和Kafka中的話題的partition數相匹配。 監(jiān)控每一個執(zhí)行的時效，去做監(jiān)控，及時發(fā)現某一些componet要不要做優(yōu)化。

我們最開始上storm就有了spark流，流利用在時空監(jiān)控的場景，這是今年2016年的大方向。

關于 Spark Streaming

設置合理的批處理時間(batchDuration)

緩存需要經常使用的數據

集群task并行度

使用Kryo序列化

這是流的簡單使用有一些心得，踩過一些坑。批處理時間。換粗需要經常的使用的數據。集群task并行度，使用Kryo序列化。

這是我們踩過的巨坑，最后和大家強調一下。

踩過的巨坑

監(jiān)控

安全

余量

第一個踩過的巨坑就是監(jiān)控。

我們有很多量，現象級的，百萬級的用戶立馬在一秒到十秒用涌入一個直播間，這個直播間放在和其它直播間放在一個server上面，立馬卡頓不卡用，如果在監(jiān)控這一塊，可以解決很多的一些告警和預警。包括有一些業(yè)務的指標監(jiān)控，監(jiān)控這一塊非常重要。

今年做了比較大的一塊，就是在做統(tǒng)一監(jiān)控平臺，現在我們也是在花主要的開發(fā)資源做這一塊，因為我們前端有網站端后端有C++服務端，語言異構排查起來就存在，沒法定位，第一反應大家很本能甩鍋，就需要統(tǒng)一監(jiān)控平臺。

第二，安全。

最開始太粗放，我們最開始做網絡隔離，我們的集群是第一次做了網絡上的隔離，然后后來就包括人員越來越大，因為不可能是我一個人干，也不可能做這么多業(yè)務場景，用的人越來越多，包括其它團隊，業(yè)務分析師做數據分析用到線上環(huán)境，這個地方安全非常重要。

第三，一定的余量。

預估業(yè)務、提需求，上機器這么一套下來，就一兩個月，小公司不要扣這部分的成本，起碼預留20%的量。

To do

探索式數據集市、推薦系統(tǒng)、風控系統(tǒng)，這是我們今年最大的三塊目標。

來源：簡尋