「大數據之路：阿里巴巴大數據實戰」 讀書心得
Data Acquisition Layer
最底層是數據採集層，主要工作有兩點：
- 日誌採集
- 資料庫數據同步
這邊專注在資料庫數據同步的策略。通常我們會把從 source system 同步到 data warehouse 的第一層稱之為 ODS or Staging layer。
實際作法通常是以 log 去達到 master, slave 的同步，避免直接 query master 造成他的負擔。以 Postgres 為例子，使用 WAL (Write-Ahead Logging) 來 sync 讀寫兩台 db，詳請可以參考下來教學
同步蠻容易遇到效能的問題，以交易的 table 來講，要 sync 就蠻麻煩的，下面是阿里的策略。
而同步到 ODS 常會遇到的經典問題是數據飄移（Data Drift）。通常一筆資料有四個時間戳記：
- modified_time: db 欄位被更新的時間
- log_time: db 的 log 寫入的時間
- proc_time: 具體業務發生的時間
- extract_time: sync 到 ods 的時間
理想上上面四個時間會是一致的，但是基於下面幾種因素常常會讓時間對不上導致 Data Drift：
- 因為 sync 要時間，遲到一下很正常的
- admin 人工修改資料忘記更新 modified_time
- loading 太重導致 log_time 和 modified_time 比 proc_time 還晚
通常的做法是根據其中一種時間來切分 ODS 的表，這樣就會導致 Data Drift。
- extract_time: 飄移最明顯
- modified_time, log_time: 原因如上
- proc_time: 只是該只是該業務的時間，沒有包含其他業務，這樣違背了 ODS 與業務系統保持一致的設計原則
淘寶的解法：通過多個時間戳記來獲取相對準確的數據
雙十一當天的交易數據會被很多人拿放大鏡檢視，所以這部分的數據質量要求特別高。然而在 23:59:59 秒的交易訂單很容易飄移到 11/12，原因是因為呼叫支付寶街口的時候會有延遲，所以整個訂購行為「下單、支付、成功」會出現跨天的狀況，導致 modified_time 和 log_time 都比 proc_time 還晚，淘寶的解法是：
- 用 log_time 取 11/11 最後的 15 分鐘和 11/12 最早的 15 分鐘
- 取最晚的 log_time 和最早的 modified_time，用 proc_time 篩選完只留下 11/11 這天的數據，這個區間內都歸類為 11/11 的數據。
Data Layering
Ref: https://zhuanlan.zhihu.com/p/99800460
名詞解釋：
Fact Table, Dimension Table 的關係圖（參考來源）
- Dimension Table: 以 posts_table 為例子，Posts 這張表因為 post_id 是 primary key 所以就是 Dim
- Fact Table: 以 post_views_table 為例，schema 是 post_id, date, user_id 這樣的 fact。通常 fact table 的 row 數量會超多，然後 column 數量少，因為都用 foreign key 連結到 dimension table。
Data Layering 的五個 Layer：
因為每一家的 Data Layering 有些許差異，所以列了三個還不錯的 reference 供大家參考。
ODS (Operational Data Store)：這層在上面 Data Acquisition 有介紹過，做的事情有 sync 跟處理 Data Drift。另外很多文章都說 ODS 要做數據清理，但是該清多少沒有共識，我個人的理解是他只做 Data Drift 的清理，其他清理給 DWD 做，下面列出其他論點：
- 一派說為了後續可能需要追溯數據問題，因此對於這一層就不建議做過多的數據清洗工作，原封不動地接入原始數據即可，至於數據的去噪、去重、異常值處理等過程可以放在後面的DWD層來做。
- 另一派說這邊要去重、提髒這些，所以大家自行選擇吧
「面向主題的」，數據運營層，也叫ODS層，是最接近數據源中數據的一層，數據源中的數據，經過抽取、洗凈、傳輸，也就說傳說中的ETL之後，裝入本層。本層的數據，總體上大多是按照源頭業務系統的分類方式而分類的。
例如這一層可能包含的數據表為：人口表（包含每個人的身份證號、姓名、住址等）、機場登機記錄（包含乘機人身份證號、航班號、乘機日期、起飛城市等）、銀聯的刷卡信息表（包含銀行卡號、刷卡地點、刷卡時間、刷卡金額等）、銀行賬戶表（包含銀行卡號、持卡人身份證號等）等等一系列原始的業務數據。這裡我們可以看到，這一層面的數據還具有鮮明的業務資料庫的特徵，甚至還具有一定的關係資料庫中的數據範式的組織形式。
但是，這一層面的數據卻不等同於原始數據。在源數據裝入這一層時，要進行諸如去噪（例如去掉明顯偏離正常水平的銀行刷卡信息）、去重（例如銀行賬戶信息、公安局人口信息中均含有人的姓名，但是只保留一份即可）、提臟（例如有的人的銀行卡被盜刷，在十分鐘內同時有兩筆分別在中國和日本的刷卡信息，這便是臟數據）、業務提取、單位統一、砍欄位（例如用於支撐前端系統工作，但是在數據挖掘中不需要的欄位）、業務判別等多項工作。
DWD (Data Warehouse Detail)：在這層會盡量把 dimension table degenerate 回 fact table，reduce the association between fact table and dimension table 是為了節省 join 的時間，也讓後續使用上變得簡單，join 完就會變成大家常講的「寬表」。
DWM (Data WareHouse Middle)：這層通常會根據一下常用的 dimension 做 aggregate 然後算他們的統計指標像是 count, sum 這些，例如時長、次數。
DWS (Data Warehouse Service)：這一層又被稱為 Data Mart 或是 Wide Tables，這邊的 wide table 都會用 service 去劃分，例如訂票、閱讀文章這樣的行為為一張有超多 columns 的表，希望後續的 OLAP 在一種場景下都只會查一張表而沒有 join 的行為出現。
白話一點就是按照主題分類，以電商為例子：商品主題、顧客主題、供應商主題、倉庫主題；以 PyCon 為例子：贊助商主題、會眾主題、志工主題；Dcard 為例：文章主題、廣告主題、用戶主題、電商主題
這一層會只保留這個主題用得到的維度，然後計算更客製化的指標。例如：PyCon 會眾與會次數、Dcard 用戶登入次數、電商用戶的下單次數等等。
注意：在實務中，統計指標如果都是從 DWD or ODS 來算的話，運算量會太大算不完而且維度會太細太瑣碎，所以 general practice 會計算很多小的中繼表放在 DWM，這邊已經有一些 statistical indicators，這樣在計算出 wide tables 時就會快很多，不過在 narrow 跟 wide 之間的界線其實很模糊，所以也可以視情況把 DWM 拿掉只留下 DWS。
ADS (Application Data Store) or APP：我們每天會看的報表就是放在這一層，通常是通用性低，只有跟該業務相關的人才會看這張表，例如：Dice 的 duration, retention、Pycon 會眾、贊助商的 retention。
表不會與其他業務線有所交集。通常可以儲存在 ES, Postgres, Redis 這類 DB，因為 row 數量不多所以撐得住。
DIM：如同上面解釋過的，posts 這張表就是 dimension table，page_view 才是 fact table。
命名 table 的規則：
API Layer
資料越來越多，如果每一張 table 都寫個 API 的話會變得難以維護，這邊可以用 GraphQL 的 API 來解決。
Data Mining Layer
資料都清完也有 API 之後，就可以做 ML 的應用，而 mining 方面的資料可以分成下面幾類：
* 應用層面：
* 個體挖掘應用 e.q. user profiling
* 關係挖掘應用 e.q. lookalike 的 tagging、協同過濾的推薦結果
* 資料粒度方面：
* 特徵數據：這個表放在 Data Mining Layer 的最底層，因為複用性（reusability）高，這邊其實就是 model 要吃的 feature
* 結果數據：model predict 出來的結果就是結果數據囉- FDM（Feature Data Mining Layer）：存 training 常用的 feature，這邊已經去掉 outlier、做過標準化這些，特性是 reusability 高！
- IDM（Individual Data Mining Layer）：介於中間，跟 ADM 有點像但是跟 DWD 很像，包含的欄位較多，介於 result 跟 feature 之間的 table。
- RDM（Relational Data Mining Layer）：word2vec、CF 的結果
- ADM（Application-oriented Data Mining Layer）：放 user profiling 這類的表，或是預測 user 喜歡哪些 category 的表。e.q.
user_id, 興趣, 權重
1 , dog, 0.5
1 , cat, 0.2
元數據（Metadata）
- Technical Metadata: 紀錄這張表的負責人是誰、生命週期、有沒有 partition、SQL、他的 airflow job 在哪、schedule 是多久一次這些
2. Business Metadata: 在每個欄位寫上白話文的描述，解釋這個欄位的意義
