华为云用户手册

  • sqoop1对接 MRS 服务 下载开源Sqoop,http://www.apache.org/dyn/closer.lua/sqoo:p/1.4.7。 将下载好的sqoop-1.4.7.bin__hadoop-2.6.0.tar.gz 包放入MRS集群master节点的/opt/sqoop目录下并解压。 tar zxvf sqoop-1.4.7.bin__hadoop-2.6.0.tar.gz 进入解压完成的目录,修改配置。 cd /opt/sqoop/sqoop-1.4.7.bin__hadoop-2.6.0/conf cp sqoop-env-template.sh sqoop-env.sh vi sqoop-env.sh 添加配置: export HADOOP_COMMON_HOME=/opt/client/HDFS/hadoop export HADOOP_MAPRED_HOME=/opt/client/HDFS/hadoop export HIVE_HOME=/opt/Bigdata/MRS_1.9.X/install/ FusionInsight -Hive-3.1.0/hive(请按照实际路径填写) export HIVE_CONF_DIR=/opt/client/Hive/config export HCAT_HOME=/opt/client/Hive/HCatalog 添加系统变量,将“SQOOP_HOME”添加到PATH中。 vi /etc/profile 添加以下信息: export SQOOP_HOME=/opt/sqoop/sqoop-1.4.7.bin__hadoop-2.6.0 export PATH=$PATH:$SQOOP_HOME/bin 执行以下命令复制jline-2.12.jar文件到lib文件下。 cp /opt/share/jline-2.12/jline-2.12.jar /opt/sqoop/sqoop-1.4.7.bin__hadoop-2.6.0/lib 执行以下命令,在文件中添加下列配置。 vim $JAVA_HOME/jre/lib/security/java.policy permission javax.management.MBeanTrustPermission "register"; 执行以下命令,实现sqoop1对接MRS服务。 source /etc/profile
  • 概述 本章节适用于MRS 3.x及后续版本。 sqoop-shell是一个开源的shell工具,其所有功能都是通过执行脚本“sqoop2-shell”来实现的。 sqoop-shell工具提供了如下功能: 支持创建和更新连接器 支持创建和更新作业 支持删除连接器和作业 支持以同步或异步的方式启动作业 支持停止作业 支持查询作业状态 支持查询作业历史执行记录 支持复制连接器和作业 支持创建和更新转换步骤 支持指定行、列分隔符 sqoop-shell工具支持如下模式: 交互模式 通过执行不带参数的“sqoop2-shell”脚本,进入Loader特定的交互窗口,用户输入脚本后,工具会返回相应信息到交互窗口。 批量模式 通过执行“sqoop2-shell”脚本,带一个文件名作为参数,该文件中按行存储了多条命令,sqoop-shell工具将会按顺序执行文件中所有命令;或者在“sqoop2-shell”脚本后面通过“-c”参数附加一条命令,一次只执行一条命令。 sqoop-shell通过表1的命令来实现Loader各种功能。 表1 命令一览表 命令 说明 exit 表示退出交互模式。 该命令仅支持交互模式。 history 查看执行过的命令。 该命令仅支持交互模式。 help 查看工具帮助信息。 set 设置服务端属性。 show 显示服务属性和Loader所有元数据信息。 create 创建连接器和作业。 update 更新连接器和作业。 delete 删除连接器和作业。 clone 复制连接器和作业。 start 启动作业。 stop 停止作业。 status 查询作业状态。
  • 访问Ranger Admin WebUI 在MRS控制台,单击集群名称进入集群详情页面。 选择“组件管理”。 选择“Ranger”,在“Ranger 概述”中单击“Ranger WebUI”对应的“RangerAdmin”。 进入Ranger WebUI登录界面,MRS 1.9.2版本集群默认用户名/默认密码为admin/admin@12345,MRS 1.9.3版本集群默认用户名/默认密码为admin/ranger@A1!。 首次登录Ranger WebUI界面后请修改用户密码并妥善保存。 用户可以单击右上角的用户名,选择下拉菜单中的“Profile”,并选择“Change Password”修改用户密码。 图1 修改Ranger WebUI登录密码 修改完用户密码后,单击右上角用户名,选择下拉菜单中的“Log Out”,并使用新的密码重新进行登录。
  • 使用Ranger UserSync同步集群节点上的Unix操作系统用户 Ranger UserSync是Ranger中一个重要的组件,它支持将Unix系统用户或LDAP用户同步到Ranger WebUI中,目前MRS服务只支持同步Ranger UserSync进程所在节点上的Unix用户。 登录到UserSync进程所在的节点。 执行useradd命令新增系统用户,例如“testuser”。 图2 新增系统用户testuser 用户添加完成后等待1分钟左右,登录到Ranger WebUI,即可查看到该用户已经同步成功。 图3 用户同步完成
  • HDFS可靠性 MRS使用HDFS的副本机制来保证数据的可靠性,HDFS中每保存一个文件则自动生成1个备份文件,即共2个副本。HDFS副本数可通过“dfs.replication”参数查询。 当MRS集群中Core节点规格选择为非本地盘(hdd)时,若集群中只有一个Core节点,则HDFS默认副本数为1。若集群中Core节点数大于等于2,则HDFS默认副本数为2。 当MRS集群中Core节点规格选择为本地盘(hdd)时,若集群中只有一个Core节点,则HDFS默认副本数为1。若集群中有两个Core节点,则HDFS默认副本数为2。若集群中Core节点数大于等于3,则HDFS默认副本数为3。 图3 HDFS架构 MRS支持HDFS组件上节点均衡调度和单节点内的磁盘均衡调度,有助于扩容节点或扩容磁盘后的HDFS存储性能提升。 关于Hadoop的架构和详细原理介绍,请参见:http://hadoop.apache.org/。
  • HDFS结构 HDFS包含主、备NameNode和多个DataNode,如图1所示。 HDFS是一个Master/Slave的架构,在Master上运行NameNode,而在每一个Slave上运行DataNode,ZKFC需要和NameNode一起运行。 NameNode和DataNode之间的通信都是建立在TCP/IP的基础之上的。NameNode、DataNode、ZKFC和JournalNode能部署在运行Linux的服务器上。 图1 HA HDFS结构 图1中各模块的功能说明如表1所示。 表1 模块说明 名称 描述 NameNode 用于管理文件系统的命名空间、目录结构、元数据信息以及提供备份机制等,分为: Active NameNode:管理文件系统的命名空间、维护文件系统的目录结构树以及元数据信息;记录写入的每个“数据块”与其归属文件的对应关系。 Standby NameNode:与Active NameNode中的数据保持同步;随时准备在Active NameNode出现异常时接管其服务。 Observer NameNode:与Active NameNode中的数据保持同步,处理来自客户端的读请求。 DataNode 用于存储每个文件的“数据块”数据,并且会周期性地向NameNode报告该DataNode的数据存放情况。 JournalNode HA集群下,用于同步主备NameNode之间的元数据信息。 ZKFC ZKFC是需要和NameNode一一对应的服务,即每个NameNode都需要部署ZKFC。它负责监控NameNode的状态,并及时把状态写入ZooKeeper。ZKFC也有选择谁作为Active NameNode的权利。 ZK Cluster ZooKeeper是一个协调服务,帮助ZKFC执行主NameNode的选举。 HttpFS gateway HttpFS是个单独无状态的gateway进程,对外提供webHDFS接口,对HDFS使用FileSystem接口对接。可用于不同Hadoop版本间的数据传输,及用于访问在防火墙后的HDFS(HttpFS用作gateway)。 HDFS HA架构 HA即为High Availability,用于解决NameNode单点故障问题,该特性通过主备的方式为主NameNode提供一个备用者,一旦主NameNode出现故障,可以迅速切换至备NameNode,从而不间断对外提供服务。 在一个典型HDFS HA场景中,通常由两个NameNode组成,一个处于Active状态,另一个处于Standby状态。 为了能实现Active和Standby两个NameNode的元数据信息同步,需提供一个共享存储系统。本版本提供基于QJM(Quorum Journal Manager)的HA解决方案,如图2所示。主备NameNode之间通过一组JournalNode同步元数据信息。 通常配置奇数个(2N+1个)JournalNode,且最少要运行3个JournalNode。这样,一条元数据更新消息只要有N+1个JournalNode写入成功就认为数据写入成功,此时最多容忍N个JournalNode写入失败。比如,3个JournalNode时,最多允许1个JournalNode写入失败,5个JournalNode时,最多允许2个JournalNode写入失败。 由于JournalNode是一个轻量级的守护进程,可以与Hadoop其它服务共用机器。建议将JournalNode部署在控制节点上,以避免数据节点在进行大数据量传输时引起JournalNode写入失败。 图2 基于QJM的HDFS架构
  • 创建集群前的准备 评估集群节点规格 您可以根据数据量、业务负载以及性能需求,选择能够支撑业务应用的节点数量,数量越多,存储与计算能力越强。 刚开始使用 GaussDB (DWS) 服务时,您也可以先创建一个规格较小的集群,今后随着数据量和业务负载的变化,再自由调整集群规模和节点规格,自由扩展而不中断业务。详情请参见扩容集群。 请确定用户可使用的节点数满足如下条件,否则系统会提示无法创建集群。 用户可使用的节点数大于或者等于3。用户可使用的节点数可在“集群管理”页面查看。
  • 数据保护技术 流水线通过多种数据保护手段和特性,保证通过流水线的数据安全可靠。 表1 流水线的数据保护手段和特性 数据保护手段 简要说明 详细介绍 传输加密(HTTPS) 流水线所有API均采用HTTPS传输协议。 构造请求 个人数据保护 流水线通过控制个人数据访问权限以及记录操作日志等方法防止个人数据泄露,保证您的个人数据安全。 云审计 服务支持的操作列表 隐私数据保护 涉及到用户的数据库账号信息需要存储时,提供敏感 数据加密 存储。 - 数据备份 支持用户数据备份。 - 父主题: 安全
  • 示例代码 为便于理解函数的使用方法,本文为您提供源数据,基于源数据提供函数相关示例。创建表logs,并添加数据,命令示例如下: create table logs( cookieid string, createtime string, url string ) STORED AS parquet; 添加数据如下: cookie1 2015-04-10 10:00:02 url2 cookie1 2015-04-10 10:00:00 url1 cookie1 2015-04-10 10:03:04 url3 cookie1 2015-04-10 10:50:05 url6 cookie1 2015-04-10 11:00:00 url7 cookie1 2015-04-10 10:10:00 url4 cookie1 2015-04-10 10:50:01 url5 cookie2 2015-04-10 10:00:02 url22 cookie2 2015-04-10 10:00:00 url11 cookie2 2015-04-10 10:03:04 url33 cookie2 2015-04-10 10:50:05 url66 cookie2 2015-04-10 11:00:00 url77 cookie2 2015-04-10 10:10:00 url44 cookie2 2015-04-10 10:50:01 url55 示例:将所有记录根据cookieid分组,并按createtime升序排列,返回每组中的最后一行数据。命令示例如下 SELECT cookieid, createtime, url, LAST_VALUE(url) OVER(PARTITION BY cookieid ORDER BY createtime) AS last FROM logs; -- 返回结果: cookieid createtime url last cookie1 2015-04-10 10:00:00 url1 url1 cookie1 2015-04-10 10:00:02 url2 url2 cookie1 2015-04-10 10:03:04 url3 url3 cookie1 2015-04-10 10:10:00 url4 url4 cookie1 2015-04-10 10:50:01 url5 url5 cookie1 2015-04-10 10:50:05 url6 url6 cookie1 2015-04-10 11:00:00 url7 url7 cookie2 2015-04-10 10:00:00 url11 url11 cookie2 2015-04-10 10:00:02 url22 url22 cookie2 2015-04-10 10:03:04 url33 url33 cookie2 2015-04-10 10:10:00 url44 url44 cookie2 2015-04-10 10:50:01 url55 url55 cookie2 2015-04-10 10:50:05 url66 url66 cookie2 2015-04-10 11:00:00 url77 url77 截止到当前行的最后一个值,其实就是它本身。
  • 参数说明 表1 参数说明 参数 是否必选 说明 expr 是 待计算返回结果的表达式。 ignore_nulls 否 BOOLEAN类型,表示是否忽略NULL值。默认值为False。 当参数的值为True时,返回窗口中第一条非NULL的值。 partition_clause 否 指定分区。分区列的值相同的行被视为在同一个窗口内。 orderby_clause 否 指定数据在一个窗口内如何排序。 frame_clause 否 用于确定数据边界。
  • 示例代码 为便于理解函数的使用方法,本文为您提供源数据,基于源数据提供函数相关示例。创建表salary,并添加数据,命令示例如下: CREATE EXTERNAL TABLE salary ( dept STRING, -- 部⻔名称 userid string, -- 员⼯ID sal INT -- 薪⽔ ) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' stored as textfile; 添加数据如下: d1,user1,1000 d1,user2,2000 d1,user3,3000 d2,user4,4000 d2,user5,5000 统计小于等于当前薪水的人数占比 select dept, userid, sal, cume_dist() over(order by sal) as cume1 from salary; -- 结果: d1 user1 1000 0.2 d1 user2 2000 0.4 d1 user3 3000 0.6 d2 user4 4000 0.8 d2 user5 5000 1.0 按部⻔分组统计⼩于等于当前薪⽔的⼈数的⽐例 select dept, userid, sal, cume_dist() over (partition by dept order by sal) as cume2 from salary; -- 结果: d1 user1 1000 0.3333333333333333 d1 user2 2000 0.6666666666666666 d1 user3 3000 1.0 d2 user4 4000 0.5 d2 user5 5000 1.0 按照sal降序排序后,结果就是统计 ⼤于等于 当前薪⽔的⼈数的⽐例 select dept, userid, sal, cume_dist() over(order by sal desc) as cume3 from salary; -- 结果: d2 user5 5000 0.2 d2 user4 4000 0.4 d1 user3 3000 0.6 d1 user2 2000 0.8 d1 user1 1000 1.0 select dept, userid, sal, cume_dist() over(partition by dept order by sal desc) as cume4 from salary; -- 结果: d1 user3 3000 0.3333333333333333 d1 user2 2000 0.6666666666666666 d1 user1 1000 1.0 d2 user5 5000 0.5 d2 user4 4000 1.0
  • 示例代码 示例数据 为便于理解函数的使用方法,本文为您提供源数据,基于源数据提供函数相关示例。创建表logs,并添加数据,命令示例如下: create table logs( cookieid string, createtime string, url string ) STORED AS parquet; 添加数据如下: cookie1 2015-04-10 10:00:02 url2 cookie1 2015-04-10 10:00:00 url1 cookie1 2015-04-10 10:03:04 url3 cookie1 2015-04-10 10:50:05 url6 cookie1 2015-04-10 11:00:00 url7 cookie1 2015-04-10 10:10:00 url4 cookie1 2015-04-10 10:50:01 url5 cookie2 2015-04-10 10:00:02 url22 cookie2 2015-04-10 10:00:00 url11 cookie2 2015-04-10 10:03:04 url33 cookie2 2015-04-10 10:50:05 url66 cookie2 2015-04-10 11:00:00 url77 cookie2 2015-04-10 10:10:00 url44 cookie2 2015-04-10 10:50:01 url55 将所有记录根据cookieid分组,并按createtime升序排列,返回窗口内往上第2行的值。命令示例如下 示例1: SELECT cookieid, createtime, url, LAG(createtime, 2) OVER (PARTITION BY cookieid ORDER BY createtime) AS last_2_time FROM logs; -- 返回结果: cookieid createtime url last_2_time cookie1 2015-04-10 10:00:00 url1 NULL cookie1 2015-04-10 10:00:02 url2 NULL cookie1 2015-04-10 10:03:04 url3 2015-04-10 10:00:00 cookie1 2015-04-10 10:10:00 url4 2015-04-10 10:00:02 cookie1 2015-04-10 10:50:01 url5 2015-04-10 10:03:04 cookie1 2015-04-10 10:50:05 url6 2015-04-10 10:10:00 cookie1 2015-04-10 11:00:00 url7 2015-04-10 10:50:01 cookie2 2015-04-10 10:00:00 url11 NULL cookie2 2015-04-10 10:00:02 url22 NULL cookie2 2015-04-10 10:03:04 url33 2015-04-10 10:00:00 cookie2 2015-04-10 10:10:00 url44 2015-04-10 10:00:02 cookie2 2015-04-10 10:50:01 url55 2015-04-10 10:03:04 cookie2 2015-04-10 10:50:05 url66 2015-04-10 10:10:00 cookie2 2015-04-10 11:00:00 url77 2015-04-10 10:50:01 说明:因为没有设置默认值,当没有上两行时显示为NULL。 示例2: SELECT cookieid, createtime, url, LAG(createtime,1,'1970-01-01 00:00:00') OVER (PARTITION BY cookieid ORDER BY createtime) AS last_1_time FROM cookie4; -- 结果: cookieid createtime url last_1_time cookie1 2015-04-10 10:00:00 url1 1970-01-01 00:00:00 (显示默认值) cookie1 2015-04-10 10:00:02 url2 2015-04-10 10:00:00 cookie1 2015-04-10 10:03:04 url3 2015-04-10 10:00:02 cookie1 2015-04-10 10:10:00 url4 2015-04-10 10:03:04 cookie1 2015-04-10 10:50:01 url5 2015-04-10 10:10:00 cookie1 2015-04-10 10:50:05 url6 2015-04-10 10:50:01 cookie1 2015-04-10 11:00:00 url7 2015-04-10 10:50:05 cookie2 2015-04-10 10:00:00 url11 1970-01-01 00:00:00 (显示默认值) cookie2 2015-04-10 10:00:02 url22 2015-04-10 10:00:00 cookie2 2015-04-10 10:03:04 url33 2015-04-10 10:00:02 cookie2 2015-04-10 10:10:00 url44 2015-04-10 10:03:04 cookie2 2015-04-10 10:50:01 url55 2015-04-10 10:10:00 cookie2 2015-04-10 10:50:05 url66 2015-04-10 10:50:01 cookie2 2015-04-10 11:00:00 url77 2015-04-10 10:50:05
  • 参数说明 表1 参数说明 参数 是否必选 说明 expr 是 待计算返回结果的表达式。 offset 否 偏移量,BIGINT类型常量,取值大于等于0。值为0时表示当前行,为1时表示前一行,以此类推。默认值为1。输入值为STRING类型、DOUBLE类型则隐式转换为BIGINT类型后进行运算。 default 是 常量,默认值为NULL。 当offset指定的范围越界时的缺省值,需要与expr对应的数据类型相同。如果expr非常量,则基于当前行进行求值。 partition_clause 否 指定分区。分区列的值相同的行被视为在同一个窗口内。 orderby_clause 否 指定数据在一个窗口内如何排序。
  • 示例代码 示例数据 为便于理解函数的使用方法,本文为您提供源数据,基于源数据提供函数相关示例。创建表logs,并添加数据,命令示例如下: create table logs( cookieid string, createtime string, url string ) STORED AS parquet; 添加数据如下: cookie1 2015-04-10 10:00:02 url2 cookie1 2015-04-10 10:00:00 url1 cookie1 2015-04-10 10:03:04 url3 cookie1 2015-04-10 10:50:05 url6 cookie1 2015-04-10 11:00:00 url7 cookie1 2015-04-10 10:10:00 url4 cookie1 2015-04-10 10:50:01 url5 cookie2 2015-04-10 10:00:02 url22 cookie2 2015-04-10 10:00:00 url11 cookie2 2015-04-10 10:03:04 url33 cookie2 2015-04-10 10:50:05 url66 cookie2 2015-04-10 11:00:00 url77 cookie2 2015-04-10 10:10:00 url44 cookie2 2015-04-10 10:50:01 url55 将所有记录根据cookieid分组,并按createtime升序排列,返回窗口内往下第2行和第1行的值。命令示例如下 SELECT cookieid, createtime, url, LEAD(createtime, 2) OVER(PARTITION BY cookieid ORDER BY createtime) AS next_2_time, LEAD(createtime, 1, '1970-01-01 00:00:00') OVER(PARTITION BY cookieid ORDER BY createtime) AS next_1_time FROM logs; -- 返回结果: cookieid createtime url next_2_time next_1_time cookie1 2015-04-10 10:00:00 url1 2015-04-10 10:03:04 2015-04-10 10:00:02 cookie1 2015-04-10 10:00:02 url2 2015-04-10 10:10:00 2015-04-10 10:03:04 cookie1 2015-04-10 10:03:04 url3 2015-04-10 10:50:01 2015-04-10 10:10:00 cookie1 2015-04-10 10:10:00 url4 2015-04-10 10:50:05 2015-04-10 10:50:01 cookie1 2015-04-10 10:50:01 url5 2015-04-10 11:00:00 2015-04-10 10:50:05 cookie1 2015-04-10 10:50:05 url6 NULL 2015-04-10 11:00:00 cookie1 2015-04-10 11:00:00 url7 NULL 1970-01-01 00:00:00 cookie2 2015-04-10 10:00:00 url11 2015-04-10 10:03:04 2015-04-10 10:00:02 cookie2 2015-04-10 10:00:02 url22 2015-04-10 10:10:00 2015-04-10 10:03:04 cookie2 2015-04-10 10:03:04 url33 2015-04-10 10:50:01 2015-04-10 10:10:00 cookie2 2015-04-10 10:10:00 url44 2015-04-10 10:50:05 2015-04-10 10:50:01 cookie2 2015-04-10 10:50:01 url55 2015-04-10 11:00:00 2015-04-10 10:50:05 cookie2 2015-04-10 10:50:05 url66 NULL 2015-04-10 11:00:00 cookie2 2015-04-10 11:00:00 url77 NULL 1970-01-01 00:00:00
  • 参数说明 表1 参数说明 参数 是否必选 说明 expr 是 待计算返回结果的表达式。 offset 否 偏移量,BIGINT类型常量,取值大于等于0。值为0时表示当前行,为1时表示前一行,以此类推。默认值为1。输入值为STRING类型、DOUBLE类型则隐式转换为BIGINT类型后进行运算。 default 是 常量,默认值为NULL。 当offset指定的范围越界时的缺省值,需要与expr对应的数据类型相同。如果expr非常量,则基于当前行进行求值。 partition_clause 否 指定分区。分区列的值相同的行被视为在同一个窗口内。 orderby_clause 否 指定数据在一个窗口内如何排序。
  • 示例代码 为便于理解函数的使用方法,本文为您提供源数据,基于源数据提供函数相关示例。创建表logs,并添加数据,命令示例如下: CREATE TABLE logs ( cookieid string, createtime string, pv INT ) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' stored as textfile; 添加数据如下: cookie1 2015-04-10 1 cookie1 2015-04-11 5 cookie1 2015-04-12 7 cookie1 2015-04-13 3 cookie1 2015-04-14 2 cookie1 2015-04-15 4 cookie1 2015-04-16 4 cookie2 2015-04-10 2 cookie2 2015-04-11 3 cookie2 2015-04-12 5 cookie2 2015-04-13 6 cookie2 2015-04-14 3 cookie2 2015-04-15 9 cookie2 2015-04-16 7 示例:将所有记录根据cookieid分组,并按pv降序排列,返回组内每行的序号。命令示例如下: select cookieid, createtime, pv, rank() over(partition by cookieid order by pv desc) as rank from logs where cookieid = 'cookie1'; -- 结果: cookie1 2015-04-12 7 1 cookie1 2015-04-11 5 2 cookie1 2015-04-16 4 3 (并列第三) cookie1 2015-04-15 4 3 cookie1 2015-04-13 3 5 (跳过4,从5开始) cookie1 2015-04-14 2 6 cookie1 2015-04-10 1 7
  • 示例代码 为便于理解函数的使用方法,本文为您提供源数据,基于源数据提供函数相关示例。创建表logs,并添加数据,命令示例如下: CREATE TABLE logs ( cookieid string, createtime string, pv INT ) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' stored as textfile; 添加数据如下: cookie1 2015-04-10 1 cookie1 2015-04-11 5 cookie1 2015-04-12 7 cookie1 2015-04-13 3 cookie1 2015-04-14 2 cookie1 2015-04-15 4 cookie1 2015-04-16 4 cookie2 2015-04-10 2 cookie2 2015-04-11 3 cookie2 2015-04-12 5 cookie2 2015-04-13 6 cookie2 2015-04-14 3 cookie2 2015-04-15 9 cookie2 2015-04-16 7 示例:将所有记录根据cookieid分组,并按pv降序排列,返回组内每行的序号。命令示例如下: select cookieid, createtime, pv, row_number() over (partition by cookieid order by pv desc) as index from logs; -- 返回结果: cookie1 2015-04-12 7 1 cookie1 2015-04-11 5 2 cookie1 2015-04-16 4 3 cookie1 2015-04-15 4 4 cookie1 2015-04-13 3 5 cookie1 2015-04-14 2 6 cookie1 2015-04-10 1 7 cookie2 2015-04-15 9 1 cookie2 2015-04-16 7 2 cookie2 2015-04-13 6 3 cookie2 2015-04-12 5 4 cookie2 2015-04-11 3 5 cookie2 2015-04-14 3 6 cookie2 2015-04-10 2 7
  • 参数说明 表1 参数说明 参数 是否必选 说明 expr 是 待计算返回结果的表达式。 ignore_nulls 否 BOOLEAN类型,表示是否忽略NULL值。默认值为False。 当参数的值为True时,返回窗口中第一条非NULL的值。 partition_clause 否 指定分区。分区列的值相同的行被视为在同一个窗口内。 orderby_clause 否 指定数据在一个窗口内如何排序。 frame_clause 否 用于确定数据边界。
  • 示例代码 示例数据 为便于理解函数的使用方法,本文为您提供源数据,基于源数据提供函数相关示例。创建表logs,并添加数据,命令示例如下: create table logs( cookieid string, createtime string, url string ) STORED AS parquet; 添加数据如下: cookie1 2015-04-10 10:00:02 url2 cookie1 2015-04-10 10:00:00 url1 cookie1 2015-04-10 10:03:04 url3 cookie1 2015-04-10 10:50:05 url6 cookie1 2015-04-10 11:00:00 url7 cookie1 2015-04-10 10:10:00 url4 cookie1 2015-04-10 10:50:01 url5 cookie2 2015-04-10 10:00:02 url22 cookie2 2015-04-10 10:00:00 url11 cookie2 2015-04-10 10:03:04 url33 cookie2 2015-04-10 10:50:05 url66 cookie2 2015-04-10 11:00:00 url77 cookie2 2015-04-10 10:10:00 url44 cookie2 2015-04-10 10:50:01 url55 示例:将所有记录根据cookieid分组,并按createtime升序排列,返回每组中的第一行数据。命令示例如下 SELECT cookieid, createtime, url, FIRST_VALUE(url) OVER (PARTITION BY cookieid ORDER BY createtime) AS first FROM logs; 返回结果如下: cookieid createtime url first cookie1 2015-04-10 10:00:00 url1 url1 cookie1 2015-04-10 10:00:02 url2 url1 cookie1 2015-04-10 10:03:04 url3 url1 cookie1 2015-04-10 10:10:00 url4 url1 cookie1 2015-04-10 10:50:01 url5 url1 cookie1 2015-04-10 10:50:05 url6 url1 cookie1 2015-04-10 11:00:00 url7 url1 cookie2 2015-04-10 10:00:00 url11 url11 cookie2 2015-04-10 10:00:02 url22 url11 cookie2 2015-04-10 10:03:04 url33 url11 cookie2 2015-04-10 10:10:00 url44 url11 cookie2 2015-04-10 10:50:01 url55 url11 cookie2 2015-04-10 10:50:05 url66 url11 cookie2 2015-04-10 11:00:00 url77 url11
  • 示例代码 示例数据 为便于理解函数的使用方法,本文为您提供源数据,基于源数据提供函数相关示例。创建表salary,并添加数据,命令示例如下: CREATE EXTERNAL TABLE salary ( dept STRING, -- 部⻔名称 userid string, -- 员⼯ID sal INT -- 薪⽔ ) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' stored as textfile; 添加数据如下: d1,user1,1000 d1,user2,2000 d1,user3,3000 d2,user4,4000 d2,user5,5000 示例:计算员工薪水在部门内的百分比排名。 select dept, userid, sal, percent_rank() over(partition by dept order by sal) as pr2 from salary; -- 结果分析: d1 user1 1000 0.0 -- (1-1)/(3-1)=0.0 d1 user2 2000 0.5 -- (2-1)/(3-1)=0.5 d1 user3 3000 1.0 -- (3-1)/(3-1)=1.0 d2 user4 4000 0.0 -- (1-1)/(2-1)=0.0 d2 user5 5000 1.0 -- (2-1)/(2-1)=1.0
  • 为什么事务调试总是失败? 在使用调试功能前,要先确认如下两点: 确保资源组为运行状态。 确保资源组的调试节点和被压测的应用之间网络互通。 登录弹性云服务控制台。 在弹性云服务器中分别找到调试机和执行机的节点并登录。 curl对应应用的URL查看网络是否连通。 满足以上两点后,对事务进行调试,单击“查看日志”查看返回内容是否正确。 如果调试功能返回内容报错,这就是使用调试功能的主要目的,需要去检查自己传入参数是否正确,检查报文配置的内容是否正确。 父主题: 压测工程管理
  • 计费项 PerfTest费用包括两部分:所使用资源(弹性云服务器)的费用和使用PerfTest的费用。 所使用资源的费用:主要用于部署PerfTest服务的执行集群,由对应的弹性云服务器服务计费,PerfTest不再单独收费。 压测资源组的节点,需提前在云容器引擎中创建,详细步骤请参考创建节点。资源组中节点由对应的弹性云服务器服务计费。 使用PerfTest的费用:PerfTest按压测所消耗的VUM收费,具体计费信息,参见产品价格详情。
  • 场景描述 购买包年/包月云应用服务器可以使用创建云服务器接口,相对于创建按需的云应用服务器,只需要在请求body中指定create_server_extend_param.charging_mode参数值为“prePaid”,即包年包月,指定订购的周期等。create_server_extend_param的详细参数解释请参见云应用API中创建云服务器的表7说明。 示例: 如下所示,在cn-north-4区域购买一台包年/包月云应用服务器,时长为一个月,且下单后自动支付,自动续订。 { "type": "createApps", "server_group_id": "266aa7aa-862b-4c46-9064-dfd057049d67", "availability_zone":"cn-north-4a", "subscription_num": 1, "product_id": "workspace.appstream.general.xlarge.2", "root_volume": { "type": "SAS", "size": 80 }, "subnet_id": "6719e894-515f-4a19-86a8-e056a839ecee", "vpc_id": "3d00f422-1968-4349-b2d0-9d72d75cc502", "update_access_agent": false, "create_server_extend_param": { "charging_mode": "prePaid", "period_type": 2, "period_num": 1, "is_auto_renew": true, "is_auto_pay": true } } 包年/包月云应用服务器创建后会返回一个order_id,即订单ID。 { "order_id": " CS 2311171xxxxxxxx" } 上面请求体中create_server_extend_param.is_auto_pay取值为true,表示自动支付,如果不填该字段或取值为false,则需要手动去支付,手动支付可以填写优惠券和折扣券等信息。 手动支付需要调用【支付包年/包月产品订单】支付,示例如下。 POST https://bss.myhuaweicloud.com/v2/orders/customer-orders/pay { "order_id": "CS2311172xxxxxxxx" }
  • 场景描述 包年/包月资源续费 包年/包月资源即将到期时,可进行包年/包月资源的续订。通过调用续订包年/包月资源接口进行续费。 示例: 如下所示,指定资源ID,按月续费,续费1个月,到期后转按需,并自动支付订单。 POST https://bss.myhuaweicloud.com/v2/orders/subscriptions/resources/renew { "resource_ids": [ "wksapp-ee96725a-e403-4c0f-88b3-0083b2a685ce" ], "period_type": 2, "period_num": 1, "expire_policy": 1, "is_auto_pay": 1 } 续费成功后会返回一个order_id,即订单ID。 { "order_ids": [ "CS2311173xxxxxxxx" ] } 上面请求体中is_auto_pay取值为1,表示自动支付,如果不填该字段或取值为0,则需要手动去支付,手动支付可以填写优惠券和折扣券等信息。expire_policy为到期策略(字段已废弃,请勿使用该字段。此字段必填,需携带,但携带的枚举实际并不生效)。
  • resilience_escape_user_permissions 参数说明:设置用户权限,以逗号分隔,可以设置多个,设置多个则表示多个特殊权限的用户都支持逃生能力,只设置一个则只针对一个特权用户进行逃生。sysadmin控制sysadmin用户的作业是否会被该逃生功能进行cancel处理;monadmin控制monadmin用户的作业是否会被该逃生功能进行cancel处理;默认为空,表示关闭sysadmin和monadmin用户的逃生能力。当前取值仅支持sysadmin,monadmin或者空字符串。该参数属于SIGHUP类型参数,请参考表1中对应设置方法进行设置。 取值范围:字符串,长度大于0。 该参数目前只支持三个取值:sysadmin,monadmin或'',这几个值的具体含义如下: sysadmin:控制sysadmin用户的作业是否会被该逃生功能进行cancel处理。 monadmin:控制monadmin用户的作业是否会被该逃生功能进行cancel处理。 '':关闭sysadmin和monadmin用户的逃生能力。 默认值:'',关闭sysadmin和monadmin用户的逃生能力。 示例: resilience_escape_user_permissions = 'sysadmin,monadmin' 表示同时开启sysadmin和monadmin用户的逃生功能。 该参数可以同时设置多个值,以逗号分隔,例如resilience_escape_user_permissions = 'sysadmin,monadmin',也可以只设置一个值,例如resilience_escape_user_permissions = 'monadmin'。 若该参数多次设置,以最新的设置生效。 该参数设置为取值范围中的任意值,普通用户都支持该逃生功能。 当用户同时具有sysadmin和monadmin时,resilience_escape_user_permissions必须要同时设置'sysadmin,monadmin'才能触发该用户的逃生功能。
  • resilience_memory_reject_percent 参数说明:用于控制内存过载逃生的动态内存占用百分比。该参数仅在GUC参数use_workload_manager和enable_memory_limit打开时生效。该参数属于SIGHUP类型参数,请参考表1中对应设置方法进行设置。 取值范围:字符串,长度大于0。 该参数分为recover_memory_percent,、overload_memory_percent 2部分,这2个部分的具体含义如下: recover_memory_percent:内存从过载状态恢复正常状态的动态内存使用占最大动态内存的百分比,当动态内存使用小于最大动态内存乘以该值对应的百分比后,停止过载逃生并放开新连接接入,取值为0~100,设置为多少表示百分之多少。 overload_memory_percent:内存过载时动态内存使用占最大动态内存的百分比,当动态内存使用大于最大动态内存乘以该值对应的百分比后,表示当前内存已经过载,触发过载逃生kill会话并禁止新连接接入,取值为0~100,设置为多少表示百分之多少。 默认值:'0,0',表示关闭内存过载逃生功能。 示例: resilience_memory_reject_percent = '70,90' 表示内存使用超过最大内存上限的90%后禁止新连接接入并kill堆积的会话,kill会话过程中内存恢复到最大内存的70%以下时停止kill会话并允许新连接接入。 最大动态内存和已使用的动态内存可以通过pv_total_memory_detail视图查询获得,最大动态内存:max_dynamic_memory,已使用的动态内存:dynamic_used_memory。 该参数如果设置的百分比过小,则会频繁触发内存过载逃生流程,会使正在执行的会话被强制退出,新连接短时间接入失败,需要根据实际内存使用情况慎重设置。 use_workload_manager参数关闭的情况下,如果打开bypass_workload_manager,则该参数也会生效,但是因为bypass_workload_manager是SIGHUP类型,reload方式设置后需要重启数据库才会使得当前功能生效。 recover_memory_percent和overload_memory_percent的值可以同时为0,除此之外,recover_memory_percent的值必须要小于overload_memory_percent,否则会设置不生效。
  • maintenance_work_mem 参数说明:设置在维护性操作(比如VACUUM、CREATE INDEX等)中可使用的最大的内存。该参数的设置会影响VACUUM、VACUUM FULL、CLUSTER、CREATE INDEX的执行效率。 该参数属于USERSET类型参数,请参考表1中对应设置方法进行设置。 取值范围:整型,1024~2147483647‬,单位为KB。 默认值: 独立部署: CN:1GB(60核CPU/480G内存);512MB(32核CPU/256G内存);256MB(16核CPU/128G内存);128MB(8核CPU/64G内存);64MB(4核CPU/32G内存);32MB(4核CPU/16G内存) DN:2GB(60核CPU/480G内存);1GB(32核CPU/256G内存);512MB(16核CPU/128G内存);256MB(8核CPU/64G内存);128MB(4核CPU/32G内存);64MB(4核CPU/16G内存) 设置建议: 建议设置此参数的值大于work_mem,可以改进清理和恢复数据库转储的速度。因为在一个数据库会话里,任意时刻只有一个维护性操作可以执行,并且在执行维护性操作时不会有太多的会话。 当自动清理线程运行时,autovacuum_max_workers倍数的内存将会被分配,所以此时设置maintenance_work_mem的值应该不小于work_mem。 如果进行大数据量的cluster等,可以在session中调大该值。
  • psort_work_mem 参数说明:设置列存表在进行局部排序中在开始写入临时磁盘文件之前使用的内存大小。带partial cluster key的表、带索引的表插入,创建表索引,删除表和更新表都会用到。 该参数属于USERSET类型参数,请参考表1中对应设置方法进行设置。 同样,好几个正在运行的会话可能会同时进行表的局部排序操作。因此使用的总内存可能是psort_work_mem的好几倍。 取值范围:整型64~2147483647,单位为KB。 默认值:512MB
  • cstore_buffers 参数说明:设置列存所使用的共享缓冲区的大小。 该参数属于POSTMASTER类型参数,请参考表1中对应设置方法进行设置。 取值范围:整型,16384~1073741823,单位为KB。 默认值:32MB 设置建议: 列存表使用cstore_buffers设置的共享缓冲区,几乎不用shared_buffers。因此在列存表为主的场景中,应减少shared_buffers,增加cstore_buffers。
  • max_stack_depth 参数说明:设置GaussDB执行堆栈的最大安全深度。需要这个安全界限是因为在服务器里,并非所有程序都检查了堆栈深度,只是在可能递规的过程,比如表达式计算这样的过程里面才进行检查。 该参数属于SUSET类型参数,请参考表1中对应设置方法进行设置。 取值范围:整型,100~2147483647‬,单位为KB。 默认值: (ulimit -s的设置)- 640 KB的值大于等于2MB时,此参数的默认值为2MB。 (ulimit -s的设置)- 640 KB的值小于2MB时,此参数的默认值为(ulimit -s的设置)- 640 KB。 设置原则: 数据库需要预留640KB堆栈深度,因此此参数可设置的最大值等于操作系统内核允许的最大值(就是ulimit -s的设置)- 640KB。 数据库未运行前设置的该参数值大于(ulimit -s的设置)- 640 KB时会导致数据库启动失败;数据库运行阶段设置该参数值大于(ulimit -s的设置)- 640 KB时该值不生效。 若(ulimit -s的设置)-640KB小于此参数取值范围的最小值时会导致数据库启动失败。 如果设置此参数的值大于实际的内核限制,则一个正在运行的递归函数可能会导致一个独立的服务器进程崩溃。 因为并非所有的操作都能够检测,所以建议用户在此设置一个明确的值。 默认值最大为2MB,这个值相对比较小,不容易导致系统崩溃。
共100000条