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