在數(shù)據(jù)驅(qū)動的商業(yè)世界中，數(shù)據(jù)權(quán)限管理是確保信息安全、合規(guī)性和數(shù)據(jù)治理的關(guān)鍵環(huán)節(jié)。本文深入探討了數(shù)據(jù)權(quán)限的復雜性和挑戰(zhàn)，從開發(fā)和運營兩個角度分析了數(shù)據(jù)權(quán)限模型的適用性，以及在實際業(yè)務(wù)流程中如何有效實施數(shù)據(jù)權(quán)限控制。

01 面向開發(fā)還是面向運營

這里主要介紹面向開發(fā)的數(shù)據(jù)權(quán)限。面向運營的數(shù)據(jù)權(quán)限會在數(shù)據(jù)運營篇數(shù)據(jù)運營中的權(quán)限問題 介紹。

開發(fā)過程中的數(shù)據(jù)權(quán)限會有創(chuàng)建表、修改表、寫入數(shù)據(jù)、刪除數(shù)據(jù)等等。

在“當我們談?wù)撛獢?shù)據(jù)，我們在談什么”中提到，面向開發(fā)元數(shù)據(jù)展示形式和面向運營的展示形式是否一樣，是一個可以討論的點，這里我們當作不一樣。

同樣，面向開發(fā)的權(quán)限申請是否和面向運營的權(quán)限申請，使用同一個流程也是可以討論的點。畢竟，開發(fā)過程中數(shù)據(jù)加工者需要的權(quán)限包括創(chuàng)建表、修改表、寫入數(shù)據(jù)、刪除數(shù)據(jù)。而面向運營的數(shù)據(jù)消費者，只需要查詢數(shù)據(jù)的權(quán)限。

數(shù)據(jù)權(quán)限似乎能講很復雜，但是似乎又就那么點東西。后續(xù)再不斷完善更新吧。

02 數(shù)據(jù)權(quán)限模型–RBAC模型適用你的場景嗎？

說起數(shù)據(jù)權(quán)限，第一反應就是“用戶-角色-權(quán)限”的三層關(guān)系，將一組數(shù)據(jù)的權(quán)限（可以是數(shù)據(jù)的增刪改查的任意權(quán)限）放到一個角色里面去，然后再將角色授權(quán)給不同的用戶。如果中間有部門的層級，可能還會增加一層，將角色授權(quán)給部門，部門內(nèi)的所有用戶都具備相同的權(quán)限。

聽起來，挺合理，但是有一個現(xiàn)實的問題，這種標準的授權(quán)是否適用于現(xiàn)有的企業(yè)內(nèi)的權(quán)限申請流程。如果現(xiàn)在企業(yè)內(nèi)權(quán)限的申請流程是按人申請的，且申請之后只能開通現(xiàn)有流程中已申請的表的權(quán)限。那么不同的流程，就沒有辦法做到和角色的對應，勢必出現(xiàn)角色特別多，不知道哪種角色應該跟給誰了。

所以，到底需要用怎樣的數(shù)據(jù)權(quán)限授權(quán)方案，其實需要結(jié)合實際的權(quán)限申請流程、粒度來做決定。

03 權(quán)限-用戶的雙向查詢

不管使用哪種形式進行了用戶的數(shù)據(jù)授權(quán)，都會面臨一個問題，就是查看一個用戶有哪些權(quán)限，同時，又需要查看某個數(shù)據(jù)權(quán)限都授權(quán)給了哪些人。這相當于一個雙向的數(shù)據(jù)授權(quán)。但是往往在數(shù)據(jù)權(quán)限的產(chǎn)品設(shè)計中，往往會忽略一個方向，倒也不是不能用，但是就是查詢起來需要手動 一個個點開。這也算是一個實踐過程中的優(yōu)化點了。

04 數(shù)據(jù)權(quán)限的審批節(jié)點

數(shù)據(jù)中臺只管理數(shù)據(jù)，不擁有數(shù)據(jù)。數(shù)據(jù)仍然是業(yè)務(wù)的，換句話說就是數(shù)據(jù)中臺的數(shù)據(jù)owner仍舊是各個數(shù)據(jù)的業(yè)務(wù)方。因為我們不擁有數(shù)據(jù)，所以當有業(yè)務(wù)方想使用數(shù)據(jù)，進行申請數(shù)據(jù)的時候，理論上仍然需要業(yè)務(wù)方進行審批的（當然，這里也會有數(shù)據(jù)owner、數(shù)據(jù)BP等不同的審批類型）。業(yè)務(wù)方審批通過之后，數(shù)據(jù)中臺的人再審批（主要技術(shù)層面的一些審批）。這里有個問題就是如果業(yè)務(wù)方來審批的話，拋開敏感的、機密的數(shù)據(jù)不提，業(yè)務(wù)方有什么理由不審批通過。如果都審批通過了，是不是業(yè)務(wù)方審批就變成了一種形式了。

