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