數(shù)據(jù)湖初識

近兩年卿嘲，為什么都開始談?wù)撈?Data Lake 這個”新名詞”了？

先說說我的想法拾枣，其實還是用戶需求驅(qū)動數(shù)據(jù)服務(wù)梅肤，大家開始關(guān)注 Data Lake 的根本原因是用戶需求發(fā)生了質(zhì)變，過去的數(shù)據(jù)倉庫模式以及相關(guān)組件沒有辦法滿足日益進(jìn)步的用戶需求俊啼。

數(shù)據(jù)湖概念的誕生左医，源自企業(yè)面臨的一些挑戰(zhàn)炒辉，如數(shù)據(jù)應(yīng)該以何種方式處理和存儲黔寇。最開始，企業(yè)對種類龐雜的應(yīng)用程序的管理都經(jīng)歷了一個比較自然的演化周期屏轰。

那么到底是什么樣的需求和挑戰(zhàn)驅(qū)動了技術(shù)的變革霎苗，從而導(dǎo)致了新技術(shù)的產(chǎn)生呢唁盏？

數(shù)據(jù)湖的定義

Wikipedia上說數(shù)據(jù)湖是一類存儲數(shù)據(jù)自然/原始格式的系統(tǒng)或存儲，通常是對象塊或者文件厘擂，包括原始系統(tǒng)所產(chǎn)生的原始數(shù)據(jù)拷貝以及為了各類任務(wù)而產(chǎn)生的轉(zhuǎn)換數(shù)據(jù)刽严，包括來自于關(guān)系型數(shù)據(jù)庫中的結(jié)構(gòu)化數(shù)據(jù)（行和列）舞萄、半結(jié)構(gòu)化數(shù)據(jù)（如CSV、日志撑螺、XML实蓬、JSON）安皱、非結(jié)構(gòu)化數(shù)據(jù)（如email艇炎、文檔、PDF等）和二進(jìn)制數(shù)據(jù)（如圖像缀踪、音頻驴娃、視頻）。

AWS定義數(shù)據(jù)湖是一個集中式存儲庫蔗草，允許您以任意規(guī)模存儲所有結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)咒精。

微軟的定義就更加模糊了旷档，并沒有明確給出什么是Data Lake鞋屈，而是取巧的將數(shù)據(jù)湖的功能作為定義故觅，數(shù)據(jù)湖包括一切使得開發(fā)者逻卖、數(shù)據(jù)科學(xué)家昭抒、分析師能更簡單的存儲灭返、處理數(shù)據(jù)的能力熙含，這些能力使得用戶可以存儲任意規(guī)模艇纺、任意類型黔衡、任意產(chǎn)生速度的數(shù)據(jù)盟劫，并且可以跨平臺、跨語言的做所有類型的分析和處理塘装。

但是隨著大數(shù)據(jù)技術(shù)的融合發(fā)展影所，早期的定義可能不再那么準(zhǔn)確了猴娩，數(shù)據(jù)湖不斷演變，匯集了各種技術(shù)裂七，包括數(shù)據(jù)倉庫背零、實時和高速數(shù)據(jù)流技術(shù)徙瓶、數(shù)據(jù)挖掘毛雇、深度學(xué)習(xí)灵疮、分布式存儲和其他技術(shù)震捣。逐漸發(fā)展成為一個可以存儲所有結(jié)構(gòu)化和非結(jié)構(gòu)化任意規(guī)模數(shù)據(jù)蒿赢，并可以運行不同類型的大數(shù)據(jù)工具渣触，對數(shù)據(jù)進(jìn)行大數(shù)據(jù)處理嗅钻、實時分析和機器學(xué)習(xí)等操作的統(tǒng)一數(shù)據(jù)管理平臺养篓。

所以說數(shù)據(jù)倉庫不是曾經(jīng)的那個倉庫了，數(shù)據(jù)湖也不是曾經(jīng)的那個"大明湖畔的夏雨荷了"剔应，sorry應(yīng)該不是那一片綠油油的湖了

趨勢