還不考慮，數(shù)據(jù)中臺將數(shù)據(jù)進行加工之后，多個業(yè)務(wù)方數(shù)據(jù)匯總表，沒有辦法指定唯一業(yè)務(wù)方，甚至區(qū)分不出來業(yè)務(wù)方了。

所以，是否比較合理的形式是，規(guī)定好數(shù)據(jù)密級之后，如果是普通密級的，跳過業(yè)務(wù)方審批，直接數(shù)據(jù)中臺進行偏技術(shù)維度的審批就可以了。如果是高密級的再進行業(yè)務(wù)審批。（當然高密級的也不會放在一個集群上）。這樣既能減少各方的審批壓力，又能加快用數(shù)效率，還能提升數(shù)據(jù)中臺的審批地位。個人感覺是一個不錯的方法。

05 數(shù)據(jù)權(quán)限的傳遞范圍

這里的權(quán)限的傳遞，倒不是說權(quán)限的上下繼承，這里的權(quán)限傳遞是指在不同組件間的權(quán)限打通。這里僅僅是一個想法討論，并沒有在實踐中完全實現(xiàn)?；蛘哂懈玫姆桨福ぷ髦袥]有接觸到。

要考慮數(shù)據(jù)權(quán)限的傳遞范圍，首先需要考慮的一個點就是在整個大數(shù)據(jù)流轉(zhuǎn)使用過程中一共經(jīng)過多少種存儲組件，或者說一共經(jīng)過了多少種存儲類型。不考慮批流一體，數(shù)倉一體等等。只說一個比較通用的場景，業(yè)務(wù)數(shù)據(jù)進入數(shù)據(jù)中臺被用戶使用的流轉(zhuǎn)：第一步進入數(shù)據(jù)湖（HIVE、ODPS等等大數(shù)據(jù)存儲，在其中進行數(shù)據(jù)的分層加工），第二步，進入數(shù)據(jù)倉庫（MPP、MySQL、GP等。因為大數(shù)據(jù)存儲類的查詢效率較慢，不足以支撐快速查詢要求所以需要一個快速查詢引擎）第三步，被多種方式進行數(shù)據(jù)消費（做成BI報表被消費、做成數(shù)據(jù)服務(wù)API被消費、直連查詢被消費）。

我們總是希望一處授權(quán)，多處使用的，但是像上面這三步，涉及到不同的存儲，不同的工具。不同存儲有不同賬號進行權(quán)限管理，不同工具之間又會有自己的權(quán)限體系?；旧洗蛲ê芾щy，很多環(huán)節(jié)中都需要人工進行一定的傳遞。

像上面說的這種，可能有不同的方式能夠更好的來解決這個問題，只是自己沒有接觸到。希望后續(xù)能夠不斷的深入吧。

06 數(shù)據(jù)源的統(tǒng)一管理

說到數(shù)據(jù)權(quán)限的統(tǒng)一，不得不提的就是數(shù)據(jù)源的統(tǒng)一。

數(shù)據(jù)平臺是以元數(shù)據(jù)為中心，那么數(shù)據(jù)源就是這個中心的一個起始點。大數(shù)據(jù)平臺也需要對數(shù)據(jù)源進行統(tǒng)一的管理，這里統(tǒng)一管理的數(shù)據(jù)源僅僅包括數(shù)據(jù)源的技術(shù)信息，包括了數(shù)據(jù)源的IP地址、用戶名、密碼等連接到數(shù)據(jù)庫的信息。數(shù)據(jù)源的業(yè)務(wù)信息、同步數(shù)據(jù)量信息、甚至變更信息等，甚至是一個數(shù)據(jù)源的治理–當管理大量數(shù)據(jù)源的時候，哪些是核心、哪些已經(jīng)入湖、比例如何、連通性監(jiān)控、變更監(jiān)控等等。

管理好了統(tǒng)一的數(shù)據(jù)源，我們會在數(shù)據(jù)集成的源端、目標端使用。會在離線開發(fā)、實時開發(fā)過程中使用，也會在數(shù)據(jù)分析的即席查詢過程中使用，在可視化BI中使用。當然，數(shù)據(jù)源也分類型，每個模塊支持哪些類型的數(shù)據(jù)源，就需要依照需求自己來做定位了。

這里數(shù)據(jù)源的統(tǒng)一管理也是一個不斷探索的階段，和上面說的一樣，不同組件中都有自己的數(shù)據(jù)源管理，如何打通需要再深入探討。