當(dāng)我們談元數(shù)據(jù)的時(shí)候，我們?cè)谡勈裁?/h2>

數(shù)據(jù)小吏

2024-01-29

1 評(píng)論 1868 瀏覽 6 收藏 10 分鐘

元數(shù)據(jù)就是表的名字、字段、類型和描述。數(shù)據(jù)資產(chǎn)的主題就是元數(shù)據(jù)。那關(guān)于元數(shù)據(jù)，你知道多少呢？

個(gè)人定義在產(chǎn)品上，數(shù)據(jù)管理主要集中在元數(shù)據(jù)管理的概念上，和數(shù)據(jù)治理的區(qū)別是什么？個(gè)人在數(shù)據(jù)管理和數(shù)據(jù)治理上怎么區(qū)分的，后續(xù)再詳細(xì)介紹。

同時(shí)，這里介紹的元數(shù)據(jù)主要面向開發(fā)過(guò)程，如果將元數(shù)據(jù)變成資產(chǎn)了，面向數(shù)據(jù)消費(fèi)者，后續(xù)在數(shù)據(jù)運(yùn)營(yíng)篇中介紹數(shù)據(jù)地圖的時(shí)候再詳細(xì)說(shuō)明。

一、元數(shù)據(jù)基本概念

元數(shù)據(jù)，關(guān)于數(shù)據(jù)的數(shù)據(jù)。標(biāo)準(zhǔn)解釋法，如果第一次接觸這個(gè)概念的話會(huì)覺得摸不著頭腦。有的也會(huì)借一個(gè)例子，比如舉出菜市場(chǎng)的例子。說(shuō)是每種菜的價(jià)格、產(chǎn)地、生產(chǎn)時(shí)間等等。

如果，讓我來(lái)進(jìn)行很粗略的說(shuō)法，元數(shù)據(jù)就是schema信息。更進(jìn)一步就是表的名字、字段、類型、描述。這樣理解起來(lái)更簡(jiǎn)便，當(dāng)然也更粗糙些。

這里更進(jìn)一步說(shuō)下，元數(shù)據(jù)有時(shí)候還會(huì)升級(jí)為數(shù)據(jù)資產(chǎn)，個(gè)人理解主體仍舊就元數(shù)據(jù)，元數(shù)據(jù)增加一些管理屬性、業(yè)務(wù)屬性，就變?yōu)閿?shù)據(jù)資產(chǎn)了。本質(zhì)上還是元數(shù)據(jù)。

?? 我一直不理解不確定，把簡(jiǎn)單的東西復(fù)雜化是一種能力，還是復(fù)雜問(wèn)題簡(jiǎn)單化是一種能力。

二、以元數(shù)據(jù)為中心構(gòu)建數(shù)據(jù)平臺(tái)

不管元數(shù)據(jù)在概念上怎么定義，作為大數(shù)據(jù)平臺(tái)的產(chǎn)品經(jīng)理都需要將概念落到實(shí)處。從整個(gè)大數(shù)據(jù)平臺(tái)上說(shuō)下元數(shù)據(jù)在大數(shù)據(jù)平臺(tái)中的位置。一句話來(lái)說(shuō)的話，整個(gè)大數(shù)據(jù)平臺(tái)是以元數(shù)據(jù)為中心來(lái)構(gòu)建的。

從最開始的數(shù)據(jù)集成，集成的源端、目標(biāo)端需要有元數(shù)據(jù)。集成之后的數(shù)據(jù)開發(fā)過(guò)程需要元數(shù)據(jù)。開發(fā)之后創(chuàng)建數(shù)據(jù)服務(wù)，也需要元數(shù)據(jù)。即席查詢分析需要元數(shù)據(jù)。報(bào)表展示需要元數(shù)據(jù)。可以通過(guò)元數(shù)據(jù)，將大數(shù)據(jù)平臺(tái)中各個(gè)模塊都串起來(lái)。所以，可以稱為以元數(shù)據(jù)為中心來(lái)構(gòu)建大數(shù)據(jù)平臺(tái)。

