本文由作者?董小礦?于社區(qū)發(fā)布

前言：有幸深度參與了公司從無數(shù)據(jù)，到有數(shù)據(jù)，到開始重視數(shù)據(jù)，最后能夠尊重?cái)?shù)據(jù)結(jié)果，參考數(shù)據(jù)進(jìn)行決策的過程。本篇文章是筆者在這個(gè)過程中，作為數(shù)據(jù)產(chǎn)品搭建數(shù)據(jù)指標(biāo)體系，如何踩坑、出坑，以及對數(shù)據(jù)倉庫建設(shè)中的一些總結(jié)。

如標(biāo)題所言，如果貴司已經(jīng)是B輪之后，數(shù)據(jù)指標(biāo)和平臺化產(chǎn)品應(yīng)該已經(jīng)比較健全，屬于數(shù)據(jù)產(chǎn)品應(yīng)用階段。如果貴司處于B輪及B輪之前階段，大概率上會出現(xiàn)筆者下面所描述的情況。

本文較長，目錄如下：

1 混亂期：資源有限，功能為先，忽視數(shù)據(jù)

1.1?資源永遠(yuǎn)不夠用

1.2?數(shù)據(jù)產(chǎn)品的窘境

2 規(guī)范期：他山之石：GrowingIO和神策

2.1?GrowingIO平臺實(shí)踐總結(jié)

2.2?神策平臺實(shí)踐總結(jié)

2.3?他山之石后的埋點(diǎn)設(shè)計(jì)及管理

3 平臺期：建設(shè)數(shù)據(jù)倉庫

3.1?數(shù)據(jù)維護(hù)及治理

3.2?數(shù)據(jù)倉庫架構(gòu)設(shè)計(jì)

4 未來：數(shù)據(jù)中臺？

4.1?我理解的數(shù)據(jù)中臺

4.2?數(shù)據(jù)中臺學(xué)習(xí)資料推薦

------正文分割線------

1

混亂期：資源有限，功能為先，忽視數(shù)據(jù)

1.1 資源永遠(yuǎn)不夠用

筆者所在的內(nèi)容服務(wù)公司，在搭建指標(biāo)體系前，已經(jīng)“裸奔”了3年。對于內(nèi)容產(chǎn)品來說，最影響用戶體驗(yàn)的是內(nèi)容本身，公司前期依靠不錯(cuò)的內(nèi)容口碑，搭上知識付費(fèi)的風(fēng)口，發(fā)展迅速，公司資源和業(yè)務(wù)方向更多是受運(yùn)營驅(qū)動、銷售驅(qū)動，目標(biāo)簡單而明確，做什么心里都有大致預(yù)判，輕輕拍拍腦袋，這事兒就定了。后來平臺用戶數(shù)達(dá)到第一個(gè)1000w，日活進(jìn)入50w量級后，新人加入，業(yè)務(wù)線也在拓展，基于主線業(yè)務(wù)上的優(yōu)化和探索，不敢再輕易拍腦袋了；各業(yè)務(wù)線也有不同的訴求，如何評判優(yōu)先級和協(xié)調(diào)資源，沒有數(shù)據(jù)，很容易僵持不下。

也是在那個(gè)時(shí)候，決定要參考數(shù)據(jù)來決策了。之前APP偏向于做功能，只在特殊功能點(diǎn)，或活動節(jié)點(diǎn)時(shí)，會在產(chǎn)品需求文檔中，附上埋點(diǎn)需求。彼時(shí)突然想看很多數(shù)據(jù)，會發(fā)現(xiàn)除了一些大數(shù)據(jù)（日活、激活率、付費(fèi)率等）外，缺少很多細(xì)部數(shù)據(jù)，因?yàn)閴焊鶝]有做埋點(diǎn)上報(bào)的需求，從日志中也無法解析出相關(guān)數(shù)據(jù)。

后來在每個(gè)版本中，由功能產(chǎn)品經(jīng)理附上相關(guān)功能的埋點(diǎn)需求，大部分開發(fā)資源還在具體功能開發(fā)上。在功能上線后很久，才會想起來撈數(shù)據(jù)看看效果。初創(chuàng)公司很容易在業(yè)務(wù)快速擴(kuò)張中忽視數(shù)據(jù)的作用，產(chǎn)品開發(fā)團(tuán)隊(duì)首要解決的是不斷新增的業(yè)務(wù)需求。資源總是不夠用的，所以數(shù)據(jù)埋點(diǎn)處理、數(shù)據(jù)分析、復(fù)盤等工作一直處在被忽視的地方。

