大數(shù)據(jù)時(shí)代:數(shù)據(jù)倉(cāng)庫(kù)搭建之路

Leo
9 評(píng)論 29278 瀏覽 173 收藏 11 分鐘
🔗 产品经理的不可取代的价值是能够准确发现和满足用户需求,把需求转化为产品,并协调资源推动产品落地,创造商业价值。

數(shù)據(jù)倉(cāng)庫(kù)是所有產(chǎn)品的數(shù)據(jù)中心,公司體系下的所有產(chǎn)品產(chǎn)生的所有數(shù)據(jù)最終都流向數(shù)據(jù)倉(cāng)庫(kù),可以說數(shù)據(jù)倉(cāng)庫(kù)不產(chǎn)生數(shù)據(jù),也不消費(fèi)數(shù)據(jù),只是數(shù)據(jù)的搬運(yùn)工。

記得很久以前曾有一位前輩和我說過:“進(jìn)來的數(shù)據(jù)是垃圾數(shù)據(jù),出去也是垃圾數(shù)據(jù)”。

在實(shí)際環(huán)境中,往往我們一條業(yè)務(wù)線會(huì)由多個(gè)不同的系統(tǒng)支撐組成(例如:很多電商后端業(yè)務(wù)線都區(qū)分為庫(kù)存系統(tǒng)、售后系統(tǒng)、采購(gòu)系統(tǒng)、CRM系統(tǒng)等)。這些系統(tǒng)由于本身設(shè)計(jì)的缺陷或業(yè)務(wù)流程變更等問題,所產(chǎn)生的數(shù)據(jù)往往都是有缺失、冗余的,如果直接使用這些數(shù)據(jù)去進(jìn)行數(shù)據(jù)分析,那最后分析出來的結(jié)論多半也不正確。

因此需要有個(gè)數(shù)據(jù)產(chǎn)品來對(duì)數(shù)據(jù)進(jìn)行整合加工,而數(shù)據(jù)倉(cāng)庫(kù)就是這樣一款產(chǎn)品。

要想了解怎么搭建數(shù)據(jù)倉(cāng)庫(kù),首先需要明白數(shù)據(jù)倉(cāng)庫(kù)的作用:

  1. 存儲(chǔ)數(shù)據(jù)
  2. 校準(zhǔn)數(shù)據(jù)
  3. 整合數(shù)據(jù)
  4. 輸出數(shù)據(jù)

基于以上幾點(diǎn),需要將數(shù)據(jù)分層次管理,每一層分工合作,對(duì)數(shù)據(jù)進(jìn)行不同程度的處理,如同工廠里的流水線一般,從而確保數(shù)據(jù)的生命性、生態(tài)性。

大數(shù)據(jù)體系整體架構(gòu)

數(shù)據(jù)倉(cāng)庫(kù)并不是獨(dú)立存在的一個(gè)個(gè)體,而是與整個(gè)大數(shù)據(jù)體系融為一體的——換句話說,數(shù)據(jù)倉(cāng)庫(kù)就像人的心臟,人只有心臟而沒有其他器官是無法單獨(dú)存活下來的。

大數(shù)據(jù)體系架構(gòu)如圖所示:

來源系統(tǒng)

數(shù)據(jù)的來源系統(tǒng),可以理解為數(shù)據(jù)的收集系統(tǒng)。

如圖所示為基于電商業(yè)務(wù)下的大數(shù)據(jù)體系,因此數(shù)據(jù)大體可分為業(yè)務(wù)數(shù)據(jù)和用戶行為數(shù)據(jù),其來源系統(tǒng)更多是與電商業(yè)務(wù)相關(guān)的后端訂單、庫(kù)存等業(yè)務(wù)系統(tǒng)以及前端商城帶來的用戶行為數(shù)據(jù)。

原始數(shù)據(jù)層

顧名思義,即存放從來源系統(tǒng)過來的原始數(shù)據(jù),所謂原始數(shù)據(jù)——即未經(jīng)過任何加工處理的數(shù)據(jù)。

