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