大數據學習筆記1：數倉、數據湖、數據中臺

本文首發於 泊浮目的簡書: https://www.jianshu.com/u/204...

版本	日期	備註
1.0	2021.5.9	文章首發

這是個人學習筆記，大量摘抄網上、書本里的內容，將我本身認爲關聯度較高的內容呈現上來。

1.數據倉庫

商業智能（Business Intelligence）誕生在上個世紀 90 年代，它是將企業已有的數據轉化爲知識，幫助企業作出經營分析決策。

好比在零售行業的門店管理中，如何使得單個門店的利潤最大化，咱們就須要分析每一個商品的銷售數據和庫存信息，爲每一個商品制定合理的銷售採購計劃，有的商品存在滯銷，應該降價促銷，有的商品比較暢銷，須要根據對將來銷售數據的預測，進行提早採購，這些都離不開大量的數據分析。

而數據分析須要聚合多個業務系統的數據，好比須要集成交易系統的數據，須要集成倉儲系統的數據等等，同時須要保存歷史數據，進行大數據量的範圍查詢。傳統數據庫面向單一業務系統，主要實現的是面向事務的增刪改查，已經不能知足數據分析的場景，這促使數據倉庫概念的出現。

舉個電商的例子，在電商場景中，有一個數據庫專門存放訂單的數據，另一個數據庫存放會員相關的數據。構建數據倉庫，首先要把不一樣業務系統的數據同步到一個統一的數據倉庫中，而後按照主題域方式組織數據。

主題域是業務過程的一個高層次的抽象，像商品、交易、用戶、流量都能做爲一個主題域，你能夠把它理解爲數據倉庫的一個目錄。數據倉庫中的數據通常是按照時間進行分區存放，通常會保留 5 年以上，每一個時間分區內的數據都是追加寫的方式，對於某條記錄是不可更新的。

2. 數據湖

進入互聯網時代，有兩個最重要的變化。

• 一個是數據規模史無前例，一個成功的互聯網產品日活能夠過億，就像你熟知的頭條、抖音、快手、網易雲音樂，天天產生幾千億的用戶行爲。傳統數據倉庫難於擴展，根本沒法承載如此規模的海量數據。
• 另外一個是數據類型變得異構化，互聯網時代的數據除了來自業務數據庫的結構化數據，還有來自 App、Web 的前端埋點數據，或者業務服務器的後端埋點日誌，這些數據通常都是半結構化，甚至無結構的。傳統數據倉庫對數據模型有嚴格的要求，在數據導入到數據倉庫前，數據模型就必須事先定義好，數據必須按照模型設計存儲。

因此，數據規模和數據類型的限制，致使傳統數據倉庫沒法支撐互聯網時代的商業智能。

05年的時候，Hadoop誕生了。 Hadoop 相比傳統數據倉庫主要有兩個優點：

• 徹底分佈式，易於擴展，可使用價格低廉的機器堆出一個計算、存儲能力很強的集羣，知足海量數據的處理要求；
• 弱化數據格式，數據被集成到 Hadoop 以後，能夠不保留任何數據格式，數據模型與數據存儲分離，數據在被使用的時候，能夠按照不一樣的模型讀取，知足異構數據靈活分析的需求。

隨着Hadoop的成熟，數據湖的概念在10年被提出：數據湖（Data Lake）是一個以原始格式存儲數據的存儲庫或系統。

3. 大數據平臺

對於一個數據開發，在完成一項需求時，常見的一個流程是首先要把數據導入到大數據平臺中，而後按照需求進行數據開發。開發完成之後要進行數據驗證比對，確認是否符合預期。接下來是把數據發佈上線，提交調度。最後是平常的任務運維，確保任務每日可以正常產出數據。

這時，業界提出大數據平臺的概念，就是爲了提升數據研發的效率，下降數據研發的門檻，讓數據可以在一個設備流水線上快速地完成加工。

4.數據中臺

大規模數據的應用，也逐漸暴露出現一些問題。

