如何进行Data Lake Analytics账号和权限体系的分析
如何进行Data Lake Analytics账号和权限体系的分析
今天就跟大家聊聊有关如何进行Data Lake Analytics账号和权限体系的分析，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。
一、Data Lake Analytics介绍
基于数据湖做分析，可以不用做任何ETL、数据搬迁等前置过程，实现跨各种异构数据源进行大数据关联分析，从而极大的节省成本和提升用户体验。
下图是DLA的简易架构（__MPP计算引擎+存储计算分离+弹性高可用+异构数据集源等）__：
二、自建账号
目前DLA是以MySQL协议方式对外提供服务，用户需要通过JDBC连接，连到DLA服务。DLA内部的账号和密码是独立自建的（与RAM不同），对应的账号和密码信息，在用户开通DLA服务时以站内信、邮件、短信等方式通知您。
可能您会疑惑，为什么DLA不是以RAM或AK账号做认证和授权，而需要自建账号。在这里，做一些简单的介绍：
DLA是数据库，在客户端建立连接（需要认证）、访问库、表、字段（需要鉴权）时，大量跨服务访问RAM系统，会给RAM系统造成很大压力，且可能会影响DLA服务延时；
DLA是数据库，需要兼容MySQL权限模型，库、表、字段等领域对象很难一一映射到RAM体系；同时RAM下的资源对象的权限粒度可粗可细，且更多偏向于管理数据生命周期而非详细数据层面的权限；
用户习惯的Grant、Revoke、Show grants等逻辑，都是直接和传统数据库的库、表、字段一一映射。
参考了阿里云上及业界云服务平台上其他数据库产品的设计，存在一样的考量；
三、三种账号模型
Root/Service账号：RAM主账号在某个Region内开通DLA服务时，系统会自动创建第一个DLA账户，并以站内信、短信、邮件方式通知RAM主账号，Root账号只有一个，不能删除；
User/子账号：由RAM主账号后续在Console上创建的新的DLA的User账号（注意，不是由Root账号创建的），云账号用户可以创建、删除User账号，也可以为其修改密码等；
Product账号：其他云产品（比如DBS）与DLA交互时，由用户在RAM中为该云产品授权过，由DLA自动产生并派发给云产品的账号；
Root账号和User账号，关联的RAM uid都是对应的云账号，从而Root和User账号都有机会访问云账号所有的资源（当然，这都是在授权管理之内）；
四、账号实测操作
a）开通服务并初始化服务
找到服务：
购买：
为不同的Region初始化服务：
初始化完成，得到一个Root账号：
配置服务访问点
b）连接数据库并通过认证
连接DLA服务，并进入服务
##连接DLA服务，账号和密码都在您的收件箱内，服务访问点则在服务页面[root]#mysql-u<您的dla用户名>-p<您的dla密码>-h<您的dla服务访问点>-P10000##进入DLA服务，开始测试之旅mysql>showdatabases;Emptyset(0.09sec)
连接DLA服务，并进入服务，也能正常工作了。
五、权限模型
DLA中有两层权限验证机制，确保您的数据被安全访问：
DLA层授权和校验校验，基于MySQL语法而定义和实现（Grant：https://dev.mysql.com/doc/refman/5.7/en/grant.html、Revoke：https://dev.mysql.com/doc/refman/5.7/en/revoke.html、Show Grants：https://dev.mysql.com/doc/refman/5.7/en/show-grants.html）
数据源和RAM层授权和校验，基于RAM的的访问控制而实现（比如OSS、TableStore等云原生产品）：https://help.aliyun.com/product/28625.html，或者基于数据源本身的权限校验（比如RDS，是自建账号，因而也有自建权限系统）
用户的SQL发送到DLA，做完DLA的权限校验后，再转发到后端数据源层，执行RAM层和数据源的权限校验，最后再真正访问到用户的数据；
a）DLA层校验原理
DLA是根据用户操作对象的范围“从大到小”验证的，从Global级（全局权限），到Schema级，再到Table级，最后到Column级（目前不支持）一层层验证权限。任何一层有权限校验成功，到最后一层也没权限时校验失败：
b）DLA层授权方法
基本上参考了MySQL的Grant/Revoke/Show Grants语法来实现：
##grant相关GRANT{SELECT|SHOW|ALTER|DROP|CREATE|INSERT|UPDATE|DELETE|GRANTOPTION|ALL|ALLPRIVILEGES|USAGE}ON{*|*.*|xxDb.*|xxDb.yyTable|yyTable}TO{oa_1234546|'oa_123456'|'oa_123456'@'1.2.3.4'}[withgrantoption]##revoke相关REVOKE{SELECT|SHOW|ALTER|DROP|CREATE|INSERT|UPDATE|DELETE|GRANTOPTION|ALL|ALLPRIVILEGES|USAGE}ON{*|*.*|xxDb.*|xxDb.yyTable|yyTable}FROM{oa_1234546|'oa_123456'|'oa_123456'@'1.2.3.4'}##showgrants相关SHOWGRANTS[for[current_user|current_user()|oa_123456|'oa_123456'|'oa_123456'@'localhost']]
相关关键信息说明：
授权人：
只能由DLA的root账号给其他非Root账号授权；
暂时不支持非Root账号给其他账号授权；
不能跨云账号授权和回收权限；
privilege列表：
可以用','连接在一起，比如SELECT,DELETE,UPDATE,INSERT,...
有ALL或ALL PRIVILEGES就会全部授权或者全部回收，无视其他的Privilege；但一定要注意，grant option这个权限本身，不包含在ALL中，必须显式授权或者回收
暂时不支持其他类型的授权；
SELECT是为Query授权；
SHOW为show、use命令授权（这里与mysql的逻辑差异比较大）；
ALTER为alter或其他变更型的ddl授权；
CREATE为create型的ddl授权；
DROP为drop型的ddl授权；
INSERT为insert型的dml授权；
UPDATE为update型的dml授权；
DELETE为delete型的dml授权；
GRANT OPTION为dcl授权（grant和revoke相关）；可以在Privilege中指定GRANT OPTION，也可以通过语句片段with grant option来做grant 授权；
USAGE其实啥也没有，表示为空；
ResourceType中：
* 表示当前连接使用了某个库xxDB，然后针对xxDB做授权，库级别权限；
. 表示所有库的所有表授权，Global级别权限；
xxDb.* 表示针对xxDB这个库做授权，库级别权限；
xxDb.yyTable 表示针对xxDB库的xxTable做授权，表级别权限；
yyTable 表示当前连接使用了某个库xxDB，针对xxDB库的xxTable做授权，表级别权限；
暂时不支持字段级别的授权；
被授权用户定义：
直接写用户名：oa_123456
用户字符串来表示：'oa_123456'
即使写了ip、host信息，也不会用于连接的白名单校验；
只有相同云账号下的Root用户才能为别人show grants；
不能跨不同uid执行show grant
必须有show权限和grant权限才能执行show grants，或者为本人执行__；__
SHOW GRANTS FOR 'jeffrey'@'localhost'：目前不支持ip地址；
c）DLA与RAM间权限映射
因为DLA中的子账号与RAM中的子账号并不是一一对应，因而RAM中资源的权限和DLA中库表的权限也不是自然映射的，而是需要在DLA中以特殊定义的方式来做资源的映射和权限的隔离。
目前DLA中授权单位是Schema级别的，也就意味着如果Root账号给某个User账号授权了一个库的权限，那这个User账号能够访问这个库下所有的表，也就意味着能够访问该库映射到RAM上所有的资源，这些访问并不受RAM的子账号权限控制。
比如，我们看一个典型的建库语句（假设用户已经可以在DLA中创建相关的库）：
CREATEDATABASEdb_namewithdbproperties(CATALOG='ots',LOCATION='https://test-hangzhou.ots.aliyuncs.com',INSTANCE='test')
如果Root账号给某个User账后执行Grant操作后，该User账号就可以访问这个库：
grantallondb_name.*toxxx_s1519122757;
上述过程都假设云账号的系统角色授权已经完成，下一节我们介绍首先如何完成系统角色授权，从而允许DLA访问你在其他云产品中的数据。
d）系统角色授权
系统角色授权是指：用户给DLA授权，允许DLA访问用户相关云服务里的数据，从而实现DLA关联分析用户数据的目标，或者通过DLA实现ETL，将数据回流到用户的库。具体过程可以参考：https://help.aliyun.com/document_detail/53478.html
e）跨账号访问
DLA支持跨账号，允许A用户在DLA上，连接B用户的OSS上的数据进行分析计算，不过这需要做一些操作，后续文档会以图形化的方式来介绍和引导用户：
库建完后，去建表
插入一行数据
点击同意授权：
查看角色授权已经成功：
假设上述测试账号对应的云账号为A，下面就以TableStore和另一个云账号B（DLA另一个真实的测试云账号）作为案例，演示B账号给A账号针对TableStore中某个instance做跨账号授权，并且A在DLA中完成查询的过程。
首先，需要到B账号内，在"访问控制（https://ram.console.aliyun.com）"中创建一个跨账号授权的角色：
重新使用云账号A的DLA Root账号，通过MySQL-cli连接到DLA，然后连接和访问云账号B的数据：
mysql>selectuser();+----------------+|user()|+----------------+|oa_xxxxxxxxxxx|+----------------+1rowinset(0.06sec)mysql>showdatabases;+------------------+|Database|+------------------+|ots_account_test|+------------------+1rowinset(0.24sec)mysql>createdatabaseots_cross_account_testwithdbproperties(catalog='ots',location='https://test-sh.cn-shanghai.ots-internal.aliyuncs.com',--云账号B的TableStoreinstanceinstance='test-sh',cross_account_accessing_arn='acs:ram::1013xxxxxx:role/test-cross-account-accessing-role'--云账号B为云账号A@云服务DLA的跨账号角色授权时的Arn信息);QueryOK,0rowsaffected(0.14sec)mysql>showdatabases;+------------------------+|Database|+------------------------+|ots_account_test||ots_cross_account_test|+------------------------+2rowsinset(0.18sec)mysql>showcreatedatabaseots_cross_account_test;+------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+|Database|CreateDatabase|+------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+|ots_cross_account_test|CREATEDATABASE`ots_cross_account_test`WITHDBPROPERTIES(catalog='ots',location='https://test-sh.cn-shanghai.ots-internal.aliyuncs.com',instance='test-sh',cross_account_accessing_arn='acs:ram::1013xxxxxx:role/test-cross-account-accessing-role')COMMENT''|+------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+1rowinset(0.19sec)mysql>useots_cross_account_test;Databasechangedmysql>showtables;Emptyset(0.19sec)mysql>createexternaltabletest_table1(id1intnotnullprimarykey,col1int);QueryOK,0rowsaffected(0.31sec)mysql>showtables;+-------------+|Table_Name|+-------------+|test_table1|+-------------+1rowinset(0.20sec)mysql>showcreatetabletest_table1;+-------------+--------------------------------------------------------------------------------------------------------------------------------------+|Table|CreateTable|+-------------+--------------------------------------------------------------------------------------------------------------------------------------+|test_table1|CREATEEXTERNALTABLE`test_table1`(`id1`intNOTNULLCOMMENT'',`col1`intNULLCOMMENT'',PRIMARYKEY(`id1`))COMMENT''|+-------------+--------------------------------------------------------------------------------------------------------------------------------------+1rowinset(0.20sec)mysql>select*fromtest_table1;+--------+------+|id1|col1|+--------+------+|0|-111||111111|111|+--------+------+2rowsinset(1.29sec)
顺便提醒一下，普通的建库流程中是不需要cross_account_accessing_arn参数的，意味着默认是云账号自己给自己开通了DLA访问云服务的权限，而有了cross_account_accessing_arn参数，就表示跨账号服务的开启，这个DLA中的库以及库下面的表，都有了跨账号访问的权限！！
看完上述内容，你们对如何进行Data Lake Analytics账号和权限体系的分析有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注恰卡编程网行业资讯频道，感谢大家的支持。
