前言

關(guān)于mysql的權(quán)限簡(jiǎn)單的理解就是mysql允許你做你全力以內(nèi)的事情，不可以越界。

權(quán)限控制，對(duì)于MLSQL而言的重要程度可以說(shuō)是生命線。 MLSQL需要面對(duì)各式各樣的資源訪問(wèn)，比如MySQL, Oracle,HDFS，Hive,Kafka,Sorl,ElasticSearch,Redis,API,Web等等，不同用戶對(duì)這些數(shù)據(jù)源（以及表，列）的權(quán)限是不一樣的。

傳統(tǒng)模式是，每個(gè)用戶都需要有個(gè)proxy user,然后到每個(gè)數(shù)據(jù)源里面給這個(gè)proxy user進(jìn)行授權(quán)。 這看起來(lái)似乎就是麻煩點(diǎn)，但是在實(shí)際操作中，基本是很難執(zhí)行的，不同的數(shù)據(jù)源在不同的團(tuán)隊(duì)里面，那么整個(gè)申請(qǐng)流程可能要天甚至周計(jì)了。
如果上面的問(wèn)題已經(jīng)讓人氣餒，那么對(duì)于采用Hive做數(shù)倉(cāng)的公司，可能對(duì)HIve權(quán)限訪問(wèn)更讓人絕望。Hive的授權(quán)模式是跟著Linux用戶走的，也就是Spark啟動(dòng)用戶是誰(shuí)，誰(shuí)就有權(quán)限訪問(wèn)，這個(gè)對(duì)于多租戶的MLSQL應(yīng)用來(lái)說(shuō)，則是完全不可行了，比如啟動(dòng)Spark的是sparkUser,但是真正執(zhí)行的人，其實(shí)可能是張三，李四等等。Hive就無(wú)法知道是具體哪個(gè)人完成的，只知道是sparkUser。

還有一個(gè)大家可能感慨的點(diǎn)：

我們好不容易寫(xiě)了個(gè)腳本，跑了一個(gè)小時(shí)，突然腳本失敗，一看，第350行那里訪問(wèn)的數(shù)據(jù)源權(quán)限不足。 這可真是讓人惱火。

問(wèn)題來(lái)了

那么，怎么才能在腳本運(yùn)行前，就知道腳本里涉及到的資源是不是都被授權(quán)了？

答案是：有

題外話：標(biāo)題不嚴(yán)謹(jǐn)，因?yàn)镸LSQL本質(zhì)是個(gè)解釋性執(zhí)行語(yǔ)言，不需要編譯，更好的標(biāo)題是 【解析時(shí)權(quán)限控制】。

MLSQL如果開(kāi)啟了權(quán)限驗(yàn)證，他會(huì)先掃描整個(gè)腳本，然后提取必要的信息，這些信息就包含了各種數(shù)據(jù)源的詳細(xì)信息，從而在運(yùn)行前就可以知道你是不是訪問(wèn)了未經(jīng)授權(quán)的庫(kù)表。那么MLSQL是怎么做到的呢？我們來(lái)看下面的信息：

connect jdbc where
driver="com.mysql.jdbc.Driver"
and url="jdbc:mysql://${ip}:${host}/db1?${MYSQL_URL_PARAMS}"
and user="${user}"
and password="${password}"
as db1_ref;

load jdbc.`db1_ref .people`
as people;

save append people as jdbc.`db1_ref.spam` ;

因?yàn)镸LSQL要求任何數(shù)據(jù)源，都需要使用load語(yǔ)句進(jìn)行加載，在解析load語(yǔ)句時(shí)，MLSQL知道，用戶現(xiàn)在要訪問(wèn)的是基于JDBC協(xié)議的數(shù)據(jù)源訪問(wèn)，他通過(guò)url拿到了這些信息：

db: db1
table: people
operateType: load
sourceType: mysql
tableType: JDBC

當(dāng)然，這個(gè)腳本用戶還會(huì)寫(xiě)入一張spam表，也一樣會(huì)被提取信息：

db: db1
table: people
operateType: save
sourceType: mysql
tableType: JDBC

然后還有一張臨時(shí)表people,所以這個(gè)腳本總共有三張表信息，之后這些信息會(huì)被發(fā)送到AuthCenter里進(jìn)行判斷，AuthCenter會(huì)告訴MLSQL那張表是沒(méi)有對(duì)當(dāng)前用戶授權(quán)的，如果發(fā)現(xiàn)未經(jīng)授權(quán)的表，MLSQL會(huì)直接拋出異常。整個(gè)過(guò)程中，完全不會(huì)執(zhí)行任何物理計(jì)劃，只是對(duì)腳本的信息抽取。

在MLSQL中，我們不能在select語(yǔ)句里訪問(wèn)hive表，只能通過(guò)load語(yǔ)句加載，比如下面的句子會(huì)報(bào)錯(cuò)：

select * from public.abc as table1;

我們無(wú)權(quán)在select語(yǔ)句中訪問(wèn)public.abc庫(kù)，如果需要使用，你可以通過(guò)如下方式完成：

load hive.`public.abc ` as abc;
select * from abc as table1;

如何實(shí)現(xiàn)列級(jí)別控制

MLSQL在解析load語(yǔ)句的時(shí)候，會(huì)詢問(wèn)當(dāng)前用戶訪問(wèn)的表，有哪些列是被授權(quán)的，然后會(huì)改寫(xiě)最后load的語(yǔ)句，提供一個(gè)新的視圖，該視圖只有用戶被授權(quán)的列。

總結(jié)

MLSQL通過(guò)一些有效的限制，可以在語(yǔ)法解析層面直接提取了所有數(shù)據(jù)源相關(guān)信息，并且將其發(fā)送給到配套的權(quán)限中心進(jìn)行判斷，避免在運(yùn)行時(shí)發(fā)現(xiàn)授權(quán)拒絕問(wèn)題。MLSQL此舉意義重大，使得MLSQL系統(tǒng)不再完全依賴于底層系統(tǒng)的權(quán)限控制，從而讓問(wèn)題得到了極大的簡(jiǎn)化。

好了，以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，謝謝大家對(duì)腳本之家的支持。