業務發展前期，爲了快速實現業務的需求，煙囪式的開發致使企業不一樣業務線，甚至相同業務線的不一樣應用之間，數據都是割裂的。兩個數據應用的相同指標，展現的結果不一致，致使運營對數據的信任度降低。若是你是運營，當你想看一下商品的銷售額，發現兩個報表上，都叫銷售額的指標出現了兩個值，你的感覺如何? 你第一反應確定是數據算錯了，你不敢繼續使用這個數據了。

數據割裂的另一個問題，就是大量的重複計算、開發，致使的研發效率的浪費，計算、存儲資源的浪費，大數據的應用成本愈來愈高。

• 若是你是運營，當你想要一個數據的時候，開發告訴你至少須要一週，你確定想是否是太慢了，能不能再快一點兒？
• 若是你是數據開發，當面對大量的需求的時候，你確定是在抱怨，需求太多，人太少，活幹不完。
• 若是你是一個企業的老闆，當你看到每月的帳單成指數級增加的時候，你確定以爲這也太貴了，能不能再省一點，要不吃不消了。

這些問題的根源在於，數據沒法共享。2016 年，阿里巴巴率先提出了「數據中臺」的口號。數據中臺的核心，是避免數據的重複計算，經過數據服務化，提升數據的共享能力，賦能數據應用。以前，數據是要啥沒啥，中間數據難於共享，沒法積累。如今建設數據中臺以後，要啥有啥，數據應用的研發速度再也不受限於數據開發的速度，一晚上之間，咱們就能夠根據場景，孵化出不少數據應用，這些應用讓數據產生價值。

4.1 數據中臺樣板

在建設中臺的過程當中，通常強調這樣幾個重點：

• 效率、質量和成本是決定數據可否支撐好業務的關鍵，構建數據中臺的目標就是要實現高效率、高質量、低成本。
• 數據只加工一次是建設數據中臺的核心，本質上是要實現公共計算邏輯的下沉和複用。
• 若是你的企業擁有 3 個以上的數據應用場景，數據產品還在不斷研發和更新，你必需要認真考慮建設數據中臺。

那麼接下來就看一下阿里巴巴對於數據中臺的實踐。

正如上述提到的數據只加工一次是建設數據中臺的核心，本質上是要實現公共計算邏輯的下沉和複用。阿里數據中臺提到了各類one思想，如：

• OneData：公共數據只保存一份
• OneService：經過一個服務接口進行暴露

4.1.2 數據服務

數據服務主旨是爲了將數據暴露出去，若是沒有數據服務，則是直接將數據導給對方，這樣很低效，也不安全。

在長期的實踐中，阿里分別經歷了四個階段：

1. DWSOA
2. OpenAPI
3. SmartDQ
4. OneService

4.1.2.1 DWSOA

很是的簡單粗暴，就是將業務方對數據的需求經過 SOA 服務的方式暴露出去。由需求驅動，一個需求開發一個或者幾個接口，編寫接口文檔，開放給業務方調用。

業務需求當然很重要，可是若是不以技術端作了一個抓手，長期來看維護成本會極高——街口多，複用率低；且一個接口從需求開發到測試上線，整個流程走完至少也要一天，但有時需求僅僅是增長1、兩個字段屬性，也要走一套流程，效率較低。

4.1.2.2 OpenAPI

DWSOA階段存在的明顯問題,就是煙囪式開發，致使接口衆多很差維護，所以須要想辦法下降接口的數量。當時阿里內部對這些需求作了調研分析，發現實現邏輯基本上就是從DB取數，而後封裝結果暴露服務，而且不少接口實際上是能夠合併的。

OpenAPI就是數據服務的第二個階段。具體的作法就是將數據按照其統計粒度進行聚合，一樣維度的數據，造成一張邏輯表，採用一樣的接口描述。以會員維度爲例：把全部以會員爲中心的數據作成一張邏輯寬表，只要是查詢會員粒度的數據。僅須要調用會員接口便可。經過段時間的實施,結果代表這種方式有效地收斂了接口數量。

4.1.2.3 SmartDO

然而，數據的維度並無開發們想象的那麼可控， 隨着時間的推移，你們對數據的深度使用，分析數據的維度也愈來愈多，當時OpenAPI生產已有近 100 個接口：同時也帶來大量對象關係映射的維護工做量。

