2018-05-29 15:39:03 1708瀏覽
Hadoop在短短的一年的時(shí)間里火爆了生態(tài)圈，如今越來越多的人想要了解學(xué)習(xí)Hadoop，本篇文章扣丁學(xué)堂大數(shù)據(jù)培訓(xùn)小編就給大家分享一下Hadoop/Spark生態(tài)圈里的新氣象，讓大家能更進(jìn)一步的了解Hadoop。
1、Spark
Spark的運(yùn)行速度正如其名;更重要的是，API用起來容易得多，所需的代碼比之前的分布式計(jì)算模式來得少。IBM承諾會(huì)培訓(xùn)100萬名新的 Spark開發(fā)人員，為這個(gè)項(xiàng)目備好了龐大資金，Cloudera宣布Spark是我們知道與其一個(gè)平臺(tái)(One Platform)計(jì)劃配套的所有項(xiàng)目的核心，加上Hortonworks全力支持Spark，鑒于這種形勢(shì)，我們可以肯定地說，業(yè)界已將“技術(shù)環(huán)球小姐”(Tech Miss Universe)這頂桂冠授予了Spark(但愿這回沒有弄錯(cuò))。
成本因素也在推動(dòng)Spark迅猛崛起。過去在內(nèi)存中分析數(shù)據(jù)成本高昂，但由了云計(jì)算和更高的計(jì)算彈性，無法裝入到內(nèi)存(至少在分布式計(jì)算集群上)中的工作負(fù)載的數(shù)量在日益減少。同樣，我們談?wù)摰牟皇悄愕乃袛?shù)據(jù)，而是為了計(jì)算結(jié)果而需要的一小部分?jǐn)?shù)據(jù)。
Spark仍然不盡如人意――如果在生產(chǎn)環(huán)境中使用它，我們確實(shí)看到了這一幕，但是缺點(diǎn)值得忍受。Spark其實(shí)速度快得多，而且完全有了改進(jìn)。
具有諷刺意味的 是，Spark方面動(dòng)靜最大的恰恰與流數(shù)據(jù)有關(guān)，而這是Spark的最大軟肋。Cloudera宣布旨在讓Spark流數(shù)據(jù)技術(shù)適用于80%的使用場(chǎng)合，就考慮到了這一缺陷。不過，你可能仍需要探究替代方案，以實(shí)現(xiàn)亞秒級(jí)或大容量的數(shù)據(jù)獲取(而不是數(shù)據(jù)分析)。
Spark不僅避免了需要MapReduce和Tez，還可能避免了Pig之類的工具。此外，Spark的RDD/DataFrames API并不是進(jìn)行抽取、轉(zhuǎn)換和加載(ETL)及其他數(shù)據(jù)轉(zhuǎn)換的糟糕方法。與此同時(shí)，Tableau及其他數(shù)據(jù)可視化廠商已宣布打算直接支持Spark。
2、Hive
Hive讓你可以對(duì)文本文件或結(jié)構(gòu)化文件執(zhí)行SQL查詢。那些文件通常駐留在HDFS上，這時(shí)你可以使用Hive，Hive可以將文件編入目錄，并暴露文件，好像它們就是表。你常用的SQL工具可以通過JDBC或ODBC連接到Hive。
簡而言之，Hive是一個(gè)乏味、緩慢但又有用的工具。默認(rèn)情況下，它將SQL任務(wù)轉(zhuǎn)換成MapReduce任務(wù)。你可以切換它，使用基于DAG的Tez，而Tez的速度快得多。還可以切換它，使用Spark，不過“alpha”這個(gè)詞無法體現(xiàn)真正體驗(yàn)。
你需要知道Hive，因?yàn)樵S多Hadoop項(xiàng)目一開始“就讓我們將數(shù)據(jù)轉(zhuǎn)儲(chǔ)到某個(gè)地方”，然后“順便提一下，我們想在常用的SQL圖表工具中看看數(shù)據(jù)?！盚ive是最直觀簡單的辦法。如果你想高效地查看數(shù)據(jù)，可能需要其他工具(比如Phoenix或Impala)。
3、Kerberos
我討厭Kerberos，它也不是那么喜歡我。遺憾的是，它又是唯一為Hadoop全面實(shí)施的驗(yàn)證技術(shù)。你可以使用Ranger或Sentry等工具來減少麻煩，不過仍可能要通過Kerberos與活動(dòng)目錄進(jìn)行集成。
4、Ranger/Sentry
如果你不使用Ranger或Sentry，那么大數(shù)據(jù)平臺(tái)的每一個(gè)部分都將進(jìn)行自己的驗(yàn)證和授權(quán)。不會(huì)有集中控制，每個(gè)部分都會(huì)以自己的獨(dú)特方式看世界。
那么該選擇哪一個(gè)：Ranger還是Sentry?這么說吧，眼下Ranger似乎有點(diǎn)領(lǐng)先，較為全面，不過它是Hortonworks的產(chǎn)物。 Sentry則是Cloudera的產(chǎn)物。各自支持Hadoop堆棧中相應(yīng)廠商支持的那一部分。如果你沒打算獲得Cloudera或 Hortonworks的支持，那么我要說，Ranger是眼下更勝一籌的解決方案。然而，Cloudera走在Spark的前面，該公司還宣布了安全方面的重大計(jì)劃，作為“一個(gè)平臺(tái)”戰(zhàn)略的一部分，這勢(shì)必會(huì)讓Sentry處于領(lǐng)先。(坦率地說，如果Apache運(yùn)作正常，它會(huì)對(duì)這兩家廠商施加壓力，共同開發(fā)一款解決方案。)
5、HBase/Phoenix
HBase是一種完全可以接受的列式數(shù)據(jù)存儲(chǔ)系統(tǒng)。它還內(nèi)置到你常用的Hadoop發(fā)行版中，它得到Ambari的支持，與Hive可以順暢地連接。如果你添加Phoenix，甚至可以使用常用的商業(yè)智能工具來查詢HBase，好像它就是SQL數(shù)據(jù)庫。如果你通過Kafka和Spark或 Storm獲取流數(shù)據(jù)，那么HBase就是合理的著陸點(diǎn)，以便該數(shù)據(jù)持久化，至少保持到你對(duì)它進(jìn)行別的操作。
使用Cassandra之類的替代方案有充分理由。但如果你使用Hadoop，那就已經(jīng)有了HBase――如果你向Hadoop廠商購買支持服務(wù)，已經(jīng)有了支持HBase的功能――所以這是個(gè)良好的起點(diǎn)。畢竟，它是一種低延遲、持久化的數(shù)據(jù)存儲(chǔ)系統(tǒng)，為原子性、一致性、隔離性和持久性(ACID)提供了相當(dāng)給力的支持。如果Hive和Impala的SQL性能沒有引起你的興趣，你會(huì)發(fā)現(xiàn)HBase和Phoenix處理一些數(shù)據(jù)集比較快。
6、Impala
Teradata和Netezza使用MPP來處理跨分布式存儲(chǔ)的SQL查詢。Impala實(shí)際上是基于HDFS的一種MPP解決方案。
Impala和Hive之間的最大區(qū)別在于，你連接常用的商業(yè)智能工具時(shí)，“平常事務(wù)”會(huì)在幾秒鐘內(nèi)運(yùn)行，而不是幾分鐘內(nèi)運(yùn)行。Impala在許多應(yīng)用場(chǎng)合可以取代Teradata和Netezza。對(duì)不同類型的查詢或分析而言，其他結(jié)構(gòu)可能必不可少(針對(duì)這種情況，可著眼于Kylin和 Phoenix之類的技術(shù))。但通常來說，Impala讓你可以避開討厭的專有MPP系統(tǒng)，使用單一平臺(tái)來分析結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)，甚至部署到云端。
這與使用正宗的Hive存在諸多重疊，但I(xiàn)mpala和Hive的操作方式不一樣，有著不同的最佳適用場(chǎng)合。Impala得到Cloudera的支持，但未得到Hortonworks的支持，Hortonworks改而支持Phoenix。雖然運(yùn)行Impala不太復(fù)雜，但是你使用Phoenix可以實(shí)現(xiàn)同樣的一些目標(biāo)，Cloudera現(xiàn)正將注意力轉(zhuǎn)向Phoenix。
7、HDFS(Hadoop分布式文件系統(tǒng))
由于Spark大行其道，所謂的大數(shù)據(jù)項(xiàng)目不斷遷移到云端，HDFS不如去年來得重要。但是它仍然是默認(rèn)技術(shù)，也是概念上比較簡單的實(shí)現(xiàn)分布式文件系統(tǒng)的技術(shù)之一。
8、Kafka
分布式消息系統(tǒng)(如Kafka提供的系統(tǒng))會(huì)完全淘汰像ActiveMQ這樣的客戶機(jī)/服務(wù)器工具。即便Kafka沒有用在大多數(shù)流數(shù)據(jù)項(xiàng)目上，至少也用在許多流數(shù)據(jù)項(xiàng)目。它也很簡單。如果你使用其他消息傳遞工具，會(huì)覺得它有點(diǎn)原始簡陋，但在大多數(shù)情況下，你無論如何也不需要MQ類解決方案提供的細(xì)粒度路由選項(xiàng)。
9、Storm/Apex
Spark處理流數(shù)據(jù)不是很擅長，但是Storm如何呢?它速度更快，延遲更低，而且耗用更少的內(nèi)存――大規(guī)模獲取流數(shù)據(jù)時(shí)，這點(diǎn)很重要。另一方面，Storm的管理工具較為遜色，API也不如Spark的API一樣好。Apex更新更好，但還沒有得到廣泛部署。我仍會(huì)在默認(rèn)情況下選擇Spark 處理不需要亞秒級(jí)的任何事務(wù)。
10、Ambari / Cloudera Manager
我見過有人不用Ambari或Cloudera Manager，試著監(jiān)視和管理Hadoop集群。效果不好。這兩種解決方案在比較短的時(shí)間里，讓Hadoop環(huán)境的管理和監(jiān)控功能取得了長足發(fā)展。不妨與NoSQL領(lǐng)域作個(gè)比較：NoSQL領(lǐng)域在這方面遠(yuǎn)遠(yuǎn)不如Hadoop一樣先進(jìn)，盡管用的是更簡單的軟件，組件數(shù)量少得多，你肯定很想知道那些 NoSQL人員把大量資金究竟花在了哪里。
11、Pig
我想這恐怕是Pig最后一年上我的名單。Spark的速度快得多，可以用于許多同樣的ETL場(chǎng)合，而Pig Latin(沒錯(cuò)，他們就是這么稱呼這門語言的)有點(diǎn)怪異，而且常常令人沮喪。正如你想象，在Spark上運(yùn)行Pig需要費(fèi)老大的勁。
從理論上來說，在Hive上執(zhí)行SQL的人可以改用Pig，就像他們過去由SQL改用PL/SQL那樣，但事實(shí)上，Pig不如PL/SQL來得簡單。介于普通SQL和正宗Spark之間的技術(shù)可能還有生存余地，但我認(rèn)為Pig不是這種技術(shù)。來自另一個(gè)方向的是Apache Nifi，這讓你可以做一些同樣的ETL，但是少用或不用代碼。我們已經(jīng)使用Kettle減少了編寫的ETL代碼數(shù)量，這相當(dāng)棒。
12、YARN/ Mesos
YARN和Mesos讓你能夠跨集群執(zhí)行任務(wù)隊(duì)列和調(diào)度操作。每個(gè)人都在嘗試各種方法：Spark到Y(jié)ARN、Spark到Mesos、Spark 到Y(jié)ARN到Mesos，等等。但要知道，Spark的獨(dú)立模式對(duì)于忙碌的多任務(wù)多用戶集群來說不是很切實(shí)際。如果你不專門使用Spark，仍運(yùn)行 Hadoop批處理任務(wù)，那么眼下就選擇YARN。
13、Nifi /Kettle
Nifi將不得不竭力避免僅僅是Oozie的改進(jìn)版。諸多廠商聲稱Nifi是物聯(lián)網(wǎng)的解決之道，不過那是營銷聲勢(shì)而已。實(shí)際上，Nifi好比為 Hadoop與Spring整合。你需要通過轉(zhuǎn)換和隊(duì)列來管道傳輸數(shù)據(jù)，然后按時(shí)間表將數(shù)據(jù)放在某個(gè)地方――或者基于觸發(fā)器，處理來自諸多來源的數(shù)據(jù)。添加一個(gè)漂亮的圖形用戶界面(GUI)，Nifi就成了。其魅力在于，有人為它編寫了一大批的連接件。
如果今天你需要這個(gè)，但想要更成熟一點(diǎn)的技術(shù)，不妨使用Pentaho公司的Kettle(以及其他相關(guān)工具，比如Spoon)。這些工具在生產(chǎn)環(huán)境中頗有成效已有一段時(shí)間。我們用過它們。坦率地說，它們很不賴。
14、Knox
雖然Knox是很強(qiáng)大的邊緣保護(hù)機(jī)制，但它的作用就是，為用Java編寫的反向代理系統(tǒng)提供驗(yàn)證。它不是寫得很好;舉例說，它掩蓋了錯(cuò)誤。另外，盡管它使用了URL重寫，但僅僅在后面添加一個(gè)新服務(wù)就需要完整的Java實(shí)現(xiàn)。
你需要知道Knox，因?yàn)槿绻腥讼胍吘壉Ｗo(hù)，這是提供這種保護(hù)的“欽定”方式。坦率地說，要是有小小的修改，或者面向HTTPD的mod_proxy的附件，它會(huì)更實(shí)用，并提供一系列更廣泛的驗(yàn)證選項(xiàng)。
15、Scala/ Python
從技術(shù)上來說，你可以用Java 8處理Spark或Hadoop任務(wù)。但實(shí)際上，支持Java 8是事后添加的功能，那樣銷售人員可以告訴大公司它們?nèi)钥梢岳迷瓉淼腏ava開發(fā)人員。事實(shí)上，Java 8是一門新語言，如果你使用得當(dāng)?shù)脑挩D―在在種情況下，我認(rèn)為Java 8拙劣地模仿Scala。
尤其是對(duì)Spark而言，Java落后于Scala，可能甚至落后于Python。本人其實(shí)并不喜歡Python，但它得到了Spark及其他工具相當(dāng)有力的支持。它還有成熟的代碼庫;就許多數(shù)據(jù)科學(xué)、機(jī)器學(xué)習(xí)和統(tǒng)計(jì)應(yīng)用而言，它將是首選語言。Scala是Spark的第一選擇，也越來越多是其他工具集的第一選擇。對(duì)于“偏運(yùn)算”的數(shù)據(jù)，你可能需要Python或R，因?yàn)樗鼈兊拇a庫很強(qiáng)大。
在以上就是扣丁學(xué)堂大數(shù)據(jù)在線學(xué)習(xí)小編給大家分享的Hadoop/Spark生態(tài)圈里的新氣象，希望對(duì)小伙伴們有所幫助，想要學(xué)習(xí)大數(shù)據(jù)的小伙伴可以登錄扣丁學(xué)堂官網(wǎng)查詢更多內(nèi)容?？鄱W(xué)堂不僅有專業(yè)的老師和與時(shí)俱進(jìn)的課程體系，還有大量的大數(shù)據(jù)在線教程供學(xué)員觀看學(xué)習(xí)，扣丁學(xué)堂是專業(yè)的大數(shù)據(jù)培訓(xùn)機(jī)構(gòu)?？鄱W(xué)堂大數(shù)據(jù)學(xué)習(xí)群：209080834。
【關(guān)注微信公眾號(hào)獲取更多學(xué)習(xí)資料】
查看更多關(guān)于“大數(shù)據(jù)培訓(xùn)資訊”的相關(guān)文章>>
全國免費(fèi)咨詢熱線
郵箱：codingke@1000phone.com
官方群：148715490
返回頂部