中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

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

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

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

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

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

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

?? 我一直不理解不確定，把簡單的東西復雜化是一種能力，還是復雜問題簡單化是一種能力。

二、以元數(shù)據(jù)為中心構建數(shù)據(jù)平臺

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

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

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

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

首先，大數(shù)據(jù)平臺的一大目標是構建數(shù)據(jù)倉庫，那么數(shù)據(jù)倉庫對應的元數(shù)據(jù)就需要管理，不管這個數(shù)據(jù)倉庫是HIVE、還是類似阿里的Maxcomputer，都需要在大數(shù)據(jù)平臺進行統(tǒng)一管理。如果說架構中既有湖又有倉，那么湖和倉的元數(shù)據(jù)也都要統(tǒng)一管理。

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

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

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

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

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

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

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

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

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

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

除了元數(shù)據(jù)的同步之外，在大數(shù)據(jù)平臺上也可以直接創(chuàng)建元數(shù)據(jù)。創(chuàng)建有兩種形式，一種就是腳本形式。一種是向導的形式。

腳本形式

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

向導形式

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

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

五、展示形式

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

六、schema on read 還是schema on writer

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

針對數(shù)據(jù)湖模式下的scheme on read 有一點是想不清楚的，如果我在向數(shù)據(jù)湖導入數(shù)據(jù)的時候，我是知道導入文件的結構的，那么我為什么不直接創(chuàng)建一張表，建立這張表和導入文件的映射關系，讀取表的時候，就能夠讀取導入文件了，也就是直接使用schema on writer了。如果我在導入文件的時候，不知道導入文件的結構，沒法建立與之映射的表，那么誰來保證，我在讀的時候，就能夠知道應該建立怎樣的表與導入文件做對應那？也就是說scheam on read是在什么場景下使用那？

以上就是個人對于數(shù)據(jù)管理-元數(shù)據(jù)部分的相關理解。