數(shù)據(jù)分析師都想使用數(shù)據(jù)庫(kù)作為數(shù)據(jù)倉(cāng)庫(kù)處理并操作數(shù)據(jù)，那么哪一款數(shù)據(jù)庫(kù)最合適分析師呢?

雖然網(wǎng)上已經(jīng)有很多對(duì)各種數(shù)據(jù)庫(kù)進(jìn)行比較的文章，但其著眼點(diǎn)一般都是架構(gòu)、成本、可伸縮性和性能，很少考慮另一個(gè)關(guān)鍵因素：分析師在這些數(shù)據(jù)庫(kù)上編寫(xiě)查詢的難易程度。最近，Mode的首席分析師Benn Stancil發(fā)布了一篇文章，從另一個(gè)角度闡釋了哪一款數(shù)據(jù)庫(kù)最適合數(shù)據(jù)分析師。

Benn Stancil認(rèn)為數(shù)據(jù)分析工作不可能一蹴而就，分析師在使用數(shù)據(jù)庫(kù)的過(guò)程中阻礙他們速度的往往不是宏觀上的性能，而是編寫(xiě)查詢語(yǔ)句時(shí)的細(xì)節(jié)。例如，在Redshift中如何獲取當(dāng)前時(shí)間，是NOW()、CURDATE()、CURDATE、SYSDATE 還是WHATDAYISIT。

在Mode公司，分析師每天都會(huì)使用各種不同的語(yǔ)言編寫(xiě)幾千個(gè)查詢，運(yùn)行在Mode編輯器里的查詢超過(guò)百萬(wàn)個(gè)，而B(niǎo)enn Stancil就是從這些數(shù)據(jù)出發(fā)，對(duì)MySQL、PostgreSQL、Redshift、SQL Server、BigQuery、Vertica、Hive和Impala這八款數(shù)據(jù)庫(kù)進(jìn)行了比較。

1.查詢錯(cuò)誤是否容易解決

首先，Benn Stancil認(rèn)為查詢錯(cuò)誤是否容易解決是衡量數(shù)據(jù)庫(kù)的一個(gè)最基本指標(biāo)。數(shù)據(jù)庫(kù)提供的錯(cuò)誤信息(通常是語(yǔ)法錯(cuò)誤、函數(shù)名錯(cuò)誤、逗號(hào)錯(cuò)位等)最能表明該系統(tǒng)是否會(huì)對(duì)數(shù)據(jù)分析師造成極大的挫敗感。通過(guò)對(duì)8種數(shù)據(jù)庫(kù)查詢錯(cuò)誤頻率的比較，Benn Stancil發(fā)現(xiàn)Vertica和SQL Server錯(cuò)誤率最高，MySQL和Impala最低，如圖所示：

但是，對(duì)于該結(jié)果Benn Stancil認(rèn)為可能有點(diǎn)不嚴(yán)謹(jǐn)，因?yàn)镮mpala、MySQL和Hive是開(kāi)源的免費(fèi)產(chǎn)品，而Vertica、SQL Server和BigQuery不是，后三者的用戶通常是有充足分析預(yù)算的大型企業(yè)，其較高的錯(cuò)誤率很有可能是由于使用更深入而不是語(yǔ)言“更難用”。

　　2.復(fù)雜性

除了錯(cuò)誤率之外，Benn Stancil還討論了復(fù)雜性。雖然不同語(yǔ)言其查詢長(zhǎng)度、查詢復(fù)雜性和語(yǔ)言復(fù)雜性之間的關(guān)系盤(pán)根錯(cuò)節(jié)，要界定清楚很難，但可以間接使用查詢長(zhǎng)度作為度量的指標(biāo)，因?yàn)橐婚T(mén)語(yǔ)言之所以簡(jiǎn)單很有可能是因?yàn)樗?jiǎn)潔。這八種數(shù)據(jù)庫(kù)查詢長(zhǎng)度的統(tǒng)計(jì)結(jié)果如下：

如果說(shuō)單純地比較最終的長(zhǎng)度有失偏頗，那么可以看看隨著分析的逐步深入，查詢逐漸變復(fù)雜的過(guò)程中，其修改次數(shù)與長(zhǎng)度之間的關(guān)系：

該圖顯示，經(jīng)過(guò)20次左右的編輯之后，查詢長(zhǎng)度通常會(huì)變?yōu)橹暗?倍，而在100次編輯之后，長(zhǎng)度會(huì)變?yōu)橹暗?倍。那么在修改的過(guò)程中，其編輯次數(shù)與出錯(cuò)的比率又是什么樣子的呢?

從圖中可以看出，PostgreSQL、MySQL和Redshift的錯(cuò)誤率較低，Impala、BigQuery和SQL Server的錯(cuò)誤率較高。另外，和之前一樣，Vertica的錯(cuò)誤率依然最高。

3.分析師技能

此外，Benn Stancil認(rèn)為分析師的技能也很重要。他對(duì)使用多個(gè)數(shù)據(jù)庫(kù)并且在每個(gè)數(shù)據(jù)庫(kù)上至少運(yùn)行了10個(gè)查詢的分析師進(jìn)行了統(tǒng)計(jì)，計(jì)算了這些分析師在每個(gè)數(shù)據(jù)庫(kù)上的查詢錯(cuò)誤率，并根據(jù)統(tǒng)計(jì)結(jié)果構(gòu)建了下面的矩陣：

該矩陣展示的是頂部數(shù)據(jù)庫(kù)與左邊數(shù)據(jù)庫(kù)相比其錯(cuò)誤率的差別，數(shù)值越高表現(xiàn)就越差。例如，Hive和BigQuery交叉處的“20.2”表示：對(duì)使用這兩款數(shù)據(jù)庫(kù)的分析師，其使用Hive的錯(cuò)誤率要比使用BigQuery高20.2。最底部的Total行是結(jié)果總計(jì)，從中可以看出MySQL和PostgreSQL始終表現(xiàn)較好;Vertica跳躍最大，幾乎是從最底部跳到了中游，打敗了SQL Server 和Hive，這也暗示了Vertica的高錯(cuò)誤率很可能是由于分析師的能力而不是語(yǔ)言本身。

最后，Benn Stancil認(rèn)為在分析的這8個(gè)數(shù)據(jù)庫(kù)中，MySQL和PostgreSQL編寫(xiě)SQL最簡(jiǎn)單，應(yīng)用也最廣泛，但與Vertica和SQL Server相比它們的特性不夠豐富，而且速度要慢。綜合各方面的因素，Redshift或許才是最好的選擇。

作者：沉默術(shù)士

想學(xué)習(xí)數(shù)據(jù)分析的小伙伴 添加微信：lovedata19 備注「B站」即可