大數(shù)據(jù)平臺(tái)搭建(大數(shù)據(jù)入門需學(xué)習(xí)哪些)

1.大數(shù)據(jù)入門需學(xué)習(xí)哪些基礎(chǔ)知識(shí)

前言，學(xué)大數(shù)據(jù)要先換電腦：

保證電腦4核8G內(nèi)存64位操作系統(tǒng)，盡量有ssd做系統(tǒng)盤，否則卡到你喪失信心。硬盤越大越好。

1，語言要求

java剛?cè)腴T的時(shí)候要求javase。

scala是學(xué)習(xí)spark要用的基本使用即可。

后期深入要求：

java NIO,netty，多線程，ClassLoader,jvm底層及調(diào)優(yōu)等，rpc。

2，操作系統(tǒng)要求

linux 基本的shell腳本的使用。

crontab的使用，最多。

cpu，內(nèi)存，網(wǎng)絡(luò)，磁盤等瓶頸分析及狀態(tài)查看的工具。

scp,ssh,hosts的配置使用。

telnet,ping等網(wǎng)絡(luò)排查命令的使用

3,sql基本使用

sql是基礎(chǔ)，hive,sparksql等都需要用到，況且大部分企業(yè)也還是以數(shù)據(jù)倉庫為中心，少不了sql。

sql統(tǒng)計(jì)，排序，join,group等，然后就是sql語句調(diào)優(yōu)，表設(shè)計(jì)等。

4，大數(shù)據(jù)基本了解

Zookeeper,hadoop,hbase,hive,sqoop,flume,kafka,spark,storm等這些框架的作用及基本環(huán)境的搭建，要熟練，要會(huì)運(yùn)維，瓶頸分析。

5,mapreduce及相關(guān)框架hive,sqoop

深入了解mapreduce的核心思想。尤其是shuffle,join，文件輸入格式，map數(shù)目，reduce數(shù)目，調(diào)優(yōu)等。

6,hive和hbase等倉庫

hive和hbase基本是大數(shù)據(jù)倉庫的標(biāo)配。要回用，懂調(diào)優(yōu)，故障排查。

hbase看浪尖hbase系列文章。hive后期更新。

7，消息隊(duì)列的使用

kafka基本概念，使用，瓶頸分析?？蠢思鈑afka系列文章。

8，實(shí)時(shí)處理系統(tǒng)

storm和spark Streaming

9,spark core和sparksql

spark用于離線分析的兩個(gè)重要功能。

10，最終方向決策

a），運(yùn)維。（精通整套系統(tǒng)及故障排查，會(huì)寫運(yùn)維腳本啥的。）

b），數(shù)據(jù)分析。（算法精通）

c），平臺(tái)開發(fā)。（源碼精通）

自學(xué)還是培訓(xùn)？

無基礎(chǔ)的同學(xué)，培訓(xùn)之前先搞到視頻通學(xué)一遍，防止盲目培訓(xùn)跟不上講師節(jié)奏，浪費(fèi)時(shí)間，精力，金錢。

有基礎(chǔ)的盡量搞點(diǎn)視頻學(xué)基礎(chǔ)，然后跟群里大牛交流，前提是人家愿意，

想辦法跟大牛做朋友才是王道。

2.大數(shù)據(jù)平臺(tái)在搭建時(shí)有哪些要注意的部分

大數(shù)據(jù)平臺(tái)搭建的主要問題

1、穩(wěn)定性 Stability

理論上來說，穩(wěn)定性是分布式系統(tǒng)最大的優(yōu)勢，因?yàn)樗梢酝ㄟ^多臺(tái)機(jī)器做數(shù)據(jù)及程序運(yùn)行備份以確保系統(tǒng)穩(wěn)定。但也由于大數(shù)據(jù)平臺(tái)部署于多臺(tái)機(jī)器上，配置不合適，也可能成為最大的問題。

2、可擴(kuò)展性 Scalability

如何快速擴(kuò)展已有大數(shù)據(jù)平臺(tái)，在其基礎(chǔ)上擴(kuò)充新的機(jī)器是云計(jì)算等領(lǐng)域應(yīng)用的關(guān)鍵問題。在實(shí)際2B的應(yīng)用中，有時(shí)需要增減機(jī)器來滿足新的需求。如何在保留原有功能的情況下，快速擴(kuò)充平臺(tái)是實(shí)際應(yīng)用中的常見問題。

