元數(shù)據(jù)一般被稱為“數(shù)據(jù)的數(shù)據(jù)”，以元數(shù)據(jù)為關鍵展開數(shù)據(jù)治理，能夠幫助企業(yè)更好地對數(shù)據(jù)資源進行管理，理清數(shù)據(jù)之間的關系，實現(xiàn)更精準高效的分析和決策。本文作者從自身工作出發(fā)，對元數(shù)據(jù)的基本功能展開了介紹說明，與大家分享。

本人在一家金融科技公司做B端產(chǎn)品經(jīng)理，大數(shù)據(jù)方向的，2019年我們公司轟轟烈烈的啟動了數(shù)據(jù)中臺建設，作為數(shù)據(jù)中臺的重要組成部分，元數(shù)據(jù)自然被提上了日程。在產(chǎn)品建設過程中遇到了很多坑跟大家分享下（第一次分享有錯誤還請大家多多包涵）。

關于元數(shù)據(jù)的概念的科普、介紹我這里就不多說了，大家在人人都是產(chǎn)品經(jīng)理隨便搜一下就有。

一、元數(shù)據(jù)功能介紹

在做元數(shù)據(jù)之前本人也做了很多的競品分析（簡單的），像這類產(chǎn)品更多還是乙方比較有經(jīng)驗舉例幾個亞信、普元信息、網(wǎng)達、星環(huán)等等。根據(jù)我們的需求現(xiàn)狀我們確定任何一家成熟的產(chǎn)品都cover不住我們的需求，對于乙方習慣于標準化，非標的需求都不太愿意做，所以我們干脆就從0到1開始建設，不用他們的產(chǎn)品，只用他們的技術能力。

對于要不要從0到1建設取決于數(shù)據(jù)量和數(shù)倉建設情況，如果數(shù)據(jù)量不大直接買一個成熟產(chǎn)品即可或者根本不需要元數(shù)據(jù)產(chǎn)品，畢竟沒有元數(shù)據(jù)也能建立數(shù)倉的（扯遠了~），每個公司對元數(shù)據(jù)的需求可能都不太一樣，元數(shù)據(jù)的標準化其實不太好做（對技術要求很高），因為你要能cover住大部分用戶的需求，cover不住要么用戶妥協(xié)、要么你妥協(xié)二次開發(fā)一些功能給用戶使用。

根據(jù)我們的需求我們規(guī)劃了以下功能（簡單的介紹下）：

1. 基礎功能

1）數(shù)據(jù)地圖：分為數(shù)據(jù)資產(chǎn)、元數(shù)據(jù)中心，為用戶提供元數(shù)據(jù)資產(chǎn)統(tǒng)計服務。

2）數(shù)據(jù)資產(chǎn)統(tǒng)計：用戶可以通過數(shù)據(jù)地圖清晰的了解數(shù)據(jù)的使用情況、分布等對整個數(shù)據(jù)資產(chǎn)情況有個大概的了解（這種分析統(tǒng)計類的需求是無止盡的，做一部分常用的即可，剩下的入庫自己用可視化分析工具展示）

3）元數(shù)據(jù)中心：這是元數(shù)據(jù)核心功能之一，整個元數(shù)據(jù)的輸出就是數(shù)據(jù)地圖，用戶可以通過元數(shù)據(jù)中心查看表的元數(shù)據(jù)信息（技術元數(shù)據(jù)、業(yè)務元數(shù)據(jù)）、任務信息、血緣關系（表級、字段級）血緣分析、使用信息等等（再多就看自己公司訴求了）

4）元模型：元模型是元數(shù)據(jù)的核心功能之一，主要實現(xiàn)技術元數(shù)據(jù)和業(yè)務元數(shù)據(jù)的管理、維護；這里說下子模型的概念，考慮場景的多樣性比如運維更關注技術元數(shù)據(jù)、業(yè)務更關注業(yè)務元數(shù)據(jù)，針對不同的庫、表可以應用不同的元模型，以滿足不同人群的需求。

5）管理中心：管理中心主要針對功能權限、數(shù)據(jù)權限進行管理包括權限申請、審批、實施等。

6）我的數(shù)據(jù)：為用戶提供查看自身權限、建表等功能。

7）數(shù)據(jù)管理：數(shù)據(jù)管理包含元模型、數(shù)據(jù)源管理等功能，用于元數(shù)據(jù)的手動、自動采集（生產(chǎn)的元數(shù)據(jù)采集依賴外部平臺，大數(shù)據(jù)側元數(shù)據(jù)采集我們自己做的）

8）元數(shù)據(jù)質量：主要做元數(shù)據(jù)治理用的，包含庫、表元數(shù)據(jù)治理功能，分多個維度統(tǒng)計元數(shù)據(jù)完成情況，并可以做相應通知等。

9）其他：還做了一些其他功能如審計等，這里不細講了。

