幾乎每個(gè)人都在以這樣或那樣的方式抱怨數(shù)據(jù)庫的性能問題，數(shù)據(jù)庫管理員和程序員時(shí)常要面臨服務(wù)器資源不夠用或數(shù)據(jù)庫查詢一直執(zhí)行不完的情況。這些情況對(duì)我們來說太正常不過了。

解決辦法多種多樣，最典型的一種就是把槍口指向查詢語句，并譴責(zé)程序員沒能寫出高效的查詢。他們本可以使用恰當(dāng)?shù)乃饕臀锘晥D，或者寫出更好的查詢。你需要增加更多的節(jié)點(diǎn)來緩解這些壓力。在某些情況下，你的服務(wù)器因執(zhí)行太多低效的查詢而過載，你會(huì)考慮為不同的查詢?cè)O(shè)置不同的優(yōu)先級(jí)，這樣那些緊急的查詢(比如CEO要求的查詢)可以得到優(yōu)先處理。如果你使用的數(shù)據(jù)庫不支持優(yōu)先級(jí)隊(duì)列，那么數(shù)據(jù)庫管理員有可能會(huì)取消掉一些查詢，以便騰出資源處理緊急的查詢。

不管你所經(jīng)歷的是哪一種情況，你都深諳其苦，要等待低效的查詢執(zhí)行完畢，或者購買更多的云服務(wù)實(shí)例或更快跟大的服務(wù)器。大多數(shù)人對(duì)傳統(tǒng)的數(shù)據(jù)庫調(diào)優(yōu)和查詢優(yōu)化技術(shù)都很熟悉，這些技術(shù)各有優(yōu)缺點(diǎn)，不過我們不打算在這里討論它們。在這篇文章里，我們將會(huì)討論最近出現(xiàn)的技術(shù)，它們不為眾人所知，但在多數(shù)情況下它們會(huì)為我們帶來更好的性能，幫助我們把握住機(jī)會(huì)。

我們將著重探討三種場(chǎng)景。

場(chǎng)景一(探索性分析)。作為一個(gè)分析師，你通過搗鼓數(shù)據(jù)來挖掘其中的價(jià)值，或者對(duì)業(yè)務(wù)、客戶或服務(wù)進(jìn)行驗(yàn)證測(cè)試。在這些情況下，你一般不知道該關(guān)注哪些方面的問題。你運(yùn)行了一個(gè)查詢，查看結(jié)果，然后決定要不要再運(yùn)行另外一個(gè)查詢。換句話說，你周旋于一系列的探測(cè)性查詢之中，直到找到你想要的結(jié)果。

這些查詢中只有一小部分是有用的，它們可能被用于生成公司報(bào)表、填充表格或?yàn)榭蛻羯蓤D表。不過每次在提交查詢之后，你可能需要等上幾分鐘才能拿到結(jié)果，等待時(shí)間的長短取決于數(shù)據(jù)量的大小以及并發(fā)運(yùn)行的查詢個(gè)數(shù)。在等待結(jié)果期間，你無法決定下一步該做怎樣的查詢，因?yàn)橄乱徊降牟樵円蕾嚿弦粋€(gè)查詢的結(jié)果!

解決方案：在等待結(jié)果期間，你可以立即看到“近似***”的結(jié)果。這里的“近似***”指的是什么?請(qǐng)比較下面的兩個(gè)圖表。

這兩個(gè)圖表分別是同一個(gè)BI工具兩次從后端數(shù)據(jù)庫加載查詢數(shù)據(jù)的結(jié)果。右邊的查詢用了71分鐘從1B的數(shù)據(jù)里得出結(jié)果，而左邊的查詢只用了3秒鐘從1M的數(shù)據(jù)里得出結(jié)果!確實(shí)，跟右邊的結(jié)果相比，左邊的結(jié)果不是很精確。不過這樣做是否值得呢?你可以為了得到完整的結(jié)果等上71分鐘，或者如果不想等，那么可以立即得到一個(gè)幾乎相同的結(jié)果。看著左邊的那副圖，很難想象會(huì)有人認(rèn)為71分鐘的等待是值得的!

