大數(shù)據(jù)分析要學什么

　　很多初入大數(shù)據(jù)領域或者轉(zhuǎn)行進入大數(shù)據(jù)領域的朋友，需要了解的第一件事不是說各種組件框架生態(tài)相關的東西，也不是各種編程語言基礎。
 

　　而是，了解清楚以下幾個問題：
 

　　1)大數(shù)據(jù)領域到底包含了哪些東西，解決了哪些問題?
 

　　2)自己的實際基礎是什么，如何結(jié)合自己的基礎以及興趣愛好，在整個大數(shù)據(jù)領域鏈路中，找到最好的切入點。只有解決了上面兩個問題，才能給自己最精確的定位，找準方向深入下去。
 

　　第一個問題，大數(shù)據(jù)領域的范圍。
 

　　現(xiàn)在一說起大數(shù)據(jù)分析，簡單起來就是一個詞，但其實這個方向已經(jīng)可以形成一個技術領域了，包含了方方面面的技術點，也提供了各種不同的技術崗位。所以，不同的崗位，對應的需求，工作內(nèi)容都是不同的。
 

　　我們可以根據(jù)數(shù)據(jù)從下到上，從無到有，到產(chǎn)生價值整個數(shù)據(jù)業(yè)務流程來拆解，并且與此同時，來看看每個環(huán)節(jié)我們需要的技術儲備以及能做的事有哪些。大數(shù)據(jù)分析的幾大基本業(yè)務流程：
 

　　收集 -> 傳輸 -> 轉(zhuǎn)換/清洗 ->存儲 -> 再加工 -> 挖掘/統(tǒng)計 -> 上層應用輸出

　　總的來說，可以分以下幾個大塊。
 

第一環(huán)：數(shù)據(jù)的收集
 

　　在收集階段，我們來看看數(shù)據(jù)主要有哪幾種存在方式：
 

　　1)第三方開放數(shù)據(jù)集
 

　　2)業(yè)務數(shù)據(jù)
 

　　3)服務日志
 

　　4)行為上報數(shù)據(jù)
 

　　首先針對于第三方開放數(shù)據(jù)，目前爬取第三方開放數(shù)據(jù)的形式已經(jīng)逐漸被認可，并且將會越來越多的人以及企業(yè)從互聯(lián)網(wǎng)開放數(shù)據(jù)集中獲取原始數(shù)據(jù)。所以，針對于開放數(shù)據(jù)的獲取，爬蟲已經(jīng)可以單獨形成一個體系了，包括不同的爬蟲框架，以及近年來對于分布式爬蟲的技術需求等，在語言方面主要還是python以及java為主，輔助其他相關腳本知識。
 

　　如果數(shù)據(jù)是業(yè)務數(shù)據(jù)，那么通常在傳統(tǒng)的路子中，業(yè)務數(shù)據(jù)一般存儲在傳統(tǒng)的數(shù)據(jù)庫中，那么，對于傳統(tǒng)數(shù)據(jù)庫相關的技術知識不可避免的需要有所了解。
 

　　我們需要對數(shù)據(jù)進行統(tǒng)一化處理，又不可避免的涉及到數(shù)據(jù)的遷移，即從傳統(tǒng)數(shù)據(jù)存儲介質(zhì)中遷移到諸如hadoop生態(tài)中，那么涉及的遷移框架諸如sqoop之類的，又是不能不懂一些。在語言以及基礎要求上，對SQL相關的知識需要補充，以及l(fā)inux操作，簡單的python需要掌握。
 

　　最后，如果是數(shù)據(jù)上報的形式，你需要對整個數(shù)據(jù)上報的流程熟悉，怎么進行埋點、怎么收集上報的數(shù)據(jù)，上報過來怎么進行傳輸接受落地，這里就不多說，最終這種上報過來的數(shù)據(jù)反倒相對規(guī)整。
 

第二環(huán)：數(shù)據(jù)的傳輸
 

　　數(shù)據(jù)的傳輸?shù)降自谑裁磿r候會涉及到呢?諸如上面說到的數(shù)據(jù)上報，在大數(shù)據(jù)模式下，通常上報過來的數(shù)據(jù)我們都不會馬上進行落地的，因為涉及到不同部分其效率不一樣，在峰值波動的情況下，直接落地十有八九都會導致系統(tǒng)宕機。

