作者 | Anthony Thong Do 譯者 | 王者 策劃 | 陳思 “數(shù)據(jù)倉庫”這個詞在數(shù)據(jù)分析領域被廣泛使用，但對于剛接觸數(shù)據(jù)分析的人來說，仍然會很經(jīng)常問到這個問題。本文將對數(shù)據(jù)倉庫的定義做一番解釋，并說明為什么以及什么時候需要考慮建立一個數(shù)據(jù)倉庫。什么是數(shù)據(jù)倉庫？

數(shù)據(jù)倉庫是一種分析數(shù)據(jù)庫，用于存儲和處理數(shù)據(jù)，以便對數(shù)據(jù)進行分析。數(shù)據(jù)倉庫的兩個主要功能：存儲分析數(shù)據(jù)和處理分析數(shù)據(jù)。

首先，如果多個業(yè)務數(shù)據(jù)位于不同的數(shù)據(jù)源，就無法輕易地將它們組合在一起。

其次，你的數(shù)據(jù)源系統(tǒng)不適合用來運行大量的數(shù)據(jù)分析，這樣做可能會危及業(yè)務運行，因為它會給系統(tǒng)帶來很重的負載。

數(shù)據(jù)倉庫是分析管道的核心，它有三個主要作用：

• 存儲：在合并 (提取和加載) 步驟，數(shù)據(jù)倉庫將接收和存儲來自多個數(shù)據(jù)源的數(shù)據(jù)。

• 處理：在處理 (轉換和建模) 步驟，數(shù)據(jù)倉庫將處理大部分 (或全部) 由轉換步驟生成的密集處理工作負載。

• 訪問：在生成報告 (可視化和交付) 步驟，首先需要在數(shù)據(jù)倉庫中收集報告，然后將其可視化并交付給最終用戶。

目前，大多數(shù)數(shù)據(jù)倉庫使用 SQL 作為主要的查詢語言。

什么時候需要構建數(shù)據(jù)倉庫？

簡單地說，這取決于公司所處的階段、所擁有的數(shù)據(jù)量和預算，等等。

在早期階段，你可能不需要數(shù)據(jù)倉庫，而是直接使用業(yè)務智能 (BI) 工具連接到生產(chǎn)數(shù)據(jù)庫。

如果你仍然不確定數(shù)據(jù)倉庫是否適合你的公司，請考慮以下幾點：

首先，你是否需要分析來自不同數(shù)據(jù)源的數(shù)據(jù)？

在公司發(fā)展的某個階段，你可能需要將來自不同數(shù)據(jù)源的數(shù)據(jù)組合起來，以便做出更好、更明智的業(yè)務決策。

例如，如果你是一家餐館，想要分析訂單 / 服務員效率比率 (每周里哪個小時員工最忙和最空閑)，就需要將銷售數(shù)據(jù) (來自 POS 系統(tǒng)) 與員工職責數(shù)據(jù) (來自 HR 系統(tǒng)) 結合起來。

對于這些分析，如果數(shù)據(jù)都位于一個中心位置，就會容易得多。

第二，是否需要將分析數(shù)據(jù)與事務數(shù)據(jù)分離？

如前所述，你的事務系統(tǒng)不適合用來進行數(shù)據(jù)分析。因此，如果你在應用程序中收集了活動日志或其他可能有用的信息，那么將這些數(shù)據(jù)存儲到應用程序的數(shù)據(jù)庫中，并讓分析師直接在生產(chǎn)數(shù)據(jù)庫上進行數(shù)據(jù)分析可能不是一個好主意。

相反，購買一個為復雜查詢而設計的數(shù)據(jù)倉庫，并將分析數(shù)據(jù)保存到數(shù)據(jù)倉庫里，這樣會更好。這樣，應用程序的性能就不會受到數(shù)據(jù)分析任務的影響。

第三，原始數(shù)據(jù)源適合用來查詢嗎？

例如，絕大多數(shù) BI 工具不能很好地與 NoSQL 數(shù)據(jù)存儲 (如 MongoDB) 搭在一起使用。也就是說，在后端使用 MongoDB 的應用程序需要將數(shù)據(jù)傳輸?shù)綌?shù)據(jù)倉庫，數(shù)據(jù)分析人員才能夠有效地使用它們。

