數據湖初識

近兩年，為什么都開始談論起 Data Lake 這個”新名詞”了？

先說說我的想法，其實還是用戶需求驅動數據服務，大家開始關注 Data Lake 的根本原因是用戶需求發生了質變，過去的數據倉庫模式以及相關組件沒有辦法滿足日益進步的用戶需求。

?

數據湖概念的誕生，源自企業面臨的一些挑戰，如數據應該以何種方式處理和存儲。最開始，企業對種類龐雜的應用程序的管理都經歷了一個比較自然的演化周期。

那么到底是什么樣的需求和挑戰驅動了技術的變革，從而導致了新技術的產生呢？

數據湖的定義

AWS定義數據湖是一個集中式存儲庫，允許您以任意規模存儲所有結構化和非結構化數據。

微軟的定義就更加模糊了，并沒有明確給出什么是Data Lake，而是取巧的將數據湖的功能作為定義，數據湖包括一切使得開發者、數據科學家、分析師能更簡單的存儲、處理數據的能力。

但是隨著大數據技術的融合發展，早期的定義可能不再那么準確了，數據湖不斷演變，匯集了各種技術，包括數據倉庫、實時和高速數據流技術、數據挖掘、深度學習、分布式存儲和其他技術。

逐漸發展成為一個可以存儲所有結構化和非結構化任意規模數據，并可以運行不同類型的大數據工具，對數據進行大數據處理、實時分析和機器學習等操作的統一數據管理平臺。

?

所以說數據倉庫不是曾經的那個倉庫了，數據湖也不是曾經的那個"大明湖畔的夏雨荷了"，sorry應該不是那一片綠油油的湖了。

趨勢

這里聊一個很重要的趨勢：數據實時化。

當然這里有很多其他的趨勢，比如低成本化、設計云原生化等，但總體上我還是認為數據實時化是近幾年來最熱門、最明顯且最容易讓人看到收益的一個趨勢。

數據倉庫過去的模式大家可能都很了解，將整個數據倉庫劃分為 ODS、DWD、DWS，使用 Hive 作為數據存儲的介質，使用 Spark 或者 MR 來做數據清洗的計算。

這樣的數據倉庫設計很清晰，數據也比較容易管理，所以大家開開心心地使用這套理論和做法將近 10 年左右。

在這 10 年的時間里，主流的互聯網公司在數據技術上的玩法并沒有多大的改變，比如推薦需要用到的用戶畫像、電商里商品的標簽、好友傳播時用的圖、金融風控數據體系。

站在更高的一個角度看，我們會發現，十年前做的事情，比如用戶畫像表，如果你現在去做推薦服務，還是需要這個表。這樣會產生一個什么現象？

十年的互聯網行業的人才積累、知識積累、經驗積累，讓我們可以更加容易地去做一些事情，比如十年前很難招聘到的懂推薦數據的人才，水平在如今也就是一個行業的平均值罷了。

既然這些事情變得更好做了，人才更多了，我們就期望在事情上做的更精致。因為從業務上講，我去推薦短視頻，讓用戶購買東西，這個需求是沒有止境的，是可以永遠做下去的。

所以以前我可能是 T+1 才能知道用戶喜歡什么，現在這個需求很容易就達到之后，我希望用戶進來 10s 之后的行為就告訴我這個用戶的喜好；以前可能做一些粗粒度的運營，比如全人群投放等，現在可能要轉化思路，做更加精細化的運營，給每個用戶提供個性化定制的結果。

技術演進——實時化

數據實時化沒問題，但是對應到技術上是什么情況呢？是不是我們要在實時領域也搭一套類似離線數據倉庫的數據體系和模式？

是的，很多公司確實是將實時數據流劃分為了不同層級——也就是我們說的實時數倉，整體層級的劃分思路和離線倉庫類似，但是實時數據的載體就不是 Hive 或者 Hdfs 了，而是要選擇更加實時的消息隊列，比如 Kafka，這樣就帶來了很多問題，比如：

