前言

就這樣貌夕，大數據領域蓬勃發(fā)展了好幾年律歼，有很多伙伴執(zhí)迷于技術，成為了分布式計算與存儲的領域專家啡专。也有很多伙伴執(zhí)迷于數據险毁，成為了行業(yè)的數據研發(fā)專家。當然還有很多小伙伴们童，熱衷于工具系統(tǒng)開發(fā)畔况，成為了數據技術專家。那么我們回過頭來考慮病附，什么是大數據问窃，什么又是數據倉庫，什么又是數據技術完沪。大數據其實是個非秤虮樱籠統(tǒng)的感念嵌戈，它是由數據倉庫演化而來的數據與技術方法論，那么我們先說一下數據倉庫的由來：

早在多年以前在Hadoop听皿、Spark熟呛、Storm、Kafka等系列分布式計算與存儲尉姨、消息中間件還沒有成熟的時候庵朝，數據倉庫主要基于Oracle的數倉建設，即便是現(xiàn)在的大數據又厉，仍然使用的是關系理論描述數據之間的關系九府，只是基于其數據存取的特點在關系數據模型的范式上有了不同的選擇而已。但隨著時間的推移覆致，傳統(tǒng)數據倉庫的數據計算與存儲侄旬，已經無法很好地支持海量數據的計算與存儲，這樣大數據（分布式）技術才開始火熱起來煌妈。那么說到這里儡羔，我們先說下數據倉庫中，OLTP和OLAP系統(tǒng)的區(qū)別：

OLTP：數據操作主要是隨機讀寫璧诵，主要采用滿足3NF的實體關系模型存儲數據汰蜘，從而在事務處理中解決數據的冗余和一致性問題。

OLAP：數據操作主要是批量讀寫之宿，事務處理中的一致性不是OLAP所關注族操，其主要關注數據的整合，以及在一次性的大數據查詢和處理中的性能澈缺。

數據模型

數據倉庫建模方法論包含 ER模型 坪创、維度模型、Data Vault模型 及 Anchor模型姐赡。

ER模型：采用ER模型建設數據倉庫模型的出發(fā)點是數據整合莱预，將各個系統(tǒng)中的數據以整個企業(yè)角度按照主題進行 相似性組合 和 合并，并進行一致性處理项滑，為數據分析決策服務依沮。建模一般分為：

• 高層模型：一個高度抽象的模型，描述主要的主題以及主題之間的關系
• 中層模型：在高層模型的基礎上枪狂，細化主題的數據項危喉。
• 物理模型：在中層模型的基礎上，考慮物理存儲州疾，同時基于性能和平臺特點進行物理屬性的設計辜限，也可以做一些表的合并、分區(qū)設計等严蓖。
• 維度模型：選擇需要進行分析決策的業(yè)務過程->選擇粒度->識別維表->選擇事實
• Data Vault模型：它強調簡歷一個可審計的基礎數據層薄嫡，也就是強調數據的歷史性氧急、可追溯性和原子性，而不要求對數據進行過度的一致性處理和整合毫深。該模型有以下幾部分組成：
  • Hub：是企業(yè)的核心業(yè)務實體吩坝，由實體Key、數據倉庫序列代理鍵哑蔫、裝載時間钉寝、數據來源組成。
  • Link：代表Hub之間的關系闸迷。這里與ER模型最大的區(qū)別是將關系作為一個獨立的單元抽象嵌纲。
  • Satellite:是Hub的詳細描述內容，一個Hub可以有多個Satellite稿黍。它由Hub的代理鍵疹瘦、裝載時間崩哩、來源類型巡球、詳細的Hub描述信息組成。
• Anchor模型：進一步規(guī)范化處理邓嘹，其核心思想是所有的擴展只添加而不是修改酣栈，因此將模型規(guī)范到6NF，基本編程了K-V結構化模型汹押。

那么總的來說矿筝，分為三個階段：
　　1、將數據以源表結構相同的方式同步到Oracle棚贾，數據工程師基于ODS數據進行統(tǒng)計窖维。
　　2、通過一些模型技術改變煙囪式的開發(fā)模型妙痹，消除一些冗余铸史，提升數據的一致性。（經驗）在不太成熟怯伊、快速變化的業(yè)務面前琳轿，構建ER模型的風險非常大，不太適合去構建ER模型耿芹。
　　3崭篡、選擇了以Kimball的維度建模為核心理念的模型方法論，同時對其進行了一定的升級和擴展吧秕，構建了公共層模型數據架構體系琉闪。

大數據鏈路

說到這里，有些偏向于技術的同學開始發(fā)問砸彬，我去颠毙，這是啥啊疗涉。。我是來看大數據技術的吟秩！ 我想說的是咱扣，不要著急，我們慢慢來哈涵防。闹伪。那么正是因為時代的發(fā)展，同時業(yè)務種類的增多壮池，數據存儲類型的多樣化（結構化偏瓤、半結構化、非結構化）造成了傳統(tǒng)數據庫無法很會好的支撐椰憋，你們要的大數據技術來了厅克！Hadoop！橙依。证舟。等等被你們帶偏了。窗骑。我們慢慢來女责。。打開你的視野创译，先從全局去觀察整個大數據體系的運作抵知。大數據大數據，我們先把數據進行分層软族，那么數據模型的分層總的來說可以分為ODS刷喜、DWD、DWS立砸、ADS掖疮、DIM：

