1.概述
“由資料倉庫之父W.H.Inmon于1990年提出，主要功能乃是将組織透過資訊系統之線上交易處理(OLTP)經年累月所累積的大量資料，透過資料倉庫理論所特有的資料存儲架構，進行系統的分析整理，以利各種分析方法如線上分析處理(OLAP)、資料挖掘(Data Mining)之進行，并進而支援如決策支援系統(DSS)、主管資訊系統(EIS)之建立，幫助決策者能快速有效的自大量資料中，分析出有價值的資訊，以利決策拟定及快速回應外在環境變動，幫助建構商業智能(BI)。”上面這一段來維基百科對資料倉庫的定義說明。
興盛優選電商平台每天會産生大量的行為日志和業務交易資料（數TB級），面對如此龐大的資料量，常見的OLTP（聯機事務處理）類型的資料庫分析引擎已經無法應對不同業務部門對資料的統計、分析等諸多使用訴求，如何快速滿足集團内部不同業務團隊對資料的分析與應用成為亟需的解決問題。而資料分析與應用的前提是整理好企業内部不同資料源、梳理資料模型開發及資料品質保證。本篇文章介紹基礎數倉團隊是如何通過相關架構完成上述說的資料源內建、資料模型開發及資料品質等相關工作的。
2.數倉的基本建設目标
基礎數倉平台收集集團内各終端包含但不限于(使用者、門店、供應商、貨物、物流等)等業務資料、行為日志資料，通過四個一的标準("統一清洗"、"統一命名"、"統一度量","統一規範")其标準包含（資料類型轉換、命名規則、異常資料修正補齊、資料歸一化等)的加工處理，形成多種次元、層次、及不同時效的資料主題域，最終滿足集團各部門便利（找得到（有名額，名額随時都有數可查）、資料正确（數倉當中的資料和業務庫當中的要能保持一緻）、簡單的SQL就能查詢（能不使用join等算子就能查詢的就盡量不使用join））的使用想要的資料名額。
3.業界數倉建設分析
資料倉庫的概念确立之後，有關資料倉庫的實施方法、實施路徑和架構等問題引發了諸多争議。1994年前後，實施資料倉庫的公司大都以失敗告終，導緻資料集市的概念被提出并大範圍運用，其代表人物是Ralph Kimball。由于資料集市僅僅是資料倉庫的某一部分，實施難度大大降低，并且能夠滿足公司内部部分業務部門的迫切需求，在初期獲得了較大成功。但随着資料集市的不斷增多，這種架構的缺陷也逐漸顯現。公司内部獨立建設的資料集市由于遵循不同的标準和建設原則，以緻多個資料集市的資料混亂和不一緻。解決問題的方法隻能是回歸到資料倉庫最初的基本建設原則上來。
3.1 數倉理論發展
（1）萌芽階段。資料倉庫概念最早可追溯到20世紀70年代，MIT的研究員緻力于研究一種優化的技術架構，該架構試圖将業務處理系統和分析系統分開，即将業務處理和分析處理分為不同層次，針對各自的特點采取不同的架構設計原則，MIT的研究員認為這兩種資訊處理的方式具有顯著差别，以至于必須采取完全不同的架構和設計方法。但受限于當時的資訊處理能力，這個研究僅僅停留在理論層面。
（2）探索階段。20世紀80年代中後期，DEC公司結合MIT的研究結論，建立了TA2（Technical Architecture2）規範，該規範定義了分析系統的四個組成部分：資料擷取、資料通路、目錄和使用者服務。這是系統架構的一次重大轉變，第一次明确提出分析系統架構并将其運用于實踐。
（3）雛形階段。1988年，為解決全企業內建問題，IBM公司第一次提出了資訊倉庫（InformationWarehouse）的概念，并稱之為VITAL規範（VirtuallyIntegrated Technical Architecture Lifecycle）。VITAL定義了85種資訊倉庫元件，包括PC、圖形化界面、面向對象的元件以及區域網路等。至此，資料倉庫的基本原理、技術架構以及分析系統的主要原則都已确定，資料倉庫初具雛形。
（4）确立階段。1991年Bill Inmon出版了他的第一本關于資料倉庫的書《Building the Data Warehouse》，标志着資料倉庫概念的确立。該書指出，資料倉庫(DataWarehouse)是一個面向主題的(Subject Oriented)、內建的(Integrated)、相對穩定的(Non-Volatile)、反映曆史變化的(Time Variant)資料集合，用于支援管理決策(Decision-Making Support)。該書還提供了建立資料倉庫的指導意見和基本原則。憑借着這本書，Bill Inmon被稱為資料倉庫之父。
3.2 數倉架構曆程
（1）傳統數倉架構
（2）Lamada數倉架構
Lambda架構可分解為三層，即Batch Layer,Real-Time(Speed) Layer和Serving Layer。
Batch Layer:存儲資料集，在資料集上預先計算查詢函數，并建構查詢所對應的View。Batch Layer可以很好的處理離線資料，但有很多場景資料是不斷實時生成且需要實時查詢處理，對于這情況，Speed Layer更為适合。
Speed Layer:Batch Layer處理的是全體資料集，而Speed Layer處理的是最近的增量資料流。Speed Layer為了效率，在接收到新的資料後會不斷更新Real-time View，而Batch Layer是根據全體離線資料集直接得到Batch View。
Serving Layer:Serving Layer用于合并Batch View和Real-time View中的結果資料集到最終資料集。
（3）Kappa資料架構
Kappa架構可以認為Lambda架構的簡化版（隻要移除lambda架構中的批處理部分即可）。
Kappa架構最大的問題是流式重新處理曆史的吞吐能力會低于批處理和曆史資料的回放。
3.3 常見網際網路數倉架構
3.3.1 美團數倉架構圖
（1）離線架構
（2）實時架構
實時架構總結：通過對基礎加工（清洗、過濾、合流、擴維、轉換、篩選等正常操作）的抽象形成基礎通用元件來産生對應的資料結果流，對于不同業務線需要相容的情況通過備援相關字段來滿足，實時資料隻不關心曆史資料備援的字段不會過多消耗記憶體，對于實時性要求非高的統計直接導入olap實時引擎，利用olap引擎自身的計算和查詢滿足快速撤回計算，即通過空間換時間。
3.3.2 有贊數倉架構圖
（1）基于lambda的架構
有贊的數倉架構是典型的lambda架構，實時數倉和離線數倉是兩條不同的線：離線數倉的計算引擎為hiveSQL和sparkSQL，實時數倉的計算引擎為flink。ODS和DW層的資料都存儲在HDFS當中，集市應用層的資料存儲在不同的引擎當中應對不同的使用場景。
4.興盛優選數倉架構&建設實踐
4.1 基于資料湖的Lambda架構
我們目前的業務還在快速的疊代，業務資料模型修改是比較常見的事情，是以kappa架構顯然不太合适，因為經常涉及曆史資料的重跑，同時我們目前的業務對于資料的實時性要求比較高，尤其一些場景還涉及到資料狀态的實時變更，這個需要Hudi等資料湖能力的支援。是以根據我們的業務，我們産出了如下示意圖的數倉架構：
從上面的架構圖可以看出，批量線我們主要基于Spark計算引擎，資料會存入到Hudi，基于的Hudi的原因是由于我們的一些業務會對較長時間寫入的資料進行修改，同時也可以提供準實時的資料建構訴求，批量線我們目前的可見性時延可以做到5分鐘左右。
實時線是基于Flink進行計算，資料會回寫到kafka，給到數倉的下一層做實時的計算，實時性的資料可見性時延可以做到秒級，同時我們也會将該部分資料同步到Hudi，存入Hudi的目的有兩個：
1、實時計算的資料表是可以給到後續的批量計算使用，起到共享資料，節省資源的作用。
2、同時Hudi的存儲是基于OBS的，是以存儲成本要遠低于kafka的存儲，kafka我們一般保留7天左右的資料，Hudi的資料我們保留的時間在1年以上，這部分資料還可以用作後續的模型疊代計算。
4.2 模型架構
數倉的模型架構按照目前業界通用的分層結構進行建設：貼源層(ODS)、公共明細層(DWD)、公共次元層(DIM)、公共彙總層(DWS)、公共應用層(ADS)。
| 層級 | 功能描述 |
| 貼源層(ODS) | 存放未經過處理的原始資料值資料倉庫系統，結構上與業務系統保持一緻，是資料倉庫的資料加工準備區域，資料原則上需要全量保留 |
| 公共明細層(DWD) | 以業務過程作為模組化驅動，基于每個具體的業務過程特點，建構最細粒度的明細層事實表。資料粒度一般保持和ODS層一樣，并且提供對應的資料品質保證。同時為了提高資料明細層的易用性，改成會采用一些次元退化的手法，将次元退化至事實表中，減少事實表和維表的關聯，甚至會和其他的事實表進行關聯，做成明細寬表，複用關聯計算，減少資料掃描。 |
| 公共次元層(DIM) | 次元是指觀察事物的角度，提供某一業務過程時間涉及用什麼過濾和分類的描述屬性，“誰、什麼時候、什麼地點、為什麼幹”等都屬于看事物的角度，次元表示是次元模組化的基礎和靈魂，基于次元模組化的理念思想，建立整個企業的一緻性次元，降低資料計算口徑和算法不統一的風險，比如“小王早上在小賣鋪花費5元錢購買了包子”，時間次元-早上，地點次元-小賣鋪，商品次元-包子，在次元層的建設過程中，會将觀察次元列舉出來，比如時間次元就是早上，而不是具體某個時間點。 |
| 公共彙總層(DWS) | 以分析的主題對象作為模組化驅動，基于上層的應用和産品的名額需求，建構公共粒度的彙總名額事實表，以寬表化手段實體化模型。建構命名規範、口徑一緻的統計名額，為上層提供公共名額，建立彙總寬表。 |
| 公共應用層(ADS) | 資料應用層，也叫DM（資料集市）或者APP層等，面向實際的資料需求，可以直接給業務人員使用，以DWD或者DWS的資料為基礎，組成各種統計報表。除此之外還有一些直接的表現形式，例如主題大寬表集市。 |
4.3 數倉建設實踐
4.3.1 資料接入
數倉的資料源主要為業務庫關系庫表資料、行為日志資料、業務加工結果集資料等。資料接入主要的目标是保持與業務庫表資料一緻性，其中最主要工作内容是如何解決在同步過中的資料同步、資料更新、schema變更及資料校驗等工作内容。
業務庫關系表資料主要由資料同步平台(binlog+canal+sparkstream)準實時攝取存儲到Hudi，通過Hudi特性Upsert模式保證資料的增量更新、動态對比shema表結構及時更新結構。
行為日志資料資料具有Append特性，我們選擇由(flink的filesystem連接配接器)提供秒到分鐘級存儲性能、通過提供的檔案滾動政策、檔案compation模式如(checkpoint周期内)、分區送出可見性配置，解決實時計算存儲端的大量小檔案、緩解中繼資料加載、過濾目标資訊等高負載問題。
業務加工結果集資料的由排程平台封裝好高性能同步算子直接同步至數倉，可視化填寫源端資料源、庫、表和目标端的資料源、庫、表，字段映射即可。
目前資料源表已接入近800多張表資料且穩定運作中。
4.3.2 資料标準
據中國通信院的定義：資料标準，是指保障資料的内外部使用與交換的一緻性和準确性的規範性限制。資料标準目标就是為資料共享、語義清晰、易了解使用提供标準規範支撐。
那麼數倉團隊在這方面有哪些建設呢？
1、梳理業務标準規範；如：業務功能矩陣圖、名詞字典、模組化規範。
2、梳理技術标準規範；如：統一實時與離線表名格式、資料類型定義、編碼規則。
4.3.3 資料模型
如何建設資料模型是數倉團隊成員每個人都需要每天面對的事情。一個覆寫業務廣、重複使用率高、資料品質可靠、易了解、查詢效率快的企業級資料模型建設需要哪些前置工作支撐呢？
1、業務分析
2、業務資料梳理
3、梳理業務過程
4、建設資料模型（業務過程基本機關）
目前常見的模組化方式：”實體模組化”、”次元模組化”，實體模組化主要是用于OATP資料庫模組化、根據業表之間關系按一定外鍵關聯整合起來，偏重資料整合處理，次元模組化是面向分析場景建構，建構以資料主題域、備援相關次元為機關的模型表快速、靈活的支援資料營運分析需求。
5、ETL加工
4.3.4 資料品質
經過前面的資料模型建設、形成了一批基礎核心資料資産表，資料品質是指保證這些核心資料的可用性、可靠性、及時性。
資料品質檢測手段主要包括“一緻性”、“完整性”、“完整性”、“規範性”、“及時性”、“唯一性”、“準确性”六個方面。
| 次元 | 描述 | 案例 |
| 完整性 | 資料資訊是否存在缺失的狀況，資料缺失的情況可能是整個資料記錄缺失，也可能是資料中某個字段資訊的記錄缺失 | 訂單相關次元資訊如(門店、商品、限量資訊)是否為空值檢測 |
| 規範性 | 資料遵循預定的文法規則的程度，是否符合其定義，比如資料的類型、格式、取值範圍等 | 訂單類型枚舉值範圍檢測 |
| 一緻性 | 遵循了統一的規範，資料集合是否保持了統一的格式 | 金額數值是否按分值格式檢測 |
| 準确性 | 資料記錄的資訊是否存在異常或錯誤 | 訂單狀态值、支付時間值為空檢測售後 |
| 唯一性 | 資料不存在重複的情形 | 訂單主鍵唯一性重複檢測 |
| 及時性 | 資料從産生到可以檢視的時間間隔 | 訂單實時資料延遲監控 |
目前資料品質規則運作配置有以清單：
1、綁定任務節點-同步串行執行，資料任務計算完成後立即運作校驗規則。
2、與任務執行時間錯開-異步定時執行，規則時間觸發器到點執行。
3、任務運作狀态檢測，定時檢測任務狀态發送消息、電話告警。
品質校驗規則目前在核心業務表的覆寫率達到100%，其它各分層表的規則覆寫率還比較低，後續會逐漸配置對的監控規則資料，保證所有業務目标表資料能穩定輸出。
4.3.5 資料服務
數倉建設之後，需要通過資料服務為客戶提供資料資産的使用管道，資料服務是連接配接一線業務的使用視窗。資料服務方式根據業務用着群體提供不同的服務方式。常見的：即席查詢、資料同步、資料接口、資料報表，目前數倉平台除資料接口外支援以上所有方式。
DataStudio的資料服務-即席查詢：
DataStudio的資料服務-資料同步：
靈犀BI的資料報表-資料報表：
5.總結
目前興盛優選的基礎數倉遵循了業界标準的數倉分層模型來建構，但是在基礎的架構上更多的結合了興盛優選的業務形态建構了Flink++Spark+Hudi這樣一種架構，廣泛的使用了資料湖的功能，這在業界來說是一種比較大的探索和嘗試。基于Flink計算引擎實時線的資料可以支撐秒級可見性延時，基于Spark批量線的結合Hudi可以達到5-10分鐘的可見性延遲，數倉團隊會根據業務的實際情況将數倉的開發配置到不同的線進行開發以滿足不同的業務需求。
目前數倉實作了0到1的建設，數倉的資料品質和使用得到了初步的建設和推廣，後續數倉會繼續聚焦在可用性（配合資料分析同學梳理常見電商的分析場景，支援多元度下鑽分析）、穩定性和準确性（數倉當中的資料能夠按時産出并且和業務庫當中的要能保持一緻）、便利性（不斷豐富多場景的寬表，能不使用join等複雜算子的就盡量不使用進行快速查詢）這三個方向進行深耕。
作者:興盛優選技術社群
出處:https://zhuanlan.zhihu.com/p/586826059