資料中台架構（企業數字化最佳實踐）-讀書筆記2

資料資産建設

一、資料資産建設概述

1、前期準備

• 資料資産建設的第一步是正确的資料觀：資料資産以價值為依據，以場景化為驅動；能解決場景需求，帶來業務價值的資料都可為資料資産。
• 資料資産建設前期需要詳細的調研（業務、資料）：需在前期調研上下功夫，明确目标和使用客戶是誰、業務痛點是什麼、資料有哪些。
• 資料域設計：對業務的整理了解最終會反映在資料域的設計上，資料域的實作會預先為未來的資料開發提供更充分的支撐。

2、資料資産建設方法論

2.1 識别三種對象（根目錄）

       人、物、關系是建設資料資産的基本要素，要将公司、業務中所包含的所有對象的資料表達識别，将之歸類到三種對象池中。

• 人（根目錄）：泛指客觀世界中的人，是主動的一方，是動作的發起方。
• 物（根目錄）：泛指客觀世界中的物體，一般是動作的承受方。
• 關系（根目錄）：通常指一種行為或者行動，關聯發起方和承受方，如購買行為、浏覽行為、收藏行為、下單行為等。

2.2 建設資料目錄體系

• 按“業務場景和業務流程”組織資料：記錄各種業務交易和行為的資料；
• 按“物”組織資料，統一彙總、記錄；
• 按“人”組織資料，統一彙總、記錄。

2.3 設計主題域及類目體系

       當某種對象下标簽越來越多時，就需要通過設計類目體系的方法來組織、管理和規劃标簽，同時将資料按照主題域進行再次彙聚群組織。

3、資料資産建設的步驟

• 産品選擇：資料資産建設需要一個或者一系列軟體（資料平台）作為支撐
• 技術方案設計：與資料資産相關的技術方案設計包括資料平台的部署方式、資料平台與其他應用的關系、資料平台與現有資料倉庫的關系等
• 資料資源了解：通過資料資源盤點工作充分了解企業的資料資源情況。
• 資料倉庫模型設計：通過對企業業務的了解和對資料資源情況的了解建構資料倉庫模型，同時基于對企業資料化未來的發展規劃選擇合适的資料倉庫模型設計規範。
• 資料開發規範制定：要執行明确的和可監控的資料開發規範。
• 資料倉庫建設：要抽取數、清洗資料、進行資料任務開發，完成資料倉庫建設。
• 資料應用支撐：當企業的資料應用需求明确後，要在資料資産層中做資料應用的資料相關部分的而開發工作，同時通過獨立應用或資料API形式建構資料應用的展示層。

二、産品選型與技術方案設計

• 整合目前各類資料倉庫産品，建構邏輯統一的資料資産層：統一規劃資料資産、建構邏輯完整的資料資産層；保持資料資産在各個資料倉庫間的流轉，保證每個資料倉庫對資料應用的支撐。
• 推翻目前資料建設成果，依托最新技術平台重新建構：對企業内的資料進行完整規劃，建構一體化的資料資産層，使用一套資料工具；這種方案完全基于最新技術平台重新建構資料資産層。雖然投入大，但資料邏輯清晰，後期應用效果好。

三、資料模型設計規範

1、基本設計思路

       資料模型是抽象描述現實業務的一種工具，是通過抽象的實體及實體之間關系的形式表示現實世界中事務互相關系的一種映射。資料模型架構采用分層設計思路，将資料分為ODS（操作資料存儲）層、CDM（公共次元模型）層、ADS（應用資料）層。

ODS層	從業務系統過渡到資料倉庫核心層的操作資料的存儲層，ODS層的資料結構與業務系統基本保持一緻，同時不做長時間的資料存儲。
CDM層	DWD層	次元和事實屬性、度量資訊融合所生成的明細寬表層，目的是為後續的DWS層提供基礎，也可在DWS層無法支撐需求時直接為ADS層提供資料
DWS層	面向分析主題模組化，目的是為ADS層提供足夠的靈活性和擴充性的基礎
ADS層	包括對資料結果的加工整合，以滿足資料應用的最終使用需要。

2、主題域設計

       主題域的設計涉及企業核心業務系統的業務過程，需要對企業核心業務系統的業務流與資料流進行詳細的調研和梳理。

3、資料模型開發規範

       資料模型開發的基本原則如下：

• 資料要幹淨、有效：保證進入資料模型的資料是經過清洗和規範的
• 模型可擴充：核心模型要盡可能保持穩定，經常變化的業務可以通過擴充模型進行分離。
• 禁止逆向調用：不能出現ods層調用cmd層和ads層的資料
• 資料可復原：資料模型多次重跑的結果資料必須保持一緻
• 成本控制：在建構資料模型時，要充分考慮計算和存儲資源建的平衡

4、資料表的命名規範

• ods層資料表命名規範：ods_{資料源}_{原始表名}
• dwd層資料表命名規範：dwd_{資料域縮寫}_{業務過程縮寫}_{重新整理周期辨別}_{表名}
• dws層資料表命名規範：dws_{資料域縮寫}_{業務過程縮寫}_{重新整理周期辨別}_{表名}
• 維表命名規範：dim_{維表定義}
• ads層資料表命名規範：ads_{資料域縮寫}_{業務應用縮寫}_{重新整理周期辨別}_{表名}

