Transaction Processing or Analytics?

每一個資料庫都能許多種不同型態的資料，如 blog 貼文、遊戲資料、聯絡人資訊等等，應用系統存取這些資料都是為了公司的商業目的，通常都需要用 key 快速查找資料、使用 index 加速、會依 user 不同的輸入而寫入資料庫，系統是能跟 user 互動的，這種資料存取模式一般稱為 online transaction processing (OLTP) ，

一筆交易 (transaction) 不代表它一定要符合 ACID 特性 (atomicity, consistency, isolation 和 durability)，transaction processing 意味著快速寫入和讀取的操作，即時性要求高，反之則是 batch processing，意味者它每隔一段時間執行。

然而，有商業資料以後管理層就需要去看一些統計指標，也就代表需要有人去分析資料，例如：

• 某個寵物商品與哪個商品最常被組合購買？
• 各子公司的 YOY 成長。
• 某間店每月的毛利額。

這些查詢通常是為了某種目的做的商業分析，能幫助管理階層做出更好的決策，這是另一套不同的資料存取模式，一般稱為 online analytic processing (OLAP)，OLTP 和 OLAP 比較難明確、清楚的分割，但我們可用下表列出在一些他倆的特點：

在有一定規模的公司裡，面對 OLAP 這種分析用面向的資料模式，通常我們會為它建立另外一套資料庫，這資料庫稱做 data warehouse。

Data Warehouse (資料倉儲)

公司可能會有數十個不同的 OLTP 系統，可能有網站、供應商系統、客服系統、ERP 系統等等，OLTP 就應該專注處理交易 (transaction)，所以分析面向用的 OLAP，就需要透過一些方法將不同的 OLTP 資料匯集至 data warehouse 中 (read-only 複製)， 重要的是絕對不能影響 OLTP 資料庫，至於怎麼做呢？

第一步會從 OLTP 資料庫擷取 (Extract)資料，第二步是轉換 (Transform) 成分析友善的 schema、資料清理，最後一步則是載入 (Load) 至 data warehouse 中，這個處理過程就是常聽到的 ETL (Extract-Transform-Load)，如下圖說明：

用分隔的資料庫作分析有幾個好處：

1. 能設計對分析友善的 schema。
2. 不影響面向交易 OLTP 資料庫的效能。
3. 能針對 data warehouse 資料庫做面向分析的 index 演算法優化。

Fact Table

直接用下圖說明，在 data warehouse 做分析時，通常會有一個主要的資料表稱 fact table ，這也是主要拿來做計算的 measure table，每一列資料都要有該 event 的發生時間，圖中的例子是銷售資料 ( fact_sales )，然後用 foreign key 連出來的那些資料表稱 dimensional table，通常是表示為 evemt 的 who, what, where, when, how 和 why。

若我們的 fact table 有十幾億筆資料該怎辦，該如何讓 OLAP 查的快速，明天會講 Column-Oriented Storage 的原理。

而我們數據團隊用的 fact table 就是整個 ETtoday 全站的瀏覽行為，所有的標籤、行為分析、dashboard 都是從這張 fact table 出發！我們用 Hadoop 做我們的 data warehouse，然後使用 Spark 做 ETL 與資料查詢，目前已有 100 多億筆資料，我們也是使用 Column-Orinted Storage 來存這些資料。