BKR體系下的數據加工規范設計

王樹明 吳時清 吳蓓蓓

（1.中國煙草總公司湖北省煙草專賣局信息中心 湖北省武漢市 430030 2.武漢楚煙信息技術有限公司 湖北省武漢市 430030）

1 引言

大數據時代，數據治理是所有公司面臨的巨大挑戰。沒有數據，企業缺乏用于做決策的數據的支持,可是有了越來越多的數據，必然增加了管理數據的成本。將數據有效的組織起來，并讓其產生價值，成為一個亟待解決的問題[1]。數據治理的核心問題就是數據加工規范，所有的治理工作都是圍繞這個核心進行的，正因如此，建立起適應企業需求的數據加工規范對于企業變得越來越重要。

2 湖北煙草數據的現狀

隨著湖北省煙草數據信息化工作的快速推進，數據中心在數據采集、加工、共享等方面的管理工作日顯滯后，導致以下問題長期存在：

（1）數據質量不高，“臟數據”、錯數據不斷產生，既包括源端業務系統的基礎數據，也包括入庫后因加工過程不規范而產生的分析型數據。

（2）數據接口混亂，由于數據獲取與開發不規范、數據接口管理措施缺失等原因，數據接口泛濫，“數入多庫、據出多門”的現象比比皆是[2]。

為支撐湖北煙草數字化轉型，支撐日益普遍的創新應用和數據運營的服務需求，湖北省局（公司）重新梳理了整個系統的數據分布，如圖1所示。數據從源端業務系統進入數據中心后，經歷了BKR體系的清洗轉換、匯聚加工、分級存儲，最后向不同的主題提供數據服務。BKR體系是數據中心實現數據治理的核心理念。

圖1：湖北煙草數據總體分布框架

3 數據中心內的BKR體系

描述數據匯聚加工的模型有多種，結合湖北煙草數據加工、管理的現狀，立足于統一、規范的管理目標，設計并采用了BKR體系，建立了湖北煙草數據中心數據加工規范，其中包括庫內數據表分層規范、數據表命名規范、數據表共享規范、血緣分析規范等。

3.1 分層規范

數據中心內的表分三個層級，并嚴格遵守數據分層存儲、層級間加工轉換的規則。這三個層級分別為是B 層、K 層、R 層。

B 層（Base）：基礎業務數據層，主要存放基礎業務數據（即B 表）。它是數據中心的數據基礎和數據緩沖。B 層數據一般保留“范式化”結構，也被稱為“貼源”層。

K 層（KPI，Key Performance Indicators)：匯聚加工層，B 層的數據通過轉換和整合，得到加工過程數據（即K 表）。K 層數據有三種來源：

（1）B 層數據整合或者聚合得到，這是K 層數據最基本的來源；

（2）B 層和K 層數據進行二次或者多次整合得到；

（3）多個K 層數據進行再次整合得到。

R 層（Reports）：報備指標層，是可直接對外提供服務的數據，可直接支撐各類數據應用。其數據來源于B 層或者K 層數據的整合或聚合，其主要服務對象是數據分析、統計報表、駕駛艙等應用。

每個服務主題均對應一個或多個B 表或K 表，但是B 表、K表粒度細、數據量龐大，不利于在線查詢分析。所以在此基礎上定義數據的維度、粒度屬性，建立數據匯集路徑，形成維度降低的R表，以提高查詢分析的效率，并滿足最大程度的復用性要求。另外，R 層數據不可由R 層自身數據表整合而來。庫內數據表的分層/轉換規范如圖2所示。

圖2：庫內數據表分層/轉換規范

3.2 命名規范

3.2.1 B 表

B 表來源于源端業務系統，即基礎業務層的原始粒度數據，因此B 表命名必須反映源端業務屬性。B 表命名規則是：

實體編碼 = T_B_業務域編碼_實體代碼

如：零售戶客戶訂單（T_B_FN_CUSTOMER_ORDER）。

3.2.2 K 表

B 表經加工后形成共享程度高，可支撐核心指標與業務報表的中間表，即K表，因此K表命名必須反映指標主題和字段/維度屬性。K 表命名規則是：

實體編碼 = T_K_主題代碼_維度組合

如：T_K_銷售_日_單位_卷煙（T_K_SELL_DAY_CORP_CIG）。

3.2.3 R 表

將數據按業務單元、服務主題進行加工整合，最終形成指標并對外提供數據服務的數據表為R 表，因此R 表命名必須反映報表主題和應用概述。R 表命名規則：

實體編碼 = T_R_報表主題_分析應用簡寫

如：T_R_ 領導首頁_ 卷煙市場動態分析（T_R_LD_CIG_MARKET_DYNAMIC_ANALYSE）。

有了命名規范以后，可以定期利用逆向工程導出數據中心的sql 腳本，并進行文法分析，以自動的篩選出不符合BKR 分層規范的模式和表格。

