如何建立一個大數據平臺？

https://www.zhihu.com/question/37627092

背景：

---

做者：Xiaoyu Ma
連接：https://www.zhihu.com/question/37627092/answer/72948056
來源：知乎
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。

對小公司來講，大概本身找一兩臺機器架個集羣算算，也算是大數據平臺了。在初創階段，數據量會很小，不須要多大的規模。這時候組件選擇也很隨意，Hadoop一套，任務調度用腳本或者輕量的框架好比luigi之類的，數據分析可能hive還不如導入RMDB快。監控和部署也許都沒時間整理，用腳本或者輕量的監控，大約是沒有ganglia、nagios，puppet什麼的。這個階段也許算是技術積累，用傳統手段仍是真大數據平臺都是兩可的事情，可是爲了從此的擴展性，這時候上Hadoop也許是不錯的選擇。
當進入高速發展期，也許擴容會跟不上計劃，很多公司可能會遷移平臺到雲上，好比AWS阿里雲什麼的。小規模高速發展的平臺，這種方式應該是經濟實惠的，省了運維和管理的成本，擴容比較省心。要解決的是選擇平臺自己提供的服務，計算成本，打通數據出入的通道。整個數據平臺自己若是走這條路，可能就已經基本成型了。走這條路的比較有名的應該是netflix。

也有一個階段，你發現雲服務的費用過高，雖然省了你不少事，可是花錢嗖嗖的。幾個老闆一合計，再玩下去下個月工資發佈出來了。而後無奈之下公司開始往私有集羣遷移。這時候你大概須要一羣靠譜的運維，幫你監管機器，以前兩三臺機器登陸上去看看狀態換個磁盤什麼的也許就不可能了，你面對的是成百上千臺主機，有些關鍵服務必須保證穩定，有些是數據節點，磁盤三天兩頭損耗，網絡可能被壓得不堪重負。你須要一個靠譜的人設計網絡佈局，設計運維規範，架設監控，值班團隊走起7*24小時隨時準備出臺。而後上面再有平臺組真的大數據平臺走起。
而後是選型，若是有技術實力，能夠直接用社區的一整套，本身管起來，監控部署什麼的本身走起。這個階段部署監控和用戶管理什麼的都不可能像兩三個節點那樣人肉搞了，配置管理，部署管理都須要專門的平臺和組件；按期Review用戶的做業和使用狀況，決定是否擴容，清理數據等等。不然等機器和業務進一步增長，團隊可能會死的很慘，疲於奔命，天天事故不斷，進入惡性循環。
固然有金錢實力的大戶能夠找Cloudera，Hortonworks，國內能夠找華爲星環，會省很多事，適合非互聯網土豪。固然互聯網公司也有用這些東西的，好比Ebay。
接下去你可能須要一些重量的組件幫你作一些事情。
好比你的數據接入，以前可能找個定時腳本或者爬log發包找個服務器接收寫入HDFS，如今可能不行了，這些大概沒有高性能，沒有異常保障，你須要更強壯的解決方案，好比Flume之類的。

你的業務不斷壯大，老闆須要看的報表愈來愈多，須要訓練的數據也須要清洗，你就須要任務調度，好比oozie或者azkaban之類的，這些系統幫你管理關鍵任務的調度和監控。
數據分析人員的數據大概可能漸漸從RDBMS搬遷到集羣了，由於傳統數據庫已經徹底hold不住了，但他們不會寫代碼，因此你上馬了Hive。而後不少用戶用了Hive以爲太慢，你就又上馬交互分析系統，好比Presto，Impala或者SparkSQL。
你的數據科學家須要寫ML代碼，他們跟你說你須要Mahout或者Spark MLLib，因而你也部署了這些。
至此可能數據平臺已是工程師的平常工做場所了，大多數業務都會遷移過來。這時候你可能面臨不少不一樣的問題。
好比各個業務線數據各類數據表多的一塌糊塗，無論是你仍是寫數據的人大概都不知道數據從哪兒來，接下去到哪兒去。你就本身搞了一套元數據管理的系統。
你分析性能，發現大家的數據都是上百Column，各類複雜的Query，裸存的Text格式即使壓縮了也仍是慢的要死，因而你主推用戶都使用列存，Parquet，ORC之類的。
又或者你發現大家的ETL很長，中間生成好多臨時數據，因而你下狠心把pipeline改寫成Spark了。
再接下來也許你會想到花時間去維護一個門戶，把這些零散的組件都整合到一塊兒，提供統一的用戶體驗，好比一鍵就能把數據從數據庫chua一下拉到HDFS導入Hive，也能一鍵就chua一下再搞回去；點幾下就能設定一個定時任務，天天跑了給老闆自動推送報表；或者點一下就能起一個Storm的topology；或者界面上寫幾個Query就能查詢Hbase的數據。這時候你的數據平臺算是成型了。

