阿里妹導(dǎo)讀：近幾年里，大數(shù)據(jù)行業(yè)發(fā)展勢頭迅猛，故而相應(yīng)的分布式產(chǎn)品和架構(gòu)層出不窮，本文分享作者在大數(shù)據(jù)系統(tǒng)實(shí)踐過程中接觸過的一些工具及使用感受，拋磚引玉，和同學(xué)們一起構(gòu)建一個(gè)分布式產(chǎn)品的全景圖。
下圖是由著名的數(shù)據(jù)觀察家Matt Turck在他的BLOG（https://mattturck.com/）里發(fā)出的2019年人工智能和大數(shù)據(jù)產(chǎn)業(yè)圖，他從2012年開始每年都會(huì)繪制一張，大致描述這個(gè)產(chǎn)業(yè)里的公司及其數(shù)據(jù)相關(guān)的產(chǎn)品，以及所屬問題的領(lǐng)域。這里面大部分是商業(yè)軟件，而對于絕大多數(shù)互聯(lián)網(wǎng)公司，中間綠色的開源產(chǎn)品可能大家接觸的更多一些，而這些產(chǎn)品里，絕大多數(shù)都屬于Apache基金會(huì)。
下面我從中挑選一些東西隨便聊聊，因?yàn)槭请S便聊聊，所以知識點(diǎn)并不全，也不能幫助大家知道如何搭建和使用，以及如何避坑，只是談?wù)勎覍@些東西的印象，描述一個(gè)大概的輪廓，如有使用需求可以搜索網(wǎng)上其它文章，資料還是很多的。當(dāng)然，大家對其中的內(nèi)容有興趣可以隨時(shí)找我交流討論，對文中如有描述錯(cuò)誤的地方也歡迎大家斧正，共同學(xué)習(xí)，謝謝。
Apache Hadoop
官網(wǎng)：http://hadoop.apache.org/
Hadoop項(xiàng)目下包含了很多子項(xiàng)目，從計(jì)算到存儲(chǔ)都有，比如HDFS、MapReduce、YARN、HBase。
HDFS全稱叫做Hadoop分布式文件系統(tǒng)，其主要由一個(gè)NameNode(NN)和多個(gè)DataNode(DN)組成，數(shù)據(jù)文件會(huì)分成多個(gè)Block，這些Block按照不同主機(jī)，不同機(jī)架的策略以默認(rèn)一備三的情況分布存儲(chǔ)在各個(gè)節(jié)點(diǎn)。現(xiàn)在每個(gè)Block大小默認(rèn)是128MB，以后隨著磁盤尋址速度的增加，這個(gè)Block也會(huì)不斷增大。而NN里面則存儲(chǔ)了這些Block元數(shù)據(jù)的信息，這樣客戶端進(jìn)行數(shù)據(jù)查詢的時(shí)候，DN告知所需數(shù)據(jù)的位置。從這種結(jié)構(gòu)上能看出一些比較明顯的問題就是NN節(jié)點(diǎn)的單點(diǎn)問題，所以在Hadoop 2.x的時(shí)候，針對NN做了一些改進(jìn)。
首先是在系統(tǒng)可用性上，增加了一個(gè)StandBy狀態(tài)的NN，作為服務(wù)中NN（Active NN）的備機(jī)，當(dāng)服務(wù)中的NN掛掉后，由StandBy的NN自動(dòng)接替工作。而NN節(jié)點(diǎn)狀態(tài)的健康和服務(wù)切換，由ZKFC負(fù)責(zé)。主備NN之間的信息同步則由Quorum Journal Node負(fù)責(zé)。
其次，由于單臺NN中存儲(chǔ)了大量的元數(shù)據(jù)信息，所以隨著HDFS數(shù)據(jù)量的不斷增加，顯然NN必將成為系統(tǒng)的瓶頸，為了解決這個(gè)問題，Hadoop 2.x增加了Federation，該技術(shù)允許系統(tǒng)中有多臺NN同時(shí)對外提供服務(wù)，這多臺NN將DN中的所有文件路徑進(jìn)行了橫向拆分，每個(gè)DN負(fù)責(zé)不同的路徑，達(dá)到了橫向擴(kuò)展的效果。
除了HDFS，Hadoop 2.x也引入了YARN，該工具負(fù)責(zé)對集群中的資源進(jìn)行管理和任務(wù)的協(xié)調(diào)。該工具分成一個(gè)ResourceManager(RM)和多個(gè)NodeManager(NM)，當(dāng)一個(gè)任務(wù)提交給YARN之后，會(huì)先在某一服務(wù)器上啟動(dòng)一個(gè)ApplicationMaster(AM)，AM向RM申請資源，RM通過NM尋找集群中空閑的資源，NM將資源打包成一個(gè)個(gè)Container，交給AM。AM將數(shù)據(jù)和程序分發(fā)到對應(yīng)節(jié)點(diǎn)上處理，如果某個(gè)Container中的任務(wù)執(zhí)行失敗了，AM會(huì)重新向RM申請新的Container。
Apache Hadoop HBase & Kudu
官網(wǎng)：http://hbase.apache.org/
眾所周知，HBase一個(gè)分布式列式存儲(chǔ)系統(tǒng)，同樣屬于Hadoop的子項(xiàng)目，列式存儲(chǔ)的優(yōu)劣在這里不說了，提一下HBase的WAL和LSM，WAL全稱為Write Ahead Log，只是在數(shù)據(jù)修改操作前，會(huì)先將此操作記錄在日志中，這樣一旦服務(wù)崩潰，通過該日志即可進(jìn)行數(shù)據(jù)的恢復(fù)，提到這里有些人就會(huì)聯(lián)想到MySQL，因?yàn)镮nnoDB引擎的redo log就是典型的WAL應(yīng)用。而在HBase中該功能是由叫做HLog的模塊所完成的。再說LSM，其全稱為Log Structured Merge Trees，介紹原理的文章也有很多，在HBase中，LSM樹是MemStore模塊的底層存儲(chǔ)結(jié)構(gòu)，而MemStore有三個(gè)作用，一是當(dāng)有數(shù)據(jù)寫入的時(shí)候，直接寫到MemStore中，從而提升寫數(shù)據(jù)的效率。二是充當(dāng)讀取數(shù)據(jù)時(shí)的緩存。三是定期對數(shù)據(jù)操作去重，并進(jìn)行數(shù)據(jù)落盤。HBase的主要角色分別有HMaster和HRegionServer，同樣是一對多的關(guān)系，而各節(jié)點(diǎn)的狀態(tài)全都交由Zookeeper負(fù)責(zé)。Kudu是一個(gè)和HBase非常類似的產(chǎn)品，其不同之處在于Kudu不依賴Zookeeper來管理自己的集群，并且HBase的數(shù)據(jù)是保存在HDFS上的，而Kudu擁有自己的數(shù)據(jù)文件格式。
Apache Spark
官網(wǎng)：https://spark.apache.org/
Spark是由加州大學(xué)伯克利分校推出的分布式計(jì)算引擎，在Spark的官方主頁上有一張和Hadoop的性能對比圖，姑且不談這張圖中數(shù)據(jù)的準(zhǔn)確性，但是Spark的確將Hadoop（主要是指MapReduce）的性能提升了一個(gè)量級。我理解這主要得益于兩個(gè)方面：第一個(gè)是Spark計(jì)算過程中生成的中間數(shù)據(jù)不再落盤，沒有了Spill的階段。第二個(gè)是引入DAG對任務(wù)進(jìn)行拆解，一個(gè)完整的Job被分成多個(gè)Stage，每個(gè)Stage里面又有多個(gè)Task，通過一張有向無環(huán)圖，使得沒有依賴關(guān)系的Task可以并行運(yùn)行。
Spark不只是在批處理上有所成績，而是更加注重整個(gè)生態(tài)圈的建設(shè)，其擁有流式處理框架SparkStreaming，采用微批的形式達(dá)到類似流處理的效果，現(xiàn)在又推出了Structured Streaming，實(shí)現(xiàn)基于狀態(tài)的流處理框架。此外還擁有SparkSQL來幫助非開發(fā)人員更加便捷的調(diào)用Spark的服務(wù)和Spark MLlib這個(gè)機(jī)器學(xué)習(xí)庫。
Spark雖好，但其對內(nèi)存資源消耗也很大，同時(shí)也使得他在穩(wěn)定性上不如MapReduce，所以有些大公司數(shù)倉的日常任務(wù)仍舊采用傳統(tǒng)MapReduce的方式執(zhí)行，不求最快，但求最穩(wěn)。我們的系統(tǒng)在剛從MapReduce上切到Spark時(shí)，每天夜里也是任務(wù)異常頻發(fā)，最后調(diào)整了任務(wù)和資源分配，再加上一個(gè)很粗暴的重試機(jī)制解決了。
Apache Flink
官網(wǎng)：https://flink.apache.org/
Flink是德國Data Artisans公司開發(fā)一款分布式計(jì)算系統(tǒng)，該公司于19年初被阿里巴巴集團(tuán)收購。包括Spark和Kafka，也都看到了未來流式計(jì)算的前景是非常巨大的，紛紛建立屬于自己的流式計(jì)算生態(tài)圈。
Flink和Spark Streaming相比，前者是真正的流式計(jì)算，而后者是微批處理，雖然批次足夠小，但其本質(zhì)畢竟還是批處理，這就導(dǎo)致有些場景SparkStreaming注定無法滿足，雖然Spark現(xiàn)在將重心轉(zhuǎn)移到了Structured Streaming，它彌補(bǔ)了Spark Streaming很多的不足，但是在處理流程上仍然是微批處理。
而Flink在設(shè)計(jì)之初就同時(shí)考慮了批處理和流處理這兩種需求，所以使用者也可以只通過一個(gè)計(jì)算引擎，就能實(shí)現(xiàn)批處理和流處理兩種計(jì)算場景，其主要幾個(gè)需要清楚的特性我覺得分別是：State狀態(tài)管理，CheckPoint容錯(cuò)機(jī)制，Window滑動(dòng)窗口，和Watermark亂序解決。這些內(nèi)容網(wǎng)上都有很多介紹，不再闡述。
Apache Impala
官網(wǎng)：https://impala.apache.org/
Impala是Cloudera公司用C++開發(fā)的支持SQL語義的查詢系統(tǒng)，可以用來查詢HDFS、HBase、Kudu的內(nèi)容，也支持多種序列化和壓縮格式，因?yàn)橐彩腔趦?nèi)存的計(jì)算，比傳統(tǒng)MapReduce快很多。不過因?yàn)橐呀?jīng)使用了Spark，所以組里并沒有對Impala進(jìn)行大規(guī)模的應(yīng)用。經(jīng)過一些零散的調(diào)研和了解，好像其它公司對Impala的應(yīng)用也不是非常多。
Apache Zookeeper
官網(wǎng)：https://zookeeper.apache.org/
Zookeeper無論在數(shù)據(jù)系統(tǒng)還是在其它后端系統(tǒng)的使用場景都非常廣，它可以用作分布式鎖服務(wù)，可以用做系統(tǒng)的配置中心，可以協(xié)助完成一致性算法的選主過程，可以用于ZKFC做節(jié)點(diǎn)健康情況的探查，總之用處還有很多。而它的工作機(jī)制，基本就是ZAB協(xié)議的機(jī)制，一個(gè)支持崩潰恢復(fù)的原子廣播協(xié)議，其主要組成也是由一個(gè)Leader和多個(gè)Follower組成的，數(shù)據(jù)的提交遵循2PC協(xié)議。當(dāng)Leader崩潰時(shí)，F(xiàn)ollower會(huì)自動(dòng)切換狀態(tài)開始重新選主，重新選完之后再進(jìn)行多節(jié)點(diǎn)的數(shù)據(jù)對齊。
Apache Sqoop
官網(wǎng)：https://sqoop.apache.org/
一款用于在傳統(tǒng)關(guān)系型數(shù)據(jù)庫和HDFS之間互相進(jìn)行數(shù)據(jù)傳遞的工具，無論是import還是export都提供了大量的參數(shù)，因?yàn)槭欠植际綀?zhí)行，數(shù)據(jù)傳輸?shù)乃俣纫卜浅？?。只是在使用的過程中需要注意數(shù)據(jù)源中的異常數(shù)據(jù)，會(huì)比較容易造成數(shù)據(jù)傳遞過程中的異常退出。為了彌補(bǔ)Sqoop的功能單一，推出了Sqoop 2，架構(gòu)上比Sqoop 1復(fù)雜了很多，不過我沒有用過。
Apache Flume
官網(wǎng)：http://flume.apache.org/
分布式數(shù)據(jù)傳輸工具，支持包含文件、Netcat、JMS、HTTP在內(nèi)的多種數(shù)據(jù)源。其結(jié)構(gòu)上分成Source、Channel、Sink三部分，Source將獲取到的數(shù)據(jù)緩存在Channel中，這個(gè)Channel可以是文件，可以是內(nèi)存，也可以使用JDBC，Sink從Channel消費(fèi)數(shù)據(jù)，傳遞給系統(tǒng)中的其他模塊，比如HBase、HDFS、Kafka等等。
Apache Kafka
官網(wǎng)：http://kafka.apache.org/
曾經(jīng)是一款由Scala開發(fā)的分布式消息隊(duì)列產(chǎn)品，現(xiàn)在生態(tài)已經(jīng)擴(kuò)展了，因?yàn)樗瞥隽薑afka Streaming，所以現(xiàn)在也應(yīng)該被稱作是一個(gè)流處理平臺了，但這里不說Kafka Streaming，因?yàn)闆]有用過和了解過。
Kafka的隊(duì)列按照Topic劃分，每個(gè)Topic下由多個(gè)Partition組成，在單個(gè)Partition中的消息保證是有序的。這種結(jié)構(gòu)下確保了消息是在磁盤順序?qū)懭氲?，?jié)省了磁盤尋址的時(shí)間，所以數(shù)據(jù)落盤的速度非?？臁＜又捎昧薽map的方式，減少了用戶態(tài)和內(nèi)核態(tài)之間的數(shù)據(jù)拷貝次數(shù)，mmap是一種將文件內(nèi)容和內(nèi)存地址映射的技術(shù)，提效十分明顯。Kafka和Flume的配合使用，形成了流式處理領(lǐng)域里的經(jīng)典框架。
Apache Ranger & Sentry
官網(wǎng)：http://ranger.apache.org/
官網(wǎng)：http://sentry.apache.org/
Ranger和Sentry都是分布式的數(shù)據(jù)安全工具，這兩個(gè)產(chǎn)品的功能也基本是一樣的，就是去管理大數(shù)據(jù)計(jì)算生態(tài)圈產(chǎn)品的權(quán)限，Sentry是采用插件的形式，將自己集成到Impala、Hive、HDFS、Solr等產(chǎn)品上，當(dāng)用戶向這些產(chǎn)品發(fā)起請求，產(chǎn)品會(huì)先向Sentry Server進(jìn)行校驗(yàn)，Sentry也可以和Kerberos配合使用，從而完成跨平臺統(tǒng)一權(quán)限管理。而Ranger所提供的功能也類似，但是所支持的產(chǎn)品更加多樣，包括HDFS、HBase、Hive、YARN、Storm、Solr、Kafka、Atlas等，其同樣也是采用一個(gè)Ranger Admin連接多個(gè)集成到產(chǎn)品上的Ranger插件完成的權(quán)限驗(yàn)證過程。
Apache Atlas
官網(wǎng)：https://atlas.apache.org/
Apache Atlas是數(shù)據(jù)治理體系中比較重要的一個(gè)產(chǎn)品，它主要負(fù)責(zé)元數(shù)據(jù)的管理，這個(gè)元數(shù)據(jù)就是指用來描述數(shù)據(jù)的數(shù)據(jù)，比如數(shù)據(jù)的類型、名稱、屬性、作用、生命周期、有效范圍、血緣關(guān)系等等，在大數(shù)據(jù)系統(tǒng)中，元數(shù)據(jù)有著非常大的價(jià)值，一個(gè)比較成熟的數(shù)據(jù)系統(tǒng)中一般都會(huì)存在著這么一個(gè)元數(shù)據(jù)管理平臺，元數(shù)據(jù)除了能讓業(yè)務(wù)人員更加方便快捷理解我們的數(shù)據(jù)和業(yè)務(wù)，也有著幫助我們提升數(shù)據(jù)質(zhì)量，消除信息不對稱，以及快速定位數(shù)據(jù)問題等作用，所以如何有效的利用好這些元數(shù)據(jù)，使這些數(shù)據(jù)產(chǎn)生更大的價(jià)值，也是很多人一直在思考的事情?，F(xiàn)在Atlas支持的數(shù)據(jù)源有Hive、Sqoop、Storm，其導(dǎo)入方式有HOOK和Batch兩種方式，首次使用是Batch的同步方式，之后Atlas會(huì)利用HOOK主動(dòng)獲取到數(shù)據(jù)源的變化，并更新自身數(shù)據(jù)。
Apache Kylin
官網(wǎng)：http://kylin.apache.org/
Kylin是一個(gè)為OLAP場景量身定制的分布式數(shù)據(jù)倉庫產(chǎn)品，提供多維分析的功能，并可以和很多BI分析工具無縫對接，比如Tableau、Superset等。Kylin提供了前端平臺，使用者可以在該平臺上去定義自己的數(shù)據(jù)維度，Kylin會(huì)定時(shí)完整分析所需數(shù)據(jù)的預(yù)計(jì)算，形成多個(gè)Cube，并將之保存在HBase中，所以部署Kylin的時(shí)候需要HBase環(huán)境的支持。在數(shù)據(jù)與計(jì)算的時(shí)候，對其所在設(shè)備的資源消耗也比較大。
Apache Hive & Tez
官網(wǎng)：https://hive.apache.org/
官網(wǎng)：https://tez.apache.org/
Hive應(yīng)該是最有名氣的數(shù)據(jù)倉庫工具了吧，他將HDFS上的數(shù)據(jù)組織成關(guān)系型數(shù)據(jù)庫的形式，并提供了HiveSQL進(jìn)行結(jié)構(gòu)化查詢，使得數(shù)據(jù)分析人員可以從傳統(tǒng)的關(guān)系型數(shù)據(jù)庫幾乎無縫的過渡到HDFS上，但其個(gè)別函數(shù)和傳統(tǒng)SQL還是有區(qū)別的，并且默認(rèn)也不支持update和delete操作。但開發(fā)人員可以開發(fā)UDF，為HiveSQL擴(kuò)充屬于自己的功能函數(shù)。Hive本身的計(jì)算是基于MapReduce的，后來為了應(yīng)對SparkSQL的出現(xiàn)，開發(fā)組推出了Hive on Spark，使得SQL的解釋、分析、優(yōu)化還是在Hive上，而執(zhí)行階段交由Spark去完成，從而以達(dá)到和SparkSQL近似的速度。
Tez是對Hive的另一項(xiàng)優(yōu)化，為其引入了DAG的概念，增加任務(wù)并行度從而提升Hive的查詢速度，但其本質(zhì)仍舊是MapReduce，所以提升效果相比Hive on Spark來講并不足夠明顯。
Apache Presto
官網(wǎng)：https://prestodb.io/
Presto是由facebook公司開發(fā)的一款分布式查詢引擎，其主要特點(diǎn)是支持了非常多的Connector，從而實(shí)現(xiàn)在一個(gè)平臺上連接多個(gè)數(shù)據(jù)源，并且可以將這些數(shù)據(jù)源的內(nèi)容進(jìn)行聚合計(jì)算，同時(shí)Presto也支持使用者自行開發(fā)新的Connector。并且Presto的計(jì)算過程全程是基于內(nèi)存的，所以速度也是非常的快，但其實(shí)Presto也只是針對個(gè)別計(jì)算場景的性能優(yōu)化會(huì)非常明顯，網(wǎng)上有非常詳細(xì)的分析文章。之前使用該工具是為了將離線數(shù)倉和實(shí)時(shí)數(shù)倉的數(shù)據(jù)進(jìn)行聯(lián)合查詢，提供給實(shí)時(shí)數(shù)據(jù)平臺使用。
在使用過程中我覺得有點(diǎn)不好的地方有三點(diǎn)。一是因?yàn)镻resto基于內(nèi)存計(jì)算，所以在資源緊張的情況下經(jīng)常Crash導(dǎo)致任務(wù)失敗。二是Presto任務(wù)為串行提交，所以會(huì)出現(xiàn)大任務(wù)阻塞小任務(wù)的情況出現(xiàn)?；蛟S通過調(diào)參可以解決該問題吧，但沒有再深入調(diào)研了。三是沒有找到一個(gè)比較好的Web平臺去查詢Presto，網(wǎng)上有Hue通過PostgreSQL去鏈接Presto的方案，覺得有點(diǎn)麻煩，看上去比較成熟的Airpal平臺也已不再更新了。最后使用了yanagishima，基本功能可以滿足，但該平臺沒有用戶管理功能，沒法控制權(quán)限。
Apache Parquet & Orc
官網(wǎng)：https://parquet.apache.org/
官網(wǎng)：https://orc.apache.org/
Parquet和ORC是兩種比較應(yīng)用比較多的列式存儲(chǔ)格式，列式存儲(chǔ)不同于傳統(tǒng)關(guān)系型數(shù)據(jù)庫中行式存儲(chǔ)的模式，這種主要的差別可能由于聯(lián)機(jī)事務(wù)處理（OLTP）和聯(lián)機(jī)分析處理（OLAP）的需求場景不同所造成的。在OLTP場景多是需要存儲(chǔ)系統(tǒng)能滿足快速的CRUD，這種操作對象都是以行為單位的。而在OLAP場景下，主要的特征是數(shù)據(jù)量巨大，而對實(shí)時(shí)性的要求并不高。而列式存儲(chǔ)正式滿足了這一需求特征。因?yàn)楫?dāng)數(shù)據(jù)以列的方式存儲(chǔ)，在查詢的時(shí)候引擎所讀取的數(shù)據(jù)量將會(huì)更小，而且同一列的數(shù)據(jù)往往內(nèi)容類似，更加便于進(jìn)行數(shù)據(jù)壓縮，但列式存儲(chǔ)不適于更新和刪除頻繁的場景。Parquet和Orc同為列式存儲(chǔ)，但他們的存儲(chǔ)格式并不相同，這種差異造成了兩者在存儲(chǔ)不同類型的數(shù)據(jù)時(shí)所出現(xiàn)的性能差異，從網(wǎng)上的一些文章看，Orc的性能要比Parquet好一點(diǎn)，但是Impala是不支持Orc的，并且諸如Delta Lake這種數(shù)據(jù)湖產(chǎn)品，也是基于Parquet去做的。所以在選擇采用哪種列式存儲(chǔ)格式時(shí)，還是要根據(jù)自身的業(yè)務(wù)特點(diǎn)來決定。
Apache Griffin
官網(wǎng)：http://griffin.apache.org/
數(shù)據(jù)質(zhì)量管理是數(shù)據(jù)系統(tǒng)中不可或缺的一環(huán)，初期的時(shí)候我們往往在ETL的各個(gè)階段，加入一些簡單的腳本來對生成的數(shù)據(jù)進(jìn)行檢查，而Apache Griffin也是一款這樣的產(chǎn)品，它是由eBay開發(fā)的一個(gè)數(shù)據(jù)質(zhì)量監(jiān)控平臺，后上升為Apache頂級項(xiàng)目。它提供了數(shù)據(jù)校驗(yàn)和報(bào)警的功能，也支持一些參數(shù)的可視化展現(xiàn)，相關(guān)的配置步驟都可以在Griffin的頁面上完成。除了能完成一些最基本最簡單的諸如是否存在異常值的數(shù)據(jù)檢查，也能完成一些諸如最值、中值的數(shù)據(jù)統(tǒng)計(jì)需求等等，并且提供了專業(yè)的圖表報(bào)告。
Apache Zeppelin
官網(wǎng)：http://zeppelin.apache.org/
Zeppelin是一款非常方便的在線筆記本，使用體驗(yàn)有點(diǎn)像Python的Jupyter NoteBook，可以從圖中看到使用者可以在線執(zhí)行，并繪制簡單的圖表。并且Zeppelin有了用戶的概念，使得多人協(xié)同工作更加方便。Zeppelin支持了非常多的數(shù)據(jù)源，通過該平臺，可以調(diào)用Hive、Cassandra、R、Kylin、Flink、Spark、ElasticSearch、HBase、Python、Shell等等。
我在使用時(shí)出現(xiàn)了Spark連接不穩(wěn)的情況，需要使用者反復(fù)登錄才可以。但總之我還是非常喜歡這款工具的。
Apache Superset
官網(wǎng)：http://superset.apache.org/
Superset是一款開源的可視化工具，使用該工具可以方便快速的創(chuàng)建數(shù)據(jù)Dashboard，同類型的產(chǎn)品還有Redash、Metabase，但調(diào)研過后個(gè)人還是更喜歡Superset一些。不過因?yàn)橥谝肓薚ableau，Superset并沒有在實(shí)際項(xiàng)目中使用。
Tableau
官網(wǎng)：https://www.tableau.com/
和介紹的其它軟件不同，Tableau是一款商用軟件，根據(jù)購買的賬號數(shù)量按年付費(fèi)，之所以這里提到它，也是因?yàn)門ableau在BI領(lǐng)域內(nèi)的名氣著實(shí)有點(diǎn)高。Tableau分為Server端和本地客戶端，使用者通過在客戶端上的拖拽，即可快速生成一個(gè)數(shù)據(jù)Dashboard，使得Dashboard的開發(fā)工作從開發(fā)側(cè)下放到了需求方。并且Tableau也提供了完備的用戶管理功能，還支持了非常多的數(shù)據(jù)源。商業(yè)軟件和開源軟件比起來，無論功能完備性上還是使用體驗(yàn)上，的確都有明顯的提升。我覺得唯一的難度可能就是如何把這個(gè)開發(fā)維護(hù)的工作在需求方落地吧，畢竟它還是有一些學(xué)習(xí)成本的。
TPCx-BB
官網(wǎng)：http://www.tpc.org/
TPC全稱是事務(wù)處理性能委員會(huì)，是由數(shù)十家公司組成的非盈利性組織，負(fù)責(zé)訂制各個(gè)行業(yè)的基準(zhǔn)測試規(guī)范，阿里巴巴的MaxCompute和OceanBase都參加過該項(xiàng)測試，并取得了非常好的成績。TPCx-BB是一個(gè)大數(shù)據(jù)基準(zhǔn)測試工具，該工具模擬了一個(gè)網(wǎng)上零售的場景，首先工具會(huì)先向被測系統(tǒng)中插入預(yù)定好的表和數(shù)據(jù)，然后經(jīng)過一系列的SQL操作，來對大數(shù)據(jù)集群的性能進(jìn)行評估。TPC針對不同的被測場景，提供了很多現(xiàn)成的工具，可以供大家下載使用：
http://www.tpc.org/tpc_documents_current_versions/current_specifications5.asp