1.2?數(shù)據(jù)產(chǎn)品的窘境

彼時(shí)我轉(zhuǎn)崗到數(shù)據(jù)產(chǎn)品，常自嘲自己是一個(gè)取數(shù)機(jī)器。公司有數(shù)據(jù)需求的部門共有7個(gè)，我負(fù)責(zé)對接各部門的數(shù)據(jù)需求，梳理清晰后再提交任務(wù)給大數(shù)據(jù)組，由他們做具體的ETL工作。這中間，常會陷入到以下的汪洋大海中：

與需求方溝通并最后明確最后的數(shù)據(jù)需求（比如：活動組提需求想看某活動頁分享數(shù)據(jù)，經(jīng)溝通之后，其目的是想看新頁面的文案上線后，對分享/瀏覽比的影響，因此明確了該需求是該頁面的uv、pv，以及分享控件點(diǎn)擊的人數(shù)、次數(shù)）；

提交明確需求后，大數(shù)據(jù)組發(fā)現(xiàn)之前沒有埋點(diǎn)，然后需要跟需求方解釋，這個(gè)數(shù)據(jù)為什么拿不到，從ta的分析目標(biāo)再看看，是否還有其他數(shù)據(jù)也能夠達(dá)成這個(gè)分析目標(biāo)。

那段時(shí)間非常忙碌，但總感覺自己是個(gè)二傳手，最大的收獲，就是在對接了N個(gè)需求之后，發(fā)現(xiàn)我司的數(shù)據(jù)基礎(chǔ)建設(shè)情況慘不忍睹：平臺埋點(diǎn)不規(guī)范、數(shù)據(jù)指標(biāo)定義不統(tǒng)一、業(yè)務(wù)數(shù)據(jù)庫和數(shù)據(jù)倉庫標(biāo)準(zhǔn)不統(tǒng)一、數(shù)據(jù)需求處理周期長……?我的精力很多耗在溝通需求、管理需求上。后來與公司的數(shù)據(jù)分析部門一同討論制定了一套新的數(shù)據(jù)提交流程：每個(gè)部門的需求匯總到部門中的一個(gè)數(shù)據(jù)對接人，由ta先行提交到數(shù)據(jù)分析組，簡單需求，會由數(shù)據(jù)分析組通過DBeaver等工具，連接數(shù)據(jù)庫導(dǎo)出，復(fù)雜類、工具類需求，則提交給我：

圖1：數(shù)據(jù)需求提交流程

另外，針對每個(gè)部門的數(shù)據(jù)對接人進(jìn)行了指標(biāo)定義的說明，以及提交數(shù)據(jù)需求的規(guī)范標(biāo)準(zhǔn)的培訓(xùn)：

圖2：培訓(xùn)資料一頁：什么是好的數(shù)據(jù)需求

此時(shí)的工作還停留在偏臨時(shí)需求的處理上，作為數(shù)據(jù)產(chǎn)品，卻沒有做出多少數(shù)據(jù)產(chǎn)品出來。

2

規(guī)范期：他山之石：GrowingIO和神策

在決定搭建數(shù)據(jù)體系后，我司接洽了幾家頭部的數(shù)據(jù)平臺，如GIO、ThinkingData、神策等，來補(bǔ)充我司埋點(diǎn)功底薄弱的問題，最后選擇了GIO，在使用了一年多之后，因?yàn)橐鏊接谢渴?#xff0c;而GIO的私有化部署功能還剛處在開發(fā)階段（寫這篇文章的時(shí)候，他們的私有化部署已經(jīng)做出來了），于是我司又決定換神策平臺，重新來一遍POC和SDK接入工作（對，就是這么折騰，o(╥﹏╥)o）。

在完整地對接了這兩家平臺之后，我司數(shù)據(jù)體系逐步走向規(guī)范，我也總結(jié)了一下兩家平臺關(guān)于指標(biāo)管理、數(shù)據(jù)體系搭建的工具特點(diǎn)，以及思路進(jìn)行了一些總結(jié)，如下。

