阿里巴巴大數據之路-數據計算層

02-27

一、阿里巴巴的數據計算層包括：

數據存儲及計算平台（離線計算平台MaxCompute和實時計算平台StreamCompute）
數據整合及管理體系（OneData）

二、統一計算平台MaxCompute（離線）

有幾萬台機器，存儲近1000PB
功能組件：SQL、MR、Graph、Spark、R、Volume

三、統一開發平台

D2（在雲端）：集成任務開發、調試及發布，生產任務調度及大數據運維，數據許可權申請及管理等功能的一站式數據開發平台，並能承擔數據分析工作台的功能。
使用D2進行數據開發的基本流程：用戶使用IDE進行計算節點的創建，可以是SQL/MR任務，也可以是Shell任務等，設置好節點屬性及依賴關係，進行試運行，並可以發布到生產環境。
SQLSCAN：包括代碼規範類規則檢查（命名規範等）、代碼質量類規則檢查（分母為0等）、代碼性能類規則檢查（大表掃描等）。
DQC：數據質量監控規則包括--主鍵監控、表數據量及波動監控、重要欄位的非空監控、重要枚舉欄位的離散值監控、指標值波動監控、業務規則監控等。阿里數據倉庫採用非侵入式清洗策略，在數據同步過程中不進行清洗，避免影響同步效率，在數據進入ODS層之後進行清洗。
在彼岸：用於大數據系統的自動化測試平台，將通用性、重複性的操作沉澱在測試平台中，避免被「人肉」，提高測試效率。
在彼岸--數據對比：表級對比規則主要包括數據量和全文對比；欄位級對比規則主要包括欄位的統計值（如sum、avg、max、min等）、枚舉值、空值、去重數、長度值等。
在彼岸-數據分布：提取表和欄位的一些特徵值，並將這些特徵值與預期值進行比對。表級數據特徵提取主要包括數據量、主鍵等；欄位級數據特徵提取主要包括欄位枚舉值分布、空值分布、統計值、去重數、長度值等。
數據脫敏：將敏感數據模糊化。

四、任務調度系統

調度配置：常規的配置是手工方式，如果出錯；阿里巴巴採用手工配置和自動識別相結合的方式。任務提交時，SQL解析引擎自動識別此任務的輸入表和輸出表，輸入表自動關聯產出此表的任務，輸出表亦然。通過此種方式，解決了上述問題，可以自動調整任務依賴，避免依賴配置錯誤。

五、數據時效性

離線：延遲時間粒度為天；准實時：延遲時間粒度為小時；實時：延遲時間粒度為秒。
離線和准實時都可以在批處理系統中實現，比如Hadoop、MaxCompute等，只是調度周期不一樣而已，而實時數據則需要在流式處理系統中完成。

六、流式技術架構：流式技術架構中的系統跟離線處理是有交叉的，兩套技術方案並不是完全獨立的，並且在業界中有合併的趨勢。

數據採集

不管是資料庫變更日誌，還是引擎訪問日誌，都會在伺服器上落地成文件，所以只要監控文件的內容發生變化，採集工具就可以把最新的數據採集下來。一般情況下，出於吞吐量以及系統壓力上的考慮，並不是新增一條記錄就採集一次，而是基於下面的原則，按批次對數據進行採集：數據大小限制原則--當數據大小達到限制條件時觸發採集；時間閾值原則--當時間達到一定條件時觸發採集。實時採集下來的數據一般放入數據中間件，比如Kafka、TimeTunnel等。

數據處理

實時處理計算引擎有Storm、SparkStreaming、Flink、StreamingCompute等。StreamingCompute：在Storm基礎上包裝一層SQL語義，方便開發人員通過寫SQL就可以實現實時計算，而不需要關心計算狀態細節；當然，它也支持傳統模式的開發；還提供了流計算開發平台，在這個平台上就可以完成應用的相關運維工作，而不需要登錄伺服器操作，極大提高運維效率。

實時數據處理遇到的幾個典型問題：

