數據湖是誰?那數據倉庫又算什么?

刀光劍影江湖情,摧枯拉朽浪滔滔。功名利祿拂衣去,山高水遠路迢迢。

數據湖初識

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

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

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

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

數據湖的定義

Wikipedia上說數據湖是一類存儲數據自然/原始格式的系統或存儲,通常是對象塊或者文件,包括原始系統所產生的原始數據拷貝以及為了各類任務而產生的轉換數據,包括來自于關系型數據庫中的結構化數據(行和列)、半結構化數據(如CSV、日志、XML、JSON)、非結構化數據(如email、文檔、PDF等)和二進制數據(如圖像、音頻、視頻)。

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

微軟的定義就更加模糊了,并沒有明確給出什么是Data Lake,而是取巧的將數據湖的功能作為定義,數據湖包括一切使得開發者、數據科學家、分析師能更簡單的存儲、處理數據的能力,這些能力使得用戶可以存儲任意規模、任意類型、任意產生速度的數據,并且可以跨平臺、跨語言的做所有類型的分析和處理。

但是隨著大數據技術的融合發展,早期的定義可能不再那么準確了,數據湖不斷演變,匯集了各種技術,包括數據倉庫、實時和高速數據流技術、數據挖掘、深度學習、分布式存儲和其他技術。逐漸發展成為一個可以存儲所有結構化和非結構化任意規模數據,并可以運行不同類型的大數據工具,對數據進行大數據處理、實時分析和機器學習等操作的統一數據管理平臺。

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

趨勢

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

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

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

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

在這 10 年的時間里,主流的互聯網公司在數據技術上的玩法并沒有多大的改變,比如推薦需要用到的用戶畫像、電商里商品的標簽、好友傳播時用的圖、金融風控數據體系,站在更高的一個角度看,我們會發現,十年前做的事情,比如用戶畫像表,如果你現在去做推薦服務,還是需要這個表。這樣會產生一個什么現象?十年的互聯網行業的人才積累、知識積累、經驗積累,讓我們可以更加容易地去做一些事情,比如十年前很難招聘到的懂推薦數據的人才,水平在如今也就是一個行業的平均值罷了。

既然這些事情變得更好做了,人才更多了,我們就期望在事情上做的更精致。因為從業務上講,我去推薦短視頻,讓用戶購買東西,這個需求是沒有止境的,是可以永遠做下去的。所以以前我可能是 T+1 才能知道用戶喜歡什么,現在這個需求很容易就達到之后,我希望用戶進來 10s 之后的行為就告訴我這個用戶的喜好;以前可能做一些粗粒度的運營,比如全人群投放等,現在可能要轉化思路,做更加精細化的運營,給每個用戶提供個性化定制的結果。

技術演進——實時化

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

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

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

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

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

舉一個比較現實的例子,假設我們構造了一個實時計算指標,在發現計算錯誤后我們需要修正昨天的實時數據,這種情況下一般是另外寫一個離線任務,從離線數倉中獲取數據,再重新計算一遍,寫入到存儲里。這樣的做法意味著我們在每寫一個實時需求的同時,都要再寫一個離線任務,這樣的成本對于一個工程師是巨大的。

技術演進——降低成本化

實時系統的成本太大了,這也是讓很多公司對實時需求望而生畏的原因之一。所以這樣去建設實時數倉的思路肯定不行啊,等于我要招兩倍的人才(可能還不止),花兩倍的時間,才能做一個讓我的業務可能只提升 10% 的功能。從技術的角度來看,是這兩套系統的技術棧不一樣造成了工程無法統一。那么,Data Lake 就是用來解決這樣一個問題,比如我一個離線任務,能不能既產生實時指標,也產生離線指標,類似下圖這樣:

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

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

這塊我們也在積極探索,國內互聯網公司的主流做法還是停留在 【技術演進——降低成本化】 的階段,相信隨著大家的努力,很快就會出現優秀且成功的實踐。

技術演進——去結構化

Pentaho的CTO James Dixon 在2011年提出了"Data Lake"的概念。在面對大數據挑戰時,他聲稱:不要想著數據的"倉庫"概念,想想數據 的“湖”概念。數據“倉庫”概念和數據湖概念的重大區別是:數據倉庫中數據在進入倉庫之前需要是事先歸類,以便于未來的分析。這在OLAP時代很常見,但是對于離線分析卻沒有任何意義,不如把大量的原始數據線保存下來,而現在廉價的存儲提供了這個可能。

數據倉庫是高度結構化的架構,數據在轉換之前是無法加載到數據倉庫的,用戶可以直接獲得分析數據。而在數據湖中,數據直接加載到數據湖中,然后根據分析的需要再轉換數據。