固然，磕磕碰碰免不了。天天你都有新的問題和挑戰，不然你就要失業了不是？
你發現社區不斷在解決你遇到過的問題，因而大家架構師天天分出不少時間去看社區的進展，有了什麼新工具，有什麼公司發佈了什麼項目解決了什麼問題，興許你就能用上。
上了這些亂七八糟的東西，你覺得就安生了？Hadoop平臺的一個大特色就是坑多。尤爲是新作的功能新起的項目。對於平臺組的人，老闆若是知道這是自然坑多的平臺，那他也許會很高興，由於跟進社區，幫忙修bug，一塊兒互動實際上是很提高公司影響力的實情。固然若是老闆不理解，你就自求多福吧，招幾個老司機，出了問題能立刻帶路纔是正道。固然團隊的技術積累不能不跟上，由於數據平臺仍是亂世，三天不跟進你就不知道世界是什麼樣了。任何一個新技術，都是坑啊坑啊修啊修啊才完善的。若是是關鍵業務換技術，那須要當心再當心，技術主管也要有足夠的積累，可以駕馭，知道收益和風險。

---

大數據平臺從平臺部署和數據分析過程可分爲以下幾步：

一、linux系統安裝
 通常使用開源版的Redhat系統--CentOS做爲底層平臺。爲了提供穩定的硬件基礎，在給硬盤作RAID和掛載數據存儲節點的時，須要按狀況配置。例如，能夠選擇給HDFS的namenode作RAID2以提升其穩定性，將數據存儲與操做系統分別放置在不一樣硬盤上，以確保操做系統的正常運行。

二、分佈式計算平臺/組件安裝
 目前國內外的分佈式系統的大多使用的是Hadoop系列開源系統。Hadoop的核心是HDFS，一個分佈式的文件系統。在其基礎上經常使用的組件有Yarn、Zookeeper、Hive、Hbase、Sqoop、Impala、ElasticSearch、Spark等。
 先說下使用開源組件的優勢：1）使用者衆多，不少bug能夠在網上找的答案（這每每是開發中最耗時的地方）。2）開源組件通常免費，學習和維護相對方便。3）開源組件通常會持續更新，提供必要的更新服務『固然還須要手動作更新操做』。4）由於代碼開源，若出bug可自由對源碼做修改維護。
 再簡略講講各組件的功能。分佈式集羣的資源管理器通常用Yarn，『全名是Yet Another Resource Negotiator』。經常使用的分佈式數據數據『倉』庫有Hive、Hbase。Hive能夠用SQL查詢『但效率略低』，Hbase能夠快速『近實時』讀取行。外部數據庫導入導出須要用到Sqoop。Sqoop將數據從Oracle、MySQL等傳統數據庫導入Hive或Hbase。Zookeeper是提供數據同步服務，Yarn和Hbase須要它的支持。Impala是對hive的一個補充，能夠實現高效的SQL查詢。ElasticSearch是一個分佈式的搜索引擎。針對分析，目前最火的是Spark『此處忽略其餘，如基礎的MapReduce 和 Flink』。Spark在core上面有ML lib，Spark Streaming、Spark QL和GraphX等庫，能夠知足幾乎全部常見數據分析需求。
 值得一提的是，上面提到的組件，如何將其有機結合起來，完成某個任務，不是一個簡單的工做，可能會很是耗時。

三、數據導入
 前面提到，數據導入的工具是Sqoop。用它能夠將數據從文件或者傳統數據庫導入到分佈式平臺『通常主要導入到Hive，也可將數據導入到Hbase』。

四、數據分析
  數據分析通常包括兩個階段：數據預處理和數據建模分析。
數據預處理是爲後面的建模分析作準備，主要工做時從海量數據中提取可用特徵，創建大寬表。這個過程可能會用到Hive SQL，Spark QL和Impala。
數據建模分析是針對預處理提取的特徵/數據建模，獲得想要的結果。如前面所提到的，這一塊最好用的是Spark。經常使用的機器學習算法，如樸素貝葉斯、邏輯迴歸、決策樹、神經網絡、TFIDF、協同過濾等，都已經在ML lib裏面，調用比較方便。