5、資料表的設計政策

5.1 DWD層資料表設計政策

• 根據業務過程來定義并建立事實表，在事實表内描述業務過程對應的原子粒度的事物資訊；
• 通過中繼資料系統查詢判斷目前模型對應業務過程是否已有dwd層事實表，吧相同業務過程的度量名額維護在同一個基礎層模型表内；
• dwd層大次元表上的常用統計屬性可以備援到事實表中，以便引用和關聯。

5.2 DWS層資料表設計政策

• 确定dwd層模型所對應的次元和度量資訊；
• 确定對度量進行的衍生計算方式，如求和統計、去重統計；
• 确定資料的重新整理周期。

四、資料開發規範及資料開發

1、資料開發規範

• 代碼書寫規範

代碼結構規範	所有代碼應放入對應的目錄中，如dwd層應放入DWD目錄，且以dwd為命名首字母 不允許tmp、test任務出現在目錄結構中 如需建立tmp、test任務，不可配置周期排程任務，使用完後立即删除 代碼最上面部門，要添加任務名稱、開發者、建立時間、任務描述等注釋 在代碼中間部分，需添加目錄表的create table if not exists語句，以確定表存在或被順利建構。 在代碼下面部分，需要添加insert overwrite語句，確定資料真正插入。
任務命名規範	任務需要以産出表的名稱命名 中間表，以_mid結尾 如任務業務邏輯複雜，需要用到子任務，那麼要将任務和子任務放到同一個檔案夾下。
代碼格式統一	SQL語句中的關鍵字用大寫，其餘的語句用小寫
時間格式統一	統一資料插入時間：yyyy-mm-dd hh:mi:ss 統一資料統計日期：yyyymmdd 統一帶小時的時間格式：yyyy-mm-dd hh:mi:ss 統一日期格式：yyyymmdd
函數使用建議	對于能封裝成函數來使用的複雜邏輯，盡量使用函數
代碼開發建議	在表關聯中盡量合理使用子查詢完成資料預處理，然後在進行關聯； 不使用select * 語句 子查詢隻查詢必需的列 如腳本需要支撐重跑，那麼注意覆寫原有資料 代碼要有縮進規範，要便于閱讀了解，要有關鍵注釋
周期排程配置	支援的排程周期：天、周、月、分鐘、小時 排程規則：任務執行個體是否能完成需要看以下條件（上遊任務執行個體是否運作成功；是否已經到了任務執行個體的設定時間；目前排程資源是否充足） 排程周期和排程時間參數配合使用
動态分區使用	如果資料延遲，那需要重新整理以前的分區資料，可使用動态分區（動态分區指在插入資料時不指定具體分區，而按查詢出來的資料判斷應該插入哪個分區）

• 任務釋出規範

任務釋出前提	已配置好周期排程 已配置好上遊依賴 已配置好相應的參數 任務測試運作通過 已測試并驗證過資料産出的正确性
任務釋出流程	資料運維人員需将資料開發人員送出的作業釋出到生産環境，并在生成環境裡運作成功，要盡量防止出現生産故障。

• 資料品質核查規範

       檢查資料行數是否符合預期、檢查資料不可為空的列是否有空值、檢查是否有資料不符合規範的格式、檢查表的主鍵值是否唯一、将檢查規則腳本配置為周期排程任務，對每日周期性任務的資料産出進行資料品質的檢查。

2、資料采集

       資料采集是指從不同資料存放媒體中獎資料同步至資料中台（即資料內建、資料同步、資料上雲）

2.1 準備工作

• 資料源分類：确定資料源種類，并根據資料的及時性要求，确定采集的技術元件；
• 确定網絡資訊和環境資訊：根據采集方案，對現有網絡和環境進行必要改造、優化；
• 調研資料内容：調研資料全量大小、增量大小、分布情況；
• 調研資料品質：調研資料的增量标記、索引、主鍵資訊等；
• 調研資料範圍：調研需要內建的資料範圍，篩選出需要內建到資料中台的相關資料，一般以支撐業務流程或帶業務屬性的資料為主。

2.2 技術架構

資料采集方式及支援引擎	資料庫離線同步	資料庫、離線、定時、批量	離線計算引擎
資料庫實時同步	資料庫、實時、流式、訂閱	流計算引擎
日志類資料同步	日志、實時、流式、訂閱	離線計算引擎+流計算引擎

3、資料開發

       資料開發是根據資料業務需求，利用大資料開發平台和大資料開發技術，将業務需求建構為資料模型，并通過開發任務支撐資料模型，最終達到滿足業務需求的過程。常見的大資料開發工具提供6種對象，如下：

• 任務：對不同任務類型（如sql、shell、python等）任務配置，包括周期屬性、依賴關系、人物參數等。
• 腳本：資料開發輔助對象，一般用于臨時性分析，不包含周期屬性和依賴關系；
• 資源：資料開發中使用的資源，如IP映射庫、引用的第三方jar包
• 函數：自定義函數、系統函數分類介紹和使用說明
• 流程：任務和任務之間的依賴關系
• 工作流：多個任務之間形成的關系圖，用來解決某一個子業務和子產品的全開發過程。