編輯導語：什麼是數據湖？企業可以利用數據湖儘可能保持業務數據的可還原性，解決存儲全域原始數據的問題；而數據中台的存在則可以幫助幫助企業提升業務處理效率。不過並非所有的企業都需要設立數據中台。本篇文章里，作者對數據湖與數據中台進行了詳細的解釋，一起來看一下。
引言：文接上回，沒有閱讀第一部分的小夥伴請點擊《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 協議