第四，是否希望提高數(shù)據(jù)分析的查詢性能？

如果事務數(shù)據(jù)有數(shù)十萬行，那么創(chuàng)建匯總表可能是一個好主意，它會將數(shù)據(jù)聚合成容易查詢的表單。如果不這樣做，查詢會非常慢，而且會給數(shù)據(jù)庫帶來不必要的負擔。

如果你對上述任意一個問題的回答是“是”，那么你很可能需要一個數(shù)據(jù)倉庫。

也就是說，在我們看來，構建一個數(shù)據(jù)倉庫通常是個好主意，因為在云計算時代，數(shù)據(jù)倉庫并不貴。

應該選擇哪一個數(shù)據(jù)倉庫？

以下是一些常見的數(shù)據(jù)倉庫，你可以從中選擇：

• 亞馬 Redshift

• 谷歌 BigQuery

• Snowflake

• ClickHouse(自托管)

• Presto(自托管)

如果你才剛開始，還沒有確定的想法，那么建議你使用谷歌 BigQuery，原因如下：

• BigQuery 前 10GB 存儲和前 1TB 查詢量是免費的，之后按使用量付費。

• BigQuery 是全托管的 (無服務器)，不需要啟動或管理物理 (或虛擬) 服務器。

• BigQuery 的架構是可自動伸縮的：根據(jù)查詢的復雜性和數(shù)據(jù)量，BigQuery 將自動確定分配給每個查詢多少計算資源，無需手動調(diào)整。

但是，如果你的數(shù)據(jù)量增長速度很快，或者如果你的場景很復雜或者很特殊，就需要仔細評估你的選項。

下面，我們列出了最為流行的一些數(shù)據(jù)倉庫，目的是讓你對數(shù)據(jù)倉庫領域最常見的選項有一個高層次的了解。這個清單并不是最完整的，也不足以幫你做出一個最完美的決定。

但我們認為，這是一個良好的開端：? ?

名稱開發(fā)商價格

亞馬遜 Redshift	亞馬遜，作為 AWS 產(chǎn)品的一部分	按實例付費，每小時 0.25 美元起(一個月大約 180 美元)
谷歌 BigQuery	谷歌，作為 Google Cloud 產(chǎn)品的一部分	按數(shù)據(jù)查詢和數(shù)據(jù)存儲付費，前 10GB 存儲和前 1TB 查詢量免費
ClickHouse	由 Yandex 開發(fā)，后來開源出來	開源免費，可以部署在自己的服務器上
Snowflake	Snowflake 公司	按使用量付費
Presto	由 Facebook 開發(fā)，后來開源出來，現(xiàn)在由 Presto 基金(Linux 基金的一部分)負責管理	開源免費，可以部署在自己的服務器上

數(shù)據(jù)倉庫與普通 SQL 數(shù)據(jù)庫有什么不一樣？

這個時候，有些人可能會問：

“數(shù)據(jù)倉庫不是像關系數(shù)據(jù)庫一樣，存儲數(shù)據(jù)，然后對數(shù)據(jù)進行分析嗎？難道我就不能使用 MySQL、PostgreSQL、MSSQL 或 Oracle 作為數(shù)據(jù)倉庫嗎？”

簡單地說：可以。

但要細說起來：這個要視情況而定。首先，我們需要了解一些概念。

事務工作負載與分析工作負載

理解這兩種數(shù)據(jù)庫工作負載 (事務工作負載和分析工作負載) 之間的差異是非常重要的。

事務工作負載是指普通業(yè)務應用程序的查詢工作負載。當訪問者在 Web 應用程序中加載一個產(chǎn)品頁面時，將向數(shù)據(jù)庫發(fā)送一個查詢，獲取產(chǎn)品信息，并將結果返回給應用程序。

SELECT * FROM products WHERE id = 123

以下是事務工作負載的幾個常見屬性：

• 每次查詢通常返回一條記錄或少量記錄 (例如，獲取某類別的前 10 篇博文)。

• 事務工作負載通常包含運行時間非常短 (少于 1 秒) 的簡單查詢。

• 在任意時刻都有大量的并發(fā)查詢，這取決于應用程序的并發(fā)訪問者數(shù)量。對于大型網(wǎng)站來說，這個數(shù)字可能是成千上萬或數(shù)十萬。