• ODS層：ODS層屬于操作數據層，是直接從業(yè)務系統(tǒng)采集過來的最原始的數據仰禽，包含了所有業(yè)務的變更過程氮墨，數據粒度也是最細的。
• DWD層：是在ODS層基礎上吐葵，根據業(yè)務過程建模出來的實時事實明細層规揪，對于訪問日志這種數據，會回流到離線系統(tǒng)供下游使用温峭，最大程度地保證實時和離線數據ODS層和DWD層一致猛铅。
• DWS層：訂閱明細層數據后，會在實時計算任務中計算各個維度的匯總指標凤藏。如果維度是各個垂直業(yè)務線通用的奸忽，則會放在實時通用匯總層堕伪，作為通用的數據模型使用。
• ADS層：個性化維度匯總層栗菜，對于不是特別通用的統(tǒng)計維度數據會放在這一層中欠雌，這里計算只有自身業(yè)務才會關注的維度和指標。
• DIM層：實時維表層的數據基本上都是從離線維表層導出來的疙筹，抽取到在線系統(tǒng)中供實時應用調用富俄。

那么整個大數據鏈路，就可以分為采集-->同步-->離線（實時）計算->存儲->線上回流而咆。我們來一一詳解霍比。
1、采集
　　數據從哪來暴备？要到哪去悠瞬？我是誰？我為什么坐在這里涯捻？因為它來自瀏覽器和線上業(yè)務數據浅妆。瀏覽器的日志采集：瀏覽器的日志采集的分類包含（1）頁面瀏覽（展現(xiàn)）日志采集（2）頁面交互日志采集

對于（1）類也就是目前所有互聯(lián)網產品的兩大基本指標：頁面瀏覽量(PV)和訪客數(UV)的統(tǒng)計基礎。

對于（2）用戶可在瀏覽器內與頁面進行的互動汰瘫，互動設計都要求采集用戶的互動行為數據狂打，以便通過量化獲知用戶的興趣點或者體驗優(yōu)化點。

1.1頁面瀏覽日志采集流程：
　用戶在瀏覽器內點擊淘寶首頁鏈接混弥。
按照HTTP協(xié)議，一個標準的HTTP請求由三部分構成：
　《允　（2）請求行蝗拿，分別是請求方法、所氫氣資源的URL以及HTTP協(xié)議版本號蒿涎。

（3）請求報頭哀托，一般會附加很多內容項（每項內容被稱為一個頭域，Header）劳秋，用戶如果已登錄過仓手，則一般會在請求頭中附加一個或多個被稱為Cookie的數據項，其中記錄上一次訪問的信息玻淑。
　∷悦啊（4）請求正文，一般HTTP請求的正文都是空的（body）补履。
　√矸弧（5）服務器接受并解析請求。
與HTTP請求相對應箫锤，一個標準的HTTP響應也由三部分構成贬蛙。
（6）狀態(tài)行雨女，標識了服務器對此次HTTP請求的處理結果。主要內容是由是三位數字構成的狀態(tài)碼阳准，比如成功響應200和代表所請求的資源在服務器沒找到404等氛堕。
（7）響應報頭，在執(zhí)行響應時野蝇，同樣可以加載一些數據項岔擂，這些數據項將在瀏覽器端被讀取和使用。
（8）響應正文浪耘，瀏覽器請求的文檔乱灵、圖片、腳本等七冲，其實就是被包裝在正文內返回瀏覽器的痛倚。
（9）瀏覽器接收到服務器的響應內容，并將其按照規(guī)范展現(xiàn)給用戶澜躺，完成整個請求蝉稳。
　　 綜上所述，真正的采集日志的動作掘鄙，需要在第（9）步耘戚，也就是瀏覽器開始解析文檔時才能進行。最直接的采集思路：在HTML文檔內的適當位置增加一個日志采集點操漠，當瀏覽器解析到這個節(jié)點時收津，將自動觸發(fā)一個特定的HTTP的請求到日志采集服務器。
　　1.2 日志采集服務器整體流程
（1）客戶端日志采集浊伙，由一小段被植入頁面HTML文檔內的JavaScript腳本來執(zhí)行撞秋。由業(yè)務服務器在響應業(yè)務請求時動態(tài)執(zhí)行。
（2）客戶端日志發(fā)送嚣鄙，會向日志服務器發(fā)起一個日志請求吻贿，以將采集到的數據發(fā)送至日志服務器。
（3）服務器端日志收集哑子，日志服務器的日志收集模塊會將日志請求內容寫入一個日志緩沖區(qū)內舅列，完成此條瀏覽日志的收集。
（4）服務器日志解析存檔卧蜓，由日志采集腳本記錄在日志請求行內的參數帐要，將在這個環(huán)節(jié)被解析，轉存入標準的日志文件中并注入實時消息通道內烦却，供其他后端程序讀取和進一步加工處理宠叼。
　　1.3 頁面交互日志采集
由于業(yè)務的發(fā)展及每個頁面業(yè)務的行為、業(yè)務特征都不相同，呈現(xiàn)出高度自定義的業(yè)務特征冒冬，造成采集元數據的困難伸蚯。需要提供一個統(tǒng)一的日志采集服務，如下简烤，可將自助采集的交互日志發(fā)送到日志服務器：
（1）業(yè)務方在元數據管理界面一次注冊需要采集交互日志的業(yè)務剂邮、具體業(yè)務場景以及場景下的具體交互才幾點，在注冊完成后横侦，系統(tǒng)將生成與之對應的交互日志采集代碼模板挥萌。
（2）將交互日志采集代碼植入目標頁面，并將采集代碼與要監(jiān)督的交互行為做綁定枉侧。
（3）當用戶在頁面上產生指定行為時引瀑，采集代碼和正常的業(yè)務交互響應代碼一起被觸發(fā)和執(zhí)行。
（4）采集代碼在采集動作完成后將對應的日志通過HTTP協(xié)議發(fā)送到日志服務器榨馁。
　　這便是整個web端的實時行為數據采集憨栽，當然也有一些來自于線上業(yè)務數據庫的離線數據同步，通常為業(yè)務特征數據翼虫。那么下來我們來聊下數據同步屑柔。