2.1?GrowingIO平臺實(shí)踐總結(jié)

在接觸了幾家平臺后，我們最終選擇了GIO，該平臺的特點(diǎn)非常明顯：

1、擁有無埋點(diǎn)技術(shù)，能夠?qū)崿F(xiàn)做功能時(shí)，不需要專門針對埋點(diǎn)花費(fèi)工時(shí)，接入GIO的SDK，在功能上線后，SDK能夠采集基礎(chǔ)使用信息，同時(shí)，針對頁面瀏覽數(shù)據(jù)，和頁面控件點(diǎn)擊數(shù)據(jù)，可以通過“圈選”的方式實(shí)現(xiàn)（對于彼時(shí)苦于埋點(diǎn)效率低下的現(xiàn)狀，這種方案極具誘惑）；

2、公有云部署，接入成本低；

3、后臺操作界面簡潔，屬于運(yùn)營思路的一款產(chǎn)品，上手較容易；

4、因?yàn)槭荢aaS服務(wù)，線上問題反饋速度比較快。

但后來發(fā)現(xiàn)一些問題：接入SDK后，我們只簡單對接了會員狀態(tài)數(shù)據(jù)，做了少量的埋點(diǎn)指標(biāo)，除此外手動圈選了大量頁面指標(biāo)和控件數(shù)據(jù)，因?yàn)镚IO的圈選功能實(shí)在太好用了，所見即所得，不必再發(fā)版等埋點(diǎn)上線，經(jīng)過簡單操作后就可以自己取數(shù)、看數(shù)，結(jié)合GIO提供的基礎(chǔ)分析工具，如事件分析、漏斗分析、留存分析等功能，人人都能成為一名分析師了。

圖3：GIO圈選功能

但到后期，圈選數(shù)據(jù)的問題逐漸暴露，也成為平臺要更換GIO平臺的導(dǎo)火索。圈選數(shù)據(jù)的邏輯：是根據(jù)頁面xpath路徑，監(jiān)聽頁面瀏覽事件，和頁面上的控件的瀏覽、點(diǎn)擊事件，保留7天，因此圈選完成后，能往前追溯7天的數(shù)據(jù)。圈選功能的問題主要在于：

1、耗流量，看下邏輯你應(yīng)該能理解；

2、一旦版本迭代，對頁面的路徑做修改，或者控件位置、文案有修改，原來的圈選數(shù)據(jù)可能就會出錯(cuò)，需要重新圈選，之前利用圈選指標(biāo)設(shè)定的分析模型都要替換；

3、圈選指標(biāo)無法區(qū)分細(xì)部參數(shù)，比如：書籍詳情頁，無法通過圈選數(shù)據(jù)來區(qū)分是哪一本書；

4、對web的頁面數(shù)據(jù)處理一直不好，尤其是涉及到APP的內(nèi)嵌H5頁時(shí)，非常痛苦。

圖4：版本升級后，某圈選指標(biāo)數(shù)據(jù)突降

這其實(shí)也是GIO的業(yè)務(wù)同事比較推崇無埋點(diǎn)技術(shù)，而我司彼時(shí)經(jīng)驗(yàn)尚不充足踩下的坑，到后半階段開始補(bǔ)課，開始做客戶端和服務(wù)端埋點(diǎn)了，埋點(diǎn)開發(fā)周期雖然長了點(diǎn)，但是至少能夠用得起來。但是因?yàn)橹皩IO工具使用上產(chǎn)生的各種不爽，導(dǎo)致后面有了更準(zhǔn)確的埋點(diǎn)后，大家用起來也常常懷疑，這數(shù)據(jù)準(zhǔn)不準(zhǔn)，能不能用？

一旦對數(shù)據(jù)源產(chǎn)生不信任感，產(chǎn)研團(tuán)隊(duì)的解釋成本高，數(shù)據(jù)發(fā)揮價(jià)值的周期變長，團(tuán)隊(duì)屢受質(zhì)疑又看不到成績，大數(shù)據(jù)團(tuán)隊(duì)本身在數(shù)據(jù)體系建設(shè)的早期存在感就低，如此一來，工作積極性變得更低。

