大数据架构详解_【数据如何驱动增长】（3）大数据背景下的数仓建设 amp; 数据分层架构设计...
背景
了解數據倉庫、數據流架構的搭建原理對于合格的數據分析師或者數據科學家來說是一項必不可少的能力。它不僅能夠幫助分析人員更高效的開展分析任務，幫助公司或者業務線搭建一套高效的數據處理架構，更是能夠從根本上提升公司的數據驅動能力
同時，對于很多數據方向的初學者來說，網上的資料大部分都是輔導如何使用excel、sql、python做分析，建模的，大部分情況下用來處理的數據已經是csv或者excel格式了。這就會讓很多人認為，數據分析的重點就是分析方法和寫報告，而忽略了數據生產及存儲這個非常重要的環節
在我學習時，發現網上關于大數據背景下的數倉建設相關的入門資料非常少，想要學習時只能去翻又厚又長的《數據倉庫》、《數據倉庫工具箱》，學習曲線非常陡峭，對于初學者很不友好。于是當時也被迫放棄了，但是后來在工作中又很巧的涉及到了這部分內容，沒辦法，只能一邊工作一邊硬著頭皮從頭學起
所以本篇就希望能夠通過最淺顯的總結和介紹，讓大家對于大數據背景下的數倉建設和數據分層產生一點點研究的興趣，同時幫助初級的數據人員把數倉建設這個環節補上，形成更完善的數據思維體系，以后工作中少走彎路
文章結構
一、數據分層處理流誕生背景
大數據時代數據的特點被總結為
- Volume (大量)
- Variety (多樣)
- Velocity（高速）
- Value （價值）
傳統的基于關系型數據庫的數倉建設在面對海量數據、結構化半結構化無結構化等多樣的數據格式、實時分析的需求時，逐漸變得無力應對。于是Hadoop、HIve、Spark、Storm、Flume、Sqoop等各種各樣的數據處理框架應運而生，同時出現了數據分層的概念
在選擇一個技術棧深耕前，我們需要先抬起頭來，看看整個大數據流處理架構大概是怎么樣的，不同的技術棧在其中分別扮演了什么樣的角色，起到了什么樣的作用，傳統的數倉建設知識在新的大數據架構下是否還能夠產生價值
二、Azure數據處理架構
數據處理流可以被抽象成5個步驟。從原始數據的獲取開始，在獲取到原始數據后進行ingestion，這里可以理解為基礎的處理和提取，接下來將處理好的數據錄入公司數據庫進行存儲。存儲好的數據便可以用來做數據處理和數據可視化等分析挖掘操作了
看個復雜點的，微軟數據平臺Azure面向企業級的數據流，其實拆分看也就五個步驟，只不過每個步驟下因為不同的業務需要有了更細致的操作處理
三、數據分層、大數據處理流程詳解
就著下面這個框架圖，我們來一步一步的看看，大數據背景下的數據從生產到最后聲稱報告產生業務價值，到底有哪些步驟
數據分層設計架構STP1. 數據源
數據的一生從讀取數據源開始，這里的數據源可能來源于埋點日志、流水日志、業務數據庫、爬取到的數據等等
不同數據來源的數據結構和字段名稱可能都是不一樣的，有的可能是csv格式，有的可能是Json格式，還有的可能是儲存成了html格式；同時這些數據還可能存在數據缺失、數據重復、單位不一致、口徑不一致等等問題。所以在用這些數據進行分析前，需要對其進行必要的處理
STP2. 數據源 ——> ETL
ETL就是對原數據進行抽取、轉換、加載
并不是所有數據源的數據都是我們需要的數據，全部存儲會浪費資源，所以第一步就是從各個數據源中抽取出需要的數據。轉換的過程則對應著數據清洗，處理缺失數據、處理重復數據、單位轉換、口徑對齊等操作。清洗完成后傳入數據庫進行存儲
STP3. ETL ——> ODS, 明細層
經過ETL處理的數據通常會直接存入ODS數據庫（Operational Data Store，操作數據存儲），ODS數據庫中的數據最接近原始數據，這里的數據屬于公司的公共數據資源
因為ODS層存儲的數據量非常大，而不同部門和業務線的實際分析需求可能只會用到其中1/100甚至1/1000的數據。如果不作處理直接使用，會浪費大量的計算資源。所以ODS層的數據需要進行維度建模，通過結構化的存儲，以空間換時間，降低后期數據取用的復雜度
- 表schema：一般按天創建分區，沒有時間概念的按具體業務選擇分區字段
- 庫與表命名：庫名 - ods, 表名 - ods_業務名
STP4. ODS ——> DWD, Data Warehouse Detail 或 DWB, Data Warehouse Basis
DWD層中的數據粒度和ODS層中的保持一致，而DWB層是對DWD層的生產數據進行輕度綜合和匯總統計（可以把復雜的清洗，處理包含，如根據PV日志生成的會話數據），這一層主要解決一些數據質量問題和數據的完整度問題
輕度綜合層與DWD的主要區別在于二者的應用領域不同
- DWD的數據來源于生產型系統，經過維度建模后根據不同的業務過程、事實、維度進行存儲沉淀
- DWB輕度匯總層則面向分析型應用進行細粒度的統計和沉淀，目的是降低數據量級和維度，方便快速分析。DWB是對ODS層中的用戶的行為做一個初步的匯總，抽象出來一些通用的維度：時間、id等，并根據這些維度做一些統計分析，比如用戶在每次登陸中的瀏覽時長，瀏覽頁面數量等。這里做一層輕度的匯總會讓計算更加的高效
DWD和DWS中的數據通常都是基于Kimball的維度建模理論來構建的，并通過一致性維度和數據總線來保證各個子主題的維度一致性
- 表schema：一般按天創建分區，沒有時間概念的按具體業務選擇分區字段
- 庫與表命名：庫名 - dwb, 表名 - dwb_任務名
STP5. DWD, DWB ——> DM, date market或DWS, data warehouse service
數據到這里被稱作數據集市或寬表，由輕度匯總層和明細層數據計算生成
儲存時一般按照業務劃分，如流量、訂單、用戶等，生成字段比較多的大寬表，用于提供后續的業務查詢，OLAP分析，數據分發等
在數據挖掘及算法建模任務時經常都會對數據有特定的格式需求或者特定的特征處理。通常在面對需要每天例行化計算的模型時，為了節省計算時間，在操作時會單獨為模型建立一個DM數據集市
- 表schema：一般按天創建分區，沒有時間概念的按具體業務選擇分區字段
- 庫與表命名：庫名 - dm, 表名 - dm_任務名
STP6. DM, DWS ——> APP (應用層)
本部分數據由明細層、輕度匯總層，數據集市層生成，一般要求數據主要來源于集市層
應用層的數據是根據業務需要，由前面三層數據統計而出的結果，可以直接提供查詢展現，或導入至Mysql中使用
四、ETL詳解
抽取extraction、轉換transformation、加載load
（1）抽取(Extract)
從數據來源提取指定數據，數據是需要指定的，不是所有的數據都要抽取過來， 某些源數據對于分析而言沒有價值，或者其可能產生的價值，遠低于儲存這些數據所需要的數據倉庫的實現和性能上的成本，就不會抽取了
（2）轉換(Transform)
將數據轉換為指定格式并進行數據清洗保證數據質量
數據轉換，如包括編碼轉換(m/f->男/女)，字段轉換(balance->bal)，度量單位的轉換(cm->m)，數據粒度的轉換。業務系統數據存儲非常明細的數據，而數據倉庫中數據是用分析的，不需要非常明細，會將業務系統數據按照數據倉庫粒度進行聚合
數據清洗，會對不完整數據，錯誤數據和重復數據等臟數據進行清洗
（3）加載(Load)
將轉換過后的數據加載到目標數據倉庫，加載可分為兩種：
ETL很可能是數據倉庫開發中最耗時最耗資源的一個環節，因為該環節要整理各大業務系統中雜亂無章的數據，并協調元數據上的差別，工作量很大，但也是構建數據倉庫的重要環節，對數據倉庫的后續環節影響比較大
五、維度建模詳解
維度建模的基本概念
維度建模(dimensional modeling)是專門用于分析型數據庫、數據倉庫、數據集市建模的方法。這里牽扯到兩個基本的名詞：維度，事實
1、維度
維度是維度建模的基礎和靈魂，在維度建模中，將度量成為事實，將環境描述為維度，維度是用于分析事實所需的多樣環境。例如，在分析交易過程中，可以通過買家、賣家、商品和時間等維度描述交易發生的環境
2、事實
事實表作為數據倉庫維度建模的核心，緊緊圍繞著業務過程來設計，通過獲取描述業務過程的度量來表達業務過程，包含了引用的維度和與業務過程有關的度量。事實表中一條記錄所表達的業務細節被稱之為粒度。通常粒度可以通過兩種方式來表述：一種是維度屬性組合所表示的細節程度；一種是所表示的具體業務含義
維度建模用到的專業術語
1、 數據域
指面向業務分析，將業務過程活動維度進行抽象的集合。其中，業務過程可以概括為一個個不可分割的行為事件，在業務過程里可以定義指標；維度是指度量的環境，如買家下單事件，買件是維度。為保障整個體系的生命力，數據域是需要抽象提煉并且長期維護更新的，但不輕易變動。在劃分數據域時，既要能涵蓋所有業務需求，又能在新業務進入時無影響的包含已有的數據還要擴展新的數據域
2、 業務過程
值企業活動事件，如下單、支付、退款都是業務過程。業務過程是一個不可分割的行為事件
3、 時間周期
用來名明確數據統計的時間周期或者時間點，如自然月、最近30天，自然周等
4、 修飾類型
是對抽象詞的一種抽象劃分。修飾類型從屬某個數據域，如日志域的訪問終端涵蓋無線端，PC端等修飾詞
5、 修飾詞
指除了統計維度以外指標的業務場景限定抽象。修飾詞隸屬于某一個修飾類型
6、 度量/原子指標
基于某一業務事件行為下的度量，是業務定義中不可在分割的指標，具有明確的業務含義名詞，如支付金額
7、維度
上述已經做了介紹，不必重述
8、 維度屬性
維度屬性隸屬于某一個維度，如地理維度里面的國家名稱，國建id，省份名稱等
9、 事實
上述已經做了介紹，不必重述
10、派生指標
派生指標=一個原子指標+多個修飾詞+時間周期。可以理解為對原子指標業務統計范圍的圈定。如原子指標：支付金額，最近一天海外買家支付金額為派生指標（最近一天為時間周期，海外為修飾詞，買家為維度）
11、鉆取
鉆取是改變維的層次，變換分析的粒度。它包括向上鉆取（roll up）和向下鉆取（drill down）
roll up是在某一維上將低層次的細節數據概括到高層次的匯總數據，或者減少維數；是指自動生成匯總行的分析方法。通過向導的方式，用戶可以定義分析因素的匯總行，例如對于各地區各年度的銷售情況，可以生成地區與年度的合計行，也可以生成地區或者年度的合計行
而drill down則相反，它從匯總數據深入到細節數據進行觀察或增加新維。例如，用戶分析“各地區、城市的銷售情況”時，可以對某一個城市的銷售額細分為各個年度的銷售額，對某一年度的銷售額，可以繼續細分為各個季度的銷售額。通過鉆取的功能，使用戶對數據能更深入了解，更容易發現問題，做出正確的決策
維度建模的三種模式
1、 星形模式
星形模式(Star Schema)是最常用的維度建模方式，下圖展示了使用星形模式進行維度建模的關系結構：
可以看出，星形模式的維度建模由一個事實表和一組維表成，且具有以下特點：
a. 維表只和事實表關聯，維表之間沒有關聯；
b. 每個維表的主碼為單列，且該主碼放置在事實表中，作為兩邊連接的外碼；
c. 以事實表為核心，維表圍繞核心呈星形分布；
2、雪花模式
雪花模式(Snowflake Schema)是對星形模式的擴展，每個維表可繼續向外連接多個子維表，下圖為使用雪花模式進行維度建模的關系結構：
星形模式中的維表相對雪花模式來說要大，而且不滿足規范化設計。雪花模型相當于將星形模式的大維表拆分成小維表，滿足了規范化設計。然而這種模式在實際應用中很少見，因為這樣做會導致開發難度增大，而數據冗余問題在數據倉庫里并不嚴重
3、星座模式
星座模式(Fact Constellations Schema)也是星型模式的擴展。基于這種思想就有了星座模式：
前面介紹的兩種維度建模方法都是多維表對應單事實表，但在很多時候維度空間內的事實表不止一個，而一個維表也可能被多個事實表用到。在業務發展后期，絕大部分維度建模都采用的是星座模式
4、三種模式對比
歸納一下，星形模式/雪花模式/星座模式的關系如下圖所示：
雪花模式是將星型模式的維表進一步劃分，使各維表均滿足規范化設計。而星座模式則是允許星形模式中出現多個事實表
維度表設計
維度的設計過程就是確定維度屬性的過程，如何生成維度屬性，以及所生成維度屬性的優劣，決定了維度是用的方便性，成為數據倉庫易用性的關鍵。數據倉庫的能力直接與維度屬性的質量和深度成正比
維度表基本設計方法
以商品維度為例對維度設計放發進行詳細說明
第一步：選擇維度或者新建維度。作為維度建模的核心，在企業級數據倉庫中，必須保證維度的唯一性。以商品維度為例，有且只有一個維度定義。
第二步：確定主維表。此處的主維表一般是ODS表，直接與業務系統同步。
第三步：確定相關維表。數據倉庫是業務源系統的數據整合，不同業務系統或者同一業務系統中的表之間存在關聯性，根據業務系統的梳理，確定哪些表和主維表存在關聯關系，并選擇其中的某些表用于生成維度屬性。以商品維度為例，根據業務邏輯的梳理，可以得到商品與類目、sku、買家、賣家、店鋪等維度存在的關聯關系。
第四步：確定維度屬性。本步驟主要包括兩個階段，其中一個階段是從主維表中選擇維度屬性或生成新的維度屬性；第二個階段是從相關維表中選擇維度屬性或者生成新的維度屬性。以商品維度為例，從主維表和類目、sku、賣家、店鋪等相關維表中選擇維度屬性或者生成新的維度屬性
確定維度屬性的幾點提示
a、 盡可能生成豐富的維度屬性；
b、 盡可能多的給出包括一些富有意義的文字描述；
c、 區分數值型屬性和事實；
d、 盡可能沉淀出通用的維度屬性
如下圖是規范化的商品維度表現形式：
該模式屬于雪花模式
注意：采用雪花模式，用戶在統計分析的過程中需要大量的關聯操作，是用復雜度高，同時查詢性能很差，如果數據量巨大，那就更差了；因此需要將維度的屬性層次合并到單個維度中，該操作稱之為反規范化，采用反規范化處理，方便，易用且性能好
對于商品維度，如果采用反規范化，將表現為下圖所示的形式：
參考
- 《數據倉庫》
- 《數據倉庫工具箱》
點贊評論不走丟，帶你看更多，數據干貨
總結
以上是生活随笔為你收集整理的大数据架构详解_【数据如何驱动增长】（3）大数据背景下的数仓建设 amp; 数据分层架构设计...的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： dim private public s
- 下一篇： eclipse 64位 免安装_Pyth