數據庫和數據倉庫的知識點?編輯導語：什麼是數據湖？企業可以利用數據湖盡可能保持業務數據的可還原性，解決存儲全域原始數據的問題；而數據中台的存在則可以幫助幫助企業提升業務處理效率不過并非所有的企業都需要設立數據中台本篇文章裡，作者對數據湖與數據中台進行了詳細的解釋，一起來看一下，我來為大家科普一下關于數據庫和數據倉庫的知識點?以下内容希望對你有幫助!

數據庫和數據倉庫的知識點

編輯導語：什麼是數據湖？企業可以利用數據湖盡可能保持業務數據的可還原性，解決存儲全域原始數據的問題；而數據中台的存在則可以幫助幫助企業提升業務處理效率。不過并非所有的企業都需要設立數據中台。本篇文章裡，作者對數據湖與數據中台進行了詳細的解釋，一起來看一下。

引言：文接上回，沒有閱讀第一部分的小夥伴請點擊《10分鐘帶你了解數據庫、數據倉庫、數據湖、數據中台的區别與聯系（一）》查看，那我們就開始第二部分的内容吧，如有不準确的地方，還請希望大家進行指正。

上文通過有序性與開放性分别對數據倉庫與數據湖進行描述并對比，現在我們來詳細地了解一下數據湖。

1. 數據湖的起源

數據湖主要是為了解決存儲全域原始數據，其名稱中的“湖”字将數據湖的含義表現得淋漓盡緻。像企業的生産數據（非結構化數據與結構化數據）、業務曆史數據、臨時數據，諸如IOT設備，移動應用程序以及傳統的設備中返回的第三方數據都可以通過ETL工具形成的“水管”存儲進數據湖中。

例如筆者之前在工作過程中接觸的手機信令數據、GPS返回的定位數據等，這些數據實際上并沒有預先定義好相應的數據結構，這就意味着可以先将數據存儲起來而無需對數據進行結構化處理，也無需明确要進行什麼分析，由數據從業人員在後續工作中進行探索和嘗試。

上文中提到的結構化數據和非結構化數據，那什麼是結構化/非結構化數據呢？下面我們就解釋下兩者的區别與聯系。

2. 何為結構化/非結構化數據

舉個例子。

我們收集到了這樣一堆文字信息：

有個學生叫小趙，男的，97年的，土木工程系的，北京的；

有個學生叫小李，98年的，女的，外語系的，江蘇蘇州的；

·····

諸如此類的文字信息有幾萬行，我們存在word中，亦或是紙質版文件經由我們掃描成圖片格式的，這類就可以稱為非結構化數據。假設有需求将這些文字信息中按照性别、籍貫、專業等等統計出來，我們在第一篇文章中提到了關系型數據庫，用相關的技術和工具将這些文字信息進行處理，處理後的數據就是結構化數據。

所以結構化數據的定義：是由二維表結構來邏輯表達和實現的數據，嚴格地遵循數據格式與長度規範，主要通過關系型數據庫進行存儲和管理。

非結構化數據：不适于由數據庫二維表來表現的非結構化數據，包括所有格式的辦公文檔、 XML 、 HTML 、各類報表、圖片和音頻、視頻信息等。

3. 數據湖的作用

回歸正題，企業為什麼要建立數據湖呢，首先數據湖中存在一個重要的組成部分ODS（Operating Data Store，操作數據存儲），大家是否記得上一篇文章講過OLTP（On-Line Transaction Processing），OLTP側重于基本的、日常的事務處理，而我們現在提到的ODS就是OLTP數據的快照與曆史。

我們在上文的數據庫一節描述時提到業務數據庫與數據倉庫的結構不同，業務數據庫是為OLTP設計的，是系統的實時狀态的數據，而數據倉庫的數據是為OLAP的需求建設的，是為了深度的多維度分析。所以這樣就會造成基于數據倉庫的數據分析會産生以下的限制：

由于數據倉庫的架構設計事先訂好的，很難能做到全面覆蓋，因此基于數據倉庫的分析是收到事先定義的分析目标及數據庫的框架限制。

從OLTP的實時狀态到OLAP的分析數據的轉換會有不少信息損失，舉個例子來說，某個用戶在某個應用程序中錢包的餘額，在OLTP系統中僅僅隻會按照業務發生情況對錢包中的餘額進行實時更新，然而在OLAP系統中也是僅僅會記錄對該錢包操作的交易，如果想要去查詢并分析該用戶的曆史餘額就會比較麻煩。

而從根本上來講，數據湖的最主要作用是盡可能保持業務數據的可還原性。數據湖的定位和搜索引擎類似，我們可以像在搜索引擎中檢索數據一樣，實現按需檢索，即取即用，它存取這原始的未經改變的全量數據，可以存取、處理、分析。

4. 數據湖的發展

數據湖最早是2011年由Pentaho的首席技術官James Dixon提出的一個概念，他認為諸如數據集市，數據倉庫由于其有序性的特點，勢必會帶來數據孤島效應，而數據湖可以由于其開放性的特點可以解決數據孤島問題。

但随着數據湖在各類企業的應用，大家都覺得：嗯，這個數據有用，我要放進去；那個數據也有用，我也要放進去；于是把所有的數據不假思索地扔進基于數據湖的相關技術或工具中，沒有規則不成方圓，當我們認為所有數據都有用時，那麼所有的數據都是垃圾，數據湖也變成了造成企業成本高企的數據沼澤。

所以這也是為什麼“數據湖”叫“湖”，而不叫數據河，數據池亦或是數據海。