后來受資方等多因素影響，我們需要做私有化部署，對數(shù)據(jù)的準(zhǔn)確度、智能運(yùn)營也有更進(jìn)一步的需求，而彼時(shí)GIO還沒有成熟的私有化部署功能，因此我們兩家后來好聚好散，轉(zhuǎn)而選擇了神策。（此處抱著GIO的同學(xué)哭一會兒）

但總體來說，GIO平臺還是可圈可點(diǎn)，它的優(yōu)勢在于：

1、數(shù)據(jù)響應(yīng)速度快，圈選功能比較成熟，對于快速迭代活動的場景，圈選功能最為便捷；

2、用戶操作界面友好，幾大核心分析功能邏輯結(jié)構(gòu)清晰，學(xué)習(xí)成本低，能夠?qū)崿F(xiàn)在公司大范圍推廣使用（你千萬別覺得這類數(shù)據(jù)工具是可以輕易上手的，根據(jù)我在公司推廣GIO和神策的經(jīng)驗(yàn)，工具使用門檻并不低）；

3、售后團(tuán)隊(duì)比較專業(yè)，能夠從分析視角，發(fā)現(xiàn)我司業(yè)務(wù)上的問題；并且對平時(shí)提到的問題，反饋及時(shí)，問題解決程度也比較高。

2.2?神策平臺實(shí)踐總結(jié)

后來因?yàn)樗接谢渴鸬脑V求，選擇了神策平臺的產(chǎn)品。這里解釋下，為啥沒有選擇自己研發(fā)數(shù)據(jù)產(chǎn)品。這其實(shí)是一個(gè)很經(jīng)濟(jì)學(xué)的考量。在接入GIO前，我司有自己一套u(yù)bt的埋點(diǎn)系統(tǒng)，但是只是基礎(chǔ)的數(shù)據(jù)采集，以及raw data進(jìn)數(shù)據(jù)庫，從raw data 到數(shù)倉，再到提取，把統(tǒng)計(jì)類數(shù)據(jù)以excel形式，或者教會分析人員使用SSMS或PowerBI來進(jìn)行取數(shù)分析，中間流程太長，無法做到快速響應(yīng)及反饋。而找一個(gè)團(tuán)隊(duì)自研，時(shí)間成本和人力成本都太高。

神策、GIO這樣的平臺，取數(shù)功能完整度比較高，而且有一個(gè)比較完整的可視化分析平臺，包含了事件分析、漏斗分析、留存分析等基礎(chǔ)的分析功能，也有歸因分析模型、用戶畫像等功能，這些功能找一個(gè)大數(shù)據(jù)團(tuán)隊(duì)和幾個(gè)算法工程師，一年的成本高了去了。對于B輪左右的公司，建議別折騰，花點(diǎn)錢，除了避免自研成本，還能從這些SaaS平臺的服務(wù)中，了解到比較成熟的方法論。

神策的分析全家桶有以下幾款產(chǎn)品：

圖5：神策產(chǎn)品矩陣

其中，左邊【數(shù)據(jù)基礎(chǔ)能力】是基礎(chǔ)服務(wù)，可以選Pass，也可以選私有化部署，但是節(jié)點(diǎn)費(fèi)、流量費(fèi)是根據(jù)自己的流量來核算。（市政單位，或者對業(yè)務(wù)數(shù)據(jù)安全敏感度高的，建議私有化。不是說Pass不安全，像神策、GIO這樣專門做數(shù)據(jù)服務(wù)的平臺，不至于去泄露客戶數(shù)據(jù)，一個(gè)客戶數(shù)據(jù)泄露事件就可以讓這類企業(yè)直接掛掉，這個(gè)賬他們拎得清，而且有數(shù)據(jù)隱私協(xié)議）

右邊的【數(shù)據(jù)應(yīng)用產(chǎn)品】則是可選項(xiàng)了，【神策分析】包含了事件分析、漏斗分析等基礎(chǔ)的分析功能，一般必不可少；【神策用戶畫像】和【智能運(yùn)營】是偏向于運(yùn)營側(cè)的工具，如果自己沒有精準(zhǔn)營銷的產(chǎn)研能力，這兩項(xiàng)服務(wù)業(yè)比較好用。至于【智能推薦】和【神策客景】則根據(jù)公司情況，對于內(nèi)容龐雜，品類繁多的內(nèi)容平臺、電商平臺，還是比較有必要。但我個(gè)人認(rèn)為，前三項(xiàng)服務(wù)玩得轉(zhuǎn)了，再去考慮采購后兩項(xiàng)服務(wù)不遲。