　　所以，數(shù)據(jù)的傳輸在大數(shù)據(jù)領域中有著不可替代的左右，會出現(xiàn)在各種系統(tǒng)耦合之間，一方面用作數(shù)據(jù)的傳輸，另一方面用作數(shù)據(jù)的緩沖、系統(tǒng)解耦。在hadoop生態(tài)中，最有名的莫過于kafka與flume的組合搭配了，收集數(shù)據(jù)，并進行數(shù)據(jù)傳輸，此外還有不少類似的消息隊列存在，諸如ActiveMQ、阿里的RocketMQ等等。
 

第三環(huán)：數(shù)據(jù)的存儲
 

　　生態(tài)中最最核心的存儲組件莫過于HDFS了，這是支撐hadoop能夠做大批量數(shù)據(jù)處理的基礎支撐，便捷而強悍的橫向擴展能力。還有各種基于此之上不同形式的數(shù)據(jù)存儲方式，諸如hive、HBase、甚至ES、Solr勉強都算，以及不可忽略的傳統(tǒng)類型的SQL存儲方式。

　　我們需要理解的是，不同的存儲方式應對于實際的應用場景是不同的，HDFS作為最基礎的分布式文件系統(tǒng)，我們就不多說。如Hive其更作用更多用于類傳統(tǒng)式的SQL查詢操作，其對于效應效率要求并不高，但對于數(shù)據(jù)規(guī)模的支撐性良好;而HBase則更偏向于即席查詢，要求有更高的響應效率，但對于查詢的復雜性支持上則相對較弱。
 

　　而我們說諸如ES、Solr都也勉強算是一種數(shù)據(jù)存儲的組織方式，其實也是有一定道理的，因為他們本身也支持這種分布式的數(shù)據(jù)存儲，只不過他們是為了應對于自己框架的檢索需求而設計的數(shù)據(jù)存儲組織。如Redis，也算是目前大數(shù)據(jù)生態(tài)中不可缺少的數(shù)據(jù)存儲方式之一，基于內(nèi)容，應對于高效的數(shù)據(jù)存儲與讀取，在很多的實際應用場景中都用的到。
 

第四環(huán)：數(shù)據(jù)的再加工
 

　　其實這一層主要要說就是基于Hadoop的MR框架以及Spark，當然，也有其他的一些分布式數(shù)據(jù)處理框架。
 

　　大規(guī)模的數(shù)據(jù)清洗轉(zhuǎn)換、再加工，都離不開分布式處理框架的支持。我們需要對雜亂的數(shù)據(jù)進行標準化、對殘缺的數(shù)據(jù)進行補全、對原始的數(shù)據(jù)進行深度加工提取高級屬性等等。簡單的，我們可以通過一些處理腳本來做，但針對于大規(guī)模的數(shù)據(jù)量級，我們依然需要依賴MR或者spark這種框架來處理。而針對于一些實時的場景，我們也不可避免的需要掌握諸如storm以及spark streaming之類的實時框架。所以，在這一環(huán)，我們不止需要了解不同的大數(shù)據(jù)處理框架，我們還需要在基于框架的基礎上，做數(shù)據(jù)應用開發(fā)，進行數(shù)據(jù)處理。
 

最后一環(huán)：數(shù)據(jù)應用價值輸出
 

　　前面我們做了很多事，包括數(shù)據(jù)的收集、傳輸、處理、存儲等等，但這些都是手段，都不是我們的目的。我們的目的是讓數(shù)據(jù)產(chǎn)生價值，這也是企業(yè)做大數(shù)據(jù)的核心目的。
 

　　我們可以用數(shù)據(jù)來做什么：
 

　　1)基于統(tǒng)計分析、數(shù)據(jù)預測，做數(shù)據(jù)化運營、決策，提升效率、效果，這是最常見的應用場景。
 

　　2)做推薦，在主體之外產(chǎn)生衍生價值，提升單位價值轉(zhuǎn)換。
 

　　3)畫像體系，至于說畫像能做什么，只要能做的準，能做的事可多了。
 

　　4)基于數(shù)據(jù)化、智能化的搜索。
 

　　5)實現(xiàn)業(yè)務的數(shù)據(jù)化、自動化、智能化。