五、結果可視化及輸出API
 可視化通常式對結果或部分原始數據作展現。通常有兩種狀況，行數據展現，和列查找展現。在這裏，要基於大數據平臺作展現，會須要用到ElasticSearch和Hbase。Hbase提供快速『ms級別』的行查找。 ElasticSearch能夠實現列索引，提供快速列查找。

 

平臺搭建主要問題：
一、穩定性 Stability
 理論上來講，穩定性是分佈式系統最大的優點，由於它能夠經過多臺機器作數據及程序運行備份以確保系統穩定。但也因爲大數據平臺部署於多臺機器上，配置不合適，也可能成爲最大的問題。 曾經遇到的一個問題是Hbase常常掛掉，主要緣由是採購的硬盤質量較差。硬盤損壞有時會到致使Hbase同步出現問題，於是致使Hbase服務中止。因爲硬盤質量較差，隔三差五會出現服務中止現象，耗費大量時間。結論：大數據平臺相對於超算確實廉價，可是配置仍是必須高於家用電腦的。

二、可擴展性 Scalability
 如何快速擴展已有大數據平臺，在其基礎上擴充新的機器是雲計算等領域應用的關鍵問題。在實際2B的應用中，有時須要增減機器來知足新的需求。如何在保留原有功能的狀況下，快速擴充平臺是實際應用中的常見問題。

上述是本身項目實踐的總結。整個平臺搭建過程耗時耗力，非一兩我的能夠完成。一個小團隊要真正作到這些也須要耗費很長時間。

目前國內和國際上已有多家公司提供大數據平臺搭建服務，國外有名的公司有Cloudera，Hortonworks，MapR等，國內也有華爲、明略數據、星環等。另外有些公司如明略數據等還提供一體化的解決方案，尋求這些公司合做對 於入門級的大數據企業或沒有大數據分析能力的企業來講是最好的解決途徑。

對於一些自己體量較小或者目前數據量積累較少的公司，我的認爲沒有必要搭建這一套系統，暫時先租用AWS和阿里雲就夠了。對於數據量大，但數據分析需求較簡單的公司，能夠直接買Tableau，Splunk，HP Vertica，或者IBM DB2等軟件或服務便可。

---

對於一個大數據平臺主要分爲三部分：

• 數據接入

• 數據處理

• 數據分析

•  

數據接入是將數據寫入數據倉儲中，也就是數據整合。由於在企業中，數據可能分佈在外部和內部，分佈在外部的是企業使用第三方系統產生的數據和一些公共數據，分佈在企業內部的是企業內部IT系統產生的數據。這些數據通常都是獨立分佈的，也就是所說的數據孤島，此時的這些數據是沒有什麼意義的，所以數據接入就是將這些內外部的數據整合到一塊兒，將這些數據綜合起來進行分析。

數據處理是對接入的數據進行數據清洗和ETL建模，將各個數據表之間的關係創建起來，好比關聯，聚合，追加等等這些處理。

數據分析是在數據處理後的數據基礎上進行維度和數值的可視化分析，也就是基於OLAP的查詢和分析，包含上卷，鑽取，切片，轉軸等操做，最後分析的結果經過報表或是儀表盤來呈現出來，從而支撐業務人員和決策人員。

按照數據處理的順序能夠將大數據平臺分爲傳統型和敏捷型，傳統型的是在將數據送入數據倉儲裏面以前作，存入數據倉儲裏面的數據已經定義好了事實維度這些模型關係，業務人員能夠直接進行查詢，可是實時性和靈活性會大打折扣，若是業務人員須要分析一個事先沒有的數據的話，須要去跟技術人員反饋，技術人員來完成處理。而敏捷型的則是將數據處理放到了後面，這樣業務人員能夠根據本身的須要去自助探索式的建模和進行數據分析，可是對系統的性能要求較高。

上面只是從產品層面來進行了說明，下面從技術層面來進行對應。

首先是數據倉儲，通常是基於HDFS，採用分佈式的文件系統來進行存儲。數據處理和數據分析須要基於大數據處理引擎，若是想要實時的查詢則須要用Spark這類的基於內存計算的，若是實時性要求沒那麼高的則能夠用基於MR的這些離線計算的引擎。數據分析須要OLAP以及前端可視化這些技術來進行支撐。

知道了是什麼樣的，接下來咱們能夠來作了。

