前言
就這樣，大數據領域蓬勃發展了好幾年，有很多夥伴執迷於技術，成爲了分佈式計算與存儲的領域專家。也有很多夥伴執迷於數據，成爲了行業的數據研發專家。當然還有很多小夥伴，熱衷於工具系統開發，成爲了數據技術專家。那麼我們回過頭來考慮，什麼是大數據，什麼又是數據倉庫，什麼又是數據技術。大數據其實是個非常籠統的感念，它是由數據倉庫演化而來的數據與技術方法論，那麼我們先說一下數據倉庫的由來：
早在多年以前在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的維度建模爲核心理念的模型方法論，同時對其進行了一定的升級和擴展，構建了公共層模型數據架構體系。
大數據鏈路
說到這裏，有些偏向於技術的同學開始發問，我去，這是啥啊。。我是來看大數據技術的！ 我想說的是，不要着急，我們慢慢來哈。。那麼正是因爲時代的發展，同時業務種類的增多，數據存儲類型的多樣化（結構化、半結構化、非結構化）造成了傳統數據庫無法很會好的支撐，你們要的大數據技術來了！我們慢慢來。。打開你的視野，先從全局去觀察整個大數據體系的運作。大數據大數據，我們先把數據進行分層，那麼數據模型的分層總的來說可以分爲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文檔內的JavaScript腳本來執行。由業務服務器在響應業務請求時動態執行。
（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。
參考文獻：《大數據之路--阿里巴巴大數據實踐》