3.怎么搭建大數(shù)據(jù)分析平臺(tái)

未至科技魔方是一款大數(shù)據(jù)模型平臺(tái)，是一款基于服務(wù)總線與分布式云計(jì)算兩大技術(shù)架構(gòu)的一款數(shù)據(jù)分析、挖掘的工具平臺(tái)，其采用分布式文件系統(tǒng)對(duì)數(shù)據(jù)進(jìn)行存儲(chǔ)，支持海量數(shù)據(jù)的處理。

采用多種的數(shù)據(jù)采集技術(shù)，支持結(jié)構(gòu)化數(shù)據(jù)及非結(jié)構(gòu)化數(shù)據(jù)的采集。通過圖形化的模型搭建工具，支持流程化的模型配置。

通過第三方插件技術(shù)，很容易將其他工具及服務(wù)集成到平臺(tái)中去。數(shù)據(jù)分析研判平臺(tái)就是海量信息的采集，數(shù)據(jù)模型的搭建，數(shù)據(jù)的挖掘、分析最后形成知識(shí)服務(wù)于實(shí)戰(zhàn)、服務(wù)于決策的過程，平臺(tái)主要包括數(shù)據(jù)采集部分，模型配置部分，模型執(zhí)行部分及成果展示部分等。

4.怎么搭建大數(shù)據(jù)分析平臺(tái)

1，大數(shù)據(jù)分析平臺(tái)的特點(diǎn)數(shù)據(jù)攝取、數(shù)據(jù)管理、ETL和數(shù)據(jù)倉庫：提供有效的數(shù)據(jù)入庫與管理數(shù)據(jù)用于管理作為一種寶貴的資源。

Hadoop系統(tǒng)功能：提供海量存儲(chǔ)的任何類型的數(shù)據(jù)，大量處理功率和處理能力幾乎是無限并行工作或任務(wù)流計(jì)算在拉動(dòng)特征：用于流的數(shù)據(jù)、處理數(shù)據(jù)并將這些流作為單個(gè)流。內(nèi)容管理特征：綜合生命周期管理和文檔內(nèi)容。

數(shù)據(jù)治理綜合：安全、治理和合規(guī)解決方案來保護(hù)數(shù)據(jù)2，怎樣去搭建大數(shù)據(jù)分析平臺(tái)大數(shù)據(jù)分析處理平臺(tái)就是整合當(dāng)前主流的各種具有不同側(cè)重點(diǎn)的大數(shù)據(jù)處理分析框架和工具，實(shí)現(xiàn)對(duì)數(shù)據(jù)的挖掘和分析，一個(gè)大數(shù)據(jù)分析平臺(tái)涉及到的組件眾多，如何將其有機(jī)地結(jié)合起來，完成海量數(shù)據(jù)的挖掘是一項(xiàng)復(fù)雜的工作。我們可以利用億信一站式數(shù)據(jù)分析平臺(tái)（ABI），可以快速構(gòu)建大數(shù)據(jù)分析平臺(tái)，該平臺(tái)集合了從數(shù)據(jù)源接入到ETL和數(shù)據(jù)倉庫進(jìn)行數(shù)據(jù)整合，再到數(shù)據(jù)分析，全部在一個(gè)平臺(tái)上完成。

我們可以看到億信一站式數(shù)據(jù)分析平臺(tái)ABI囊括了企業(yè)全部所需的大數(shù)據(jù)分析工具。ABI可以對(duì)各類業(yè)務(wù)進(jìn)行前瞻性預(yù)測分析，并為企業(yè)各層次用戶提供統(tǒng)一的決策分析支持，提升數(shù)據(jù)共享與流轉(zhuǎn)能力。

5.如何快速全面建立自己的大數(shù)據(jù)知識(shí)體系

所謂的大數(shù)據(jù)平臺(tái)不是獨(dú)立存在的，比如百度是依賴搜索引擎獲得大數(shù)據(jù)并開展業(yè)務(wù)的，阿里是通過電子商務(wù)交易獲得大數(shù)據(jù)并開展業(yè)務(wù)的，騰訊是通過社交獲得大數(shù)據(jù)并開始業(yè)務(wù)的，所以說大數(shù)據(jù)平臺(tái)不是獨(dú)立存在的，重點(diǎn)是如何搜集和沉淀數(shù)據(jù)，如何分析數(shù)據(jù)并挖掘數(shù)據(jù)的價(jià)值。