這里聊一個很重要的趨勢：數(shù)據(jù)實時化峻贮。

當(dāng)然這里有很多其他的趨勢应闯，比如低成本化碉纺、設(shè)計云原生化等骨田，但總體上我還是認(rèn)為數(shù)據(jù)實時化是近幾年來最熱門、最明顯且最容易讓人看到收益的一個趨勢态贤。

數(shù)據(jù)倉庫過去的模式大家可能都很了解，將整個數(shù)據(jù)倉庫劃分為 ODS芥驳、DWD茬高、DWS怎栽，使用 Hive 作為數(shù)據(jù)存儲的介質(zhì)婚瓜，使用 Spark 或者 MR 來做數(shù)據(jù)清洗的計算。

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

在這 10 年的時間里片橡，主流的互聯(lián)網(wǎng)公司在數(shù)據(jù)技術(shù)上的玩法并沒有多大的改變吹泡，比如推薦需要用到的用戶畫像经瓷、電商里商品的標(biāo)簽舆吮、好友傳播時用的圖色冀、金融風(fēng)控數(shù)據(jù)體系锋恬，站在更高的一個角度看，我們會發(fā)現(xiàn)趟径，十年前做的事情蜗巧，比如用戶畫像表，如果你現(xiàn)在去做推薦服務(wù)蓝丙，還是需要這個表渺尘。這樣會產(chǎn)生一個什么現(xiàn)象？十年的互聯(lián)網(wǎng)行業(yè)的人才積累鸥跟、知識積累、經(jīng)驗積累盔沫，讓我們可以更加容易地去做一些事情架诞，比如十年前很難招聘到的懂推薦數(shù)據(jù)的人才很泊，水平在如今也就是一個行業(yè)的平均值罷了。

既然這些事情變得更好做了沾谓，人才更多了委造，我們就期望在事情上做的更精致。因為從業(yè)務(wù)上講搏屑，我去推薦短視頻争涌，讓用戶購買東西，這個需求是沒有止境的辣恋，是可以永遠(yuǎn)做下去的亮垫。所以以前我可能是 T+1 才能知道用戶喜歡什么，現(xiàn)在這個需求很容易就達(dá)到之后伟骨，我希望用戶進(jìn)來 10s 之后的行為就告訴我這個用戶的喜好饮潦；以前可能做一些粗粒度的運營，比如全人群投放等携狭，現(xiàn)在可能要轉(zhuǎn)化思路仅颇，做更加精細(xì)化的運營引颈，給每個用戶提供個性化定制的結(jié)果凌停。

技術(shù)演進(jìn)——實時化

數(shù)據(jù)實時化沒問題完箩，但是對應(yīng)到技術(shù)上是什么情況呢吉捶？是不是我們要在實時領(lǐng)域也搭一套類似離線數(shù)據(jù)倉庫的數(shù)據(jù)體系和模式慷蠕？

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

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

除了實時數(shù)據(jù)載體的問題，還有引入實時數(shù)倉后，和離線數(shù)倉的統(tǒng)一的問題贵涵，

• 比如實時數(shù)倉的數(shù)據(jù)治理刻炒、權(quán)限管理，是不是要單獨做一套？
• 如何統(tǒng)一實時數(shù)據(jù)和離線數(shù)據(jù)的計算口徑？
• 兩套數(shù)據(jù)系統(tǒng)的資源浪費嚴(yán)重，成本提高？

舉一個比較現(xiàn)實的例子，假設(shè)我們構(gòu)造了一個實時計算指標(biāo)，在發(fā)現(xiàn)計算錯誤后我們需要修正昨天的實時數(shù)據(jù)，這種情況下一般是另外寫一個離線任務(wù)狂秘，從離線數(shù)倉中獲取數(shù)據(jù)破衔，再重新計算一遍晰筛，寫入到存儲里般哼。這樣的做法意味著我們在每寫一個實時需求的同時，都要再寫一個離線任務(wù)，這樣的成本對于一個工程師是巨大的险绘。

技術(shù)演進(jìn)——降低成本化

