關于數倉基礎知識的超全概括
編輯導語:數據倉庫,是為企業所有級別的決策制定過程,提供所有類型數據支持的戰略集合,它可以為需要業務智能的企業,提供指導業務流程改進、監視時間、成本、質量以及控制。在本篇文章中,作者就關于數倉的基礎知識進行了超全概括。
面對大數據的多樣性,在存儲和處理這些大數據時,我們就必須要知道兩個重要的技術,其分別是:數據倉庫技術、Hadoop。當數據為結構化數據,來自傳統的數據源,則采用數據倉庫技術來存儲和處理這些數據,如下圖:
1. 什么是數據倉庫
數據倉庫之父 Bill Inmon 將數據倉庫描述為一個面向主題的、集成的、隨時間變化的、非易失的數據集合,用于支持管理者的決策過程。
數據倉庫的目的是構建面向分析的集成化數據環境,為企業提供決策支持。
數據倉庫本身并不 “生產” 任何數據;同時自身也不需要 “消費” 任何的數據,數據來源于外部,并且開放給外部應用,這也是為什么叫 “倉庫” ,而不叫 “工廠” 的原因。
2. 數據倉庫的基本概念
2.1 數據源
構建一個數據倉庫,必然要有充足的數據源,從外部為數據倉庫系統提供進行分析的 “原材料” ——數據,這些數據來源稱為數據倉庫的數據源。
數據源并不局限于傳統數據庫,可以是非結構化的信息,如爬取日志,也可以是埋點日志。
2.2 ETL
在 BI 項目中 ETL 會花掉整個項目至少 1/3 的時間,ETL 設計的好壞直接關系到 BI 項目的成敗。其中,花費時間最長的是 “T”(Transform,清洗、轉換)的部分,一般情況下這部分工作量是整個 ETL 的 2/3 。
ETL 是將業務系統中的數據經過抽?。‥xtract)、清洗轉換(Transform)和加載(Load)到數據倉庫的過程,目的是將企業中的分散、凌亂、標準不統一的數據整合到一起,為企業的決策提供分析依據。
ETL 處理分為五大模塊,分別是:數據抽取、數據清洗、數據轉換、規則檢查、數據裝載。各模塊之間靈活組合,形成 ETL 處理流程。下面簡單介紹一下各模塊之間的功能。
2.2.1 數據抽取
在構建數據倉庫過程中,數據源所提供的數據并不都是有用的,有些數據對決策并不能提供支持。
同時,外部數據源中數據冗余的現象也很普遍。數據倉庫既然是面向主題的,那么在數據源中,只有那些與主題相關的內容才是必需的、有使用價值的。
因此,必須以主題的需求為依據,對數據源的內容進行有目的地選擇,這一過程被稱為“數據抽取”(Data Extraction)。對于數據的抽取,是從各個不同的數據源抽取到 ODS(Operational Data Store,操作型數據存儲)中。
具體步驟為,首先要搞清楚數據是從哪幾個業務系統中來,各個業務系統的數據庫服務器運行什么 DBMS ,是否存在非結構化的數據等,當收集完這些信息后才可以進行數據抽取的設計。
1)對于與存放 DW 的數據庫系統相同的數據源處理方法
這類數據源在設計上比較容易處理。一般情況下,DBMS(Mysql、SQLServer)都會提供數據庫連接功能,在 DW 數據庫服務器和原業務系統之間建立直接的連接關系,接下來就可以寫查詢語句直接訪問。
2)對于與存放 DW 的數據庫系統不同的數據源處理方法
對于這類數據源,一般情況下也可以通過 ODBC 的方式建立數據庫連接。如果不能建立數據庫連接,可以用兩種方法完成,一種是通過工具將數據源導出成 .txt 或者 .xls 文件,然后再將這些源系統文件導入到 ODS 中。另一種方法是通過程序接口來完成。
3)對于文件類型數據源(.txt/.xls)
業務人員可以利用數據庫工具將這些數據導入到指定的數據庫,然后從指定的數據庫中抽取?;蛘邩I務人員借助工具實現。
4)增量更新問題
對于數據量大的系統,必須考慮增量抽取。
一般情況,業務系統會記錄業務發生的時間,可以用作增量的標志,每次抽取之前首先判斷 ODS 中記錄最大的時間,然后根據這個時間去業務系統取大于這個時間的所有記錄。
2.2.2 數據清洗轉換
一般情況下,數據倉庫分為 ODS、DW 兩部分。通過的做法是從業務系統到 ODS 做清洗,將臟數據和不完整數據過濾掉,再從 ODS 到 DW 的過程中轉換,進行一些業務規則的計算和聚合。
1)數據清洗
數據倉庫的數據源所提供的數據內容并不完美,存在著 “臟數據” ——即數據有缺省值、異常值等缺陷,而且在數據倉庫的各數據源之間,其內容也存在著不一致的現象。
為了控制這些 “臟數據” 對數據倉庫分析結果的影響程度,必須采取各種有效的措施,對其進行處理,這一處理過程稱為 “數據清洗”(Data Transform)。
對于任何數據倉庫而言,數據清洗過程都是不可缺少的。不同類型的 “臟數據” ,清洗處理的方法是不同的。
對于缺省值:產生的原因可能是,信息暫時無法獲取、信息被遺漏、屬性值不存在,比如一個兒童的固定收入等。
解決方法是,通過簡單的統計分析,得到含有缺失值的屬性個數,以及每個屬性的未缺失數、缺失數和缺失率。刪除含有缺失值的記錄、對可能值進行插補和不處理三種情況。
對于異常值:產生的原因可能是:業務系統檢查不充分。解決方法是,先對變量做一個描述性統計,進而查看哪些數據是不合理的。最常用的統計量是最大值和最小值,然后判斷變量是否超過了合理的范圍。
如果數據是符合正態分布,在原則下,異常值被定義為一組測定值中與平均值的偏差超過 3 倍標準的值,如果不符合正態分布,也可以用原理平均值的多少倍標準差來描述。
對于不一致值:產生的原因可能是:被挖掘的數據是來自不同的數據源、對于重復性存放的數據未能進行一致性更新造成。
例如:兩張表中都存儲了用戶電話號碼,但在用戶的號碼發生改變時只更新了一張表中的數據,那么兩張表中就有了不一致的數據。
解決辦法是,注意數據抽取的規則,對于業務數據變動的控制應該保證數據倉庫中數據抽取是最新數據。
數據清洗是一個反復的過程,不可能在幾天內完成,只有不斷的發現問題,解決問題。
對于是否過濾、是否修正一般要求客戶確認;對于過濾掉的數據,寫入 Excel 文件或者將過濾數據寫入數據表,在 ETL 開發的初期可以每天向業務單位發送過來數據的郵件,促使他們盡快的修正錯誤,同時也可以作為將來驗證數據的依據。
數據清洗需要注意的是不要將有用的數據過濾掉了,對于每個過濾規則認真進行驗證,并要用戶確認才行。
2) 數據轉換
數據轉換的任務主要是進行不一致的數據轉換、數據粒度的轉換和一些商務規則的計算等。
- 不一致的數據轉換:這個過程是一個整合的過程,將不同業務系統的相同類型的數據統一,比如同一個用戶在用戶管理系統的編碼是 XX0001 ,而在訂單系統的編碼是 YY0001 ,這樣在抽取過來之后統一轉換成一個編碼;
- 數據粒度的轉換:業務系統一般存儲粒度較小的數據,而數據倉庫中的數據是用來分析的,不需要粒度很小的數據,一般情況下,會將業務系統數據按照數據倉庫粒度進行聚合;
- 商務規則的計算:不同的企業有不同的業務規則,不同的數據指標,這些指標有時候不能簡單的加加減減就能完成,這個時候需要在 ETL 中將這些數據指標計算好了之后存儲在數據倉庫中,供分析使用。
2.3 元數據
所謂 “元數據”(Meta Data),就是關于數據倉庫中數據的數據。
它是關于數據倉庫中數據、操作數據以及應用程序的結構和意義的描述信息。它的作用類似于數據庫管理系統的數據字典,保存了邏輯數據結構、文件、地址和索引等信息。
廣義上講,在數據倉庫中,元數據描述了數據倉庫內數據的結構和建立方法的數據。
元數據是整個數據倉庫的核心部件,元數據管理器是企業級數據倉庫中的關鍵部件,貫穿數據倉庫構建的整個過程,直接影響著數據倉庫的構建、使用和維護。
將數據倉庫功能區域包括數據獲取、數據存儲和信息傳遞三個部分,按照這三個功能區域可以相應地將元數據分為數據獲取區域元數據、數據存儲區域元數據和信息傳遞區域元數據。
2.3.1 數據獲取區域元數據
在這個區域中,數據倉庫的處理過程主要包括數據抽取、數據轉換、數據清洗、數據集成、數據準備五項功能。
這些處理過程是通過相應的工具完成的,在這些處理過程進行時,相應的工具就記錄下了與這些處理相關的元數據。在以后的數據倉庫維護和管理過程中,技術人員也將使用這些已記錄下來的元數據管理和監控正在運行的功能。
2.3.2 數據存儲區域元數據
在這個區域中,數據倉庫的處理過程主要包括數據裝載、數據存儲、數據管理三項功能。
這些處理過程同樣是通過相應的工具完成的,在這些處理過程進行時,相應的工具就記錄下了與這些處理相關的元數據。
數據倉庫的管理員在進行完全數據刷新和數據增量裝載中會用到這些元數據;在數據備份、恢復的處理中,以及對數據倉庫的清理和數據定期歸檔中也需要用到這些元數據。對用戶來說,也有可能用到這些元數據。
2.3.3 信息傳遞區域元數據
在這個區域中,數據倉庫的處理過程主要包括報表生成、查詢處理、復雜分析三項功能。
信息傳遞區域的處理過程主要是為最終用戶服務的,所記錄的元數據為用戶提供預定義查詢和預定義報表解疑,定義了用戶查詢和報表生成需要輸入的相關參數,也包括與 OLAP 相關的元數據,系統的開發者和管理員都會參加這個區域的處理過程。
在該區域中,當用戶在查詢處理工具的輔助下構建一條查詢時,也會引用數據獲取區域和數據存儲區域中記錄的元數據。
元數據定義了數據倉庫中的數據的模式、來源、抽取和轉換規則等,而且是整個數據倉庫系統運行的基礎,元數據把數據倉庫系統中各個松散的組件聯系起來,組成了一個有機的整體。
2.4 數據集市
數據集市(Data Market,DM)是為企業特定部門的決策支持而組織起來的一批數據和業務規劃。
它是一種小型的、部門級數據倉庫,習慣上稱之為 “主題域” ,企業的不同部門有不同的 “主題域” ,因而就有不同的數據集市。
數據集市有兩種類型:獨立型數據集市(Independent Data Mart)和從屬型數據集市(Dependent Data Mart)。
獨立型數據集市的實質,是為了滿足企業內各部門的分析需求而建立的微型數據倉庫。
有些企業在實施數據倉庫項目時,為了節省投資,盡快見效,針對不同部門的需要,分布建立起這類數據集市,已解決一些較為迫切的問題。
但是,當多個獨立的數據集市增長到一定規模后,由于沒有統一的數據倉庫協調,企業只會又增長出一些新的信息孤島,仍然不能以整個企業的視角來分析數據。
從屬型數據集市的內容并不直接來自外部數據源,而是從數據倉庫中得到。在數據倉庫內部,數據根據分析主題,劃分成若干個子集,進行組織、存放。
這種面向某個具體的主題而在邏輯上或物理上進行劃分所形成的數據子集,就是從屬型數據集市。數據劃分成集市之后,在進行某個確定主題的分析時,可以有效縮小數據的檢索范圍,明顯提高工作效率。
3. 數據倉庫的四個基本特征
3.1 面向主題
傳統的操作型系統是圍繞組織的功能性應用進行組織的,而數據倉庫是面向主題的。
主題是一個抽象概念,簡單地說就是與業務相關的數據的類別,每一個主題基本對應一個宏觀的分析領域。數據倉庫被設計成輔助人們分析數據。
比如,一個公司要分析銷售數據,就可以建立一個專注于銷售的數據倉庫,使用這個數據倉庫,就可以回答類似于 “上一季度誰是我們這款產品的最佳用戶” 這樣的問題。
這個場景下的銷售,就是一個數據主題,而這種通過劃分主題定義數據倉庫的能力,就使得數據倉庫是面向主題的。
主題域是對某個主題進行分析后確定的主題的邊界,如客戶、銷售、產品都是主題域的例子。
3.2 集成
數據倉庫的一個重要的功能,是把不同的數據源的數據匯總到一起(如上圖)。
而集成是指把不同類型的數據源的數據進行整合,按照統一的形式進行集成。比如性別在一個數據源用男/女,另一個數據源用1/2,那么在數據倉庫中,就需要對其進行統一。
3.3 非易失
傳統的操作型環境中的數據一般是要周期性地更新的,且一般按一次一條記錄的方式進行。但數據倉庫中的數據通常以批量方式載入與訪問(如上圖),但在數據倉庫環境中并不進行數據更新。
數據倉庫中的數據在進行裝載時是以靜態快照的格式進行的。當產生后繼變化時,一個新的快照記錄就會寫入數據倉庫。這樣,在數據倉庫中就保存了數據的歷史狀況。
3.4 時變性
時變性指的是數據倉庫中的每個數據單元只在某一時間是準確的,在一些情況下,記錄中加有時間戳,而在另外一些情況下記錄則包含一個事務的時間。
總之,任何情況下,記錄都包含某種形式的時間標志用以說明數據在哪一時間是準確的。
除了以上四個特性外,數據倉庫還有一個非常重要的概念就是粒度,粒度問題遍布于數據倉庫體系結構的各個部分。粒度是指數據的細節或匯總程度,細節程度越高,粒度級別越低。
比如:單個事務是低粒度級別,而全部一個月事務的匯總就是高粒度級別(如下圖)。
粒度之所以是數據倉庫環境的關鍵設計問題,是因為它極大地影響數據倉庫的數據量和可以進行的查詢類型。粒度級別越低,數據量越大,查詢的細節程度越高,查詢范圍越廣泛,反之依然。
4. 數據庫和數據倉庫的區別
數據倉庫是在傳統數據庫的基礎之上發展起來的,但它并不是對傳統數據庫的徹底拋棄,而是旨在彌補傳統數據庫在數據分析能力方面的不足,以提供良好的大規模數據分析能力為己任,力圖為決策提供有效的技術支持。
和傳統數據庫相比,數據倉庫在總體特征、面向用戶、存儲內容等方面,都有著重大的差異(如下表)。
數據倉庫是在數據庫已經大量存在的情況下,為了進一步挖掘數據資源、為了決策需要而產生的,它絕不是所謂的“大型數據庫”。
數據倉庫的出現,并不是要取代數據庫。目前,大部分數據倉庫還是用關系數據庫管理系統來管理的??梢哉f,數據庫、數據倉庫相輔相成、各有千秋。
本文由 @汪仔4623 原創發布于人人都是產品經理,未經許可,禁止轉載
題圖來自 Unsplash,基于 CC0 協議
關于數倉的數據源寫的也比較狹隘,萬物皆可數據,爬蟲,埋點,采集,人工收集的數據都可以稱為數倉的數據源。阿里云dataworks是國內典型的數倉產品,它可以讀取主流的數據庫從而獲取數據,他同時也可以通過excel直接導入數據進行分析。另外關于數倉模型也是比較老的版本,但是大體沒問題,新型的數倉包含除了文中所說的原始數據層ODS與數據應用層ADM,還包含中間層CDM–主題寬表(明細整合層DWD與高粒度匯總層DWS)
整片文章寫的很好,但是對數倉的理解有誤。對數據庫和數據倉庫的區分理解有誤??梢韵攘私庖幌耯adoop生態產生的原因再去理解數據倉庫和數據庫。數倉最早在世界范圍內大型互聯網公司產生,原因很簡單,因為他們起步早,體量大,積累了大量的數據(可以用PB,ZB)計算,這些大量的數據是傳統的數據庫無法存儲與處理的。因此這個時候為了解決千臺甚至更多的計算機集群之間的數據存儲與計算問題,數倉模型產生了,hadoop生態則是為大數據存儲計算而生??梢韵胍幌?,一個初創互聯網公司,與一個創辦20年的互聯網巨頭哪個更需要DW?答案顯而易見。
很不錯!