數據湖
- 2018.2.21
- 版權聲明：本文爲博主chszs的原創文章，未經博主允許不得轉載。
我們生活在數據時代，根據Gartner的報告，全球信息數據量每年以59％的速度遞增。管理海量數據是一個重大挑戰，數據的品種和增長速度使管理變得更加困難。而且非常明顯的是，越來越巨量的數據隨着時間在繼續生成，特別是在手持設備和互聯網連接設備數量的指數增長的背景下。
對於參與其中的組織來說，這是事實——但對於其他傳統組織來說，數據量的增長並不是那麼高。不同組織的數據量不同。儘管存在這種差異，但它們之間的一個共同因素是，對於不同的利益相關方來說，進行有意義且有用的分析的重要性。隨着越來越多的組織使用不同功能的工具，爲不同利益相關者生成有意義且有用的報告的任務變得越來越具有挑戰性。
什麼是數據湖？
Gartner研究總監Nick Heudecker解釋了數據湖：
“從廣義上講，數據湖作爲企業範圍的數據管理平臺進行銷售，以分析原生格式的不同數據源。這個想法很簡單：不是將數據放入專門構建的數據存儲區，而是將其移入原始格式的數據湖。這消除了數據攝入的前期成本，如轉換。數據放入湖中後，可供組織中的每個人分析。”
因此，數據湖通過打破數據孤島，幫助企業洞察數據。“數據湖”一詞在2010年首次使用，其定義/特徵仍在不斷演變。一般來說，“數據湖”指的是一箇中央存儲庫，能夠存儲從各種內部和外部源以接近原始數據的格式獲取的Zettabytes數據。
數據湖的挑戰
數據湖通常被認爲是收集和整理來自遺留系統和來源，數據倉庫和分析系統，第三方數據，社交媒體數據，點擊流數據以及可能被視爲有用信息的所有企業數據企業。雖然這個定義很有趣，但它對每個組織來說都是可行的還是必需的？
不同的組織具有不同的分佈式數據挑戰和模式，並且隨着場景的多樣化，每個組織都有自己的數據湖需求。雖然數據的需求，模式，來源和體系結構不同，但在構建中央存儲或數據中心方面面臨的挑戰是相同的：
- 將來自不同來源的數據導入共同的中央池
- 處理少量但高度多樣化的數據
- 與數據倉庫或大數據相比，將數據存儲在低成本基礎架構中
- 與中央數據存儲接近實時同步數據
- 中央數據的可追溯性和治理
數據湖的實施注意事項
在大多數情況下，數據湖與數據即服務模型的實質部署在一起，被視爲集中記錄系統，爲企業級別的其他系統提供服務。本地化數據湖不僅擴展到支持多個團隊，而且還生成多個數據湖實例以支持更大的需求。這些集中的數據可以被所有不同的團隊用於分析需求。
有了這些理解，就可以在集成和治理方面討論數據湖泊的各種需求。
數據湖整合的挑戰
爲了在企業級部署數據湖，它需要具備某些功能，以便將其整合到組織的整體數據管理策略，IT應用程序和數據流環境中。
- 爲了使數據湖的數據在以後的時間點有用，確保湖泊在正確的時間獲取正確的數據非常重要。例如，數據湖可能會從企業財務軟件中提取月度銷售數據。如果數據湖太早接收數據，它可能只會獲得部分數據集或根本沒有數據。這可能會導致報告不準確，導致公司朝錯誤的方向發展。因此，將數據總體背景中的數據集成平臺運行到數據湖應該能夠根據業務情況實時和按需地從各種工具推送數據。
- 雖然數據庫的主要目的是存儲數據，但有時（基於不同的業務案例，爲了方便其他部門將來使用這些數據），一些數據需要在插入數據之前進行提取或處理湖。因此，集成平臺不僅應該支持這一點，還要確保數據處理的準確性和正確的順序。
- 只有當存儲的數據可以被所有不同部門提取以供自己使用時，集中式數據存儲纔是有用的。應該有能力將數據湖與其他應用程序或下游報告/分析系統集成。數據湖應該也支持REST API，不同的應用程序可以通過它們交互來獲取或推送他們自己的數據。
數據湖治理的挑戰
數據湖不僅僅是集中存儲數據並在需要時將其提供給不同的部門。隨着越來越多的用戶開始直接使用數據湖或通過下游應用程序或分析工具，數據湖治理的重要性也隨之增加。數據湖通過將來自不同儲存庫的多樣化數據集引入單一儲存庫，創造了新的挑戰和機遇。
主要挑戰是確保數據治理政策和程序的存在並在數據湖中實施。每個數據集的擁有者在進入湖泊時都應該有明確的定義。應該有一個關於每個數據所需的可訪問性，完整性，一致性和更新的非常詳細的政策或指南。
爲了解決上述問題，數據湖中應該有內置的機制來跟蹤和記錄數據湖中存在的任何數據資產的操縱。
數據湖對每個人都是一樣的嗎？
對於所有組織而言，數據湖的實施情況並不相同，因爲數據量和數據收集要求因組織而異。總的來說，數據湖帶來的觀念是數據量應該在PB級或甚至更多，並且需要使用NoSQL數據庫來實現。實際上，這些數據量和NoSQL DB的實現可能並不是所有組織都可能需要或可能無法實現的。擁有適合組織所有分析需求的中央數據存儲的最終目標可以從SQL DB開始，並具有相當大的數據量。