這一層次咋看之下有點(diǎn)多余,但實(shí)際上是有所考量的:

1)將數(shù)據(jù)倉(cāng)庫(kù)與業(yè)務(wù)系統(tǒng)分隔開

數(shù)據(jù)倉(cāng)庫(kù)的數(shù)據(jù),實(shí)時(shí)性要求不高,而準(zhǔn)確性、清潔型必須較高,因此清洗的腳本繁多。如果每條數(shù)據(jù)都實(shí)時(shí)傳送到數(shù)據(jù)倉(cāng)庫(kù)的話,那腳本執(zhí)行的頻率將非常高,所占用的系統(tǒng)資源也隨之增加。

2)分擔(dān)業(yè)務(wù)系統(tǒng)的報(bào)表任務(wù)

總所周知,搭建大數(shù)據(jù)體系架構(gòu)所使用的硬件資源是相對(duì)較高的,而業(yè)務(wù)系統(tǒng)往往只是支撐業(yè)務(wù)持續(xù)開展,從性能上往往無法支撐大數(shù)據(jù)量報(bào)表的導(dǎo)出。因此,原始數(shù)據(jù)層可以承載此項(xiàng)功能,業(yè)務(wù)系統(tǒng)數(shù)據(jù)傳輸?shù)膶?shí)時(shí)性也保證了從原始數(shù)據(jù)層導(dǎo)出的數(shù)據(jù)符合業(yè)務(wù)人員對(duì)報(bào)表實(shí)時(shí)性的需要。

數(shù)據(jù)倉(cāng)庫(kù)

一般來說,數(shù)據(jù)倉(cāng)庫(kù)可區(qū)分為三層:基礎(chǔ)數(shù)據(jù)層、主題層、模型層

基礎(chǔ)數(shù)據(jù)層

原始數(shù)據(jù)層以天為時(shí)間周期,將每天的數(shù)據(jù)傳輸?shù)綌?shù)據(jù)倉(cāng)庫(kù),數(shù)據(jù)倉(cāng)庫(kù)通過ETL(抽取、轉(zhuǎn)化、加載)的方式,將數(shù)據(jù)按照設(shè)定的數(shù)據(jù)表格式存儲(chǔ)好,形成基礎(chǔ)數(shù)據(jù)層的數(shù)據(jù)。

何謂ETL呢?

ETL即:Extra、Transfer、Load——簡(jiǎn)單來說,即數(shù)據(jù)清洗。先將數(shù)據(jù)抽取出來,將冗余數(shù)據(jù),錯(cuò)誤數(shù)據(jù),有歧義的數(shù)據(jù)按照既定的規(guī)則進(jìn)行刪減、填充、修改,再填充入已設(shè)定好的表結(jié)構(gòu)的數(shù)據(jù)庫(kù)表中。

舉個(gè)栗子:

從訂單系統(tǒng)過來的訂單數(shù)據(jù)上,客戶名稱多種多樣,相同一個(gè)客戶,有大寫的名稱、小寫的名稱、有些訂單甚至沒有客戶的相關(guān)信息(這當(dāng)然是業(yè)務(wù)系統(tǒng)本身的歷史遺留問題導(dǎo)致的)。此時(shí),作為數(shù)據(jù)產(chǎn)品經(jīng)理必須要了解這些數(shù)據(jù)的“坑”,并且和對(duì)應(yīng)業(yè)務(wù)系統(tǒng)的產(chǎn)品經(jīng)理共同商討如何處理這批數(shù)據(jù),確定好清洗邏輯(例如:所有名稱統(tǒng)一轉(zhuǎn)化為小寫,如果客戶名稱、地址、電話號(hào)碼都是同一個(gè)的,歸為同一個(gè)客戶),程序猿們根據(jù)數(shù)據(jù)產(chǎn)品經(jīng)理的清洗規(guī)則寫好腳本進(jìn)行清洗。

主題層