這里看到數據倉庫這種Schema on write 已經不滿足日益變化的需求了,數據湖是Schema on read ,但是個人覺得與其說是Schema 還不如說是對數據的態度變了,以前我們只將對當前有用的數據抽取到數倉,而現在我們希望數據湖可以容納所有的數據,即使當前用不到,但是當想用的時候就有數據可以用。

數據湖與數據倉庫的區別

數據倉庫是一種成熟穩定的技術架構。它們存儲經過ETL 處理的結構化數據,以便完成整決策支持的過程。數據倉庫將數據組合為一種聚合、摘要形式,以在企業范圍內使用,并在執行數據寫入操作時寫入元數據和模式定義。數據倉庫通常擁有固定的配置;它們是高度結構化的,因此不太靈活和敏捷。數據倉庫成本與在存儲前處理所有數據相關,而且大容量存儲的費用相對較高。

相較而言,數據湖是較新的技術,擁有不斷演變的架構。數據湖存儲任何形式(包括結構化和非結構化)和任何格式(包括文本、音頻、視頻和圖像)的原始數據。根據定義,數據湖不會接受數據治理,但專家們都認為良好的數據管理對預防數據湖轉變為數據沼澤不可或缺。數據湖在數據讀取期間創建模式,與數據倉庫相比,數據湖缺乏結構性,而且更靈活;它們還提供了更高的敏捷性。在檢索數據之前無需執行任何處理,而且數據湖特意使用了更加便宜的存儲。


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

  1. 數據價值性:數倉中保存的都是結構化處理后的數據,而數據湖中可以保存原始數據也可以保存結構化處理后的數據,保證用戶能獲取到各個階段的數據。因為數據的價值跟不同的業務和用戶強相關,有可能對于A用戶沒有意義的數據,但是對于B用戶來說意義巨大,所以都需要保存在數據湖中。
  2. 數據實時性:數據湖支持對實時和高速數據流執行 ETL 功能,這有助于將來自 IoT 設備的傳感器數據與其他數據源一起融合到數據湖中。形象的來看,數據湖架構保證了多個數據源的集成,并且不限制schema,保證了數據的精確度。數據湖可以滿足實時分析的需要,同時也可以作為數據倉庫滿足批處理數據挖掘的需要。數據湖還為數據科學家從數據中發現更多的靈感提供了可能。
  3. 數據保真性:數據湖中對于業務系統中的數據都會存儲一份“一模一樣”的完整拷貝。與數據倉庫不同的地方在于,數據湖中必須要保存一份原始數據,無論是數據格式、數據模式、數據內容都不應該被修改。在這方面,數據湖強調的是對于業務數據“原汁原味”的保存。同時,數據湖應該能夠存儲任意類型/格式的數據。
  4. 數據靈活性:數據湖提供靈活的,面向任務的數據綁定,不需要提前定義數據模型,"寫入型schema" 和"讀取型schema",其實本質上來講是數據schema的設計發生在哪個階段的問題。對于任何數據應用來說,其實schema的設計都是必不可少的,即使是MongoDB等一些強調“無模式”的數據庫,其最佳實踐里依然建議記錄盡量采用相同/相似的結構。

數據倉庫強調的"寫入型schema"背后隱含的邏輯是數據在寫入之前,就需要根據業務的訪問方式確定數據的schema,然后按照既定schema,完成數據導入,帶來的好處是數據與業務的良好適配;但是這也意味著數倉的前期擁有成本會比較高,特別是當業務模式不清晰、業務還處于探索階段時,數倉的靈活性不夠。

數據湖強調的"讀取型schema"背后的潛在邏輯則是認為業務的不確定性是常態:我們無法預期業務的變化,那么我們就保持一定的靈活性,將設計去延后,讓整個基礎設施具備使數據“按需”貼合業務的能力。因此,個人認為“保真性”和“靈活性”是一脈相承的:既然沒辦法預估業務的變化,那么索性保持數據最為原始的狀態,一旦需要時,可以根據需求對數據進行加工處理。因此,數據湖更加適合創新型企業、業務高速變化發展的企業。同時,數據湖的用戶也相應的要求更高,數據科學家、業務分析師(配合一定的可視化工具)是數據湖的目標客戶。

總結

離線架構大行其道數十年,互聯網數十年技術積淀和業務發展對數據又提出新要求,實時計算技術的發展滿足了人們對數據實時性的要求,但未能滿足互聯網人對低成本高性能的執著追逐,技術的浪潮一波接一波,如果你錯過了朝陽和高山,請不要錯過了星辰和大海

當然,對于數據湖架構的批評也是不絕于耳。有人批評說,匯集各種雜亂的數據,應該就是數據沼澤。Martin Fowler也對數據湖中數據的安全性和私密性提出了質疑,歷史見證了每一次新技術的誕生總是遇到萬般挫折與質疑,但是它何曾讓你失望過。




作者:柯廣的網絡日志

微信公眾號:Java大數據與數據倉庫