關注天善智能，走好數據之路↑↑↑

歡迎關注天善智能hellobi.com，我們是專注於商業智能BI，大數據，數據分析領域的垂直社區，學習、問答、求職一站式搞定！

前言：對於一些朋友而言，做技術（包括大數據挖掘、深度學習），優先選擇最潮流的技術，跟上開源社區的節奏，這樣才能讓自己不被這個大數據時代所淘汰，談薪資也才有底氣。出發點也沒錯，可是在我看來，我們對待每一次技術的選型，還應該客觀去結合數據業務的適用場景，也應該認真去做一定的調研分析，知其然，知其所以然。

說明：此文在3月初首發於 大數據挖掘雜談 小密圈。在 影響力與知識傳播 和 付費 之間，我選擇前者

一、初識Hadoop生態系統

從古到今，數據一直存在著，而所謂的大數據也並不是起源於Hadoop，更不會受限於Hadoop的發展，它會伴隨著宇宙源遠流長著。

但是，大數據這個概念的逐漸爆發得源於2014年左右的Hadoop被推廣使用，這是無可非議的。

整個互聯網每天都會產生巨大的數據量，從G級、到TB、乃至PB和EB級別，這些大數據包括很多方面：生活、網絡、通信、出行和飲食等等，而且越來越多公司開始重視起積累數據了。

1 EB = 1024 PB = 1024 * 1024 TB = 1024 * 1024 * 1024 GB

從2014年~2016年底，在我看來，整個大數據領域做對了兩件事：數據積累和大數據平臺的基礎性建設。

我經常和團隊的開發成員說這樣一句話："當下大數據價值還沒真正挖掘出來，這不是代表我們做的數據產品不夠好，而是整個大環境本身就是這樣。經過這麼多年的努力，可以說整個大數據環境的準備工作已經做完了，接下來的時間就能真正去花心思去彰顯大數據的價值。而且這個時間，我認為不會等太長。"

所以，在這個前期，我們還需要去了解整個Hadoop生態系統所涉及的技術面，這才是以後真正做好大數據挖掘的前提，而不僅僅只考慮到算法和模型這個層次面的技術，知道它的來龍去脈。

Hadoop生態系統

上面這樣的圖，大家都會看到很多類似的，但是真正去了解和使用的朋友不會太多

有時候可以戲稱Hadoop生態圈是一個軟件庫框架，包含了很多重要的組建。但因為有著嚴格的選擇標準，Apache下的項目並不會顯得擁擠和重複，反而各有其職，分別提供特定的服務。

Apache Hive：數據倉庫基礎設施，提供數據彙總和特定查詢。它是最常用的大數據ETL工具，底層的計算引擎支持MR和Spark等。

Apache Spark：Apache Spark是提供大數據集上快速進行數據分析的計算引擎。它建立在HDFS之上，卻繞過了MapReduce使用自己的數據處理框架。適用於實時查詢、流處理、迭代算法、複雜操作運算和機器學習。

Apache Ambari：Ambari用來協助管理Hadoop。它提供對Hadoop生態系統中許多工具的支持，包括Hive、HBase、Pig、 Spooq和ZooKeeper。這個工具提供集群管理儀表盤，可以跟蹤集群運行狀態，幫助診斷性能問題。

Apache Pig：Pig是一個集成高級查詢語言的平臺，可以用來處理大數據集，現在相對而言使用很少了。

Apache HBase：HBase是一個非關係型數據庫管理系統，運行在HDFS之上。它用來處理大數據工程中稀疏數據集，做業務場景建模中使用很多。

其他常見的Hadoop項目還包括Avro、Cassandra、Chukwa, Sqoop和ZooKeeper等等。

我在兩年前針對性創建了一個關於Sqoop1\2的QQ群，感興趣可以去搜，裡面的交流氛圍一直很好

對於一個優秀的大數據挖掘工程師，在整個業務場景建模的過程中，經常會使用到的主要有Hive（用來做數據清洗）、HDFS（存儲模型數據的文件系統）、MapReduce（寫模型需要的分佈式計算框架）、Spark（寫模型需要的迭代式計算框架）和HBase（特殊模型數據存儲）。

