斗魚實(shí)時(shí)計(jì)算平臺(tái)的演進(jìn)

我是吳瑞誠(chéng)，來自斗魚，很高興能有機(jī)會(huì)和大家分享斗魚TV實(shí)時(shí)計(jì)算平臺(tái)的演進(jìn)。

做一個(gè)簡(jiǎn)單的自我介紹。我之前在淘寶干過三年，主要做HBase，目前在斗魚TV做大數(shù)據(jù)開發(fā)。

斗魚典型直播間介紹

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

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

主要分享內(nèi)容

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

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

第三，實(shí)時(shí)流計(jì)算，流計(jì)算。strong text

一、日志檢索

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

我加入斗魚，當(dāng)時(shí)是一個(gè)人負(fù)責(zé)整個(gè)這一大塊的東西，后來就是因?yàn)榫W(wǎng)站量上來了，個(gè)人吞吐量到了上限，招了第一批人。我第一批是組內(nèi)培養(yǎng)的，會(huì)有一些java開發(fā)，生拉硬拽湊到大數(shù)據(jù)團(tuán)隊(duì)，從最開始的小系統(tǒng)越做越大，做到現(xiàn)在這個(gè)架構(gòu)。

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

上面一層就是數(shù)據(jù)清洗和格式轉(zhuǎn)換包括初步的結(jié)算。

再上面一層就包括依賴MySQL實(shí)現(xiàn)的歸檔數(shù)據(jù)，最大一塊是離線計(jì)算基于Hadoop，YARN。去年上線Spark，現(xiàn)在應(yīng)用的范圍還比較小，主要還是在風(fēng)控和個(gè)性推薦這一塊。

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

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

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

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

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

這是Lambda架構(gòu)，這三層架構(gòu)，P處理層，再是上面的加速層到服務(wù)層，這三層架構(gòu)，應(yīng)該可以覆蓋絕大多數(shù)的大數(shù)據(jù)團(tuán)隊(duì)架構(gòu)的場(chǎng)景。

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

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

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

最開始的方案，因?yàn)槲覀冇蠧++的團(tuán)隊(duì)做服務(wù)化，他們覺得我們可以自己造輪子，這個(gè)輪子比較簡(jiǎn)單，后來我做了一圈對(duì)比，發(fā)現(xiàn)Logstash新版本中，有一個(gè)Beats組件，是golang實(shí)現(xiàn)的。

架構(gòu)圖中間以Elastic技術(shù)棧為主，包括中間匯聚層在不久將來會(huì)被替換掉，但是現(xiàn)有的一些場(chǎng)景，如果一直穩(wěn)定的話先保持現(xiàn)狀。因?yàn)槲覀冊(cè)谶@個(gè)階段它比較穩(wěn)定。

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

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

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

再說一下踩過的一些坑。

首先Flume的選型。我最開始看中還是因?yàn)樗茿pache的產(chǎn)品，覺得它穩(wěn)定，在很多公司PPT里面，我稍微估計(jì)一下，flume出現(xiàn)的概率比其它產(chǎn)品出現(xiàn)頻率高很多，所以做一些壓測(cè)做了對(duì)比，差不太多，就選了flume，現(xiàn)在要新用或者要換型需要更詳細(xì)的壓測(cè)。

channel這一塊，最開始內(nèi)存到disk到現(xiàn)在兩個(gè)方案混搭在一起，但是占資源特別耗資源。

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

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

因?yàn)镋lastic除了我們最開始最傳統(tǒng)的搜索引擎、文本搜索，現(xiàn)在更大的一塊可以當(dāng)作我們的多維自助查詢，水平擴(kuò)展能力非常強(qiáng)，因?yàn)閿?shù)據(jù)結(jié)構(gòu)的天熱優(yōu)勢(shì)，就有一些場(chǎng)景，包括多維的及時(shí)查詢這一塊有非常強(qiáng)悍的性能。

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

ES讀寫分離。ES集群拓?fù)湓絹碓酱?，如果按照默認(rèn)的拓?fù)鋪硎褂玫脑?，可能量上沒法滿足很多場(chǎng)景，比如，如果讀寫不做分離，查詢極有可能把線上寫的節(jié)點(diǎn)直接壓垮，這樣就建議有一個(gè)專門的節(jié)點(diǎn)來負(fù)責(zé)讀。

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

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

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

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

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

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

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

Hbase使用有兩大點(diǎn)需要注意：

第一，rowkey的設(shè)計(jì)，Hbase中除了rowkey沒有索引可供使用。

第二，數(shù)據(jù)壓縮，歷史數(shù)據(jù)的壓縮很關(guān)鍵。一個(gè)指標(biāo)兩個(gè)指標(biāo)做抽樣做一些歸檔很好做，但是怎么做到統(tǒng)一，而且還很簡(jiǎn)單，我們能直接拿來用，這個(gè)時(shí)候碰到open? TSDB，一個(gè)時(shí)間序列存儲(chǔ)方案。

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

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

