天天在做大資料，你的時間都花在哪了

大資料做了這許多年，有沒有問過自己，大資料中，工作量最大和技術難度最高的，分别是什麼呢?

大資料

　　前言

我每天都在思考，思考很重要，是一個消化和不斷深入的過程。

正如下面的一句話:

我們從出生開始如果沒思考過人生本身這件事情，一切按照社會的習慣前行，那人生是沒有意義的。因為你連人生都沒有想過。

那麼延生出來，我們有沒有想過大資料本身?大資料到底是在做什麼，為什麼我做了這麼多年的大資料，總是做不完呢?

大資料本質是：

随着科學技術發展，更多的資料能夠被存儲了，能被分析了。是以有了大資料的概念。

機器學習的本質是：

随着資料變多了，量變導緻質變，資料足夠大後其内部的隐含的規律會越來越精确和完整。機器學習則是将資料記憶體存在的這種隐含關聯給挖掘出來的一項技術。

大資料最消耗工作量的地方是哪裡呢?

目前百分之八十的工作量都在于資料收集 清理和校驗。 這個工作本身并不難，但是真的很繁瑣，很費力。

我們天天感歎：

資料在哪裡?如何收集

資料要怎麼進行清洗

無效資料太多，如何去除

而讓我們心灰意冷的是

當一個新的需求來臨時，現有的資料形态似乎不能滿足需求，我們又要在現有的資料堆裡，重新走資料收集，清理，校驗的流程。

這似乎是一種詛咒，如同可憐的西西弗斯，被判要将大石推上陡峭的高山，每次用盡全力， 大石快要到頂時，石頭就會從其手中滑脫，又得重新推回去，幹著無止境的勞動。

大資料目前遇到的最大技術難點是什麼

是海量資料的ad-hoc查詢

當hadoop剛剛興起，我們可以通過它來操控越來越廉價的pc伺服器價格，于是一種暴力彌漫了整個生态：

我們因為突然有了強大的算力，這就好比一個窮人突然有了一筆很大的錢。我們開始讓強大的算力駕着最低效的程式去跑資料，這是批處理時代的悲哀

但是随着查詢效率要求越來越高，我們不得不被迫做出改變。還記得我們以前的日志都是簡單的raw文本嗎? 現在各種存儲的格式慢慢開花結果：

parquet, 數磚公司大力發展的一個存儲技術

orc, hive 常見的一種存儲格式

carbondata, 華為推出的一套可支援pb級别的資料格式

總之，我們似乎沒有找到一個奇妙的技術解決查詢的問題，隻能做某種折中：

為了加快查詢速度，資料存儲慢慢從早期的raw文本轉為具備向量化，帶索引，支援特定編碼和壓縮的列式存儲結構，當然這種通過調整存儲結構的方式必然以消耗資料進入時的時間和資源為代價。

也就是我們在存儲和查詢之間做了妥協。

如何讓苦力幹的更少

前面我們提及了，我們可能80%的工作都花在了資料的采集，清洗和校驗上了。但是我們該如何壓縮這部分的工作呢?

答案是：

流式計算

流式計算上層建築

讓所有的計算流動起來，就會讓下面的事情變得簡單：

我們可以在已經流動的資料中的任何一個環節引入一個新的支流。當我要擷取資料時，我做的本質其實就是 連接配接兩個或者多個節點，并且在其中對資料進行轉換。就如同河水，我們可以很友善的開一個支流，将水引入灌溉新的額農田。

而且我們希望流式計算的實作是結合了流式和批量語義的。為什麼呢?看看華為在storm上做的streamcql，就知道，很多情況實時流式是很有局限的，因為未來我們在流式上能做的事情會非常多：

資料處理

ad-hoc查詢

機器學習

報表

存儲輸出

這就需要一定的靈活性，因為隻有在資料集上，才會有譬如ad-hoc查詢，才能高效的進行存儲，才能适應一些機器學習算法。單條資料很多情況下，是沒有太大意義的。

這塊我一直是spark streaming的支援者。資料天生就是流式的

那為啥我們需要一個流式計算上層建築? 我們回顧下問題，資料的etl過程是個苦力活，消耗掉大量程式員的工作時間，那麼為了減少這種時間，我們有兩個辦法：

将做些任務分散出去，使得每個人都可做，那麼在總量不變的情況下，單個人就會變少了

提高每個人的工作效率

流式計算建構了整個基礎，而其上的架構則使得上面兩點成為可能。這裡我依然推薦我現在正在做的一個開源項目: streamingpro 。未來我們還會有一個更通用的基于流式計算的采集程式，敬請期待。

本文轉自d1net（轉載）