我可能還不夠資格回答這個(gè)問題，沒有經(jīng)歷過一個(gè)公司大數(shù)據(jù)平臺(tái)從無到有到復(fù)雜的過程。不過說說看法吧，也算是梳理一下想法找找噴。

這是個(gè)需求驅(qū)動(dòng)的過程。曾經(jīng)聽過spotify的分享，印象很深的是，他們分享說，他們的hadoop集群第一次故障是因?yàn)椋瑱C(jī)器放在靠窗的地方，太陽曬了當(dāng)機(jī)了（笑）。

從簡單的沒有機(jī)房放在自家窗前的集群到一直到現(xiàn)在復(fù)雜的數(shù)據(jù)平臺(tái)，這是一個(gè)不斷演進(jìn)的過程。對(duì)小公司來說，大概自己找一兩臺(tái)機(jī)器架個(gè)集群算算，也算是大數(shù)據(jù)平臺(tái)了。

在初創(chuàng)階段，數(shù)據(jù)量會(huì)很小，不需要多大的規(guī)模。這時(shí)候組件選擇也很隨意，Hadoop一套，任務(wù)調(diào)度用腳本或者輕量的框架比如luigi之類的，數(shù)據(jù)分析可能hive還不如導(dǎo)入RMDB快。

監(jiān)控和部署也許都沒時(shí)間整理，用腳本或者輕量的監(jiān)控，大約是沒有g(shù)anglia、nagios,puppet什么的。這個(gè)階段也許算是技術(shù)積累，用傳統(tǒng)手段還是真大數(shù)據(jù)平臺(tái)都是兩可的事情，但是為了今后的擴(kuò)展性，這時(shí)候上Hadoop也許是不錯(cuò)的選擇。

當(dāng)進(jìn)入高速發(fā)展期，也許擴(kuò)容會(huì)跟不上計(jì)劃，不少公司可能會(huì)遷移平臺(tái)到云上，比如AWS阿里云什么的。小規(guī)模高速發(fā)展的平臺(tái)，這種方式應(yīng)該是經(jīng)濟(jì)實(shí)惠的，省了運(yùn)維和管理的成本，擴(kuò)容比較省心。

要解決的是選擇平臺(tái)本身提供的服務(wù)，計(jì)算成本，打通數(shù)據(jù)出入的通道。整個(gè)數(shù)據(jù)平臺(tái)本身如果走這條路，可能就已經(jīng)基本成型了。

走這條路的比較有名的應(yīng)該是netflix。也有一個(gè)階段，你發(fā)現(xiàn)云服務(wù)的費(fèi)用太高，雖然省了你很多事，但是花錢嗖嗖的。

幾個(gè)老板一合計(jì)，再玩下去下個(gè)月工資發(fā)布出來了。然后無奈之下公司開始往私有集群遷移。

這時(shí)候你大概需要一群靠譜的運(yùn)維，幫你監(jiān)管機(jī)器，之前兩三臺(tái)機(jī)器登錄上去看看狀態(tài)換個(gè)磁盤什么的也許就不可能了，你面對(duì)的是成百上千臺(tái)主機(jī)，有些關(guān)鍵服務(wù)必須保證穩(wěn)定，有些是數(shù)據(jù)節(jié)點(diǎn)，磁盤三天兩頭損耗，網(wǎng)絡(luò)可能被壓得不堪重負(fù)。你需要一個(gè)靠譜的人設(shè)計(jì)網(wǎng)絡(luò)布局，設(shè)計(jì)運(yùn)維規(guī)范，架設(shè)監(jiān)控，值班團(tuán)隊(duì)走起7*24小時(shí)隨時(shí)準(zhǔn)備出臺(tái)。

然后上面再有平臺(tái)組真的大數(shù)據(jù)平臺(tái)走起。然后是選型，如果有技術(shù)實(shí)力，可以直接用社區(qū)的一整套，自己管起來，監(jiān)控部署什么的自己走起。