當(dāng)然，這并非什么新點(diǎn)子!實(shí)際上，所有的瀏覽器都在使用這種模式。當(dāng)你使用瀏覽器加載一張高分辨率圖片時(shí)，可以看到瀏覽器先是加載一張粗糙的圖片，然后圖片會(huì)慢慢變清晰。不過想到在數(shù)據(jù)庫和SQL查詢上使用這種模式的人并不多。

也許你會(huì)有所疑問：在實(shí)際應(yīng)用當(dāng)中如何實(shí)現(xiàn)這種提速呢?如果數(shù)據(jù)不是正態(tài)分布的可以嗎?還能看到那些特征值嗎?它是否需要一個(gè)特定的數(shù)據(jù)庫?我希望能在這篇文章結(jié)束之前回答所有問題，不過先讓我介紹完其它的場(chǎng)景，在這些場(chǎng)景里你會(huì)看到一些更有意思的想法：以快200倍的速度看到99.9%準(zhǔn)確度的結(jié)果!

場(chǎng)景二(過載的集群)?，F(xiàn)今大多數(shù)數(shù)據(jù)庫用戶都無法擁有自己的專用數(shù)據(jù)庫集群。也就是說，你通常要跟團(tuán)隊(duì)共享集群，或者是其它的報(bào)告和BI工具，它們?cè)谙嗤臄?shù)據(jù)庫資源上執(zhí)行SQL查詢。當(dāng)這些集群發(fā)生過載，那么只有三種結(jié)果：

A. 全局癱瘓。你什么事情都做不了，其他人也一樣。也就是說，一旦數(shù)據(jù)庫請(qǐng)求隊(duì)列被掛起，并且沒有更多的CPU資源可用，那么就沒有人能以他們所期望的速度得到查詢結(jié)果。

B. 部分癱瘓。你可以終結(jié)或掛起一些低優(yōu)先級(jí)的查詢，讓緊急的查詢(例如你的上司要求執(zhí)行的查詢)先執(zhí)行。也就是說，你讓一小部分重要的人開心，但會(huì)讓其他人不高興!

C. 如果經(jīng)常發(fā)生上述情況，你可能會(huì)購買更多更強(qiáng)大的服務(wù)器，或者把系統(tǒng)遷移到云端，根據(jù)實(shí)際情況使用更多的節(jié)點(diǎn)。當(dāng)然，這需要投入更多的錢，而且會(huì)帶來不便，而且這是一個(gè)長期的方案。

很多人不知道還有第四種情況，它比前面兩種更好，而且不像第三種那么費(fèi)錢。那么它是什么?

為低優(yōu)先級(jí)的查詢返回99.9%準(zhǔn)確度的結(jié)果，而為高優(yōu)先級(jí)的查詢返回100%準(zhǔn)確度的結(jié)果!根據(jù)統(tǒng)計(jì)法則，通常使用0.1%的數(shù)據(jù)就可以得到99.9%準(zhǔn)確度的結(jié)果。這就是為什么犧牲0.1%的準(zhǔn)確性卻能換來100到200倍的速度。我知道沒有人愿意接受只有99.9%準(zhǔn)確度的結(jié)果，不過除此以外你所能做的，要么中斷查詢，排很長的隊(duì)等候，要么空等查詢結(jié)束。

在場(chǎng)景一里已經(jīng)提到過，大多數(shù)情況下不需要很長時(shí)間都能夠得到100%準(zhǔn)確度的結(jié)果，但對(duì)于那些需要等待很久的查詢，可以嘗試使用99.9%準(zhǔn)確性的結(jié)果。在文章結(jié)束部分我會(huì)告訴你們“如何”做到這些?，F(xiàn)在只要記住，99.9%的準(zhǔn)確性不代表你會(huì)失去0.1%的結(jié)果。你仍然可以看到所有的東西，只是少了0.1%，而在大多數(shù)時(shí)候你根本無法看出區(qū)別，除非你非常在意。比較下面兩張圖表：

