瞭解一下數據倉庫

0.什麼是數據庫？

• 數據庫（DB）是按照數據結構來組織、存儲和管理數據的創建在計算機存儲設備上的倉庫

• 數據庫是長期存儲在計算機內、有組織的、可共享的數據集合。數據庫中的數據指的是以必定的數據模型組織、描述和儲存在一塊兒、具備儘量小的冗餘度、較高的數據獨立性和易擴展性的特色並可在必定範圍內爲多個用戶共享

1.什麼是數據倉庫？

數據倉庫是面向主題的，集成的，相對穩定的，反映歷史變化的數據集合，用於支持管理決策。

• 面向主題：在較高層次上將企業信息系統的數據綜合歸併進行分析利用的抽象的概念。每一個主題基本上對應一個相應的分析領域。

• 集成的：企業級數據，同時數據要保持一致性、完整性、有效性、精確性。

• 穩定性：從某個時間段來看是保持不變的，沒有更新操做、刪除操做，以查詢分析爲主。

• 變化的：反映歷史變化。

功能	數據倉庫	數據庫
數據範圍	存儲歷史的、完整的、反應歷史變化的	當前狀態數據
數據變化	可添加、誤刪除、無變動的、反映歷史變化	支持頻繁的增、刪、改、查操做
應用場景	面向分析、支持戰略決策	面向業務交易流程
設計理論	違範式、適當冗餘	遵守範式（1NF、2NF、3NF等範式）、避免冗餘
處理量	非頻繁、大批量、高吞吐、有延遲	頻繁、小批次、高併發、低延遲

面向業務的數據庫常稱做OLTP，面向分析的數據倉庫稱爲OLAP。

2.數據倉庫的發展歷程

數據倉庫概念最先可追溯到20世紀70年代，但願經過一種架構將業務處理系統和分析處理分爲不一樣的層次。

20世紀80年代，簡歷TA2(Technical Architecture2)規範，該明肯定義了分析系統的四個組成部分：數據獲取、數據訪問、目錄、用戶服務。

1988年，IBM第一次提出信息倉庫的概念：一個結構化的環境，能支持最終用戶管理其所有的業務，並支持信息技術部門保證數據質量；抽象出基本組件：數據抽取、轉換、有效性驗證、加載、cube開發等，基本明確了數據倉庫的基本原理、框架結構，以及分析系統的主要原則。

---

[敲黑板，說重點]:

轉換：Sqoop進行簡單的數據轉換，更多的轉化操做是經過ETL來實現的

有效性驗證：牽扯到數據質量的問題

---

那麼如何去建設數據倉庫呢？

• 1. 1991年，Bill Inmon提出了自上而下（top-down）的方式建設企業數據倉庫（Data Warehouse, DW），認爲DW是一個總體的商業智能系統（BI）的一部分。一家企業只有一個DW，數據集市（Data Market, DM）的信息來源出自DW，在DW中，信息存儲符合3NF範式。

• 2）Ralph Kimball則主張自下而上(bottom-up)的方式創建DW，極力推崇創建數據集市，認爲DW是企業內全部DM的集合，信息老是被存儲在多維模型中。

• 3）Bill Inmon提出了新的BI架構CIP（Corporation information factory），把DM包含了進來。CIP的核心是將DW架構劃分爲不一樣的層次以知足不一樣場景的需求，好比常見的ODS、DW（e g: DWD, DWS等）、DM等，每層根據實際場景採用不一樣的建設方案，該思路也是目前DW建設的架構指南，但究竟是以top-down仍是bottom-up方式進行DW建設，並未統一。

---

[敲黑板，說重點]:

不少人說Hadoop時代維度建模已經不是必須的了，其實否則，在整個Hadoop時代建模依然是有用的，並且是很是有意義的。Hadoop爲整個大數據應用提供了技術的基礎，包括Hive、Spark，只是技術架構。而咱們談及大數據的時候，更多的關注的是大數據的價值，因此在組織梳理數據內容的時候依然會有數據建模的概念。

只不過不少公司作大數據多是剛起步階段，更在乎與流量方面，因此不須要建模，可是等數據體量達到必定程度後，若是沒有數據建模，那麼數據質量也就沒法保障，數據也就會廢掉、爛掉。

---

數據倉庫分層架構圖：

核心簡述：

• 將業務DB中數據同步到只讀DB中
• 使用Sqoop將只讀DB中的數據Import到HDFS上（ODS）
• 將ODS層Hive中的數據經過HQL篩選到DWS層中（DWS存儲的是中間彙總的結果）
• 將DWS層Hive中的數據經過HQL結合具體需求篩選到DM中（DM存儲的是待計算的指標）
• 將DM層Hive中的數據經過Sqoop，Spark SQL導入到RDBMS之MySQL中存儲起來（用於數據可視化展現）
• 經過可視化技術讀取RDBMS中相應結果數據進行可視化展現（餅狀圖、柱形圖、折線圖等）

