大數(shù)據(jù)做了這許多年览爵，有沒有問過自己置鼻，大數(shù)據(jù)中，工作量最大和技術(shù)難度最高的蜓竹，分別是什么呢箕母？
前言
我每天都在思考，思考很重要俱济，是一個消化和不斷深入的過程嘶是。
正如下面的一句話:
我們從出生開始如果沒思考過人生本身這件事情，一切按照社會的習慣前行蛛碌，那人生是沒有意義的聂喇。因為你連人生都沒有想過。
那么延生出來蔚携，我們有沒有想過大數(shù)據(jù)本身希太？
大數(shù)據(jù)到底是在做什么，為什么我做了這么多年的大數(shù)據(jù)酝蜒，總是做不完呢誊辉？
大數(shù)據(jù)本質(zhì)是：
隨著科學技術(shù)發(fā)展，更多的數(shù)據(jù)能夠被存儲了亡脑，能被分析了堕澄。所以有了大數(shù)據(jù)的概念。
機器學習的本質(zhì)是：
隨著數(shù)據(jù)變多了霉咨，量變導致質(zhì)變蛙紫，數(shù)據(jù)足夠大后其內(nèi)部的隱含的規(guī)律會越來越精確和完整。機器學習則是將數(shù)據(jù)內(nèi)存存在的這種隱含關(guān)聯(lián)給挖掘出來的一項技術(shù)躯护。
大數(shù)據(jù)最消耗工作量的地方是哪里呢惊来？
目前百分之八十的工作量都在于數(shù)據(jù)收集 清理和校驗。 這個工作本身并不難棺滞，但是真的很繁瑣裁蚁，很費力。
我們天天感嘆：
- 數(shù)據(jù)在哪里继准？如何收集
- 數(shù)據(jù)要怎么進行清洗
- 無效數(shù)據(jù)太多枉证，如何去除
而讓我們心灰意冷的是
當一個新的需求來臨時，現(xiàn)有的數(shù)據(jù)形態(tài)似乎不能滿足需求移必，我們又要在現(xiàn)有的數(shù)據(jù)堆里室谚，重新走數(shù)據(jù)收集，清理，校驗的流程秒赤。
這似乎是一種詛咒猪瞬，如同可憐的西西弗斯，被判要將大石推上陡峭的高山入篮，每次用盡全力陈瘦， 大石快要到頂時，石頭就會從其手中滑脫潮售，又得重新推回去痊项，幹著無止境的勞動。
大數(shù)據(jù)目前遇到的最大技術(shù)難點是什么
是海量數(shù)據(jù)的ad-hoc查詢
當Hadoop剛剛興起酥诽，我們可以通過它來操控越來越廉價的PC服務器價格鞍泉，于是一種暴力彌漫了整個生態(tài)：
我們因為突然有了強大的算力，這就好比一個窮人突然有了一筆很大的錢肮帐。我們開始讓強大的算力駕著最低效的程序去跑數(shù)據(jù)咖驮，這是批處理時代的悲哀
但是隨著查詢效率要求越來越高，我們不得不被迫做出改變泪姨。還記得我們以前的日志都是簡單的Raw文本嗎游沿？ 現(xiàn)在各種存儲的格式慢慢開花結(jié)果：
- Parquet, 數(shù)磚公司大力發(fā)展的一個存儲技術(shù)
- ORC, Hive 常見的一種存儲格式
- CarbonData, 華為推出的一套可支持PB級別的數(shù)據(jù)格式
總之，我們似乎沒有找到一個奇妙的技術(shù)解決查詢的問題肮砾，只能做某種折中：
為了加快查詢速度诀黍，數(shù)據(jù)存儲慢慢從早期的raw文本轉(zhuǎn)為具備向量化，帶索引仗处，支持特定編碼和壓縮的列式存儲結(jié)構(gòu)眯勾，當然這種通過調(diào)整存儲結(jié)構(gòu)的方式必然以消耗數(shù)據(jù)進入時的時間和資源為代價。
也就是我們在存儲和查詢之間做了妥協(xié)婆誓。
如何讓苦力干的更少
前面我們提及了吃环，我們可能80%的工作都花在了數(shù)據(jù)的采集，清洗和校驗上了洋幻。但是我們該如何壓縮這部分的工作呢郁轻？
答案是：
- 流式計算
- 流式計算上層建筑
讓所有的計算流動起來，就會讓下面的事情變得簡單：
我們可以在已經(jīng)流動的數(shù)據(jù)中的任何一個環(huán)節(jié)引入一個新的支流文留。當我要獲取數(shù)據(jù)時好唯，我做的本質(zhì)其實就是 連接兩個或者多個節(jié)點，并且在其中對數(shù)據(jù)進行轉(zhuǎn)換燥翅。就如同河水骑篙，我們可以很方便的開一個支流，將水引入灌溉新的額農(nóng)田森书。
而且我們希望流式計算的實現(xiàn)是結(jié)合了流式和批量語義的靶端。為什么呢谎势？
看看華為在Storm上做的StreamCQL，就知道杨名，很多情況實時流式是很有局限的脏榆，因為未來我們在流式上能做的事情會非常多：
- 數(shù)據(jù)處理
- Ad-Hoc查詢
- 機器學習
- 報表
- 存儲輸出
這就需要一定的靈活性，因為只有在數(shù)據(jù)集上台谍，才會有譬如Ad-Hoc查詢姐霍，才能高效的進行存儲，才能適應一些機器學習算法典唇。單條數(shù)據(jù)很多情況下，是沒有太大意義的胯府。
這塊我一直是Spark Streaming的支持者介衔。數(shù)據(jù)天生就是流式的
那為啥我們需要一個流式計算上層建筑？ 我們回顧下問題骂因，數(shù)據(jù)的ETL過程是個苦力活炎咖，消耗掉大量程序員的工作時間，那么為了減少這種時間寒波，我們有兩個辦法：
- 將做些任務分散出去乘盼，使得每個人都可做，那么在總量不變的情況下俄烁，單個人就會變少了
- 提高每個人的工作效率
流式計算構(gòu)建了整個基礎绸栅，而其上的框架則使得上面兩點成為可能。這里我依然推薦我現(xiàn)在正在做的一個開源項目: StreamingPro 页屠。未來我們還會有一個更通用的基于流式計算的采集程序粹胯，敬請期待。
