第12章 元數(shù)據(jù)
第13章 計算管理
第14章 存儲和成本管理
第15章 數(shù)據(jù)質(zhì)量
第16章 數(shù)據(jù)應(yīng)用
第12章 元數(shù)據(jù)
12.1 元數(shù)據(jù)概述
12.1.1 元數(shù)據(jù)定義
按照傳統(tǒng)的定義，元數(shù)據(jù)（Metadata）是關(guān)于數(shù)據(jù)的數(shù)據(jù)。元數(shù)據(jù)打通了源數(shù)據(jù)、數(shù)據(jù)倉庫、數(shù)據(jù)應(yīng)用，記錄了數(shù)據(jù)從產(chǎn)生到消費(fèi)的全過程。元數(shù)據(jù)主要記錄數(shù)據(jù)倉庫中模型的定義、各層級間的映射關(guān)系、監(jiān)控數(shù)據(jù)倉庫的數(shù)據(jù)狀態(tài)及ETL的任務(wù)運(yùn)行狀態(tài)。
在數(shù)據(jù)倉庫系統(tǒng)中，元數(shù)據(jù)可以幫助數(shù)據(jù)倉庫管理員和開發(fā)人員非常方便地找到他們所關(guān)心的數(shù)據(jù)，用于指導(dǎo)其進(jìn)行數(shù)據(jù)管理和開發(fā)工作，提高工作效率。
將元數(shù)據(jù)按用途的不同分為兩類：
- 技術(shù)元數(shù)據(jù)（Technical Metadata)
存儲關(guān)于數(shù)據(jù)倉庫系統(tǒng)技術(shù)細(xì)節(jié)的數(shù)據(jù)，是用于開發(fā)和管理數(shù)據(jù)倉庫使用的數(shù)據(jù)。
（包括分布式計算系統(tǒng)存儲元數(shù)據(jù)/運(yùn)行元數(shù)據(jù)、數(shù)據(jù)開發(fā)平臺中數(shù)據(jù)同步/計算任務(wù)/任務(wù)調(diào)度等數(shù)據(jù)、數(shù)據(jù)質(zhì)量和運(yùn)維相關(guān)元數(shù)據(jù)等）
- 業(yè)務(wù)元數(shù)據(jù)（Business Metadata）
從業(yè)務(wù)角度描述了數(shù)據(jù)倉庫中的數(shù)據(jù)，它提供了介于使用者和實際系統(tǒng)之間的語義層，使得不懂計算機(jī)技術(shù)的業(yè)務(wù)人員也能夠“讀懂”數(shù)據(jù)倉庫中的數(shù)據(jù)。
（包括OneData元數(shù)據(jù)和數(shù)據(jù)應(yīng)用元數(shù)據(jù)等，如數(shù)據(jù)報表、數(shù)據(jù)產(chǎn)品等的配置和運(yùn)行元數(shù)據(jù)）
12.1.2 元數(shù)據(jù)價值
元數(shù)據(jù)有重要的應(yīng)用價值，是數(shù)據(jù)管理、數(shù)據(jù)內(nèi)容、數(shù)據(jù)應(yīng)用的基礎(chǔ)，在數(shù)據(jù)管理方面為集團(tuán)數(shù)據(jù)提供在計算、存儲、成本、質(zhì)量、安全、模型等治理領(lǐng)域上的數(shù)據(jù)支持。
例如在計算上可以利用元數(shù)據(jù)查找超長運(yùn)行節(jié)點，對這些節(jié)點進(jìn)行專項治理，保障基線產(chǎn)出時間。
在數(shù)據(jù)內(nèi)容方面為集團(tuán)數(shù)據(jù)進(jìn)行數(shù)據(jù)域、數(shù)據(jù)主題、業(yè)務(wù)屬性等的提取和分析提供數(shù)據(jù)素材。例如可以利用元數(shù)據(jù)構(gòu)建知識圖譜，給數(shù)據(jù)打標(biāo)簽，清楚地知道現(xiàn)在有哪些數(shù)據(jù)。
在數(shù)據(jù)應(yīng)用方面打通產(chǎn)品及應(yīng)用鏈路，保障產(chǎn)品數(shù)據(jù)準(zhǔn)確、及時產(chǎn)出。例如打通MaxCompute和應(yīng)用數(shù)據(jù)，明確數(shù)據(jù)資產(chǎn)等級，更有效地保障產(chǎn)品數(shù)據(jù)。
12.1.3 統(tǒng)一元數(shù)據(jù)體系建設(shè)
元數(shù)據(jù)的質(zhì)量直接影響到數(shù)據(jù)管理的準(zhǔn)確性，如何把元數(shù)據(jù)建設(shè)好將起到至關(guān)重要的作用。
元數(shù)據(jù)建設(shè)的目標(biāo)是打通數(shù)據(jù)接入到加工，再到數(shù)據(jù)消費(fèi)整個鏈路，規(guī)范元數(shù)據(jù)體系與模型，提供統(tǒng)一的元數(shù)據(jù)服務(wù)出口，保障元數(shù)據(jù)產(chǎn)出的穩(wěn)定性和質(zhì)量。
12.2 元數(shù)據(jù)應(yīng)用
數(shù)據(jù)的真正價值在于數(shù)據(jù)驅(qū)動決策，通過數(shù)據(jù)指導(dǎo)運(yùn)營。通過數(shù)據(jù)驅(qū)動的方法，我們能夠判斷趨勢，從而展開有效行動，幫助自己發(fā)現(xiàn)問題，推動創(chuàng)新或解決方案的產(chǎn)生。這就是數(shù)據(jù)化運(yùn)營。同樣，對于元數(shù)據(jù)，可以用于指導(dǎo)數(shù)據(jù)相關(guān)人員進(jìn)行日常工作，實現(xiàn)數(shù)據(jù)化“運(yùn)營”。
比如對于數(shù)據(jù)使用者，可以通過元數(shù)據(jù)讓其快速找到所需要的數(shù)據(jù)；對于ETL工程師，可以通過元數(shù)據(jù)指導(dǎo)其進(jìn)行模型設(shè)計、任務(wù)優(yōu)化和任務(wù)下線等各種日常ETL工作；對于運(yùn)維工程師，可以通過元數(shù)據(jù)指導(dǎo)其進(jìn)行整個集群的存儲、計算和系統(tǒng)優(yōu)化等運(yùn)維工作。
12.2.1 Data Profile
核心思路是為紛繁復(fù)雜的數(shù)據(jù)建立一個脈絡(luò)清晰的血緣圖譜。通過圖計算、標(biāo)簽傳播算法等技術(shù)，系統(tǒng)化、自動化地對計算與存儲平臺上的數(shù)據(jù)進(jìn)行打標(biāo)、整理、歸檔。形象地說，DataProfile實際承擔(dān)的是為元數(shù)據(jù)“畫像”的任務(wù)。
- 基礎(chǔ)標(biāo)簽
針對數(shù)據(jù)的存儲情況、訪問情況、安全等級等進(jìn)行打標(biāo)。
- 數(shù)倉標(biāo)簽
針對數(shù)據(jù)是增量還是全量、是否可再生、數(shù)據(jù)的生命周期來進(jìn)行標(biāo)簽化處理。
- 業(yè)務(wù)標(biāo)簽
根據(jù)數(shù)據(jù)歸屬的主題域、產(chǎn)品線、業(yè)務(wù)類型為數(shù)據(jù)打上不同的標(biāo)簽。
- 潛在標(biāo)簽
這類標(biāo)簽主要是為了說明數(shù)據(jù)潛在的應(yīng)用場景，比如社交、媒體、廣告、電商、金融等。
12.2.2 元數(shù)據(jù)門戶
元數(shù)據(jù)門戶致力打造一站式的數(shù)據(jù)管理平臺、高效的一體化數(shù)據(jù)市場。包括“前臺”和“后臺”，“前臺”產(chǎn)品為數(shù)據(jù)地圖，定位消費(fèi)市場，實現(xiàn)檢索數(shù)據(jù)、理解數(shù)據(jù)等“找數(shù)據(jù)”需求；“后臺”產(chǎn)品為數(shù)據(jù)管理，定位于一站式數(shù)據(jù)管理，實現(xiàn)成本管理、安全管理、質(zhì)量管理等。
- 數(shù)據(jù)地圖
圍繞數(shù)據(jù)搜索，服務(wù)于數(shù)據(jù)分析、數(shù)據(jù)開發(fā)、數(shù)據(jù)挖掘、算法工程師、數(shù)據(jù)運(yùn)營等數(shù)據(jù)表的使用者和擁有者，提供方便快捷的數(shù)據(jù)搜索服務(wù)，擁有功能強(qiáng)大的血緣信息及影響分析，利用表使用說明、評價反饋、表收藏及精品表機(jī)制，為用戶浮現(xiàn)高質(zhì)量、高保障的目標(biāo)數(shù)據(jù)。
比如在進(jìn)行數(shù)據(jù)分析前，使用數(shù)據(jù)地圖進(jìn)行關(guān)鍵詞搜索，幫助快速縮小范圍，找到對應(yīng)的數(shù)據(jù)；比如使用數(shù)據(jù)地圖根據(jù)表名直接查看表詳情，快速查閱明細(xì)信息，掌握使用規(guī)則：比如通過數(shù)據(jù)地圖的血緣分析可以查看每個數(shù)據(jù)表的來源、去向，并查看每個表及字段的加工邏輯。
- 數(shù)據(jù)管理平臺
圍繞數(shù)據(jù)管理，服務(wù)于個人開發(fā)者、BU管理者、系統(tǒng)管理員等用戶，提供個人和BU全局資產(chǎn)管理、成本管理和質(zhì)量管理等。針對個人開發(fā)者，主要包括計算費(fèi)用和健康分管理、存儲費(fèi)用和健康分管理，并提供優(yōu)化建議和優(yōu)化接口；針對BU管理者和管理員，主要提供BU、應(yīng)用、集群等全局資產(chǎn)消耗概覽、分析和預(yù)測。
12.2.3 應(yīng)用鏈路分析
對于某個數(shù)據(jù)計算任務(wù)或表，其重要程度如何，是否還有下游在使用，是否可以下線；阿里巴巴有這么多數(shù)據(jù)產(chǎn)品，都依賴哪些MaxCompute表，對這些MaxCompute表是否需要根據(jù)應(yīng)用的重要程度進(jìn)行資源、運(yùn)維保障。
對于這些問題，我們都可以通過元數(shù)據(jù)血緣來分析產(chǎn)品及應(yīng)用的鏈路，通過血緣鏈路可以清楚地統(tǒng)計到某個產(chǎn)品所用到的數(shù)據(jù)在計算、存儲、質(zhì)量上存在哪些問題，通過治理優(yōu)化保障產(chǎn)品數(shù)據(jù)的穩(wěn)定性。
通過應(yīng)用鏈路分析，產(chǎn)出表級血緣、字段血緣和表的應(yīng)用血緣。其中表級血緣主要有兩種計算方式：一種是通過MaxCompute任務(wù)日志進(jìn)行解析；一種是根據(jù)任務(wù)依賴進(jìn)行解析。
常見的應(yīng)用鏈路分析應(yīng)用主要有影響分析、重要性分析、下線分析、鏈路分析、尋根溯源、故障排查等。
12.2.4 數(shù)據(jù)建模
傳統(tǒng)的數(shù)據(jù)倉庫建模一般采用經(jīng)驗建模的方式，效率較低且不準(zhǔn)確。基于現(xiàn)有底層數(shù)據(jù)已經(jīng)有下游使用的情況，我們可以通過下游所使用的元數(shù)據(jù)指導(dǎo)數(shù)據(jù)參考建模。通過元數(shù)據(jù)驅(qū)動的數(shù)據(jù)倉庫模型建設(shè)，可以在一定程度上解決此問題，提高數(shù)據(jù)倉庫建模的數(shù)據(jù)化指導(dǎo)，提升建模效率。
- 數(shù)據(jù)模型建設(shè)
基于下游使用中關(guān)聯(lián)次數(shù)大于某個闊值的表或查詢次數(shù)大于某個闡值的表等元數(shù)據(jù)信息，篩選用于數(shù)據(jù)模型建設(shè)的表。
- 業(yè)務(wù)過程標(biāo)識
基于表的字段元數(shù)據(jù)，如字段中的時間字段、字段在下游使用中的過濾次數(shù)等，選擇業(yè)務(wù)過程標(biāo)識字段。
- 關(guān)聯(lián)從表
基于主從表的關(guān)聯(lián)關(guān)系、關(guān)聯(lián)次數(shù)，確定和主表關(guān)聯(lián)的從表。
- 目標(biāo)模型
基于主從表的字段使用情況，如字段的查詢次數(shù)、過濾次數(shù)、關(guān)聯(lián)次數(shù)、聚合次數(shù)等，確定哪些字段進(jìn)入目標(biāo)模型。
12.2.5 驅(qū)動ETL開發(fā)
可以通過DataProfile得到數(shù)據(jù)的下游任務(wù)依賴情況、最近被讀寫的次數(shù)、數(shù)據(jù)是否可再生、每天消耗的存儲計算等，這些信息足以讓我們判斷數(shù)據(jù)是否可以下線；如果根據(jù)一些規(guī)則判斷可以下線，則會通過OneClick觸發(fā)一個數(shù)據(jù)下線的工作任務(wù)流，數(shù)據(jù)Owner可能只需要點擊提交按鈕，刪除數(shù)據(jù)、刪除元數(shù)據(jù)、下線調(diào)度任務(wù)、下線DQC監(jiān)控等一系列操作就會自動在后臺執(zhí)行完成。
第13章 計算管理
目前內(nèi)部MaxCompute集群上有200多萬個任務(wù)，每天存儲資源、計算資源消耗都很大。如何降低計算資源的消耗，提高任務(wù)執(zhí)行的性能，提升任務(wù)產(chǎn)出的時間，是計算平臺和ETL開發(fā)工程師孜孜追求的目標(biāo)。
13.1 系統(tǒng)優(yōu)化
Hadoop等分布式計算系統(tǒng)評估資源的方式，一般是根據(jù)輸入數(shù)據(jù)量進(jìn)行靜態(tài)評估，Map任務(wù)用于處理輸入，對于普通的Map任務(wù)，評估一般符合預(yù)期：而對于Reduce任務(wù)，其輸入來自于Map的輸出，但一般只能根據(jù)Map任務(wù)的輸入進(jìn)行評估，經(jīng)常和實際需要的資源數(shù)相差很大，所以在任務(wù)穩(wěn)定的情況下，可以考慮基于任務(wù)的歷史執(zhí)行情況進(jìn)行資源評估，即采用HBO(History-Based Optimizer，基于歷史的優(yōu)化器）。
13.2 任務(wù)優(yōu)化
主要從數(shù)據(jù)傾斜方面進(jìn)行數(shù)據(jù)優(yōu)化。
13.2.1 Map傾斜
Map端是MR任務(wù)的起始階段，Map端的主要功能是從磁盤中將數(shù)據(jù)讀入內(nèi)存，在Map端讀數(shù)據(jù)時，由于讀入數(shù)據(jù)的文件大小分布不均勻，因此會導(dǎo)致有些MapInstance讀取并且處理的數(shù)據(jù)特別多，而有些MapInstance處理的數(shù)據(jù)特別少，造成Map端長尾。
以下兩種情況可能會導(dǎo)致Map端長尾：
- 上游表文件的大小特別不均勻，并且小文件特別多，導(dǎo)致當(dāng)前表Map端讀取的數(shù)據(jù)分布不均勻，引起長尾。
可通過對上游合并小文件，同時調(diào)節(jié)本節(jié)點的小文件的參數(shù)來進(jìn)行優(yōu)化。
- Map端做聚合時，由于某些MapInstance讀取文件的某個值特別多而引起長尾，主要是指CountDistinct操作。
針對這種情況，可以使用“distribute by rand()”來打亂數(shù)據(jù)分布，使數(shù)據(jù)盡可能分布均勻。
通過“distribute by rand()”會將Map端分發(fā)后的數(shù)據(jù)重新按照隨機(jī)值再進(jìn)行一次分發(fā)。原先不加隨機(jī)分發(fā)函數(shù)時，Map階段需要與使用MapJoin的小表進(jìn)行笛卡兒積操作，Map端完成了大小表的分發(fā)和笛卡兒積操作。使用隨機(jī)分布函數(shù)后，Map端只負(fù)責(zé)數(shù)據(jù)的分發(fā)，不再有復(fù)雜的聚合或者笛卡兒積操作，因此不會導(dǎo)致Map端長尾。
（代碼略）
Map端長尾的根本原因是由于讀入的文件塊的數(shù)據(jù)分布不均勻，再加上UDF函數(shù)性能、Join、聚合操作等，導(dǎo)致讀人數(shù)據(jù)量大的Maplnstance耗時較長。在開發(fā)過程中如果遇到Map端長尾的情況，首先考慮如何讓MapInstance讀取的數(shù)據(jù)量足夠均勻，然后判斷是哪些操作導(dǎo)致MapInstance比較慢，最后考慮這些操作是否必須在Map端完成，在其他階段是否會做得更好。
13.2.2 Join傾斜
MaxComputeSQL在Join執(zhí)行階段會將JoinKey相同的數(shù)據(jù)分發(fā)到同一個執(zhí)行Instance上處理。如果某個Key上的數(shù)據(jù)量比較大，則會導(dǎo)致該Instance執(zhí)行時間較長。其表現(xiàn)為：在執(zhí)行日志中該JoinTask的大部分Instance都已執(zhí)行完成，但少數(shù)幾個Instance一直處于執(zhí)行中（這種現(xiàn)象稱之為長尾）。
因為數(shù)據(jù)傾斜導(dǎo)致長尾的現(xiàn)象比較普遍，嚴(yán)重影響任務(wù)的執(zhí)行時間，尤其是在“雙11”等大型活動期間，長尾程度比平時更嚴(yán)重。比如某些大型店鋪的PV遠(yuǎn)遠(yuǎn)超過一般店鋪的PV，當(dāng)用瀏覽日志數(shù)據(jù)和賣家維表關(guān)聯(lián)時，會按照賣家ID進(jìn)行分發(fā)，導(dǎo)致某些大賣家所在Instance處理的數(shù)據(jù)量遠(yuǎn)遠(yuǎn)超過其他Instance，而整個任務(wù)會因為這個長尾的Instance遲遲無法結(jié)束。
三種常見的傾斜場景：
- Join的某路輸入比較小
可以采用MapJoin，避免分發(fā)引起長尾。
- Join的每路輸入都較大，且長尾是空值導(dǎo)致的
可以將空值處理成隨機(jī)值，避免聚集。
- Join的每路輸入都較大，且長尾是熱點值導(dǎo)致的
可以對熱點值和非熱點值分別進(jìn)行處理，再合并數(shù)據(jù)。
13.2.3 Reduce傾斜
Reduce端負(fù)責(zé)的是對Map端梳理后的有序key-value鍵值對進(jìn)行聚合，即進(jìn)行Count、Sum、Avg等聚合操作，得到最終聚合的結(jié)果。
Distinct是MaxComputeSQL中支持的語法，用于對字段去重。比如計算在某個時間段內(nèi)支付買家數(shù)、訪問UV等，都是需要用Distinct進(jìn)行去重的。
MaxCompute中Distinct的執(zhí)行原理是將需要去重的字段以及GroupBy字段聯(lián)合作為key將數(shù)據(jù)分發(fā)到Reduce端。
因為Distinct操作，數(shù)據(jù)無法在Map端的Shuffle階段根據(jù)GroupBy先做一次聚合操作，以減少傳輸?shù)臄?shù)據(jù)量，而是將所有的數(shù)據(jù)都傳輸?shù)絉educe端，當(dāng)key的數(shù)據(jù)分發(fā)不均勻時，就會導(dǎo)致Reduce端長尾。
Reduce端產(chǎn)生長尾的主要原因就是key的數(shù)據(jù)分布不均勻。比如有些Reduce任務(wù)Instance處理的數(shù)據(jù)記錄多，有些處理的數(shù)據(jù)記錄少，造成Reduce端長尾。
如下幾種情況會造成Reduce端長尾：
對同一個表按照維度對不同的列進(jìn)行Count Distinct操作，造成Map端數(shù)據(jù)膨脹，從而使得下游的Join和Reduce出現(xiàn)鏈路上的長尾。
Map端直接做聚合時出現(xiàn)key值分布不均勻，造成Reduce端長尾。
可以對熱點key進(jìn)行單獨處理，然后通過“Union All”合并。
- 動態(tài)分區(qū)數(shù)過多時可能造成小文件過多，從而引起Reduce端長尾。
可以把符合不同條件的數(shù)據(jù)放到不同的分區(qū)，避免通過多次“InsertOverwrite”寫人表中，特別是分區(qū)數(shù)比較多時，能夠很好地簡化代碼。
但是動態(tài)分區(qū)也有可能會帶來小文件過多的困擾。
MaxCompute對動態(tài)分區(qū)的處理是引人額外一級的Reduce Task，把相同的目標(biāo)分區(qū)交由同一個（或少量幾個）Reduce Instance來寫入，避免小文件過多，并且這個Reduce肯定是最后一個ReduceTask操作。
- 多個Distinct同時出現(xiàn)在一段SQL代碼中時，數(shù)據(jù)會被分發(fā)多次，不僅會造成數(shù)據(jù)膨脹N倍，還會把長尾現(xiàn)象放大N倍。
在7天、30天等時間范圍內(nèi)，分PC端、無線端、所有終端，計算支付買家數(shù)和支付商品數(shù)，其中支付買家數(shù)和支付商品數(shù)指標(biāo)需要去重。因為需要根據(jù)日期、終端等多種條件組合對買家和商品進(jìn)行去重計算，因此有12個Count Distinct計算。在計算過程中會根據(jù)12個組合key分發(fā)數(shù)據(jù)來統(tǒng)計支付買家數(shù)和支付商品數(shù)。這樣做使得節(jié)點運(yùn)行效率變低。
針對上面的問題，可以先分別進(jìn)行查詢，執(zhí)行GroupBy原表粒度+ buyer_id，計算出PC端、無線端、所有終端以及在7天、30天等統(tǒng)計口徑下的buyer_id（這里可以理解為買家支付的次數(shù)），然后在子查詢外GroupBy原表粒度，當(dāng)上一步的Count值大于0時，說明這一買家在這個統(tǒng)計口徑下有過支付，計人支付買家數(shù)，否則不計入。計算支付商品數(shù)采用同樣的處理方式。最后對支付商品數(shù)和支付買家數(shù)進(jìn)行Join操作。
（代碼略）
對MultiDistinct的思考如下：
- 上述方案中如果出現(xiàn)多個需要去重的指標(biāo)，那么在把不同指標(biāo)Join在一起之前，一定要確保指標(biāo)的粒度是原始表的數(shù)據(jù)粒度。
比如支付買家數(shù)和支付商品數(shù)，在子查詢中指標(biāo)粒度分別是：原始表的數(shù)據(jù)粒度＋buyer_id和原始表的數(shù)據(jù)粒度＋item_id，這時兩個指標(biāo)不是同一數(shù)據(jù)粒度，所以不能Join，需要再套一層代碼，分別把指標(biāo)GroupBy到“原始表的數(shù)據(jù)粒度”，然后再進(jìn)行Join操作。
- 修改前的MultiDistinct代碼的可讀性比較強(qiáng)，代碼簡潔，便于維護(hù)；修改后的代碼較為復(fù)雜。
當(dāng)出現(xiàn)的Distinct個數(shù)不多、表的數(shù)據(jù)量也不是很大、表的數(shù)據(jù)分布較均勻時，不使用MultiDistinct的計算效果也是可以接受的。
所以，在性能和代碼簡潔、可維護(hù)之間需要根據(jù)具體情況進(jìn)行權(quán)衡。另外，這種代碼改動還是比較大的，需要投入一定的時間成本，因此可以考慮做成自動化，通過檢測代碼、優(yōu)化代碼自動生成將會更加方便。
- 當(dāng)代碼比較臃腫時，也可以將上述子查詢落到中間表里，這樣數(shù)據(jù)模型更合理、復(fù)用性更強(qiáng)、層次更清晰。
當(dāng)需要去除類似的多個Distinct時，也可以查一下是否有更細(xì)粒度的表可用，避免重復(fù)計算。
目前Reduce端數(shù)據(jù)傾斜很多是由Count Distinct問題引起的，因此在ETL開發(fā)工作中應(yīng)該予以重視Count Distinct問題，避免數(shù)據(jù)膨脹。對于一些表的Join階段的Null值問題，應(yīng)該對表的數(shù)據(jù)分布要有清楚的認(rèn)識，在開發(fā)時解決這個問題。
第14章 存儲和成本管理
如何有效地降低存儲資源的消耗，節(jié)省存儲成本，將是存儲管理孜孜追求的目標(biāo)。
14.1 數(shù)據(jù)壓縮
14.2 數(shù)據(jù)重分布
在MaxCompute中主要采用基于列存儲的方式，由于每個表的數(shù)據(jù)分布不同，插人數(shù)據(jù)的順序不一樣，會導(dǎo)致壓縮效果有很大的差異，因此通過修改表的數(shù)據(jù)重分布，避免列熱點，將會節(jié)省一定的存儲空間。
目前我們主要通過修改distributeby和sortby字段的方法進(jìn)行數(shù)據(jù)重分布。
14.3 存儲治理項優(yōu)化
阿里巴巴數(shù)據(jù)倉庫在資源管理的過程中，經(jīng)過不斷地實踐，慢慢摸索出一套適合大數(shù)據(jù)的存儲優(yōu)化方法，在元數(shù)據(jù)的基礎(chǔ)上，診斷、加工成多個存儲治理優(yōu)化項。
目前已有的存儲治理優(yōu)化項有未管理表、空表、最近62天未訪問表、數(shù)據(jù)無更新無任務(wù)表、數(shù)據(jù)無更新有任務(wù)表、開發(fā)庫數(shù)據(jù)大于1OOGB且無訪問表、長周期表等。
通過對該優(yōu)化項的數(shù)據(jù)診斷，形成治理項，治理項通過流程的方式進(jìn)行運(yùn)轉(zhuǎn)、管理，最終推動各個ETL開發(fā)人員進(jìn)行操作，優(yōu)化存儲管理，并及時回收優(yōu)化的存儲效果。在這個體系下，形成現(xiàn)狀分析、問題診斷、管理優(yōu)化、效果反饋的存儲治理項優(yōu)化的閉環(huán)。通過這個閉環(huán)，可以有效地推進(jìn)數(shù)據(jù)存儲的優(yōu)化，降低存儲管理的成本。
14.4 生命周期管理
生命周期管理的根本目的就是用最少的存儲成本來滿足最大的業(yè)務(wù)需求，使數(shù)據(jù)價值最大化。
管理策略：
- 周期性刪除策略
所存儲的數(shù)據(jù)都有一定的有效期，從數(shù)據(jù)創(chuàng)建開始到過時，可以周期性刪除X天前的數(shù)據(jù)。
- 徹底刪除策略
無用表數(shù)據(jù)或者ETL過程產(chǎn)生的臨時數(shù)據(jù)，以及不需要保留的數(shù)據(jù)，可以進(jìn)行及時刪除，包括刪除元數(shù)據(jù)。
- 永久保留策略
重要且不可恢復(fù)的底層數(shù)據(jù)和應(yīng)用數(shù)據(jù)需要永久保留。
比如底層交易的增量數(shù)據(jù)，出于存儲成本與數(shù)據(jù)價值平衡的考慮，需要永久保留，用于歷史數(shù)據(jù)的恢復(fù)與核查。
- 極限存儲策略
極限存儲可以超高壓縮重復(fù)鏡像數(shù)據(jù)，通過平臺化配置手段實現(xiàn)透明訪問；缺點是對數(shù)據(jù)質(zhì)量要求非常高，配置與維護(hù)成本比較高，建議一個分區(qū)有超過5GB的鏡像數(shù)據(jù)（如商品維表、用戶維表）就使用極限存儲。
- 冷數(shù)據(jù)管理策略
冷數(shù)據(jù)管理是永久保留策略的擴(kuò)展。永久保留的數(shù)據(jù)需要遷移到冷數(shù)據(jù)中心進(jìn)行永久保存，同時將MaxCompute中對應(yīng)的數(shù)據(jù)刪除。
一般將重要且不可恢復(fù)的、占用存儲空間大于lOOTB，且訪問頻次較低的數(shù)據(jù)進(jìn)行冷備，例如3年以上的日志數(shù)據(jù)。
- 增量表merge全量表策略
對于某些特定的數(shù)據(jù)，極限存儲在使用性與存儲成本方面的優(yōu)勢不是很明顯，需要改成增量同步與全量merge的方式，對于對應(yīng)的delta增量表的保留策略，目前默認(rèn)保留93天。
例如，交易增量數(shù)據(jù)，使用訂單創(chuàng)建日期或者訂單結(jié)束日期作為分區(qū)，同時將未完結(jié)訂單放在最大分區(qū)中，對于存儲，一個訂單在表里只保留一份；對于用戶使用，通過分區(qū)條件就能查詢某一段時間的數(shù)據(jù)。
管理矩陣：
- 歷史數(shù)據(jù)等級劃分
對歷史數(shù)據(jù)進(jìn)行重要等級的劃分。
- 表類型劃分
劃分為事件型流水表（增量表）、事件型鏡像表（增量表）、維表、Merge全量表、ETL臨時表、TT臨時數(shù)據(jù)、普通全量表等。
14.5 數(shù)據(jù)成本計量
在計量數(shù)據(jù)表的成本時，除考慮數(shù)據(jù)表本身的計算成本、存儲成本外，還要考慮對上游數(shù)據(jù)表的掃描帶來的掃描成本。
我們將數(shù)據(jù)成本定義為存儲成本、計算成本和掃描成本三個部分。
通過在數(shù)據(jù)成本計量中引人掃描成本的概念，可以避免僅僅將表自身硬件資源的消耗作為數(shù)據(jù)表的成本，以及對數(shù)據(jù)表成本進(jìn)行分析時，孤立地分析單獨的一個數(shù)據(jù)表，能夠很好地體現(xiàn)出數(shù)據(jù)在加工鏈路中的上下游依賴關(guān)系，使得成本的評估盡量準(zhǔn)確、公平、合理。
14.6 數(shù)據(jù)使用計費(fèi)
對于數(shù)據(jù)表的使用計費(fèi)，分別依據(jù)這三部分成本進(jìn)行收費(fèi)，稱為：計算付費(fèi)、存儲付費(fèi)和掃描付費(fèi)。
把數(shù)據(jù)資產(chǎn)的成本管理分為數(shù)據(jù)成本計量和數(shù)據(jù)使用計費(fèi)兩個步驟。通過成本計量，可以比較合理地評估出數(shù)據(jù)加工鏈路中的成本，從成本的角度反映出在數(shù)據(jù)加工鏈路中是否存在加工復(fù)雜、鏈路過長、依賴不合理等問題，間接輔助數(shù)據(jù)模型優(yōu)化，提升數(shù)據(jù)整合效率；通過數(shù)據(jù)使用計費(fèi)，可以規(guī)范下游用戶的數(shù)據(jù)使用方法，提升數(shù)據(jù)使用效率，從而為業(yè)務(wù)提供優(yōu)質(zhì)的數(shù)據(jù)服務(wù)。
第15章 數(shù)據(jù)質(zhì)量
數(shù)據(jù)質(zhì)量是數(shù)據(jù)分析結(jié)論有效性和準(zhǔn)確性的基礎(chǔ)，也是這一切的前提。
15.1 數(shù)據(jù)質(zhì)量保障原則
- 完整性
指數(shù)據(jù)的記錄和信息是否完整，是否存在缺失的情況。
數(shù)據(jù)的缺失主要包括記錄的缺失和記錄中某個字段信息的缺失，兩者都會造成統(tǒng)計結(jié)果不準(zhǔn)確，所以說完整性是數(shù)據(jù)質(zhì)量最基礎(chǔ)的保障。
- 準(zhǔn)確性
準(zhǔn)確性是指數(shù)據(jù)中記錄的信息和數(shù)據(jù)是否準(zhǔn)確，是否存在異常或者錯誤的信息。
- 一致性
一般體現(xiàn)在跨度很大的數(shù)據(jù)倉庫體系中，比如阿里巴巴數(shù)據(jù)倉庫，內(nèi)部有很多業(yè)務(wù)數(shù)據(jù)倉庫分支，對于同一份數(shù)據(jù)，必須保證一致性。（必須都是同一種類型，長度也需要保持一致）
所以，才有了公共層的加工，以確保數(shù)據(jù)的一致性。
- 及時性
在確保數(shù)據(jù)的完整性、準(zhǔn)確性和一致性后，接下來就要保障數(shù)據(jù)能夠及時產(chǎn)出，這樣才能體現(xiàn)數(shù)據(jù)的價值。
一般決策支持分析師都希望當(dāng)天就能夠看到前一天的數(shù)據(jù)，而不是等三五天才能看到某一個數(shù)據(jù)分析結(jié)果；否則就已經(jīng)失去了數(shù)據(jù)及時性的價值，分析工作變得毫無意義。現(xiàn)在對時間要求更高了，越來越多的應(yīng)用都希望數(shù)據(jù)是小時級別或者實時級別的。
15.2 數(shù)據(jù)質(zhì)量萬法概述
- 消費(fèi)場景知曉
通過數(shù)據(jù)資產(chǎn)等級和基于元數(shù)據(jù)的應(yīng)用鏈路分析解決消費(fèi)場景知曉的問題。
根據(jù)應(yīng)用的影響程度，確定資產(chǎn)等級；根據(jù)數(shù)據(jù)鏈路血緣，將資產(chǎn)等級上推至各數(shù)據(jù)生產(chǎn)加工的各個環(huán)節(jié)，確定鏈路上所涉及數(shù)據(jù)的資產(chǎn)等級和在各加工環(huán)節(jié)上根據(jù)資產(chǎn)等級的不同所采取的不同處理方式。
- 數(shù)據(jù)生產(chǎn)加工各個環(huán)節(jié)卡點校驗
主要包括在線系統(tǒng)（OLTP）和離線系統(tǒng)（OLAP）數(shù)據(jù)生產(chǎn)加工各個環(huán)節(jié)的卡點校驗。
- 風(fēng)險點監(jiān)控
針對在數(shù)據(jù)日常運(yùn)行過程中可能出現(xiàn)的數(shù)據(jù)質(zhì)量和時效等問題進(jìn)行監(jiān)控，并設(shè)置報警機(jī)制，包括在線數(shù)據(jù)和離線數(shù)據(jù)的風(fēng)險點監(jiān)控兩個方面。
- 質(zhì)量衡量
對質(zhì)量的衡量既有事前的衡量，如DQC覆蓋率；又有事后的衡量，主要用于跟進(jìn)質(zhì)量問題，確定質(zhì)量問題原因、責(zé)任人、解決情況等，并用于數(shù)據(jù)質(zhì)量的復(fù)盤，避免類似事件再次發(fā)生。
根據(jù)質(zhì)量問題對不同等級資產(chǎn)的影響程度，確定其是屬于低影響的事件還是具有較大影響的故障。質(zhì)量分則是綜合事前和事后的衡量數(shù)據(jù)進(jìn)行打分。
- 質(zhì)量配套工具
針對數(shù)據(jù)質(zhì)量的各個方面，都有相關(guān)的工具進(jìn)行保證，以提高效能。
