分享以下大數據處理工具 大數據處理工具有哪些?( 三 )


Apache Atlas官網:https://atlas.apache.org/
Apache Atlas是數據治理體系中比較重要的一個產品,它主要負責元數據的管理,這個元數據就是指用來描述數據的數據,比如數據的類型、名稱、屬性、作用、生命周期、有效范圍、血緣關系等等,在大數據系統中,元數據有著非常大的價值,一個比較成熟的數據系統中一般都會存在著這么一個元數據管理平臺,元數據除了能讓業務人員更加方便快捷理解我們的數據和業務,也有著幫助我們提升數據質量,消除信息不對稱,以及快速定位數據問題等作用,所以如何有效的利用好這些元數據,使這些數據產生更大的價值,也是很多人一直在思考的事情 。 現在Atlas支持的數據源有Hive、Sqoop、Storm,其導入方式有HOOK和Batch兩種方式,首次使用是Batch的同步方式,之后Atlas會利用HOOK主動獲取到數據源的變化,并更新自身數據 。
Apache Kylin官網:http://kylin.apache.org/
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去做的 。 所以在選擇采用哪種列式存儲格式時,還是要根據自身的業務特點來決定 。

推薦閱讀