掃一掃數(shù)據(jù)倉庫管理與全鏈路數(shù)據(jù)體系
來源：未知 時間：2018-49-5 瀏覽次數(shù)：262次
早在多年以前在Hadoop、Spark、Storm、Kafka等系列分布式計算與存儲、消息中間件還沒有成熟的時候，數(shù)據(jù)倉庫主要基于Oracle的數(shù)倉建設(shè)，即便是現(xiàn)在的大數(shù)據(jù)，仍然使用的是關(guān)系理論描述數(shù)據(jù)之間的關(guān)系，只是基于其數(shù)據(jù)存取的特點在關(guān)系數(shù)據(jù)模型的范式上有了不同的選擇而已。但隨著時間的推移，傳統(tǒng)數(shù)據(jù)倉庫的數(shù)據(jù)計算與存儲，已經(jīng)無法很好地支持海量數(shù)據(jù)的計算與存儲，這樣大數(shù)據(jù)（分布式）技術(shù)才開始火熱起來。那么說到這里，我們先說下數(shù)據(jù)倉庫中，OLTP和OLAP系統(tǒng)的區(qū)別：
OLTP：數(shù)據(jù)操作主要是隨機讀寫，主要采用滿足3NF的實體關(guān)系模型存儲數(shù)據(jù)，從而在事務(wù)處理中解決數(shù)據(jù)的冗余和一致性問題。
OLAP：數(shù)據(jù)操作主要是批量讀寫，事務(wù)處理中的一致性不是OLAP所關(guān)注，其主要關(guān)注數(shù)據(jù)的整合，以及在一次性的大數(shù)據(jù)查詢和處理中的性能。
數(shù)據(jù)模型
數(shù)據(jù)倉庫建模方法論包含 ER模型 、維度模型、Data Vault模型 及 Anchor模型。
ER模型：采用ER模型建設(shè)數(shù)據(jù)倉庫模型的出發(fā)點是數(shù)據(jù)整合，將各個系統(tǒng)中的數(shù)據(jù)以整個企業(yè)角度按照主題進行 相似性組合 和 合并，并進行一致性處理，為數(shù)據(jù)分析決策服務(wù)。建模一般分為：
高層模型：一個高度抽象的模型，描述主要的主題以及主題之間的關(guān)系
中層模型：在高層模型的基礎(chǔ)上，細(xì)化主題的數(shù)據(jù)項。
物理模型：在中層模型的基礎(chǔ)上，考慮物理存儲，同時基于性能和平臺特點進行物理屬性的設(shè)計，也可以做一些表的合并、分區(qū)設(shè)計等。
維度模型：選擇需要進行分析決策的業(yè)務(wù)過程->選擇粒度->識別維表->選擇事實
Data Vault模型：它強調(diào)簡歷一個可審計的基礎(chǔ)數(shù)據(jù)層，也就是強調(diào)數(shù)據(jù)的歷史性、可追溯性和原子性，而不要求對數(shù)據(jù)進行過度的一致性處理和整合。該模型有以下幾部分組成：
Hub：是企業(yè)的核心業(yè)務(wù)實體，由實體Key、數(shù)據(jù)倉庫序列代理鍵、裝載時間、數(shù)據(jù)來源組成。
Link：代表Hub之間的關(guān)系。這里與ER模型最大的區(qū)別是將關(guān)系作為一個獨立的單元抽象。
Satellite:是Hub的詳細(xì)描述內(nèi)容，一個Hub可以有多個Satellite。它由Hub的代理鍵、裝載時間、來源類型、詳細(xì)的Hub描述信息組成。
Anchor模型：進一步規(guī)范化處理，其核心思想是所有的擴展只添加而不是修改，因此將模型規(guī)范到6NF，基本編程了K-V結(jié)構(gòu)化模型。
那么總的來說，分為三個階段：
1、將數(shù)據(jù)以源表結(jié)構(gòu)相同的方式同步到Oracle，數(shù)據(jù)工程師基于ODS數(shù)據(jù)進行統(tǒng)計。
2、通過一些模型技術(shù)改變煙囪式的開發(fā)模型，消除一些冗余，提升數(shù)據(jù)的一致性。（經(jīng)驗）在不太成熟、快速變化的業(yè)務(wù)面前，構(gòu)建ER模型的風(fēng)險非常大，不太適合去構(gòu)建ER模型。
3、選擇了以Kimball的維度建模為核心理念的模型方法論，同時對其進行了一定的升級和擴展，構(gòu)建了公共層模型數(shù)據(jù)架構(gòu)體系。
大數(shù)據(jù)鏈路
說到這里，有些偏向于技術(shù)的同學(xué)開始發(fā)問，我去，這是啥啊。。我是來看大數(shù)據(jù)技術(shù)的！ 我想說的是，不要著急，我們慢慢來哈。。那么正是因為時代的發(fā)展，同時業(yè)務(wù)種類的增多，數(shù)據(jù)存儲類型的多樣化（結(jié)構(gòu)化、半結(jié)構(gòu)化、非結(jié)構(gòu)化）造成了傳統(tǒng)數(shù)據(jù)庫無法很會好的支撐，你們要的大數(shù)據(jù)技術(shù)來了！Hadoop！。。等等被你們帶偏了。。我們慢慢來。。打開你的視野，先從全局去觀察整個大數(shù)據(jù)體系的運作。大數(shù)據(jù)大數(shù)據(jù)，我們先把數(shù)據(jù)進行分層，那么數(shù)據(jù)模型的分層總的來說可以分為ODS、DWD、DWS、ADS、DIM：
ODS層：ODS層屬于操作數(shù)據(jù)層，是直接從業(yè)務(wù)系統(tǒng)采集過來的最原始的數(shù)據(jù)，包含了所有業(yè)務(wù)的變更過程，數(shù)據(jù)粒度也是最細(xì)的。
DWD層：是在ODS層基礎(chǔ)上，根據(jù)業(yè)務(wù)過程建模出來的實時事實明細(xì)層，對于訪問日志這種數(shù)據(jù)，會回流到離線系統(tǒng)供下游使用，最大程度地保證實時和離線數(shù)據(jù)ODS層和DWD層一致。
DWS層：訂閱明細(xì)層數(shù)據(jù)后，會在實時計算任務(wù)中計算各個維度的匯總指標(biāo)。如果維度是各個垂直業(yè)務(wù)線通用的，則會放在實時通用匯總層，作為通用的數(shù)據(jù)模型使用。
ADS層：個性化維度匯總層，對于不是特別通用的統(tǒng)計維度數(shù)據(jù)會放在這一層中，這里計算只有自身業(yè)務(wù)才會關(guān)注的維度和指標(biāo)。
DIM層：實時維表層的數(shù)據(jù)基本上都是從離線維表層導(dǎo)出來的，抽取到在線系統(tǒng)中供實時應(yīng)用調(diào)用。
那么整個大數(shù)據(jù)鏈路，就可以分為采集-->同步-->離線（實時）計算->存儲->線上回流。我們來一一詳解。
1、采集
數(shù)據(jù)從哪來？要到哪去？我是誰？我為什么坐在這里？因為它來自瀏覽器和線上業(yè)務(wù)數(shù)據(jù)。瀏覽器的日志采集：瀏覽器的日志采集的分類包含（1）頁面瀏覽（展現(xiàn)）日志采集（2）頁面交互日志采集
對于（1）類也就是目前所有互聯(lián)網(wǎng)產(chǎn)品的兩大基本指標(biāo)：頁面瀏覽量(PV)和訪客數(shù)(UV)的統(tǒng)計基礎(chǔ)。
對于（2）用戶可在瀏覽器內(nèi)與頁面進行的互動，互動設(shè)計都要求采集用戶的互動行為數(shù)據(jù)，以便通過量化獲知用戶的興趣點或者體驗優(yōu)化點。
1.1頁面瀏覽日志采集流程：
用戶在瀏覽器內(nèi)點擊淘寶首頁鏈接。
按照HTTP協(xié)議，一個標(biāo)準(zhǔn)的HTTP請求由三部分構(gòu)成：
?。?）請求行，分別是請求方法、所氫氣資源的URL以及HTTP協(xié)議版本號。
?。?）請求報頭，一般會附加很多內(nèi)容項（每項內(nèi)容被稱為一個頭域，Header），用戶如果已登錄過，則一般會在請求頭中附加一個或多個被稱為Cookie的數(shù)據(jù)項，其中記錄上一次訪問的信息。
（4）請求正文，一般HTTP請求的正文都是空的（body）。
?。?）服務(wù)器接受并解析請求。
與HTTP請求相對應(yīng)，一個標(biāo)準(zhǔn)的HTTP響應(yīng)也由三部分構(gòu)成。
（6）狀態(tài)行，標(biāo)識了服務(wù)器對此次HTTP請求的處理結(jié)果。主要內(nèi)容是由是三位數(shù)字構(gòu)成的狀態(tài)碼，比如成功響應(yīng)200和代表所請求的資源在服務(wù)器沒找到404等。
（7）響應(yīng)報頭，在執(zhí)行響應(yīng)時，同樣可以加載一些數(shù)據(jù)項，這些數(shù)據(jù)項將在瀏覽器端被讀取和使用。
（8）響應(yīng)正文，瀏覽器請求的文檔、圖片、腳本等，其實就是被包裝在正文內(nèi)返回瀏覽器的。
（9）瀏覽器接收到服務(wù)器的響應(yīng)內(nèi)容，并將其按照規(guī)范展現(xiàn)給用戶，完成整個請求。
綜上所述，真正的采集日志的動作，需要在第（9）步，也就是瀏覽器開始解析文檔時才能進行。最直接的采集思路：在HTML文檔內(nèi)的適當(dāng)位置增加一個日志采集點，當(dāng)瀏覽器解析到這個節(jié)點時，將自動觸發(fā)一個特定的HTTP的請求到日志采集服務(wù)器。
1.2 日志采集服務(wù)器整體流程
（1）客戶端日志采集，由一小段被植入頁面HTML文檔內(nèi)的JavaScript腳本來執(zhí)行。由業(yè)務(wù)服務(wù)器在響應(yīng)業(yè)務(wù)請求時動態(tài)執(zhí)行。
（2）客戶端日志發(fā)送，會向日志服務(wù)器發(fā)起一個日志請求，以將采集到的數(shù)據(jù)發(fā)送至日志服務(wù)器。
（3）服務(wù)器端日志收集，日志服務(wù)器的日志收集模塊會將日志請求內(nèi)容寫入一個日志緩沖區(qū)內(nèi)，完成此條瀏覽日志的收集。
（4）服務(wù)器日志解析存檔，由日志采集腳本記錄在日志請求行內(nèi)的參數(shù)，將在這個環(huán)節(jié)被解析，轉(zhuǎn)存入標(biāo)準(zhǔn)的日志文件中并注入實時消息通道內(nèi)，供其他后端程序讀取和進一步加工處理。
1.3 頁面交互日志采集
由于業(yè)務(wù)的發(fā)展及每個頁面業(yè)務(wù)的行為、業(yè)務(wù)特征都不相同，呈現(xiàn)出高度自定義的業(yè)務(wù)特征，造成采集元數(shù)據(jù)的困難。需要提供一個統(tǒng)一的日志采集服務(wù)，如下，可將自助采集的交互日志發(fā)送到日志服務(wù)器：
（1）業(yè)務(wù)方在元數(shù)據(jù)管理界面一次注冊需要采集交互日志的業(yè)務(wù)、具體業(yè)務(wù)場景以及場景下的具體交互才幾點，在注冊完成后，系統(tǒng)將生成與之對應(yīng)的交互日志采集代碼模板。
（2）將交互日志采集代碼植入目標(biāo)頁面，并將采集代碼與要監(jiān)督的交互行為做綁定。
（3）當(dāng)用戶在頁面上產(chǎn)生指定行為時，采集代碼和正常的業(yè)務(wù)交互響應(yīng)代碼一起被觸發(fā)和執(zhí)行。
（4）采集代碼在采集動作完成后將對應(yīng)的日志通過HTTP協(xié)議發(fā)送到日志服務(wù)器。
這便是整個web端的實時行為數(shù)據(jù)采集，當(dāng)然也有一些來自于線上業(yè)務(wù)數(shù)據(jù)庫的離線數(shù)據(jù)同步，通常為業(yè)務(wù)特征數(shù)據(jù)。那么下來我們來聊下數(shù)據(jù)同步。
2、數(shù)據(jù)同步
數(shù)據(jù)同步的方式有很多種，從剛才采集端我們發(fā)現(xiàn)，存在 日志采集 和 數(shù)據(jù)庫數(shù)據(jù)同步 兩部分。那么總的來說同步的方式分為 直連同步、數(shù)據(jù)文件同步、數(shù)據(jù)庫日志解析同步
直連同步：對于直連同步來說，直接通過API接口直連線上數(shù)據(jù)庫，何種方式的比較容易實現(xiàn)，但是帶來的問題便是對線上數(shù)據(jù)庫造成一定的壓力，比如直接用sqoop進行數(shù)據(jù)同步。
數(shù)據(jù)文件同步：每日從業(yè)務(wù)系統(tǒng)直接導(dǎo)出文件，通過FTP等方式同步到大數(shù)據(jù)集群環(huán)境，然后通過load的方式加載到目標(biāo)環(huán)境中，這種方式在大多數(shù)公司普遍使用。
數(shù)據(jù)庫日志解析同步：通過解析日志文件獲取發(fā)生變更的數(shù)據(jù)，從而滿足增量數(shù)據(jù)同步的需求。
這里的數(shù)據(jù)同步，更多的偏向于離線數(shù)據(jù)同步。對于實時呢，通常會將數(shù)據(jù)直接寫入消息中間件例如kafka、flume。然后push到對應(yīng)的服務(wù)端進行解析或者由storm等的流式處理框架進行數(shù)據(jù)的計算等。
3、數(shù)據(jù)開發(fā)（離線與實時）
現(xiàn)在好了~數(shù)據(jù)已經(jīng)同步過來了，我們要開始做數(shù)據(jù)處理（ETL）了！，來自各個業(yè)務(wù)系統(tǒng)的數(shù)據(jù)都已經(jīng)到了分布式文件系統(tǒng)中，我們挨個一個一個的去清洗、制作業(yè)務(wù)寬表、抽取多業(yè)務(wù)線通用的數(shù)據(jù)中間層。做時間長了呢，發(fā)現(xiàn)，這不行?。∥姨焯鞂慚apReduce、天天寫Scala，又沒幾個人會，上手干活兒的成本太大了，還牽扯到代碼調(diào)優(yōu)，那么有沒有統(tǒng)一的工作平臺，直接寫Sql就好了啊。于是，數(shù)據(jù)研發(fā)工作臺應(yīng)運而生，這里先說離線。
玩過大數(shù)據(jù)的都知道，寫MapReduce的成本很高，而且任何業(yè)務(wù)都要去通過Map、Reduce這樣的模型框架下開發(fā)，非常的繁瑣而又復(fù)雜。Hive應(yīng)運而生，基于SQL的數(shù)據(jù)研發(fā)。但是我們總不能讓數(shù)據(jù)研發(fā)，每次都登錄Linux服務(wù)器，萬一執(zhí)行錯一個命令，代價很高的，你懂的~ 同時，當(dāng)業(yè)務(wù)越來越多，任務(wù)越來越多，不用的任務(wù)之間可能會相互依賴，那么我們就需要一個，數(shù)據(jù)研發(fā)工作臺來很好的解決這一的問題。
1、統(tǒng)一開發(fā)平臺，從任務(wù)開發(fā)、調(diào)試、測試、發(fā)布、監(jiān)控、報警到運維管理，形成了整套工具和產(chǎn)品，即提高了開發(fā)效率，又保證了數(shù)據(jù)質(zhì)量。
在任務(wù)開發(fā)中遇到的各種問題，如用戶編寫的SQL質(zhì)量差、性能低、不遵循規(guī)范等，總結(jié)后形成規(guī)則，并通過系統(tǒng)及研發(fā)流程保障，事前解決故障隱患，避免事后處理。
?。?）在用戶提交job時，校驗系統(tǒng)主要有如下三類規(guī)則校驗：
1、 代碼規(guī)則校驗：如表名規(guī)范、生命周期設(shè)置、表注釋等。
2、 代碼質(zhì)量類規(guī)則：如調(diào)度參數(shù)使用檢查、分母為0提醒、NULL值參與計算影響結(jié)果提醒、插入字段順序錯誤等。
3、 代碼性能類規(guī)則：如分區(qū)裁剪失敗、掃描大表提醒、重復(fù)計算檢測等。
在校驗系統(tǒng)中，觸發(fā)強規(guī)則后，任務(wù)的提交就會被阻斷，必須修復(fù)代碼后才能夠再次提交。
?。?） 質(zhì)量系統(tǒng)DQC
主要關(guān)注數(shù)據(jù)質(zhì)量，通過配置數(shù)據(jù)質(zhì)量校驗規(guī)則，自動在數(shù)據(jù)處理任務(wù)過程中進行數(shù)據(jù)質(zhì)量方面的監(jiān)控。
1、 數(shù)據(jù)監(jiān)控
強規(guī)則會阻斷任務(wù)的執(zhí)行、弱規(guī)則只會告警不會阻斷任務(wù)的執(zhí)行。常見的DQC監(jiān)控規(guī)則有：主鍵監(jiān)控、表數(shù)據(jù)量及波動監(jiān)控、重要字段的非空監(jiān)控、重要枚舉字段的離散值監(jiān)控、指標(biāo)值波動監(jiān)控、業(yè)務(wù)規(guī)則監(jiān)控等。
2、 數(shù)據(jù)清洗
其過程在數(shù)據(jù)進入ODS層之后執(zhí)行。對于離線任務(wù)，每隔固定時間，數(shù)據(jù)入倉以后，啟動清洗任務(wù)，調(diào)用DQC的清洗規(guī)則，將符合清洗規(guī)則的數(shù)據(jù)清洗掉，并保存到DIRTY表歸檔。如果清洗掉的數(shù)據(jù)量大于預(yù)設(shè)的閾值，則阻斷任務(wù)的執(zhí)行，否則不會阻斷。
（3） 數(shù)據(jù)測試系統(tǒng)
數(shù)據(jù)測試的典型測試方法是 功能測試，主要驗證目標(biāo)數(shù)據(jù)是否符合預(yù)期。
1、新增業(yè)務(wù)需求
2、數(shù)據(jù)遷移、重構(gòu)和修改
2、 任務(wù)調(diào)度系統(tǒng)
（1）數(shù)據(jù)開發(fā)流程與調(diào)度系統(tǒng)的關(guān)系
（2）調(diào)度系統(tǒng)的核心設(shè)計模型
1、調(diào)度引擎：根據(jù)任務(wù)節(jié)點屬性以及依賴關(guān)系進行實例化，生成各類參數(shù)的實例，并生成調(diào)度樹。
2、執(zhí)行引擎：根據(jù)調(diào)度引擎生成的具體任務(wù)實例和配置信息，分配CPU、內(nèi)存、運行節(jié)點等資源，在任務(wù)對應(yīng)的執(zhí)行環(huán)境中運行代碼節(jié)點。
?。?）任務(wù)狀態(tài)機模型
針對數(shù)據(jù)任務(wù)節(jié)點在整個運行生命周期的狀態(tài)定義，總共有6種狀態(tài)，狀態(tài)之間的轉(zhuǎn)換邏輯：1、未運行 -> 2、等待運行 -> 3、等待資源 -> 4、運行中 -> 5、成功或失敗。
（4）工作流狀態(tài)機模型
針對數(shù)據(jù)任務(wù)節(jié)點在調(diào)度樹中生成的工作流運行的不同狀態(tài)定義，一共有5種狀態(tài)：1、創(chuàng)建工作流 -> 已創(chuàng)建 -> 運行中 -> 成功或失敗 <- 是否重跑
（5）調(diào)度引擎工作原理
以時間驅(qū)動的方式運行，為數(shù)據(jù)任務(wù)節(jié)點生成實例，并在調(diào)度樹種生成具體執(zhí)行的工作流。
（6）執(zhí)行引擎工作原理
（不詳細(xì)多說）
?。?）執(zhí)行引擎的用法
用戶系統(tǒng)包括上文的工作流服務(wù)、數(shù)據(jù)同步服務(wù)，以及調(diào)度引擎生成的各類數(shù)據(jù)處理任務(wù)的調(diào)度服務(wù)。
下來我們說一下實時，實時處理有別于離線處理。我們知道，實時數(shù)據(jù)是來自于各個業(yè)務(wù)的日志服務(wù)器中，這些數(shù)據(jù)被實時采集到數(shù)據(jù)中間件中，供下游實時訂閱使用。數(shù)據(jù)采集一般基于以下原則，按批次對數(shù)據(jù)進行采集：
1、 數(shù)據(jù)大小限制：當(dāng)達(dá)到限制條件時，把目前采集到的新數(shù)據(jù)作為一批。
2、 時間閾值限制：當(dāng)時間到達(dá)一定條件時，也會把目前采集到的新數(shù)據(jù)作為一批，避免在數(shù)據(jù)量少的情況下一直不采集。
隨后呢，數(shù)據(jù)被采集到中間件后，需要下游實時訂閱數(shù)據(jù)，并通過（推或拉）的方式到流式計算系統(tǒng)的任務(wù)中進行加工處理。
基于Storm的實時數(shù)據(jù)處理應(yīng)用，出于性能考慮，計算任務(wù)往往是多線程的，一般會根據(jù)業(yè)務(wù)主鍵進行分桶處理，并且大部分計算過程需要的數(shù)據(jù)都會放在內(nèi)存中，會大大提高吞吐量。
1、 去重指標(biāo)
在統(tǒng)計實時任務(wù)中，會產(chǎn)生大量的數(shù)據(jù)存儲在內(nèi)存中，計算邏輯一般都是內(nèi)存完成的，中間結(jié)果數(shù)據(jù)也會緩存在內(nèi)存中。那么就需要 布隆過濾器 和 基數(shù)估計
布隆過濾器：位數(shù)組算法的應(yīng)用，不保存真實的明細(xì)數(shù)據(jù)，值保存明細(xì)數(shù)據(jù)對哈希值的標(biāo)記位。
基數(shù)估計：按照數(shù)據(jù)的分散程度來估算現(xiàn)有數(shù)據(jù)集的便捷，從而得出大概的去重綜合。
2、 數(shù)據(jù)傾斜
在數(shù)據(jù)量非常大的時候，單個節(jié)點的處理能力有限，必然會遇到性能瓶頸。這時就需要對數(shù)據(jù)進行分桶處理，分桶處理和離線處理的思路一致。
去重指標(biāo)分桶：對去重值進行分桶Hash，相同的值一定會被放在同一個桶中去重，最后再把每個桶里面的值進行加和就得到總值。
非去重指標(biāo)分桶：數(shù)據(jù)隨機分發(fā)到每個桶中，最后再把每個桶的值匯總，主要利用的是各個桶的CPU能力。
3、 事務(wù)處理
為了做到數(shù)據(jù)的精準(zhǔn)處理，包括如下：
超時時間：由于數(shù)據(jù)處理是按照批次來進行的，當(dāng)一批數(shù)據(jù)處理超時時，會從拓?fù)涞膕pout端重發(fā)數(shù)據(jù)，另外批次處理的數(shù)據(jù)量不宜過大，應(yīng)該增加一個限流的功能，避免數(shù)據(jù)處理超時。
事務(wù)信息：每批數(shù)據(jù)都會附帶一個事務(wù)ID的信息，在重發(fā)的情況下，讓開發(fā)者自己根據(jù)事務(wù)信息去判斷數(shù)據(jù)第一次到達(dá)和重發(fā)時不同的處理邏輯。
備份機制：開發(fā)人員需要保證內(nèi)存數(shù)據(jù)可以通過外部存儲恢復(fù)，因此在計算中用到的中間結(jié)果數(shù)據(jù)需要備份到外部存儲中。
數(shù)據(jù)被實時加工處理（比如聚合、清洗等）后，會寫到某個在線服務(wù)的存儲系統(tǒng)中，供下游調(diào)用方便使用。實時任務(wù)在運行過程中，會計算很多維度和指標(biāo)，這些數(shù)據(jù)需要放在一個存儲系統(tǒng)中作為恢復(fù)或關(guān)聯(lián)使用。
1、 中間結(jié)果：在實時應(yīng)用處理中，會有一些狀態(tài)的保存（比如去重指標(biāo)的明細(xì)數(shù)據(jù)），用于發(fā)生故障時，使用數(shù)據(jù)庫中的數(shù)據(jù)恢復(fù)內(nèi)存現(xiàn)場（HBASE）。
2、 最終結(jié)果數(shù)據(jù)：這些數(shù)據(jù)是實時更新的，寫的頻率非常高，可以直接被下游使用。
3、 維表數(shù)據(jù)：在離線計算系統(tǒng)中，通過同步工具導(dǎo)入到在線存儲系統(tǒng)中，供實時任務(wù)來關(guān)聯(lián)實時流數(shù)據(jù)。
最后又牽扯到Hbase的存儲及rowkey設(shè)計相關(guān)：
1、 表名設(shè)計
設(shè)計規(guī)則：匯總層標(biāo)識+數(shù)據(jù)域+主維度+時間維度
2、 Rowkey設(shè)計
設(shè)計規(guī)則：MD5+主維度+維度標(biāo)識+子維度1+時間維度+子維度2
4、數(shù)據(jù)回流
數(shù)據(jù)回流的含義，就是講計算好的數(shù)據(jù)表回流至線上系統(tǒng)，供線上系統(tǒng)使用，一般回流的數(shù)據(jù)皆為離線數(shù)據(jù)，或?qū)崟r數(shù)據(jù)的校對后的補充數(shù)據(jù)。
綜上所述，我們玩完了整個數(shù)據(jù)鏈路。。再見！ 。。等等。。少了好多東西，數(shù)據(jù)管理？數(shù)據(jù)治理？數(shù)據(jù)質(zhì)量？要啥自行車？那我們繼續(xù)先從數(shù)據(jù)管理開始。
數(shù)據(jù)管理
1、元數(shù)據(jù)
傳統(tǒng)意義上呢，元數(shù)據(jù)是指數(shù)據(jù)的數(shù)據(jù)。元數(shù)據(jù)打通了源數(shù)據(jù)、數(shù)據(jù)倉庫、數(shù)據(jù)應(yīng)用，記錄了數(shù)據(jù)從 產(chǎn)生 到 消費 的全過程。
元數(shù)據(jù)主要記錄了數(shù)據(jù)倉庫模型的定義、各層級間的映射關(guān)系、監(jiān)控數(shù)據(jù)倉庫的數(shù)據(jù)狀態(tài)及ETL的任務(wù)運行狀態(tài)。那么針對元數(shù)據(jù)，我們又可以分為 技術(shù)元數(shù)據(jù) 和 業(yè)務(wù)元數(shù)據(jù)。
那么我們首先來講技術(shù)元數(shù)據(jù)，其實理解技術(shù)元數(shù)據(jù)你可以理解為是存儲數(shù)據(jù)倉庫系統(tǒng)技術(shù)細(xì)節(jié)的數(shù)據(jù)，是用于開發(fā)和管理數(shù)據(jù)倉庫使用的數(shù)據(jù)。包括：分布式計算系統(tǒng)存儲元數(shù)據(jù)、分布式計算系統(tǒng)運行元數(shù)據(jù) 以及 數(shù)據(jù)開發(fā)平臺中 數(shù)據(jù)同步、計算任務(wù)、任務(wù)調(diào)度等信息，包括數(shù)據(jù)同步的輸入輸出表和字段，以及同步任務(wù)本身的元數(shù)據(jù)信息。
業(yè)務(wù)元數(shù)據(jù)呢，從業(yè)務(wù)角度描述數(shù)據(jù)倉庫中的數(shù)據(jù)，提供了使用者和實際系統(tǒng)之間的語義層。其中包括：維度及屬性、業(yè)務(wù)過程、指標(biāo)等的規(guī)范定義，用于更好地管理和使用數(shù)據(jù)。數(shù)據(jù)應(yīng)用元數(shù)據(jù)，如數(shù)據(jù)報表、數(shù)據(jù)產(chǎn)品的配置等。
那么綜合兩種元數(shù)據(jù)，我們可以看出元數(shù)據(jù)的應(yīng)用價值，是數(shù)據(jù)管理、數(shù)據(jù)內(nèi)容、數(shù)據(jù)應(yīng)用的基礎(chǔ)，在數(shù)據(jù)管理方面為集團數(shù)據(jù)提供在計算、存儲、成本、質(zhì)量、安全、模型等治理領(lǐng)域上的數(shù)據(jù)支持。
1.1 統(tǒng)一元數(shù)據(jù)建設(shè)
元數(shù)據(jù)建設(shè)的目標(biāo)是 打通 數(shù)據(jù)接入 到 加工，再到 數(shù)據(jù)消費 整個鏈路，規(guī)范元數(shù)據(jù)體系與模型，提供統(tǒng)一的元數(shù)據(jù)服務(wù)出口，保障元數(shù)據(jù)產(chǎn)出的穩(wěn)定性和質(zhì)量。包括：
?。?）元倉底層數(shù)據(jù)：對元數(shù)據(jù)做分類，如計算元數(shù)據(jù)、存儲元數(shù)據(jù)、質(zhì)量元數(shù)據(jù)等，減少數(shù)據(jù)重復(fù)建設(shè)，保障數(shù)據(jù)的唯一性。
?。?）根據(jù)元倉底層數(shù)據(jù)構(gòu)建元倉中間層：建設(shè)元倉基礎(chǔ)寬表，也就是元數(shù)據(jù)中間層，打通從 數(shù)據(jù)產(chǎn)生 到 消費 整個鏈路，不斷豐富中間層數(shù)據(jù)，如MaxCompute元數(shù)據(jù)、調(diào)度元數(shù)據(jù)、同步元數(shù)據(jù)、產(chǎn)出訪問元數(shù)據(jù)、服務(wù)元數(shù)據(jù)等。
?。?）元數(shù)據(jù)服務(wù)：基于元數(shù)據(jù)中間層，對外提供標(biāo)準(zhǔn)統(tǒng)一的元數(shù)據(jù)服務(wù)出口，保障元數(shù)據(jù)產(chǎn)出的質(zhì)量。
1.2 元數(shù)據(jù)應(yīng)用
?。?） 血緣圖譜：系統(tǒng)化、自動化地對計算與存儲平臺上的數(shù)據(jù)進行打標(biāo)、整理、歸檔。形象地說，是為元數(shù)據(jù)“畫像”的任務(wù)。
實際上，在數(shù)據(jù)的研發(fā)流程、保障登記、數(shù)據(jù)質(zhì)量要求、安全等級、運維策略、告警設(shè)置上都會有差異，那么可以將標(biāo)簽體系分為四類：
基礎(chǔ)標(biāo)簽：針對數(shù)據(jù)的存儲情況、訪問情況、安全等級等進行打標(biāo)。
數(shù)倉標(biāo)簽：針對數(shù)據(jù)是增量還是全量、是否可再生、數(shù)據(jù)的生命周期來進行標(biāo)簽化處理。
業(yè)務(wù)標(biāo)簽：根據(jù)數(shù)據(jù)歸屬的主題域、產(chǎn)品線、業(yè)務(wù)類型為數(shù)據(jù)打上不同的標(biāo)簽。
潛在標(biāo)簽：為了說明數(shù)據(jù)潛在的應(yīng)用場景，比如社交、媒體、廣告、電商、金融等。
?。?） 元數(shù)據(jù)門戶：
“前臺”產(chǎn)品為數(shù)據(jù)地圖，定位消費市場，實現(xiàn)檢索數(shù)據(jù)、理解數(shù)據(jù)等的“找數(shù)據(jù)”的需求。
“后臺” 產(chǎn)品為數(shù)據(jù)管理，定位于一站式數(shù)據(jù)管理，實現(xiàn)成本管理、安全管理、質(zhì)量管理等。
同時，針對開發(fā)者，主要包括計算費用和健康分管理、存儲費用，并提供優(yōu)化建議和健康分管理。
?。?） 應(yīng)用鏈路分析：通過應(yīng)用鏈路分析，產(chǎn)出表級血緣、字段血緣和表的應(yīng)用血緣。其中表級血緣主要計算方式為：通過 計算引擎日志進行解析 和 根據(jù)任務(wù)依賴進行解析。
常見的應(yīng)用鏈路分析應(yīng)用主要有：影響分析、重要性分析、下線分析、鏈路分析、尋根分析、故障排查等。
?。?） 數(shù)據(jù)建模：
通過元數(shù)據(jù)驅(qū)動的數(shù)據(jù)倉庫模型建設(shè)，可以在一定程度上提高數(shù)據(jù)倉庫建模的數(shù)據(jù)化指導(dǎo)，提升建模效率。
所使用的元數(shù)據(jù)有：
表的基礎(chǔ)元數(shù)據(jù) 包括：下游情況、查詢次數(shù)、關(guān)聯(lián)次數(shù)、聚合次數(shù)、產(chǎn)出時間等。
表的關(guān)聯(lián)關(guān)系元數(shù)據(jù) 包括：關(guān)聯(lián)表、關(guān)聯(lián)類型、關(guān)聯(lián)字段、關(guān)聯(lián)次數(shù)等。
表的字段的基礎(chǔ)元數(shù)據(jù) 包括：字段名稱、字段注釋、查詢次數(shù)、關(guān)聯(lián)次數(shù)、聚合次數(shù)、過濾次數(shù)等。
其中查詢指SQL的SELECT，關(guān)聯(lián)指SQL的JOIN，聚合指SQL的GROUP BY，過濾指SQL的WHERE。
?。?） 驅(qū)動ETL開發(fā)：
通過元數(shù)據(jù)驅(qū)動一鍵、批量高效數(shù)據(jù)同步。
2、存儲與成本治理
大數(shù)據(jù)啊大數(shù)據(jù)，數(shù)據(jù)量太大了。。然后呢，由于業(yè)務(wù)形態(tài)的變換，很多已有的ETL任務(wù)所產(chǎn)出的業(yè)務(wù)表已經(jīng)木有了業(yè)務(wù)價值。但每日跑批任務(wù)依舊會占用計算資源，同時增加現(xiàn)有分區(qū)的存儲資源。那么我們就以成本治理的角度，去干掉它！方法如下：
1、 數(shù)據(jù)壓縮
數(shù)據(jù)壓縮主要采取archive壓縮方法，對于Hadoop等分布式文件系統(tǒng)來說，通常會將數(shù)據(jù)存儲3份，通過file壓縮，可將壓縮比從1:3提高到1:1.5（具體要深入研究）。
2、數(shù)據(jù)重分布
主要采取基于列存儲的方式，通過修改表的數(shù)據(jù)重分布，避免列熱點，會節(jié)省一定的存儲空間。一般會采用Distribute by 和 Sort by 的方式。
數(shù)據(jù)重分布效果的波動比較大，主要跟數(shù)據(jù)表中字段的重復(fù)值、字段本身的大小、其他字段的具體分布有一定的關(guān)系，一般要篩選出重分布效果高于15%的表進行優(yōu)化處理。
3、存儲治理項優(yōu)化
在元數(shù)據(jù)基礎(chǔ)上，診斷、加工成多個存儲治理優(yōu)化項。目前已有的存儲治理優(yōu)化項有 未管理表、空表、最近62天未訪問表、數(shù)據(jù)無更新無任務(wù)表、數(shù)據(jù)無更新有任務(wù)表、開發(fā)庫數(shù)據(jù)大于100GB且無訪問表、長周期表等。
4、生命周期管理
生命周期你管理的根本目的是 用最少的存儲成本 來滿足最大的業(yè)務(wù)需求，使數(shù)據(jù)價值最大化。
?。?） 生命周期管理策略
周期性刪除策略：某些歷史數(shù)據(jù)可能已經(jīng)沒有價值，且占用存儲成本，那么針對無效的歷史數(shù)據(jù)就可以進行定期清理。
徹底刪除策略：無用表策略或者ETL過程產(chǎn)生的臨時數(shù)據(jù)，以及不需要保留的數(shù)據(jù)，可以進行及時刪除，包括刪除元數(shù)據(jù)。
永久保存策略：重復(fù)且不可恢復(fù)的底層數(shù)據(jù)和應(yīng)用數(shù)據(jù)需要永久保存。
極限存儲策略：超高壓縮重復(fù)鏡像數(shù)據(jù)。
冷數(shù)據(jù)管理策略：一般將重要且不可恢復(fù)的、占用存儲空間大于100TB，且訪問頻次較低的數(shù)據(jù)進行冷備（例如3年以上的日志數(shù)據(jù)）。
增量表merge全量表策略：對于對應(yīng)的delta增量表的保留策略，目前默認(rèn)保留93天。
（2） 通用的生命周期管理矩陣
主要通過對歷史數(shù)據(jù)的等級劃分與對表類型的劃分生成相應(yīng)的生命周期管理矩陣。
?。?） 歷史數(shù)據(jù)等級劃分
主要將歷史數(shù)據(jù)劃分為P0、P1、P2、P3四個等級。
1、 P0：非常重要的主題域數(shù)據(jù)和非常重要的應(yīng)用數(shù)據(jù)，具有不可恢復(fù)性，如：交易、日志、集團KPI數(shù)據(jù)、IPO關(guān)聯(lián)表。
2、 P1：重要的業(yè)務(wù)數(shù)據(jù)和重要的應(yīng)用數(shù)據(jù)，具有不可恢復(fù)性，如重要的業(yè)務(wù)產(chǎn)品數(shù)據(jù)。
3、 P2：重要的業(yè)務(wù)數(shù)據(jù)和重要的應(yīng)用數(shù)據(jù)，具有可恢復(fù)性，如交易線ETL產(chǎn)生的中間過程數(shù)據(jù)。
4、 P3：不重要的業(yè)務(wù)數(shù)據(jù)和不重要的應(yīng)用數(shù)據(jù)，具有可恢復(fù)性，如某些SNS產(chǎn)品報表。
?。?） 表類型劃分
1、 事件型流水表：數(shù)據(jù)無重復(fù)或者無主鍵數(shù)據(jù)，如日志。
2、 事件型鏡像表：業(yè)務(wù)過程性數(shù)據(jù)，有主鍵，但是對于同樣主鍵的屬性會發(fā)生緩慢變化。如交易、訂單狀態(tài)與時間會根據(jù)業(yè)務(wù)發(fā)生變更。
3、 維表：包括維度與維度屬性數(shù)據(jù)，如用戶表、商品表。
4、 Merge全量表：包括業(yè)務(wù)過程性數(shù)據(jù)或者維表數(shù)據(jù)。由于數(shù)據(jù)本身有新增的或者發(fā)生狀態(tài)變更，對于同樣主鍵的數(shù)據(jù)可能會保留多份，因此可以對這些數(shù)據(jù)根據(jù)主鍵進行Merge操作，主鍵對應(yīng)屬性只會保留最新狀態(tài)，歷史狀態(tài)保留在前一天的分區(qū)中。
5、 ETL臨時表：指ETL處理過程中產(chǎn)生的臨時表數(shù)據(jù)，一般不建議保留，最多7天。
6、 TT臨時數(shù)據(jù)：TT拉取的數(shù)據(jù)和DbSync產(chǎn)生的臨時數(shù)據(jù)最終會流轉(zhuǎn)到ODS層，ODS層數(shù)據(jù)作為原始數(shù)據(jù)保留下來很長時間，生命周期默認(rèn)設(shè)置為93天，可以根據(jù)實際情況適當(dāng)減少保留天數(shù)。
7、 普通全量表：根據(jù)歷史數(shù)據(jù)等級確定保留策略。
5、 數(shù)據(jù)成本計量
任何一個計算任務(wù)都會涉及計算和存儲資源的消耗，其中計算資源的消耗主要考慮CPU消耗，CPU消耗的單位定義為CU，代表一個核心(Core)運行一天的消耗量。
在計量數(shù)據(jù)表的成本時，除了考慮數(shù)據(jù)表本身的計算成本、存儲成本外，還要考慮對上游數(shù)據(jù)表的掃描帶來的掃描成本。
6、 數(shù)據(jù)使用計費
規(guī)范下游用戶的數(shù)據(jù)使用方法，提升數(shù)據(jù)使用效率，從而為業(yè)務(wù)提供優(yōu)質(zhì)的數(shù)據(jù)服務(wù)。
3、數(shù)據(jù)質(zhì)量
數(shù)據(jù)質(zhì)量是每一位數(shù)據(jù)人的生命線。那么數(shù)據(jù)質(zhì)量的評估，可以從完整性、準(zhǔn)確性、一致性和及時性來說。
?。?） 完整性
完整性是指數(shù)據(jù)的 記錄 和 信息是否完整，是否存在缺失的情況。那么數(shù)據(jù)缺失主要包括 記錄的缺失 和 記錄中某個字段信息 的缺失。
（2） 準(zhǔn)確性
準(zhǔn)確性是指數(shù)據(jù)中記錄的信息和數(shù)據(jù)是否準(zhǔn)確，是否存在異?；蛘咤e誤的信息。
?。?） 一致性
在數(shù)據(jù)倉庫中，有很多業(yè)務(wù)數(shù)據(jù)倉庫分支，對于同一份數(shù)據(jù)，必須保證一致性。
?。?） 及時性
在確保數(shù)據(jù)的完整性、準(zhǔn)確性和一致性后，接下來就要保障數(shù)據(jù)能夠及時產(chǎn)出，這樣才能體現(xiàn)數(shù)據(jù)的價值。
1、 數(shù)據(jù)質(zhì)量方法概述
針對數(shù)據(jù)質(zhì)量的各個方面，都有相關(guān)的工具進行保證，以提高效能。
（1） 消費場景知曉：主要通過 數(shù)據(jù)資產(chǎn)等級 和 基于元數(shù)據(jù)的應(yīng)用鏈路分析 解決消費場景知曉的問題。那么又引出 數(shù)據(jù)資產(chǎn)等級定義 和 數(shù)據(jù)資產(chǎn)等級落地方法
數(shù)據(jù)資產(chǎn)等級定義：按照一般性和未執(zhí)行，不同性質(zhì)的重要性依次降低包括：毀滅性質(zhì)、全局性質(zhì)、局部性質(zhì)、一般性質(zhì)、未知性質(zhì)。
毀滅性質(zhì)-A1等級 全局性質(zhì)-A2等級 局部性質(zhì)-A3等級 一般性質(zhì)-A4等級，未知性質(zhì)-Ax等級，如果一份數(shù)據(jù)出現(xiàn)在多個應(yīng)用場景，則遵循就高原則。
數(shù)據(jù)資產(chǎn)等級落地方法：通過給不同的數(shù)據(jù)產(chǎn)品或者應(yīng)用劃分?jǐn)?shù)據(jù)資產(chǎn)等級，再依托元數(shù)據(jù)的上下游血緣，就可以將整個消費鏈路打上某一數(shù)據(jù)資產(chǎn)的標(biāo)簽，這樣就可以將數(shù)以億計的數(shù)據(jù)進行分類。
（2） 數(shù)據(jù)生產(chǎn)加工各個環(huán)節(jié)卡點校驗：校驗部分主要包括在線系統(tǒng)和離線系統(tǒng)數(shù)據(jù)生產(chǎn)加工各個環(huán)節(jié)的卡點校驗。
發(fā)布上線前的測試包括：Code Review 和 回歸測試，對于資產(chǎn)等級較高的任務(wù)變更發(fā)布，則采取強阻斷的形式，完成回歸測試以后才允許發(fā)布。
（3） 風(fēng)險點監(jiān)控：主要是針對在數(shù)據(jù)日常運行過程中可能出現(xiàn)的 數(shù)據(jù)質(zhì)量 和 時效 等問題進行監(jiān)控。
那么風(fēng)險點監(jiān)控又包括 在線數(shù)據(jù)風(fēng)險點監(jiān)控 和 離線數(shù)據(jù)風(fēng)險點監(jiān)控。
在線數(shù)據(jù)風(fēng)險點監(jiān)控：在線業(yè)務(wù)系統(tǒng)的數(shù)據(jù)生產(chǎn)過程中需要保證數(shù)據(jù)質(zhì)量，主要根據(jù)業(yè)務(wù)規(guī)則對數(shù)據(jù)進行監(jiān)控。
方法：同時訂閱一份相同的數(shù)據(jù)，在系統(tǒng)中進行邏輯校驗，當(dāng)校驗不通過時，以報警的形式披露出來給到規(guī)則訂閱人，以完成數(shù)據(jù)的校對。
離線數(shù)據(jù)風(fēng)險點監(jiān)控：主要包括對 數(shù)據(jù)準(zhǔn)確性 和 數(shù)據(jù)產(chǎn)出及時性 的監(jiān)控。
數(shù)據(jù)準(zhǔn)確性：由離線開發(fā)人員進行配置來確保數(shù)據(jù)準(zhǔn)確性。
數(shù)據(jù)及時性包括：
1、任務(wù)優(yōu)先級： 調(diào)度是個樹形結(jié)構(gòu)，在優(yōu)先級的設(shè)置上，首先是確定業(yè)務(wù)的資產(chǎn)等級，等級高的業(yè)務(wù)所對應(yīng)的消費節(jié)點自然配置高優(yōu)先級，一般業(yè)務(wù)則對應(yīng)低優(yōu)先級，確保高等級業(yè)務(wù)準(zhǔn)時產(chǎn)出。
2、任務(wù)報警：若發(fā)現(xiàn)異常則執(zhí)行不同等級的預(yù)警，根據(jù)不同的資產(chǎn)等級執(zhí)行強保障或弱保障。
強保障又包括：監(jiān)控范圍、監(jiān)控異常、告警對象、何時告警、告警方式。
自定義監(jiān)控：出錯告警、完成告警、未完成告警、周期性告警、超時告警。
?。?） 質(zhì)量衡量：主要用于跟進質(zhì)量問題，確定質(zhì)量問題原因、責(zé)任人、解決情況等。斌慣用語數(shù)據(jù)質(zhì)量的復(fù)盤，避免類似事件再次發(fā)生。
1、數(shù)據(jù)質(zhì)量起夜率：每個月的起夜次數(shù)將是衡量數(shù)據(jù)質(zhì)量建設(shè)完善度的一個關(guān)鍵指標(biāo)。
2、數(shù)據(jù)質(zhì)量事件：用來跟進數(shù)據(jù)質(zhì)量問題的處理過程、用來歸納分析找到數(shù)據(jù)出現(xiàn)問題的原因、給出后續(xù)預(yù)防方案。
3、數(shù)據(jù)質(zhì)量故障體系：故障定義、故障等級、故障處理、故障Review。
作者：
鏈接：https://www.imooc.com/article/39808
來源：慕課網(wǎng)