1. 何為數(shù)據(jù)治理

數(shù)據(jù)治理是為了讓數(shù)據(jù)在形式上和質量上更好地達成某一數(shù)據(jù)應用目標而進行的數(shù)據(jù)集成、數(shù)據(jù)整理、數(shù)據(jù)分析、數(shù)據(jù)修繕、數(shù)據(jù)發(fā)布，數(shù)據(jù)應用的過程。

2. 為什么需要數(shù)據(jù)治理

數(shù)據(jù)治理平臺通常不是源端的數(shù)據(jù)生產(chǎn)者。政府和大企業(yè)通常有非常多的信息系統(tǒng)，這些信息系統(tǒng)往往有不同的廠家，在不同的時期建設，數(shù)據(jù)的存儲方式和形式一般由廠家根據(jù)業(yè)務需要自行設計。數(shù)據(jù)模型在整體層面上缺少統(tǒng)一規(guī)范的頂層設計。當有的業(yè)務需要跨系統(tǒng)進行數(shù)據(jù)整合應用時，往往都需要相應的項目承包商，自行處理，而這過程中通常會出現(xiàn)各種各樣的問題。例如：
a. 編碼方式不統(tǒng)一，同一對象在不同的系統(tǒng)有不同的編碼。
b. 命名不統(tǒng)一，雖然人通過語義和層級結構理解，可以知道是同一個對象，但因為字符順序和字符上有些許差異，不能用字符串equals比較。
c. 字段缺失。對某一業(yè)務來說是必需的，但在源系統(tǒng)里面，它可能只是一個非必填的邊緣字段，有的對象設置了，有的對象沒有設置。
d. 字段值單位和設值不規(guī)范。例如在源系統(tǒng)中，有些字段可能只是為了展示，所以只要用一個字符串，人能看的懂，中文名稱或西文字符單位都可能出現(xiàn)，中間有空格等等。但是在用在計算的時候，單位和格式就不得不統(tǒng)一
e. 不同來源的數(shù)據(jù)連接不能很好對齊。就像需要連接兩根光纜似的，有的光纖能連上，有的連不上，有的又似乎能找到對應的連上，但又不是很確定。
f. 不同來源的同一對象，同樣含義的字段，取值不一致。

數(shù)據(jù)治理就是源系統(tǒng)和個性化業(yè)務系統(tǒng)之間的中間層，基于底層不同的源系統(tǒng)，為上層多個業(yè)務系統(tǒng)提供形式統(tǒng)一、質量更好且完備的數(shù)據(jù)。如下圖所示：

數(shù)據(jù)治理平臺定位

從數(shù)據(jù)治理平臺的這個定位來看，其實數(shù)據(jù)治理平臺應該盡量和數(shù)據(jù)倉庫、數(shù)據(jù)集市、數(shù)據(jù)中臺等設計統(tǒng)一協(xié)調起來，避免重復設計，冗余開發(fā)。

這樣可以避免各個上層業(yè)務系統(tǒng)獨自對接底層系統(tǒng)。這樣至少具有以下好處：
a. 各個業(yè)務系統(tǒng)廠家不用自己找各個源系統(tǒng)廠家對接，減少尋找業(yè)務人員溝通的時間成本。
b. 各個業(yè)務系統(tǒng)廠家只需要對接數(shù)據(jù)治理平臺，減少了對接和數(shù)據(jù)獲取的工作量和難度。
c. 由數(shù)據(jù)指令平臺統(tǒng)一處理，極大減少了各個廠家各自整合數(shù)據(jù)、規(guī)范化數(shù)據(jù)、處理異常數(shù)據(jù)的工作量，可以更快推進業(yè)務系統(tǒng)開發(fā)落地。
d. 由數(shù)據(jù)治理平臺提供統(tǒng)一形式的，處理過后的數(shù)據(jù)，數(shù)據(jù)的一致性將會更好。統(tǒng)計計算結果在各個業(yè)務系統(tǒng)中的數(shù)據(jù)一致性將會更好。

3. 數(shù)據(jù)治理的架構和過程

數(shù)據(jù)治理架構和過程

首先數(shù)據(jù)治理的關鍵是要有統(tǒng)一的模式設計，能覆蓋將要接入到數(shù)據(jù)平臺的各類型數(shù)據(jù)，并且能合理地描述各類對象之間的關聯(lián)關系。模式設計的基本原則是：從領域內的事物本質出發(fā)，以兼容業(yè)務需要為考量，回顧底層數(shù)據(jù)對模式的支撐性。這種支撐性指的是當前能拿到的各類型數(shù)據(jù)，是否能轉換成當前設計的模式形式以及轉換過來的結果質量如何。避免造就一個理想化模型，以致數(shù)據(jù)無法填充，業(yè)務需求無法滿足。

數(shù)據(jù)治理的主要過程是：
整合-->分析-->修繕-->發(fā)布。（分析和修繕的過程可能需要循環(huán)進行）

為了支撐起這個過程，需要有“Raw數(shù)據(jù)倉庫”、“Formal數(shù)據(jù)倉庫”、和“Pending數(shù)據(jù)倉庫”三個數(shù)據(jù)倉庫。這三種數(shù)據(jù)倉庫都受統(tǒng)一模式的約束，符合模式的設計要求。它們的底層數(shù)據(jù)庫技術可以不一致。一個倉庫也可有有多種類型數(shù)據(jù)庫共同組成。一般有以下幾種類型的數(shù)據(jù)庫可選擇（不同類型數(shù)據(jù)庫有不同的特性，結合開發(fā)技術、數(shù)據(jù)寫入和查詢要求選擇）：