因而阿里的同窗給予OpenAPI上，又加了一層類SQL的DSL。將全部的簡單查詢服務都變成了一個接口。至此，全部的簡單 查詢服務減小到只有一 個接口 ，這大大下降 了數據服務的維護成本。傳統的方式查問題須要翻源碼，確認邏輯：而SmartDQ只須要檢查 SQL 的工做量，而且能夠開放給業務方經過寫 SQL 的方式對外提供服務，由服務提供者本身來維護SQL ，也算是服務走向 DevOps的 一 個里程碑吧 。

邏輯表雖然在 OpenAPI 階段就已經存在，可是在 SmartDQ階段講更合適，由於 SmartDQ 把邏輯表的 做用真正發揮出來了。SQL 提供者只 需關心邏輯 表 的結構，不須要關心底層由多少物理表 組成，甚至不須要 關心這些物 理表是 HBase 仍是 MySQL 的，是單表還 是分庫分表，由於 SmartDQ 已經封裝了跨異構數據源和分佈式查詢功能。此外，數據部門字段的變動相對比較頻繁 ，這種底層變動對應用層來講應該算是最糟糕的變動之一了 。而邏輯表層的設計很好地規避了這個痛點，只變動邏輯表中物理字段的映射關係，而且即刻生效，對調用方來講徹底無感知。

接口易上難下，即便一個接口也會綁定一批人（業務方、接口開發維護人員、調用方）。因此對外提 供的數據服務接口必定要儘可 能抽象，接口的數量要儘量收斂，最後在保障服務質量的狀況下，儘量減小維 護工做量。如今SmartDQ 提供 300多個 SQL 模板每條 SQL 承擔多個接口的需求，而咱們只用1位同窗來維護SmartDQ 。

4.1.2.4 OneService

第四階段是統一的數據服務層（即 OneService ）。

你們內心可能會有疑問：SQL並不能解決複雜的業 務邏輯啊。確實SmartDQ 其實只知足了簡單的查 詢服務需求。咱們遇到的場景還有這麼幾類：個性 化 的垂直業務場景、 實時數據推送服務 、定時任務服務。 因此OneService主要是提供多種服務 類型來知足用戶需求，分別是 OneService-SmartDQ OneService-Lego、OneService-iPush、OneService-uTiming 。

1. OneService-SmartDQ：知足了簡單的查詢服務需求。
2. OneService-Lego：插件化方式，一類需求開發一個插件，並作成微服務，使用 Docker 作隔離，避免插件之間相互影響。
3. OneService-iPush：提供 Web Socket和long polling 兩種方式，其應用場景主要是商家端實時直播。
4. OneService-uTiming：提供即時任務和定時任務兩種模式，其主要應用場景是知足用戶運行大數據量任務的需求。

技術細節

SmartDO

SmartDQ的元數據模型， 簡單來講， 就是邏輯表到物理表的映射。自底向上分別是：

1. 數據源：SmartDQ支持跨數據源查詢，底層支持接入多種數據源，好比MySQL、HBase、OpenSearch等。
2. 物理表：物理表是具體某個數據源中的一張表。每張物理表都須要指明主鍵由哪些列組成，主鍵肯定後便可得知該表的統計粒度。
3. 邏輯表：邏輯表能夠理解爲數據庫中的視圖，是一張虛擬表，也能夠看做是由若干主鍵相同的物理表構成的大寬表。SmartDQ對用戶展示的只是邏輯表，從而屏蔽了底層物理表的存儲細節。
4. 主題：邏輯表通常會掛載在某個主題下，以便進行管理與查找。

1. 查詢數據庫
   SmartDQ 底層支持多 種數據源， 數據的來源主要有兩種：
2. 實時公 共層的計算做業直接將計算結果寫人 HBase
3. 經過同步做業將公共層 的離線數據同步到對應的查詢庫
4. 服務層
5. 元數據配置。 數據發佈者須要到元數據中心進行元數據配置， 建 立好物理表與邏輯表的映射關係， 服務層會將元數據加載到本地 緩存中， 以便進行後續的模型解析。