經過上面的介紹，咱們能夠看出須要的技術成本是比較高的，所以對於初創型的公司建議採用第三方的工具來使用。好比國內的BDP(http://www.bdp.cn)和永洪（http://yonghongtech.com），國外的DOMO(http://domo.com)這些SaaS產品,更小型的團隊可使用BDP我的版(http://me.bdp.cn)。這些數據產品都是能夠知足企業分析數據的須要，同時有上面所說的各種功能。因爲BDP我的版是免費的，這裏經過一些截圖來講明一下。

數據接入- 支持各種第三方API以及數據庫

數據處理-可視化拖拽和SQL

數據可視化-豐富的圖表和交互

若是公司有足夠的實力，想自建數據平臺，能夠在現有的一些開源的數據相關的工具來進行搭建，底層存儲和計算平臺的HDFS，Spark，Hive這些都是Apache開源的，OLAP有Kylin，Saiku這些開源工具，可視化有Airbnb開源的Superset，若是在這些基礎上進行搭建和開發，相信可以省去一些開發量，可是事物除了有共性仍是有個性的，想要絕對的知足需求是沒有的，都是須要企業根據自身的需求來進行定製化開發的。

---

軟件工程的流程來分析數據工程，也就是大數據平臺的建設步驟。

軟件工程建設步驟包括需求分析、系統設計、系統開發、系統運維等4大方面。本文主要講一下前3個方面。

一、需求分析

數據需求分爲三個層次，分別爲業務需求、用戶需求、功能需求。各需求要了解清楚大體內容：

• 業務需求，老闆想幹啥？是想賺多點錢仍是政績工程？固然通常會是精準營銷、個性化服務、提高效率等

• 用戶需求，真正使用這個平臺的用戶的需求是什麼？要什麼數據？分析啥？

• 功能需求，基於業務需求和用戶需求推導出大數據平臺須要具有哪些功能

• 數據需求：要接入哪些數據？指標體系是怎樣？數據來源於哪些系統？數據量大概什麼量級？日增量大概多少？數據接口是怎樣的？

二、系統設計

基於需求分析的輸出設計大數據平臺，設計步驟主要包含4個子環節：

• 技術選型，技術選型主要考慮3個輸入：數據量、查詢性能要求、實時性要求等，由此決定是採用傳統數據倉庫仍是分佈式架構，同時還需考慮資金和團隊的因素，若是有錢可採用商用平臺和服務，沒錢但有技術團隊，可採用開源方案，沒錢又沒團隊能夠洗洗睡了。

• 技術架構設計，採集、存儲、計算、交互式查詢、機器學習等場景分別採用什麼技術？同時各技術的集成性須要考慮。

• 數據架構設計，數據主題、數據分層、數據流、數據交換方式等等

• 數據應用設計，也就是上層數據應用的功能設計，這個和軟件差很少，但基於數據的應用設計仍是有不少不一樣的考慮，在此不作贅述。

三、系統開發

• 平臺部署：部署hadoop等大數據平臺；

• 數據集成及處理開發：開發ETL，從數據源採集數據，並作清洗、標準化造成主題庫，並根據主題庫的標準數據，根據上層數據應用需求，處理成相應的專題庫（也叫數據集市）；

• 數據服務開發：開發併發布上層所需的數據服務接口，供上層數據應用調用；

• 數據應用開發：基於數據服務、數據集，開發數據應用；

 

---

比較簡單的步驟：
1. 首先要有一個分佈式的文件系統，保證可以對「大」的數據進行存儲，並且該文件系統應該具備容錯和高吞吐量的特色，例如HDFS之類的。
2. 而後要有一個分佈式的計算環境，如Hadoop、Spark之類的，可以快速開發程序對數據進行分析和加工。
3. 最後要有一個大數據的可視化工具，可以快速生成可視化界面。

---

我參與了一個大數據平臺從無到有的過程，建立平臺提及來很簡單！但你須要考慮幾個問題：
1、平臺的定位：交易？解決方案？商城？
2、數據的來源：自有？第三方渠道？
3、人員的配備：技術驅動？銷售驅動？運營驅動？
4、平臺的規則：如何保證數據安全？如何給數據訂價？如何保證數據質量？數據使用問題如何定則？數據的更新頻率。及時。有效性。
5、快速變現：如何教育用戶使用？如何讓數據流通碰撞？

---

第一步，抓取數據
第二步，創建模型
第三步，讀取數據。