data pipeline 中充斥着驚人的浪費，只是選擇視而不見

愈來愈多的公司言並稱大數據，而大數據管道和存儲集羣的規模甚至能夠是業務集羣的一百倍的規模。這裏有多少機器是真正在作有價值的事情，而有多少cpu cycle是白白被浪費掉了呢？data pipeline 中充斥着驚人的浪費！只是咱們選擇視而不見。廉不知恥地把集羣規模到了xxx臺作爲本身的功勞。卻不知機器只是成本，集羣規模只說明咱們在大量浪費，不說明任何其餘問題。如下是個人吐槽正文：

重複建設

大數據很火，寫簡歷上很是好就業。因而各個部門都進行着重複性地建設，從數據上報開始就報多份，各自有各自的採集agent。看一個機器上agent的進程名基本上能夠推倒出一個公司的組織架構。你要是用storm，我就用samza。大家都走日誌kafka，我就用udp和statsd。大家用elasticsearch，我就用influxdb，後來的要擠進來爲了有區分度就用了druid。各類相似的技術棧被掛在數據管道的後面作着重複性的相似的工做。

RD太忙了，咱們來兼容吧

建設data pipeline的同窗和作業務的RD是兩幫人。因此就出現了日誌是「非結構化數據」的需求。日誌歷來都不是非結構化的好很差。由於搞數據人懶得和RD溝通，或者不肯意推進RD去修改業務代碼，因此就得作各類定製。什麼正則解析啦，什麼去掉時間戳的頭啦，什麼multiline鏈接啦。就是json我都以爲是浪費磁盤和cpu的序列化格式。

另外日誌的路徑和rotate的方式老是多種多樣的吧。這也是由於組織架構決定軟件架構的事情。誰規定了就必定是作data pipeline的人要去監控業務的日誌路徑和rotate方式。爲何不是data pipeline規定了一個目錄結構讓業務必定要打到這個目錄裏，而rotate爲何不能是agent發起的，日誌寫入方去follow？

把這二者的關係反轉過來，能夠節省大量在格式解析，序列化反序列化，日誌分揀上帶來的無謂的開銷。制定規範和標準讓rd去調整業務代碼，而不是跟着業務後面去改採集和解析。

各自爲戰的數據集羣

kafka是集羣吧，logstash是集羣吧，elasticsearch是集羣吧。每一個集羣都有本身的分佈式節點的管理系統（zk的，etcd的，本身擼的），都有本身的數據分區策略。數據在不一樣的集羣中倒騰來倒騰去，就在不斷地作rehash，從新分組到不一樣的partition上。帶來的是巨大的內網帶寬的消耗。

把數據從一個集羣拷貝到另一個集羣就那麼好玩麼？吹噓本身每秒處理多少數據就那麼爽？其實deep down，你知道你作的工做不過就是倒個手而已，不是麼。

暴力檢索

Map-reduce暴力全表掃描早就是過氣的技術了。暴力使用hadoop，或者使用hive隱形暴力地mr，堆大量機器地撈數據。業務一些機器學習的算法真地須要這麼幹，可是大部分BI SQL，絕對是能夠充分利用列式存儲和各類索引結構的。不管是elasticsearch仍是spark sql都有大量成熟的解決方案了。用索引和不用索引，那效率但是百倍的差距。

是的，所有吐槽無數據無干貨，純感性吐槽。

RoR的啓發

縱觀如今Data pipeline & 監控 & 日誌檢索 & BI多維查詢的技術棧，很是相似當年的spring，各類可插拔，各類可配置。而咱們須要的就是ruby on rails，橫空出世，高舉出convention over configuration的旗號，把一個集成好伸手就用不需思考的解決方案全盤端出。打通各自爲戰的管道和存儲集羣，整合最牛的索引和存儲格式，把data pipeline的拼裝從專業技術變成commodities。亟需這樣一個從業務內打日誌開始，到出時間序列圖的端到端的完整解決方案，把廣大從業人員從低水平的重複建設裏解脫出來。

你不就是想省幾臺機器嘛

不在意這幾臺機器的公司多得是。省計算資源真沒啥好吹噓的。更爲寶貴的資源是RD和PM的時間。當產品研發的同窗想要對一個事情進行監控，BI的時候，他能不能徹底自主地把全流程跑完？如今不少時候咱們須要考慮新增的數據須要佔用很多的新機器，須要去申請。新打的日誌要通知另一個部門去採集，而後再通知另一個部門去計算，而後去通知另一個部門去作圖表。這樣的效率能高嗎？搞數據的部門別高冷地一副帶你的數據來，帶你的需求來，哦對了，帶你的機器來，我幫你搞搞的態度。而是真地實現平臺化，自助化。別各個部門都跟着業務後面作需求，我這加點東西，你那就得加點東西。節省全部人的時間。時間纔是最寶貴的東西。