資訊專欄INFORMATION COLUMN
摘要：近兩年，為什么都開始談?wù)撈疬@個新名詞了先說我的想法，其實還是用戶需求驅(qū)動數(shù)據(jù)服務(wù)，大家開始關(guān)注的根本原因是用戶需求發(fā)生了質(zhì)變，過去的數(shù)據(jù)倉庫模式以及涉及到的相關(guān)組件沒有辦法滿足日益進(jìn)步的用戶需求。
近兩年，為什么都開始談?wù)撈?Data Lake 這個”新名詞”了？
先說我的想法，其實還是用戶需求驅(qū)動數(shù)據(jù)服務(wù)，大家開始關(guān)注 Data Lake 的根本原因是用戶需求發(fā)生了質(zhì)變，過去的數(shù)據(jù)倉庫模式以及涉及到的相關(guān)組件沒有辦法滿足日益進(jìn)步的用戶需求。
趨勢
這里聊一個很重要的趨勢：
數(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)1
數(shù)據(jù)實時化沒問題，但是對應(yīng)到技術(shù)上是什么情況呢？是不是我們要在實時領(lǐng)域也搭一套類似離線數(shù)據(jù)倉庫的數(shù)據(jù)體系和模式？
是的，很多公司確實是將實時數(shù)據(jù)流劃分為了不同層級，整體層級的劃分思路和離線倉庫類似，但是實時數(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)2
實時系統(tǒng)的成本太大了，這也是讓很多公司對實時需求望而生畏的原因之一。所以這樣去建設(shè)實時數(shù)倉的思路肯定不行啊，等于我要招兩倍的人才（可能還不止），花兩倍的時間，才能做一個讓我的業(yè)務(wù)可能只提升 10% 的功能。從技術(shù)的角度來看，是這兩套系統(tǒng)的技術(shù)棧不一樣造成了工程無法統(tǒng)一。那么，Data Lake 就是用來解決這樣一個問題，比如我一個離線任務(wù)，能不能既產(chǎn)生實時指標(biāo)，也產(chǎn)生離線指標(biāo)，類似下圖這樣：
除了計算層面上，在數(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)1】 的階段，相信隨著大家的努力，很快就會出現(xiàn)優(yōu)秀且成功的實踐。
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/125909.html
摘要：數(shù)據(jù)湖通常更大，其存儲成本也更為廉價。高存儲成本數(shù)倉和數(shù)據(jù)湖都是為了降低數(shù)據(jù)存儲的成本。數(shù)據(jù)停滯在數(shù)據(jù)湖中，數(shù)據(jù)停滯是一個最為嚴(yán)重的問題，如果數(shù)據(jù)一直無人治理，那將很快變?yōu)閿?shù)據(jù)沼澤。數(shù)據(jù)湖（Data Lake)，湖倉一體（Data Lakehouse）儼然已經(jīng)成為了大數(shù)據(jù)領(lǐng)域最為火熱的流行詞，在接受這些流行詞洗禮的時候，身為技術(shù)人員我們往往會發(fā)出這樣的疑問，這是一種新的技術(shù)嗎，還是僅僅只是概...
1、數(shù)據(jù)結(jié)構(gòu)：數(shù)據(jù)倉庫只能存儲經(jīng)過處理和提煉的數(shù)據(jù)，而數(shù)據(jù)湖存儲尚未出于某種目的處理的原始數(shù)據(jù)。因此，數(shù)據(jù)湖需要比數(shù)據(jù)倉庫大得多的存儲容量，且數(shù)據(jù)靈活、分析迅速，非常適合機器學(xué)習(xí)。2、加工：數(shù)據(jù)倉庫使用寫入時序模式的方法來處理數(shù)據(jù)以賦予其形狀和結(jié)構(gòu)，而數(shù)據(jù)湖對原始數(shù)據(jù)使用讀取模式來處理它。3、成本：存儲在數(shù)據(jù)倉庫中的成本可能很高，尤其是在有大量數(shù)據(jù)的情況下，而數(shù)據(jù)湖是專為低成本數(shù)據(jù)存儲而設(shè)計，成本...
摘要：今天就我和大家來談?wù)劥髷?shù)據(jù)領(lǐng)域的一些新變化新趨勢。結(jié)語以上四個方面是數(shù)據(jù)科學(xué)在實踐發(fā)展中提出的新需求，誰能在這些方面得到好的成績，誰便會在這個大數(shù)據(jù)時代取得領(lǐng)先的位置。 從2012年開始，幾乎人人（至少是互聯(lián)網(wǎng)界）言必稱大數(shù)據(jù)，似乎不和大數(shù)據(jù)沾點邊都不好意思和別人聊天。從2016年開始，大數(shù)據(jù)系統(tǒng)逐步開始在企業(yè)中進(jìn)入部署階段，大數(shù)據(jù)的炒作逐漸散去，隨之而來的是應(yīng)用的蓬勃發(fā)展期，一些代表...
摘要：今天就我和大家來談?wù)劥髷?shù)據(jù)領(lǐng)域的一些新變化新趨勢。結(jié)語以上四個方面是數(shù)據(jù)科學(xué)在實踐發(fā)展中提出的新需求，誰能在這些方面得到好的成績，誰便會在這個大數(shù)據(jù)時代取得領(lǐng)先的位置。 從2012年開始，幾乎人人（至少是互聯(lián)網(wǎng)界）言必稱大數(shù)據(jù)，似乎不和大數(shù)據(jù)沾點邊都不好意思和別人聊天。從2016年開始，大數(shù)據(jù)系統(tǒng)逐步開始在企業(yè)中進(jìn)入部署階段，大數(shù)據(jù)的炒作逐漸散去，隨之而來的是應(yīng)用的蓬勃發(fā)展期，一些代表...
閱讀 3546·2023-04-25 20:09
閱讀 3745·2022-06-28 19:00
閱讀 3066·2022-06-28 19:00
閱讀 3092·2022-06-28 19:00
閱讀 3185·2022-06-28 19:00
閱讀 2886·2022-06-28 19:00
閱讀 3057·2022-06-28 19:00
閱讀 2643·2022-06-28 19:00