1. OLAP型數(shù)據(jù)。例如Hive、MaxCompute等。
2. 傳統(tǒng)關系型數(shù)據(jù)庫：例如MySQL、PostgreSQL，DM（達夢）等
3. 時序數(shù)據(jù)庫。例如 TDengine，InfluxDB等

Raw數(shù)據(jù)倉庫，存儲的是通過數(shù)據(jù)集成任務整合、經(jīng)過初發(fā)規(guī)范化和修繕的的符合統(tǒng)一模式的生數(shù)據(jù)。
Formal數(shù)據(jù)倉庫，存儲的是經(jīng)過數(shù)據(jù)分析確定符合輸出條件的數(shù)據(jù)。
Pending數(shù)據(jù)倉庫，存儲的是經(jīng)過數(shù)據(jù)分析，發(fā)現(xiàn)不符合輸出條件，待決的數(shù)據(jù)。

數(shù)據(jù)分析引擎基于統(tǒng)一模式上定義的約束，對數(shù)據(jù)進行分析。每條約束都有以下信息：

1. id
2. 名稱
3. 范圍（scope）。有三種形式：
   a. 類名。表示約束針對的不是單個屬性，而是多屬性。如果約束不成立，將描述為某個對象不滿足某個約束要求。
   b. 類名.屬性名。表示約束針對的是單個屬性。如果約束不成立，將描述為某個對象的某個屬性不滿足要求。
   c.空。表示約束是針對多類型的對象綜合判定。可以認為它是全局性的，避免這種約束綁定在多個類上，造成多次重復分析。
4. 數(shù)據(jù)集（數(shù)據(jù)查詢方式）
5. 數(shù)據(jù)判定條件。
6. 順序（order）。缺省都是1，順序小的先開始分析；順序相同的，可以并行，無所謂先后。
7. 是否是強約束。如果是強約束，當強約束不成立時，即時對象數(shù)據(jù)質量閥決定放行，這個對象會輸出，但這個屬性不會輸出。不會輸出的意思是，當目標數(shù)據(jù)庫存在這個對象時，不會去更新這個屬性，如果原先對象不存在，則新建對象此字段會留空。

數(shù)據(jù)分析引擎根據(jù)全局的、類上的、屬性上定義的約束進行分析規(guī)則進行分析。判定約束條件在各個對象上是否成立。

Raw數(shù)據(jù)倉庫的數(shù)據(jù)是否可以流轉到Formal數(shù)據(jù)倉庫，首先需要經(jīng)過數(shù)據(jù)分析，得到結果后由數(shù)據(jù)對象質量閥來判定。數(shù)據(jù)質量閥是一條規(guī)則鏈，由判定規(guī)則組成，最后是一個最終缺省判定。每條規(guī)則有一個判定目標（拒絕或允許），第1條成立的規(guī)則，它的判定目標是拒絕還是允許，就是數(shù)據(jù)質量閥對這個對象的判定。當所有規(guī)則都不成立的時候，最終缺省判定將作為對象數(shù)據(jù)質量閥的最終判定。一般都是允許。得到允許的對象將流轉到Formal數(shù)據(jù)倉庫，得到拒絕判定的對象將流轉到Pending數(shù)據(jù)倉庫。對象質量閥的判定依據(jù)是約束條件的執(zhí)行結果。例如“A.約束1 && A.約束2”

數(shù)據(jù)在進入Formal數(shù)據(jù)倉庫的時候會經(jīng)過一個攔截器。攔截器主要是為了獲得Formal倉庫的增、刪、改操作，以在HBase數(shù)據(jù)版本倉庫寫入對象的新版本數(shù)據(jù)。屬性變化了，才記錄。如果用Formal倉庫存儲數(shù)據(jù)，則可以考慮使用BinLog機制獲得數(shù)據(jù)的增、刪、改操作。

之所以要使用HBase數(shù)據(jù)庫作為對象版本記錄數(shù)據(jù)庫，是為了使用HBase的字段值多版本記錄的特性。

手動和自動數(shù)據(jù)修繕工具可以利用Pending庫中的數(shù)據(jù)和對象版本庫中的數(shù)據(jù)，修繕數(shù)據(jù)。修繕之后，寫入到Formal倉庫。數(shù)據(jù)分析引擎也會分析formal倉庫中的數(shù)據(jù)，當質量不滿足對象質量閥要求時會將它從Formal數(shù)據(jù)倉庫流轉到Pending數(shù)據(jù)倉庫。經(jīng)過修繕之后再寫入Formal倉庫。

Formal數(shù)據(jù)倉庫的數(shù)據(jù)，通過數(shù)據(jù)服務對外發(fā)布。

4. 如何解決自動同步和手動修繕數(shù)據(jù)的被覆蓋的問題

當數(shù)據(jù)不符合對象質量閥的要求，被輸出到了pending倉庫，人工修正以后，寫入到了Formal倉庫。下次數(shù)據(jù)同步分析，如果數(shù)據(jù)符合對象質量閥要求了，那這個人工修繕后的數(shù)據(jù)是該被覆蓋，還是被保留？

這其實應該取決于修繕數(shù)據(jù)的人。他可以有兩種選擇：

1. 如果他覺得他修繕的數(shù)據(jù)是標準的最終答案，那么可以鎖定對象或屬性，不允許被覆蓋；
2. 如果它覺得源端只要改成符合他的某種檢查規(guī)則，那么就采用源端的。

這兩種選擇其實都可以用約束來表示。鎖定一個id為123的對象的屬性，可以定義一條針對某個對象的單屬性強約束，它的判定目標是拒絕，：

id == '123'

第2種選擇就是一般的強約束。