2、數據同步

數據同步的方式有很多種珍剑，從剛才采集端我們發(fā)現(xiàn)掸宛，存在 日志采集 和 數據庫數據同步 兩部分。那么總的來說同步的方式分為 直連同步招拙、數據文件同步唧瘾、數據庫日志解析同步
　　直連同步：對于直連同步來說，直接通過API接口直連線上數據庫迫像，何種方式的比較容易實現(xiàn)劈愚，但是帶來的問題便是對線上數據庫造成一定的壓力，比如直接用sqoop進行數據同步闻妓。
　　數據文件同步：每日從業(yè)務系統(tǒng)直接導出文件，通過FTP等方式同步到大數據集群環(huán)境掠械，然后通過load的方式加載到目標環(huán)境中由缆，這種方式在大多數公司普遍使用。
　　數據庫日志解析同步：通過解析日志文件獲取發(fā)生變更的數據猾蒂，從而滿足增量數據同步的需求均唉。
　　這里的數據同步，更多的偏向于離線數據同步肚菠。對于實時呢舔箭，通常會將數據直接寫入消息中間件例如kafka、flume。然后push到對應的服務端進行解析或者由storm等的流式處理框架進行數據的計算等层扶。

3箫章、數據開發(fā)（離線與實時）

現(xiàn)在好了~數據已經同步過來了，我們要開始做數據處理（ETL）了镜会！檬寂，來自各個業(yè)務系統(tǒng)的數據都已經到了分布式文件系統(tǒng)中，我們挨個一個一個的去清洗戳表、制作業(yè)務寬表桶至、抽取多業(yè)務線通用的數據中間層。做時間長了呢匾旭，發(fā)現(xiàn)镣屹，這不行啊价涝！我天天寫MapReduce女蜈、天天寫Scala，又沒幾個人會飒泻，上手干活兒的成本太大了鞭光，還牽扯到代碼調優(yōu)，那么有沒有統(tǒng)一的工作平臺泞遗，直接寫Sql就好了啊惰许。于是，數據研發(fā)工作臺應運而生史辙，這里先說離線汹买。
　　玩過大數據的都知道，寫MapReduce的成本很高聊倔，而且任何業(yè)務都要去通過Map晦毙、Reduce這樣的模型框架下開發(fā)，非常的繁瑣而又復雜耙蔑。Hive應運而生见妒，基于SQL的數據研發(fā)。但是我們總不能讓數據研發(fā)甸陌，每次都登錄Linux服務器须揣，萬一執(zhí)行錯一個命令，代價很高的钱豁，你懂的~ 同時耻卡，當業(yè)務越來越多，任務越來越多牲尺，不用的任務之間可能會相互依賴卵酪，那么我們就需要一個，數據研發(fā)工作臺來很好的解決這一的問題。
　　1溃卡、統(tǒng)一開發(fā)平臺溢豆，從任務開發(fā)、調試塑煎、測試沫换、發(fā)布、監(jiān)控最铁、報警到運維管理讯赏，形成了整套工具和產品，即提高了開發(fā)效率冷尉，又保證了數據質量漱挎。
　　在任務開發(fā)中遇到的各種問題，如用戶編寫的SQL質量差雀哨、性能低磕谅、不遵循規(guī)范等，總結后形成規(guī)則雾棺，并通過系統(tǒng)及研發(fā)流程保障膊夹，事前解決故障隱患，避免事后處理捌浩。
》排佟（1）在用戶提交job時，校驗系統(tǒng)主要有如下三類規(guī)則校驗：
　　1尸饺、 代碼規(guī)則校驗：如表名規(guī)范进统、生命周期設置、表注釋等浪听。
　　2螟碎、 代碼質量類規(guī)則：如調度參數使用檢查、分母為0提醒迹栓、NULL值參與計算影響結果提醒掉分、插入字段順序錯誤等。
　　3克伊、 代碼性能類規(guī)則：如分區(qū)裁剪失敗叉抡、掃描大表提醒、重復計算檢測等答毫。
　　在校驗系統(tǒng)中，觸發(fā)強規(guī)則后季春，任務的提交就會被阻斷洗搂，必須修復代碼后才能夠再次提交。
　（2） 質量系統(tǒng)DQC
　　主要關注數據質量耘拇，通過配置數據質量校驗規(guī)則撵颊，自動在數據處理任務過程中進行數據質量方面的監(jiān)控。
　　　　1惫叛、 數據監(jiān)控
　　　　強規(guī)則會阻斷任務的執(zhí)行倡勇、弱規(guī)則只會告警不會阻斷任務的執(zhí)行。常見的DQC監(jiān)控規(guī)則有：主鍵監(jiān)控嘉涌、表數據量及波動監(jiān)控妻熊、重要字段的非空監(jiān)控、重要枚舉字段的離散值監(jiān)控仑最、指標值波動監(jiān)控扔役、業(yè)務規(guī)則監(jiān)控等。
　　　　2警医、 數據清洗
　　　　其過程在數據進入ODS層之后執(zhí)行亿胸。對于離線任務，每隔固定時間预皇，數據入倉以后侈玄，啟動清洗任務，調用DQC的清洗規(guī)則吟温，將符合清洗規(guī)則的數據清洗掉序仙，并保存到DIRTY表歸檔。如果清洗掉的數據量大于預設的閾值溯街，則阻斷任務的執(zhí)行诱桂，否則不會阻斷。
　 （3） 數據測試系統(tǒng)
　　　　數據測試的典型測試方法是 功能測試呈昔，主要驗證目標數據是否符合預期挥等。
1、新增業(yè)務需求
2堤尾、數據遷移肝劲、重構和修改
　2、 任務調度系統(tǒng)
（1）數據開發(fā)流程與調度系統(tǒng)的關系
（2）調度系統(tǒng)的核心設計模型
　　　　1郭宝、調度引擎：根據任務節(jié)點屬性以及依賴關系進行實例化辞槐，生成各類參數的實例，并生成調度樹粘室。
　　　　2榄檬、執(zhí)行引擎：根據調度引擎生成的具體任務實例和配置信息，分配CPU衔统、內存鹿榜、運行節(jié)點等資源海雪，在任務對應的執(zhí)行環(huán)境中運行代碼節(jié)點。
〔盏睢（3）任務狀態(tài)機模型
　　　　針對數據任務節(jié)點在整個運行生命周期的狀態(tài)定義奥裸，總共有6種狀態(tài)，狀態(tài)之間的轉換邏輯：1沪袭、未運行 -> 2湾宙、等待運行 -> 3、等待資源 -> 4冈绊、運行中 -> 5侠鳄、成功或失敗。
》俾怠（4）工作流狀態(tài)機模型
　　　　針對數據任務節(jié)點在調度樹中生成的工作流運行的不同狀態(tài)定義畦攘，一共有5種狀態(tài)：1、創(chuàng)建工作流 -> 已創(chuàng)建 -> 運行中 -> 成功或失敗 <- 是否重跑
∈纭（5）調度引擎工作原理
　　　　以時間驅動的方式運行知押，為數據任務節(jié)點生成實例，并在調度樹種生成具體執(zhí)行的工作流鹃骂。
√ǘⅰ（6）執(zhí)行引擎工作原理
（不詳細多說）
　（7）執(zhí)行引擎的用法
用戶系統(tǒng)包括上文的工作流服務畏线、數據同步服務静盅，以及調度引擎生成的各類數據處理任務的調度服務。

