@

建設規範

為何要有規範

• 無規矩不成方圓，建立規範的目的也是為了提升開發效率，可以很快的追蹤資料鏈路，最終保障交付質量。資料倉儲是資料工程師的無形產品。

• 資料規範是數倉體系建設的"語言"，是資料使用的說明書和翻譯官，同時也是資料質量的保駕護航者。為了資料體系能夠長久健康的發展，數倉管理，應該從人治逐步轉變到制度化、規範化、工具化的道路上了來。

• 在資料倉儲開發的過程中，遵循一定的規範能夠避免我們的開發偏離原有設計的方向，也能夠保證資料安全。

規範如何落地

• 規範制定：由Leader 或架構師充分考慮公司實際情況，參考行業標準或約定俗成的規範，綜合統一制定。也可以將規範拆分後交由各個部分核心開發人員編寫（比如模型設計師負責模型設計規範，ETL 工程師負責 ETL 開發規範，BI開發人員制定前端開發規範）， Leader 或架構師統一整合，總體上初稿應該儘量保證規範的完整性和各個部分間的相容性。
• 規範討論：初稿完成後由 Leader 牽頭組織部分核心成員進一步完善各個細節，糾正初稿的不足。
• 規範推行：定稿後規範已具備全面推廣的條件，可以下發給所有團隊成員。分發宣講後進入執行階段，所有人必須嚴格遵守，為了確保規範的貫徹落實，除了通過以上兩點引起全員重視外，還需要組織、制度、流程上的多方面保障。
  • 資料模型應該有統一歸口，比如資料架構師，架構師定期檢查模型是否合理合規。
  • 組織資料開發人員，定期 Review 每個人的程式碼，目的是通過對比和討論讓大家明白什麼樣的才是好程式碼，最終使「寫好程式碼」成為基本素養。如果覺得采用區域性思路也可以由 Leader 負責定期檢查，有問題的私下指出來幫助相應的組員逐漸規範。
  • 規範的執行監督，最好引入相應的工具加強監管。比如在有指標體系後設資料、有詞根（可以用來統一表名、欄位名、主題域名等等）庫後設資料、有建表的後設資料、有 ETL 流程的後設資料等時，基於資料標準、資料質量監控如備註是否為空、欄位或表命名裡的詞根是否都在詞根庫裡存在、表或頁面等用到的指標是否都存在於指標體系、資料血緣中是否存在閉環或者孤立的節點。
• 規範完善：在宣講階段、執行階段遇到問題，發行稿應該根據實際情況對規範做出調整，唯有經過實踐檢驗才能愈發完善進而降低溝通成本、提高開發效率、保證交付質量。

有哪些規範

• 設計規範：包括資料模型設計、命名規範、程式碼設計規範、指標體系設計、詞根庫。

  

• 流程規範：主要是從數倉管理的角度，對數倉場景下的各種流程進行約束。核心流程一共提煉出來五類：需求提交、模型設計、ETL開發、前端開發、上線流程。

  • 需求提交流程
    • 需求對接人；
    • 需求提交途徑；
    • 需求澄清、評審會。
  • 模型設計流程
    • 模型評審會溝通
  • ETL開發流程
    • 資料接入方式，資料接入工具
  • 前端開發規範
    • 報表風格；
    • 更新時間監控。
  • 上線流程
    • 確定上線時間；
    • 確定上線途徑；
    • 確定上線後驗證。

• 質量管理規範：針對從資料來源到應用層的資料質量問題，主要是從資料流動的角度實現，包括源端管控、數倉管理、應用管控。
  • 源端管控
    • 監控資料來源接入任務是否正常執行；
    • 監控資料來源資料是否正常。
  • 數倉管理
    • 監控模型任務是否正常執行；
    • 監控模型資料是否正常。
  • 應用管控
    • 監控報表任務是否正常執行；
    • 監控報表資料是否正常。

• 安全規範：安全規範對外是為了防止資料通過網路洩露，對內是通過許可權的管理實現資料許可權最小化；主體分為網路安全、賬號安全、資料安全。
  • 網路安全
    • 考慮資料應用層是否需要外網使用。
  • 賬號安全
    • 一個一賬號原則，可以與公司內部賬號繫結，遵循資料許可權最小化。
  • 資料安全
    • 涉及到個人資訊的資料加密處理；
    • 必須要明文展示的敏感資料掩碼處理；
    • 前端報表頁面加水印顯示資料使用人資訊。

