簡介：近幾年里，大數(shù)據行業(yè)發(fā)展勢頭迅猛，故而相應的分布式產品和架構層出不窮，本文分享作者在大數(shù)據系統(tǒng)實踐過程中接觸過的一些工具及使用感受，拋磚引玉，和同學們一起構建一個分布式產品的全景圖。

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

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

Apache Hadoop

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

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

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

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

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

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

Apache Hadoop HBase & Kudu

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

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

Apache Spark

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

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

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

Spark雖好，但其對內存資源消耗也很大，同時也使得他在穩(wěn)定性上不如MapReduce，所以有些大公司數(shù)倉的日常任務仍舊采用傳統(tǒng)MapReduce的方式執(zhí)行，不求最快，但求最穩(wěn)。我們的系統(tǒng)在剛從MapReduce上切到Spark時，每天夜里也是任務異常頻發(fā)，最后調整了任務和資源分配，再加上一個很粗暴的重試機制解決了。

Apache Flink

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

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

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

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

Apache Impala

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

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

Apache Zookeeper

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

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

Apache Sqoop

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

一款用于在傳統(tǒng)關系型數(shù)據庫和HDFS之間互相進行數(shù)據傳遞的工具，無論是import還是export都提供了大量的參數(shù)，因為是分布式執(zhí)行，數(shù)據傳輸?shù)乃俣纫卜浅？臁Ｖ皇窃谑褂玫倪^程中需要注意數(shù)據源中的異常數(shù)據，會比較容易造成數(shù)據傳遞過程中的異常退出。為了彌補Sqoop的功能單一，推出了Sqoop 2，架構上比Sqoop 1復雜了很多，不過我沒有用過。

Apache Flume

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

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

Apache Kafka

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

曾經是一款由Scala開發(fā)的分布式消息隊列產品，現(xiàn)在生態(tài)已經擴展了，因為它推出了Kafka Streaming，所以現(xiàn)在也應該被稱作是一個流處理平臺了，但這里不說Kafka Streaming，因為沒有用過和了解過。

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

Apache Ranger & Sentry

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

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

Apache Atlas

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

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

Apache Kylin

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

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

Apache Hive & Tez

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

Hive應該是最有名氣的數(shù)據倉庫工具了吧，他將HDFS上的數(shù)據組織成關系型數(shù)據庫的形式，并提供了HiveSQL進行結構化查詢，使得數(shù)據分析人員可以從傳統(tǒng)的關系型數(shù)據庫幾乎無縫的過渡到HDFS上，但其個別函數(shù)和傳統(tǒng)SQL還是有區(qū)別的，并且默認也不支持update和delete操作。但開發(fā)人員可以開發(fā)UDF，為HiveSQL擴充屬于自己的功能函數(shù)。Hive本身的計算是基于MapReduce的，后來為了應對SparkSQL的出現(xiàn)，開發(fā)組推出了Hive on Spark，使得SQL的解釋、分析、優(yōu)化還是在Hive上，而執(zhí)行階段交由Spark去完成，從而以達到和SparkSQL近似的速度。

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

Apache Presto

官網：https://prestodb.io/

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

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

Apache Parquet & Orc

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

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

Apache Griffin

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

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

Apache Zeppelin

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

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

我在使用時出現(xiàn)了Spark連接不穩(wěn)的情況，需要使用者反復登錄才可以。但總之我還是非常喜歡這款工具的。

Apache Superset

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

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

Tableau

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

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

TPCx-BB

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

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

原文鏈接：https://developer.aliyun.com/article/768464?

版權聲明：本文中所有內容均屬于阿里云開發(fā)者社區(qū)所有，任何媒體、網站或個人未經阿里云開發(fā)者社區(qū)協(xié)議授權不得轉載、鏈接、轉貼或以其他方式復制發(fā)布/發(fā)表。申請授權請郵件developerteam@list.alibaba-inc.com，已獲得阿里云開發(fā)者社區(qū)協(xié)議授權的媒體、網站，在轉載使用時必須注明"稿件來源：阿里云開發(fā)者社區(qū)，原文作者姓名"，違者本社區(qū)將依法追究責任。 如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內容，歡迎發(fā)送郵件至：developer2020@service.aliyun.com 進行舉報，并提供相關證據，一經查實，本社區(qū)將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的有哪些大数据处理工具？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。