Data Lake Analytics账号和权限体系详细介绍

一、Data Lake Analytics介绍
数据湖(Data Lake)是时下大数据行业热门的概念:https://en.wikipedia.org/wiki/Data_lake。基于数据湖做分析,可以不用做任何ETL、数据搬迁等前置过程,实现跨各种异构数据源进行大数据关联分析,从而极大的节省成本和提升用户体验

阿里云数据湖分析产品Data Lake Analytics(简称DLA):https://www.aliyun.com/product/datalakeanalytics
产品文档:https://help.aliyun.com/product/70174.html

下图是DLA的简易架构(MPP计算引擎+存储计算分离+弹性高可用+异构数据集源等)

二、自建账号
目前DLA是以MySQL协议方式对外提供服务,用户需要通过JDBC连接,连到DLA服务。DLA内部的账号和密码是独立自建的(与RAM不同),对应的账号和密码信息,在用户开通DLA服务时以站内信、邮件、短信等方式通知您。

可能您会疑惑,为什么DLA不是以RAM或AK账号做认证和授权,而需要自建账号。在这里,做一些简单的介绍:

DLA是数据库,在客户端建立连接(需要认证)、访问库、表、字段(需要鉴权)时,大量跨服务访问RAM系统,会给RAM系统造成很大压力,且可能会影响DLA服务延时;
DLA是数据库,需要兼容MySQL权限模型,库、表、字段等领域对象很难一一映射到RAM体系;同时RAM下的资源对象的权限粒度可粗可细,且更多偏向于管理数据生命周期而非详细数据层面的权限;
用户习惯的Grant、Revoke、Show grants等逻辑,都是直接和传统数据库的库、表、字段一一映射。
参考了阿里云上及业界云服务平台上其他数据库产品的设计,存在一样的考量;
目前DLA账号体系与RAM账号体系的关系:

三、三种账号模型
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账号:

重新回到主页:https://openanalytics.console.aliyun.com/overview,设置服务访问点

image.png | left | 747x379

配置服务访问点

image.png | left | 747x431

image.png | left | 747x353

b)连接数据库并通过认证
连接DLA服务,并进入服务

##连接DLA服务,账号和密码都在您的收件箱内,服务访问点则在服务页面
[root]# mysql -u<您的dla用户名> -p<您的dla密码> -h<您的dla服务访问点> -P10000

进入DLA服务,开始测试之旅

mysql> show databases;
Empty set (0.09 sec)
image.png | left | 747x213

到此,我们已经完成了服务开通过程,并认证和连接成功。

c)创建子账号,并连接数据库
image.png | left | 747x325

image.png | left | 747x206

image.png | left | 747x163

连接DLA服务,并进入服务,也能正常工作了:

image.png | left | 747x233

五、权限模型
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级(目前不支持)一层层验证权限。任何一层有权限校验成功,到最后一层也没权限时校验失败:

image.png | left | 351x557

b)DLA层授权方法
基本上参考了MySQL的Grant/Revoke/Show Grants语法来实现:

##grant相关
GRANT {SELECT | SHOW | ALTER | DROP | CREATE | INSERT | UPDATE | DELETE | GRANT OPTION | ALL | ALL PRIVILEGES | USAGE }
ON { | . | xxDb. | xxDb.yyTable | yyTable }
TO { oa_1234546 | ‘oa_123456‘ | ‘oa_123456‘@‘1.2.3.4‘}
[with grant option]

##revoke相关
REVOKE {SELECT | SHOW | ALTER | DROP | CREATE | INSERT | UPDATE | DELETE |GRANT OPTION | ALL | ALL PRIVILEGES | USAGE}
ON { | . | xxDb. | xxDb.yyTable | yyTable }
FROM { oa_1234546 | ‘oa_123456‘ | ‘oa_123456‘@‘1.2.3.4‘}

##show grants相关
SHOW GRANTS
[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中创建相关的库):

CREATE DATABASE db_name
with dbproperties (
CATALOG = ‘ots‘,
LOCATION = ‘https://test-hangzhou.ots.aliyuncs.com‘,
INSTANCE = ‘test‘
)
如果Root账号给某个User账后执行Grant操作后,该User账号就可以访问这个库:

grant all on db_name.* to xxx_s1519122757;
上述过程都假设云账号的系统角色授权已经完成,下一节我们介绍首先如何完成系统角色授权,从而允许DLA访问你在其他云产品中的数据。