實時系統(tǒng)的成本太大了，這也是讓很多公司對實時需求望而生畏的原因之一成黄。所以這樣去建設(shè)實時數(shù)倉的思路肯定不行啊思瘟，等于我要招兩倍的人才（可能還不止）诞帐，花兩倍的時間完慧，才能做一個讓我的業(yè)務(wù)可能只提升 10% 的功能鞭执。從技術(shù)的角度來看估脆，是這兩套系統(tǒng)的技術(shù)棧不一樣造成了工程無法統(tǒng)一。那么圃阳，Data Lake 就是用來解決這樣一個問題，比如我一個離線任務(wù)晕城，能不能既產(chǎn)生實時指標(biāo)滤蝠，也產(chǎn)生離線指標(biāo)，類似下圖這樣：

why-data-lake1

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

除了計算層面上，在數(shù)據(jù)管理上岭佳，比如中間表的 schema 管理血巍，數(shù)據(jù)權(quán)限管理，能否做到統(tǒng)一珊随，在架構(gòu)上實現(xiàn)統(tǒng)一后述寡，我們在應(yīng)對實時需求時，可以將實時離線的冗余程度降到最低叶洞，甚至能夠做到幾乎沒有多余成本鲫凶。

這塊我們也在積極探索，國內(nèi)互聯(lián)網(wǎng)公司的主流做法還是停留在 【技術(shù)演進(jìn)——降低成本化】 的階段衩辟，相信隨著大家的努力螟炫，很快就會出現(xiàn)優(yōu)秀且成功的實踐。

技術(shù)演進(jìn)——去結(jié)構(gòu)化

Pentaho的CTO James Dixon 在2011年提出了"Data Lake"的概念艺晴。在面對大數(shù)據(jù)挑戰(zhàn)時昼钻，他聲稱：不要想著數(shù)據(jù)的"倉庫"概念掸屡，想想數(shù)據(jù) 的“湖”概念。數(shù)據(jù)“倉庫”概念和數(shù)據(jù)湖概念的重大區(qū)別是：數(shù)據(jù)倉庫中數(shù)據(jù)在進(jìn)入倉庫之前需要是事先歸類然评，以便于未來的分析仅财。這在OLAP時代很常見，但是對于離線分析卻沒有任何意義碗淌，不如把大量的原始數(shù)據(jù)線保存下來盏求，而現(xiàn)在廉價的存儲提供了這個可能。

數(shù)據(jù)倉庫是高度結(jié)構(gòu)化的架構(gòu)贯莺，數(shù)據(jù)在轉(zhuǎn)換之前是無法加載到數(shù)據(jù)倉庫的风喇，用戶可以直接獲得分析數(shù)據(jù)。而在數(shù)據(jù)湖中缕探，數(shù)據(jù)直接加載到數(shù)據(jù)湖中魂莫，然后根據(jù)分析的需要再轉(zhuǎn)換數(shù)據(jù)。

這里看到數(shù)據(jù)倉庫這種Schema on write 已經(jīng)不滿足日益變化的需求了爹耗，數(shù)據(jù)湖是Schema on read 耙考，但是個人覺得與其說是Schema 還不如說是對數(shù)據(jù)的態(tài)度變了，以前我們只將對當(dāng)前有用的數(shù)據(jù)抽取到數(shù)倉潭兽，而現(xiàn)在我們希望數(shù)據(jù)湖可以容納所有的數(shù)據(jù)倦始，即使當(dāng)前用不到，但是當(dāng)想用的時候就有數(shù)據(jù)可以用

數(shù)據(jù)湖與數(shù)據(jù)倉庫的區(qū)別

數(shù)據(jù)倉庫是一種成熟穩(wěn)定的技術(shù)架構(gòu)山卦。它們存儲經(jīng)過ETL 處理的結(jié)構(gòu)化數(shù)據(jù)鞋邑，以便完成整決策支持的過程。數(shù)據(jù)倉庫將數(shù)據(jù)組合為一種聚合账蓉、摘要形式枚碗，以在企業(yè)范圍內(nèi)使用，并在執(zhí)行數(shù)據(jù)寫入操作時寫入元數(shù)據(jù)和模式定義铸本。數(shù)據(jù)倉庫通常擁有固定的配置肮雨；它們是高度結(jié)構(gòu)化的，因此不太靈活和敏捷箱玷。數(shù)據(jù)倉庫成本與在存儲前處理所有數(shù)據(jù)相關(guān)怨规，而且大容量存儲的費用相對較高。