6. 主處理模塊。 一 次查詢從開始到結果返回， 通常會通過以下幾步：

   • DSL 解析：對用戶的查詢 DSL 進行語法解析， 構建完整的查 詢樹。
   • 邏輯 Query 構建：遍歷查詢樹， 經過查找元數據模型， 轉變爲邏輯 Query 。
   • 物理 Query 構建：經過查找元數據模型中的邏輯表與物理表 的映射關係， 將邏輯 Query 轉變爲物理 Query 。
   • Query 拆分：若是該次查詢涉及多張物理表， 而且在該查詢場景下容許拆分， 則將 Query 拆分爲多個 SubQuery 。
   • SQL 執行：將拆分後的 的 DB 執行。SubQuery 組裝成 SQL 語句，交給對應。
   • 結果合併：將DB 執行的返回結果進行合併，返回給調用者。

• 其餘模塊。除了一些必要的功能（好比日誌記錄、權限校驗等）， 服務層中的一些模塊是專門用於性能及穩定性方面的優化的。

IPush

Push應用產品是一個面向TT、MetaQ等不一樣消息源，經過定製過濾規則，向Web、無線等終端推送消息的中間件平臺。iPush核心服務器端基於高性能異步事件驅動模型的網絡通訊框架Netty 4實現，結合使用Guava緩存實現本地註冊信息的存儲，Filter與Server之間的通訊採用Thrift異步調用高效服務實現，消息基於Disruptor高性能的異步處理框架（能夠認爲是最快的消息框架）的消息隊列，在服務器運行中Zookeeper實時監控服務器狀態，以及經過Diamond做爲統一的控制觸發中心。

Lego

Lego被設計成一個面向中度和高度定製化數據查詢需求、支持插件機制的服務容器。它自己只提供日誌、服務註冊、Diamond配置監聽、鑑權、數據源管理等一系列基礎設施，具體的數據服務則由服務插件提供。基於Lego的插件框架能夠快速實現個性化需求併發布上線。

Lego採用輕量級的Node.JS技術棧實現，適合處理高併發、低延遲的IO密集型場景，目前主要支撐用戶識別發碼、用戶識別、用戶畫像、人羣透視和人羣圈選等在線服務。底層根據需求特色分別選用Tair、HBase、ADS存儲數據。

uTiming

uTiming是基於在雲端的任務調度應用，提供批量數據處理服務。uTiming-scheduler負責調度執行SQL或特定配置的離線任務，但並不直接對用戶暴露任務調度接口。用戶使用數據超市工具或Lego API創建任務。

4.1.3 數據管理

面對爆炸式增加的數據，如何建設高效的數據模型和體系，對這些 數據進行有序和有結構地分類組織和存儲，避免重複建設和數據不一致 性，保證數據的規範性， 一直是大數據系統建設不斷追求的方向。

OneData 便是阿里巴巴內部進行數據 整合及管理的方法體系和工具。阿里巴巴的大數據工程師在這一體系下，構建統一 、規範、可共享 的全域數據體系，避免數據的冗餘和重複建設，規避數據煙囪和不一致 性，充分發揮阿里巴巴在大數據海量、多樣性方面的獨特優點。藉助這 一統一化數據整合及管理的方法體系，阿里的同窗構建了阿里巴巴的數據公共 層，並能夠幫助類似的大數據項目快速落地實現。因爲篇幅緣由，下面重點介紹OneData的模型設計。

4.1.3.1 指導理論

阿里巴巴集團數據公共層設計理念遵循維度建模思想， 可參考Star Schema- The Complete Reference和The Dαtα Warehouse Toolkit-The Definitive Guide to Dimensional Modeling。數據模型的維度設計主要以維度建模理論爲基礎，基於維度數據模型總線架構，構建一致性的維度和事實。

4.1.3.2 模型層次

阿里巴巴的數據團隊把表數據模型分爲三層

• 操做數據層（ ODS ）
• 公共維度模型層（ CDM ）：包括明細數據層（ DWD ）和彙總數據層（ DWS ）
• 應用數據層（ ADS ）

操做數據層(ODS,Operational Data Store)：把操做系統數據幾乎無處理地存放在數據倉庫系統中。

