看了一些其他文章，有說定義的，有畫圖的，其中也不乏有一些很不錯的文章
數倉系列：
【數倉】數據倉庫的思考（一）：https://blog.csdn.net/lsr40/article/details/105576047
【數倉】數據倉庫的建設（二）：https://blog.csdn.net/lsr40/article/details/105639190
但是其實沒有一個統一的概念說明元數據管理的邊界應該是什麼，所以大家的做法會有所不同，有些元數據管理還會把數據質量模塊也加入進來，有些可能是獨立出來一個監控數據質量的模塊，當然大家的目的都是想實現數倉的完整架構，只是各有各的方式和步驟~
之前看過一句話，覺得很有意思：
元數據管理其實就是解決，數據的哲學問題，我是誰，我從哪來，又要到哪去？
1、表的血緣分析：
表的上下游依賴關係
我們常常會不知道這張表的前後關係，由哪些表生成這張表，這張表最後又去了哪裏，然後就需要從各種sql，存儲過程，代碼，甚至kettle等ETL工具中來找到我們想要的信息，耗時又耗力
因此如果有可以在開發的過程中就把表的上下游依賴錄入到元數據管理平臺中，那會方便很多
如圖（雖然畫的很醜）：
數據庫存的時候：
1、通過product_id或者topic_id來區分不同鏈路
2、通過label字段，來標識每張表的等級（屬於ods還是dwd還是dws，臨時表就寫tmp，維表就寫dim）
3、通過order字段來標識表的先後順序，ods層order=0，dwd層order=10，dws層order=20，以此類推，比如dwd到dws中間臨時表，order就可以使用11，多張臨時表就12,13往後，如果dim指向tmp表，那order就和tmp表一樣，否則就和tmp叫一樣order往後排就行了
4、如果存在join，需要記錄是哪種join（可以用實線，虛線和箭頭的方向來表示inner還是leftjoin），通過什麼字段join（單獨做一張表來記錄如何關聯，當然實在不想記錄。。。也行吧）
備註：上圖的title是ods，dwd，dws，dm，這是數倉基礎的分層，那麼如果是一個數據產品的血緣關係的話，是不是可以自定義title，同一個層的表有沒有先後依賴關係，這些可能都需要實際做的時候，加入人工的思考與判斷
如何自動的收集：
如果是sql的話，其實做sql解析還是做得到的，可以百度到相關的東西，使用正則，或者一些sql解析工具包啊是ok的
如果是寫成代碼，或者存儲過程，這就比較麻煩了，一般是需要手動去填寫相關信息
如果是kettle或者其他框架寫好了一串流程，那麼也不太好收集這部分信息，所以類似這個，是否可以自研一個調度框架來解決這個問題（大多數人使用kettle應該用的是shell，sql，寫文件，發郵件等基礎功能），要做一個自研的框架，並把流程寫到裏面應該是沒什麼太大問題，然後每天定時調度功能也寫一下就好（當然肯定是需要版本迭代更新，提供新的功能，仁者見仁智者見智了）
2、表，字段信息管理
各種類型的數據庫都會有各自的元數據信息，比如hive，我們可以通過show create table xxx，來查看一張表的建表語句
因此我們如果自己管理整條鏈路上的所有表的元數據，也可以通過類似的方式收集，關於如何保存這些元數據，可以參考hive的元數據庫的做法！
Hive元數據信息對應MySQL數據庫表：https://www.cnblogs.com/qingyunzong/p/8710356.html
舉個例子，甚至可以記錄每張表的count（定時count下，看錶的膨脹率，可以是全量count也可以是新增分區的count，看日趨勢）
可以根據不同的數據庫不同的功能去新增一些字段記錄更多的信息，比如greenplum中，每張表都會有distributed by(xxx)，也需要記錄，又比如mysql裏表有引擎的，是InnoDB還是MyISAM等等，所以也是需要根據實際用的不同數據庫去微調自己的元數據記錄的方式
當有新建表的需求的時候，如果可以做出一個平臺，直接在平臺上建表，那麼元數據就可以實時更新的，但是如果是直接連接數據庫操作的話，就應該定時去show tables，然後查詢所有表的建表信息，然後解析之後保存到正確的表中，並且如果有已存在的非臨時表的信息查詢出來和上次不一樣的話，應該有適當的報警！
額外說幾點：
1、表或者業務線的負責人
2、記錄該表的生成規則！（比如該表存了活躍的人的行爲，那麼如何定義這個活躍的人，應該有適當的說明甚至有樣例sql）
2、字段一定要有註釋，甚至有時候字段的生成規則也需要記錄！（因爲有些字段涉及到了計算，爲了驗證數據或者口徑統一，就需要計算的方法，給出樣例sql，並且要標明中文含義，避免同一個字段，大家的叫法不同），當然也可以不在這裏記錄，在專門的指標庫中記錄也可以
3、記錄下該表數據保存週期，比如存近一年，或者近6個月這樣，讓大家有個概念
4、修改相關信息造成的影響（通知或者告警）：向下追溯元數據對象改變對下游的影響，是不是要發通知或者郵件給下游所有負責人
3、權限管理
當然既然是一個平臺，就會有權限的設置，其實不就是增刪改查元數據的權限嗎，根據業務線開通，然後有底層人員（管理員），有數據分析人員，業務人員不同等級的權限，只要這裏的元數據查看，不涉及到真實數據的查詢，那權限相對沒那麼重要。
除非是在元數據平臺中，也有預覽數據的功能，那就需要查看數據之前的開通權限，並且數據展示時的脫敏操作，例如電話號碼中間4位加密啊等等的一些隱私字段加密功能，那麼就需要在設計表的字段信息存放的時候，給每個字段加上權限等級，以此來做數據的保密！
emmmm，暫時說這麼多吧，主要還是要看這個元數據管理平臺想做多少，簡單的方法，也可以提供一個wiki，或者文檔解釋下相關的信息就可以，複雜的話可以做成一個大的應用服務，功能點還是蠻多的！
如果有什麼還需要補充的或者各位有疑惑的，可以給我留言，相互探討下
沒啥好說的，反正努力吧，多學習，多開闊視野，多提高技術水平！