相較而言锡足，數(shù)據(jù)湖是較新的技術(shù)波丰，擁有不斷演變的架構(gòu)。數(shù)據(jù)湖存儲任何形式（包括結(jié)構(gòu)化和非結(jié)構(gòu)化）和任何格式（包括文本舶得、音頻掰烟、視頻和圖像）的原始數(shù)據(jù)。根據(jù)定義，數(shù)據(jù)湖不會接受數(shù)據(jù)治理媚赖，但專家們都認(rèn)為良好的數(shù)據(jù)管理對預(yù)防數(shù)據(jù)湖轉(zhuǎn)變?yōu)閿?shù)據(jù)沼澤不可或缺。數(shù)據(jù)湖在數(shù)據(jù)讀取期間創(chuàng)建模式珠插，與數(shù)據(jù)倉庫相比惧磺，數(shù)據(jù)湖缺乏結(jié)構(gòu)性，而且更靈活捻撑；它們還提供了更高的敏捷性磨隘。在檢索數(shù)據(jù)之前無需執(zhí)行任何處理，而且數(shù)據(jù)湖特意使用了更加便宜的存儲顾患。

數(shù)據(jù)湖與數(shù)據(jù)倉庫的差別很明顯唱矛。 然而罚舱，在企業(yè)中兩者的作用是互補的，不應(yīng)認(rèn)為數(shù)據(jù)湖的出現(xiàn)是為了取代數(shù)據(jù)倉庫绎谦，畢竟兩者的作用是截然不同的

1. 數(shù)據(jù)價值性：數(shù)倉中保存的都是結(jié)構(gòu)化處理后的數(shù)據(jù)管闷，而數(shù)據(jù)湖中可以保存原始數(shù)據(jù)也可以保存結(jié)構(gòu)化處理后的數(shù)據(jù)，保證用戶能獲取到各個階段的數(shù)據(jù)窃肠。因為數(shù)據(jù)的價值跟不同的業(yè)務(wù)和用戶強相關(guān)包个，有可能對于A用戶沒有意義的數(shù)據(jù)，但是對于B用戶來說意義巨大，所以都需要保存在數(shù)據(jù)湖中碧囊。

2. 數(shù)據(jù)實時性：數(shù)據(jù)湖支持對實時和高速數(shù)據(jù)流執(zhí)行 ETL 功能树灶，這有助于將來自 IoT 設(shè)備的傳感器數(shù)據(jù)與其他數(shù)據(jù)源一起融合到數(shù)據(jù)湖中。形象的來看糯而，數(shù)據(jù)湖架構(gòu)保證了多個數(shù)據(jù)源的集成天通，并且不限制schema，保證了數(shù)據(jù)的精確度熄驼。數(shù)據(jù)湖可以滿足實時分析的需要像寒，同時也可以作為數(shù)據(jù)倉庫滿足批處理數(shù)據(jù)挖掘的需要。數(shù)據(jù)湖還為數(shù)據(jù)科學(xué)家從數(shù)據(jù)中發(fā)現(xiàn)更多的靈感提供了可能瓜贾。

3. 數(shù)據(jù)保真性：數(shù)據(jù)湖中對于業(yè)務(wù)系統(tǒng)中的數(shù)據(jù)都會存儲一份“一模一樣”的完整拷貝诺祸。與數(shù)據(jù)倉庫不同的地方在于，數(shù)據(jù)湖中必須要保存一份原始數(shù)據(jù)祭芦，無論是數(shù)據(jù)格式筷笨、數(shù)據(jù)模式、數(shù)據(jù)內(nèi)容都不應(yīng)該被修改实束。在這方面奥秆，數(shù)據(jù)湖強調(diào)的是對于業(yè)務(wù)數(shù)據(jù)“原汁原味”的保存。同時咸灿，數(shù)據(jù)湖應(yīng)該能夠存儲任意類型/格式的數(shù)據(jù)构订。

