大數據做了這許多年，有沒有問過自己，大數據中，工作量最大和技術難度最高的，分別是什么呢?

　　前言

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

正如下面的一句話:

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

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

大數據本質是：

隨著科學技術發展，更多的數據能夠被存儲了，能被分析了。所以有了大數據的概念。

機器學習的本質是：

隨著數據變多了，量變導致質變，數據足夠大后其內部的隱含的規律會越來越精確和完整。機器學習則是將數據內存存在的這種隱含關聯給挖掘出來的一項技術。

大數據最消耗工作量的地方是哪里呢?

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

我們天天感嘆：

數據在哪里?如何收集

數據要怎么進行清洗

無效數據太多，如何去除

而讓我們心灰意冷的是

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

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

大數據目前遇到的最大技術難點是什么

是海量數據的ad-hoc查詢

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

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

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

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

ORC, Hive 常見的一種存儲格式

CarbonData, 華為推出的一套可支持PB級別的數據格式

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

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

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

如何讓苦力干的更少

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

答案是：

流式計算

流式計算上層建筑

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

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

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

數據處理

Ad-Hoc查詢

機器學習

報表

存儲輸出

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

這塊我一直是Spark Streaming的支持者。數據天生就是流式的

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

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

提高每個人的工作效率

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