神策平臺的特點(diǎn)是一開始推的是埋點(diǎn)方案，而非無埋點(diǎn)方案；而且最早支持私有化部署的數(shù)據(jù)服務(wù)平臺。這一點(diǎn)是讓他們能夠獲得一些金融行業(yè)、政企行業(yè)的單子的原因。這也是我們最后評估后，選擇他們的原因。

2.3?我司平臺的埋點(diǎn)設(shè)計(jì)及指標(biāo)管理

在經(jīng)過了UBT、GIO和神策三套埋點(diǎn)方案的使用和比較后，對于我司自己的埋點(diǎn)系統(tǒng)也有了比較清晰的方向，最后決定采用常規(guī)數(shù)據(jù)使用前端埋點(diǎn)、關(guān)鍵數(shù)據(jù)使用服務(wù)端埋點(diǎn)、臨時(shí)活動搭配使用全埋點(diǎn)的方案。

全埋點(diǎn)、前端埋點(diǎn)和服務(wù)端埋點(diǎn)的區(qū)別

而我司基本是前端埋點(diǎn)和服務(wù)端埋點(diǎn)的組合，其中關(guān)于數(shù)據(jù)指標(biāo)的設(shè)計(jì)和管理，采用了下圖所展示的字段名，對事實(shí)表進(jìn)行管理和維護(hù)。

圖6：我司數(shù)據(jù)指標(biāo)維護(hù)表頭

關(guān)于數(shù)據(jù)指標(biāo)管理，最讓我頭大的就是如何保證可讀性的前提下，梳理不斷新增的數(shù)據(jù)埋點(diǎn)需求。我的設(shè)計(jì)思路是：以使用者視角設(shè)計(jì)，盡可能合并同類型指標(biāo)，用維度保證擴(kuò)展性，用備注內(nèi)容保證可讀性。

上面的指標(biāo)維護(hù)表，是要同時(shí)給開發(fā)人員，和運(yùn)營人員看的，這里指的使用者，是指運(yùn)營人員。因?yàn)樽詈舐顸c(diǎn)設(shè)計(jì)做完了，也正常上報(bào)了，但是運(yùn)營人員看不懂，用不起來，培訓(xùn)成本高企，是無法充分發(fā)揮數(shù)據(jù)價(jià)值的。所以在這里就需要數(shù)據(jù)產(chǎn)品經(jīng)理平衡簡約和可用性。

舉兩個(gè)例子：

例子1：平臺資源位埋點(diǎn)設(shè)計(jì)

對于一般互聯(lián)網(wǎng)產(chǎn)品平臺來說，資源位無外乎兩種類型，彈出型和輪播型；而具體指標(biāo)無外乎瀏覽和點(diǎn)擊，因此，將這兩種類型的資源位抽象成下面4個(gè)指標(biāo)，由維度（資源位位置、輪播位置）來進(jìn)行拆分。

圖7：平臺資源位埋點(diǎn)設(shè)計(jì)

例子2：內(nèi)容詳情頁埋點(diǎn)設(shè)計(jì)

對于內(nèi)容類、電商類平臺來說，內(nèi)容詳情頁和商品詳情頁是最為關(guān)鍵的頁面，因此這個(gè)頁面的瀏覽數(shù)據(jù)極為重要。因?yàn)樵斍轫撌且粋€(gè)通用頁面，而且對于一篇文章，或者一個(gè)商品來說，可能會在APP出現(xiàn)多個(gè)入口，如果對N個(gè)入口進(jìn)行分別埋點(diǎn)，會讓指標(biāo)建設(shè)冗余，并且因?yàn)榫W(wǎng)絡(luò)環(huán)境等影響，點(diǎn)擊數(shù)≠頁面加載≠頁面加載成功，可能會采到臟數(shù)據(jù)上來。因此我在這里的設(shè)計(jì)思路是：以頁面加載成功為觸發(fā)，區(qū)分頁面本身的數(shù)據(jù)信息，以及上一個(gè)頁面的維度信息。

圖8：內(nèi)容詳情頁埋點(diǎn)設(shè)計(jì)

