數(shù)據(jù)管理 | 數(shù)據(jù)規(guī)劃真的可行嗎

1 評論 3281 瀏覽 5 收藏 10 分鐘

通常來講,數(shù)據(jù)規(guī)劃可能包括兩個層面的規(guī)劃,一個是表層面的規(guī)劃,一個是字段層面的規(guī)劃。那么對于元數(shù)據(jù),我們可以規(guī)劃些什么?數(shù)據(jù)規(guī)劃是否可行呢?這篇文章里,作者談了談他的看法,一起來看一下。

元數(shù)據(jù)是大數(shù)據(jù)平臺的一個基礎(chǔ),大數(shù)據(jù)平臺是以元數(shù)據(jù)為中心進行構(gòu)建的。一個大數(shù)據(jù)平臺能夠把元數(shù)據(jù)管理好,那么這個平臺就成功了一半。那么對于元數(shù)據(jù)我們能夠規(guī)劃些什么,是否可行?

一、數(shù)據(jù)規(guī)劃的時候都規(guī)劃什么

數(shù)據(jù)的規(guī)劃都規(guī)劃些什么,具體來分的話大概包括兩個層面的規(guī)劃,一個是表層面的,一個是字段層面的。

二、表層面的規(guī)劃

表層面的規(guī)劃涉及到數(shù)據(jù)倉庫設(shè)計了。會包括了數(shù)據(jù)倉庫分層、業(yè)務(wù)線劃分。

1. 數(shù)據(jù)倉庫分層

對于數(shù)據(jù)倉庫的分層也就是我們在數(shù)據(jù)倉庫領(lǐng)域中常常聽到的ODS、DWD、DWS等等層級了。

在一般建表過程中,只需要在表名稱之前增加前綴來區(qū)分不同層級即可。但是在大數(shù)據(jù)平臺上,我們還希望增加一個類似分層的標簽,來區(qū)分表分別屬于什么層級。

如果使用的是向?qū)降慕ū磉^程,可以直接在建表過程中,增加數(shù)倉分層的選擇,這樣在建表過程中就確定表所屬數(shù)倉分層。如果是腳本式建的表,就需要表創(chuàng)建完成之后,再進行一次維護,因為在腳本式的文本編輯框中,是沒有辦法標記,表屬于什么分層的。

當然,除非表的分層和底層存儲的數(shù)據(jù)庫具有邏輯關(guān)系,即不同的數(shù)據(jù)倉庫分層,即是不同的數(shù)據(jù)庫(好像大部分實際情況也是這個樣子的)。

2. 業(yè)務(wù)分層

一張表除了需要確定是什么數(shù)據(jù)倉庫分層的,還需要確定是什么業(yè)務(wù)域的。一個數(shù)據(jù)倉庫一般是匯總多個業(yè)務(wù)線數(shù)據(jù),這些業(yè)務(wù)線中有的業(yè)務(wù)域重疊,有的是獨有的。這就需要按照實際的業(yè)務(wù)情況進行劃分。如果說數(shù)據(jù)倉庫的分層是一個技術(shù)問題,業(yè)務(wù)域的劃分就是一個業(yè)務(wù)+技術(shù)的問題了。需要對業(yè)務(wù)足夠熟悉,又能知道把這些業(yè)務(wù)怎么進行技術(shù)表達,做到不重不漏。

在表上進行業(yè)務(wù)域的打標簽,和進行數(shù)倉分層基本類型,如果向?qū)降目梢灾苯釉趧?chuàng)建過程中進行打標。如果是腳本式,則需要再維護一次了。

三、表層面的規(guī)劃,可行嗎

回到上面的問題,數(shù)據(jù)規(guī)劃可行嗎?個人認為在表層面的規(guī)劃是可行的,也是有必要的。有了這些數(shù)倉分層、業(yè)務(wù)域劃分,就能夠很好的找到數(shù)據(jù),或者后續(xù)對不同的層進行治理,審視。

?? 個人感覺在大數(shù)據(jù)領(lǐng)域更多的是一個經(jīng)驗領(lǐng)域,每個人都有自己的認識,各種名詞也都不能完全統(tǒng)一,各種理解也會有各自的角度,這里更多的是從自己的實際工作理解出發(fā),后續(xù)可能隨著工作接觸不同層面,理解也會變化。

四、字段層面的規(guī)劃

另一個層面的規(guī)劃,字段層面的規(guī)劃,這個層面的規(guī)劃是否能夠可行呢?又有哪些可以在字段層面進行規(guī)劃呢?

數(shù)據(jù)指標

數(shù)據(jù)指標的使用,首選需要數(shù)據(jù)指標的統(tǒng)一。

數(shù)據(jù)指標的統(tǒng)一,在有一個系統(tǒng)支持之前,一般使用一張excel表進行管理,使用一個表格統(tǒng)一需要的指標口徑,這種情況下可能小范圍統(tǒng)一是可行的,如一個項目組,以為一個項目組內(nèi)的信息拉齊很簡單。如果要更大范圍,變成全公司、全集團級別的指標對齊,就不能單單依賴Excel了。而是有一套系統(tǒng),有指標的創(chuàng)建、審核、發(fā)布、下線等流程。