數倉分層

分層原則

數倉分層既要保證資料層的穩定，又要遮蔽對下游的影響，並且要避免鏈路過長，數倉分層總結如下：

• 不能為了分層而分層，沒有最好的，只有最適合的。
• 分層是以解決當前業務快速的資料支撐為目的，為未來抽象出共性的框架並能夠賦能給其他業務線，同時為業務的發展提供穩定的、準確的資料支撐，並能夠按照已有的模型為新業務發展提供方向，也就是資料的驅動和賦能。

好的數倉分層架構會帶來以下好處：

• 清晰的資料結構；
• 資料血緣追蹤；
• 減少重複開發；
• 資料關係條理化；
• 遮蔽原始資料的影響；

常見分層

數倉分層要結合公司業務進行，並且需要清晰明確各層職責，一般採用如下分層結構：

• ODS層：資料來源層，僅匯入業務方資料，不做任何處理，相當於巨量資料平臺前的快照；
• DW層：資料明細層，對資料進行主題劃分，分為事實表和維度表，並對資料進行規範處理，如資料淨化等操作；
• DM層：資料輕彙總層，建設通用性維度和指標，主要表資料還是明細資料，部分資料為彙總資料，主要增強指標複用性；
• APP層：資料應用層，面向不同部門，不同業務需求進行客製化化開發，提供報表資料；

數倉建模在那層建設呢？我們以維度建模為例，建模是在資料來源層的下一層進行建設，就是在DW層進行數倉建模，所以DW層是數倉建設的核心層。

• STG：為ODS全量表提供增量變化的資料，某種意義上和ODS有重疊。
• 資料來源層：ODS（Operational Data Store），是最接近資料來源中資料的一層，為了考慮後續可能需要追溯資料問題，因此對於這一層就不建議做過多的資料淨化工作，原封不動地接入原始資料即可，至於資料的去噪、去重、異常值處理等過程可以放在後面的 DWD 層來做。
• 資料倉儲層：DW（Data Warehouse）是我們在做資料倉儲時要核心設計的一層，從 ODS 層中獲得的資料按照主題建立各種資料模型。DW 層又細分為 DWD（Data Warehouse Detail）層、DWM（Data WareHouse Middle）層和 DWS（Data WareHouse Servce） 層。
  • 資料明細層：DWD（Data Warehouse Detail），該層一般保持和 ODS 層一樣的資料粒度，並且提供一定的資料質量保證。DWD 層要做的就是將資料清理、整合、規範化、髒資料、垃圾資料、規範不一致的、狀態定義不一致的、命名不規範的資料都會被處理。同時，為了提高資料明細層的易用性，該層會採用一些維度退化手法，將維度退化至事實表中，減少事實表和維表的關聯。另外，在該層也會做一部分的資料聚合，將相同主題的資料彙集到一張表中，提高資料的可用性 。
  • 資料中間層：DWM（Data WareHouse Middle），該層會在 DWD 層的資料基礎上，資料做輕度的聚合操作，生成一系列的中間表，提升公共指標的複用性，減少重複加工。直觀來講，就是對通用的核心維度進行聚合操作，算出相應的統計指標。在實際計算中，如果直接從 DWD 或者 ODS 計算出寬表的統計指標，會存在計算量太大並且維度太少的問題，因此一般的做法是，在 DWM 層先計算出多個小的中間表，然後再拼接成一張 DWS 的寬表。由於寬和窄的界限不易界定，也可以去掉 DWM 這一層，只留 DWS 層，將所有的資料再放在 DWS 亦可。
  • 資料服務層：DWS（Data WareHouse Servce），DWS 層為公共彙總層，會進行輕度彙總，粒度比明細資料稍粗，基於 DWD 層上的基礎資料，整合彙總成分析某一個主題域的服務資料，一般是寬表，DWS 層應覆蓋 80% 的應用場景。按照業務劃分，如流量、訂單、使用者等，生成欄位比較多的寬表，用於提供後續的業務查詢，OLAP分析，資料分發等。一般來講，該層的資料表會相對比較少，一張表會涵蓋比較多的業務內容，由於其欄位較多，因此一般也會稱該層的表為寬表。
