行業專家最近寫了一篇文章，揭露了關于數據湖架構、數據湖定義和數據湖分析的常見誤區。其文章名為“什么是數據湖？需要來避免最大的迷思。”在那篇文章中，構建了有關數據湖及其在企業數據策略中的適用范圍的當前對話。對于那些希望從數據湖中獲取價值的人來說，由于顧問和供應商的建議相互矛盾，這個主題歷來是令人困惑和不透明的。

一個可能特別令人困惑的領域是人們認為數據湖僅用于“大數據”。如果花時間閱讀湖泊上的資料，就會認為只有一種類型。人們將數據湖描述為龐大的、無所不包的實體，旨在容納所有知識。好消息是，湖泊不僅僅用于“大數據”，而且比以往任何時候都有更多的機會將其納入數據堆棧。

不同類型的數據湖

就像大自然一樣，湖泊具有各種不同的形狀和大小。每個都有自然狀態，通常反映數據生態系統，就像自然界中反映魚類，鳥類或其他生物的生態系統一樣。

不幸的是，國內服務器租用服務器托管，“大數據”角度給人們的印象是湖泊僅用于“里海”規模的數據工作。這無疑使使用數據湖變得令人生畏。因此，以如此大的角度來描述事物使得那些可以從中受益的人們無法接近湖泊的概念。這里有一些數據湖的例子。

•偉大的“里海”：就像里海是一個大水域一樣，這種類型的湖泊也是一個龐大而廣泛的，種類繁多的數據集。廣泛收集的各種數據反映了整個企業的信息。這就是大多數數據湖工作的框架。

•暫時的“湖泊”：就像沙漠中可以有小的臨時湖泊一樣，短暫的短暫存在。它們可以用于項目、試點、PoC或點解決方案，并且它們的打開與關閉速度一樣快。

•領域“項目”：這些湖泊與臨時數據湖泊一樣，通常側重于特定的知識領域。但是，與臨時湖不同，該湖將隨著時間的推移而持續存在。這些也可能是“淺”的，這意味著它們可能專注于狹窄的數據域，例如媒體、社交、Web分析、電子郵件或類似的數據源。

最近，與客戶合作創建了“域”型湖泊。該湖會將Adobe事件數據保存到AWS，以支持企業Oracle Cloud環境。為什么選擇AWS to Oracle？對于客戶的OracleBI環境，這是一種高效且具有成本效益的數據消耗模式，尤其是考慮到使用AWS Lake和Athena作為湖內容的按需查詢服務的敏捷性和經濟性。

通過設計，所有類型的湖泊都應采用抽象技術，以最大程度地降低風險并為您提供更大的靈活性。而且，它們的結構應易于使用，而與大小無關。這確保了數據科學家，業務用戶或分析師所使用的湖泊都具有易于數據使用的結構化環境。

數據湖入門

成為成功的早期采用者意味著采取業務價值方法而不是技術方法。當組織考慮如何入門時，這里有一些提示：

•重點：尋找機會，在其中部署“臨時”或“項目”解決方案。這將確保您降低風險并克服技術和組織挑戰，以便您的團隊可以對湖泊建立信心。

•熱情：確保內部有一位“傳道者”或“倡導者”，他們對組織的解決方案和采用充滿熱情。

•簡單：擁護簡單性和敏捷性，使人員、流程和技術選擇貫穿于此。缺乏復雜性不應被看作是缺陷，云服務器，而是周到的設計的副產品。

•狹義：通過限制湖泊來理解數據（例如從ERP、CRM、銷售點、市場營銷或廣告數據中導出）來使范圍狹窄且定義明確。此階段的數據素養將幫助您了解有關數據結構、提取、治理，質量和測試的工作流。

•實驗：將數據湖與現代BI和Tableau、Power BI、Amazon Quicksight或Looker等分析工具配對。這將使非技術用戶有機會通過湖泊進行實驗和探索數據訪問。這使組織可以與其他用戶群互動，以評估性能瓶頸，發現改進機會，與任何現有EDW系統（或其他數據系統）的可能鏈接以及其他候選數據源。

關注業務價值而不是技術，可以為組織提供一個在整體數據和分析策略的框架內進行工作的機會。這樣可以提高速度，并幫助組織實現數據湖目標并衡量業務績效的進度。這也導致了完善的共享術語、最佳實踐以及對建立更好平臺的投資。