【51CTO.com快譯】設(shè)想一下：在沒(méi)有任何索引的情況下，以及數(shù)據(jù)庫(kù)本身并無(wú)調(diào)整選項(xiàng)的情況下，您會(huì)如何優(yōu)化Snowflake數(shù)據(jù)倉(cāng)庫(kù)呢?眾所周知，Snowflake的設(shè)計(jì)非常簡(jiǎn)單，幾乎沒(méi)有提供有關(guān)性能調(diào)整的選項(xiàng)。本文為您總結(jié)了提高查詢(xún)性能的五項(xiàng)優(yōu)秀實(shí)踐。

單獨(dú)地查詢(xún)工作負(fù)載?

最大化吞吐量、以及最小化Snowflake延遲的首選方法莫過(guò)于：對(duì)于工作負(fù)載的查詢(xún)進(jìn)行分離。下圖說(shuō)明了一種常見(jiàn)的Snowflake部署設(shè)計(jì)模式--分離工作負(fù)載(separation of workloads，請(qǐng)參見(jiàn)https://www.analytics.today/blog/what-is-the-ideal-cloud-datawarehouse-platform)。

與其他數(shù)據(jù)庫(kù)系統(tǒng)不同，Snowflake是針對(duì)云端構(gòu)建的。它能夠有效地支持無(wú)限量的虛擬倉(cāng)庫(kù)，即一些獨(dú)立大小的計(jì)算群集。它們可以對(duì)于公共數(shù)據(jù)的存儲(chǔ)進(jìn)行共享式訪(fǎng)問(wèn)。這種EPP(Elastic Parallel Processing，彈性并行處理，請(qǐng)參見(jiàn)https://www.analytics.today/blog/four-stages-that-revolutionised-database-architecture)的架構(gòu)，可以運(yùn)行復(fù)雜的數(shù)據(jù)科學(xué)類(lèi)操作。在針對(duì)相同數(shù)據(jù)進(jìn)行ELT加載、以及商業(yè)智能查詢(xún)時(shí)，該架構(gòu)不會(huì)去爭(zhēng)用任何的資源。

在一般情況下，我們往往需要按照部門(mén)或團(tuán)隊(duì)，來(lái)分離不同的工作負(fù)載。例如：通過(guò)為每個(gè)團(tuán)隊(duì)提供屬于其自己的虛擬倉(cāng)庫(kù)，來(lái)協(xié)助跟蹤團(tuán)隊(duì)的使用情況。而實(shí)際上，最合適的做法應(yīng)該是：按工作負(fù)載的類(lèi)型，而不是用戶(hù)組來(lái)分離工作負(fù)載。這就意味著：在一個(gè)倉(cāng)庫(kù)中，營(yíng)銷(xiāo)用戶(hù)在進(jìn)行商業(yè)智能類(lèi)查詢(xún)的同時(shí)，我們可以運(yùn)行另一個(gè)單獨(dú)的虛擬倉(cāng)庫(kù)，以支持超快的財(cái)務(wù)儀表板式查詢(xún)。

曾經(jīng)在一個(gè)案子中，我們有位客戶(hù)計(jì)劃運(yùn)行十五個(gè)超小型的倉(cāng)庫(kù)，以為每個(gè)團(tuán)隊(duì)提供各自專(zhuān)用的計(jì)算資源。然而，在分析了使用狀況之后，我們將其改成了四個(gè)更大的虛擬倉(cāng)庫(kù)。此法不但可以讓運(yùn)行的成本更低，而且能夠在大幅提高性能的前提下，改善用戶(hù)的體驗(yàn)。

最大化Snowflake緩存的使用

下圖展示了Snowflake是如何自動(dòng)地將數(shù)據(jù)緩存到虛擬倉(cāng)庫(kù)(本地的磁盤(pán)緩存)和結(jié)果緩存(Result Cache)中的。

雖然上述是一種自動(dòng)化行為，但您完全可以通過(guò)如下的兩種優(yōu)秀實(shí)踐，來(lái)最大限度地提高緩存的使用率，并加快查詢(xún)的性能。

首先，在分割查詢(xún)工作的負(fù)載時(shí)，您應(yīng)該能夠讓用戶(hù)在同一個(gè)虛擬倉(cāng)庫(kù)中查詢(xún)到相同的數(shù)據(jù)。如此，那些由某個(gè)用戶(hù)檢索到緩存里的數(shù)據(jù)，也將極有可能被其他人所使用到。

此外，您還應(yīng)該避免在不使用虛擬倉(cāng)庫(kù)時(shí)，草草地暫停虛擬倉(cāng)庫(kù)。默認(rèn)情況下，任何倉(cāng)庫(kù)將在10分鐘后自動(dòng)被掛起，并在有SQL語(yǔ)句需要被執(zhí)行時(shí)才自動(dòng)恢復(fù)。當(dāng)然，您雖然可以將自動(dòng)掛起設(shè)置為幾秒鐘，以節(jié)省資源。但是應(yīng)該注意的是：在恢復(fù)之后，虛擬倉(cāng)庫(kù)的緩存可能會(huì)被清空，這就意味著您將失去原先的緩存性能優(yōu)勢(shì)。

最后，請(qǐng)注意：由于結(jié)果緩存是完全獨(dú)立于虛擬倉(cāng)庫(kù)的，因此，任何用戶(hù)用其帳號(hào)執(zhí)行的任何查詢(xún)，都將會(huì)從結(jié)果緩存中產(chǎn)生完全相同的SQL文本。

縱向擴(kuò)展(Scale Up)，以適應(yīng)大型工作負(fù)載

雖然這并非嚴(yán)格意義上的數(shù)據(jù)庫(kù)調(diào)優(yōu)，但是利用Snowflake的虛擬倉(cāng)庫(kù)功能，來(lái)擴(kuò)展大型工作負(fù)載是非常重要的。

上述的SQL代碼片段說(shuō)明了如何調(diào)整倉(cāng)庫(kù)的大小。本例是一個(gè)能夠處理巨大工作負(fù)載的32個(gè)節(jié)點(diǎn)集群。在測(cè)試中，由于Snowflake維護(hù)著一個(gè)可用的資源池，因此，它需要花費(fèi)幾毫秒的時(shí)間來(lái)實(shí)現(xiàn)部署，而在特別繁忙的時(shí)段，則可能需要幾分鐘的時(shí)間。

在處理完成之后，我們可以簡(jiǎn)單地讓群集在300秒(即，五分鐘)之后自動(dòng)掛起，或者直接在完成任務(wù)后立即暫停群集。如果需要，它可以在另一個(gè)查詢(xún)需要被執(zhí)行時(shí)，自動(dòng)恢復(fù)?？梢?jiàn)，整個(gè)過(guò)程對(duì)于最終用戶(hù)的應(yīng)用程序來(lái)說(shuō)都是透明的。

下面的截圖顯示的是倉(cāng)庫(kù)容量不佳時(shí)的指標(biāo)，它包括了溢出到本地存儲(chǔ)(虛擬倉(cāng)庫(kù)SSD)和遠(yuǎn)程存儲(chǔ)的數(shù)據(jù)量。

在虛擬倉(cāng)庫(kù)中，由于本地存儲(chǔ)始終采用的是快速SSD，因此任何無(wú)法在內(nèi)存中完成的大型排序操作，都將不可避免地溢出到本地存儲(chǔ)之中。那么，如果您看到有大量的數(shù)據(jù)溢出到了外部存儲(chǔ)之中，則表明SSD存儲(chǔ)已經(jīng)被用完，而且那些數(shù)據(jù)正在被寫(xiě)入慢得多的S3或Blob存儲(chǔ)之中?？梢?jiàn)，根據(jù)這兩個(gè)指標(biāo)，我們應(yīng)該考慮調(diào)整到一個(gè)更大的、擁有更多內(nèi)存和本地SSD存儲(chǔ)的虛擬倉(cāng)庫(kù)之中。