• 通常對全數(shù)據(jù)記錄感興趣 (例如產(chǎn)品表中的每一列)。

分析工作負載是指用于實現(xiàn)分析目的的工作負載。在生成一個數(shù)據(jù)報告時，一個查詢將被發(fā)送給數(shù)據(jù)庫，計算結果，然后將結果顯示給最終用戶。

SELECT category_name, count(*) as num_products FROM products GROUP BY 1

分析工作負載具有以下屬性：

• 每個查詢通常會掃描表中的大量數(shù)據(jù)行。

• 每個查詢都是重量級的，并且需要很長時間 (幾分鐘，甚至幾小時) 才能完成。

• 并發(fā)查詢并不多，主要由使用分析系統(tǒng)的報告或內(nèi)部人員數(shù)量決定。

• 通常只對幾列數(shù)據(jù)感興趣。

下面是事務工作負載(或數(shù)據(jù)庫)與分析工作負載(或數(shù)據(jù)庫)的比較。

事務工作負載有很多簡單的查詢，而分析工作負載有一些重量級的查詢。

底層架構的不同

由于上述兩種工作負載之間的巨大差異，這兩種工作負載的數(shù)據(jù)庫底層后端設計也是非常不一樣的。事務數(shù)據(jù)庫的優(yōu)化目標是高并發(fā)的快速短查詢，而分析數(shù)據(jù)庫的優(yōu)化目標是長時間運行的資源密集型查詢。

那么它們之間的架構區(qū)別是什么呢？這需要專門的文章才能解釋清楚，不過簡單地說，分析數(shù)據(jù)庫使用以下技術來保證性能：

• 列式存儲引擎：分析數(shù)據(jù)庫不是在磁盤上逐行存儲數(shù)據(jù)，而是將數(shù)據(jù)的列分組存儲。

• 列式數(shù)據(jù)的壓縮：壓縮每個列中的數(shù)據(jù)，獲得更小的存儲和更快的檢索速度。

• 查詢執(zhí)行的并行化：現(xiàn)代分析數(shù)據(jù)庫通常運行在數(shù)千臺機器上。因此，可以將每個分析查詢拆分為多個更小的查詢，并在這些機器之間并行執(zhí)行 (分治策略)。

你可能已經(jīng)猜到了，MySQL、PostgreSQL、MSSQL 和 Oracle 數(shù)據(jù)庫主要用于處理事務工作負載，而數(shù)據(jù)倉庫用于處理分析工作負載。

那么，我可以使用普通的 SQL 數(shù)據(jù)庫作為數(shù)據(jù)倉庫嗎？

就像我們之前說的，可以，但要視情況而定。

如果剛開始時只有少量的數(shù)據(jù)和分析用例，選擇一個普通的 SQL 數(shù)據(jù)庫作為數(shù)據(jù)倉庫是可以的 (最流行的是 MySQL、PostgreSQL、MSSQL 或 Oracle)。如果有很多數(shù)據(jù)，仍然可以這樣做，但需要進行適當?shù)恼{(diào)優(yōu)和配置。

也就是說，隨著像 BigQuery、Redshift 這樣低成本數(shù)據(jù)倉庫的出現(xiàn)，我們建議使用數(shù)據(jù)倉庫。

不過，如果你必須要選擇一個普通的基于 SQL 的數(shù)據(jù)庫 (例如，你的公司只允許數(shù)據(jù)駐留在自己的網(wǎng)絡中)，我們建議使用 PostgreSQL，因為它提供的分析功能最多。

總結

在這篇文章里，我們主要談到了：

• 數(shù)據(jù)倉庫是存儲和處理數(shù)據(jù)的集中式分析數(shù)據(jù)庫。

• 構建數(shù)據(jù)倉庫的四個出發(fā)點。

• 一個簡單的數(shù)據(jù)倉庫技術列表。

• 數(shù)據(jù)倉庫為分析工作負載而優(yōu)化，而傳統(tǒng)數(shù)據(jù)庫為事務工作負載而優(yōu)化。

原文鏈接：

https://towardsdatascience.com/what-is-a-data-warehouse-when-and-why-to-consider-one-2e826be68e95

你也「在看」嗎？?

總結

以上是生活随笔為你收集整理的mssql 为什么连接是sleeping 而不释放_什么是数据仓库，以及我为什么需要它？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。