下來我們說一下實時寝殴，實時處理有別于離線處理蒿叠。我們知道，實時數據是來自于各個業(yè)務的日志服務器中蚣常，這些數據被實時采集到數據中間件中市咽，供下游實時訂閱使用。數據采集一般基于以下原則抵蚊，按批次對數據進行采集：
　　1施绎、 數據大小限制：當達到限制條件時，把目前采集到的新數據作為一批贞绳。
　　2谷醉、 時間閾值限制：當時間到達一定條件時，也會把目前采集到的新數據作為一批冈闭，避免在數據量少的情況下一直不采集俱尼。
　　隨后呢，數據被采集到中間件后萎攒，需要下游實時訂閱數據号显，并通過（推或拉）的方式到流式計算系統(tǒng)的任務中進行加工處理臭猜。
　 基于Storm的實時數據處理應用，出于性能考慮押蚤，計算任務往往是多線程的，一般會根據業(yè)務主鍵進行分桶處理，并且大部分計算過程需要的數據都會放在內存中，會大大提高吞吐量龄章。
　
　　1灯帮、 去重指標
　　在統(tǒng)計實時任務中，會產生大量的數據存儲在內存中召川，計算邏輯一般都是內存完成的，中間結果數據也會緩存在內存中。那么就需要 布隆過濾器 和 基數估計
　　布隆過濾器：位數組算法的應用掖桦，不保存真實的明細數據，值保存明細數據對哈希值的標記位供汛。
　　基數估計：按照數據的分散程度來估算現(xiàn)有數據集的便捷枪汪，從而得出大概的去重綜合。