這個(gè)階段部署監(jiān)控和用戶管理什么的都不可能像兩三個(gè)節(jié)點(diǎn)那樣人肉搞了，配置管理，部署管理都需要專門的平臺(tái)和組件；定期Review用戶的作業(yè)和使用情況，決定是否擴(kuò)容，清理數(shù)據(jù)等等。否則等機(jī)器和業(yè)務(wù)進(jìn)一步增加，團(tuán)隊(duì)可能會(huì)死的很慘，疲于奔命，每天事故不斷，進(jìn)入惡性循環(huán)。

當(dāng)然有金錢實(shí)力的大戶可以找Cloudera,Hortonworks，國內(nèi)可以找華為星環(huán)，會(huì)省不少事，適合非互聯(lián)網(wǎng)土豪。當(dāng)然互聯(lián)網(wǎng)公司也有用這些東西的，比如Ebay。

接下去你可能需要一些重量的組件幫你做一些事情。比如你的數(shù)據(jù)接入，之前可能找個(gè)定時(shí)腳本或者爬log發(fā)包找個(gè)服務(wù)器接收寫入HDFS，現(xiàn)在可能不行了，這些大概沒有高性能，沒有異常保障，你需要更強(qiáng)壯的解決方案，比如Flume之類的。

你的業(yè)務(wù)不斷壯大，老板需要看的報(bào)表越來越多，需要訓(xùn)練的數(shù)據(jù)也需要清洗，你就需要任務(wù)調(diào)度，比如oozie或者azkaban之類的，這些系統(tǒng)幫你管理關(guān)鍵任務(wù)的調(diào)度和監(jiān)控。數(shù)據(jù)分析人員的數(shù)據(jù)大概可能漸漸從RDBMS搬遷到集群了，因?yàn)閭鹘y(tǒng)數(shù)據(jù)庫已經(jīng)完全hold不住了，但他們不會(huì)寫代碼，所以你上馬了Hive。

然后很多用戶用了Hive覺得太慢，你就又上馬交互分析系統(tǒng)，比如Presto,Impala或者SparkSQL。你的數(shù)據(jù)科學(xué)家需要寫ML代碼，他們跟你說你需要Mahout或者Spark MLLib，于是你也部署了這些。

至此可能數(shù)據(jù)平臺(tái)已經(jīng)是工程師的日常工作場所了，大多數(shù)業(yè)務(wù)都會(huì)遷移過來。這時(shí)候你可能面臨很多不同的問題。

比如各個(gè)業(yè)務(wù)線數(shù)據(jù)各種數(shù)據(jù)表多的一塌糊涂，不管是你還是寫數(shù)據(jù)的人大概都不知道數(shù)據(jù)從哪兒來，接下去到哪兒去。你就自己搞了一套元數(shù)據(jù)管理的系統(tǒng)。

你分析性能，發(fā)現(xiàn)你們的數(shù)據(jù)都是上百Column，各種復(fù)雜的Query，裸存的Text格式即便壓縮了也還是慢的要死，于是你主推用戶都使用列存，Parquet,ORC之類的。又或者你發(fā)現(xiàn)你們的ETL很長，中間生成好多臨時(shí)數(shù)據(jù)，于是你下狠心把pipeline改寫成Spark了。

再接下來也許你會(huì)想到花時(shí)間去維護(hù)一個(gè)門戶，把這些零散的組件都整合到一起，提供統(tǒng)一的用戶體驗(yàn)，比如一鍵就能把數(shù)據(jù)從數(shù)據(jù)庫chua一下拉到HDFS導(dǎo)入Hive，也能一鍵就chua一下再搞回去；點(diǎn)幾下就能設(shè)定一個(gè)定時(shí)任務(wù)，每天跑了給老板自動(dòng)推送報(bào)表；或者點(diǎn)一下就能起一個(gè)Storm的topology；或者界面上寫幾個(gè)Query就能查詢Hbase的數(shù)據(jù)。這時(shí)候你的數(shù)據(jù)平臺(tái)算是成型了。

當(dāng)然，磕磕碰碰免不了。每天你都有新的問題和挑戰(zhàn)，否則你就要失業(yè)了不是？你發(fā)現(xiàn)社區(qū)不斷在解決你遇到過的問題，于是你們架構(gòu)師每天分出很多時(shí)間去看社區(qū)的進(jìn)展，有了什么新工具，有。