爲何要對數據倉庫進行分層？

• 用空間換時間，經過大量的預處理來提高系統的用戶體驗（效率），所以數據倉庫會存在大量的數據冗餘。
• 若是不分層的話，源業務系統的業務規則發生變化將會影響整個系統的清洗過程，工做量巨大。
• 經過數據分層管理能夠簡化數據清洗的過程，由於原來把一步的工做分了多個步驟去執行，至關於把一個複雜的工做拆分紅了多個簡單的工做，把一個大的黑盒變成了一個白盒，每一層的處理的邏輯都相對簡單和容易理解，這樣咱們比較容易肯定每個步驟的正確性，當數據發生錯誤的時候，每每咱們須要調整某個步驟便可。

說了這麼多，那麼數據倉庫的創建步驟呢？

• 1. 收集和分析業務需求
• 2）創建數據模型和數據倉庫的物理設計
• 3）定義數據源
• 4）選擇數據倉庫技術和平臺
• 5）從操做型數據庫中抽取，淨化和轉換數據到數據倉庫中
• 6）選擇訪問和報表工具
• 7）選擇數據庫鏈接軟件
• 8）選擇數據分析和數據展現軟件
• 9）更新數據倉庫

3.基於大數據的數倉構建特色

• 1. 特色

鑑於互聯網行業的「要麼變化，要麼去死」的影響，決定了在互聯網領域，基於大數據的數據倉庫建設是沒法按照原有的項目流程、開發模式進行，更多的是須要結合新的技術體系、業務場景進行靈活的調整，以快速響應需求爲導向。

• 2. 普遍的應用場景

傳統的數倉	基於大數據的數倉
建設週期長	要求快速響應需求
需求穩定	需求靈活、多變
時效性要求不高	對實時性有不一樣程度的要求
面向DSS、CRM、BI等系統	除了面向DSS、BI等傳統應用外，還要響應用戶畫像、個性化推薦（好比你看了一遍文章，再給你推薦十片同類型文章）、及其學習、數據分析等各類複雜的應用場景

阿里系：OneData（公司級別全部數據應用都基於我這一個數據，只有一個數據出口，不論實時仍是離線都是統一的惟一出口），OneService（數據服務也是統一的）

不少時候，咱們提供到數倉，就會以爲是離線的、至少也是T+1的，可是這是傳統的數據倉庫，而基於大數據的數據倉庫不該該這麼理解，實時也應該概括到數據倉庫中。

• 3. 技術棧更全面、複雜
  • 傳統數倉建設：更可能是基於成熟的商業數據集成平臺，好比Oracle、Informatica等，技術體系比較成熟完善，但相對較封閉，對實施者技術面要求也相對專業且單一。
  • 基於大數據的數倉建設：通常是基於非商業、開源的技術，且涉及技術較普遍、複雜，沒有商業的公司提供服務，須要本身維護更多的技術框架。常見的是基於Hadoop的生態建設。

技術棧總圖：

• 4. 數倉模型設計更靈活
  • 傳統數倉：
    • 有較爲穩定的業務場景和相對可靠的數據質量，同時也有較爲穩定的需求，對數倉的建設有較爲完善的項目流程管控，數倉模型設計有嚴格的、穩定的建設標準
  • 互聯網行業：
    • 行業變化快、業務靈活，同時互聯網又是個靠速度存活的行業
    • 源數據種類繁多：數據庫、Nginx log、用戶瀏覽軌跡等結構化、非結構化、半結構化數據
    • 數據質量相對差，層次不齊

綜上，在互聯網領域，數倉模型是必需要存在（不必定是維度建模，可是至少須要一個建模），且數倉模型的設計更關注靈活、快速響應和應對多變的市場環境，更加以快速解決業務、運營問題爲導向，快速數據接入、快速業務接入，更不存在一勞永逸。

4.數據倉庫的應用範圍與前景

• 數倉存在的意義

  • 工程治理

• 基於大數據的數據倉庫在互聯網行業應用：

  • BI
  • 消息推送
  • 千人千面
  • 用戶畫像
  • 反欺詐

5.發展方向

• 1）數據分析、數據挖掘、人工智能、機器學習、風險控制、無人駕駛

• 2）數據化運營、精準運營

• 3）廣告精準、智能投放

Resource Link

• [1] 數據倉庫(三)之架構篇
• [2] 數據倉庫學習筆記 --- 如何設計數據倉庫