大數據架構與數據分析

從目前接觸的大數據組件中，涵蓋範圍越來越多，從hadoop,hive,spark,storm,hbase,Kafka等到輻射出來的周邊生態組件，諸如:ES,Solr,Lucent等。從一個宏觀的架構層面來看，一個大數據項目都會配合不同的業務場景來選型合適的組件構建自己的大數據架構。比如，從一個數據分析或者挖掘為導向來看，一個應用場景（電商，社交或者遊戲等），它的基礎架構可以採用這種方式。舉個例子，比如遊戲的場景，不管是當下流行的手游（比如，王者榮耀）還是以前的網遊剛興起的盛大傳奇（現在廣告不是又興起了渣渣輝代言的貪玩藍月）。

那麼，通常情況下，一個遊戲從產品開發出來都會有運營的過程，需要了解當前遊戲的新增玩家，活躍玩家，玩家留存率等等，當然這些基礎數據只是給運營的可以作決策，為遊戲上線後暴露出的問題作調整和決策。畫一個圖，來看看基礎的架構:

整個架構可以剖析為以下幾個方面:

手機App或者終端產生的日誌，從遊戲的伺服器上面採集日誌文件：

將日誌信息打入Kafka集群，Kafka有較好的吞吐量，高可用和解耦性。

將Kafka的消息對接給HDFS,spark的集群或者ES的集群，HDFS可以用來存放全量的數據用於離線的數據分析（用於hive或者spark的Dataframe）,實時場景的數據則可以打入Spark streaming，ES的好處是可以做全文檢索和分析（比如聊天記錄，文本關鍵字快速檢索）,諸如百度搜索一個關鍵詞，會顯示許多相關網頁鏈接，就是對全文進行檢索然後做權重分析，將分數高的網頁鏈接排在前面。

將數據分析後的結果落地至DB，對於結構化的數據存放到關係型資料庫（Mysql,oracle）,對於非結構化數據或者有條件查詢性能要求的可以存放到非關係型資料庫Hbase.

將結果對接前端App做展現.

整體的技術架構可以根據當前的業務場景調整合適的方案，每一個組件都應發揮自己核心的功能。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！