這些查詢結(jié)果來自著名的NYC出租車數(shù)據(jù)集，它們所展示的是到市區(qū)所需要的時(shí)間。

你能分辨出哪個(gè)是100%準(zhǔn)確的結(jié)果，哪個(gè)是99.9%的結(jié)果嗎?對(duì)大多數(shù)人來說，它們是沒有區(qū)別的。但上面那個(gè)查詢只用了1.7秒，而下面那個(gè)用了42.7秒。也就是說，雖然犧牲了0.1%的準(zhǔn)確性，卻節(jié)省了25倍的CPU時(shí)間!讓我們?cè)賮砜匆环N場(chǎng)景，然后我會(huì)告訴你們“如何”做到這些。

場(chǎng)景三(機(jī)器學(xué)習(xí)和數(shù)據(jù)科學(xué))。如果你是一個(gè)機(jī)器學(xué)習(xí)專家或數(shù)據(jù)科學(xué)家，你會(huì)發(fā)現(xiàn)自己經(jīng)常做一些諸如訓(xùn)練統(tǒng)計(jì)模型、參數(shù)調(diào)優(yōu)、特性選型或工程方面的事情。最讓人感到崩潰的是需要逐個(gè)嘗試大量的參數(shù)和特性，而且機(jī)器學(xué)習(xí)模型的訓(xùn)練會(huì)占用很長的時(shí)間。集群總是忙于運(yùn)行和測(cè)試模型訓(xùn)練，數(shù)據(jù)科學(xué)家無法在上面嘗試更多的模型和參數(shù)，因此拖慢了整個(gè)進(jìn)程。

對(duì)于大多數(shù)應(yīng)用來說，你完全可以基于非***的結(jié)果做出合理的決策。比如，A/B測(cè)試、問題根源分析、特性選型、可視化、噪音數(shù)據(jù)或包含缺失數(shù)據(jù)的數(shù)據(jù)集。不過如果你是在財(cái)務(wù)部門工作，那么你應(yīng)該不會(huì)考慮這么做的!

我想另寫一篇文章專門講解如何通過參數(shù)調(diào)優(yōu)和特性選型來提速。

那么，我們“如何”做到只犧牲一點(diǎn)準(zhǔn)確性就可以換來200倍查詢速度的提升?

答案是使用近似查詢處理技術(shù)(AQP)。實(shí)現(xiàn)AQP有很多種方式，最簡(jiǎn)單的做法是使用隨機(jī)取樣數(shù)據(jù)。事實(shí)表明，如果你的數(shù)據(jù)是非正態(tài)的，那么使用隨機(jī)取樣數(shù)據(jù)會(huì)導(dǎo)致大部分特征值丟失，而只有少數(shù)幾個(gè)會(huì)出現(xiàn)在你的原始表里。所以更常用的是一種叫作“分層取樣”的技術(shù)。為什么要分層取樣?考慮以下情況：

假設(shè)你想在這個(gè)表上面運(yùn)行下面的查詢：

SELECT avg(salary)FROM table WHERE city =‘AnnArbor’ 

運(yùn)行這個(gè)查詢是沒有問題的，不過如果這個(gè)表有一億條數(shù)據(jù)或者這些數(shù)據(jù)分布在多個(gè)機(jī)器上，那么這個(gè)查詢可能需要運(yùn)行幾分鐘才能得到結(jié)果。你可以在隨機(jī)的取樣數(shù)據(jù)上運(yùn)行這個(gè)查詢，比如：