橫向擴(kuò)展(Scale Out)并發(fā)

與上述縱向擴(kuò)展不同，橫向擴(kuò)展技術(shù)被用于部署一些相同大小節(jié)點(diǎn)的集群，以達(dá)到目標(biāo)并發(fā)量，即：增加用戶(hù)的數(shù)量，而不是任務(wù)的大小或復(fù)雜性。

上面的SQL片段顯示了在部署針對(duì)多個(gè)集群的橫向擴(kuò)展體系結(jié)構(gòu)時(shí)，所需要的語(yǔ)句。此法并非部署某個(gè)大型的主機(jī)群集，而是讓Snowflake按需添加其他相同大小的群集，直至達(dá)到既定的上限。

我們?cè)谙聢D中所展示的是：將商業(yè)智能虛擬倉(cāng)庫(kù)配置成在其他用戶(hù)執(zhí)行查詢(xún)的時(shí)候，能夠自動(dòng)將群集添加到現(xiàn)有的配置環(huán)境之中。

顯然，這與ELT的倉(cāng)庫(kù)有著明顯的差異，后者被定義為一個(gè)更大的單一化集群，用來(lái)處理復(fù)雜任務(wù)中的各種海量數(shù)據(jù)。

這種調(diào)整方法在英國(guó)食品配送服務(wù)商Deliveroo那里得到成功應(yīng)用。2017年，根據(jù)最終用戶(hù)需要在近20TB的數(shù)據(jù)中，每小時(shí)開(kāi)展7,000多次查詢(xún)的需求，他們使用到了Snowflake的自動(dòng)化橫向擴(kuò)展資源的方式。

