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