2怔昨、 數據傾斜
　　在數據量非常大的時候雀久，單個節(jié)點的處理能力有限，必然會遇到性能瓶頸趁舀。這時就需要對數據進行分桶處理赖捌，分桶處理和離線處理的思路一致。
　　去重指標分桶：對去重值進行分桶Hash矮烹，相同的值一定會被放在同一個桶中去重越庇，最后再把每個桶里面的值進行加和就得到總值。
　　非去重指標分桶：數據隨機分發(fā)到每個桶中奉狈，最后再把每個桶的值匯總卤唉，主要利用的是各個桶的CPU能力。

3嘹吨、 事務處理

為了做到數據的精準處理搬味，包括如下：

超時時間：由于數據處理是按照批次來進行的，當一批數據處理超時時蟀拷，會從拓撲的spout端重發(fā)數據碰纬，另外批次處理的數據量不宜過大，應該增加一個限流的功能问芬，避免數據處理超時悦析。

事務信息：每批數據都會附帶一個事務ID的信息，在重發(fā)的情況下此衅，讓開發(fā)者自己根據事務信息去判斷數據第一次到達和重發(fā)時不同的處理邏輯强戴。

備份機制：開發(fā)人員需要保證內存數據可以通過外部存儲恢復亭螟，因此在計算中用到的中間結果數據需要備份到外部存儲中。

數據被實時加工處理（比如聚合骑歹、清洗等）后预烙，會寫到某個在線服務的存儲系統(tǒng)中，供下游調用方便使用道媚。實時任務在運行過程中扁掸，會計算很多維度和指標，這些數據需要放在一個存儲系統(tǒng)中作為恢復或關聯(lián)使用最域。

1谴分、 中間結果：在實時應用處理中，會有一些狀態(tài)的保存（比如去重指標的明細數據）镀脂，用于發(fā)生故障時牺蹄，使用數據庫中的數據恢復內存現(xiàn)場（HBASE）。

2薄翅、 最終結果數據：這些數據是實時更新的沙兰，寫的頻率非常高，可以直接被下游使用匿刮。

3僧凰、 維表數據：在離線計算系統(tǒng)中，通過同步工具導入到在線存儲系統(tǒng)中熟丸，供實時任務來關聯(lián)實時流數據训措。

最后又牽扯到Hbase的存儲及rowkey設計相關：

1、 表名設計

設計規(guī)則：匯總層標識+數據域+主維度+時間維度

2光羞、 Rowkey設計

設計規(guī)則：MD5+主維度+維度標識+子維度1+時間維度+子維度2

4绩鸣、數據回流

數據回流的含義，就是講計算好的數據表回流至線上系統(tǒng)纱兑，供線上系統(tǒng)使用呀闻，一般回流的數據皆為離線數據，或實時數據的校對后的補充數據潜慎。

綜上所述捡多，我們玩完了整個數據鏈路。铐炫。再見垒手！ 。倒信。等等科贬。。少了好多東西鳖悠，數據管理榜掌？數據治理优妙？數據質量？要啥自行車憎账？那我們繼續(xù)先從數據管理開始套硼。

數據管理

1、元數據

傳統(tǒng)意義上呢鼠哥，元數據是指數據的數據熟菲。元數據打通了源數據、數據倉庫朴恳、數據應用，記錄了數據從 產生 到 消費 的全過程允蚣。

元數據主要記錄了數據倉庫模型的定義于颖、各層級間的映射關系、監(jiān)控數據倉庫的數據狀態(tài)及ETL的任務運行狀態(tài)嚷兔。那么針對元數據森渐，我們又可以分為 技術元數據 和 業(yè)務元數據。

那么我們首先來講技術元數據冒晰，其實理解技術元數據你可以理解為是存儲數據倉庫系統(tǒng)技術細節(jié)的數據同衣，是用于開發(fā)和管理數據倉庫使用的數據。包括：分布式計算系統(tǒng)存儲元數據壶运、分布式計算系統(tǒng)運行元數據 以及 數據開發(fā)平臺中 數據同步耐齐、計算任務、任務調度等信息蒋情，包括數據同步的輸入輸出表和字段埠况，以及同步任務本身的元數據信息。