• 資料應用層：APP（Application），也有叫DM（資料市集）或ADS。主要是提供給資料產品和資料分析使用的資料，一般會存放在 ES、 PostgreSql、Redis 等系統中供線上系統使用，也可能會存在 Hive 或者 Druid 中供資料分析和資料探勘使用。比如經常說的報表資料，一般就放在這裡。
• 維表層（Dimension）：如果維表過多，也可針對維表設計單獨一層，維表層主要包含兩部分資料
  • 高基數維度資料：一般是使用者資料表、商品資料表類似的資料表。資料量可能是千萬級或者上億級別。
  • 低基數維度資料：一般是設定表，比如列舉值對應的中文含義，或者日期維表。 資料量可能是個位數或者幾千幾萬。

主題域劃分原則

• 按照業務或業務過程劃分
  • 業務容易理解，就是指的功能模組、業務線。
  • 業務過程：指企業的業務活動事件，如下單、支付、退款都是業務過程。不過需要注意的是，一個業務過程是一個不可拆分的行為事件，通俗的講，業務過程就是企業活動中的事件。
• 按照資料域劃分
  • 資料域是指面向業務分析，將業務過程或者維度進行抽象的集合。其中，業務過程可以概括為一個個不可拆分的行為事件，在業務過程下，可以定義指標，維度是指度量的環境，如買家下單事件，買家是維度。為保障整個體系生命力，資料域是需要抽象提煉，並且長期維護和更新的，但不輕易變動。
  • 在劃分資料域時，既能涵蓋當前所有的業務需求，又能在新業務進入時無影響的被包含進已有的資料域中和擴充套件新的資料域。

資料模型設計原則

• 高內聚、低耦合：即主題內部高內聚、不同主題間低耦合。明細層按照業務過程劃分主題，彙總層按照「實體+活動」劃分不同分析主題，應用層根據應用需求劃分不同應用主題。
• 核心模型和擴充套件模型要分離：建立核心模型與擴充套件模型體系，核心模型包括的欄位支援常用的核心業務，擴充套件模型包括的欄位支援個性化或少量應用的需要，不能讓擴充套件模型的欄位過度侵入核心模型，以免破壞核心模型的架構簡潔性與可維護性。
• 公共處理邏輯下沉及單一：越是底層公用的處理邏輯越應該在資料排程依賴的底層進行封裝與實現，不要讓公用的處理邏輯暴露給應用實現，不要讓公共邏輯多處同時存在。
• 成本與效能平衡：適當的資料冗餘可換取查詢和重新整理效能，不宜過度冗餘與資料複製。
• 資料可回滾：處理邏輯不變，在不同時間多次執行資料結果確定不變。

資料型別規範

需統一規定不同的資料的資料型別，嚴格按照規定的資料型別執行：

金額 :   double 或使用 decimal(28,6) 控制精度等，明確單位是分還是元
字串:  string
id:       bigint
時間:    string
狀態 :   string

資料冗餘規範

針對寬表的冗餘欄位要確保：

• 冗餘欄位要使用高頻，下游3個或以上使用。
• 冗餘欄位引入不應造成本身資料產生過多的延後。
• 冗餘欄位和已有欄位的重複率不應過大，原則上不應超過60%，如需要可以選擇join或原表拓展。

表規範

處理規範

• 增量表：新增資料，增量資料是上次匯出之後的新資料。
  • 記錄每次增加的量，而不是總量；
  • 增量表，只報變化量，無變化不用報；
  • 每天一個分割區。
• 全量表：每天的所有的最新狀態的資料。
  • 全量表，有無變化，都要報；
  • 每次上報的資料都是所有的資料（變化的 + 沒有變化的）；
  • 只有一個分割區。
• 快照表：按日分割區，記錄截止資料日期的全量資料。
  • 快照表，有無變化，都要報；
  • 每次上報的資料都是所有的資料（變化的 + 沒有變化的）；
  • 一天一個分割區。
• 拉連結串列：記錄截止資料日期的全量資料。
  • 記錄一個事物從開始，一直到當前狀態的所有變化的資訊；
  • 拉連結串列每次上報的都是歷史記錄的最終狀態，是記錄在當前時刻的歷史總量；
  • 當前記錄存的是當前時間之前的所有歷史記錄的最後變化量（總量）；
  • 只有一個分割區。

命名規範