2. 產(chǎn)品架構

我簡單描述下：

• 存儲/計算：元數(shù)據(jù)使用MySQL進行存儲、圖數(shù)據(jù)庫，查詢使用clickhouse，緩存分布式redis；
• 服務層：服務層提供基礎的平臺服務能力，包括元數(shù)據(jù)管理、元數(shù)據(jù)地圖、管理中心、用戶權限管理等。
• 通知服務：元數(shù)據(jù)管理系統(tǒng)中通知類消息目前有三種呈現(xiàn)形式，分別為站內信、短信、郵箱；
• 元數(shù)據(jù)采集：kafka、hook插件、flume、sftp
• 安全服務：LDAP認證、kerberos

二、產(chǎn)品建設的準備工作

1. 需求調研

關于需求調研、分析，需求從來都是無止盡的，沒有上限，作為產(chǎn)品心中要給自己劃個底線，你的產(chǎn)品邊界、產(chǎn)品定位在哪里，尤其是需求方比較強勢的時候，確定好邊界和底線你才知道哪些能做、哪些不能做，哪些需要重點優(yōu)先建設，這樣你在交付產(chǎn)品才能得到需求方的認可。

我們就沒有守住底線接了很多運維類的需求，同時也拒絕了很多運維類的需求，因為在做下去就變成了四不像了集ETL部分功能、數(shù)據(jù)加工部分功能、數(shù)據(jù)庫管理功能等等等。元數(shù)據(jù)核心還是數(shù)據(jù)采集、數(shù)據(jù)地圖、元模型、數(shù)據(jù)權限，當你接了太多需求時，還是回歸產(chǎn)品定位、明確產(chǎn)品邊界，時間有限、精力有限我們能做的也有限。

2. 數(shù)據(jù)采集

（1）采集內容的確認

基本只要是個具備大數(shù)據(jù)環(huán)境的公司都有數(shù)據(jù)采集的能力，采集可以用現(xiàn)有的能力、也可以單獨開發(fā)，這里還是要看你采集的內容，在確定采集方案前還是要先確定內容，內容會決定你用什么技術方案。我們采集的內容我大致分為三種類型：應用信息、庫信息、表信息

1. 應用信息：應用名稱（中、英文）、應用類型、應用狀態(tài)、應用負責人、地址等
2. 庫信息：ip地址、實例名稱、JDBC地址、庫名稱、歸屬部門、服務名稱、用途、字符集、版本等等
3. 表信息：owner或庫名、字段名、字段類型、字段注釋、大小、行數(shù)、創(chuàng)建時間、分區(qū)、索引等

不同的類型庫采集的內容不同，這里談一下應用信息，我們是有專門的IT系統(tǒng)可以直接從系統(tǒng)里拿到，如果沒有類似的IT系統(tǒng)，那采集方案就要重新設計和考慮了。

這三類信息我們都是直接從IT資源管理系統(tǒng)（CMDB）通過kafka消費，頻率3小時一次，IT資源管理系統(tǒng)（CMDB）會從生產(chǎn)數(shù)據(jù)庫、各應用管理平臺等通過自身的采集能力拿到。

所有新增、變更需求由技術部門快速迭代開發(fā)響應。

寫到這里大家肯定認為我們省了很大的工作量，但這恰恰是我們栽的第一個坑。我會在后幾個篇幅來講遇到的坑。

元數(shù)據(jù)的采集是個非常重要的功能，產(chǎn)品在設計之初一定要進行充分的調研，并跟開發(fā)確定好合理的方案，但同時也要考慮工作量的問題，是否可以先做一部分，后期再迭代優(yōu)化，畢竟采集是基礎能力，而用戶更關心數(shù)據(jù)地圖、權限和元模型

（2）元模型的確認

元模型決定你要展示的元數(shù)據(jù)信息包含有哪些內容，在采集前同樣要確定好元模型的內容，考慮元模型的不確定性和變化性、我們前期可以定一個基礎元模型，按照數(shù)據(jù)庫的類型做區(qū)分如hive、Hbase、mysql、oracle、CK、ES等元模型，針對每個元模型定一個基礎的。

比如hive我們可以包含所屬庫名（中、英文）表名、存儲位置、存儲大小、創(chuàng)建時間、分區(qū)信息、DDL變更時間、數(shù)據(jù)變更時間等。其他如oracle、mysql類似，在不清楚業(yè)務屬性的時候我們可以把技術屬性先確定了。這樣就可以將采集到的信息按照元模型進行展示了。最終給用戶呈現(xiàn)的內容就是元模型+采集到的基本信息。

后續(xù)內容比較多也比較重要我放到下一個篇幅來展開講。

#相關閱讀

聊聊數(shù)據(jù)中臺：元數(shù)據(jù)建設有哪些坑（二）

本文由 @逆襲的騎士 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉載。

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