首先數據要能“存”，數據要夠“存”，數據要有邊界地“存”。企業級的數據是需要長期積澱的，所以是“數據湖”。

同時湖水天然會進行分層，滿足不同的生态系統要求，這與企業建設統一數據中心，存放管理數據的需求是一緻的。熱數據在上層方便流通應用，溫數據、冷數據位于數據中心的不同存儲介質之中，達到數據存儲容量與成本的平衡。

我們終于迎來了最近幾年很火的數據中台。網上有很多文章關于數據中台的介紹，什麼Hive、Spark、Hadoop、Kalfa等等很多技術名詞，聽上去非常的高大上而且雲裡霧裡的，會使初涉産品的我們望而卻步。

所以接下來我們從何為中台、何為數據中台、數據中台可以做什麼三個方面來講講數據中台。

1. 何為中台

首先抛開數據，中台這一概念這兩年在國内大火。說起來源，網上文章都會提到這種組織是2015年馬雲參觀Supercell的遊戲公司借鑒過來的，并且後來“阿裡巴巴”CEO逍遙子提出的組建的“大中台，小前台”的組織和業務體制。那麼我們能用一個比較淺顯的例子來理解“中台”一詞麼?

當然可以，有一家連鎖且超級便宜的意大利西餐連鎖店“薩莉亞”，相信大部分同學都光顧過，9元的意面，24的披薩，上菜速度超快，雖然比不上傳統西餐，但相比于這個價位，屬實很良心了，而且目前薩莉亞在中國已經開設了将近400家（截止2019年）分店。

那麼薩莉亞保持價格低廉同時上菜效率高效的原因是什麼？答案很簡單，就是中央廚房進行粗加工，然後門店的廚師僅需要簡單地烹饪即可端上餐桌。相比于傳統餐廳采購（買菜）→配菜→做菜的環節，既減少門店廚師的數量，降低人工成本的同時又加快上菜速度。

回到我們研發流程來看，采購（買菜）→配菜環節就是我們研發的後台，他們幫助我們解決“有什麼”；而配菜→做菜環節就是我們的業務前台團隊，他們要做的就是根據客戶的“口味”來“做什麼”。

而配菜，蔬菜整理這個環節，也就是薩莉亞的“中央廚房”就相當于我們的中台，僅僅需要門店的需求，中央廚房就可以快速提供對應的材料，提高業務開發效率，減少重複開發成本。

2. 何為數據中台

介紹完了“中台”這一概念，數據中台相信大家也能舉一反三。沒錯，對于采購來的“菜”就相當于數據，做出來的“菜”就相當于業務部門所以需要的數據應用。

那麼配菜環節就相當于IT部門的各種數據算法，每道菜單獨配菜效率慢且冗餘度較高，于是“中央廚房”就對數據算法進行規範化，系統化。針對于業務部門所需要的各道菜提供粗加工的半成品，這就是“數據産品”。

這種“中央廚房”配菜的過程就相當于我們所說的“數據中台”。那麼是不是每個企業都必須搭建數據中台麼？數據中台在業務上能解決什麼問題呢？

3. 數據中台能做什麼

所有企業是否都需要搭建數據中台？首先我們知道企業引進一項技術或産品，不在于是否“時髦”，不在于是否“高科技”，而在于是否适合該公司目前的發展，是否能提高公司的利潤，降低公司的成本。

首先數據中台的作用通過對中台及數據中台的描述，總結以下2點：

提供數據産品及數據服務，包括但不限于決策支持類工具（例如業務報表、大屏數據可視化展示）；數據分析類（BI商業智能、機器學習模型、數據挖掘）；數據檢索（日志分析）等；

提升企業各部門的數據連通性，避免數據孤島的産生。

根據以上提到數據中台的兩個優勢，針對一個企業是否搭建數據中台，亦或是說一個企業在一開始從零到一就要構建數據中台？筆者在此有幾點自己的總結：

首先針對于不同的行業，盡管傳統企業數字化改革正在路上且已經有很多行業已經改革成功，但是針對于大部分傳統企業，别說數據中台，公司連數據倉庫的時代都沒有到來，“羅馬不是一天建成的”抛去建設數據中台的财力，時間成本高昂不提，就是對于傳統企業的業務流轉模式，企業員工接受程度來說都是一條難以逾越的鴻溝，數據中台不可操之過急。

對于一些處于數據倉庫時代的傳統企業或互聯網企業，由于各個部門不停無限地進行滿足其業務支撐點取數要求、業務統計、看數需求，就可以嘗試轉型數據中台。

對初創企業，業務線單一且業務模式還經常不斷變化，不斷試錯時，沒有能力去進行數據中台的搭建，換言之就是“先活下去最重要”。

本篇文章分兩部分介紹了數據庫、數據倉庫、數據湖、數據中台的區别與聯系。

關于數據有人說數據是新的石油資源，國家也将數據作為一種新型生産要素，與傳統生産要素并列。

筆者曾經在泛互聯網以及傳統企業的業務部門都工作一段時間，由于各類原因，相比于泛互聯網行業的數據化相比，傳統企業的數據化之路并不一帆風順。2020年8月，國務院國資委引發《關于加快推進國有企業數字化轉型工作的通知》表現出各國有企業未來數字化轉型将成為必然，如何協助傳統企業進行數字化轉型，利用數據驅動傳統行業迸發新的活力對于數據産品經理，尤其是對ToB的數據産品經理将會是挑戰與機遇。

筆者會繼續努力與大家分享交流其他數據産品相關的文章與内容。

本文由 @快樂的給予 原創發布于人人都是産品經理，未經許可，禁止轉載

題圖來自 Pexels，基于 CC0 協議