天天都在討論大數(shù)據(jù)，你的時(shí)間都花在哪了

大數(shù)據(jù) 機(jī)器學(xué)習(xí) 流計(jì)算

祝威廉 | 2016-07-01 10:54

【數(shù)據(jù)猿導(dǎo)讀】大數(shù)據(jù)本質(zhì)是，隨著科學(xué)技術(shù)發(fā)展，更多的數(shù)據(jù)能夠被存儲(chǔ)了，能被分析了。所以有了大數(shù)據(jù)的概念。我們有沒有想過(guò)大數(shù)據(jù)本身?大數(shù)據(jù)到底是在做什么，為什么我做了這么多年的大數(shù)據(jù)，總是做不完呢

大數(shù)據(jù)做了這許多年，有沒有問(wèn)過(guò)自己，大數(shù)據(jù)中，工作量最大和技術(shù)難度最高的，分別是什么呢?

我每天都在思考，思考很重要，是一個(gè)消化和不斷深入的過(guò)程。正如下面的一句話:

我們從出生開始如果沒思考過(guò)人生本身這件事情，一切按照社會(huì)的習(xí)慣前行，那人生是沒有意義的。因?yàn)槟氵B人生都沒有想過(guò)。

那么延生出來(lái)，我們有沒有想過(guò)大數(shù)據(jù)本身?大數(shù)據(jù)到底是在做什么，為什么我做了這么多年的大數(shù)據(jù)，總是做不完呢?大數(shù)據(jù)本質(zhì)是：

隨著科學(xué)技術(shù)發(fā)展，更多的數(shù)據(jù)能夠被存儲(chǔ)了，能被分析了。所以有了大數(shù)據(jù)的概念。

機(jī)器學(xué)習(xí)的本質(zhì)是：

隨著數(shù)據(jù)變多了，量變導(dǎo)致質(zhì)變，數(shù)據(jù)足夠大后其內(nèi)部的隱含的規(guī)律會(huì)越來(lái)越精確和完整。機(jī)器學(xué)習(xí)則是將數(shù)據(jù)內(nèi)存存在的這種隱含關(guān)聯(lián)給挖掘出來(lái)的一項(xiàng)技術(shù)。

大數(shù)據(jù)最消耗工作量的地方是哪里呢?

目前百分之八十的工作量都在于數(shù)據(jù)收集清理和校驗(yàn)。這個(gè)工作本身并不難，但是真的很繁瑣，很費(fèi)力。

我們天天感嘆：

數(shù)據(jù)在哪里?如何收集

數(shù)據(jù)要怎么進(jìn)行清洗

無(wú)效數(shù)據(jù)太多，如何去除

而讓我們心灰意冷的是當(dāng)一個(gè)新的需求來(lái)臨時(shí)，現(xiàn)有的數(shù)據(jù)形態(tài)似乎不能滿足需求，我們又要在現(xiàn)有的數(shù)據(jù)堆里，重新走數(shù)據(jù)收集，清理，校驗(yàn)的流程。

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

大數(shù)據(jù)目前遇到的最大技術(shù)難點(diǎn)是什么?

是海量數(shù)據(jù)的ad-hoc查詢。當(dāng)Hadoop剛剛興起，我們可以通過(guò)它來(lái)操控越來(lái)越廉價(jià)的PC服務(wù)器價(jià)格，于是一種暴力彌漫了整個(gè)生態(tài)：

我們因?yàn)橥蝗挥辛藦?qiáng)大的算力，這就好比一個(gè)窮人突然有了一筆很大的錢。我們開始讓強(qiáng)大的算力駕著最低效的程序去跑數(shù)據(jù)，這是批處理時(shí)代的悲哀。

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

Parquet, 數(shù)磚公司大力發(fā)展的一個(gè)存儲(chǔ)技術(shù)

ORC, Hive 常見的一種存儲(chǔ)格式

CarbonData, 華為推出的一套可支持PB級(jí)別的數(shù)據(jù)格式

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

為了加快查詢速度，數(shù)據(jù)存儲(chǔ)慢慢從早期的raw文本轉(zhuǎn)為具備向量化，帶索引，支持特定編碼和壓縮的列式存儲(chǔ)結(jié)構(gòu)，當(dāng)然這種通過(guò)調(diào)整存儲(chǔ)結(jié)構(gòu)的方式必然以消耗數(shù)據(jù)進(jìn)入時(shí)的時(shí)間和資源為代價(jià)。

也就是我們?cè)诖鎯?chǔ)和查詢之間做了妥協(xié)。

如何讓苦力干的更少

前面我們提及了，我們可能80%的工作都花在了數(shù)據(jù)的采集，清洗和校驗(yàn)上了。但是我們?cè)撊绾螇嚎s這部分的工作呢?

答案是：

流式計(jì)算

流式計(jì)算上層建筑

讓所有的計(jì)算流動(dòng)起來(lái)，就會(huì)讓下面的事情變得簡(jiǎn)單：

我們可以在已經(jīng)流動(dòng)的數(shù)據(jù)中的任何一個(gè)環(huán)節(jié)引入一個(gè)新的支流。當(dāng)我要獲取數(shù)據(jù)時(shí)，我做的本質(zhì)其實(shí)就是連接兩個(gè)或者多個(gè)節(jié)點(diǎn)，并且在其中對(duì)數(shù)據(jù)進(jìn)行轉(zhuǎn)換。就如同河水，我們可以很方便的開一個(gè)支流，將水引入灌溉新的額農(nóng)田。

而且我們希望流式計(jì)算的實(shí)現(xiàn)是結(jié)合了流式和批量語(yǔ)義的。為什么呢?

看看華為在Storm上做的StreamCQL，就知道，很多情況實(shí)時(shí)流式是很有局限的，因?yàn)槲磥?lái)我們?cè)诹魇缴夏茏龅氖虑闀?huì)非常多：

數(shù)據(jù)處理

Ad-Hoc查詢

機(jī)器學(xué)習(xí)

報(bào)表

存儲(chǔ)輸出

這就需要一定的靈活性，因?yàn)橹挥性跀?shù)據(jù)集上，才會(huì)有譬如Ad-Hoc查詢，才能高效的進(jìn)行存儲(chǔ)，才能適應(yīng)一些機(jī)器學(xué)習(xí)算法。單條數(shù)據(jù)很多情況下，是沒有太大意義的。

這塊我一直是Spark Streaming的支持者。

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

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

提高每個(gè)人的工作效率

流式計(jì)算構(gòu)建了整個(gè)基礎(chǔ)，而其上的框架則使得上面兩點(diǎn)成為可能。

來(lái)源：簡(jiǎn)書

收藏分享

聲明：數(shù)據(jù)猿尊重媒體行業(yè)規(guī)范，相關(guān)內(nèi)容都會(huì)注明來(lái)源與作者；轉(zhuǎn)載我們?cè)瓌?chuàng)內(nèi)容時(shí)，也請(qǐng)務(wù)必注明“來(lái)源：數(shù)據(jù)猿”與作者名稱，否則將會(huì)受到數(shù)據(jù)猿追責(zé)。