三、元數(shù)據(jù)管理應(yīng)該包含哪些數(shù)據(jù)源類型

如果簡(jiǎn)單來(lái)說(shuō)元數(shù)據(jù)就是schema，而且元數(shù)據(jù)又如此重要。那么大數(shù)據(jù)平臺(tái)需要管理哪些數(shù)據(jù)源的元數(shù)據(jù)那？

首先，大數(shù)據(jù)平臺(tái)的一大目標(biāo)是構(gòu)建數(shù)據(jù)倉(cāng)庫(kù)，那么數(shù)據(jù)倉(cāng)庫(kù)對(duì)應(yīng)的元數(shù)據(jù)就需要管理，不管這個(gè)數(shù)據(jù)倉(cāng)庫(kù)是HIVE、還是類似阿里的Maxcomputer，都需要在大數(shù)據(jù)平臺(tái)進(jìn)行統(tǒng)一管理。如果說(shuō)架構(gòu)中既有湖又有倉(cāng)，那么湖和倉(cāng)的元數(shù)據(jù)也都要統(tǒng)一管理。

其他類型的那，隨著大數(shù)據(jù)平臺(tái)的能力不斷擴(kuò)大，能夠支持的開發(fā)類型不斷增多，漸漸的也都支持其他類型的數(shù)據(jù)源。如MySQL、Oracle等等。甚至于將文本、kakfa等都在產(chǎn)品層面上賦予一個(gè)schema，有的在名稱上稱為全域的元數(shù)據(jù)管理。

有了這種對(duì)文本、kafka等沒有schema結(jié)構(gòu)的統(tǒng)一管理，也能能夠支持對(duì)于沒有表結(jié)構(gòu)的數(shù)據(jù)源的界面化操作了。

包含的元數(shù)據(jù)管理類型越多，勢(shì)必會(huì)對(duì)其他模塊有影響，造成平臺(tái)越復(fù)雜。如后續(xù)介紹的即席查詢，是否需要能夠?qū)λ泄芾淼脑獢?shù)據(jù)都進(jìn)行查詢？查詢的時(shí)候是否需要跨源進(jìn)行關(guān)聯(lián)？這是需要通盤考慮的事情，倒沒有好與不好之分，只要整體流暢即可。

四、元數(shù)據(jù)同步形式

大部分情況下元數(shù)據(jù)已經(jīng)存在底層數(shù)據(jù)庫(kù)上了，這個(gè)時(shí)候就需要進(jìn)行同步。同步無(wú)非兩種，一種離線，一種實(shí)時(shí)。

離線即為創(chuàng)建一個(gè)定時(shí)的調(diào)度，通過(guò)調(diào)度周期性的抓取到最新元數(shù)據(jù)。這種會(huì)有一定的更新延遲性。

實(shí)時(shí)即為監(jiān)控?cái)?shù)據(jù)庫(kù)上的日志，當(dāng)出現(xiàn)變更時(shí)，也同步變更平臺(tái)上的元數(shù)據(jù)。

但不管這兩種方式的哪一種，依舊不能擺脫元數(shù)據(jù)兩層皮的問(wèn)題。

似乎有一種和底層深度結(jié)合的方式，就是元數(shù)據(jù)直接讀取底層的catlog。不會(huì)將元數(shù)據(jù)在平臺(tái)再次存儲(chǔ)。不過(guò)這個(gè)偏底層，不確定是否是我理解的這樣，并且面對(duì)上文提到的全域的元數(shù)據(jù)管理時(shí)，需要怎么處理，這些個(gè)人沒有做過(guò)升入的研究，需要再學(xué)習(xí)學(xué)習(xí)。

元數(shù)據(jù)創(chuàng)建兩種形式-向?qū)?腳本式

除了元數(shù)據(jù)的同步之外，在大數(shù)據(jù)平臺(tái)上也可以直接創(chuàng)建元數(shù)據(jù)。創(chuàng)建有兩種形式，一種就是腳本形式。一種是向?qū)У男问健?/p>

腳本形式