因?yàn)锳nn Arbor元組相比原始表里完整的NYC元組會(huì)少很多，所以你從取樣數(shù)據(jù)里可能只能看到少許的幾個(gè)，或者根本看不到。而分層取樣會(huì)先對(duì)數(shù)據(jù)表按照City進(jìn)行分層(例如，分區(qū))，然后針對(duì)每個(gè)City的數(shù)據(jù)進(jìn)行取樣：

不需要太多的統(tǒng)計(jì)數(shù)據(jù)，我們可以看到這樣的分層取樣可以保證得到非常精確的結(jié)果，而我們只使用了原始數(shù)據(jù)的一小部分。

接下來的問題是你該怎么對(duì)數(shù)據(jù)進(jìn)行分層取樣以及如何衡量結(jié)果的準(zhǔn)確性。我在一本書里寫了一個(gè)章節(jié)介紹這方面的內(nèi)容。不過我們可以借助一些工具自動(dòng)完成這些工作。有一些現(xiàn)成的產(chǎn)品可以使用，你只需要按下按鈕，它們會(huì)自動(dòng)幫你完成剩下的工作，并很快地返回結(jié)果。有時(shí)候，根據(jù)這些結(jié)果，你完全可以決定如何在準(zhǔn)確性和速度之間做出權(quán)衡。

BlinkDB/G-OLA

盡管有很多的AQP技術(shù)可選擇，不過BlinkDB仍然可以算是***個(gè)開源的分布式(高并行)AQP引擎。我參與了這個(gè)項(xiàng)目，所以我可能會(huì)偏袒它。我很喜歡BlinkDB的解決方案，我認(rèn)為它給后來出現(xiàn)的學(xué)院派或商業(yè)的解決方案帶來了靈感。Databricks公司接手了BlinkDB后續(xù)的開發(fā)工作(這個(gè)公司把Apache Spark商業(yè)化了)。不久前，Databricks發(fā)布了BlinkDB的一個(gè)插件，這個(gè)插件可以允許用戶對(duì)結(jié)果進(jìn)行隨意的調(diào)整，直到滿意為止。這個(gè)插件叫作G-OLA，不過它并沒有被公開發(fā)布，而且BlinkDB也很久沒有更新了。

SnappyData

SnappyData是一個(gè)開源的內(nèi)存混合分析平臺(tái)，它的引擎同時(shí)支持OLTP、OLAP和流。這個(gè)數(shù)據(jù)庫引擎直接對(duì)Apache Spark進(jìn)行了擴(kuò)展(所以與Spark完全兼容)，并提供了可控的分層取樣和概率性結(jié)構(gòu)來支持AQP。它的查詢語法跟BlinkDB類似，允許用戶指定準(zhǔn)確度，也就是說準(zhǔn)確度是可以調(diào)整的。例如，如果你需要完整的結(jié)果，那么你可以指定100%的準(zhǔn)確度(默認(rèn)就是這樣的)。不過如果你想快點(diǎn)得到結(jié)果，可以使用99%的準(zhǔn)確度，這樣可能在一秒鐘內(nèi)就可以得到結(jié)果。在我看來，SnappyData的一個(gè)優(yōu)勢(shì)是它使用了可控的分層取樣。也就是說，你可以在幾秒內(nèi)運(yùn)行完一個(gè)查詢，就算查詢的是幾T的數(shù)據(jù)，或者查詢是運(yùn)行在筆記本上或在同時(shí)運(yùn)行著幾個(gè)查詢的集群上。SnappyData還內(nèi)置了對(duì)流的支持，你可以實(shí)時(shí)地對(duì)輸入流進(jìn)行取樣。

SnappyData另一個(gè)優(yōu)點(diǎn)是它提供了很多上層的用戶界面，你不需要具備很專業(yè)的統(tǒng)計(jì)知識(shí)也能使用AQP特性。例如，他們現(xiàn)在提供了一個(gè)云服務(wù)，叫作iSight，它會(huì)在后臺(tái)運(yùn)行查詢的同時(shí)使用Apache Zeppelin作為前端來可視化查詢結(jié)果。

