系統設計之事務處理型 Or 分析處理型？

早期，數據庫寫入通常與一筆商業交易（commercial transaction）相對應：如銷售、訂單等。雖然隨數據庫發展到不涉及金錢交易的領域，術語 交易 / 事務（transaction） 仍保留下來，指一組讀寫操作構成的一個邏輯單元。

事務不一定具備 ACID。事務處理只是意味着允許客戶端進行低延遲讀取和寫入，而不是隻能週期運行（如每天一次）的批量處理作業。

即使數據庫開始被用於許多不同類型的數據，如博客評論，遊戲的動作，通訊錄的聯繫人等，但基本訪問模式仍類似處理商業交易。應用程序通常使用索引通過某 K 查找少量記錄。根據用戶輸入新增或更新記錄。由於這些應用程序是交互式的，這種訪問模式被稱爲 在線事務處理（OLTP, OnLine Transaction Processing） 。

但數據庫也越來越多用於數據分析，它們有着很不同的訪問模式。通常，分析查詢需掃描大量記錄，每個記錄只讀取幾列，並計算彙總統計信息（如計數，總和或平均值），而非將原始數據返給用戶。例如，若數據是個銷售交易表，則分析查詢可能包含：

這些查詢通常由業務分析師編寫，並提供給幫助公司管理層做出更好決策（商業智能）的報告。爲將這種使用數據庫的模式和事務處理區分，被稱爲在線分析處理（OLAP, OnLine Analytice Processing）。

表 1：事務處理 V.S 分析系統

K0jOnY

起初，相同數據庫可同時用於事務處理和分析查詢。SQL 在這方面證明是非常靈活：可同時勝任 OLTP 及 OLAP 類型查詢。但 1980s 末和 1990s 初期，公司放棄使用 OLTP 系統用於分析，而是在單獨數據庫上運行分析：數據倉庫。

數據倉庫（data warehouse）

企業可能有幾十個不同交易處理系統：面向終端客戶的網站，控制實體店的收銀系統，跟蹤倉庫庫存，規劃車輛路線，供應鏈管理，員工管理等。這些系統中每個都很複雜，需專人維護，所以系統最終都是彼此獨立運行。

這些 OLTP 系統往往對業務運作至關重要，因而通常要求高可用 與處理事務時 低延遲。所以 DBA 會密切關注他們的 OLTP 數據庫，DBA 一般不願意讓業務分析人員在 OLTP 數據庫上運行臨時分析查詢，因爲這些查詢通常開銷巨大，會掃描大量數據集，這會損害併發執行事務的性能。

相比之下，數據倉庫是個獨立數據庫，分析人員可查詢他們想要的內容而不影響 OLTP 操作。數據倉庫包含公司各種 OLTP 系統的只讀副本。從 OLTP 數據庫（使用週期數據轉儲或連續更新流）中提取數據，轉換成適合分析的模式，清理並加載到數據倉庫中。將數據存入倉庫的過程稱爲 “提取 - 轉換 - 加載（Extract-Transform-Load，ETL）”：

圖 8：數據倉庫和簡化的 ETL 過程

大廠幾乎都有數倉，但小廠卻少聞。可能是因爲小廠沒那麼多不同 OLTP 系統，一般只有少量數據，完全可以在傳統 SQL 數據庫中直接查詢分析，甚至可以在 Excel 分析。而在大廠，做一些在小廠很簡單的事，往往需大量繁重工作。

使用單獨的數倉，而非直接查詢 OLTP 系統進行分析，一大優勢是數倉能針對分析訪問模式進行優化。之前討論的索引算法對 OLTP 工作效果很好，但不擅長應對分析查詢。

OLTP 數據庫 V.S 數據倉庫

數倉的數據模型通常是關係型，因爲 SQL 通常很適合分析查詢。有許多 GUI 數據分析工具可生成 SQL 查詢，可視化結果，並允許分析人員探索數據（通過下鑽，切片和切塊等操作）。

表面上，數倉和關係 OLTP 數據庫相似，因爲它們都有 SQL 查詢接口。但系統內部很不同，它們針對迥然不同的查詢模式，各自進行了優化。許多數據庫供應商都專注支持事務處理或分析工作負載，而不是同時支持。

一些數據庫（如 Microsoft SQL Server 和 SAP HANA）支持在同一產品中支持事務處理和數倉。但它們正在日益成爲兩個獨立的存儲和查詢引擎，這些引擎恰好能通過一個通用 SQL 接口進行訪問。

最近，大量開源的基於 Hadoop 的 SQL 項目出現，雖然還很年輕，但在與商業數倉系統競爭。入 Apache Hive，Spark SQL，Cloudera Impala，Facebook Presto。

星型和雪花型的分析模式

根據應用程序需要，在事務處理領域使用了多種不同數據模型。分析型業務的數據模型則少得多。許多數倉都以相當公式化的方式使用，稱爲星型模式（也稱爲維度建模）。

圖 9 中的模式顯示了可能在食品零售商處找到的數倉。模式的中心是個事實表（該案例中稱爲fact_sales）。事實表的每行表示在特定時間發生的事件（這裏的每行代表客戶購買的產品）。若分析網站流量而非零售量，則每行可能代表一個用戶的頁面瀏覽量或點擊量：

圖 9：用於數據倉庫的星型模式的示例 **

一般事實被捕獲爲單獨事件，因爲這樣之後的分析中獲得最大的靈活性。但是，這意味着事實表可能很大。像蘋果這樣巨頭在數倉可能有幾十 PB 交易歷史，其中大部分保存在事實表。

事實表中的列是屬性，如產品銷售的價格和從供應商處購買的成本（可計算出利潤率），其它列是對其他表（稱爲維度表）的外鍵引用。由於事實表中的每一行都表示一個事件，因此這些維度代表事件的發生地點，時間，方式和原因。

如圖 9 中，其中一個維度是銷售的產品。 dim_product 表中的每行代表一種出售產品，包括庫存單位（SKU），說明，品牌名稱，類別，脂肪含量，包裝尺寸等。fact_sales 表中的每行都使用外鍵表示在特定交易中銷售了哪些產品。（爲簡單起見，如果客戶一次購買幾種不同產品，則它們在事實表中被表示爲單獨行）。

日期和時間通常使用維度表來表示，因爲這允許對日期的附加信息（如公共假期）進行編碼，從而允許查詢區分假期和非假期的銷售。

“星型模式” 名字來源：當表關係可視化時，事實表在中間，被一系列維度表包圍；與這些表的連接就像星星的光芒。

該模板的變體爲雪花模式，其中維度被進一步分解爲子維度。如品牌和產品類別可能有單獨表格，且dim_product 表格中的每行都能再次將品牌和類別作爲外鍵，而不是將它們作爲字符串直接存儲在 dim_product 表。雪花模式比星形模式更規範化，但星形模式是首選，因爲對於分析師，它更簡單。

典型數倉中，表格通常很寬：

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/OX0g2jm1L1gywk0ccYEqgg

猜你喜歡