對(duì)數(shù)據(jù)壓縮，每一個(gè)指標(biāo)每一個(gè)小時(shí)會(huì)有一個(gè)row，open TSDB幫我們做了。后面有定制需求我們從頭開始做，這一塊是比較簡(jiǎn)單的，底層Hbase性能是沒有問題，越往后看，Hbase有很多地方它會(huì)做得越來越通用。因?yàn)樗男阅苓@一塊顯性能沒有問題，后面卡頓的問題會(huì)有明顯的提升。

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

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

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

Open TSDB，業(yè)務(wù)指標(biāo)非常靈活，我們現(xiàn)在有一些CPU指標(biāo)，打出來我們收集起來，各個(gè)指標(biāo)匯集在一起，而且是秒級(jí)的力度，這個(gè)力度因?yàn)橹笜?biāo)量大，時(shí)間粒度比較細(xì)，我們服務(wù)機(jī)器的服務(wù)數(shù)越來越大，現(xiàn)在還碰不到瓶頸。

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

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

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

關(guān)注寫熱點(diǎn)，一般，按照默認(rèn)的Region Split方案，上線后如果寫壓力比較大，都會(huì)有寫熱點(diǎn)的問題，這時(shí)需要考慮預(yù)建region。再就是寫壓內(nèi)考慮writebuffer、WAL、autoflush，我寫的要求很高，數(shù)據(jù)一致性要求很高那這事就不好辦，只有做權(quán)衡，寫性能上和數(shù)據(jù)一致上做權(quán)衡，下面三個(gè)參數(shù)只要你調(diào)了或者關(guān)了，可用性就會(huì)丟，有這個(gè)風(fēng)險(xiǎn)擇，這是預(yù)先告訴大家。

對(duì)日志類的表化考慮關(guān)閉compact，手動(dòng)觸發(fā)GC。

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

這是跟open TSDB密切相關(guān)的兩個(gè)點(diǎn)。

三、實(shí)時(shí)流計(jì)算

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

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

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

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

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

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

Spark吞吐量是非常好的，因?yàn)閮蓚€(gè)數(shù)據(jù)模型就決定了他們兩個(gè)側(cè)重業(yè)務(wù)場(chǎng)景是不一樣的，后面離線計(jì)算，這個(gè)中間有一個(gè)是數(shù)據(jù)應(yīng)用層，我們可以從實(shí)時(shí)計(jì)算到數(shù)據(jù)應(yīng)用層，會(huì)寫到中間離線層，又有另外一批數(shù)據(jù)到前面的應(yīng)用層，實(shí)時(shí)數(shù)據(jù)監(jiān)控和其它應(yīng)用。

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

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

Storm的新版本中，已經(jīng)剝離了對(duì)ZK的依賴。我們所有的調(diào)優(yōu)調(diào)這幾個(gè)對(duì)象的參數(shù)，比方提高并行度，我們要提高時(shí)間時(shí)效，就是基于這個(gè)圖。

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

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

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

我們最后往redis寫，性能強(qiáng)悍，你一個(gè)storm沒問題，當(dāng)時(shí)用一個(gè)redis做一些hush，做分散，還是解決不了，后來把redis替換掉。

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

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

這是流的簡(jiǎn)單使用有一些心得，踩過一些坑。批處理時(shí)間。換粗需要經(jīng)常的使用的數(shù)據(jù)。集群task并行度，使用Kryo序列化。

這是我們踩過的巨坑，最后和大家強(qiáng)調(diào)一下。

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

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

今年做了比較大的一塊，就是在做統(tǒng)一監(jiān)控平臺(tái)，現(xiàn)在我們也是在花主要的開發(fā)資源做這一塊，因?yàn)槲覀兦岸擞芯W(wǎng)站端后端有C++服務(wù)端，語(yǔ)言異構(gòu)排查起來就存在，沒法定位，第一反應(yīng)大家很本能甩鍋，就需要統(tǒng)一監(jiān)控平臺(tái)。

第二，安全。

最開始太粗放，我們最開始做網(wǎng)絡(luò)隔離，我們的集群是第一次做了網(wǎng)絡(luò)上的隔離，然后后來就包括人員越來越大，因?yàn)椴豢赡苁俏乙粋€(gè)人干，也不可能做這么多業(yè)務(wù)場(chǎng)景，用的人越來越多，包括其它團(tuán)隊(duì)，業(yè)務(wù)分析師做數(shù)據(jù)分析用到線上環(huán)境，這個(gè)地方安全非常重要。

第三，一定的余量。

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

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