爆料：我是SnappyData的推崇者。

Presto

Facebook的Presto有一些實(shí)驗(yàn)性的特性可以滿足基本的近似聚合查詢。我不知道這些特性是否是***的，不過它的不足之處在于你需要使用不一樣的查詢語法(需要修改SQL)才能使用這些特性。對(duì)現(xiàn)有的BI工具和應(yīng)用程序來說，這樣會(huì)有點(diǎn)麻煩，因?yàn)檫@樣就無法體現(xiàn)潛在的提速價(jià)值，除非我們使用新的語法對(duì)原有的查詢進(jìn)行重寫。

InfoBright

InfoBright提供了近似查詢特性(IAQ)。跟其它系統(tǒng)不一樣的是，IAQ完全不使用樣本。可惜的是，對(duì)于IAQ的工作原理，我們也知之甚少，也不知道它是如何提供準(zhǔn)確性保證的。不過通過閱讀他們的博客，我認(rèn)為他們針對(duì)底層數(shù)據(jù)進(jìn)行了建模，然后使用這些結(jié)果代替樣本。IAQ不是開源的，在他們的網(wǎng)站也找不到更多的細(xì)節(jié)信息，不過他們的解決方案看起來挺有意思。

ABS

Analytical Bootstrap System(ABS)是另一款近似查詢引擎，它使用樣本和高效的統(tǒng)計(jì)技術(shù)來檢查錯(cuò)誤。不過它的代碼有點(diǎn)舊了，而且只支持早期版本的Apache Hive。這個(gè)項(xiàng)目目前處在不活躍狀態(tài)。

Verdict

Verdict是一款中間件，它的客戶端端是應(yīng)用程序或BI工具，后端是SQL數(shù)據(jù)庫。你可以像往常一樣在現(xiàn)有數(shù)據(jù)庫上運(yùn)行查詢，并立即得到近似結(jié)果。原則上，可以在任何SQL數(shù)據(jù)庫上使用Verdict，也就是說，它不會(huì)限制你使用特定的關(guān)系型數(shù)據(jù)庫。不過目前它只提供了Spark SQL、Hive和Impala的驅(qū)動(dòng)。它的優(yōu)點(diǎn)在于，它可以通用于任何SQL數(shù)據(jù)庫，而且它是開源的。它的不足之處在于，因?yàn)樗且粋€(gè)中間件，所以它可能不像InfroBright或SnappyData那么高效。

爆料：我是Verdict的設(shè)計(jì)者。

Oracle 12C

Oracle 12C支持近似count distinct和近似百分率。這些近似聚合不僅改進(jìn)了性能而且使用更少的內(nèi)存。Oracle 12C還支持物化視圖，這樣用戶就可以對(duì)近似聚合進(jìn)行預(yù)處理。不過，雖然近似count distinct和近似百分率很有用，也很常用，不過Oracle 12C并沒有提供對(duì)其它類型查詢的支持，不過這些特性已經(jīng)給用戶帶來很大的好處了。不過據(jù)我所知，有很多數(shù)據(jù)庫廠商一直以來都支持count distinct(例如，使用HyperLogLog算法)。這里有一篇論文，如果你對(duì)Oracle 12C的這些新特性感興趣，可以讀一讀。

每一次相遇都是久別重逢。時(shí)隔一年，QCon北京站華麗歸來。20+熱點(diǎn)專題出爐，涵蓋區(qū)塊鏈、VR、TensorFlow、深度學(xué)習(xí)等潮流技術(shù)，及研發(fā)安全、移動(dòng)專項(xiàng)、智能運(yùn)維、業(yè)務(wù)架構(gòu)等一手實(shí)踐。國內(nèi)外技術(shù)專家共襄盛舉，即刻報(bào)名，盡享7折特惠。