身為數(shù)據(jù)分析師最重要的決定—適合的數(shù)據(jù)庫

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

Benn Stancil認(rèn)為數(shù)據(jù)分析工作不可能一蹴而就，分析師在使用數(shù)據(jù)庫的過程中阻礙他們速度的往往不是宏觀上的性能，而是編寫查詢語句時的細(xì)節(jié)。例如，在Redshift中如何獲取當(dāng)前時間，是NOW()、CURDATE()、CURDATE、SYSDATE 還是WHATDAYISIT。在Mode公司，分析師每天都會使用各種不同的語言編寫幾千個查詢，運行在Mode編輯器里的查詢超過百萬個，而Benn Stancil就是從這些數(shù)據(jù)出發(fā)，對MySQL、PostgreSQL、Redshift、SQL Server、BigQuery、Vertica、Hive和Impala這八款數(shù)據(jù)庫進(jìn)行了比較。

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

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

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

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

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

數(shù)據(jù)庫" style="width:479.25pt; height:199.5pt;visibility:visible;mso-wrap-style:square">

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

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

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

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