由于并發(fā)用戶(hù)的數(shù)量在一天中的不同時(shí)段持續(xù)發(fā)生變化，因此該群集會(huì)自動(dòng)暫停，以實(shí)現(xiàn)Deliveroo只為實(shí)際使用到的計(jì)算資源付費(fèi)。下圖展示了其他群集會(huì)根據(jù)用戶(hù)的使用量，被自動(dòng)添加進(jìn)來(lái)，以及在不需要的時(shí)侯，自動(dòng)暫停的情況。

使用數(shù)據(jù)聚合來(lái)調(diào)整Snowflake

由于使用聚合密鑰(cluster key)可以最大限度地消除分區(qū)，進(jìn)而提高查詢(xún)的性能，因此對(duì)于某些大型數(shù)據(jù)表(通常超過(guò)1 TB)而言，設(shè)計(jì)人員應(yīng)考慮通過(guò)定義聚合密鑰，來(lái)最大化查詢(xún)的性能。

為了說(shuō)明使用聚合調(diào)整給Snowflake帶來(lái)的性能優(yōu)勢(shì)，我們針對(duì)TPC(Transaction Processing Council)表的STORE_SALES設(shè)置了一項(xiàng)基準(zhǔn)測(cè)試，該表容量有1.3Tb，其中保存了近300億行銷(xiāo)售數(shù)據(jù)。接著，我們針對(duì)該表的聚合版本和非聚合版本，運(yùn)行了相同的查詢(xún)，下圖是兩項(xiàng)結(jié)果的對(duì)比。

通過(guò)在SS_SOLD_DATE_SK列上放置聚合密鑰，并按日期進(jìn)行過(guò)濾，整體查詢(xún)的運(yùn)行速度提高了14倍，并且只掃描了近1/30的數(shù)據(jù)。

下面的圖表進(jìn)一步說(shuō)明了Snowflake聚合的效果，其中涉及到的數(shù)據(jù)是在語(yǔ)句中對(duì)WHERE by DATE進(jìn)行過(guò)濾后產(chǎn)生的。

由于數(shù)據(jù)是按照日期進(jìn)行加載的，因此它們往往能夠自然聚集，即同一天的所有數(shù)據(jù)都屬于同一個(gè)微分區(qū)。但是，如果執(zhí)行以下SQL語(yǔ)句，Snowflake將會(huì)把所有銷(xiāo)售日期都保留在同一個(gè)微分區(qū)中。而在需要時(shí)，后臺(tái)任務(wù)將自動(dòng)重新聚類(lèi)數(shù)據(jù)，并將用到的計(jì)算處理資源按照單獨(dú)的項(xiàng)目進(jìn)行計(jì)費(fèi)。

由于Snowflake掌握了每個(gè)微分區(qū)中、每列的最小和最大值，因此它可以直接跳過(guò)那些與查詢(xún)條件完全不匹配的微分區(qū)。為了演示該聚合的性能效果，我們創(chuàng)建了一個(gè)包含有6億行和16Gb壓縮數(shù)據(jù)的表。該表由一個(gè)唯一性的密鑰(ORDER_KEY)所標(biāo)識(shí)，因此我們將其表示為聚類(lèi)密鑰。

通過(guò)執(zhí)行上述查詢(xún)，我們?cè)?億行的正好中間找到了目標(biāo)記錄，其返回的時(shí)間為88毫秒。如下面的Snowflake Query Profiler截圖所示，速度快的主要原因在于：該查詢(xún)只掃描了整個(gè)16Gb壓縮數(shù)據(jù)中的1.5Mb，而且除了一個(gè)微分區(qū)之外，它幾乎跳過(guò)了所有不相關(guān)的內(nèi)容。

可見(jiàn)，只要使用到了聚類(lèi)密鑰，Snowflake就能夠跳過(guò)多達(dá)99.91%的數(shù)據(jù)，進(jìn)而避免了任何與需要維護(hù)傳統(tǒng)索引相關(guān)的性能、以及數(shù)據(jù)管理的開(kāi)銷(xiāo)。

結(jié)論

綜上所述，雖然可供調(diào)整Snowflake性能的選項(xiàng)寥寥無(wú)幾，但是我們可以通過(guò)上述優(yōu)秀實(shí)踐來(lái)最大化查詢(xún)的性能、以及吞吐量。

原文標(biāo)題：Snowflake Performance Tuning: Top 5 Best Practices，作者：John Ryan

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】