通俗語言解釋數據倉庫、數據湖、數據中臺

數據倉庫

 

如何理解數據倉庫？舉個簡單的例子。

我如今打算學習大數據的內容，因此我看了CSDN，博客園，微信的大數據公衆號，一些實體書等等，而且我在看某些這些東西的時候，有些不錯的文章我都收藏了，儲存在這些論壇的帳號中，實體書我也作了不少標記，來標出那些對我有用的部分。

 

看了好幾個月以後，我打算來一次總體的複習，結果這個時候遇到了困難：我收藏的文章太多了，我徹底記不獲得底哪些文章在哪裏了，若是我要找某一篇文章，我可能要從頭開始一個一個的翻找這些論壇的收藏夾，看看我要找的東西到底在哪裏，何況還要實體書呢！也要翻一遍！

  這工做量也太大了，並且我每找一次東西都要幾乎從頭開始找一次，太麻煩了，此時我想到，我爲何不把我收藏夾的那些東西都放到一個地方呢？這樣我也不用登陸不少帳號找了，此時我就想到，我是否是能夠用Word軟件呢？把收藏夾裏面的文章都複製到Word裏不就能夠了嗎？並且Word軟件還有查找功能，比這樣翻找的快太多了！立馬行動，我開始把一篇文章從標題到內容全都複製到Word文檔裏，實體書上的我也打字打進來，花了好幾天時間，我終於把全部的東西都搬到Word文檔上了，真是累死了！

 

  這個時候我又有了新的麻煩：雖然我按照一篇文檔一個文件來分開，可是這些文件很是多，並且標題都不明確，單從文件名字上來看根本就不知道內容是什麼，若是要知道是什麼內容，仍是須要一個一個打開來看。

 

  這樣並不比以前的操做要輕鬆啊？我花了這麼多的時間，結果也就省了一個打開網頁的操做，反而又增長了一個打開Word文檔的操做，這樣彷佛比以前更麻煩了，畢竟個人電腦打開網頁還好，打開Word可慢多了，這要怎麼辦呢？

這時候我又想到了一個辦法：把這些文檔所有打開看看，而後把文件名字改好，改爲我一眼就能看得懂的名字，這樣就很便於查找了吧，畢竟看一眼名字就知道這個文件是否是我想要的，因而我又花了好幾天的時間，把這些文檔按照文章的內容，歸納出來一個主題，把它看成文檔的名字，當我完成以後我以爲目前就能夠很輕鬆的經過Wrod自帶的查找功能來找到我想要的文檔來看了，我以爲個人整理工做以及結束了

 

  但是當我開始複習這些資料的時候，又發現了一個問題：這些文檔讀起來很冗餘，不少的地方都是重複的，並且有的幾乎都所有重複了僅僅有一小部分纔是不一樣的，好比什麼Hadoop的定義啥的，這些不少文檔都寫了，並且都是如出一轍的，每次打開文檔都要看一遍，並且還很佔用個人磁盤空間，而另一些，好比Hadoop的版本解讀，我搜集的這些文檔，從1.0.x到3.0.x的版本解讀都有，可是我想要從1.0到3.0的版本變化，這樣的話的得把這些文檔所有都打開，而後一個文檔一個文檔的看，每次這樣翻我也很煩躁，我只想更懶一點，爲何沒有一個文檔整理了從1.0到3.0全部的版本變化呢？我在網上也沒找到，哎，靠人不如靠本身，我仍是本身來吧！

 

  這個時候我通過了前兩次的整理經歷以後我學聰明瞭，我沒有一開始就着手整理，我想了一下，我如今到底須要整理成什麼樣子？

1.不變的東西整理到一個文檔裏面去，上面寫上xxxx定義 

2.會變的東西，好比版本解讀啥的，每一個版本都會有一個文檔，這些我也整理到一個文檔裏面去，這樣我就不用處處翻來翻去了

3.可是以前的這些東西我不能刪掉，我本身合併的東西可能有的不全，或者是合併的有問題，我須要找原來的文檔對比一下，若是我把以前的刪掉，一旦我打錯了字，我可能就會一直學了錯的知識了

 

  好吧，我目前就想到這麼多，那我就開始整理吧！因而我又花了好幾天的時間，把原來的文檔中的東西提取出來，重複的定義都合併到一塊兒而且只留一份，不一樣的版本解讀我放到一個文檔裏面去，而後我要保存以前的那些原始的文檔，這倆東西不能都在一個都放在一個文件夾裏面吧，這樣也太亂了，因而我又打算吧這兩個放在兩個文件夾裏面，我建立了兩個文件夾，一個存放原始的文檔，一個存放我整理好的文檔，而後把這倆文件夾都放到

一個叫知識庫的文件夾裏面，這樣個人整理工做貌似真的已經完成了。