• 表名、欄位名採用一個下劃線分隔詞根（範例：clienttype->client_type）。
• 每部分使用小寫英文單詞，屬於通用欄位的必須滿足通用欄位資訊的定義。 儘量用英文簡寫，部分可以漢語拼音首字母標準縮寫如中國製造zgzz。
• 表名、欄位名需以字母為開頭。
• 命名不宜過長，表名、欄位名最長不超過 64 個英文字元。
• 優先使用詞根中已有關鍵字（數倉標準設定中的詞根管理），定期 Review 新增命名的不合理性。
• 在表名自定義部分禁止採用非標準的縮寫。

模型層 ：卡券主題域中卡券購買主題 dwd_ride_package_user_ride_cashcoupon_record_df。分解 ：dwd-層次 ride_package-主題域 user_ride_cashcoupon_record-主題 d-按天 f-全量

貼源層以及以下： 領養收益表ods_mysql_adoptdb_adopt_order_income_di。分解 ：ods-層次 mysql-資料庫型別 adoptdb-庫名 order_income-業務表名 d-按天i-增量

生命週期管理

通過對歷史資料的等級劃分與對錶型別的劃分生成相應的生命週期管理矩陣。

• 主要將歷史資料劃分為P0、P1、P2、P3四個等級，其具體定義如下：
  • P0: 非常重要的主題域資料和非常重要的應用資料，具有不可恢復性，如交易、紀錄檔、集團KPI資料、IPO關聯表。
  • P1: 重要的業務資料和重要的應用資料，具有不可恢復性，如重要的業務產品資料。
  • P2: 重要的業務資料和重要的應用資料，具有可恢復性，如交易線ETL產生的中間過程資料。
  • P3: 不重要的業務資料和不重要的應用資料，具有可恢復性，如某些SNS產品報表。
• 表型別劃分
  • 事件型流水錶（增量表）：指資料無重複或者無主鍵資料，如紀錄檔。
  • 事件型映象表（增量表）：指業務過程性資料，有主鍵，但是對於同樣主鍵的屬性會發生緩慢變化，如交易、訂單狀態與時間會根據業務發生變更。
  • 維表：包括維度與維度屬性資料，如使用者表、商品表。
  • Merge全量表：包括業務過程性資料或者維表資料。由於資料本身有新增的或者發生狀態變更，對於同樣主鍵的資料可能會保留多份，因此可以對這些資料根據主鍵進行Merge操作，主鍵對應的屬性只會保留最新狀態，歷史狀態保留在前一天的分割區中。例如，使用者表、交易表等都可以進行Merge操作。
  • ETL臨時表：指ETL處理過程中產生的臨時表資料，一版不建議保留，最多7天。
  • TT臨時資料：TT拉取的資料和DbSync產生的臨時資料最終會流轉到DS層，ODS層資料作為原始資料保留下來，從而使得TT&DbSync上游資料成為臨時資料。這類資料不建議保留很長時間，宣告週期預設設定為93天，可以根據實際情況適當減少保留天數。
  • 普通全量表：很多小業務資料或者產品資料，BI一般是直接全量拉取，這種方式效率快，對儲存壓力也不是很大，而且表保留很長時間，可以根據歷史資料等級確定保留策略。

通過上述歷史資料等級劃分與表型別劃分，生成相應的宣告週期管理矩陣，如下表所示：

指標管理

指標定義

指標是用於衡量事物發展程度的單位或方法，也常被稱作度量，通常情況下也是報表統計的欄位，例如：人口數、營業收入、使用者數、利潤率、成功率、失敗率、覆蓋率等。

指標構成

• 資料域
  • 資料域是統一數倉層的頂層劃分，是一個較高層次的資料歸類標準，是對企業業務過程進行抽象、提煉、組合的集合，面向業務分析，一個資料域對應一個宏觀分析領域，比如採購域、供應鏈域、HR域等。
  • 資料域是抽象、提煉出來的，並且不輕易變動，既能涵蓋當前所有業務需求，又能在新業務進入時無影響地將其分配到已有的資料域中，只有當所有分類都不合適時才會擴充套件新的資料域。
  • 資料域是有效歸納、組織業務過程的方式，同時方便定位指標/度量。
• 業務過程
  • 業務過程是一種企業的業務活動事件，且是企業經營過程中不可拆分的行為事件，比如下訂單、銀行轉賬、賬號註冊都是業務過程。
  • 業務過程產生度量，並且會被轉換為最終的事實表中的事實。業務過程一般與事實表一一對應，也有一對多或者多對一的特殊情況，比如累計快照事實表就會把多個業務過程產生的事實在一張表中表達。
