前言

資料服務的架構大致在前面幾篇都介紹完了，這篇算是來把前面的大元件的關係、服務設計做一個統整收尾，今天會先簡單介紹資料倉儲的三層式架構，然後再跟大家分享我們的架構設計。

Data Warehouse 的三層式架構

在打造資料服務、提供分析洞察前，一個好的Data Warehouse (資料倉儲) 的架構很重要，他能提供給你分析上的彈性，支援變化快速的業務需求，也能幫助你減少重複性資料查詢的負擔。

這裡有幾個比較常見的名詞，有時候會混用：

Data Lake 資料湖

Data lake 主要是用來集中儲存各種不同資料源的地方，他能匯集結構化、非結構化的資料，存放的是原始數據，不在這一層做清理和轉換。

我們的定義就是存放未經處理的原始數據。

Data Warehouse 資料倉儲

Data Warehouse 是一個專門為報告和數據分析做好事先準備的中央廚房，通常儲存結構化數據，數據會從資料湖中被讀取出來，經過轉換、清洗和整理，最後儲存到資料倉儲。

這裡常用的一個設計模式叫做 Dimensional Modeling，中文翻譯是維度建模，目的是將原先設計給 OLTP 的資料格式去正規化，轉成適合 OLAP 分析使用的資料結構設計，讓 JOIN 次數可以減少，常見的模式有 Star Schema、Snowflake Schema，這個設計非常重要，需要結合產品與業務情境，也考量當前的資料表設計，預計在接下來的幾篇做比較深入的分享。

我們的定義是存放轉換後的Dimension Tables & Fact Tables。

Data Mart 資料超市

Data Mart 是一個提供給數據使用者的資料庫，會從 Data Warehouse 設計好的材料區，快速取用所需要的歷史資料與屬性，彙整放到第三層的資料超市，提供特定的業務部門或應用情境使用，如產品留存、銷售狀況等，用來支援部門層級的決策分析。

我們的定義是存放針對特定情境需求，做完彙整的最終資料表。

彙整目前的資料架構設計

把最後 OLAP 的資料結構設計講完，接著就用我們的資料流架構來做這幾天文章聊到的觀念做的彙整：

Data Sources

我們在產品上有 MySQL, MongoDB 兩個資料庫，專責提供給系統服務使用，裡面有紀錄當前狀況的資料表，也有紀錄登入記錄的紀錄型資料表。
另外有Google Analytics、Amplitude 等用來追蹤產品使用狀況的第三方數據追蹤工具，這邊的資料會是以 event logs 的形式取得。

Data Pipeline: ELT + Airflow

在資料的處理，我們選擇ELT這樣的做法，讓我們可以較輕量的維運我們的資料建設，並且透過Airflow 來幫助我們做到在 Data Warehouse 裡面資料轉換的複雜相依關係，並即時監控失敗的資料任務，幫助我們能第一時間反應和處理。

Data Warehouse

我們在 Data Warehouse 的選擇是GCP BigQuery ，原因是Google提供給end user 的服務對公司同仁比較熟悉，也能結合 Google Sheet 工具來強化和營運單位的工作流；另一個原因是AWS Redshift 的啟動成本比較高，沒記錯當時一個月開一台機器的費用大約落在1800美金，而BigQuery 是依據查詢量 (TB) 來計算，每 TB $5美金。

我們的資料源會先匯集到 Google Cloud Storage(GCS)，以檔案的方式儲存，接著再匯入到 GCP BigQuery 中做Warehouse 和 Mart 的分層處理，基本上在GCS到BigQuery這段的載入，會先做格式的處理，讓他能被正確餵入資料表，但我們不做任何的轉換，因為BigQuery 能吃結構化和半結構化的資料，以我們的資料源來說都能順利被讀取進去。

在BigQuery 中我們就會切成三層 Lake, Warehouse 以及Mart，主要的轉換工作都在這三層這間做處理，就是前面提到的 Dimensional Modeling設計，最後透過Data Mart 去連結 Business Intelligence 工具，或是依據需求產出報表、分析用的數據給需求單位、資料服務。

以上是我們一個階段性的架構版本，中間遇到的困難和問題就如同前幾篇文章的內容:

1. ETL vs. ELT
2. 我們真的需要 OLAP嗎？
3. 深入瞭解MySQL的瓶頸，分析真的不好用嗎？
4. OLAP工具怎麼選？
5. 資料流的相依關係很複雜，cron job 不夠用
6. 越切越多層，資料到底要切幾層？

小結

今天的文章先簡單介紹了分析的三層式結構 Data Lake, Data Warehouse 以及 Data Mart，也如前面說的這些名詞有時候蠻容易混用，但對我來說比較重要的是三層架構，三層架構基本上算是能滿足分析的切分需求也方便管理，分得太多容易不知道哪張表該放在哪裡，最後越來越亂。

而Dimensional Modeling 我認為是在資料工程裡，針對分析設計非常重要的一環，接下來我打算分幾天來聊聊維度建模的觀念和設計，當然還有我們的慘痛經驗。