數據湖是誰？那數據倉庫又算什麼？

數據湖初識

近兩年，爲何都開始談論起 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 就是用來解決這樣一個問題，好比我一個離線任務，能不能既產生實時指標，也產生離線指標，相似下圖這樣：

why-data-lake1

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

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

這塊咱們也在積極探索，國內互聯網公司的主流作法仍是停留在 【技術演進——下降成本化】 的階段，相信隨着你們的努力，很快就會出現優秀且成功的實踐。

技術演進——去結構化

Pentaho的CTO James Dixon 在2011年提出了"Data Lake"的概念。在面對大數據挑戰時，他聲稱：不要想着數據的"倉庫"概念，想一想數據 的「湖」概念。數據「倉庫」概念和數據湖概念的重大區別是：數據倉庫中數據在進入倉庫以前須要是事先歸類，以便於將來的分析。這在OLAP時代很常見，可是對於離線分析卻沒有任何意義，不如把大量的原始數據線保存下來，而如今廉價的存儲提供了這個可能。

數據倉庫是高度結構化的架構，數據在轉換以前是沒法加載到數據倉庫的，用戶能夠直接得到分析數據。而在數據湖中，數據直接加載到數據湖中，而後根據分析的須要再轉換數據。

這裏看到數據倉庫這種Schema on write 已經不知足日益變化的需求了，數據湖是Schema on read ，可是我的以爲與其說是Schema 還不如說是對數據的態度變了，之前咱們只將對當前有用的數據抽取到數倉，而如今咱們但願數據湖能夠容納全部的數據，即便當前用不到，可是當想用的時候就有數據能夠用

數據湖與數據倉庫的區別

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

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

數據湖	數據倉庫
能處理全部類型的數據，如結構化數據，非結構化數據，半結構化數據等，數據的類型依賴於數據源系統的原始數據格式。	只能處理結構化數據進行處理，並且這些數據必須與數據倉庫事先定義的模型吻合。
讀取的時候設計schema，存儲原始原始數據	寫入時設計數據倉庫，存儲處理後的原始數據
擁有足夠強的計算能力用於處理和分析全部類型的數據，分析後的數據會被存儲起來供用戶使用。	處理結構化數據，將它們或者轉化爲多維數據，或者轉換爲報表，以知足後續的高級報表及數據分析需求。
數據湖一般包含更多的相關的信息，這些信息有很高几率會被訪問，而且可以爲企業挖掘新的運營需求。	數據倉庫一般用於存儲和維護長期數據，所以數據能夠按需訪問。

數據湖與數據倉庫的差異很明顯。 然而，在企業中二者的做用是互補的，不該認爲數據湖的出現是爲了取代數據倉庫，畢竟二者的做用是大相徑庭的

1. 數據價值性：數倉中保存的都是結構化處理後的數據，而數據湖中能夠保存原始數據也能夠保存結構化處理後的數據，保證用戶能獲取到各個階段的數據。由於數據的價值跟不一樣的業務和用戶強相關，有可能對於A用戶沒有意義的數據，可是對於B用戶來講意義巨大，因此都須要保存在數據湖中。

2. 數據實時性：數據湖支持對實時和高速數據流執行 ETL 功能，這有助於未來自 IoT 設備的傳感器數據與其餘數據源一塊兒融合到數據湖中。形象的來看，數據湖架構保證了多個數據源的集成，而且不限制schema，保證了數據的精確度。數據湖能夠知足實時分析的須要，同時也能夠做爲數據倉庫知足批處理數據挖掘的須要。數據湖還爲數據科學家從數據中發現更多的靈感提供了可能。

3. 數據保真性：數據湖中對於業務系統中的數據都會存儲一份「如出一轍」的完整拷貝。與數據倉庫不一樣的地方在於，數據湖中必需要保存一份原始數據，不管是數據格式、數據模式、數據內容都不該該被修改。在這方面，數據湖強調的是對於業務數據「原汁原味」的保存。同時，數據湖應該可以存儲任意類型/格式的數據。

4. 數據靈活性：數據湖提供靈活的，面向任務的數據綁定，不須要提早定義數據模型，"寫入型schema" 和"讀取型schema"，其實本質上來說是數據schema的設計發生在哪一個階段的問題。對於任何數據應用來講，其實schema的設計都是必不可少的，即便是MongoDB等一些強調「無模式」的數據庫，其最佳實踐裏依然建議記錄儘可能採用相同/類似的結構。

數據倉庫強調的"寫入型schema"背後隱含的邏輯是數據在寫入以前，就須要根據業務的訪問方式肯定數據的schema，而後按照既定schema，完成數據導入，帶來的好處是數據與業務的良好適配；可是這也意味着數倉的前期擁有成本會比較高，特別是當業務模式不清晰、業務還處於探索階段時，數倉的靈活性不夠。

數據湖強調的"讀取型schema"背後的潛在邏輯則是認爲業務的不肯定性是常態：咱們沒法預期業務的變化，那麼咱們就保持必定的靈活性，將設計去延後，讓整個基礎設施具有使數據「按需」貼合業務的能力。所以，我的認爲「保真性」和「靈活性」是一脈相承的：既然沒辦法預估業務的變化，那麼索性保持數據最爲原始的狀態，一旦須要時，能夠根據需求對數據進行加工處理。所以，數據湖更加適合創新型企業、業務高速變化發展的企業。同時，數據湖的用戶也相應的要求更高，數據科學家、業務分析師（配合必定的可視化工具）是數據湖的目標客戶。

總結

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

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