• 統計週期
  • 統計週期即統計資料的時間範圍，例如歷史至今、最近7天、最近30天、最近1年等（類似於SQL中where後的時間條件）。
  • 公共定義僅支援定義統計週期，定義時與資料域、業務過程、事實/維度表是否定義無關，在此僅作計算邏輯定義。
• 業務限定
  • 業務限定是指除統計維度以外對指標進行限定抽象的業務場景修飾詞，限定統計的業務範圍，篩選出符合業務規則的記錄（類似於SQL中where後的條件，不包括時間區間）。
  • 業務限定也有歸屬的資料域，某個業務限定來源於一張事實表或維度表，繼承來源表的資料域，比如限定詞「江蘇省」、「部門-銷售事業部」等。
• 維度
  • 維度是度量的環境，用來反映業務的一類屬性，這類屬性的集合構成一個維度。維度屬於一個資料域，如組織維度（其中包括產品線、部門、科室、車間等）、時間維度（其中包括年、季、月、周、日等）。

指標分類

數倉指標分類主要為原子指標、派生指標、複合指標、應用指標。

• 原子指標：是針對某一業務事件行為的度量，是一種不可拆分的指標，具有明確業務含義，比如支付金額。原子指標有確定的欄位名稱、資料型別、演演算法說明、所屬資料域和業務過程。原子指標名稱一般採用「動作+度量」方式命名，比如支付金額、註冊使用者數。
• 派生指標：可以理解為對原子指標業務統計範圍的圈定，比如最近1年銷售事業部銷售金額（「最近1年」是統計週期，「銷售事業部」是業務限定，「銷售金額」是原子指標），1個派生指標=1個原子指標+統計週期+業務限定。

• 複合指標：是基於已經設計好的派生指標，設定複合計算邏輯而構成的指標。例如，一個已儲存的派生指標A為最近1年銷售事業部銷售金額，另一個已儲存的派生指標B為歷史至今銷售事業部在職員工人數，A/B即可以統計最近一年銷售事業部人均銷售金額。

• 應用指標：通常指從客戶處調研得到，滿足業務需要，最終要形成報表的指標，一般來源於派生指標或者複合指標。

命名規範

• 公共規則

  • 所有單詞⼩寫
  • 單詞之間下劃線分割 (反例：appName 或 AppName)
  • 可讀性優於長度 (詞根，避免出現同⼀個指標，命名⼀致性)
  • 禁止使用 sql 關鍵字，如欄位名與關鍵字衝突時 +col
  • 數量欄位字尾 _cnt 等標識...
  • ⾦額欄位字尾 _price 標識
  • 天分割區使⽤欄位 dt，格式統⼀ (yyyymmdd 或 yyyy-mm-dd)
  • ⼩時分割區使⽤欄位 hh，範圍 (00-23)
  • 分鐘分割區使⽤欄位 mi，範圍 (00-59)
  • 布林型別標識：is_{業務}，不允許出現空值

• 指標命名規範:結合指標的特性以及詞根管理規範，將指標進⾏結構化處理。

  • 基礎指標詞根，即所有指標必須包含以下基礎詞根：
  • 業務修飾詞，用於描述業務場景的詞彙，例如 trade-交易。
  • 日期修飾詞，用於修飾業務發生的時間區間。
  • 聚合修飾詞，對結果進⾏聚集操作。
  • 基礎指標，單⼀的業務修飾詞+基礎指標詞根構建基礎指標，例如：交易⾦額 -trade_amt。
  • 派⽣指標，多修飾詞+基礎指標詞根構建派⽣指標。派⽣指標繼承基礎指標的特性，例如：安裝門店數量-install_poi_cnt。
  • 普通指標命名規範，與欄位命名規範⼀致，由詞彙轉換即可以。

• 基礎指標： 業務修飾詞+基礎指標詞 如 交易金額 trade_cost

• 派生指標： 多修飾詞+ 基礎指標詞 如 安裝門店數量 install_poi_cnt

• 日期型別指標： 業務修飾詞+基礎指標詞+日期修飾詞 如 七日交易額 trade_cost_7d

• 聚合型別指標：業務修飾+基礎指標詞+聚合修飾詞+日期修飾詞 如 七日平均交易額 trade_cost_avg_7d

• 本人部落格網站IT小神 www.itxiaoshen.com