就是一個(gè)文本編輯框，在文本編輯框中編寫SQL直接創(chuàng)建，這種形式是大部分研發(fā)喜歡的形式。符合日常的形式。但是，這種創(chuàng)建形式不能很好的和標(biāo)準(zhǔn)，指標(biāo)，碼表等綁定。

向?qū)问?/strong>

除了腳本的形式，也可以使用向?qū)У男问絹?lái)創(chuàng)建表，使用類似表格形式來(lái)創(chuàng)建。這種形式需要將表的一行一行來(lái)填充、選擇類型等等。操作上效率低，而且和研發(fā)人員的日常建表習(xí)慣也不一致。是不是能夠使用推廣，個(gè)人認(rèn)為是有一定阻力的。

但是這種形式能夠很好的綁定標(biāo)準(zhǔn)、指標(biāo)、碼表等。而且似乎只有這種形式能夠?qū)⑦@些信息和表進(jìn)行綁定。這部分將在后面“數(shù)據(jù)規(guī)劃真的可行嗎”?中繼續(xù)介紹。

五、展示形式

在數(shù)據(jù)運(yùn)營(yíng)篇，會(huì)介紹面向運(yùn)營(yíng)的元數(shù)據(jù)展示開啟使用數(shù)據(jù)的第一步—找到數(shù)據(jù) ，在運(yùn)營(yíng)過(guò)程中展示的形式，打破了庫(kù)的限制，能夠更加靈活的來(lái)顯示出來(lái)表信息。但是在面向開發(fā)的元數(shù)據(jù)是單獨(dú)做一個(gè)元數(shù)據(jù)展示界面，這個(gè)界面形式上是庫(kù)表的層級(jí)樹，還是可以和面向運(yùn)營(yíng)的元數(shù)據(jù)使用一個(gè)。也是可以討論的一個(gè)點(diǎn)。

六、schema on read 還是schema on writer

以上寫的所有都是基于schema on writer形式的，也就是在寫入數(shù)據(jù)的時(shí)候，就已經(jīng)確定了schema信息了，這也是大家在日常中普遍使用的。但是，隨著，數(shù)據(jù)湖的推廣，越來(lái)越多出現(xiàn)schema on read的形式了。這種形式的核心是，schema信息不是在數(shù)據(jù)寫入的時(shí)候指定，而是在讀取的時(shí)候，再賦予schema信息。因?yàn)閭€(gè)人在現(xiàn)有的產(chǎn)品設(shè)計(jì)中，沒有接觸到這類的形式，所以目前對(duì)這種形式的schema在什么場(chǎng)景下應(yīng)用，持一定的懷疑態(tài)度。后續(xù)有接觸到了，再進(jìn)行更新。

針對(duì)數(shù)據(jù)湖模式下的scheme on read 有一點(diǎn)是想不清楚的，如果我在向數(shù)據(jù)湖導(dǎo)入數(shù)據(jù)的時(shí)候，我是知道導(dǎo)入文件的結(jié)構(gòu)的，那么我為什么不直接創(chuàng)建一張表，建立這張表和導(dǎo)入文件的映射關(guān)系，讀取表的時(shí)候，就能夠讀取導(dǎo)入文件了，也就是直接使用schema on writer了。如果我在導(dǎo)入文件的時(shí)候，不知道導(dǎo)入文件的結(jié)構(gòu)，沒法建立與之映射的表，那么誰(shuí)來(lái)保證，我在讀的時(shí)候，就能夠知道應(yīng)該建立怎樣的表與導(dǎo)入文件做對(duì)應(yīng)那？也就是說(shuō)scheam on read是在什么場(chǎng)景下使用那？

以上就是個(gè)人對(duì)于數(shù)據(jù)管理-元數(shù)據(jù)部分的相關(guān)理解。

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

題圖來(lái)自 Unsplash，基于 CC0 協(xié)議

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

收藏已收藏{{ postmeta.bookmark }} 點(diǎn)贊已贊{{ postmeta.postlike }}

更多精彩內(nèi)容，請(qǐng)關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App

元數(shù)據(jù)基本定義數(shù)據(jù)治理

海報(bào)