數據湖
出自 MBA智库百科(https://wiki.mbalib.com/)
數據湖（Data Lake）
目錄 |
數據湖是一個以原始格式存儲數據的存儲庫或系統。它按原樣存儲數據，而無需事先對數據進行結構化處理。一個數據湖可以存儲結構化數據（如關係型資料庫中的表），半結構化數據（如CSV、日誌、XML、JSON），非結構化數據（如電子郵件、文檔、PDF）和二進位數據（如圖形、音頻、視頻）。
數據湖是一個集中式存儲庫，允許您以任意規模存儲所有結構化和非結構化數據。您可以按原樣存儲數據（無需先對數據進行結構化處理），並運行不同類型的分析 – 從控制面板和可視化到大數據處理、實時分析和機器學習，以指導做出更好的決策。
簡單來說，數據湖的定義就是原始數據保存區
數據湖從企業的多個數據源獲取原始數據，並且針對不同的目的，同一份原始數據還可能有多種滿足特定內部模型格式的數據副本。因此，數據湖中被處理的數據可能是任意類型的信息，從結構化數據到完全非結構化數據。
企業對數據湖寄予厚望，希望它能幫助用戶快速獲取有用信息，並能將這些信息用於數據分析和機器學習演算法，以獲得與企業運行相關的洞察力。
數據湖最早是由Pentaho的創始人兼CTO， James Dixon，在2010年10月紐約Hadoop World大會上提出來的。當時Pentaho剛剛發佈了Hadoop的第一個版本。在這樣的一個大背景下，可以合理的猜測，當時James Dixon提出數據湖的概念，是為了推廣自家的Pentaho產品以及Hadoop的。
Pentaho是個BI分析組件。當時的BI分析主要是基於數據市場（Data Mart）的。數據市場的建立需要事先識別出感興趣的欄位、屬性，並對數據進行聚合處理。這樣BI分析面臨兩個問題：
- 只使用一部分屬性，這些數據只能回答預先定義好（pre-determined）的問題。
- 數據被聚合了，最低層級的細節丟失了，能回答的問題被限制了。
而基於Hadoop的BI分析，可以解決這個問題——把所有數據都原樣存在Hadoop中，後面需要的時候再來取用。如果說數據集市、數據倉庫裡面是瓶裝的水——它是清潔的、打包好的、擺放整齊方便取用的；那麼數據湖裡面就是原生態的水——它是未經處理的，原汁原味的。數據湖中的水從源頭流入湖中，各種用戶都可以來湖裡獲取、蒸餾提純這些水（數據）。
由此，數據湖的概念被提出來了，並引起了大家的普遍關註。
後來，不知怎麼，又有一個新的特性加進來了：就是數據湖可以解決數據孤島問題。——這個想法似乎也挺符合數據湖的理念的。各種數據源都匯聚到一個湖裡，自然就解決了數據孤島問題。——但這應該並不是James的本意。從他後來的blog中可以看出，他所認為的數據湖是這樣的：
- 數據湖應該是來源於單一的數據源；
- 你可以有多個數據湖；
- 如果存儲來自多個系統的數據並對他們進行關聯，那麼這不是數據湖，而是由多個數據湖填充而成的水上花園（Water Garden）
不過，創始人怎麼想已經不重要了……目前大家普遍認為，解決數據孤島是數據湖的一大特點，畢竟這是一個看上去很美好的事。但是，把解決數據孤島作為數據湖的使命，也確實引入了不少問題。
輕鬆地收集數據：數據湖與數據倉庫的一大區別就是，Schema On Read，即在使用數據時才需要Schema信息；而數據倉庫是Schema On Write，即在存儲數據時就需要設計好Schema。這樣，由於對數據寫入沒有限制，數據湖可以更容易的收集數據。
從數據中發掘更多價值：數據倉庫和數據市場由於只使用數據中的部分屬性，所以只能回答一些事先定義好的問題；而數據湖存儲所有最原始、最細節的數據，所以可以回答更多的問題。並且數據湖允許組織中的各種角色通過自助分析工具，對數據進行分析，以及利用AI、機器學習的技術，從數據中發掘更多的價值。
消除數據孤島：數據湖中彙集了來自各個系統中的數據，這就消除了數據孤島問題。
具有更好的擴展性和敏捷性：數據湖可以利用分散式文件系統來存儲數據，因此具有很高的擴展能力。開源技術的使用還降低了存儲成本。數據湖的結構沒那麼嚴格，因此天生具有更高的靈活性，從而提高了敏捷性。
數據湖應該具備哪些特征。在數據方面：
1）“保真性”。數據湖中對於業務系統中的數據都會存儲一份“一模一樣”的完整拷貝。與數據倉庫不同的地方在於，數據湖中必須要保存一份原始數據，無論是數據格式、數據模式、數據內容都不應該被修改。在這方面，數據湖強調的是對於業務數據“原汁原味”的保存。同時，數據湖應該能夠存儲任意類型/格式的數據。
2）“靈活性”： 上表一個點是 “寫入型schema” v.s.“讀取型schema”，其實本質上來講是數據schema的設計發生在哪個階段的問題。對於任何數據應用來說，其實schema的設計都是必不可少的，即使是mongoDB等一些強調“無模式”的資料庫，其最佳實踐里依然建議記錄儘量採用相同/相似的結構。“寫入型schema”背後隱含的邏輯是數據在寫入之前，就需要根據業務的訪問方式確定數據的schema，然後按照既定schema，完成數據導入，帶來的好處是數據與業務的良好適配；但是這也意味著數倉的前期擁有成本會比較高，特別是當業務模式不清晰、業務還處於探索階段時，數倉的靈活性不夠。
數據湖強調的“讀取型schema”，背後的潛在邏輯則是認為業務的不確定性是常態：我們無法預期業務的變化，那麼我們就保持一定的靈活性，將設計去延後，讓整個基礎設施具備使數據“按需”貼合業務的能力。因此，個人認為“保真性”和“靈活性”是一脈相承的：既然沒辦法預估業務的變化，那麼索性保持數據最為原始的狀態，一旦需要時，可以根據需求對數據進行加工處理。因此，數據湖更加適合創新型企業、業務高速變化發展的企業。同時，數據湖的用戶也相應的要求更高，數據科學家、業務分析師（配合一定的可視化工具）是數據湖的目標客戶。
3）“可管理”：數據湖應該提供完善的數據管理能力。既然數據要求“保真性”和“靈活性”，那麼至少數據湖中會存在兩類數據：原始數據和處理後的數據。數據湖中的數據會不斷的積累、演化。因此，對於數據管理能力也會要求很高，至少應該包含以下數據管理能力：數據源、數據連接、數據格式、數據schema（庫/表/列/行）。同時，數據湖是單個企業/組織中統一的數據存放場所，因此，還需要具有一定的許可權管理能力。
4）“可追溯”：數據湖是一個組織/企業中全量數據的存儲場所，需要對數據的全生命周期進行管理，包括數據的定義、接入、存儲、處理、分析、應用的全過程。一個強大的數據湖實現，需要能做到對其間的任意一條數據的接入、存儲、處理、消費過程是可追溯的，能夠清楚的重現數據完整的產生過程和流動過程。
在計算方面，個人認為數據湖對於計算能力要求其實非常廣泛，完全取決於業務對於計算的要求。
5）豐富的計算引擎。從批處理、流式計算、互動式分析到機器學習，各類計算引擎都屬於數據湖應該囊括的範疇。一般情況下，數據的載入、轉換、處理會使用批處理計算引擎；需要實時計算的部分，會使用流式計算引擎；對於一些探索式的分析場景，可能又需要引入互動式分析引擎。隨著大數據技術與人工智慧技術的結合越來越緊密，各類機器學習/深度學習演算法也被不斷引入，例如TensorFlow/PyTorch框架已經支持從HDFS/S3/OSS上讀取樣本數據進行訓練。因此，對於一個合格的數據湖項目而言，計算引擎的可擴展/可插拔，應該是一類基礎能力。
6）多模態的存儲引擎。理論上，數據湖本身應該內置多模態的存儲引擎，以滿足不同的應用對於數據訪問需求（綜合考慮響應時間/併發/訪問頻次/成本等因素）。但是，在實際的使用過程中，數據湖中的數據通常並不會被高頻次的訪問，而且相關的應用也多在進行探索式的數據應用，為了達到可接受的性價比，數據湖建設通常會選擇相對便宜的存儲引擎（如S3/OSS/HDFS/OBS），並且在需要時與外置存儲引擎協同工作，滿足多樣化的應用需求。
通過數據成功創造商業價值的組織將勝過同行。Aberdeen 的一項調查表明，實施數據湖的組織比同類公司在有機收入增長方面高出 9%。這些領導者能夠進行新類型的分析，例如通過日誌文件、來自點擊流的數據、社交媒體以及存儲在數據湖中的互聯網連接設備等新來源的機器學習。這有助於他們通過吸引和留住客戶、提高生產力、主動維護設備以及做出明智的決策來更快地識別和應對業務增長機會。
根據要求，典型的組織將需要數據倉庫和數據湖，因為它們可滿足不同的需求和使用案例。
數據倉庫是一個優化的資料庫，用於分析來自事務系統和業務線應用程式的關係數據。事先定義數據結構和 Schema 以優化快速 SQL 查詢，其中結果通常用於操作報告和分析。數據經過了清理、豐富和轉換，因此可以充當用戶可信任的“單一信息源”。
數據湖有所不同，因為它存儲來自業務線應用程式的關係數據，以及來自移動應用程式、IoT 設備和社交媒體的非關係數據。捕獲數據時，未定義數據結構或 Schema。這意味著您可以存儲所有數據，而不需要精心設計也無需知道將來您可能需要哪些問題的答案。您可以對數據使用不同類型的分析（如 SQL 查詢、大數據分析、全文搜索、實時分析和機器學習）來獲得見解。
隨著使用數據倉庫的組織看到數據湖的優勢，他們正在改進其倉庫以包括數據湖，並啟用各種查詢功能、數據科學使用案例和用於發現新信息模型的高級功能。Gartner 將此演變稱為“分析型數據管理解決方案”或“DMSA”。
組織構建數據湖和分析平臺時，他們需要考慮許多關鍵功能，包括：
數據移動
數據湖允許您導入任何數量的實時獲得的數據。您可以從多個來源收集數據，並以其原始形式將其移入到數據湖中。此過程允許您擴展到任何規模的數據，同時節省定義數據結構、Schema 和轉換的時間。
安全地存儲和編目數據
數據湖允許您存儲關係數據（例如，來自業務線應用程式的運營資料庫和數據）和非關係數據（例如，來自移動應用程式、IoT 設備和社交媒體的運營資料庫和數據）。它們還使您能夠通過對數據進行爬網、編目和建立索引來瞭解湖中的數據。最後，必須保護數據以確保您的數據資產受到保護。
分析
數據湖允許組織中的各種角色（如數據科學家、數據開發人員和業務分析師）通過各自選擇的分析工具和框架來訪問數據。這包括 Apache Hadoop、Presto 和 Apache Spark 等開源框架，以及數據倉庫和商業智能供應商提供的商業產品。數據湖允許您運行分析，而無需將數據移至單獨的分析系統。
機器學習
數據湖將允許組織生成不同類型的見解，包括報告歷史數據以及進行機器學習（構建模型以預測可能的結果），並建議一系列規定的行動以實現最佳結果。
能夠在更短的時間內從更多來源利用更多數據，並使用戶能夠以不同方式協同處理和分析數據，從而做出更好、更快的決策。數據湖具有增值價值的示例包括：
改善客戶互動
數據湖可以將來自 CRM 平臺的客戶數據與社交媒體分析相結合，有一個包括購買歷史記錄和事故單的營銷平臺，使企業能夠瞭解最有利可圖的客戶群、客戶流失的原因以及將提升忠誠度的促銷活動或獎勵。
改善研發創新選擇
數據湖可以幫助您的研發團隊測試其假設，改進假設並評估結果 – 例如在產品設計中選擇正確的材料從而提高性能，進行基因組研究從而獲得更有效的藥物，或者瞭解客戶為不同屬性付費的意願。
提高運營效率
物聯網 (IoT) 引入了更多方式來收集有關製造等流程的數據，包括來自互聯網連接設備的實時數據。使用數據湖，可以輕鬆地存儲，並對機器生成的 IoT 數據進行分析，以發現降低運營成本和提高質量的方法。
數據湖架構的主要挑戰是存儲原始數據而不監督內容。對於使數據可用的數據湖，它需要有定義的機制來編目和保護數據。沒有這些元素，就無法找到或信任數據，從而導致出現“數據沼澤”。 滿足更廣泛受眾的需求需要數據湖具有管理、語義一致性和訪問控制。