有了統(tǒng)一的數(shù)據(jù)指標,但是最終可以在兩種場景下使用。一種是建模場景下的數(shù)據(jù)指標,一種是OLAP場景下的數(shù)據(jù)指標。這里的數(shù)據(jù)字段級別的規(guī)劃,主要是在建模場景下的數(shù)據(jù)指標規(guī)劃。

?? 數(shù)據(jù)指標使用,個人劃分為建模場景下的數(shù)據(jù)指標使用和OLAP場景下的數(shù)據(jù)指標使用。這兩種場景多少有些細微的類似,但是又多少有些細微的區(qū)別,也說不好這樣分有沒有道理,先暫且這么記錄吧。

如果有了全公司統(tǒng)一的指標口徑之后,在建模場景下能在哪里使用。個人認為只能在圖形化向?qū)絼?chuàng)建元數(shù)據(jù)過程中使用。在向?qū)絼?chuàng)建元數(shù)據(jù)的時候,將字段名由輸入框,變成下拉選擇形式,只能選擇已經(jīng)發(fā)布的指標來創(chuàng)建表,而不能隨便輸入任意字段。這樣就能夠從元數(shù)據(jù)層面上確保所有類似含義的指標在名稱上、口徑上是一致的,不會出現(xiàn)相同含義字段不一致的問題。

但是,這種向?qū)问剑趯嶋H的數(shù)據(jù)開發(fā)過程中是否適用,是不是能夠強力的推廣圖形建模,而將SQL語句形式禁止掉。個人認為可能并不是特別可行。這必然會拖慢研發(fā)效率,在實際中不一定能推廣開。

五、數(shù)據(jù)標準

這里只說下數(shù)據(jù)標準的使用,暫時不說數(shù)據(jù)標準的確定,后續(xù)會單獨寫下確定數(shù)據(jù)標準。數(shù)據(jù)標準里通常還會包含碼表的部分,就統(tǒng)一稱為數(shù)據(jù)標準,不做單獨的區(qū)分。

如果確定了標準,最終在哪里使用呢?個人感覺都是在向?qū)降膭?chuàng)建元數(shù)據(jù)中后,去選擇一個數(shù)據(jù)標準,也就是將這個數(shù)據(jù)標準和這個字段進行一個關(guān)系的綁定。綁定關(guān)系確立之后能做什么?

如果是進行質(zhì)量的校驗,把不符合標準的數(shù)據(jù)過濾出來,又和數(shù)據(jù)質(zhì)量有關(guān)了。如果不和數(shù)據(jù)質(zhì)量有關(guān),那確定了標準之后,那然后呢?就好像沒有什么然后了。所以一直也沒有想清楚,數(shù)據(jù)標準在創(chuàng)建元數(shù)據(jù)過程中起到一個什么樣的定位,還需要再學(xué)習(xí)下。

?? 個人沒有接觸過工業(yè)領(lǐng)域的數(shù)據(jù)標準,感覺工業(yè)領(lǐng)域?qū)τ谶@種數(shù)據(jù)長度、精度等數(shù)據(jù)標準的應(yīng)用場景可能會更多些。

六、字段層面的規(guī)劃可行嗎

字段類的規(guī)劃在實際中能夠跑的通嗎?說實話,目前沒有看到過跑通的案例。兩方面原因吧。

一方面,不管的數(shù)據(jù)指標還是數(shù)據(jù)標準,字段級的規(guī)劃都需要圖形界面支持,也就是向?qū)絹韯?chuàng)建元數(shù)據(jù),這樣創(chuàng)建元數(shù)據(jù)的形式需要一行一行添加,字段多的情況下,需要設(shè)置的內(nèi)容太多了,研發(fā)人員也不一定會接受。

另一方面,就是大部分公司都已經(jīng)有了一定的基礎(chǔ)了,也就是有歷史的數(shù)據(jù),在這種場景下可以稱之為歷史包袱了,沒有辦法說把所有的都調(diào)一遍。

七、存在即合理?

如果按照存在即是合理的理解,只能是自己還沒有遇到過具體的業(yè)務(wù)使用場景。數(shù)據(jù)指標如何使用,數(shù)據(jù)標準如何使用,這個還需要繼續(xù)深入研究下。

但是有一個有趣的點。就是各個云廠商好像又都有這個模塊,不知道是他們想清楚了怎么用,還是因為有了這個模塊在競標功能項上不丟分,至于是不是能用起來,就不是云廠商的事情了。

據(jù)傳Dataphine能夠?qū)⒆侄螌用娴囊?guī)劃用起來,因為使用Dataphine的一個前提是,從頭開始,從規(guī)劃、建模、開發(fā)。如果在流程上嚴格的做到建表向?qū)Щ?,也是可行的。?jù)說這個也是為啥阿里既有Dataworks又有Dataphine的原因。Dataworks面向的就是有歷史包袱,Dataphine重頭再來。當前也可能僅僅因為人力資源過于豐富了。

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

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

該文觀點僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)。

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 雖說計劃趕不上變化,但是絕對比沒有好,而且還是最容易出岔子的數(shù)據(jù)分析。

    來自北京 回復(fù)