3.3 共享規范

從溯源的視角來審視湖北煙草數據加工模型，即為每張表添加從“主鍵”到“外鍵”或從“分散”到“匯總”的邏輯索引，用索引的“入度”和“出度”衡量每張數據表的生成代價和共享程度。其中，“入度”表示數據表的加工復雜程度，理論上講，“入度”值大，表示該數據表的加工過程所依賴的數據表多，加工消耗資源大，即生成代價大；反之，“入度”值小，表示生成代價小。“出度”表示數據表的共享程度，“出度”值大，表示該數據表的共享程度高；“出度”值小，表示該數據表的共享程度低。數據表匯聚加工應滿足“入度”足夠簡單，“出度”足夠寬，體現數據加工過程高內聚、松耦合、高復用的優化原則。

單純以“入度”和“出度”來判斷每張表的共享程度，只能反應局部特性，湖北煙草加工模型從BKR體系的整體視角提出了互為對偶的兩個全局指標——“共享度”和“依賴度”。通過改進的PageRank 算法可以評估每張表的這兩個指標，并為不斷迭代的數據模型提供重要的參考依據。

3.4 BKR血緣關系

厘清BKR 三層數據間的血緣關系[3]，展現數據從源端業務系統到當前位置的完整路徑。當鏈條中某一數據表發生變化時，向上評估其變化的影響范圍，包括但不限于相關的K 表及表內數據、R表及表內數據、數據服務內容等；向下追溯其變化的來源，包括但不限于B 表及表內數據、源端業務系統等。

4 支撐BKR體系的接口規范

BKR 三層體系是數據中心的核心模塊，為了能夠穩定可靠的運營和維護這個體系，還需要建立一套完善的接口規范，并對接口進行統一管理。原則上各業務系統只與數據中心進行數據交換，業務系統間不直接進行數據交換。數據接口有三種類型：

（1）數據入庫接口，即數據從業務系統流入數據中心的數據接口；

（2）數據出庫接口，即數據從數據中心流出到業務系統的數據接口；

（3）庫間接口，即數據在數據中心各庫間流轉的數據接口。

4.1 接口設計規范

接口設計應滿足以下要求：

（1）充分理由：任何接口存在應有充分的理由，盡可能避免出現無意義接口。

（2）職責明確：一個接口只負責一類數據傳輸，盡可能避免同一接口傳輸內容過于復雜。

（3）高內聚低耦合：一個接口包含一類完整數據，不同接口之間的業務、數據關聯應盡可能小。

（4）分析角度明確：設計接口分析的角度要統一明確，應按照業務域、業務環節角度分析設計。

（5）數據量控制：一個接口不宜返回過多數據量，為減少數據處理及傳輸壓力，應對接口進行合理劃分。

4.2 接口編碼規范

數據中心通過建立標準的接口模型，規范數據從業務系統到數據中心的采集轉換過程。接口模型包含業務域實體、業務系統實體、接口目錄實體、接口單實體和接口文件實體，如圖3所示。

圖3：數據接口模型

接口單元編碼規則是由10 位字符表示，如圖4所示。

圖4：采集接口單元編碼規則

4.3 接口實現規范

數據中心常用的接口實現方式有四類。

4.3.1 庫表復制

是使用ETL(Extract-Transform-Load，數據抽取、轉換和加載)工具，基于SQL 數據庫復制批量數據的技術，是源端業務系統數據進入數據中心的主要方式。庫表復制適用于大多數情況下批量數據非實時、準實時的數據傳輸與轉換。

4.3.2 HTTP 接口

是一種基于HTTP 服務的API，是系統之間交互的一種約定。HTTP 接口適用于跨系統的實時數據交互。通過HTTP 接口方式進行數據對接，要明確接口基本信息、請求參數和返回數據等內容。

4.3.3 文件方式

是輸入和輸出以文件或文本方式進行的數據接口實現方式，適用于對時效性要求較低，超大批量數據導入、導出。通過文件方式進行數據對接，需明確文件名和文件格式。

4.3.4 其它方式

用于未來更多類型數據（如非結構化數據）與數據中心交互擴展。

4.4 接口管理規范

數據運維團隊是數據架構和業務數據的維護和管理者，負責按照數據主管部門要求，開展數據接口的統一管理、運行監控、策略維護等工作，響應數據接口新增、變更及刪除（作廢）需求，進行數據需求分析、接口影響分析，并牽頭制定接口維護方案，執行維護操作，發布并更新接口資源目錄。

5 總結

湖北煙草數據治理的工作核心是在數據中心建立完善的BKR體系，并圍繞該體系建立起一系列標準和規范。該體系已經在湖北省公司的煙葉系統中逐步展開，并取得了初步成效。今后將繼續完善和細化該體系，并進一步推廣到煙草的營銷、物流、專賣、審計等其它業務領域。