A、去重指標：模糊去重的第一個--布隆過濾器在實時指標計算中的應用；模糊去重的第二個方法--基數估計，估算的去重值可能比真實值小，也可以大，存儲1億條數據只需要幾KB的內存，適用統計精讀要求不高，統計維度非常粗的情況，比如整個大盤的UV數據，基數估計在各個維度值之間不能共用，比如統計全天小時的UV數據，就需要有24個基數估計對象。

B、數據傾斜：數據傾斜是ETL中經常遇到的問題，比如計算一天中全網訪客數或者成交額時，最終的結果只有1個，通常應該是在一個節點上完成相關的計算任務。因此，在數據量非常大的時候，單個節點的處理能力是有限的，就需要進行分桶處理，充分利用每個桶的CPU和內存資源。第一種情況是去重指標分桶--通過對去重值進行分桶Hash，相同的值一定會被放在同一個桶中去重，最後再把每個桶裡面的值進行加和得到總值；第二種情況是非去重指標分桶--此時數據隨機分發到每個桶中，最後再把每個桶的值匯總。

C、事務處理：上面提到的幾個流計算系統幾乎都提供了數據自動ACK、失敗重發以及事務信息等機制，這些機制都是為了保證數據的冪等性。

數據存儲

在實踐中一般使用HBase、MongoDB等列式存儲系統，這些系統的讀寫效率都能達到毫秒級。但是這些系統的缺點也是明顯的，以HBase為例，一張表必須要有rowkey，而rowkey是按照ASCII碼來排序的，這就像關係型資料庫的索引一樣，rowkkey的規則限制了讀取數據的方式，如果業務方需要使用另一種讀取數據的方式，則必須重新輸出rowkey。從這個角度來看，HBase沒有關係資料庫方便，但HBase可以存儲幾十TB的海量資料庫，而關係資料庫必須要分庫分表才能實現這個量級的數據存儲。因此，對於海量數據的實時計算，一般會採用NoSql資料庫，以應對大量的多並發讀寫。

數據服務：實時數據落地到存儲系統後，使用方就可以通過OneService等把數據對外進行共享。

流式數據模型：實時數據模型是離線數據模型的一個子集，在實時數據處理過程中，很多模型設計就是參考離線數據模型實現的。

數據分層：ODS（實時介面層）、DWD（實時明細數據層）、DWS（實時通用匯總層）、ADS（實時個性化維度匯總層）、DIM（維表層）。一般ODS和DWD會放在數據中間件中，供下游訂閱使用，而DWS和ADS會落地到在線存儲系統中，DIM一般離線處理。在每一層中，可以按照重要性劃分等級，優先保障最高等級的實時任務。

通過一個簡單的例子來說明每一層存儲的數據：

A、ODS層：訂單粒度的變更過程，一筆訂單有多條記錄。

B、DWD層：訂單粒度的支付記錄，一筆訂單只有一條記錄。

C、DWS層：賣家的實時成交金額，一個賣家只有一條記錄，並且指標在實時刷新。

D、ADS層：外賣地區的實時成交金額，只有外賣業務使用。

D、DIM層：訂單商品類目和行業的對應關係維表。

多流關聯：實時採集兩張表的數據，每到來一條新數據時都在對方內存表截止當前的全量數據中查找，如果能找到則說明關聯成功直接輸出，否則需要把數據放在內存中的自己表數據集合中等待。另外，不管是否關聯成功，內存數據都需要備份到外部存儲系統中。還有，訂單記錄的變更可能發生多次，需要根據訂單ID去重，避免A表和B表多次關聯成功。同時，考慮到內存關聯查找數據的性能，一般會把數據按照關聯主鍵進行分桶處理。
維表使用：在實時計算中，一般會使用當前的實時數據（T）去關聯T-2的維表數據。因為到達零點時，T-1的維表數據還沒準備好，所以一般在實時計算中維表關聯都統一使用T-2的數據，這樣對於業務來說，起碼關聯到的維表數據是確定的（雖然維表數據有一定的延時，但是許多業務的維表在兩天之間變化是很少的）。如果維表數據量不是特別大，可以全量載入到內存使用；如果維表數據量特別大，則可以增量查找和LRU過期的形式，讓最熱門的數據留在內存中。