數(shù)據(jù)清洗就像打掃衛(wèi)生一樣,將不要的東西扔掉,將破舊的東西擦拭干凈,但并不代表數(shù)據(jù)是完整的。

主題層的構(gòu)建相對(duì)復(fù)雜,搭建的規(guī)則主要是看未來的需要以及產(chǎn)品經(jīng)理對(duì)業(yè)務(wù)的理解。

舉個(gè)栗子:

題主所在的公司是一家大型零售分銷公司,因此往往有一張訂單賣給零售商,零售商再下一張訂單給零售店,零售單再下一張訂單給終端用戶。此時(shí),每一級(jí)訂單是斷層,且來源于不同的系統(tǒng)的,因此每一級(jí)訂單的表結(jié)構(gòu)完全不同。

這樣導(dǎo)致的結(jié)果是:無法從全鏈條上看到每一個(gè)商品在渠道中的流轉(zhuǎn),也無法實(shí)時(shí)跟蹤到每個(gè)商品的具體轉(zhuǎn)化效率。所以,需要把每一級(jí)的訂單按照主題分門別類(一級(jí)訂單、二級(jí)訂單、三級(jí)訂單),并且建立一種關(guān)聯(lián)關(guān)系,使這三者能串聯(lián)起來,形成一整個(gè)渠道流程。

模型層

數(shù)據(jù)來到模型層,也就意味著他們最終要成為“炮彈”,發(fā)射到數(shù)據(jù)分析平臺(tái)了,因此模型層的最主要作用是:將主題數(shù)據(jù)組合成數(shù)據(jù)分析模型。

假設(shè)我們需要在數(shù)據(jù)分析平臺(tái)上體現(xiàn)出“不同商品在不同區(qū)域不同客戶的熱銷情況”,那在模型層就需要以訂單表作為最基礎(chǔ)的表,關(guān)聯(lián)上區(qū)域表、客戶表、商品表,關(guān)聯(lián)出一個(gè)以區(qū)域+商品+客戶特征維度劃分的明細(xì)數(shù)據(jù)。每個(gè)區(qū)域每個(gè)商品每個(gè)客戶對(duì)應(yīng)一行銷售數(shù)據(jù),根據(jù)這份數(shù)據(jù)匯總出一個(gè)按區(qū)域+商品+客戶特征的模型,輸出到數(shù)據(jù)分析平臺(tái),展示出不同區(qū)域,不同商品的客戶特征是怎樣的。

需要注意的是:模型層的數(shù)據(jù)都是呈現(xiàn)出星狀結(jié)構(gòu)和高度索引化的。

因?yàn)樵诖髷?shù)據(jù)平臺(tái)上,數(shù)據(jù)與數(shù)據(jù)之間往往是需要存在關(guān)聯(lián)的,運(yùn)營(yíng)人員看到商品在不同區(qū)域上的銷量分布,往往也想進(jìn)一步看到在不同區(qū)域上的商品有什么特征,客戶有什么特征,這些都需要和區(qū)域強(qiáng)關(guān)聯(lián)起來的。

數(shù)據(jù)應(yīng)用層

數(shù)據(jù)應(yīng)用層嚴(yán)格意義上不屬于大數(shù)據(jù)架構(gòu),因?yàn)樗藭?huì)涉及各式各樣的數(shù)據(jù)分析平臺(tái),還會(huì)涉及到業(yè)務(wù)系統(tǒng)。

數(shù)據(jù)反哺

上文提到過,業(yè)務(wù)系統(tǒng)對(duì)于數(shù)據(jù)倉(cāng)庫(kù)而言更多是作為數(shù)據(jù)收集工具,但同時(shí)業(yè)務(wù)系統(tǒng)也存在著數(shù)據(jù)的需求,我把這樣的過程稱為數(shù)據(jù)反哺。

