周末有讀者私聊我咨詢了一些問題，遂想起了之前看過的一些關于資料湖的知識，下面是基于之前的所見和自己的思考而成文。
資料湖
資料湖是一個集中式存儲庫，允許您以任意規模存儲所有結構化和非結構化資料。您可以按原樣存儲資料（無需先對資料進行結構化處理），并運作不同類型的分析 – 從控制台和可視化到大資料處理、實時分析和機器學習，以指導做出更好的決策。
這是AWS給出的解釋。
看了很多資料湖的介紹文章，筆者認為資料湖和我們常說的ODS資料很類似，也就是原始資料的儲存區域，存儲來自各業務系統（消息隊列）的原始資料。比如電商網站的通路日志（埋點的時候是以JSON存儲），物聯網終端裝置實時發送的資料等原始資料直接存儲在資料倉庫的ODS層。
資料湖為什麼火了
做資料倉庫已經有ODS資料了，那麼怎麼突然大家都在提資料湖了？
真正的原因在于資料分析和機器學習這兩年成為了主流，可以看看現在的招聘網站，很多招聘資料分析師和算法工程師的崗位，筆者所在城市尤為明顯。15年的時候大家都在建立各自的大資料平台，那時候你懂點Hadoop，已經很了不起了。現在各個大資料平台已經建設成熟，逐漸為業務服務，越來越多的公司需要利用大資料服務于業務，提升變現能力。
基于大資料建設的資料倉庫往往是各個次元的聚合資料，大多服務于傳統的報表分析。而機器學習往往需要使用到原始資料，另外很多機器學習用到的也不至于格式化資料，使用者的評論，圖像等都可以應用到機器學習中。
為什麼要有資料湖
可以看下上面的這個組織架構圖。資料湖的存在更多的是改變部門的組織架構，畢竟現在大部分公司都更注重業務分析的價值。
傳統企業的資料團隊被當做IT體系，整天要求提數。現在，資料團隊隻需要負責提供簡單易用的工具，業務部門直接進行資料的使用。這也就是人人具備資料分析能力（人人都是資料分析師，真的很難）。
資料湖 vs 資料倉庫
這是AWS給出的對比，還是比較中肯的。
傳統的資料倉庫工作方式是集中式的：業務人員給需求到資料團隊，資料團隊根據要求加工、開發成次元表，供業務團隊通過BI報表工具查詢或者業務分析系統展示。
資料湖是開放、自助式的：開放資料給所有人使用，資料團隊更多是提供工具、環境供各業務團隊使用，業務團隊進行開發、分析。
和資料倉庫不同的是，以前資料倉庫都是先設計schema，然後灌入資料。資料湖的schema是随用随生成，随着分析場景不同而不同。關于資料湖的技術實作方面可以了解下 delta lake這個項目（我司的平台部分功能在delta lake這個項目出來之前已經實作了一些功能）。
資料湖對于資料分析師來說對資料的操控性更強，但是要求也更高，不光懂業務，懂sql，懂資料，還要懂大資料處理技術，每個人都在處理自己需要的資料，會造成很多備援資料存儲和計算資源浪費，無法形成共性的可複用的資料層，這方面數倉是有益的補充。
資料湖并不是為了颠覆資料倉庫，是為了滿足數倉無法滿足的資料需求，二者是互補的（目前來看）。
ELT
你沒看錯，是ELT，不是ETL！
周末有讀者私聊一哥，看了一篇ETL和ELT的文章，知道了概念，但是不知道具體在什麼場景下實施？
很多時候，我們隻講概念，很晦澀。先上一張圖：
資料內建包含三個基本的環節：Extract（抽取）、Transform（轉換）、Load（加載）。
ETL：抽取是将資料從已有的資料源中提取出來；轉換是對原始資料進行處理，例如使用ETL工具（Informatica、Kettle等）進行過濾空值，名額計算等；加載是将資料寫入目的地，一般是關系型資料庫。
ELT：在抽取後将結果先寫入目的地，比如Hive中，然後由下遊應用利用外部計算架構進行名額加工、模組化，例如 Spark 來完成轉換的步驟。
可以說現在大資料環境下，很多已經是ELT架構了，資料湖就非常适合作為ELT架構中的“資料存儲目的地”。
資料湖的未來
3月初和一個好友飯後閑聊，聊到數倉的建設。首先，我們思考一下數倉為什麼會出現？其實是資料量的飛速增長，以至于當時的資料存儲計算引擎，不能很好的滿足分析需求；于是數倉概念和經典的理論出現了，很好的解決了當時的問題，用“規範+存儲”來解決了當時的問題。
那麼現在大資料時代，随着技術的不斷發展，很多新技術出現了，大批量的存儲和計算不再是那麼難了，那麼我們放棄數倉那一套是否可行呢？從一哥現在處理的業務看，如果你的業務系統相對較單一，沒有幾十個業務系統每天往數倉裡灌資料，那麼資料湖可以滿足你的需求，并且對于“資料驅動”更“靈活”。如果一線的業務系統較複雜，那麼現在使用資料湖也會一不小心會變成“資料沼澤”。
是以，下一個方向也許就是資料湖的資料治理，當資料湖的治理明确後，也就是它大放異彩的時刻了！