《大數據之路1》筆記3：數據管理

一元數據

1.1 元數據概述

定義：元數據是關于數據的數據，元數據打通了源數據、數據倉庫、數據應用，記錄了數據從生產到消費的全部過程。元數據主要記錄數據倉庫中模型的定義、各層級間的映射關系、監控數據倉庫的數據狀態和ETL的任務運行狀態。

分為：技術元數據、業務元數據

技術元數據：存儲關于數據倉庫系統技術細節的數據，是用于開發和管理數據倉庫使用的數據。比如：分布式計算系統存儲元數據；分布式計算系統運行元數據；數據開發平臺中數據同步、計算任務、任務調度等信息；數據質量和運維相關元數據
業務元數據：從業務角度描述了數據倉庫中的數據，提供了介于使用者和實際系統之間的語義層，使得不懂計算機技術的業務人員能夠讀懂數據據倉庫中的數據

價值：數據管理、數據內容、數據應用的基礎。在數據管理方面為集團數據提供在計算、存儲、成本、質量、安全、模型等治理領域上的數據支持

1.2 統一元數據體系建設

首先梳理清楚元倉底層數據，對元數據做分類，如計算元數據、存儲元數據、質量元數據等，減少數據重復建設，保障數據的唯一性
要豐富表和字段使用說明，方便使用和理解。根據元倉底層數據構建元倉中間層，依據 OneData 規范，建設元數據基礎寬表，也就是元數據中間層，打通從數據產生到消費整個鏈路，不斷豐富中間層數據
基于元數據中間層，對外提供標準統一的元數據服務出口，保障元數據產出的質量。

1.3 元數據應用

數據的真正價值在于數據驅動決策，通過數據指導運營

對于元數據，可以用于指導數據相關人員進行日常工作，實現數據化“運營”。對ETL 工程師，可以通過元數據指導其進行模型設計、任務優化和任務下線等各種日常 ETL 工作；對于運維工程師，可以通過元數據指導其進行整個集群的存儲、計算和系統優化等運維工作。

Data Profile

元數據門戶：數據地圖圍繞數據搜索，服務于數據分析、數據開發、數據挖掘、算法工程師、數據運營等數據表的使用者和擁有者，提供方便快捷的數據搜索服務，擁有功能強大的血緣信息及影響分析，利用表使用說明、評價反饋、表收藏及精品表機制，為用戶浮現高質量、高保障的目標數據
應用鏈路分析：通過元數據血緣來分析產品及應用的鏈路，通過血緣鏈路可以清楚地統計到某個產品所用到的數據在計算、存儲、質量上存在哪些問題，通過治理優化保障產品數據的穩定。通過應用鏈路分析，產出表級血緣、字段血緣、表的應用血緣
數據建模：有別于傳統的經驗建模方式，通過下游所使用的元數據指導數據參考建模。可以在一定程度上解決此問題，提高數據倉庫建模的數據化指導，提升建模效率
所使用的元數據：表的基礎元數據；表的關聯關系元數據；表的字段的基礎元數據，舉例：
驅動ETL開發

二計算管理

如何降低計算資源的消耗，提高任務執行的性能，提升任務產出的時間，是計算平臺和 ETL 開發工程師孜孜追求的目標。本章分別從系統優化和任務優化面介紹計算優化。

[[SQL性能優化]]

2.1 系統優化

HB（Oistory-Based Optimizer,基于歷史的優化器）： HBO 是根據任務歷史執行情況為任務分配更合理的資源，包括內存、 CPU 以及 Instance 個數。
HBO 是對集群資源分配的種優化，概括起來就是：任務執行歷史＋集群狀態信息＋優化規則→更優的執行配置。 HBO的提出通過數據分析，發現在系統中存在大量的周期性調度的腳本（物理計劃穩定），且這些腳本的輸入般比較穩定，如果能對這部分腳本進行優化，那么對整個集群的計算資源的使用率將會得到顯著提升。由此，我們想到了 HBO ，根據任務的執行歷史為其分配更合理的計算資源。HBO 般通過自造應調整系統參數來達到控制計算資源的目的。