• 同步：結構化數據增量或全量同步到 MaxCompute。
• 結構化：非結構化（日誌）結構化處理並存儲到 MaxCompte。
• 累積歷史、清洗：根據數據業務需求及稽覈和審計要求保存歷史數據、清洗數據。

公共維度模型層（CDM,Common Data Model）：存放明細事實數據、維表數據及公共指標彙總數據，其中明細事實數據、維表數據通常根據 ODS 層數據加工生成；公共指標彙總數據通常根 據維表數據和明細事實數據加工生成。

CDM 層又細分爲明細數據層（ DWD,Data Warehouse Detail）層和 彙總數據層（DWS,Data Warehouse Summary），採用維度模型方法做爲理論基 礎，更多地採用一些維度退化手法，將維度退化至事實表中，減小事實表和維表的關聯 ，提升明細數據表的易用性：同時在彙總數據層，增強指標的維度退化，採起更多的寬表化手段構建公共指標數據層，主要功能以下：

• 組合相關和類似數據：採用明細寬表，複用關聯計算，減小數據掃描。
• 公共指標統一加工：基於 OneData 體系構建命名規範、口徑一 致和算法統一 的統計指標，爲上層數據產品、應用和服務提供公共指標；創建邏輯彙總寬表。
• 創建一致性維度：創建一致的數據分析維表，下降數據計算口徑、算法不統一的風險。

應用數據層（ADS,Application Data Store）：存放數據產品個性化的 統計指標數據，根據CDM層與ODS層加工生成。

• 個性化指標加工：不公用型、複雜性（指數型、比值型、排名型指標）
• 基於應用的數據組長：大寬表集市、橫錶轉縱表、趨勢指標串。

數據調用服務優先使用公共維度模型層（CDM）數據，當公共層沒有數據時，需評估是否須要建立公共層數據，當不須要建設公用的公共層時，方可直接使用操做數據層（ODS）數據。應用數據層（ADS）做爲產品特有的個性化數據通常不對外提供數據服務，可是ADS做爲被服務方也須要遵照這個約定。

4.1.3.3 基本原則

1. 高內聚和低耦合：一個邏輯或者物理模型由哪些記錄和字段組成，應該遵循最基本的軟件設計方法的高內聚和低耦合原則。主要從數據業務特性和訪問特性兩個角度來考慮：將業務相近或者相關、粒度相同的數據設計爲一個邏輯或者物理模型；將高几率同時訪問的數據放一塊兒，將低機率同時訪問的數據分開儲存。
2. 核心模型與擴展模型分離：創建核心模型與擴展模型體系，核心模型包括的字段支持經常使用的核心業務，擴展模型包括的字段支持個性化或少許應用的須要，不能讓擴展模型的字段過分侵入核心模型，以避免破壞核心模型的架構間接性和可維護性。
3. 公共處理邏輯下沉及單一：越是底層公用的處理邏輯越應該在數據調度依賴的底層進行封裝與實現，不要讓公用的處理邏輯暴露給應用層實現，不要讓公共邏輯多處同時存在
4. 成本與性能平衡：適當的數據冗餘能夠換取查詢和刷新的性能，可是不宜過分的冗餘與數據複製。
5. 數據可回滾：處理邏輯不變的狀況下，在不一樣時間屢次運行數據，它的數據結果是肯定不變的。
6. 一致性：具備相同含義的字段，在不一樣表中的命名必須相同，必須使用規範定義中的名稱。
7. 命名清晰、可理解：表命名須要清晰，一直，代表易於消費者理解和使用。

5. 實時數倉

實時數倉和離線數倉很是的像，誕生的背景主要是近幾年企業對於數據服務的實時性需求日益增多。裏面的數據模型也會像中臺同樣分好幾層：ODS 、CDM、ADS。但總體對於實時性要求極高，所以通常存儲會考慮採用Kafka這種log base的MQ，而計算引擎會採用FLink、Storm這種流計算引擎。

6. 參考資料

• 《大數據之路：阿里巴巴大數據實踐》
• Data Lake vs Data Warehouse
• 美團基於 Flink 的實時數倉建設實踐