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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我們總是希望一處授權(quán)，多處使用的，但是像上面這三步，涉及到不同的存儲(chǔ)，不同的工具。不同存儲(chǔ)有不同賬號(hào)進(jìn)行權(quán)限管理，不同工具之間又會(huì)有自己的權(quán)限體系。基本上打通很困難，很多環(huán)節(jié)中都需要人工進(jìn)行一定的傳遞。

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

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

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

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

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

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