資料湖初識
近兩年，為什麼都開始談論起 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 處理的結構化資料，以便完成整決策支援的過程。資料倉儲將資料組合為一種聚合、摘要形式，以在企業範圍內使用，並在執行資料寫入操作時寫入後設資料和模式定義。資料倉儲通常擁有固定的配置；它們是高度結構化的，因此不太靈活和敏捷。資料倉儲成本與在儲存前處理所有資料相關，而且大容量儲存的費用相對較高。
相較而言，資料湖是較新的技術，擁有不斷演變的架構。資料湖儲存任何形式（包括結構化和非結構化）和任何格式（包括文字、音訊、視訊和影像）的原始資料。根據定義，資料湖不會接受資料治理，但專家們都認為良好的資料管理對預防資料湖轉變為資料沼澤不可或缺。資料湖在資料讀取期間建立模式，與資料倉儲相比，資料湖缺乏結構性，而且更靈活；它們還提供了更高的敏捷性。在檢索資料之前無需執行任何處理，而且資料湖特意使用了更加便宜的儲存。
| 資料湖 | 資料倉儲 |
|---|---|
| 能處理所有型別的資料，如結構化資料，非結構化資料，半結構化資料等，資料的型別依賴於資料來源系統的原始資料格式。 | 只能處理結構化資料進行處理，而且這些資料必須與資料倉儲事先定義的模型吻合。 |
| 讀取的時候設計schema，儲存原始原始資料 | 寫入時設計資料倉儲，儲存處理後的原始資料 |
| 擁有足夠強的計算能力用於處理和分析所有型別的資料，分析後的資料會被儲存起來供使用者使用。 | 處理結構化資料，將它們或者轉化為多維資料，或者轉換為報表，以滿足後續的高階報表及資料分析需求。 |
| 資料湖通常包含更多的相關的資訊，這些資訊有很高概率會被訪問，並且能夠為企業挖掘新的運營需求。 | 資料倉儲通常用於儲存和維護長期資料，因此資料可以按需訪問。 |
資料湖與資料倉儲的差別很明顯。 然而，在企業中兩者的作用是互補的，不應認為資料湖的出現是為了取代資料倉儲，畢竟兩者的作用是截然不同的
資料價值性：數倉中儲存的都是結構化處理後的資料，而資料湖中可以儲存原始資料也可以儲存結構化處理後的資料，保證使用者能獲取到各個階段的資料。因為資料的價值跟不同的業務和使用者強相關，有可能對於A使用者沒有意義的資料，但是對於B使用者來說意義巨大，所以都需要儲存在資料湖中。
資料實時性：資料湖支援對實時和高速資料流執行 ETL 功能，這有助於將來自 IoT 裝置的感測器資料與其他資料來源一起融合到資料湖中。形象的來看，資料湖架構保證了多個資料來源的整合，並且不限制schema，保證了資料的精確度。資料湖可以滿足實時分析的需要，同時也可以作為資料倉儲滿足批處理資料探勘的需要。資料湖還為資料科學家從資料中發現更多的靈感提供了可能。
資料保真性：資料湖中對於業務系統中的資料都會儲存一份“一模一樣”的完整拷貝。與資料倉儲不同的地方在於，資料湖中必須要儲存一份原始資料，無論是資料格式、資料模式、資料內容都不應該被修改。在這方面，資料湖強調的是對於業務資料“原汁原味”的儲存。同時，資料湖應該能夠儲存任意型別/格式的資料。
資料靈活性：資料湖提供靈活的，面向任務的資料繫結，不需要提前定義資料模型，"寫入型schema" 和"讀取型schema"，其實本質上來講是資料schema的設計發生在哪個階段的問題。對於任何資料應用來說，其實schema的設計都是必不可少的，即使是MongoDB等一些強調“無模式”的資料庫，其最佳實踐裡依然建議記錄儘量採用相同/相似的結構。
資料倉儲強調的"寫入型schema"背後隱含的邏輯是資料在寫入之前，就需要根據業務的訪問方式確定資料的schema，然後按照既定schema，完成資料匯入，帶來的好處是資料與業務的良好適配；但是這也意味著數倉的前期擁有成本會比較高，特別是當業務模式不清晰、業務還處於探索階段時，數倉的靈活性不夠。
資料湖強調的"讀取型schema"背後的潛在邏輯則是認為業務的不確定性是常態：我們無法預期業務的變化，那麼我們就保持一定的靈活性，將設計去延後，讓整個基礎設施具備使資料“按需”貼合業務的能力。因此，個人認為“保真性”和“靈活性”是一脈相承的：既然沒辦法預估業務的變化，那麼索性保持資料最為原始的狀態，一旦需要時，可以根據需求對資料進行加工處理。因此，資料湖更加適合創新型企業、業務高速變化發展的企業。同時，資料湖的使用者也相應的要求更高，資料科學家、業務分析師（配合一定的視覺化工具）是資料湖的目標客戶。
總結
離線架構大行其道數十年，網際網路數十年技術積澱和業務發展對資料又提出新要求，實時計算技術的發展滿足了人們對資料實時性的要求，但未能滿足網際網路人對低成本高效能的執著追逐，技術的浪潮一波接一波，如果你錯過了朝陽和高山，請不要錯過了星辰和大海
當然，對於資料湖架構的批評也是不絕於耳。有人批評說，彙集各種雜亂的資料，應該就是資料沼澤。Martin Fowler也對資料湖中資料的安全性和私密性提出了質疑，歷史見證了每一次新技術的誕生總是遇到萬般挫折與質疑，但是它何曾讓你失望過。