99999久久久久久亚洲,欧美人与禽猛交狂配,高清日韩av在线影院,一个人在线高清免费观看,啦啦啦在线视频免费观看www

熱線電話：13121318867

登錄
首頁(yè)精彩閱讀什么數(shù)據(jù)庫(kù)最適合數(shù)據(jù)分析師
什么數(shù)據(jù)庫(kù)最適合數(shù)據(jù)分析師
2016-01-13
收藏

數(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ě)查詢(xún)的難易程度。最近，Mode的首席分析師Benn Stancil發(fā)布了一篇文章，從另一個(gè)角度闡釋了哪一款數(shù)據(jù)庫(kù)最適合數(shù)據(jù)分析師。

Benn Stancil認(rèn)為數(shù)據(jù)分析工作不可能一蹴而就，分析師在使用數(shù)據(jù)庫(kù)的過(guò)程中阻礙他們速度的往往不是宏觀上的性能，而是編寫(xiě)查詢(xún)語(yǔ)句時(shí)的細(xì)節(jié)。例如，在Redshift中如何獲取當(dāng)前時(shí)間，是NOW()、CURDATE()、CURDATE、SYSDATE 還是WHATDAYISIT。在Mode公司，分析師每天都會(huì)使用各種不同的語(yǔ)言編寫(xiě)幾千個(gè)查詢(xún)，運(yùn)行在Mode編輯器里的查詢(xún)超過(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)行了比較。

首先，Benn Stancil認(rèn)為查詢(xú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ù)查詢(xún)錯(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不是，后三者的用戶(hù)通常是有充足分析預(yù)算的大型企業(yè)，其較高的錯(cuò)誤率很有可能是由于使用更深入而不是語(yǔ)言“更難用”。

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

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

該圖顯示，經(jīng)過(guò)20次左右的編輯之后，查詢(xún)長(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ò)誤率依然最高。

此外，Benn Stancil認(rèn)為分析師的技能也很重要。他對(duì)使用多個(gè)數(shù)據(jù)庫(kù)并且在每個(gè)數(shù)據(jù)庫(kù)上至少運(yùn)行了10個(gè)查詢(xún)的分析師進(jìn)行了統(tǒng)計(jì)，計(jì)算了這些分析師在每個(gè)數(shù)據(jù)庫(kù)上的查詢(xún)錯(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ù)據(jù)分析咨詢(xún)請(qǐng)掃描二維碼

若不方便掃碼，搜微信號(hào)：CDAshujufenxi

數(shù)據(jù)分析師資訊
更多

OK
客服在線
立即咨詢(xún)
客服在線
立即咨詢(xún)
') } function initGt() { var handler = function (captchaObj) { captchaObj.appendTo('#captcha'); captchaObj.onReady(function () { $("#wait").hide(); }).onSuccess(function(){ $('.getcheckcode').removeClass('dis'); $('.getcheckcode').trigger('click'); }); window.captchaObj = captchaObj; }; $('#captcha').show(); $.ajax({ url: "/login/gtstart?t=" + (new Date()).getTime(), // 加隨機(jī)數(shù)防止緩存 type: "get", dataType: "json", success: function (data) { $('#text').hide(); $('#wait').show(); // 調(diào)用 initGeetest 進(jìn)行初始化 // 參數(shù)1：配置參數(shù) // 參數(shù)2：回調(diào)，回調(diào)的第一個(gè)參數(shù)驗(yàn)證碼對(duì)象，之后可以使用它調(diào)用相應(yīng)的接口 initGeetest({ // 以下 4 個(gè)配置參數(shù)為必須，不能缺少 gt: data.gt, challenge: data.challenge, offline: !data.success, // 表示用戶(hù)后臺(tái)檢測(cè)極驗(yàn)服務(wù)器是否宕機(jī) new_captcha: data.new_captcha, // 用于宕機(jī)時(shí)表示是新驗(yàn)證碼的宕機(jī) product: "float", // 產(chǎn)品形式，包括：float，popup width: "280px", https: true // 更多配置參數(shù)說(shuō)明請(qǐng)參見(jiàn)：http://docs.geetest.com/install/client/web-front/ }, handler); } }); } function codeCutdown() { if(_wait == 0){ //倒計(jì)時(shí)完成 $(".getcheckcode").removeClass('dis').html("重新獲取"); }else{ $(".getcheckcode").addClass('dis').html("重新獲取("+_wait+"s)"); _wait--; setTimeout(function () { codeCutdown(); },1000); } } function inputValidate(ele,telInput) { var oInput = ele; var inputVal = oInput.val(); var oType = ele.attr('data-type'); var oEtag = $('#etag').val(); var oErr = oInput.closest('.form_box').next('.err_txt'); var empTxt = '請(qǐng)輸入'+oInput.attr('placeholder')+'！'; var errTxt = '請(qǐng)輸入正確的'+oInput.attr('placeholder')+'！'; var pattern; if(inputVal==""){ if(!telInput){ errFun(oErr,empTxt); } return false; }else { switch (oType){ case 'login_mobile': pattern = /^1[3456789]\d{9}$/; if(inputVal.length==11) { $.ajax({ url: '/login/checkmobile', type: "post", dataType: "json", data: { mobile: inputVal, etag: oEtag, page_ur: window.location.href, page_referer: document.referrer }, success: function (data) { } }); } break; case 'login_yzm': pattern = /^\d{6}$/; break; } if(oType=='login_mobile'){ } if(!!validateFun(pattern,inputVal)){ errFun(oErr,'') if(telInput){ $('.getcheckcode').removeClass('dis'); } }else { if(!telInput) { errFun(oErr, errTxt); }else { $('.getcheckcode').addClass('dis'); } return false; } } return true; } function errFun(obj,msg) { obj.html(msg); if(msg==''){ $('.login_submit').removeClass('dis'); }else { $('.login_submit').addClass('dis'); } } function validateFun(pat,val) { return pat.test(val); }