Hadoop/Spark生态圈里的新气象
令人驚訝的是，Hadoop在短短一年的時間里被重新定義。讓我們看看這個火爆生態(tài)圈的所有主要部分，以及它們各自具有的意義。
對于Hadoop你需要了解的最重要的事情就是，它不再是原來的Hadoop。
這邊廂，Cloudera有時換掉HDFS改用Kudu，同時宣布Spark是其圈子的核心(因而一概取代發(fā)現(xiàn)的MapReduce);那邊 廂，Hortonworks加入了Spark陣營。在Cloudera和Hortonworks之間，“Hadoop”集群中唯一可以確信的項目就是 ? YARN。但是Databricks(又叫Spark人)偏愛Mesos而不是YARN;順便說一句，Spark不需要HDFS。
不過，分布式文件系統(tǒng)依然有用。對Cloudera的Impala來說，商業(yè)智能是一種理想的使用場合;而分布式列式存儲系統(tǒng)Kudu針對商業(yè)智能 進(jìn)行了優(yōu)化。Spark很適合處理許多任務(wù)，但有時候你需要像Impala這樣的大規(guī)模并行處理(MPP)解決方案來達(dá)到目的，而Hive仍是一種有用的 文件到表管理系統(tǒng)。即使你因為專注于Spark的內(nèi)存中實時分析技術(shù)而沒有使用Hadoop，到頭來仍可能到處使用Hadoop的部分。
Hadoop絕對沒有消亡，不過我確信，知名研究機(jī)構(gòu)Gartner的下一篇文章會這么認(rèn)為。但Hadoop絕不再是原來的Hadoop。
現(xiàn)在你需要知道這個新的Hadoop/Spark生態(tài)圈里面有什么?我在去年探討過這個話題，但出現(xiàn)了許多新氣象，這回我?guī)缀鯊念^開始來介紹。
1.?Spark
Spark的運行速度正如其名；更重要的是，API用起來容易得多，所需的代碼比之前的分布式計算模式來得少。IBM承諾會培訓(xùn)100萬名新的 ? Spark開發(fā)人員，為這個項目備好了龐大資金，Cloudera宣布Spark是我們知道與其一個平臺(One ? Platform)計劃配套的所有項目的核心，加上Hortonworks全力支持Spark，鑒于這種形勢，我們可以肯定地說，業(yè)界已將“技術(shù)環(huán)球小 姐”(Tech ?Miss Universe)這頂桂冠授予了Spark(但愿這回沒有弄錯)。
成本因素也在推動Spark迅猛崛起。過去在內(nèi)存中分析數(shù)據(jù)成本高昂，但由了云計算和更高的計算彈性，無法裝入到內(nèi)存(至少在分布式計算集群上)中的工作負(fù)載的數(shù)量在日益減少。同樣，我們談?wù)摰牟皇悄愕乃袛?shù)據(jù)，而是為了計算結(jié)果而需要的一小部分?jǐn)?shù)據(jù)。
Spark仍然不盡如人意――如果在生產(chǎn)環(huán)境中使用它，我們確實看到了這一幕，但是缺點值得忍受。Spark其實速度快得多，而且完全有了改進(jìn)。
具有諷刺意味的是，Spark方面動靜最大的恰恰與流數(shù)據(jù)有關(guān)，而這是Spark的最大軟肋。Cloudera宣布旨在讓Spark流數(shù)據(jù)技術(shù) 適用于80%的使用場合，就考慮到了這一缺陷。不過，你可能仍需要探究替代方案，以實現(xiàn)亞秒級或大容量的數(shù)據(jù)獲取(而不是數(shù)據(jù)分析)。
Spark不僅避免了需要MapReduce和Tez，還可能避免了Pig之類的工具。此外，Spark的RDD/DataFrames ? API并不是進(jìn)行抽取、轉(zhuǎn)換和加載(ETL)及其他數(shù)據(jù)轉(zhuǎn)換的糟糕方法。與此同時，Tableau及其他數(shù)據(jù)可視化廠商已宣布打算直接支持Spark。
2. Hive
Hive讓你可以對文本文件或結(jié)構(gòu)化文件執(zhí)行SQL查詢。那些文件通常駐留在HDFS上，這時你可以使用Hive，Hive可以將文件編入目錄，并暴露文件，好像它們就是表。你常用的SQL工具可以通過JDBC或ODBC連接到Hive。
簡而言之，Hive是一個乏味、緩慢但又有用的工具。默認(rèn)情況下，它將SQL任務(wù)轉(zhuǎn)換成MapReduce任務(wù)。你可以切換它，使用基于DAG的Tez，而Tez的速度快得多。還可以切換它，使用Spark，不過“alpha”這個詞無法體現(xiàn)真正體驗。
你需要知道Hive，因為許多Hadoop項目一開始“就讓我們將數(shù)據(jù)轉(zhuǎn)儲到某個地方”，然后“順便提一下，我們想在常用的SQL圖表工具中看看數(shù)據(jù)。”Hive是最直觀簡單的辦法。如果你想高效地查看數(shù)據(jù)，可能需要其他工具(比如Phoenix或Impala)。
3. Kerberos
我討厭Kerberos，它也不是那么喜歡我。遺憾的是，它又是唯一為Hadoop全面實施的驗證技術(shù)。你可以使用Ranger或Sentry等工具來減少麻煩，不過仍可能要通過Kerberos與活動目錄進(jìn)行集成。
4. Ranger/Sentry
如果你不使用Ranger或Sentry，那么大數(shù)據(jù)平臺的每一個部分都將進(jìn)行自己的驗證和授權(quán)。不會有集中控制，每個部分都會以自己的獨特方式看世界。
那么該選擇哪一個：Ranger還是Sentry?這么說吧，眼下Ranger似乎有點領(lǐng)先，較為全面，不過它是Hortonworks的產(chǎn)物。 Sentry則是Cloudera的產(chǎn)物。各自支持Hadoop堆棧中相應(yīng)廠商支持的那一部分。如果你沒打算獲得Cloudera或 ? Hortonworks的支持，那么我要說，Ranger是眼下更勝一籌的解決方案。然而，Cloudera走在Spark的前面，該公司還宣布了安全方 面的重大計劃，作為“一個平臺”戰(zhàn)略的一部分，這勢必會讓Sentry處于領(lǐng)先。(坦率地說，如果Apache運作正常，它會對這兩家廠商施加壓力，共同 開發(fā)一款解決方案。)
5. HBase/Phoenix
HBase是一種完全可以接受的列式數(shù)據(jù)存儲系統(tǒng)。它還內(nèi)置到你常用的Hadoop發(fā)行版中，它得到Ambari的支持，與Hive可以順暢地連 接。如果你添加Phoenix，甚至可以使用常用的商業(yè)智能工具來查詢HBase，好像它就是SQL數(shù)據(jù)庫。如果你通過Kafka和Spark或 ? Storm獲取流數(shù)據(jù)，那么HBase就是合理的著陸點，以便該數(shù)據(jù)持久化，至少保持到你對它進(jìn)行別的操作。
使用Cassandra之類的替代方案有充分理由。但如果你使用Hadoop，那就已經(jīng)有了HBase――如果你向Hadoop廠商購買支持服務(wù)， 已經(jīng)有了支持HBase的功能――所以這是個良好的起點。畢竟，它是一種低延遲、持久化的數(shù)據(jù)存儲系統(tǒng)，為原子性、一致性、隔離性和持久性(ACID)提 供了相當(dāng)給力的支持。如果Hive和Impala的SQL性能沒有引起你的興趣，你會發(fā)現(xiàn)HBase和Phoenix處理一些數(shù)據(jù)集比較快。
6. Impala
Teradata和Netezza使用MPP來處理跨分布式存儲的SQL查詢。Impala實際上是基于HDFS的一種MPP解決方案。
Impala和Hive之間的最大區(qū)別在于，你連接常用的商業(yè)智能工具時，“平常事務(wù)”會在幾秒鐘內(nèi)運行，而不是幾分鐘內(nèi)運行。Impala在許多 應(yīng)用場合可以取代Teradata和Netezza。對不同類型的查詢或分析而言，其他結(jié)構(gòu)可能必不可少(針對這種情況，可著眼于Kylin和 ? Phoenix之類的技術(shù))。但通常來說，Impala讓你可以避開討厭的專有MPP系統(tǒng)，使用單一平臺來分析結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)，甚至部署到云端。
這與使用正宗的Hive存在諸多重疊，但I(xiàn)mpala和Hive的操作方式不一樣，有著不同的最佳適用場合。Impala得到Cloudera的支 持，但未得到Hortonworks的支持，Hortonworks改而支持Phoenix。雖然運行Impala不太復(fù)雜，但是你使用Phoenix可 以實現(xiàn)同樣的一些目標(biāo)，Cloudera現(xiàn)正將注意力轉(zhuǎn)向Phoenix。
7. HDFS(Hadoop分布式文件系統(tǒng))
由于Spark大行其道，所謂的大數(shù)據(jù)項目不斷遷移到云端，HDFS不如去年來得重要。但是它仍然是默認(rèn)技術(shù)，也是概念上比較簡單的實現(xiàn)分布式文件系統(tǒng)的技術(shù)之一。
8. Kafka
分布式消息系統(tǒng)(如Kafka提供的系統(tǒng))會完全淘汰像ActiveMQ這樣的客戶機(jī)/服務(wù)器工具。即便Kafka沒有用在大多數(shù)流數(shù)據(jù)項目上，至 少也用在許多流數(shù)據(jù)項目。它也很簡單。如果你使用其他消息傳遞工具，會覺得它有點原始簡陋，但在大多數(shù)情況下，你無論如何也不需要MQ類解決方案提供的細(xì) 粒度路由選項。
9. Storm/Apex
Spark處理流數(shù)據(jù)不是很擅長，但是Storm如何呢?它速度更快，延遲更低，而且耗用更少的內(nèi)存――大規(guī)模獲取流數(shù)據(jù)時，這點很重要。另一方 面，Storm的管理工具較為遜色，API也不如Spark的API一樣好。Apex更新更好，但還沒有得到廣泛部署。我仍會在默認(rèn)情況下選擇Spark ?處理不需要亞秒級的任何事務(wù)。
10. Ambari / Cloudera Manager
我見過有人不用Ambari或Cloudera ? Manager，試著監(jiān)視和管理Hadoop集群。效果不好。這兩種解決方案在比較短的時間里，讓Hadoop環(huán)境的管理和監(jiān)控功能取得了長足發(fā)展。不妨 與NoSQL領(lǐng)域作個比較：NoSQL領(lǐng)域在這方面遠(yuǎn)遠(yuǎn)不如Hadoop一樣先進(jìn)，盡管用的是更簡單的軟件，組件數(shù)量少得多，你肯定很想知道那些 ? NoSQL人員把大量資金究竟花在了哪里。
11. Pig
我想這恐怕是Pig最后一年上我的名單。Spark的速度快得多，可以用于許多同樣的ETL場合，而Pig ?Latin(沒錯，他們就是這么稱呼這門語言的)有點怪異，而且常常令人沮喪。正如你想象，在Spark上運行Pig需要費老大的勁。
從理論上來說，在Hive上執(zhí)行SQL的人可以改用Pig，就像他們過去由SQL改用PL/SQL那樣，但事實上，Pig不如PL/SQL來得簡 單。介于普通SQL和正宗Spark之間的技術(shù)可能還有生存余地，但我認(rèn)為Pig不是這種技術(shù)。來自另一個方向的是Apache ? Nifi，這讓你可以做一些同樣的ETL，但是少用或不用代碼。我們已經(jīng)使用Kettle減少了編寫的ETL代碼數(shù)量，這相當(dāng)棒。
12. YARN/ Mesos
YARN和Mesos讓你能夠跨集群執(zhí)行任務(wù)隊列和調(diào)度操作。每個人都在嘗試各種方法：Spark到Y(jié)ARN、Spark到Mesos、Spark ?到Y(jié)ARN到Mesos，等等。但要知道，Spark的獨立模式對于忙碌的多任務(wù)多用戶集群來說不是很切實際。如果你不專門使用Spark，仍運行 Hadoop批處理任務(wù)，那么眼下就選擇YARN。
13. Nifi /Kettle
Nifi將不得不竭力避免僅僅是Oozie的改進(jìn)版。諸多廠商聲稱Nifi是物聯(lián)網(wǎng)的解決之道，不過那是營銷聲勢而已。實際上，Nifi好比為 ? Hadoop與Spring整合。你需要通過轉(zhuǎn)換和隊列來管道傳輸數(shù)據(jù)，然后按時間表將數(shù)據(jù)放在某個地方――或者基于觸發(fā)器，處理來自諸多來源的數(shù)據(jù)。添 加一個漂亮的圖形用戶界面(GUI)，Nifi就成了。其魅力在于，有人為它編寫了一大批的連接件。
如果今天你需要這個，但想要更成熟一點的技術(shù)，不妨使用Pentaho公司的Kettle(以及其他相關(guān)工具，比如Spoon)。這些工具在生產(chǎn)環(huán)境中頗有成效已有一段時間。我們用過它們。坦率地說，它們很不賴。
14. Knox
雖然Knox是很強(qiáng)大的邊緣保護(hù)機(jī)制，但它的作用就是，為用Java編寫的反向代理系統(tǒng)提供驗證。它不是寫得很好;舉例說，它掩蓋了錯誤。另外，盡管它使用了URL重寫，但僅僅在后面添加一個新服務(wù)就需要完整的Java實現(xiàn)。
你需要知道Knox，因為如果有人想要邊緣保護(hù)，這是提供這種保護(hù)的“欽定”方式。坦率地說，要是有小小的修改，或者面向HTTPD的mod_proxy的附件，它會更實用，并提供一系列更廣泛的驗證選項。
15. Scala/ Python
從技術(shù)上來說，你可以用Java 8處理Spark或Hadoop任務(wù)。但實際上，支持Java ? 8是事后添加的功能，那樣銷售人員可以告訴大公司它們?nèi)钥梢岳迷瓉淼腏ava開發(fā)人員。事實上，Java ? 8是一門新語言，如果你使用得當(dāng)?shù)脑挩D―在在種情況下，我認(rèn)為Java 8拙劣地模仿Scala。
尤其是對Spark而言，Java落后于Scala，可能甚至落后于Python。本人其實并不喜歡Python，但它得到了Spark及其他工具 相當(dāng)有力的支持。它還有成熟的代碼庫;就許多數(shù)據(jù)科學(xué)、機(jī)器學(xué)習(xí)和統(tǒng)計應(yīng)用而言，它將是首選語言。Scala是Spark的第一選擇，也越來越多是其他工 具集的第一選擇。對于“偏運算”的數(shù)據(jù)，你可能需要Python或R，因為它們的代碼庫很強(qiáng)大。
記住：如果你用Java 7編寫任務(wù)，那太傻了。如果使用Java 8，那是由于有人對你老板撒了謊。
16. Zeppelin/ Databricks
大多數(shù)人在iPython ?Notebook中首次碰到的Notebook概念很流行。編寫一些SQL或Spark代碼以及描述代碼的一些標(biāo)記，添加一個圖形，動態(tài)執(zhí)行，然后保存起來，那樣別人就能從你的結(jié)果獲得一些東西。
最終，你的數(shù)據(jù)被記錄并執(zhí)行，圖表很漂亮!
Databricks有良好的開端，自我上一次表示對它膩味以來，其解決方案已經(jīng)成熟起來。另一方面，Zeppelin是開源的，沒必要非得從Databricks購買云服務(wù)。你應(yīng)該知道其中一款這樣的工具。學(xué)會一款，學(xué)另一款不會太費勁。
值得關(guān)注的新技術(shù)
我還不會將這些技術(shù)應(yīng)用到生產(chǎn)環(huán)境，但是一定要了解它們。
Kylin：一些 查詢需要更低的延遲，于是你一頭有HBase;另一頭，更龐大的分析查詢可能不適合HBase――因此另一頭使用 ? Hive。此外，一再合并幾個表來計算結(jié)果速度緩慢，所以“預(yù)合并”(prejoining)和“預(yù)計算”( ? precalculating)這些數(shù)據(jù)處理成數(shù)據(jù)立方(Cube)對這類數(shù)據(jù)集來說是一大優(yōu)勢。這時候，Kylin有了用武之地。
Kylin是今年的后起之秀。我們已經(jīng)看到有人將Kylin用于生產(chǎn)環(huán)境，不過我建議還是謹(jǐn)慎一點為好。因為Kylin并不適用于一切，其采用也不如Spark來得廣泛，但是Kylin也受到同樣熱烈的追捧。眼下，你對它應(yīng)該至少了解一點。
Atlas/Navigator：Atlas 是Hortonworks新的數(shù)據(jù)治理工具。它甚至還談不上完全成熟，不過正取得進(jìn)展。我預(yù)計它可能會超過Cloudera的Navigator，但如果 歷史重演的話，它會有一個不太花哨的GUI。如果你需要知道某個表的世系，或者沒必要逐列(tagging)地映射安全，那么Atlas或 Navigator可能正是你需要的工具。如今治理是個熱門話題。你應(yīng)該知道這其中一項新技術(shù)的功能。
我寧愿遺忘的技術(shù)
下面是我會很高興地扔到窗外的技術(shù)。我之所以這么任性，是因為已出現(xiàn)了更出色地執(zhí)行同一功能的新技術(shù)。
Oozie：在去 年的All Things Open大會上，來自Cloudera的Ricky ? Saltzer為Oozie辯護(hù)，說它適用于原本旨在處理的任務(wù)――也就是把幾個MapReduce任務(wù)串連起來;人們對于Oozie頗為不滿是要求過 高。我仍要說，Oozie一無是處。
不妨舉例說明：隱藏錯誤，功能不是失靈就是與文檔描述的不一樣、XML錯誤方面的說明文檔完全不正確、支離破碎的驗證器，不一而足。Oozie完全 自吹自擂。它寫得很差勁;要是哪里出了問題，連基本的任務(wù)都會變成需要一周才搞得定。由于Nifi及其他工具取而代之，我沒指望會大量使用Oozie。
MapReduce：Hadoop的這個處理核心在漸行漸遠(yuǎn)。DAG算法可以更有效地利用資源。Spark使用更好的API在內(nèi)存中處理數(shù)據(jù)。由于內(nèi)存變得越來越便宜，向云計算遷移的步伐加快，支持繼續(xù)使用MapReduce的成本原因漸漸站不住腳。
Tez：從某種程度上說，Tez是條沒人走的路――或者說是分布式計算這棵進(jìn)化樹上早已過時的分支。與Spark一樣，它也是一種DAG算法，不過有個開發(fā)人員稱之為是匯編語言。
與MapReduce一樣，使用Tez的成本原因(磁盤與內(nèi)存)漸漸站不住腳。繼續(xù)使用它的主要原因是：面向一些流行Hadoop工具的Spark ? 綁定不太成熟，或者根本就沒有準(zhǔn)備好。然而，由于Hortonworks加入了向Spark靠攏的陣營，Tez到年底之前似乎不太可能有一席之地。要是你 現(xiàn)在不知道Tez，也不用心煩。
現(xiàn)在是大好時機(jī)
Hadoop/Spark領(lǐng)域在不斷變化。盡管存在一些碎片化現(xiàn)象，不過隨著圍繞Spark的生態(tài)圈日益穩(wěn)固，核心會變得穩(wěn)定得多。
下一大增長點將來自治理和技術(shù)的應(yīng)用，以及讓云計算化(cloudification)和容器化更容易管理、更簡單的工具。這類進(jìn)步給錯過第一波熱潮的廠商帶來了大好機(jī)會。
如果你還沒有采用大數(shù)據(jù)技術(shù)，眼下正是趁機(jī)進(jìn)入的大好時機(jī)。發(fā)展太快了，啥時行動永遠(yuǎn)不會太晚。同時，主攻遺留MPP立方數(shù)據(jù)分析平臺的廠商應(yīng)該作好被顛覆的準(zhǔn)備。
文章來源：云頭條
本文轉(zhuǎn)自UltraSQL51CTO博客，原文鏈接：http://blog.51cto.com/ultrasql/1834457?，如需轉(zhuǎn)載請自行聯(lián)系原作者
總結(jié)
以上是生活随笔為你收集整理的Hadoop/Spark生态圈里的新气象的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： springMVC简单实例
- 下一篇： JMM和happens-before原则