大數(shù)據(jù)平臺搭建(大數(shù)據(jù)入門需學(xué)習(xí)哪些)
1.大數(shù)據(jù)入門需學(xué)習(xí)哪些基礎(chǔ)知識
前言，學(xué)大數(shù)據(jù)要先換電腦：
保證電腦4核8G內(nèi)存64位操作系統(tǒng)，盡量有ssd做系統(tǒng)盤，否則卡到你喪失信心。硬盤越大越好。
1，語言要求
java剛?cè)腴T的時候要求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)計，排序，join,group等，然后就是sql語句調(diào)優(yōu)，表設(shè)計等。
4，大數(shù)據(jù)基本了解
Zookeeper,hadoop,hbase,hive,sqoop,flume,kafka,spark,storm等這些框架的作用及基本環(huá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ù)倉庫的標配。要回用，懂調(diào)優(yōu)，故障排查。
hbase看浪尖hbase系列文章。hive后期更新。
7，消息隊列的使用
kafka基本概念，使用，瓶頸分析?？蠢思鈑afka系列文章。
8，實時處理系統(tǒng)
storm和spark Streaming
9,spark core和sparksql
spark用于離線分析的兩個重要功能。
10，最終方向決策
a），運維。（精通整套系統(tǒng)及故障排查，會寫運維腳本啥的。）
b），數(shù)據(jù)分析。（算法精通）
c），平臺開發(fā)。（源碼精通）
自學(xué)還是培訓(xùn)？
無基礎(chǔ)的同學(xué)，培訓(xùn)之前先搞到視頻通學(xué)一遍，防止盲目培訓(xùn)跟不上講師節(jié)奏，浪費時間，精力，金錢。
有基礎(chǔ)的盡量搞點視頻學(xué)基礎(chǔ)，然后跟群里大牛交流，前提是人家愿意，
想辦法跟大牛做朋友才是王道。
2.大數(shù)據(jù)平臺在搭建時有哪些要注意的部分
大數(shù)據(jù)平臺搭建的主要問題
1、穩(wěn)定性 Stability
理論上來說，穩(wěn)定性是分布式系統(tǒng)最大的優(yōu)勢，因為它可以通過多臺機器做數(shù)據(jù)及程序運行備份以確保系統(tǒng)穩(wěn)定。但也由于大數(shù)據(jù)平臺部署于多臺機器上，配置不合適，也可能成為最大的問題。
2、可擴展性 Scalability
如何快速擴展已有大數(shù)據(jù)平臺，在其基礎(chǔ)上擴充新的機器是云計算等領(lǐng)域應(yīng)用的關(guān)鍵問題。在實際2B的應(yīng)用中，有時需要增減機器來滿足新的需求。如何在保留原有功能的情況下，快速擴充平臺是實際應(yīng)用中的常見問題。
3.怎么搭建大數(shù)據(jù)分析平臺
未至科技魔方是一款大數(shù)據(jù)模型平臺，是一款基于服務(wù)總線與分布式云計算兩大技術(shù)架構(gòu)的一款數(shù)據(jù)分析、挖掘的工具平臺，其采用分布式文件系統(tǒng)對數(shù)據(jù)進行存儲，支持海量數(shù)據(jù)的處理。
采用多種的數(shù)據(jù)采集技術(shù)，支持結(jié)構(gòu)化數(shù)據(jù)及非結(jié)構(gòu)化數(shù)據(jù)的采集。通過圖形化的模型搭建工具，支持流程化的模型配置。
通過第三方插件技術(shù)，很容易將其他工具及服務(wù)集成到平臺中去。數(shù)據(jù)分析研判平臺就是海量信息的采集，數(shù)據(jù)模型的搭建，數(shù)據(jù)的挖掘、分析最后形成知識服務(wù)于實戰(zhàn)、服務(wù)于決策的過程，平臺主要包括數(shù)據(jù)采集部分，模型配置部分，模型執(zhí)行部分及成果展示部分等。
4.怎么搭建大數(shù)據(jù)分析平臺
1，大數(shù)據(jù)分析平臺的特點數(shù)據(jù)攝取、數(shù)據(jù)管理、ETL和數(shù)據(jù)倉庫：提供有效的數(shù)據(jù)入庫與管理數(shù)據(jù)用于管理作為一種寶貴的資源。
Hadoop系統(tǒng)功能：提供海量存儲的任何類型的數(shù)據(jù)，大量處理功率和處理能力幾乎是無限并行工作或任務(wù)流計算在拉動特征：用于流的數(shù)據(jù)、處理數(shù)據(jù)并將這些流作為單個流。內(nèi)容管理特征：綜合生命周期管理和文檔內(nèi)容。
數(shù)據(jù)治理綜合：安全、治理和合規(guī)解決方案來保護數(shù)據(jù)2，怎樣去搭建大數(shù)據(jù)分析平臺大數(shù)據(jù)分析處理平臺就是整合當前主流的各種具有不同側(cè)重點的大數(shù)據(jù)處理分析框架和工具，實現(xiàn)對數(shù)據(jù)的挖掘和分析，一個大數(shù)據(jù)分析平臺涉及到的組件眾多，如何將其有機地結(jié)合起來，完成海量數(shù)據(jù)的挖掘是一項復(fù)雜的工作。我們可以利用億信一站式數(shù)據(jù)分析平臺（ABI），可以快速構(gòu)建大數(shù)據(jù)分析平臺，該平臺集合了從數(shù)據(jù)源接入到ETL和數(shù)據(jù)倉庫進行數(shù)據(jù)整合，再到數(shù)據(jù)分析，全部在一個平臺上完成。
我們可以看到億信一站式數(shù)據(jù)分析平臺ABI囊括了企業(yè)全部所需的大數(shù)據(jù)分析工具。ABI可以對各類業(yè)務(wù)進行前瞻性預(yù)測分析，并為企業(yè)各層次用戶提供統(tǒng)一的決策分析支持，提升數(shù)據(jù)共享與流轉(zhuǎn)能力。
5.如何快速全面建立自己的大數(shù)據(jù)知識體系
所謂的大數(shù)據(jù)平臺不是獨立存在的，比如百度是依賴搜索引擎獲得大數(shù)據(jù)并開展業(yè)務(wù)的，阿里是通過電子商務(wù)交易獲得大數(shù)據(jù)并開展業(yè)務(wù)的，騰訊是通過社交獲得大數(shù)據(jù)并開始業(yè)務(wù)的，所以說大數(shù)據(jù)平臺不是獨立存在的，重點是如何搜集和沉淀數(shù)據(jù)，如何分析數(shù)據(jù)并挖掘數(shù)據(jù)的價值。
我可能還不夠資格回答這個問題，沒有經(jīng)歷過一個公司大數(shù)據(jù)平臺從無到有到復(fù)雜的過程。不過說說看法吧，也算是梳理一下想法找找噴。
這是個需求驅(qū)動的過程。曾經(jīng)聽過spotify的分享，印象很深的是，他們分享說，他們的hadoop集群第一次故障是因為，機器放在靠窗的地方，太陽曬了當機了（笑）。
從簡單的沒有機房放在自家窗前的集群到一直到現(xiàn)在復(fù)雜的數(shù)據(jù)平臺，這是一個不斷演進的過程。對小公司來說，大概自己找一兩臺機器架個集群算算，也算是大數(shù)據(jù)平臺了。
在初創(chuàng)階段，數(shù)據(jù)量會很小，不需要多大的規(guī)模。這時候組件選擇也很隨意，Hadoop一套，任務(wù)調(diào)度用腳本或者輕量的框架比如luigi之類的，數(shù)據(jù)分析可能hive還不如導(dǎo)入RMDB快。
監(jiān)控和部署也許都沒時間整理，用腳本或者輕量的監(jiān)控，大約是沒有g(shù)anglia、nagios,puppet什么的。這個階段也許算是技術(shù)積累，用傳統(tǒng)手段還是真大數(shù)據(jù)平臺都是兩可的事情，但是為了今后的擴展性，這時候上Hadoop也許是不錯的選擇。
當進入高速發(fā)展期，也許擴容會跟不上計劃，不少公司可能會遷移平臺到云上，比如AWS阿里云什么的。小規(guī)模高速發(fā)展的平臺，這種方式應(yīng)該是經(jīng)濟實惠的，省了運維和管理的成本，擴容比較省心。
要解決的是選擇平臺本身提供的服務(wù)，計算成本，打通數(shù)據(jù)出入的通道。整個數(shù)據(jù)平臺本身如果走這條路，可能就已經(jīng)基本成型了。
走這條路的比較有名的應(yīng)該是netflix。也有一個階段，你發(fā)現(xiàn)云服務(wù)的費用太高，雖然省了你很多事，但是花錢嗖嗖的。
幾個老板一合計，再玩下去下個月工資發(fā)布出來了。然后無奈之下公司開始往私有集群遷移。
這時候你大概需要一群靠譜的運維，幫你監(jiān)管機器，之前兩三臺機器登錄上去看看狀態(tài)換個磁盤什么的也許就不可能了，你面對的是成百上千臺主機，有些關(guān)鍵服務(wù)必須保證穩(wěn)定，有些是數(shù)據(jù)節(jié)點，磁盤三天兩頭損耗，網(wǎng)絡(luò)可能被壓得不堪重負。你需要一個靠譜的人設(shè)計網(wǎng)絡(luò)布局，設(shè)計運維規(guī)范，架設(shè)監(jiān)控，值班團隊走起7*24小時隨時準備出臺。
然后上面再有平臺組真的大數(shù)據(jù)平臺走起。然后是選型，如果有技術(shù)實力，可以直接用社區(qū)的一整套，自己管起來，監(jiān)控部署什么的自己走起。
這個階段部署監(jiān)控和用戶管理什么的都不可能像兩三個節(jié)點那樣人肉搞了，配置管理，部署管理都需要專門的平臺和組件；定期Review用戶的作業(yè)和使用情況，決定是否擴容，清理數(shù)據(jù)等等。否則等機器和業(yè)務(wù)進一步增加，團隊可能會死的很慘，疲于奔命，每天事故不斷，進入惡性循環(huán)。
當然有金錢實力的大戶可以找Cloudera,Hortonworks，國內(nèi)可以找華為星環(huán)，會省不少事，適合非互聯(lián)網(wǎng)土豪。當然互聯(lián)網(wǎng)公司也有用這些東西的，比如Ebay。
接下去你可能需要一些重量的組件幫你做一些事情。比如你的數(shù)據(jù)接入，之前可能找個定時腳本或者爬log發(fā)包找個服務(wù)器接收寫入HDFS，現(xiàn)在可能不行了，這些大概沒有高性能，沒有異常保障，你需要更強壯的解決方案，比如Flume之類的。
你的業(yè)務(wù)不斷壯大，老板需要看的報表越來越多，需要訓(xùn)練的數(shù)據(jù)也需要清洗，你就需要任務(wù)調(diào)度，比如oozie或者azkaban之類的，這些系統(tǒng)幫你管理關(guān)鍵任務(wù)的調(diào)度和監(jiān)控。數(shù)據(jù)分析人員的數(shù)據(jù)大概可能漸漸從RDBMS搬遷到集群了，因為傳統(tǒng)數(shù)據(jù)庫已經(jīng)完全hold不住了，但他們不會寫代碼，所以你上馬了Hive。
然后很多用戶用了Hive覺得太慢，你就又上馬交互分析系統(tǒng)，比如Presto,Impala或者SparkSQL。你的數(shù)據(jù)科學(xué)家需要寫ML代碼，他們跟你說你需要Mahout或者Spark MLLib，于是你也部署了這些。
至此可能數(shù)據(jù)平臺已經(jīng)是工程師的日常工作場所了，大多數(shù)業(yè)務(wù)都會遷移過來。這時候你可能面臨很多不同的問題。
比如各個業(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ù)據(jù)，于是你下狠心把pipeline改寫成Spark了。
再接下來也許你會想到花時間去維護一個門戶，把這些零散的組件都整合到一起，提供統(tǒng)一的用戶體驗，比如一鍵就能把數(shù)據(jù)從數(shù)據(jù)庫chua一下拉到HDFS導(dǎo)入Hive，也能一鍵就chua一下再搞回去；點幾下就能設(shè)定一個定時任務(wù)，每天跑了給老板自動推送報表；或者點一下就能起一個Storm的topology；或者界面上寫幾個Query就能查詢Hbase的數(shù)據(jù)。這時候你的數(shù)據(jù)平臺算是成型了。
當然，磕磕碰碰免不了。每天你都有新的問題和挑戰(zhàn)，否則你就要失業(yè)了不是？你發(fā)現(xiàn)社區(qū)不斷在解決你遇到過的問題，于是你們架構(gòu)師每天分出很多時間去看社區(qū)的進展，有了什么新工具，有。