業(yè)務元數據呢棵癣，從業(yè)務角度描述數據倉庫中的數據辕翰，提供了使用者和實際系統(tǒng)之間的語義層。其中包括：維度及屬性狈谊、業(yè)務過程喜命、指標等的規(guī)范定義，用于更好地管理和使用數據河劝。數據應用元數據壁榕，如數據報表、數據產品的配置等丧裁。

那么綜合兩種元數據护桦，我們可以看出元數據的應用價值，是數據管理煎娇、數據內容二庵、數據應用的基礎贪染，在數據管理方面為集團數據提供在計算、存儲催享、成本杭隙、質量、安全因妙、模型等治理領域上的數據支持痰憎。

1.1 統(tǒng)一元數據建設
元數據建設的目標是 打通 數據接入 到 加工，再到 數據消費 整個鏈路攀涵，規(guī)范元數據體系與模型铣耘，提供統(tǒng)一的元數據服務出口，保障元數據產出的穩(wěn)定性和質量以故。包括：
　∥舷浮（1）元倉底層數據：對元數據做分類，如計算元數據怒详、存儲元數據炉媒、質量元數據等，減少數據重復建設昆烁，保障數據的唯一性吊骤。

（2）根據元倉底層數據構建元倉中間層：建設元倉基礎寬表，也就是元數據中間層静尼，打通從 數據產生 到 消費 整個鏈路白粉，不斷豐富中間層數據，如MaxCompute元數據茅郎、調度元數據蜗元、同步元數據、產出訪問元數據系冗、服務元數據等奕扣。

（3）元數據服務：基于元數據中間層，對外提供標準統(tǒng)一的元數據服務出口掌敬，保障元數據產出的質量惯豆。

1.2 元數據應用

（1） 血緣圖譜：系統(tǒng)化、自動化地對計算與存儲平臺上的數據進行打標奔害、整理楷兽、歸檔。形象地說华临，是為元數據“畫像”的任務芯杀。

實際上，在數據的研發(fā)流程、保障登記揭厚、數據質量要求却特、安全等級、運維策略筛圆、告警設置上都會有差異裂明，那么可以將標簽體系分為四類：

基礎標簽：針對數據的存儲情況、訪問情況太援、安全等級等進行打標闽晦。

數倉標簽：針對數據是增量還是全量、是否可再生提岔、數據的生命周期來進行標簽化處理仙蛉。

業(yè)務標簽：根據數據歸屬的主題域、產品線碱蒙、業(yè)務類型為數據打上不同的標簽捅儒。

潛在標簽：為了說明數據潛在的應用場景，比如社交振亮、媒體、廣告鞭莽、電商坊秸、金融等。

（2） 元數據門戶：

“前臺”產品為數據地圖澎怒，定位消費市場褒搔，實現(xiàn)檢索數據、理解數據等的“找數據”的需求喷面。

“后臺” 產品為數據管理星瘾，定位于一站式數據管理，實現(xiàn)成本管理惧辈、安全管理琳状、質量管理等。

同時盒齿，針對開發(fā)者念逞，主要包括計算費用和健康分管理、存儲費用边翁，并提供優(yōu)化建議和健康分管理翎承。

（3） 應用鏈路分析：通過應用鏈路分析，產出表級血緣符匾、字段血緣和表的應用血緣叨咖。其中表級血緣主要計算方式為：通過 計算引擎日志進行解析 和 根據任務依賴進行解析。

常見的應用鏈路分析應用主要有：影響分析、重要性分析甸各、下線分析垛贤、鏈路分析、尋根分析痴晦、故障排查等南吮。

（4） 數據建模：

通過元數據驅動的數據倉庫模型建設，可以在一定程度上提高數據倉庫建模的數據化指導誊酌，提升建模效率部凑。

所使用的元數據有：

表的基礎元數據 包括：下游情況、查詢次數碧浊、關聯(lián)次數涂邀、聚合次數、產出時間等箱锐。

表的關聯(lián)關系元數據 包括：關聯(lián)表比勉、關聯(lián)類型、關聯(lián)字段驹止、關聯(lián)次數等浩聋。

表的字段的基礎元數據 包括：字段名稱、字段注釋臊恋、查詢次數衣洁、關聯(lián)次數、聚合次數抖仅、過濾次數等坊夫。

其中查詢指SQL的SELECT，關聯(lián)指SQL的JOIN撤卢，聚合指SQL的GROUP BY环凿，過濾指SQL的WHERE。

（5） 驅動ETL開發(fā)：

通過元數據驅動一鍵放吩、批量高效數據同步智听。

2、存儲與成本治理