4. 數(shù)據(jù)靈活性：數(shù)據(jù)湖提供靈活的，面向任務(wù)的數(shù)據(jù)綁定避矢，不需要提前定義數(shù)據(jù)模型悼瘾，"寫入型schema" 和"讀取型schema"，其實本質(zhì)上來講是數(shù)據(jù)schema的設(shè)計發(fā)生在哪個階段的問題审胸。對于任何數(shù)據(jù)應(yīng)用來說亥宿，其實schema的設(shè)計都是必不可少的，即使是MongoDB等一些強調(diào)“無模式”的數(shù)據(jù)庫砂沛，其最佳實踐里依然建議記錄盡量采用相同/相似的結(jié)構(gòu)烫扼。

數(shù)據(jù)倉庫強調(diào)的"寫入型schema"背后隱含的邏輯是數(shù)據(jù)在寫入之前，就需要根據(jù)業(yè)務(wù)的訪問方式確定數(shù)據(jù)的schema碍庵，然后按照既定schema映企，完成數(shù)據(jù)導(dǎo)入，帶來的好處是數(shù)據(jù)與業(yè)務(wù)的良好適配静浴；但是這也意味著數(shù)倉的前期擁有成本會比較高堰氓，特別是當(dāng)業(yè)務(wù)模式不清晰、業(yè)務(wù)還處于探索階段時苹享，數(shù)倉的靈活性不夠双絮。

數(shù)據(jù)湖強調(diào)的"讀取型schema"背后的潛在邏輯則是認(rèn)為業(yè)務(wù)的不確定性是常態(tài)：我們無法預(yù)期業(yè)務(wù)的變化，那么我們就保持一定的靈活性，將設(shè)計去延后囤攀，讓整個基礎(chǔ)設(shè)施具備使數(shù)據(jù)“按需”貼合業(yè)務(wù)的能力软免。因此，個人認(rèn)為“保真性”和“靈活性”是一脈相承的：既然沒辦法預(yù)估業(yè)務(wù)的變化焚挠，那么索性保持?jǐn)?shù)據(jù)最為原始的狀態(tài)或杠，一旦需要時，可以根據(jù)需求對數(shù)據(jù)進(jìn)行加工處理宣蔚。因此，數(shù)據(jù)湖更加適合創(chuàng)新型企業(yè)认境、業(yè)務(wù)高速變化發(fā)展的企業(yè)胚委。同時，數(shù)據(jù)湖的用戶也相應(yīng)的要求更高叉信，數(shù)據(jù)科學(xué)家亩冬、業(yè)務(wù)分析師（配合一定的可視化工具）是數(shù)據(jù)湖的目標(biāo)客戶。

總結(jié)

離線架構(gòu)大行其道數(shù)十年硼身，互聯(lián)網(wǎng)數(shù)十年技術(shù)積淀和業(yè)務(wù)發(fā)展對數(shù)據(jù)又提出新要求硅急，實時計算技術(shù)的發(fā)展?jié)M足了人們對數(shù)據(jù)實時性的要求，但未能滿足互聯(lián)網(wǎng)人對低成本高性能的執(zhí)著追逐佳遂，技術(shù)的浪潮一波接一波营袜，如果你錯過了朝陽和高山，請不要錯過了星辰和大海丑罪。

當(dāng)然荚板，對于數(shù)據(jù)湖架構(gòu)的批評也是不絕于耳。有人批評說吩屹，匯集各種雜亂的數(shù)據(jù)跪另，應(yīng)該就是數(shù)據(jù)沼澤。Martin Fowler也對數(shù)據(jù)湖中數(shù)據(jù)的安全性和私密性提出了質(zhì)疑煤搜，歷史見證了每一次新技術(shù)的誕生總是遇到萬般挫折與質(zhì)疑免绿，但是它何曾讓你失望過。