如今，我想看Hadoop相關的版本解讀的話，我就打開版本解讀文檔就能夠了，若是我想看Hadoop的定義和版本解讀呢？我就打開這兩個文檔，一個放在屏幕左邊，一個放在右邊，這樣看起來也很舒服，至此，個人整理工做真的算完成了。

 

  而後我忽然想到，我X，我不就是在搭建數據倉庫嗎？？？

 

  是的，你們看到這裏，若是對數據倉庫有了一些瞭解的話已經知道了數據倉庫的通常流程了，把上文的一些名詞換成數據倉庫的名詞：

 

  各個論壇和實體書的文章 ->搭建數倉以前各個系統的數據源，好比MySQL，Oracle等傳統關係型數據，還要一些業務日誌和埋點日誌（好比說你在某寶點擊某個商品啊，瀏覽了某些商品啊，這些都是有記錄的，也叫作埋點數據，前端已經在你點擊進入這個商品的詳情頁的時候作了埋點，你點進去就會產生了一條數據，會記錄你點擊的商品記錄和你這個用戶的通常信息，這就叫作埋點日誌）

 

 

  把這些不在同一個論壇，甚至在實體書上的文章，都統一放到Word文檔上，而且稍微改個文件名 --->利用一些數據導入工具，好比Sqoop，Flume，DataX（阿里雲的產品，但已開源），把這些不一樣系統上面的數據，都導入到同一個框架裏，這裏大部分都是導入到Hive裏，它利用HDFS存儲，具備自然的容災性，查詢的引擎是MR（也可使用Spark），對於這麼大的數據量是再適合不過了。這種遷移數據的行爲已是搭建數倉的一部分了，這些遷移過來的數據做爲數據倉庫的ODS層（數據準備層），這一層是爲加下來的數據層提供原始數據，咱們儘可能不作什麼變更，只作一些數據按日期分表存儲，把這些數據按照主題和邏輯劃分好。

 

 

  把文章去重，把版本解讀放到一塊兒 --->對應數據倉庫的DW層，這一層的主要任務就是把原始數據進行ETL，把原始數據分爲維度表和事實表（這種方法稱爲維度建模），把細粒度的數據聚合成粗粒的表，把一些維度退化，造成業務寬表等等

 

 

  使用文檔  --->對應數據倉庫的ADS層（也叫ST層），ST層面向用戶應用和分析需求，包括前端報表、分析圖表、KPI、儀表盤、OLAP、專題等分析，面向最終結果用戶

 

 

  這樣，咱們就完成了一個簡單的數據倉庫（三層），其中DW層還能夠細分爲DWD,DM等，這個就看實際狀況了，靈活分層

 

 

數據湖與數據中臺

 

至於數據湖和數據中臺呢？

  我是這樣理解數據湖的，上面的例子裏，咱們在把各類不一樣論壇的文章導入到Word文檔中的時候，其實已經丟失掉了一層信息：來源

放到Word文檔以後，你就沒法知道某篇文章到底來自於哪一個論壇的了 ，而數據湖呢？數據湖是盡力保持全部數據的原始面貌，不丟失任何信息，一樣，也不會作任何的處理（由於你處理數據多多少少會丟失掉一部分信息），盡力保持數據的原汁原味，由於誰也不知道之後某些數據又擁有多達的價值，因此咱們須要保持數據的原封原貌，而這個時候咱們能夠把數據倉庫想象成一個在湖邊的礦泉水加工廠，一邊抽取湖中的水（數據），進行各類清洗消毒加工，最後生產出各類各樣包裝的礦泉水來，這就是這兩個概念我本身理解。

 

  下面是維基百科上關於數據湖的定義：數據湖（Data Lake）是一個存儲企業的各類各樣原始數據的大型倉庫，其中的數據可供存取、處理、分析及傳輸。數據湖是以其天然格式存儲的數據的系統或存儲庫，一般是對象blob或文件。數據湖一般是企業全部數據的單一存儲，包括源系統數據的原始副本，以及用於報告、可視化、分析和機器學習等任務的轉換數據。數據湖能夠包括來自關係數據庫（行和列）的結構化數據，半結構化數據（CSV，日誌，XML，JSON），非結構化數據（電子郵件，文檔，PDF）和二進制數據（圖像，音頻，視頻）。

 

至於數據中臺呢？咱們先來看下數據中臺的定義：

  數據中臺是指經過企業內外部多源異構的數據採集、治理、建模、分析，應用，使數據對內優化管理提升業務，對外能夠數據合做價值釋放，成爲企業數據資產管理中樞。數據中臺創建後，會造成數據API，爲企業和客戶提供高效各類數據服務。（這個概念最先由阿里提出，實際上阿里雲的一些雲產品就是一個大的數據中臺）

  又回到以前說的礦泉水加工廠的例子，若是咱們只有一個加工廠，那確定是僅僅不夠的，由於咱們不只要喝水，還要喝的是安全健康的水，這個檢測若是工廠內本身作，你們仍是不太相信的，那麼仍是須要別人來檢測，監管加工廠的質量和水質等安全問題，這些的監管檢測機制，並且還有一個問題就是，加工廠缺乏一個管帳的，內部的財務情況很混亂， 所以，加工廠又請了另外一家公司來爲他們作財務管理，如此，再加上加工廠內部的更新換代，又增長了新技術來加工礦泉水（機器學習，數據挖掘等），加工廠是愈來愈大了，而包含兼管人員，財務管理和整個加工廠在內的，就是你們常說的數據中臺了。

 

 

 

 

以上就是我本身理解的數據倉庫、數據湖和數據中臺的概念了，若是有錯誤，歡迎在評論區指正！