大數據啊大數據屎慢，數據量太大了瞭稼。。然后呢腻惠，由于業(yè)務形態(tài)的變換环肘，很多已有的ETL任務所產出的業(yè)務表已經木有了業(yè)務價值。但每日跑批任務依舊會占用計算資源集灌，同時增加現(xiàn)有分區(qū)的存儲資源悔雹。那么我們就以成本治理的角度复哆，去干掉它！方法如下：
　　1腌零、 數據壓縮
數據壓縮主要采取archive壓縮方法梯找，對于Hadoop等分布式文件系統(tǒng)來說，通常會將數據存儲3份益涧，通過file壓縮锈锤，可將壓縮比從1:3提高到1:1.5（具體要深入研究）。
　　2闲询、數據重分布
主要采取基于列存儲的方式久免，通過修改表的數據重分布，避免列熱點扭弧，會節(jié)省一定的存儲空間阎姥。一般會采用Distribute by 和 Sort by 的方式。
數據重分布效果的波動比較大鸽捻，主要跟數據表中字段的重復值呼巴、字段本身的大小、其他字段的具體分布有一定的關系御蒲，一般要篩選出重分布效果高于15%的表進行優(yōu)化處理衣赶。
　　3、存儲治理項優(yōu)化
在元數據基礎上厚满，診斷屑埋、加工成多個存儲治理優(yōu)化項。目前已有的存儲治理優(yōu)化項有 未管理表痰滋、空表、最近62天未訪問表续崖、數據無更新無任務表敲街、數據無更新有任務表、開發(fā)庫數據大于100GB且無訪問表严望、長周期表等多艇。
　　4、生命周期管理
生命周期你管理的根本目的是 用最少的存儲成本 來滿足最大的業(yè)務需求像吻，使數據價值最大化峻黍。
　 　　（1） 生命周期管理策略
　　　　　周期性刪除策略：某些歷史數據可能已經沒有價值拨匆，且占用存儲成本姆涩，那么針對無效的歷史數據就可以進行定期清理。
　　　　　徹底刪除策略：無用表策略或者ETL過程產生的臨時數據惭每，以及不需要保留的數據骨饿，可以進行及時刪除，包括刪除元數據。
　　　　　永久保存策略：重復且不可恢復的底層數據和應用數據需要永久保存宏赘。
　　　　　極限存儲策略：超高壓縮重復鏡像數據绒北。
　　　　 冷數據管理策略：一般將重要且不可恢復的、占用存儲空間大于100TB察署，且訪問頻次較低的數據進行冷備（例如3年以上的日志數據）闷游。
　　　　 增量表merge全量表策略：對于對應的delta增量表的保留策略，目前默認保留93天贴汪。
　　∑晖（2） 通用的生命周期管理矩陣
　　　　主要通過對歷史數據的等級劃分與對表類型的劃分生成相應的生命周期管理矩陣。
　　∷皇恰（3） 歷史數據等級劃分
　　　　主要將歷史數據劃分為P0钙勃、P1、P2聂喇、P3四個等級辖源。
　　　　1、 P0：非常重要的主題域數據和非常重要的應用數據希太，具有不可恢復性克饶，如：交易、日志誊辉、集團KPI數據矾湃、IPO關聯(lián)表。

2堕澄、 P1：重要的業(yè)務數據和重要的應用數據邀跃，具有不可恢復性，如重要的業(yè)務產品數據蛙紫。

3拍屑、 P2：重要的業(yè)務數據和重要的應用數據，具有可恢復性坑傅，如交易線ETL產生的中間過程數據僵驰。

4、 P3：不重要的業(yè)務數據和不重要的應用數據唁毒，具有可恢復性蒜茴，如某些SNS產品報表。

（4） 表類型劃分

1浆西、 事件型流水表：數據無重復或者無主鍵數據粉私，如日志。

2近零、 事件型鏡像表：業(yè)務過程性數據毡鉴，有主鍵崔泵，但是對于同樣主鍵的屬性會發(fā)生緩慢變化。如交易猪瞬、訂單狀態(tài)與時間會根據業(yè)務發(fā)生變更憎瘸。

3、 維表：包括維度與維度屬性數據陈瘦，如用戶表幌甘、商品表。

4痊项、 Merge全量表：包括業(yè)務過程性數據或者維表數據锅风。由于數據本身有新增的或者發(fā)生狀態(tài)變更，對于同樣主鍵的數據可能會保留多份鞍泉，因此可以對這些數據根據主鍵進行Merge操作皱埠，主鍵對應屬性只會保留最新狀態(tài)，歷史狀態(tài)保留在前一天的分區(qū)中咖驮。

5边器、 ETL臨時表：指ETL處理過程中產生的臨時表數據，一般不建議保留托修，最多7天忘巧。

6、 TT臨時數據：TT拉取的數據和DbSync產生的臨時數據最終會流轉到ODS層睦刃，ODS層數據作為原始數據保留下來很長時間砚嘴，生命周期默認設置為93天，可以根據實際情況適當減少保留天數涩拙。

7际长、 普通全量表：根據歷史數據等級確定保留策略。

5兴泥、 數據成本計量
　 任何一個計算任務都會涉及計算和存儲資源的消耗也颤，其中計算資源的消耗主要考慮CPU消耗，CPU消耗的單位定義為CU郁轻，代表一個核心(Core)運行一天的消耗量。
在計量數據表的成本時文留，除了考慮數據表本身的計算成本好唯、存儲成本外，還要考慮對上游數據表的掃描帶來的掃描成本燥翅。
　　6骑篙、 數據使用計費
　 規(guī)范下游用戶的數據使用方法，提升數據使用效率森书，從而為業(yè)務提供優(yōu)質的數據服務靶端。
　 3谎势、數據質量

