什麼是OLAP
數據處理大致可以分成兩大類：聯機事務處理OLTP（on-line transaction processing）、聯機分析處理OLAP（On-Line Analytical Processing);
-
OLTP是傳統的關係型數據庫的主要應用，主要是基本的、日常的事務處理，例如銀行交易。通俗的講，就是對數據的增刪改查等操作。
-
OLAP是數據倉庫系統的主要應用，支持複雜的分析操作，側重決策支持，並且提供直觀易懂的查詢結果。通俗的講，就是對數據按不同維度的聚合，維度的上鑽，下卷等
這裏我們聊一聊OLAP，OLAP系統對數據的處理也有多種：MPP、搜索引擎和預處理。這裏講的是預處理的場景。
一個預處理的OLAP系統在處理數據時總是分成如下幾個階段：數據收集，數據清洗，數據計算，數據輸出。根據業務需要部分階段會重複。
數據收集
數據收集階段負責對接第三方系統，從第三方系統接收數據。有如下方式
-
API方式：通過程序發佈一個接口，一般使用restful api，這個方式比較靈活。
-
共享數據庫：通過約定一個數據庫表，給第三方提供一個數據庫賬號，第三方直接寫數據進去。
-
消息隊列：將數據直接發送進消息隊列，之後通過API將數據轉到數據庫。
各方式的比較
| API | 數據庫 | 消息隊列 | |
|---|---|---|---|
| 安全認證 | 可以自定義 | 依賴數據庫 | 依賴消息隊列 |
| 接收復雜數據 | 複雜JSON | 關係數據 | 複雜JSON |
| 數據校驗 | 個性化校驗 | 字段長度和類型的校驗 | 不校驗 |
| 發佈協議 | 任意協議 | 依賴數據庫 | 依賴消息隊列 |
| 開發工作 | 需要 | 不需要 | 需要，需要解析消息裏的數據到數據庫 |
| 維護難度 | 高，需要修改Bug | 低 | 高，需要修改Bug |
| 可用性 | 中，部署服務會中斷業務 | 中，增加字段會中斷業務 | 高，不中斷業務 |
| 部署設備 | 數據庫+API服務器 | 數據庫 | 數據庫+API服務器+消息隊列 |
此階段有兩個注意事項：
-
無論使用什麼方式，這些接口都是一個事件接口。
事件接口的意思是這個接口接收的信息不是名詞，是動詞。類似一個接收物流運單的接口，這個接口接收的不是物流運單，接收的是物流運單變化。所以接口需要知道運單是新建的、修改的、刪除的。
-
保存原始數據 任何邏輯都會有bug，如果保存數據時對數據做了加工，一旦發現邏輯有bug，將沒有修復的機會了。所以要求數據一旦接收了，就原封不動的保存。所以這裏的數據庫只保存原始數據，儘可能的原封不動。
對於接收到的數據我們可以稱之爲Data Event。這些數據一般有時間戳，或者其他的確定順序的字段，便於事件回放。
數據清洗
數據清洗階段的主要作用是對接收到的數據按照業務調整格式。
-
將事件轉換爲業務數據。 收到的數據可能是好多條：新建運輸單；修改運輸方式爲海運；修改重量爲1噸。經過清洗變成一條業務數據：運輸單，運輸方式爲海運，重量1噸。
-
業務模型轉換 上游第三方系統發送的數據一般會按照他們的業務來發送數據，類似第三方可能會跟蹤一個一個的小箱子，而我們的新系統需要將這些小箱子當成一個運輸單來跟蹤。
-
數據格式轉換 類似將字符串的2020-02-20，調整爲時間格式，將各種時間統一到一個時區，將字符串的男女轉換爲枚舉值
-
記錄變化 這個是一個可選項，有些業務會統計變化次數，此時這個記錄就很重要了。但是這個信息的記錄會比較繁瑣，根據業務實際情況酌情處理。
經過數據清洗，我們得到了具有業務含義的基礎數據，這些數據會根據第三方提供的數據不斷更新，我們稱其爲Base Data。這部分數據的特點是
-
和Data Event基本一致
-
各種轉換是非常確定的業務，未來幾乎不變化
-
這類數據也建議放一個時間戳，標記什麼時候更新過，方便定位問題
數據計算
此階段的邏輯是：加載Base Data，根據配置和業務需要計算KPI。類似計算每個運輸單從發貨到收貨持續了多長時間。這個階段計算內容有如下要求：
-
冪等性。相同的數據多次計算結果應該是一樣的。
-
計算的KPI的邏輯之間彼此獨立。這是爲了便於維護
-
如果KPI的邏輯是配置的，需要有version，每一條數據在計算的時候都可以找到固定的version，保證第一條冪等性。
-
建議增加更新時間信息，方便定位問題
這個階段的產物是可以直接輸出或者經過簡單的匯聚就可以輸出的數據，基本到達了最後的可視數據階段，我們稱其爲View Data。在一個複雜的系統中，一個業務的View Data可能成爲另一個業務的Base Data。此時會多出來一個階段：計算關聯數據。
通過計算關聯數據，讓數據計算過程只被一種數據觸發計算，在實際實施時可以有效防止數據衝突。
數據輸出
代表整個平臺將計算後數據對外輸出，可以有如下形式
-
監控數據變化，給下游系統發送變化內容
-
對下游系統提供查詢接口
-
定期發送符合條件的數據到服務器。類似ftp服務器。
-
做簡單的匯聚，類似統計指定時間段中運輸單耗時爲1天2天3天的量分別爲多少。
對於主動給下游發送數據的接口，在設計的時候要提供重複發送的功能。重複發送功能對定位問題和實際線上生產問題的數據恢復很有幫助。發送數據接口最好提供指定模擬發送時間功能，這樣在數據遺漏，補充發送時會更爲簡單。
Demo
這裏舉一個複雜點的物流系統的例子，如圖：
圖中實線是數據的流向，虛線是消息隊列的流向，Kafka代表Kafka的一個topic。
這裏有兩類數據，運單和發票。
-
運單
運單的場景是一個普通場景。
-
採用數據庫接收了數據。
-
通過"運單Processor"將數據清洗了一下，結果保存到運單Base庫中，同時發送運單單號到kafaka。
-
運單Integrator在接到Kafka中運單號任務後，從運單Base庫中讀取運單信息計算需要的KPI，之後保存結果到運單View。
-
運單Service負責對外提供數據查詢和統計運單的Data API。
-
-
發票
發票的場景是一個複雜場景。標準流程部分
-
採用數據庫接收了數據。
-
通過"發票Processor"將數據清洗了一下，結果保存到運單Base庫中，同時發送運單單號到kafaka。
-
發票Integrator在接到Kafka中運單號任務後，從發票Base庫和運單View庫兩個中讀取信息計算需要的KPI，之後保存結果到發票View。
-
發票Service負責對外提供數據查詢和統計發票的Data API。
附加流程部分
-
爲了監控運單的變化，運單Integrator會將更新後運單號發送到發票Discovery的Kafka中。
-
發票Discovery服務從發票View中可以找到所有曾經分攤過的發票數據，這部分需要重新計算。
-
發票Discovery服務將找到的發票號重新發送到發票Integrator的Kafka中
-
其他
-
歸檔
一個完備的系統應該也要提供數據歸檔機制，不過一般數據在運行1，2年內不會涉及這個功能。可以延遲一年開發。
-
重跑
任何程序都會出問題，所以每個階段都要提供從跑的機制。