這里的挑戰(zhàn)來自于去梳理上一個(gè)頁面的類型和具體參數(shù)值，需要與運(yùn)營組、數(shù)據(jù)組同事溝通清楚，他們關(guān)心的維度，以及下鉆的顆粒度。

?

3

平臺期：建設(shè)數(shù)據(jù)倉庫

建設(shè)數(shù)據(jù)倉庫是一個(gè)必然的選擇，在業(yè)務(wù)體量不大，數(shù)據(jù)需求不多的情況下，從業(yè)務(wù)數(shù)據(jù)庫撈數(shù)據(jù)，甚至解析日志，都是能夠滿足的。但后期必然會有更多維度、更復(fù)雜的分析型、報(bào)表型數(shù)據(jù)需求，全部依靠業(yè)務(wù)數(shù)據(jù)庫顯然不現(xiàn)實(shí)。現(xiàn)在計(jì)算機(jī)存儲成本不高，數(shù)據(jù)倉庫可以看做是一個(gè)【用空間換時(shí)間】的方案，數(shù)據(jù)倉庫是面向分析、應(yīng)用的數(shù)據(jù)庫，在建立好標(biāo)準(zhǔn)的ETL流程和更新機(jī)制后，分析型、報(bào)表型數(shù)據(jù)需求從數(shù)據(jù)倉庫中獲取，從而提高效率，也解放業(yè)務(wù)數(shù)據(jù)庫，讓業(yè)務(wù)庫專心處理業(yè)務(wù)。

目前有關(guān)數(shù)據(jù)倉庫的文章非常多，對數(shù)據(jù)倉庫應(yīng)該分幾層，也有很多說法。這里需要明確一點(diǎn)，數(shù)據(jù)倉庫的分層是一個(gè)理念，其核心是將不同應(yīng)用層級的數(shù)據(jù)進(jìn)行劃分。一般來說至少有三級，我司采用的也是三級數(shù)倉。

3.1?數(shù)據(jù)維護(hù)及治理

基于Hadoop的成熟體系，搭建完成數(shù)倉系框架后，接下來要做的是往數(shù)倉中填充數(shù)據(jù)“血肉”，以及持續(xù)進(jìn)行數(shù)據(jù)治理的工作了。在用數(shù)據(jù)賦能業(yè)務(wù)的鏈條中：產(chǎn)生數(shù)據(jù)（埋點(diǎn)）-> 獲取數(shù)據(jù)(ETL) ->?分析數(shù)據(jù) ->?發(fā)現(xiàn)問題 ->業(yè)務(wù)決策，似乎并沒有數(shù)據(jù)治理的事情。

鏈條上的四點(diǎn)是可見的過程，而數(shù)據(jù)本身產(chǎn)生污染后，可能會到獲取時(shí)、分析時(shí)，甚至是決策階段，才會意識到數(shù)據(jù)本身可能出現(xiàn)了問題。數(shù)據(jù)從觸發(fā)上報(bào)->?發(fā)送-> ETL->?進(jìn)數(shù)倉，中間有任何一個(gè)過程出問題，都可能會影響數(shù)據(jù)的穩(wěn)定、準(zhǔn)確和及時(shí)。另外，不斷擴(kuò)展的業(yè)務(wù)需求，業(yè)務(wù)數(shù)據(jù)字段會發(fā)生變更，這時(shí)錯(cuò)傳、漏傳了數(shù)據(jù)進(jìn)數(shù)倉，也會影響數(shù)據(jù)質(zhì)量。

總結(jié)下來，基于下面三個(gè)點(diǎn)，需要持續(xù)進(jìn)行數(shù)據(jù)維護(hù)和治理：

1.數(shù)據(jù)進(jìn)倉鏈路長，存在出現(xiàn)臟數(shù)據(jù)的風(fēng)險(xiǎn)；

2.新業(yè)務(wù)需求增刪改字段，沒有及時(shí)同步進(jìn)數(shù)倉；

3.數(shù)倉表結(jié)構(gòu)字段設(shè)計(jì)擴(kuò)展性不足，新數(shù)據(jù)需要單獨(dú)建表，導(dǎo)致冗余。

針對第1點(diǎn)，我司對于數(shù)據(jù)指標(biāo)本身的異常波動做了監(jiān)控的設(shè)計(jì)。在接入了神策平臺之后，該平臺提供了一個(gè)指標(biāo)異常波動提醒的功能，還挺好用。