數據質量是每一位數據人的生命線。那么數據質量的評估杨名，可以從完整性脏榆、準確性、一致性和及時性來說台谍。

（1） 完整性

完整性是指數據的 記錄 和 信息是否完整须喂，是否存在缺失的情況。那么數據缺失主要包括 記錄的缺失 和 記錄中某個字段信息 的缺失趁蕊。

（2） 準確性

準確性是指數據中記錄的信息和數據是否準確坞生，是否存在異常或者錯誤的信息掷伙。

（3） 一致性

在數據倉庫中是己，有很多業(yè)務數據倉庫分支，對于同一份數據任柜，必須保證一致性卒废。

（4） 及時性

在確保數據的完整性、準確性和一致性后乘盼，接下來就要保障數據能夠及時產出升熊，這樣才能體現(xiàn)數據的價值。

1绸栅、 數據質量方法概述
　　　 針對數據質量的各個方面级野，都有相關的工具進行保證，以提高效能粹胯。
　　　”腿帷（1） 消費場景知曉：主要通過 數據資產等級 和 基于元數據的應用鏈路分析 解決消費場景知曉的問題。那么又引出 數據資產等級定義 和 數據資產等級落地方法
　　　　 數據資產等級定義：按照一般性和未執(zhí)行风纠，不同性質的重要性依次降低包括：毀滅性質况鸣、全局性質、局部性質竹观、一般性質镐捧、未知性質。

毀滅性質-A1等級 全局性質-A2等級 局部性質-A3等級 一般性質-A4等級臭增，未知性質-Ax等級懂酱，如果一份數據出現(xiàn)在多個應用場景，則遵循就高原則誊抛。

數據資產等級落地方法：通過給不同的數據產品或者應用劃分數據資產等級列牺，再依托元數據的上下游血緣，就可以將整個消費鏈路打上某一數據資產的標簽拗窃，這樣就可以將數以億計的數據進行分類泌辫。

（2） 數據生產加工各個環(huán)節(jié)卡點校驗：校驗部分主要包括在線系統(tǒng)和離線系統(tǒng)數據生產加工各個環(huán)節(jié)的卡點校驗。

發(fā)布上線前的測試包括：Code Review 和 回歸測試九默，對于資產等級較高的任務變更發(fā)布震放，則采取強阻斷的形式，完成回歸測試以后才允許發(fā)布荤西。

（3） 風險點監(jiān)控：主要是針對在數據日常運行過程中可能出現(xiàn)的 數據質量 和 時效 等問題進行監(jiān)控澜搅。

那么風險點監(jiān)控又包括 在線數據風險點監(jiān)控 和 離線數據風險點監(jiān)控。

在線數據風險點監(jiān)控：在線業(yè)務系統(tǒng)的數據生產過程中需要保證數據質量邪锌，主要根據業(yè)務規(guī)則對數據進行監(jiān)控勉躺。

方法：同時訂閱一份相同的數據，在系統(tǒng)中進行邏輯校驗觅丰，當校驗不通過時饵溅，以報警的形式披露出來給到規(guī)則訂閱人，以完成數據的校對妇萄。

離線數據風險點監(jiān)控：主要包括對 數據準確性 和 數據產出及時性 的監(jiān)控蜕企。

數據準確性：由離線開發(fā)人員進行配置來確保數據準確性。

數據及時性包括：

1冠句、任務優(yōu)先級： 調度是個樹形結構轻掩，在優(yōu)先級的設置上，首先是確定業(yè)務的資產等級懦底，等級高的業(yè)務所對應的消費節(jié)點自然配置高優(yōu)先級唇牧，一般業(yè)務則對應低優(yōu)先級，確保高等級業(yè)務準時產出聚唐。

2丐重、任務報警：若發(fā)現(xiàn)異常則執(zhí)行不同等級的預警，根據不同的資產等級執(zhí)行強保障或弱保障杆查。

強保障又包括：監(jiān)控范圍扮惦、監(jiān)控異常、告警對象亲桦、何時告警崖蜜、告警方式。
　　　 自定義監(jiān)控：出錯告警客峭、完成告警豫领、未完成告警、周期性告警桃笙、超時告警。

（4） 質量衡量：主要用于跟進質量問題沙绝，確定質量問題原因搏明、責任人鼠锈、解決情況等。斌慣用語數據質量的復盤星著，避免類似事件再次發(fā)生购笆。

1、數據質量起夜率：每個月的起夜次數將是衡量數據質量建設完善度的一個關鍵指標虚循。

2同欠、數據質量事件：用來跟進數據質量問題的處理過程、用來歸納分析找到數據出現(xiàn)問題的原因横缔、給出后續(xù)預防方案铺遂。

3、數據質量故障體系：故障定義茎刚、故障等級襟锐、故障處理、故障Review膛锭。