• 消息隊列的存儲時間有限；
• 消息隊列沒有查詢分析的功能；
• 回溯效率比文件系統更差；

除了實時數據載體的問題，還有引入實時數倉后，和離線數倉的統一的問題，

• 比如實時數倉的數據治理、權限管理，是不是要單獨做一套？
• 如何統一實時數據和離線數據的計算口徑？
• 兩套數據系統的資源浪費嚴重，成本提高？

舉一個比較現實的例子，假設我們構造了一個實時計算指標，在發現計算錯誤后我們需要修正昨天的實時數據，這種情況下一般是另外寫一個離線任務，從離線數倉中獲取數據，再重新計算一遍，寫入到存儲里。

這樣的做法意味著我們在每寫一個實時需求的同時，都要再寫一個離線任務，這樣的成本對于一個工程師是巨大的。

技術演進——降低成本化

實時系統的成本太大了，這也是讓很多公司對實時需求望而生畏的原因之一。所以這樣去建設實時數倉的思路肯定不行啊，等于我要招兩倍的人才（可能還不止），花兩倍的時間，才能做一個讓我的業務可能只提升 10% 的功能。

從技術的角度來看，是這兩套系統的技術棧不一樣造成了工程無法統一。那么，數據湖就是用來解決這樣一個問題，比如我一個離線任務，能不能既產生實時指標，也產生離線指標，類似下圖這樣：

?

滿足上面最重要的一個前提就是我的數據源是實時的，這樣對我們的大數據存儲主要就是HDFS 和 S3 又提出了新的挑戰——數據實時更新，如果原有技術或者組件不能滿足需求，新的技術在需求的驅動下就此誕生。

除了計算層面上，在數據管理上，比如中間表的 schema 管理，數據權限管理，能否做到統一，在架構上實現統一后，我們在應對實時需求時，可以將實時離線的冗余程度降到最低，甚至能夠做到幾乎沒有多余成本。

數據湖與數據倉庫的區別

數據倉庫是一種成熟穩定的技術架構。它們存儲經過ETL 處理結構化數據，以便完成整決策支持的過程。數據倉庫將數據組合為一種聚合、摘要形式，以在企業范圍內使用，并在執行數據寫入操作時寫入元數據和模式定義。

數據倉庫通常擁有固定的配置；它們是高度結構化的，因此不太靈活和敏捷。數據倉庫成本與在存儲前處理所有數據相關，而且大容量存儲的費用相對較高。

相較而言，數據湖是較新的技術，擁有不斷演變的架構。數據湖存儲任何形式（包括結構化和非結構化）和任何格式（包括文本、音頻、視頻和圖像）的原始數據。根據定義，數據湖不會接受數據治理，但專家們都認為良好的數據管理對預防數據湖轉變為數據沼澤不可或缺。

數據湖在數據讀取期間創建模式，與數據倉庫相比，數據湖缺乏結構性，而且更靈活；它們還提供了更高的敏捷性。在檢索數據之前無需執行任何處理，而且數據湖特意使用了更加便宜的存儲。

數據湖與數據倉庫的差別很明顯。?然而，在企業中兩者的作用是互補的，不應認為數據湖的出現是為了取代數據倉庫，畢竟兩者的作用是截然不同的。

總結

離線架構大行其道數十年，互聯網數十年技術積淀和業務發展對數據又提出新要求，實時計算技術的發展滿足了人們對數據實時性的要求，但未能滿足互聯網人對低成本高性能的執著追逐。

當然，對于數據湖架構的批評也是不絕于耳。有人批評說，匯集各種雜亂的數據，應該就是數據沼澤。

歷史見證了每一次新技術的誕生總是遇到萬般挫折與質疑，但是它何曾讓你失望過。

總結

以上是生活随笔為你收集整理的在批评数据湖的时候，你有没有想过，它并不是取代数据仓库的的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。