轉自：https://www.sohu.com/a/396680882_411876?scm=1002.44003c.17c024f.PC_ARTICLE_REC
作者：顏博，馬蜂窩數倉研發總監
1、數據處理架構
下面是一個簡單的數據處理架構演進過程：
最早數據倉庫的計算只支持批處理，通常是按天定時處理數據，在後期逐步進化到準實時，本質上還是批處理，只是處理頻度上得有提升，到小時級，或者15分鐘這種。
隨着技術不斷進步，後期演化出一條新的流處理鏈路，這個鏈路和之前的批處理分別處理，然後在服務層面利用大數據的計算能力進行合併，向外提供離線+實時數據服務，這也是著名的lambda架構。
最近幾年隨着Flink等技術的發展，有一個趨勢是流批一體化，在接入層統一採用流式接入，計算層採用統一套框架支持實時計算+離線計算，批處理僅僅作爲流處理的一個特殊場景進行支持。整體上可以做到流處理、批處理的自由切換。
流計算和批處理在需求場景上有一些本質區別，前者主要用於支持線上業務場景（比如互聯網的推薦、搜索、風控等），而批處理更多是支持離線統計分析。
日出而作，日落而息，大家針對大數據的統計分析習慣不會發生根本性變化，最簡單的T+1批處理方式也還是數據應用必不可少的環節。在使用同一套架構上，由於數據源變化&維度變化的多樣性，批處理往往面臨一些複雜場景，這是採用同一套框架上的一些難點，充分支持好批處理也是將來流批一體框架的發展方向。
2、數倉分層與主題分類
1）數倉分層
與傳統ETL不同的，我們採用的是ELT的數據架構，較爲適合在互聯網，總體分爲業務數據層、公共數據層、應用數據層三大層次。
① 業務數據層（ODS層）
原始數據經過緩衝層（STG）的加載，會進入數倉的業務數據層，這一層採用範式建模，基本保持與數據源完全一致的結構，對於變化的數據，使用數據拉鍊加工與存儲。
這一層選用範式建模，是指保持源系統（例如關係數據庫）的範式結構，好處主要是：
一次性接入數據源結構，針對需求的變動不用頻繁去與數據源對接；
便於業務研發更好地理解數據，同時是也是公司的原始數據資產。
針對變化數據採用數據拉鍊的好處：
保留歷史數據的同時，儘可能少佔用存儲空間，長期來看，拉鍊存儲比起每天全量保留歷史節約大概90%空間；
快速、高效地獲取歷史任意一天業務系統的快照數據。
② 公共數據層（包括公共明細層DWD，公共彙總層DWS）
公共數據層是數據倉庫的核心層，是整個數倉中使用率最高的，這一層主要採用的維度建模思路進行設計，類型包括事務事實、週期快照、累積快照。同時爲了方便下游對數據的使用，我們會設計一系列的寬表模型，將不同業務過程中的事實進行統一整合，包括縱向整合&橫向整合；對於商品、用戶主數據類可能分散在不同的源系統中採用縱向整合；橫向整合主要包括交易、內容等行爲數據不同業務過程的整合，比如：用戶（用戶信息、註冊信息）購買（下單、支付、結算、覆約、完成）商品（商品信息，商家信息，等），我們會把訂單流轉業務過程整合放到一張明細表裏，同時會研發一些基於用戶、或者商品視角的輕度彙總寬表。
寬表非常便於理解和易用，下游應用調用也方便。我們之前也做過一些統計，在調用分佈來看，寬表的使用佔到70%以上。
雖然寬表的使用在數倉建模中非常普遍，但是也有一些缺陷：
數據冗餘較多，在存儲、計算、調用較爲佔資源，建議儘量還是按場景去使用；
寬表整合的信息較多，數據權限不好控制。建議可以根據需求，在有限範圍內開放整體寬表權限，或者通過視圖或者子表的方式建立不同權限的數據範圍，適應不同組織的需求；
寬表通常依賴比較多，會影響數據的產出的時效。
③ 應用數據層（DWA層）
顧名思義，就是偏向應用的數據加工，也可以叫集市層，這一層的設計可以相對靈活，貼近應用即可，總體設計思想仍然可以按維度建模思想爲主。
2）主題分類
數倉架構的數據分類兩個視角，包括主題視角與業務視角。
① 數據主題視角
最重要的一個視角，也就是咱們經常提到的數倉主題，主題是將企業的業務進行宏觀數據抽象，是數據倉庫裏數據的主要組織形式，劃分方法如下：
參照波特價值鏈，分析企業本身經營的業務（基本活動、支持型活動），分別對應哪些數據；
參照業界通用模型，例如像IBM、TD等針對大型行業（如電信、金融、零售）有一些數據主題的通用劃分方法；
對企業的內部數據（線上數據模塊、數據字典）進行摸底，確認對應到哪些主題。
劃分結果會按照三個層級：主題域-->主題-->子主題。
第一級是主題域，針對相對穩定的主題進行合併，歸攏到主題域，利於數據的理解與建立全局的數據資產目錄；
第二級是主題；
第三級是子主題，主要針對有些主題下分類較多，比如供應鏈主題下會包含採購、倉儲、配送等子主題。
數據主題劃分建議完全互斥，不建議重複。
② 數據業務視角
數據業務域是根據企業經營的具體業務，結合企業的組織架構進行劃分，層次和分類可以相對靈活，子分類可以允許重複，因爲兩條不同的業務域可能經營相同的業務，例如電商、內容下都有會員這個業務。
上圖是一個比較典型的內容+電商的數據主題與業務分類。
以上一橫一縱兩個視角，將數據進行更好的歸類，在數據模型設計中會打上相應分類標籤，從而讓數據研發&數據使用人員統一認知。以上兩種分類方式主要應用於核心的公共數據層。
業務數據層、應用數據層並不需要遵循以上分類規則，比如業務數據層（ODS層）是按照數據源進行分類，應用數據層（DWA）是根據具體的應用進行分類。
3、數據研發流程
除了合理的架構之外，數據研發的流程也很重要，總體流程如下：
包括需求分析/數據調研、數據模型設計、數據開發&測試、上線發佈等流程。
在之前數據中臺的核心架構提到不閉門造車，數據研發需要與業務部門充分銜接，比如在數據調研中要與業務研發同學進行線上數據&結構訪談；在數據開發中，與分析&業務同學共同確認標準口徑；在數據研發完成後對數據使用方進行數據發佈與培訓。
以上流程中，除了需求調研，其他部分我們都進行了線上化，包括數據的模型設計，早期我們會手寫mapping文檔，後期我們逐步把mapping文檔進行了線上化，整體的數據模型設計通過模型設計工具完成，包括從概念模型、邏輯模型到物理模型的設計。模型設計完成後，可以一鍵生成數據知識文檔。
4、數據生命週期管理
數據研發完成，還需要關注數據生命週期，一方面數據量的飛速增長不僅僅需要佔用大量存儲，比如像自建機房，會涉及擴充機櫃、機房，往往會面臨一些瓶頸；另外一方面，大量的數據會降低數據的計算效率，所以從數據的生成開始，我們就需要考慮生命週期，並且結合數據的使用情況制定數據歸檔、數據銷燬等管理策略。
針對數據已經佔用了大量存儲資源，可以採取一系列措施進行成本控制，例如：
降存量：通過數據壓縮技術、降副本等方式，以及在數據模型更合理的設計，將存量數據存儲降低；
控增量：根據數據重要性，可恢復性等考量角度，確認數據的保留週期，並根據週期自動歸檔或刪除；
攤成本：可以通過一些算法，比如數據調用分佈、需求來源等，把成本分攤到相應業務部門，讓相關業務部門關注到成本。
數據安全也是數據生命週期管理重的一個重要課題，比如針對用戶敏感信息，需要在接入時考慮如何加密。一種做法是通過一個獨立的物理集羣對敏感數據進行隔離與強管控；數據使用中，也需要將數據劃分不同的安全或敏感等級（例如有些財務數據的非常敏感，需要謹慎對外開放），根據不同的等級設定不同的訪問審批機制。另外，在數據歸檔、銷燬也需要制定好配套的安全管理措施，避免安全風險。
5、數據質量管理
數據質量管理主要包括3個角度：準確性、及時性、一致性。
管理的環節包括：事前、事中、事後、以及事故管理。
針對數據運維的告警發送，傳統的方式主要是短信、郵件、電話；隨着移動辦公工具功能逐步的強大，可以將運維告警以數據接口的方式與這些工具進行對接，將告警發送到企業內部的即時通訊工具。
6、數據應用架構
數據研發最終還是需要賦能到業務&應用，一個合理的數據應用架構是非常關鍵的，這張圖是一個應用架構的簡圖參考：
從數據的流向上分：
數據倉庫（或者數據湖）：負責原始數據的計算，主要將數據落地到HDFS；
數據引擎層：數據加工完成之後，會將數據推送到不同的引擎中，這一層之前提到選擇非常多，可以根據自己的場景選擇一個混搭組合，比如我們目前選擇的有Presto，Kylin，Druid，Mysql；
數據服務層：通過統一化的SQL調用服務，屏蔽底層不同的數據引擎，爲上層統一查詢提供標準接口；
指標平臺：指標平臺是一個非常關鍵的產品，定位於銜接數據研發與數據應用，包括指標的標準定義、邏輯、計算方式、分類等各項內容。指標分類上我們分爲標準指標(指標口徑經過審覈過)、以及非標準指標；
多維查詢：這是我們的一個即席查詢工具，查詢的數據主要來源指標平臺，可以選定不同的指標維度組合進行結果呈現，用戶可以一次性查詢得到結果，也可以將查詢結果配置成可視化的報表進行固化。
中間是統一元數據管理：對整個架構中可以對外提供服務的元數據進行統一管理（包括數倉的元數據、查詢引擎的元數據、指標元數據等），以及監控這些元數據的調用情況。
最右側是權限管理：權限管理關乎到數據安全，在設計上需要考慮周全，比如針對表級、指標級、維度級別都可以進行控制；同時產品層面也需要靈活配置權限審批級別與人員。
在面向用戶使用層面，我們主要開放的是多維查詢&可視化，用戶通過多維去查詢各類指標&維度數據，得到數據結果列表，再選擇可視化配置面板，完成各類圖表、表格的自主配置，併發布到個人看板或者業務大盤目錄裏。也可以將配置的數據看板進行靈活組合，定製成一個小型的數據產品。
7、數據ROI評估
在數據研發中，也要考量數據的ROI，下面是一個簡單的ROI模型：
根據活躍度（調用次數等）、覆蓋度（通過血緣關係找出依賴數量），以及貢獻度（依賴數據的重要等級）來確認數據的價值。同時會評估數據的成本指數（例如計算成本、存儲成本等）。
通過以上兩者相除，綜合得到數據的ROI，針對ROI可以將數據分爲不同等級，並相應進行數據治理。比如針對價值低，成本高的數據，可以考慮下線等。
數據研發趨勢&關注點
提效：目前藉助工具的研發可以把絕大部分數據研發工作線上化，將來藉助AI等能力，實現數據處理中包括開發、運維的自動化，提升處理效率；
靈活：流批一體化，包括流處理與批處理自由切換，之前已經提到過，個人認爲也是一個發展的趨勢；
降本：數據研發鏈路的成本控制，在數據建設的早期通常不太引起關注，隨着數據量不斷的積累，往往存儲、計算成本成爲瓶頸。針對數據建設成本需提前考慮；
算力：我們看到Google，IBM和阿里都在研究量子計算，將來的數據中間層（比如數倉的公共模型）是否可以考慮虛擬化（比如只保留規則&數據結構），具體數據內容在應用發起時，即調即用，更多時候可以不需要佔用存儲資源。算力的不斷提升，有可能會顛覆一些傳統數據建設的思路。