摘要：殊不知機(jī)器只是成本，集群規(guī)模只說(shuō)明我們?cè)诖罅坷速M(fèi)，不說(shuō)明任何其他問(wèn)題。這也是因?yàn)榻M織架構(gòu)決定軟件架構(gòu)的事情。節(jié)省所有人的時(shí)間。

越來(lái)越多的公司言并稱大數(shù)據(jù)，而大數(shù)據(jù)管道和存儲(chǔ)集群的規(guī)模甚至可以是業(yè)務(wù)集群的一百倍的規(guī)模。這里有多少機(jī)器是真正在做有價(jià)值的事情，而有多少cpu cycle是白白被浪費(fèi)掉了呢？data pipeline 中充斥著驚人的浪費(fèi)！只是我們選擇視而不見(jiàn)。廉不知恥地把集群規(guī)模到了xxx臺(tái)做為自己的功勞。殊不知機(jī)器只是成本，集群規(guī)模只說(shuō)明我們?cè)诖罅坷速M(fèi)，不說(shuō)明任何其他問(wèn)題。以下是我的吐槽正文：

大數(shù)據(jù)很火，寫簡(jiǎn)歷上非常好就業(yè)。于是各個(gè)部門都進(jìn)行著重復(fù)性地建設(shè)，從數(shù)據(jù)上報(bào)開始就報(bào)多份，各自有各自的采集agent。看一個(gè)機(jī)器上agent的進(jìn)程名基本上可以推倒出一個(gè)公司的組織架構(gòu)。你要是用storm，我就用samza。你們都走日志kafka，我就用udp和statsd。你們用elasticsearch，我就用influxdb，后來(lái)的要擠進(jìn)來(lái)為了有區(qū)分度就用了druid。各種類似的技術(shù)棧被掛在數(shù)據(jù)管道的后面做著重復(fù)性的類似的工作。

建設(shè)data pipeline的同學(xué)和做業(yè)務(wù)的RD是兩幫人。所以就出現(xiàn)了日志是“非結(jié)構(gòu)化數(shù)據(jù)”的需求。日志從來(lái)都不是非結(jié)構(gòu)化的好不好。因?yàn)楦銛?shù)據(jù)人懶得和RD溝通，或者不愿意推動(dòng)RD去修改業(yè)務(wù)代碼，所以就得做各種定制。什么正則解析啦，什么去掉時(shí)間戳的頭啦，什么multiline連接啦。就是json我都覺(jué)得是浪費(fèi)磁盤和cpu的序列化格式。

另外日志的路徑和rotate的方式總是多種多樣的吧。這也是因?yàn)榻M織架構(gòu)決定軟件架構(gòu)的事情。誰(shuí)規(guī)定了就一定是做data pipeline的人要去監(jiān)控業(yè)務(wù)的日志路徑和rotate方式。為什么不是data pipeline規(guī)定了一個(gè)目錄結(jié)構(gòu)讓業(yè)務(wù)一定要打到這個(gè)目錄里，而rotate為什么不能是agent發(fā)起的，日志寫入方去follow？

把這兩者的關(guān)系反轉(zhuǎn)過(guò)來(lái)，可以節(jié)省大量在格式解析，序列化反序列化，日志分揀上帶來(lái)的無(wú)謂的開銷。制定規(guī)范和標(biāo)準(zhǔn)讓rd去調(diào)整業(yè)務(wù)代碼，而不是跟著業(yè)務(wù)后面去改采集和解析。

kafka是集群吧，logstash是集群吧，elasticsearch是集群吧。每個(gè)集群都有自己的分布式節(jié)點(diǎn)的管理系統(tǒng)（zk的，etcd的，自己擼的），都有自己的數(shù)據(jù)分區(qū)策略。數(shù)據(jù)在不同的集群中倒騰來(lái)倒騰去，就在不斷地做rehash，重新分組到不同的partition上。帶來(lái)的是巨大的內(nèi)網(wǎng)帶寬的消耗。

把數(shù)據(jù)從一個(gè)集群拷貝到另外一個(gè)集群就那么好玩么？吹噓自己每秒處理多少數(shù)據(jù)就那么爽？其實(shí)deep down，你知道你做的工作不過(guò)就是倒個(gè)手而已，不是么。

Map-reduce暴力全表掃描早就是過(guò)氣的技術(shù)了。暴力使用hadoop，或者使用hive隱形暴力地mr，堆大量機(jī)器地?fù)茢?shù)據(jù)。業(yè)務(wù)一些機(jī)器學(xué)習(xí)的算法真地需要這么干，但是大部分BI SQL，絕對(duì)是可以充分利用列式存儲(chǔ)和各種索引結(jié)構(gòu)的。無(wú)論是elasticsearch還是spark sql都有大量成熟的解決方案了。用索引和不用索引，那效率可是百倍的差距。

是的，全部吐槽無(wú)數(shù)據(jù)無(wú)干貨，純感性吐槽。

縱觀現(xiàn)在Data pipeline & 監(jiān)控 & 日志檢索 & BI多維查詢的技術(shù)棧，非常類似當(dāng)年的spring，各種可插拔，各種可配置。而我們需要的就是ruby on rails，橫空出世，高舉出convention over configuration的旗號(hào)，把一個(gè)集成好伸手就用不需思考的解決方案全盤端出。打通各自為戰(zhàn)的管道和存儲(chǔ)集群，整合最牛的索引和存儲(chǔ)格式，把data pipeline的拼裝從專業(yè)技術(shù)變成commodities。亟需這樣一個(gè)從業(yè)務(wù)內(nèi)打日志開始，到出時(shí)間序列圖的端到端的完整解決方案，把廣大從業(yè)人員從低水平的重復(fù)建設(shè)里解脫出來(lái)。

不在乎這幾臺(tái)機(jī)器的公司多得是。省計(jì)算資源真沒(méi)啥好吹噓的。更為寶貴的資源是RD和PM的時(shí)間。當(dāng)產(chǎn)品研發(fā)的同學(xué)想要對(duì)一個(gè)事情進(jìn)行監(jiān)控，BI的時(shí)候，他能不能完全自主地把全流程跑完？現(xiàn)在很多時(shí)候我們需要考慮新增的數(shù)據(jù)需要占用不少的新機(jī)器，需要去申請(qǐng)。新打的日志要通知另外一個(gè)部門去采集，然后再通知另外一個(gè)部門去計(jì)算，然后去通知另外一個(gè)部門去做圖表。這樣的效率能高嗎？搞數(shù)據(jù)的部門別高冷地一副帶你的數(shù)據(jù)來(lái)，帶你的需求來(lái)，哦對(duì)了，帶你的機(jī)器來(lái)，我?guī)湍愀愀愕膽B(tài)度。而是真地實(shí)現(xiàn)平臺(tái)化，自助化。別各個(gè)部門都跟著業(yè)務(wù)后面做需求，我這加點(diǎn)東西，你那就得加點(diǎn)東西。節(jié)省所有人的時(shí)間。時(shí)間才是最寶貴的東西。