d)系统角色授权
系统角色授权是指:用户给DLA授权,允许DLA访问用户相关云服务里的数据,从而实现DLA关联分析用户数据的目标,或者通过DLA实现ETL,将数据回流到用户的库。具体过程可以参考:https://help.aliyun.com/document_detail/53478.html

e)跨账号访问
DLA支持跨账号,允许A用户在DLA上,连接B用户的OSS上的数据进行分析计算,不过这需要做一些操作,后续文档会以图形化的方式来介绍和引导用户:

image.png | left | 563x426

六、权限实测操作(以TableStore为案例)
a)准备TableStore的库表
我们来到OTS的首页,https://ots.console.aliyun.com/index,创建希望DLA做分析的库和表

image.png | left | 747x384

库建完后,去建表

image.png | left | 747x301

image.png | left | 747x313

image.png | left | 747x243

image.png | left | 747x331

插入一行数据

image.png | left | 747x250

b)开通TableStore给DLA的云服务角色授权
关于访问控制和角色授权等信息,请参考:https://help.aliyun.com/product/28625.html

回到DLA主页:https://openanalytics.console.aliyun.com/overview

image.png | left | 747x432

点击同意授权:

image.png | left | 747x342

授权完成之后的状态:

image.png | left | 747x484

查看角色授权已经成功:

image.png | left | 747x413

c)在DLA中创建库和表,关联TableStore库和表
我们重新回到DLA Root账号(oa_xxx),通过JDBC协议连接到DLA(账号信息、DLA访问点、JDBC连接方式,请参考前面文档)

╰─○ mysql -u<您的DLA Root账号> -p<您的DLA Root账号的密码> -h<您的DLA-jdbc访问点> -P10000

mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 194631
Server version: 5.6.40-log Source distribution

Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type ‘help;‘ or ‘\h‘ for help. Type ‘\c‘ to clear the current input statement.

mysql>
开始创建库,去关联TableStore中的实例:

mysql> select user();
+----------------+
| user() |
+----------------+
| oa_xxxxxxxxxxx |
+----------------+
1 row in set (0.08 sec)

mysql> show databases; Empty set (0.02 sec)

mysql> create database ots_account_test
with dbproperties(
catalog = ‘ots‘,
location = ‘https://account-test.cn-shanghai.ots-internal.aliyuncs.com‘,
instance = ‘account-test‘
) comment ‘test account and privileges‘;
Query OK, 0 rows affected (0.10 sec)

mysql> show databases;
+------------------+
| Database |
+------------------+
| ots_account_test |
+------------------+
1 row in set (0.01 sec)

mysql> show create database ots_account_test;
+------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Database | Create Database |
+------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| ots_account_test | CREATE DATABASE ots_account_test
WITH DBPROPERTIES (
catalog = ‘ots‘,
location = ‘https://account-test.cn-shanghai.ots-internal.aliyuncs.com‘,
instance = ‘account-test‘
)
COMMENT ‘test account and privileges‘ |
+------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.03 sec)
开始创建表,去关联TableStore中的表,并查询数据(结果与OTS中的结果一致):

mysql> use ots_account_test;
Database changed

mysql> show tables;
Empty set (0.03 sec)

mysql> create external table account_test (
-> pk1 int not null primary key,
-> name varchar(20)
-> );
Query OK, 0 rows affected (0.15 sec)

mysql> show create table account_test;
+--------------+-----------------------------------------------------------------------------------------------------------------------------------------------+
| Table | Create Table |
+--------------+-----------------------------------------------------------------------------------------------------------------------------------------------+
| account_test | CREATE EXTERNAL TABLE account_test (
pk1 int NOT NULL COMMENT ‘‘,
name varchar(20) NULL COMMENT ‘‘,
PRIMARY KEY (pk1)
)
COMMENT ‘‘ |
+--------------+-----------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.04 sec)

mysql> select * from account_test;
+------+--------------+
| pk1 | name |
+------+--------------+
| 123 | account-test |
+------+--------------+
1 row in set (1.61 sec)
至此,我们已经成功完成了数据关联并实现数据查询的过程!!

d)把库和表授权给子账号来访问
上诉都是Root账号在操作,从前面的分析可知,Root账号是可以操作对应云账号所有的云资源的,但是DLA的User账号却不行,必须通过Root账号给User账号Grant权限,DLA才能允许某个User账号访问对应的库和表:

切换到User账号/子账号连接页面,此时看不到任何库表:

mysql> select user();
+------------------------+
| user() |
+------------------------+
| test_sxxxxxxxxxxxxxxxx |
+------------------------+
1 row in set (0.14 sec)

mysql> show databases;
Empty set (0.02 sec)

mysql> show grants ;
+------------------------------------------------+
| Grants for test_sxxxxxxxxxxxxxxxx |
+------------------------------------------------+
| GRANT USAGE ON . TO ‘test_sxxxxxxxxxxxxxxxx‘ |
+------------------------------------------------+
1 row in set (0.03 sec)
切换Root账号连接页面,我们给前面的账号授权:

mysql> select user();
+------------------------+
| user() |
+------------------------+
| oa_xxxxxxxxxxx |
+------------------------+
1 row in set (0.14 sec)

mysql> show grants for test_sxxxxxxxxxxxxxxxx;
+---------------------------------------------------------------+
| Grants for test_sxxxxxxxxxxxxxxxx |
+---------------------------------------------------------------+
| GRANT USAGE ON . TO ‘test_sxxxxxxxxxxxxxxxx‘ |
+---------------------------------------------------------------+
1 rows in set (0.02 sec)

mysql> grant all on ots_account_test.* to test_sxxxxxxxxxxxxxxxx;
Query OK, 0 rows affected (0.05 sec)

mysql> show grants for test_sxxxxxxxxxxxxxxxx;
+---------------------------------------------------------------+
| Grants for test_sxxxxxxxxxxxxxxxx |
+---------------------------------------------------------------+
| GRANT USAGE ON . TO ‘test_sxxxxxxxxxxxxxxxx‘ |
| GRANT ALL ON ots_account_test.* TO ‘test_sxxxxxxxxxxxxxxxx‘ |
+---------------------------------------------------------------+
2 rows in set (0.03 sec)
切换User账号连接页面,重新查询看看,已经有权限了,并且可以读取数据:

mysql> select user();
+------------------------+
| user() |
+------------------------+
| test_sxxxxxxxxxxxxxxxx |
+------------------------+
1 row in set (0.14 sec)

mysql> show grants ;
+---------------------------------------------------------------+
| Grants for test_sxxxxxxxxxxxxxxxx |
+---------------------------------------------------------------+
| GRANT USAGE ON . TO ‘test_sxxxxxxxxxxxxxxxx‘ |
| GRANT ALL ON ots_account_test.* TO ‘test_sxxxxxxxxxxxxxxxx‘ |
+---------------------------------------------------------------+
2 rows in set (0.02 sec)

mysql> show databases;
+------------------+
| Database |
+------------------+
| ots_account_test |
+------------------+
1 row in set (0.02 sec)

mysql> select * from ots_account_test.account_test;
+------+--------------+
| pk1 | name |
+------+--------------+
| 123 | account-test |
+------+--------------+
1 row in set (0.43 sec)
至此,子账号授权访问就可以了!

e)支持跨账号访问
一般情况,用户大部分使用DLA的场景是,云账号A使用DLA访问云账号A在其他云产品中的数据,从前面的分析可以知道,只要用户在DLA的console上选择具体的数据源(比如TableStore)给DLA做系统角色授权之后,就可以打通数据源,创建库表和查询数据了。

但是,还有一种场景是:云账号A使用DLA来访问云账号B在其他云产品(以下以TableStore)中的数据,这需要专门的角色授权才能正常运行:

image.png | left | 563x426

假设上述测试账号对应的云账号为A,下面就以TableStore和另一个云账号B(DLA另一个真实的测试云账号)作为案例,演示B账号给A账号针对TableStore中某个instance做跨账号授权,并且A在DLA中完成查询的过程。

首先,需要到B账号内,在"访问控制(https://ram.console.aliyun.com)"中创建一个跨账号授权的角色

image.png | left | 747x445

选择一个“服务角色”,选择一个合适的模板,快速创建:

image.png | left | 747x323

image.png | left | 747x407

image.png | left | 747x283

image.png | left | 747x355

重新回到角色管理页面,找到这个角色做修改(修改成支持DLA的模板):

image.png | left | 747x412

image.png | left | 747x278

image.png | left | 747x315

image.png | left | 747x273

跨账号的角色创建和修改完成,开始做“角色授权策略”的配置,这里我们以TableStore为例,其他数据源类似:

image.png | left | 747x337

image.png | left | 747x144

跨账号角色定义,以及角色授权都操作完成,我们开始进入DLA的实际测试,首先查看云账号B的TableStore中的instance和table的情况:

image.png | left | 747x393

image.png | left | 747x259

重新使用云账号A的DLA Root账号,通过MySQL-cli连接到DLA,然后连接和访问云账号B的数据:

mysql> select user();
+----------------+
| user() |
+----------------+
| oa_xxxxxxxxxxx |
+----------------+
1 row in set (0.06 sec)

mysql> show databases;
+------------------+
| Database |
+------------------+
| ots_account_test |
+------------------+
1 row in set (0.24 sec)

mysql> create database ots_cross_account_test
with dbproperties(
catalog = ‘ots‘,
location = ‘https://test-sh.cn-shanghai.ots-internal.aliyuncs.com‘, --云账号B的TableStore instance
instance = ‘test-sh‘,
cross_account_accessing_arn= ‘acs:ram::1013xxxxxx:role/test-cross-account-accessing-role‘ --云账号B为云账号A@云服务DLA的跨账号角色授权时的Arn信息
);
Query OK, 0 rows affected (0.14 sec)

mysql> show databases ;
+------------------------+
| Database |
+------------------------+
| ots_account_test |
| ots_cross_account_test |
+------------------------+
2 rows in set (0.18 sec)

mysql> show create database ots_cross_account_test;
+------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Database | Create Database |
+------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| ots_cross_account_test | CREATE DATABASE ots_cross_account_test
WITH DBPROPERTIES (
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 ‘‘ |
+------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.19 sec)

mysql> use ots_cross_account_test;
Database changed

mysql> show tables;
Empty set (0.19 sec)

mysql> create external table test_table1 (
id1 int not null primary key,
col1 int
);
Query OK, 0 rows affected (0.31 sec)

mysql> show tables;
+-------------+
| Table_Name |
+-------------+
| test_table1 |
+-------------+
1 row in set (0.20 sec)

mysql> show create table test_table1;
+-------------+--------------------------------------------------------------------------------------------------------------------------------------+
| Table | Create Table |
+-------------+--------------------------------------------------------------------------------------------------------------------------------------+
| test_table1 | CREATE EXTERNAL TABLE test_table1 (
id1 int NOT NULL COMMENT ‘‘,
col1 int NULL COMMENT ‘‘,
PRIMARY KEY (id1)
)
COMMENT ‘‘ |
+-------------+--------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.20 sec)

mysql> select * from test_table1;
+--------+------+
| id1 | col1 |
+--------+------+
| 0 | -111 |
| 111111 | 111 |
+--------+------+
2 rows in set (1.29 sec)
顺便提醒一下,普通的建库流程中是不需要cross_account_accessing_arn参数的,意味着默认是云账号自己给自己开通了DLA访问云服务的权限,而有了cross_account_accessing_arn参数,就表示跨账号服务的开启,这个DLA中的库以及库下面的表,都有了跨账号访问的权限!!

到这里,我们跨账号访问的全过程就完成啦!!如果你希望连接OSS等云服务,你也可以按照上述流程操作一遍!!

原文地址:https://blog.51cto.com/14031893/2361269

时间: 2024-10-07 23:08:37

Data Lake Analytics账号和权限体系详细介绍的相关文章

基于Data Lake Analytics的Serverless SQL大数据分析

摘要: TableStore(简称OTS)是阿里云的一款分布式表格系统,为用户提供schema-free的分布式表格服务.随着越来越多用户对OLAP有强烈的需求,我们提供在表格存储上接入Data Lake Analytics(简称DLA)服务的方式,提供一种快速的OLAP解决方案. 背景介绍TableStore(简称OTS)是阿里云的一款分布式表格系统,为用户提供schema-free的分布式表格服务.随着越来越多用户对OLAP有强烈的需求,我们提供在表格存储上接入Data Lake Analy

Data Lake Analytics的Geospatial分析函数

0. 简介 为满足部分客户在云上做Geometry数据的分析需求,阿里云Data Lake Analytics(以下简称:DLA)支持多种格式的地理空间数据处理函数,符合Open Geospatial Consortium's (OGC) OpenGIS规范,支持的常用数据格式包括: WKT WKB GeoJson ESRI Geometry Object Json ESRI Shape DLA采用4326坐标系标准,EPSG 4326使用经纬度坐标,属于地理坐标系.GPS采用的就是这个坐标系.

