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

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

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

關于元數據的概念的科普、介紹我這里就不多說了，大家在人人都是產品經理隨便搜一下就有。

一、元數據功能介紹

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

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

根據我們的需求我們規劃了以下功能（簡單的介紹下）：

1. 基礎功能

1）數據地圖：分為數據資產、元數據中心，為用戶提供元數據資產統計服務。

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

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

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

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

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

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

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

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

2. 產品架構

我簡單描述下：

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

二、產品建設的準備工作

1. 需求調研

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

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

2. 數據采集

（1）采集內容的確認

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

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

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

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

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

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

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

（2）元模型的確認

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

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

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

#相關閱讀

聊聊數據中臺：元數據建設有哪些坑（二）

本文由 @逆襲的騎士 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。