後期有文章會單獨介紹如何通過Spark和Hadoop來程序查詢HBase數據和存儲數據

同樣，作為一個優秀的大數據挖掘工程師，更要時刻清楚自己工作在整個大數據生態系統所扮演的角色，以及所處於的位置，至關重要。

大數據挖掘所扮演的角色性

短短的這些內容，很難讓你徹底掌握大數據生態圈的很多技術，沒有一個真實的大數據平臺和環境去大量實踐操作，感悟沒這麼深。

但是參與任何分享和學習書本知識，首先就應該抱著一個正確的態度：有了這個印象，線下的時候我需要實操，杜絕看了即忘。

二、知曉Spark的背景與特點

談起Spark，很多人對它特別著迷，甚至一些初學者完全拋棄Hadoop，直接去接觸它，得它得offer。

我覺得這樣很不好，任何事，都需要去真正瞭解它的背景，知道它的發展是如何變遷的，你才會使用得更好。

MapReduce的不足

我以往的文章中簡單提到過下面這個概念，在Spark誕生前，MapReduce的使用存在很多侷限性。

第1點：這套分佈式計算框架支持的操作很有限，僅僅有Map和Reduce兩種。

第2點：處理效率很低，中間結果的不斷寫磁盤操作，以及每一次任務的初始化啟動時間、還有強制性的數據排序以及內存的利用率低。

第3點：開發週期長，重複代碼量很多，不簡潔，也不高效。

第4點：實時性不夠高，也不適合進行迭代式計算，使用場景很單一，只針對離線。

所以，由於這些種種因素，迫使得人們渴望一種更全能的計算框架去滿足更多的業務場景需求。

有需求才會有方向，這是最直接的生產力

來自Spark的誕生

Hadoop生態圈的開源社區探索者們就開始思考這個問題："能否有一種靈活的框架，可以包括批處理、流式計算，以及是交互式計算呢？。"

最終召喚神龍，集三者為一體，終究發佈了Spark這樣的迭代式計算框架。

集3張卡片召喚神龍

相比MapReduce而言，它有很多自身的優勢，如果簡單粗暴去說，就這三點：高效、易用和集成性高。

而且目前它支持四種語言，Scala、Java、Python和R。

推薦它原生的底層語言，Scala來進行編程，你會有不一樣的收穫

它們執行過程的區別

如果是細問MapReduce和Spark的任務執行過程有什麼區別，我們這裡可以看看它們分別對於執行任務的定義就可以看得出來。

在一些人看來，它們都是向集群提交任務，執行過程不就都一樣？

在我前幾期圈子內的文章裡，我給大家分享了關於MapReduce的編程，裡面詳細去說明了整個MR的執行過程包括Map階段和Reduce階段。

簡單來說，一個MR過程就是一次作業（稱為Task，包含Map和Reduce階段），而一個完整的MR工程可能會包含多次執行作業（稱為Job），有多個執行階段，重複的初始化啟動過程。

而在Spark中，涉及到的概念會更多，而且有差異性。

new SparkContext(new SparkConf().setAppName())

上面的一個SparkContext對應一個Application，而每個Application可能會有一個或多個Job來進行執行。

對於具體的Job，可能會因為數據的因素存在多個Stage來進行處理，最終每個Stage可以包含多個Task去執行。

一張圖看懂包含關係

而整個任務進程的生命週期可以通過下面命令來進行查看：

yarn application -list

以上就是關於使用Spark前期，需要去了解的背景知識和它與MapReduce的差異性和自身特點。

下篇涉及內容：

三、Spark和MapReduce編程的差異

四、對於一個算法模型，如何靈活在MapReduce和Spark兩則之間進行轉換

五、面對一個實際的業務場景，怎麼去選擇更合適的實現工具去構建業務場景模型

本文作者：樂平汪二

天善社區博客地址：https://ask.hellobi.com/blog/wanger0728