Data Lake Analytics,大数据的ETL神器!

0. Data Lake Analytics(简称DLA)介绍 数据湖(Data Lake)是时下大数据行业热门的概念:https://en.wikipedia.org/wiki/Data_lake.基于数据湖做分析,可以不用做任何ETL.数据搬迁等前置过程,实现跨各种异构数据源进行大数据关联分析,从而极大的节省成本和提升用户体验.关于Data Lake的概念. 终于,阿里云现在也有了自己的数据湖分析产品:https://www.aliyun.com/product/datalakeanalyt

Linux/Centos7账号与权限管理(超详细实例操作)

Linux/Centos7账号与权限管理 管理用户账号.组账号 查询账号信息 设置文件和目录的权限 设置文件和目录的归属 一.前言概述 ? 作为多用户.多任务(Multi-Users,Multi-tasks)的服务器操作系统,Linux提供了严格的权限管理机制,主要从用户身份.文件权限两个方面对资源进行限制.Linux基于用户身份对资源访问进行控制. 用户账号类别: 超级用户--root,权限最高 普通用户--自定义用户 匿名用户(nobody)类似于Windows中的Guest 程序用户--控

构建企业级数据湖?Azure Data Lake Storage Gen2不容错过(上)

背景 相较传统的重量级OLAP数据仓库,“数据湖”以其数据体量大.综合成本低.支持非结构化数据.查询灵活多变等特点,受到越来越多企业的青睐,逐渐成为了现代数据平台的核心和架构范式. 数据湖的核心功能,简单地可以分为数据存储与数据查询计算两个部分,在云端可以有多种的实现选择.在之前的文章中,我们曾介绍Azure上Azure Data Lake Storage (ADLS Gen1)和Azure Data Lake Analytics (ADLA)这一对可配合使用的服务.这对黄金搭档正是为数据湖而生

【免费公测中】为数据赋予超能力,阿里云重磅推出Serverless数据分析引擎-Data Lake

摘要: 近日,阿里云重磅推出Serverless数据分析引擎-Data Lake Analytics,Data Lake Analytics,帮助更多不具备分析能力的存储服务,赋予其分析的能力. 近日,阿里云重磅推出Serverless数据分析引擎-Data Lake Analytics,Data Lake Analytics,帮助更多不具备分析能力的存储服务,赋予其分析的能力. 从生活中的购物交易,到工业上的生产制造,再到社交网络媒体信息.企业化管理决策等等,大数据成为当前经济社会最重要的前进

MySQL中的账号与权限管理

MySQL权限管理 权限系统的工作原理     MySQL权限系统通过下面两个阶段进行认证: (1)对连接的用户进行身份认证,合法的用户通过认证.不合法的用户拒绝连接. (2)对通过认证的合法用户赋予相应的权限,用户可以在这些权限范围内对数据库做相应的操作. 对于身份,MySQL是通过IP地址和用户名联合进行确认的,例如MySQL安装默认创建的用户[email protected]表示用户root只能从本地(localhost)进行连接才可以通过认证,此用户从其他任何主机对数据库进行的连接都将被

sqlserver权限体系(下)

简介 在上一篇文章中,我对主体的概念做了全面的阐述.本篇文章接着讲述主体所作用的安全对象以及所对应的权限. 理解安全对象(Securable) 安全对象,是SQL Server 数据库引擎授权系统控制对其进行访问的资源.通俗点说,就是在SQL Server权限体系下控制的对象,因为所有的对象(从服务器,到表,到视图触发器等)都在SQL Server的权限体系控制之下,所以在SQL Server中的任何对象都可以被称为安全对象. 和主体一样,安全对象之间也是有层级,对父层级上的安全对象应用的权限会

Mysql 之权限体系

MySQL 的权限体系大致分为5个层级: 全局层级: 全局权限适用于一个给定服务器中的所有数据库.这些权限存储在mysql.user表中.GRANT ALL ON .和REVOKE ALL ON .只授予和撤销全局权限. 数据库层级: 数据库权限适用于一个给定数据库中的所有目标.这些权限存储在mysql.db表中.GRANT ALL ON db_name.和REVOKE ALL ON db_name.只授予和撤销数据库权限. 表层级: 表权限适用于一个给定表中的所有列.这些权限存储在mysql.