往往支撐公司業(yè)務(wù)開展下去的業(yè)務(wù)系統(tǒng)不止一個(gè),很可能是有多個(gè),而各式各樣的業(yè)務(wù)系統(tǒng)之間也需要數(shù)據(jù)交互。例如:一般電商公司會(huì)有一套前端商家平臺(tái),也會(huì)一套后端的管理平臺(tái),這兩套平臺(tái)使用的往往不是同一套SKU,因此需要將后端SKU同步到前端來進(jìn)行mapping。

那么為什么不能直接讓這兩套系統(tǒng)直接進(jìn)行數(shù)據(jù)交互呢?

因?yàn)閿?shù)據(jù)已經(jīng)不再干凈,需要數(shù)據(jù)倉(cāng)庫(kù)進(jìn)行清洗過后,將冗余的數(shù)據(jù)去除后方可推送至前端商家平臺(tái)。

分析模型輸出

數(shù)據(jù)倉(cāng)庫(kù)的數(shù)據(jù),最終除了會(huì)流向業(yè)務(wù)系統(tǒng)以外,更多的會(huì)流向各大數(shù)據(jù)應(yīng)用系統(tǒng),即:數(shù)據(jù)大屏,大數(shù)據(jù)分析平臺(tái)等

此時(shí)的數(shù)據(jù),已經(jīng)過層層清洗加工、模型搭建,形成一個(gè)個(gè)炮彈,通過接口的形式推送至各大數(shù)據(jù)平臺(tái)。對(duì)于這些數(shù)據(jù)分析、數(shù)據(jù)展示平臺(tái)而言,更多的只需要考慮如何直觀展示數(shù)據(jù)即可。

總結(jié)

數(shù)據(jù)倉(cāng)庫(kù)不產(chǎn)生數(shù)據(jù),也不消費(fèi)數(shù)據(jù),如果把數(shù)據(jù)比作是水的話,可以將它理解成礦泉水廠商:負(fù)責(zé)將水抽取上來->排污->打包->運(yùn)送。說來容易,做來難,其中辛酸與難度只有數(shù)據(jù)產(chǎn)品經(jīng)理能理解。

 

本文由 @Leo 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載

題圖來自Unsplash,基于CC0協(xié)議

更多精彩內(nèi)容,請(qǐng)關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
評(píng)論
評(píng)論請(qǐng)登錄
  1. 感謝~

    來自北京 回復(fù)
  2. 謝謝分享,思路清晰了很多

    來自廣東 回復(fù)
  3. 直觀解答疑惑了

    來自江蘇 回復(fù)
  4. 感謝樓主,非常有幫助

    來自廣東 回復(fù)
  5. 學(xué)習(xí)了,可以加v學(xué)習(xí)嗎

    來自廣東 回復(fù)
  6. 學(xué)習(xí)了

    來自福建 回復(fù)
  7. 辛苦,謝謝分享,感覺挺有用

    來自北京 回復(fù)
  8. 感謝

    來自陜西 回復(fù)
  9. 先收藏,再細(xì)看。 感謝LEO

    來自福建 回復(fù)
专题
14361人已学习13篇文章
裂变是研究用户增长的重要一环。本专题的文章分享了如何做裂变活动。
专题
55155人已学习12篇文章
据说70%的问题都是沟通问题,沟通能力对产品经理太太太重要了。
专题
17391人已学习14篇文章
MVP是指开发团队通过提供最小化可行产品获取用户反馈,并在这个最小化可行产品上持续快速迭代,直到产品到达一个相对稳定的阶段。本专题的文章分享了如何做MVP产品。
专题
14333人已学习13篇文章
作为一名运营,需要持续对自己的经验进行总结并不断更新迭代。本专题的文章分享了运营方法论。
专题
11583人已学习12篇文章
任何理论都有它的局限性和前提条件,没有一种方法论是永远有效的。品牌方法论一直处在变化阶段,它随着时代发展的变化而变化。本专题的文章分享了品牌方法论。
专题
14929人已学习12篇文章
自传播是基于一个事件、一个产品或者营销活动自身的吸引力,激发人们自愿转发分享。本专题的文章分享了如何让产品具有自传播性。