有哪些大數據處理工具?

雲棲號資訊:【點擊查看更多行業資訊
在這裏您可以找到不同行業的第一手的上雲資訊,還在等什麼,快來!

image

阿里妹導讀:近幾年裏,大數據行業發展勢頭迅猛,故而相應的分佈式產品和架構層出不窮,本文分享作者在大數據系統實踐過程中接觸過的一些工具及使用感受,拋磚引玉,和同學們一起構建一個分佈式產品的全景圖。

下圖是由著名的數據觀察家Matt Turck在他的BLOG(https://mattturck.com/)裏發出的2019年人工智能和大數據產業圖,他從2012年開始每年都會繪製一張,大致描述這個產業裏的公司及其數據相關的產品,以及所屬問題的領域。這裏面大部分是商業軟件,而對於絕大多數互聯網公司,中間綠色的開源產品可能大家接觸的更多一些,而這些產品裏,絕大多數都屬於Apache基金會。

image

下面我從中挑選一些東西隨便聊聊,因爲是隨便聊聊,所以知識點並不全,也不能幫助大家知道如何搭建和使用,以及如何避坑,只是談談我對這些東西的印象,描述一個大概的輪廓,如有使用需求可以搜索網上其它文章,資料還是很多的。當然,大家對其中的內容有興趣可以隨時找我交流討論,對文中如有描述錯誤的地方也歡迎大家斧正,共同學習,謝謝。

Apache Hadoop

官網:http://hadoop.apache.org/

Hadoop項目下包含了很多子項目,從計算到存儲都有,比如HDFS、MapReduce、YARN、HBase。

HDFS全稱叫做Hadoop分佈式文件系統,其主要由一個NameNode(NN)和多個DataNode(DN)組成,數據文件會分成多個Block,這些Block按照不同主機,不同機架的策略以默認一備三的情況分佈存儲在各個節點。現在每個Block大小默認是128MB,以後隨着磁盤尋址速度的增加,這個Block也會不斷增大。而NN裏面則存儲了這些Block元數據的信息,這樣客戶端進行數據查詢的時候,DN告知所需數據的位置。從這種結構上能看出一些比較明顯的問題就是NN節點的單點問題,所以在Hadoop 2.x的時候,針對NN做了一些改進。

image

首先是在系統可用性上,增加了一個StandBy狀態的NN,作爲服務中NN(Active NN)的備機,當服務中的NN掛掉後,由StandBy的NN自動接替工作。而NN節點狀態的健康和服務切換,由ZKFC負責。主備NN之間的信息同步則由Quorum Journal Node負責。

其次,由於單臺NN中存儲了大量的元數據信息,所以隨着HDFS數據量的不斷增加,顯然NN必將成爲系統的瓶頸,爲了解決這個問題,Hadoop 2.x增加了Federation,該技術允許系統中有多臺NN同時對外提供服務,這多臺NN將DN中的所有文件路徑進行了橫向拆分,每個DN負責不同的路徑,達到了橫向擴展的效果。

除了HDFS,Hadoop 2.x也引入了YARN,該工具負責對集羣中的資源進行管理和任務的協調。該工具分成一個ResourceManager(RM)和多個NodeManager(NM),當一個任務提交給YARN之後,會先在某一服務器上啓動一個ApplicationMaster(AM),AM向RM申請資源,RM通過NM尋找集羣中空閒的資源,NM將資源打包成一個個Container,交給AM。AM將數據和程序分發到對應節點上處理,如果某個Container中的任務執行失敗了,AM會重新向RM申請新的Container。

Apache Hadoop HBase & Kudu

官網:http://hbase.apache.org/

image

衆所周知,HBase一個分佈式列式存儲系統,同樣屬於Hadoop的子項目,列式存儲的優劣在這裏不說了,提一下HBase的WAL和LSM,WAL全稱爲Write Ahead Log,只是在數據修改操作前,會先將此操作記錄在日誌中,這樣一旦服務崩潰,通過該日誌即可進行數據的恢復,提到這裏有些人就會聯想到MySQL,因爲InnoDB引擎的redo log就是典型的WAL應用。而在HBase中該功能是由叫做HLog的模塊所完成的。再說LSM,其全稱爲Log Structured Merge Trees,介紹原理的文章也有很多,在HBase中,LSM樹是MemStore模塊的底層存儲結構,而MemStore有三個作用,一是當有數據寫入的時候,直接寫到MemStore中,從而提升寫數據的效率。二是充當讀取數據時的緩存。三是定期對數據操作去重,並進行數據落盤。HBase的主要角色分別有HMaster和HRegionServer,同樣是一對多的關係,而各節點的狀態全都交由Zookeeper負責。Kudu是一個和HBase非常類似的產品,其不同之處在於Kudu不依賴Zookeeper來管理自己的集羣,並且HBase的數據是保存在HDFS上的,而Kudu擁有自己的數據文件格式。

Apache Spark

官網:https://spark.apache.org/

Spark是由加州大學伯克利分校推出的分佈式計算引擎,在Spark的官方主頁上有一張和Hadoop的性能對比圖,姑且不談這張圖中數據的準確性,但是Spark的確將Hadoop(主要是指MapReduce)的性能提升了一個量級。我理解這主要得益於兩個方面:第一個是Spark計算過程中生成的中間數據不再落盤,沒有了Spill的階段。第二個是引入DAG對任務進行拆解,一個完整的Job被分成多個Stage,每個Stage裏面又有多個Task,通過一張有向無環圖,使得沒有依賴關係的Task可以並行運行。

Spark不只是在批處理上有所成績,而是更加註重整個生態圈的建設,其擁有流式處理框架SparkStreaming,採用微批的形式達到類似流處理的效果,現在又推出了Structured Streaming,實現基於狀態的流處理框架。此外還擁有SparkSQL來幫助非開發人員更加便捷的調用Spark的服務和Spark MLlib這個機器學習庫。

Spark雖好,但其對內存資源消耗也很大,同時也使得他在穩定性上不如MapReduce,所以有些大公司數倉的日常任務仍舊採用傳統MapReduce的方式執行,不求最快,但求最穩。我們的系統在剛從MapReduce上切到Spark時,每天夜裏也是任務異常頻發,最後調整了任務和資源分配,再加上一個很粗暴的重試機制解決了。

Apache Flink

官網:https://flink.apache.org/

Flink是德國Data Artisans公司開發一款分佈式計算系統,該公司於19年初被阿里巴巴集團收購。包括Spark和Kafka,也都看到了未來流式計算的前景是非常巨大的,紛紛建立屬於自己的流式計算生態圈。

Flink和Spark Streaming相比,前者是真正的流式計算,而後者是微批處理,雖然批次足夠小,但其本質畢竟還是批處理,這就導致有些場景SparkStreaming註定無法滿足,雖然Spark現在將重心轉移到了Structured Streaming,它彌補了Spark Streaming很多的不足,但是在處理流程上仍然是微批處理。

image

而Flink在設計之初就同時考慮了批處理和流處理這兩種需求,所以使用者也可以只通過一個計算引擎,就能實現批處理和流處理兩種計算場景,其主要幾個需要清楚的特性我覺得分別是:State狀態管理,CheckPoint容錯機制,Window滑動窗口,和Watermark亂序解決。這些內容網上都有很多介紹,不再闡述。

Apache Impala

官網:https://impala.apache.org/

Impala是Cloudera公司用C++開發的支持SQL語義的查詢系統,可以用來查詢HDFS、HBase、Kudu的內容,也支持多種序列化和壓縮格式,因爲也是基於內存的計算,比傳統MapReduce快很多。不過因爲已經使用了Spark,所以組裏並沒有對Impala進行大規模的應用。經過一些零散的調研和了解,好像其它公司對Impala的應用也不是非常多。

Apache Zookeeper

官網:https://zookeeper.apache.org/

Zookeeper無論在數據系統還是在其它後端系統的使用場景都非常廣,它可以用作分佈式鎖服務,可以用做系統的配置中心,可以協助完成一致性算法的選主過程,可以用於ZKFC做節點健康情況的探查,總之用處還有很多。而它的工作機制,基本就是ZAB協議的機制,一個支持崩潰恢復的原子廣播協議,其主要組成也是由一個Leader和多個Follower組成的,數據的提交遵循2PC協議。當Leader崩潰時,Follower會自動切換狀態開始重新選主,重新選完之後再進行多節點的數據對齊。

Apache Sqoop

官網:https://sqoop.apache.org/

一款用於在傳統關係型數據庫和HDFS之間互相進行數據傳遞的工具,無論是import還是export都提供了大量的參數,因爲是分佈式執行,數據傳輸的速度也非常快。只是在使用的過程中需要注意數據源中的異常數據,會比較容易造成數據傳遞過程中的異常退出。爲了彌補Sqoop的功能單一,推出了Sqoop 2,架構上比Sqoop 1複雜了很多,不過我沒有用過。

Apache Flume

官網:http://flume.apache.org/

分佈式數據傳輸工具,支持包含文件、Netcat、JMS、HTTP在內的多種數據源。其結構上分成Source、Channel、Sink三部分,Source將獲取到的數據緩存在Channel中,這個Channel可以是文件,可以是內存,也可以使用JDBC,Sink從Channel消費數據,傳遞給系統中的其他模塊,比如HBase、HDFS、Kafka等等。

Apache Kafka

官網:http://kafka.apache.org/

曾經是一款由Scala開發的分佈式消息隊列產品,現在生態已經擴展了,因爲它推出了Kafka Streaming,所以現在也應該被稱作是一個流處理平臺了,但這裏不說Kafka Streaming,因爲沒有用過和了解過。

Kafka的隊列按照Topic劃分,每個Topic下由多個Partition組成,在單個Partition中的消息保證是有序的。這種結構下確保了消息是在磁盤順序寫入的,節省了磁盤尋址的時間,所以數據落盤的速度非常快。加之採用了mmap的方式,減少了用戶態和內核態之間的數據拷貝次數,mmap是一種將文件內容和內存地址映射的技術,提效十分明顯。Kafka和Flume的配合使用,形成了流式處理領域裏的經典框架。

Apache Ranger & Sentry

官網:http://ranger.apache.org/
官網:http://sentry.apache.org/

Ranger和Sentry都是分佈式的數據安全工具,這兩個產品的功能也基本是一樣的,就是去管理大數據計算生態圈產品的權限,Sentry是採用插件的形式,將自己集成到Impala、Hive、HDFS、Solr等產品上,當用戶向這些產品發起請求,產品會先向Sentry Server進行校驗,Sentry也可以和Kerberos配合使用,從而完成跨平臺統一權限管理。而Ranger所提供的功能也類似,但是所支持的產品更加多樣,包括HDFS、HBase、Hive、YARN、Storm、Solr、Kafka、Atlas等,其同樣也是採用一個Ranger Admin連接多個集成到產品上的Ranger插件完成的權限驗證過程。

Apache Atlas

官網:https://atlas.apache.org/

Apache Atlas是數據治理體系中比較重要的一個產品,它主要負責元數據的管理,這個元數據就是指用來描述數據的數據,比如數據的類型、名稱、屬性、作用、生命週期、有效範圍、血緣關係等等,在大數據系統中,元數據有着非常大的價值,一個比較成熟的數據系統中一般都會存在着這麼一個元數據管理平臺,元數據除了能讓業務人員更加方便快捷理解我們的數據和業務,也有着幫助我們提升數據質量,消除信息不對稱,以及快速定位數據問題等作用,所以如何有效的利用好這些元數據,使這些數據產生更大的價值,也是很多人一直在思考的事情。現在Atlas支持的數據源有Hive、Sqoop、Storm,其導入方式有HOOK和Batch兩種方式,首次使用是Batch的同步方式,之後Atlas會利用HOOK主動獲取到數據源的變化,並更新自身數據。

Apache Kylin

官網:http://kylin.apache.org/

image

Kylin是一個爲OLAP場景量身定製的分佈式數據倉庫產品,提供多維分析的功能,並可以和很多BI分析工具無縫對接,比如Tableau、Superset等。Kylin提供了前端平臺,使用者可以在該平臺上去定義自己的數據維度,Kylin會定時完整分析所需數據的預計算,形成多個Cube,並將之保存在HBase中,所以部署Kylin的時候需要HBase環境的支持。在數據與計算的時候,對其所在設備的資源消耗也比較大。

Apache Hive & Tez

官網:https://hive.apache.org/
官網:https://tez.apache.org/

Hive應該是最有名氣的數據倉庫工具了吧,他將HDFS上的數據組織成關係型數據庫的形式,並提供了HiveSQL進行結構化查詢,使得數據分析人員可以從傳統的關係型數據庫幾乎無縫的過渡到HDFS上,但其個別函數和傳統SQL還是有區別的,並且默認也不支持update和delete操作。但開發人員可以開發UDF,爲HiveSQL擴充屬於自己的功能函數。Hive本身的計算是基於MapReduce的,後來爲了應對SparkSQL的出現,開發組推出了Hive on Spark,使得SQL的解釋、分析、優化還是在Hive上,而執行階段交由Spark去完成,從而以達到和SparkSQL近似的速度。

Tez是對Hive的另一項優化,爲其引入了DAG的概念,增加任務並行度從而提升Hive的查詢速度,但其本質仍舊是MapReduce,所以提升效果相比Hive on Spark來講並不足夠明顯。

Apache Presto

官網:https://prestodb.io/

Presto是由facebook公司開發的一款分佈式查詢引擎,其主要特點是支持了非常多的Connector,從而實現在一個平臺上連接多個數據源,並且可以將這些數據源的內容進行聚合計算,同時Presto也支持使用者自行開發新的Connector。並且Presto的計算過程全程是基於內存的,所以速度也是非常的快,但其實Presto也只是針對個別計算場景的性能優化會非常明顯,網上有非常詳細的分析文章。之前使用該工具是爲了將離線數倉和實時數倉的數據進行聯合查詢,提供給實時數據平臺使用。

在使用過程中我覺得有點不好的地方有三點。一是因爲Presto基於內存計算,所以在資源緊張的情況下經常Crash導致任務失敗。二是Presto任務爲串行提交,所以會出現大任務阻塞小任務的情況出現。或許通過調參可以解決該問題吧,但沒有再深入調研了。三是沒有找到一個比較好的Web平臺去查詢Presto,網上有Hue通過PostgreSQL去鏈接Presto的方案,覺得有點麻煩,看上去比較成熟的Airpal平臺也已不再更新了。最後使用了yanagishima,基本功能可以滿足,但該平臺沒有用戶管理功能,沒法控制權限。

Apache Parquet & Orc

官網:https://parquet.apache.org/
官網:https://orc.apache.org/

Parquet和ORC是兩種比較應用比較多的列式存儲格式,列式存儲不同於傳統關係型數據庫中行式存儲的模式,這種主要的差別可能由於聯機事務處理(OLTP)和聯機分析處理(OLAP)的需求場景不同所造成的。在OLTP場景多是需要存儲系統能滿足快速的CRUD,這種操作對象都是以行爲單位的。而在OLAP場景下,主要的特徵是數據量巨大,而對實時性的要求並不高。而列式存儲正式滿足了這一需求特徵。因爲當數據以列的方式存儲,在查詢的時候引擎所讀取的數據量將會更小,而且同一列的數據往往內容類似,更加便於進行數據壓縮,但列式存儲不適於更新和刪除頻繁的場景。Parquet和Orc同爲列式存儲,但他們的存儲格式並不相同,這種差異造成了兩者在存儲不同類型的數據時所出現的性能差異,從網上的一些文章看,Orc的性能要比Parquet好一點,但是Impala是不支持Orc的,並且諸如Delta Lake這種數據湖產品,也是基於Parquet去做的。所以在選擇採用哪種列式存儲格式時,還是要根據自身的業務特點來決定。

Apache Griffin

官網:http://griffin.apache.org/

image

數據質量管理是數據系統中不可或缺的一環,初期的時候我們往往在ETL的各個階段,加入一些簡單的腳本來對生成的數據進行檢查,而Apache Griffin也是一款這樣的產品,它是由eBay開發的一個數據質量監控平臺,後上升爲Apache頂級項目。它提供了數據校驗和報警的功能,也支持一些參數的可視化展現,相關的配置步驟都可以在Griffin的頁面上完成。除了能完成一些最基本最簡單的諸如是否存在異常值的數據檢查,也能完成一些諸如最值、中值的數據統計需求等等,並且提供了專業的圖表報告。

Apache Zeppelin

官網:http://zeppelin.apache.org/

image

Zeppelin是一款非常方便的在線筆記本,使用體驗有點像Python的Jupyter NoteBook,可以從圖中看到使用者可以在線執行,並繪製簡單的圖表。並且Zeppelin有了用戶的概念,使得多人協同工作更加方便。Zeppelin支持了非常多的數據源,通過該平臺,可以調用Hive、Cassandra、R、Kylin、Flink、Spark、ElasticSearch、HBase、Python、Shell等等。

我在使用時出現了Spark連接不穩的情況,需要使用者反覆登錄纔可以。但總之我還是非常喜歡這款工具的。

Apache Superset

官網:http://superset.apache.org/

Superset是一款開源的可視化工具,使用該工具可以方便快速的創建數據Dashboard,同類型的產品還有Redash、Metabase,但調研過後個人還是更喜歡Superset一些。不過因爲同期引入了Tableau,Superset並沒有在實際項目中使用。

Tableau

官網:https://www.tableau.com/

image

和介紹的其它軟件不同,Tableau是一款商用軟件,根據購買的賬號數量按年付費,之所以這裏提到它,也是因爲Tableau在BI領域內的名氣着實有點高。Tableau分爲Server端和本地客戶端,使用者通過在客戶端上的拖拽,即可快速生成一個數據Dashboard,使得Dashboard的開發工作從開發側下放到了需求方。並且Tableau也提供了完備的用戶管理功能,還支持了非常多的數據源。商業軟件和開源軟件比起來,無論功能完備性上還是使用體驗上,的確都有明顯的提升。我覺得唯一的難度可能就是如何把這個開發維護的工作在需求方落地吧,畢竟它還是有一些學習成本的。

TPCx-BB

官網:http://www.tpc.org/

TPC全稱是事務處理性能委員會,是由數十家公司組成的非盈利性組織,負責訂製各個行業的基準測試規範,阿里巴巴的MaxCompute和OceanBase都參加過該項測試,並取得了非常好的成績。TPCx-BB是一個大數據基準測試工具,該工具模擬了一個網上零售的場景,首先工具會先向被測系統中插入預定好的表和數據,然後經過一系列的SQL操作,來對大數據集羣的性能進行評估。TPC針對不同的被測場景,提供了很多現成的工具,可以供大家下載使用:
http://www.tpc.org/tpc_documents_current_versions/current_specifications5.asp

【雲棲號在線課堂】每天都有產品技術專家分享!
課程地址:https://yqh.aliyun.com/live

立即加入社羣,與專家面對面,及時瞭解課程最新動態!
【雲棲號在線課堂 社羣】https://c.tb.cn/F3.Z8gvnK

原文發佈時間:2020-07-22
本文作者:李雲翔(降雲)
本文來自:“阿里技術公衆號”,瞭解相關信息可以關注“阿里技術

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章