CBO：優化器（ Optimizer ）引人了 Volcano 模型（請參考論文 The Volcano Optimizer Gener tor: Extensibility and fficient Search ，該模型是基于代價的優化器（ CBO ），并且引人了重新排序 Join (Join Reorder ）和MapJoin (Auto MapJoin ）優化規則等，同時基于 Volcano 模型的優化器會盡最大的搜索寬度來獲取最優計劃。

2.2 任務優化

[[數據傾斜]]
主要介紹數據傾斜方面

Map傾斜
背景：在Map 端讀數據時，由于讀入數據的文件大小分布不均勻，因此會導致有些 Map Instance 讀取并且處理的數據特別多，而有些 Map Instance 處理的數據特別少，造成 Map 端長尾： - 上游表文件的大小特別不均勻，并且小文件特別多，導致當前表Map 端讀取的數據分布不均勻，引起長尾。 - Map 端做聚合時，由于某些 Map Instance 讀取文件的某個值特別多而引起長尾，主要是指 Count Distinct 操作

方案：
- 第一種情況導致的 Map 端長尾，可通過對上游合并小文件，同時調節本節點的小文件的參數來進行優化，即通過設置“ set odps.sql.mapper.merge.limit.size 64 ”和“ set odps .sql.mapper.s plit.size=256“兩個參數來調節，其中第一個參數用于調節 Map 任務的 Map Instance個數；第二個參數用于調節單個 Map Instance 讀取的小文件個數，防止由于小文件過多導致 Map Instance 讀取的數據量很不均勻；兩個參數配合調整。
- 通過“distribute by rand （）”會將 Map 端分發后的數據重新按照隨機值再進行一次分發。原先不加隨機分發函數時，Map 階段需要與使用MapJoin 的小表進行笛卡兒積操作， Map 端完成了大小表的分發和笛卡兒積操作。使用隨機分布函數后，Map 端只負責數據的分發，不再有復雜的聚合或者笛卡兒積操作，因此不會導致 Map 端長尾。
Join傾斜
- Join的某路輸入比較小，可以采用MapJoin,避免分發引起長尾。
- Join 的每路輸入都較大，且長尾是空值導致的，可以將空值處理成隨機值，避免聚集。
- Join 的每路輸入都較大，且長尾是熱點值導致的，可以對熱點值和非熱點值分別進行處理，再合并數據
解決方案： - mapjoin方案：MapJoin 的原理是將Join操作提前到Map 端執行，將小表讀入內存，順序掃描大表完成Join。這樣可以避免因為分發key不均勻導致數據傾斜。但是 MapJoin的使用有限制，必須是Join中的從表比較小才可用。所謂從表，即左外連接中的右表，或者右外連接中的左表。。。
Reduce傾斜

三存儲和成本管理

3.1 數據壓縮

[[數據壓縮]]
在分布式文件系統中，為了提高數據的可用性與性能，通常會將數據存儲3份，這就意味著存儲ITB的邏輯數據，實際上會占用3TB的物理空間。目前 MaxCompute中提供了 archive 壓縮方法，它采用了具有更高壓縮比的壓縮算法，可以將數據保存為RAID file 的形式，數據不再簡單地保存為3份，而是使用盤古RAIDfile的默認值(6,3)格式的文件，即 6份數據+3 份校驗塊的方式，這樣能夠有效地將存儲比約為1:3提高到1:1.5,大約能夠省下一半的物理空間。

3.2 數據重分布

在MaxCompute中主要采用基于列存儲的方式，由于每個表的數據分布不同，插入的數據的順序不一樣，會導致壓縮效果有很大差異，因此通過修改表的數據重分布，避免列熱點，將會節省一定的存儲空間，主要通過修改distrubute by 和sort by字段的方法實現數據重分布

3.3 存儲治理項優化

阿里巴巴數據倉庫在資源管理的過程中，經過不斷地實踐，慢慢摸索出一套適合大數據的存儲優化方法，在元數據的基礎上，診斷、加工成多個存儲治理優化項。目前已有的存儲治理優化項有未管理表、空表、最近62 天未訪問表、數據無更新無任務表、數據無更新有任務表、開發庫數據大于lOOGB 且無訪問表、長周期表等。通過對該優化項的數據診斷，形成治理項，治理項通過流程的方式進行運轉、管理，最終推動各個E TL 開發人員進行操作，優化存儲管理，并及時回收優化的存儲效果。在這個體系下，形成現狀分析、問題診斷、管理優化、效果反饋的存儲治理項優化的閉環。通過這個閉環，可以有效地推進數據存儲的優化，降低存儲管理的成本