應該使用哪種資料倉儲？
您選擇哪種資料倉儲取決於您要處理多少資料。本指南將引導您了解各種選項，無論您是小型新創公司還是大型企業。
為組織或專案設定分析系統時，您需要找出資料的儲存位置。雖然沒有萬能的解決方案，但我們會為您提供資料倉儲可用選項的概略地圖，目標是協助您找到最符合預算、預期處理資料量和效能需求的解決方案。
以下是我們為小型新創公司及以上規模的公司精選的最佳資料倉儲軟體列表。
1. 您的應用程式資料庫
最簡單的選項就是使用目前儲存您資料的生產資料庫，無論是 Web 應用程式、行動應用程式或原生桌面應用程式（而非 Metabase 自己的 應用程式資料庫）。
常見範例
| 優點 | 缺點 |
|---|---|
| 您的資料倉儲已存在。 | 分析工作負載可能會拖慢您的應用程式速度。 |
| 只需要處理一個資料庫伺服器。 | 資料結構描述通常難以用於分析。 |
| 無需轉換資料或移動資料。 | 在平衡兩種截然不同的使用模式時，擴充變得困難。 |
將資料庫同時用作生產資料庫和資料倉儲通常是「實際」應用程式的初步階段，但如果您正在建構小型內部應用程式、MVP 或原型，則在單一資料庫上加倍使用是可行的選擇。一旦您準備好啟動（針對消費者應用程式），您可能會想要將此設定遷移到以下更具擴充性的選擇。如果您尚未為您的應用程式選擇資料庫，請確保它支援讀取複本，這將我們帶到下一個選項
2. 您的應用程式資料庫的讀取複本
如果您的主要資料庫支援讀取複本，那麼您可以做的最簡單的事情就是建立主要資料庫的讀取複本，也就是生產資料庫的副本。您也可以設定另一個命名空間以包含您的第三方資料或事件，並稱之為勝利。
| 優點 | 缺點 |
|---|---|
| 您不需要管理不同類型的資料庫。 | 針對交易負載最佳化的資料庫通常不是分析的最佳選擇 |
| 無需轉換資料或移動資料。 | 您需要管理另一個資料庫伺服器。 |
| 您可以獨立擴充分析和交易負載。 | 資料結構描述通常難以用於分析。 |
通常，一旦您開始認真對待分析，並且您的規模擴大（無論是在資料量還是分析查詢的複雜性方面），遷移到專用資料倉儲都有顯著的效能優勢。
3. 執行與您的應用程式相同類型的資料庫
如果您的規模不需要您在多部機器上執行資料庫，您可以將用於應用程式資料庫的相同類型資料庫用作專用分析資料倉儲（例如，如果您為您的應用程式使用 PostgreSQL，您可以使用另一個 Postgres 資料庫來儲存您的分析資料）。此設定與前一個設定的不同之處在於，此資料倉儲不僅僅是您資料庫的讀取複本；而是針對分析工作負載進行了調整。此調整涉及設定資料庫的設定，以及重塑資料在表格中的佈局方式，以使分析查詢更快、更易於撰寫。
| 優點 | 缺點 |
|---|---|
| 您只需要管理一種資料庫。 | 您需要管理另一個資料庫伺服器。 |
| 您可以獨立擴充分析和交易負載。 | 針對交易負載最佳化的資料庫通常不是分析的最佳選擇。 |
| 您可以針對您的分析工作最佳化資料模型/結構描述。 | 您需要移動資料（並轉換資料）。 |
| 這些資料庫通常僅限於單一節點，這會影響擴充性。 |
此設定可以讓您走得很遠。一旦您達到常見查詢需要幾分鐘或更長時間的地步，您就應該評估效能更強大的選項。
4. 基於 SQL 的分析資料庫
在這裡，我們將深入探討專為分析工作負載設計的資料庫。 「一般」資料庫軟體與用於大量分析工作負載的資料庫之間的主要區別在於平行化和資料格式。您經常會看到線上交易處理資料庫 (OLTP) 和線上分析處理資料庫 (OLAP) 這兩個術語。這些是 OLAP 資料庫。
OLAP 與 OLTP 的差異
為了清楚說明 OLAP 和 OLTP 資料庫之間的差異：交易 (OLTP) 工作負載通常有許多小型讀取、寫入和更新。對於給定的公司而言，這些工作負載可以在單一機器上存活的時間遠長於分析工作負載。相比之下，分析 (OLAP) 工作負載的讀取操作較少，但這些讀取會觸及更大的資料量。
- 交易工作負載範例：擷取單一使用者的上次登入時間，以便在應用程式中向他們顯示。
- 分析工作負載範例：查詢過去三個月每天的使用者登入總數，以建立折線圖。
交易資料庫通常以列格式儲存資料。例如，假設我們有一個包含使用者記錄的表格，每個使用者記錄都包含其姓名、地址、上次登入時間和出生日期。交易資料庫會將這四個欄位全部儲存在一個單元中，這使資料庫能夠非常快速地檢索（或更新）該記錄。
相反地，分析資料庫傾向於使用欄式儲存，將所有姓名儲存在一起，將所有上次登入時間儲存在一起，依此類推。欄式儲存使「我們使用者群的平均年齡是多少？」之類的操作變得容易，因為資料庫可以忽略資料庫中除出生日期欄位之外的所有資料。透過減少資料庫需要掃描的資料量，欄式儲存顯著提高了分析查詢的效能。不利的一面是，欄式儲存在交易工作負載方面不是那麼出色。
託管式基於 SQL 的分析資料庫選項
如果您沒有太多內部資料庫管理專業知識，那麼作為服務的基於 SQL 的分析資料庫可能非常划算。這個領域競爭非常激烈，因此這裡的一般共識是，您應該只使用您目前的雲端供應商提供的選項，但如果您正處於這個階段，那麼可能是時候貨比三家，看看是否可以獲得更好的交易。這些資料倉儲的主要挑戰是將資料導入其中可能很複雜。效能在所有選項中相對可比，因此請對顯示某個解決方案顯著優於其他解決方案的基準測試持懷疑態度。
| 優點 | 缺點 |
|---|---|
| 專為分析查詢設計。 | 可能很昂貴。 |
| 可擴充。 | 定價可能難以預測。 |
| 經過實戰考驗。 | 導入資料很麻煩。 |
以下是一些主要的資料倉儲
Redshift - 亞馬遜網路服務
Redshift 是亞馬遜網路服務 (AWS) 託管的資料倉儲。它通常是整體而言最便宜且最簡單的選項。您必須手動佈建叢集，但您將獲得更可預測的定價，因為您將是「購買」更多機器時間的人。最近，AWS 在 Redshift 產品中新增了 RA3 執行個體，讓您可以分離運算和儲存，類似於 Big Query 和 Snowflake 等選項。當與 AWS Aqua 結合使用時，您可以顯著提高效能。
BigQuery - Google 雲端平台
一段時間以來，BigQuery（在內部和研究文獻中稱為 Dremel）一直是 Google 的半秘密武器之一。它速度很快，而且 BigQuery 不像在伺服器上執行 Postgres 那樣按機器付費，而是抽離了基礎架構，而是根據您的資料量以及查詢使用的 CPU/IO 量向您收費。它過去使用自訂的 SQL 方言，但自 2.0 版以來，它已切換到 標準 SQL。 BigQuery 還透過 BigQuery ML 提供內建的機器學習功能。按運算和儲存付費的不利之處在於定價可能較難以預測。
Snowflake - 可託管，或在其他供應商上使用
Snowflake 是最受歡迎的資料倉儲之一。它的優點是速度快（有些人聲稱他們的運算最佳化使他們成為最快的），而且您不需要擴充 Snowflake，因此無需擔心佈建機器。缺點是它很昂貴。
Vertica - 託管服務或自行執行
Vertica 提供免費的社群版，限制為 3 個節點和 1 TB 資料，商業版則以 Docker 映像和透過 Kubernetes 提供，沒有這些限制。
專有分析資料庫
有各種針對分析工作負載最佳化的複雜（且昂貴）資料庫解決方案。如果您正在閱讀本指南，那麼您很可能沒有打算與資料庫供應商進行 6 到 7 位數的交易。
| 優點 | 缺點 |
|---|---|
| 如果您需要協助（並且可以付費），則具有強大的服務組件。 | 昂貴。 |
| 有些具有內部部署選項或託管。 | 您需要管理另一個資料庫伺服器。 |
| 長期的營運歷史和複雜部署的經驗。 | 通常設定和管理非常複雜。 |
範例
5. 超越資料倉儲：資料湖和湖倉
在這裡，選項數量開始失控。如果您是一家處理大量規模的公司，您可以考慮建構專用的資料管線，使用資料湖：一個儲存所有資料（包括結構化和非結構化資料）的地方。這裡的重點是，圍繞資料湖建構管線將需要組建一支（昂貴的）資料工程師團隊。此時，您將使用事件（例如應用程式開啟、按鈕點擊）來檢測您的應用程式，根據需要修飾該資料（例如將其他相關詳細資訊新增至事件，例如使用者工作階段詳細資訊），然後將清理後的資料傾印到廉價儲存空間（例如 AWS 的 S3 (Simple Storage Service)，通常採用 parquet 之類的格式）。這個物件儲存區就是您的資料湖。
您的使用者通常不會直接查詢資料湖。相反，您將使用 擷取轉換載入 (ETL) 操作，根據需要建立資料的「結構」。您將使用 Presto 之類的查詢引擎在資料湖上執行 ETL 查詢，目標是將資料組織成表格，以預測您的業務將提出的問題類型。這些查詢引擎允許您像查詢關係資料庫一樣查詢 S3 之類的物件儲存區 - 這就像使用 SQL 查詢檔案系統。
您可以使用 有向無環圖 (DAG) 來排程和執行這些 ETL：Airflow 在這裡派上用場。您的 ETL 的想法是產生事實表格和維度表格，以及列出彙總資料（每日訂單數、平均工作階段持續時間或其他任何內容）的摘要表格。 ETL 產生的表格將來自多個來源的大量資訊結合在一起，這將有助於企業做出決策（例如，您想了解的有關訂單或產品的所有資訊，等等）。這就像即時建構您的資料倉儲。
您也可以將這些 ETL 表格傾印回您的資料湖，或者 - 如果您真的需要快速儀表板 - 傾印到 Druid 之類的記憶體內資料庫。
| 優點 | 缺點 |
|---|---|
| 可以擴充到龐大的資料集。 | 資料工程師和管線服務很昂貴。 |
| 彈性，無需預先定義結構描述。 | 您正在承擔許多移動部件的複雜性。 |
混合資料湖和資料倉儲為我們帶來了湖倉，這是一種旨在為資料湖提供一些結構的架構，目標是減少管理並讓分析工具更直接地存取資料。
一些用於處理資料湖設定的熱門工具
- Presto 開源查詢引擎，可讓您使用 SQL 查詢檔案儲存區
- Athena。 AWS 的無伺服器互動式查詢服務。
- Spark SQL。在 Parquet 格式或 Hive 表格中的資料上執行 SQL 查詢。
- Azure 資料湖儲存體.
- Databricks
- AWS 上的資料湖 資料湖設定概觀。
- Airflow 用於排程 ETL。
- Druid。記憶體內資料庫，用於儲存您的 ETL 表格以進行分析查詢。
- Pinot 專為即時分析而建構的 OLAP 資料庫。源自 LinkedIn，現在隸屬於 Apache。
延伸閱讀
下一步：ETL、ELT 與反向 ETL
如何將來自多個來源的資料導入您的資料倉儲，然後如何透過將您的見解推送到您可以利用它們的地方來運作這些資料。