圖9：神策數(shù)據(jù)異常監(jiān)控

針對第2點(diǎn)說說我司實(shí)踐。我司通過搭建【異構(gòu)數(shù)據(jù)平臺】來解決業(yè)務(wù)數(shù)據(jù)同步到數(shù)據(jù)倉庫的問題。業(yè)務(wù)數(shù)據(jù)在進(jìn)數(shù)據(jù)倉的同時(shí)，會按照約定的規(guī)范，同步傳送一份到數(shù)據(jù)倉庫；如果有修業(yè)務(wù)數(shù)據(jù)的情況，也需要異步地通過該平臺，發(fā)消息給數(shù)據(jù)倉庫，由數(shù)倉消費(fèi)后，更新數(shù)倉的數(shù)據(jù)。

針對第3點(diǎn)，沒有什么好辦法，需要數(shù)據(jù)產(chǎn)品和大數(shù)據(jù)組、業(yè)務(wù)產(chǎn)品經(jīng)理多溝通，對于數(shù)倉目前有哪些表，哪些字段，功能規(guī)劃上，未來會新增哪些產(chǎn)品線，與當(dāng)前業(yè)務(wù)線的關(guān)系，有一個(gè)大致預(yù)判，最大程度減少重復(fù)建表的工作。

3.2?數(shù)據(jù)倉庫架構(gòu)設(shè)計(jì)

基于以上，我司數(shù)據(jù)倉庫是基于Hadoop框架，Hive處理離線數(shù)據(jù)，Flink處理實(shí)時(shí)數(shù)據(jù)，實(shí)現(xiàn)用戶行為數(shù)據(jù)和業(yè)務(wù)數(shù)據(jù)準(zhǔn)實(shí)時(shí)入數(shù)倉（有一些延時(shí)），并且前端數(shù)據(jù)產(chǎn)品應(yīng)用，從數(shù)據(jù)倉庫中調(diào)接口取數(shù)。（目前還沒有完全實(shí)現(xiàn)所有業(yè)務(wù)數(shù)據(jù)都從數(shù)據(jù)倉庫走，還在建設(shè)中）

圖10：數(shù)據(jù)倉庫架構(gòu)設(shè)計(jì)

4

未來：數(shù)據(jù)中臺？

數(shù)據(jù)中臺概念在19年實(shí)在太火了，頗有些12年，到處都在說O2O的情形。對于數(shù)據(jù)產(chǎn)品來說，將產(chǎn)出的數(shù)據(jù)產(chǎn)品抽象化、共用化，成為像中臺一樣的基礎(chǔ)服務(wù)能力是心之所向。但是否應(yīng)該盲目上中臺項(xiàng)目，談?wù)勎业睦斫狻?br />

4.1?我所理解的數(shù)據(jù)中臺

我很喜歡【中臺】這個(gè)詞：處于中間，承上啟下；成為平臺，隔絕上下流動，但自身提供服務(wù)上下的能力。對于數(shù)據(jù)中臺，其核心是提煉各業(yè)務(wù)線的共性需求，將這些需求解決方案封裝為標(biāo)準(zhǔn)化、組件化的解決能力，然后以接口的形式提供給前前臺業(yè)務(wù)數(shù)據(jù)。從而實(shí)現(xiàn)盡量少地重復(fù)造輪子，盡量多地提高研發(fā)的敏捷性。

不是所有公司都需要立刻做中臺，但根據(jù)熵增定律，一家能持續(xù)發(fā)展的企業(yè)，其業(yè)務(wù)形態(tài)一定會不斷發(fā)展和膨脹，而當(dāng)新業(yè)務(wù)線和老業(yè)務(wù)線有共性訴求，能夠通過中臺化來提高效率，并且具有能串聯(lián)多業(yè)務(wù)線的項(xiàng)目能力，這些問題想清楚，就可以開始做中臺項(xiàng)目了。

------正文分割線------

那么，如何才能快速低成本搭建自己的數(shù)據(jù)體系呢？

快來「云隊(duì)友」招個(gè)靠譜的兼職數(shù)據(jù)分析師吧！

總結(jié)

以上是生活随笔為你收集整理的埋点、数仓到中台：数据体系的从0到1的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。