云服务器内容精选

  • 数据湖 准备 在本示例中,选择 数据湖探索 DLI )服务作为数据湖。为确保 DataArts Studio 与DLI网络互通,在创建DLI队列时区域和企业项目应与DataArts Studio实例保持一致。 当前由于DLI的“default”队列默认Spark组件版本较低,可能会出现无法支持建表语句执行的报错,这种情况下建议您选择自建队列运行业务。如需“default”队列支持建表语句执行,可联系DLI服务客服或技术支持人员协助解决。 DLI的“default”队列为共享队列,仅用于用户体验,用户间可能会出现抢占资源的情况,不能保证每次都可以得到资源执行相关操作。当遇到执行时间较长或无法执行的情况,建议您在业务低峰期再次重试,或选择自建队列运行业务。 开通DLI服务后,您需要在管理中心创建DLI连接,然后通过数据开发组件新建数据库,再执行SQL来创建OBS外表。操作步骤如下: 参考访问DataArts Studio实例控制台,登录DataArts Studio管理控制台。 在DataArts Studio控制台首页,选择对应工作空间的“管理中心”模块,进入管理中心页面。 在“数据连接”页面,单击“创建数据连接”按钮。 图1 数据连接 创建一个到DLI的连接,数据连接类型选择“数据湖探索(DLI)”,数据连接名称设置为“dli”。 完成设置后,单击“测试”,测试成功后单击“确定”,完成DLI数据连接的创建。 图2 创建数据连接 DLI连接创建完成后,跳转到数据开发页面。 图3 跳转到数据开发页面 参见图4,在DLI连接上右键单击,创建一个数据库用于存放数据表,数据库名称为“BI”。 图4 创建数据库 创建一个DLI SQL脚本,以通过DLI SQL语句来创建数据表。 图5 新建脚本 在新建脚本弹出的SQL编辑器中输入如下SQL语句,并单击“运行”来创建数据表。其中,user、product、comment、action为OBS外表,使用指定OBS路径中的 CS V文件来填充数据,用于存放原始数据;top_like_product和top_bad_comment_product为DLI表,用于存放分析结果。 create table user( user_id int, age int, gender int, rank int, register_time string ) USING csv OPTIONS (path "obs://fast-demo/user_data"); create table product( product_id int, a1 int, a2 int, a3 int, category int, brand int ) USING csv OPTIONS (path "obs://fast-demo/product_data"); create table comment( deadline string, product_id int, comment_num int, has_bad_comment int, bad_comment_rate float ) USING csv OPTIONS (path "obs://fast-demo/comment_data"); create table action( user_id int, product_id int, time string, model_id string, type string ) USING csv OPTIONS (path "obs://fast-demo/action_data"); create table top_like_product(brand int, like_count int); create table top_bad_comment_product(product_id int, comment_num int, bad_comment_rate float); 图6 创建数据表 关键参数说明: 数据连接:步骤4中创建的DLI数据连接。 数据库:步骤6中创建的数据库。 资源队列:可使用提供的默认资源队列“default”。 当前由于DLI的“default”队列默认Spark组件版本较低,可能会出现无法支持建表语句执行的报错,这种情况下建议您选择自建队列运行业务。如需“default”队列支持建表语句执行,可联系DLI服务客服或技术支持人员协助解决。 DLI的“default”队列为共享队列,仅用于用户体验,用户间可能会出现抢占资源的情况,不能保证每次都可以得到资源执行相关操作。当遇到执行时间较长或无法执行的情况,建议您在业务低峰期再次重试,或选择自建队列运行业务。 脚本运行成功后,可以通过如下脚本检查数据表是否创建成功。 SHOW TABLES; 确认数据表创建成功后,该脚本后续无需使用,可直接关闭。
  • 方案说明 DataArts Studio数据开发模块支持以事件触发的方式运行作业,因此通过DIS或者 MRS Kafka作为作业依赖纽带,可以跨空间实现作业调度。 如下图,工作空间A中的job1运行完成后,可以使用DIS Client或Kafka Client发送消息触发中继作业job_agent;job_agent配置事件触发调度,根据DIS Client或Kafka Client发送的消息触发运行后,判断消息是否符合预期,符合则触发job2作业运行,否则不再触发job2运行。 图1 调度方案
  • 配置方法(Kafka Client) 登录DataArts Studio控制台,找到所需要的DataArts Studio实例,单击实例卡片上的“进入控制台”,进入概览页面。 单击第一个工作空间A的“数据开发”,系统跳转至数据开发页面,新建数据开发作业job1。分别选择Dummy节点和Kafka Client节点,选中连线图标并拖动,编排如图7所示的作业。 Dummy节点不执行任何操作,本例选择Dummy节点仅为演示操作,实际使用中您可以用其他作业节点替代。 Kafka Client节点用于发送消息。您需要选择Kafka连接和Topic名称,并将发送数据配置为EL表达式job1,#{DateUtil.getDay(Job.startTime)}。则当本作业执行完成后,将使用Kafka Client发送一条字符串消息:job1,作业执行日期。例如2月15日作业job1执行,实际的消息则为:job1,15。 作业调度等其他作业参数无需配置,保持默认即可。 图7 job1作业Kafka Client节点配置 在另一个工作空间B,新建数据开发作业job_agent。分别选择Dummy节点和Subjob节点,选中连线图标并拖动,编排图8所示的作业。 图8 job_agent作业调度配置 Dummy节点不执行任何操作,本例选择Dummy节点用于设置Dummy节点到Subjob节点之间连线的IF条件。 Subjob节点用于将需要后续执行的作业job2作为子作业引用执行。实际使用中您可以引用已有作业,也可以使用其他作业节点替代Subjob节点。 作业的调度方式设置为“事件驱动调度”,连接名称和Topic选择为工作空间B中的Kafka连接和Topic,需要与工作空间A中job1作业中Kafka Client节点所选择的Kafka连接和Topic相对应,用于通过Kafka消息触发作业运行。 IF判断条件设置,用于校验Kafka Client节点发送的消息是否符合预期,符合才会继续执行Subjob节点,否则跳过。 右键单击连线,选择“设置条件”,在弹出的“编辑参数表达式”文本框中输入IF判断条件,失败策略保持默认即可。IF判断条件为通过EL表达式语法填写三元表达式,当三元表达式结果为true的时候,才会执行连线后面的节点,否则后续节点将被跳过。 #{StringUtil.equals(StringUtil.split(Job.eventData,',')[1],'21')} 该IF判断条件表示,仅当从Kafka通道获取的消息逗号后的部分为“21”时,即每月21日时,才执行后续的作业节点。 如果您需要匹配多条消息记录,可以添加多个Dummy节点并分别添加到Subjob节点的IF条件,然后将数据开发组件配置项中的“多IF策略”设置为“逻辑或”即可。 图9 编辑参数表达式 测试运行作业job_agent,在工作空间A的作业job1未运行的情况下,前往实例监控中查看执行结果是否符合预期。 由于作业job1未运行即未发送消息,则job_agent作业中的Subjob节点被跳过,证明IF条件判断生效。 图10 Subjob节点被跳过 启动调度job_agent。然后测试运行工作空间A作业job1,待job1实例运行成功后,前往工作空间B实例监控中查看作业运行结果是否符合预期。 job_agent被触发运行。 如果当天日期和IF条件中的日期匹配,则job_agent作业中的Subjob节点成功运行、子作业job2也执行完成。否则Subjob节点被跳过。 图11 Subjob节点成功运行
  • 配置方法(DIS Client) 登录DataArts Studio控制台,找到所需要的DataArts Studio实例,单击实例卡片上的“进入控制台”,进入概览页面。 单击第一个工作空间A的“数据开发”,系统跳转至数据开发页面,新建数据开发作业job1。分别选择Dummy节点和DIS Client节点,选中连线图标并拖动,编排如图2所示的作业。 Dummy节点不执行任何操作,本例选择Dummy节点仅为演示操作,实际使用中您可以用其他作业节点替代。 DIS Client节点用于发送消息。您需要选择DIS所属Region和通道,并将发送数据配置为EL表达式job1,#{DateUtil.getDay(Job.startTime)}。则当本作业执行完成后,将使用DIS Client发送一条字符串消息:job1,作业执行日期。例如2月15日作业job1执行,实际的消息则为:job1,15。 作业调度等其他作业参数无需配置,保持默认即可。 图2 job1作业DIS Client节点配置 在另一个工作空间B,新建数据开发作业job_agent。分别选择Dummy节点和Subjob节点,选中连线图标并拖动,编排图3所示的作业。 图3 job_agent作业调度配置 Dummy节点不执行任何操作,本例选择Dummy节点用于设置Dummy节点到Subjob节点之间连线的IF条件。 Subjob节点用于将需要后续执行的作业job2作为子作业引用执行。实际使用中您可以引用已有作业,也可以使用其他作业节点替代Subjob节点。 作业的调度方式设置为“事件驱动调度”,DIS通道名称选择为工作空间A中job1作业中DIS Client节点所选择的通道,用于通过DIS消息触发作业运行。 IF判断条件设置,用于校验DIS Client节点发送的消息是否符合预期,符合才会继续执行Subjob节点,否则跳过。 右键单击连线,选择“设置条件”,在弹出的“编辑参数表达式”文本框中输入IF判断条件,失败策略保持默认即可。IF判断条件为通过EL表达式语法填写三元表达式,当三元表达式结果为true的时候,才会执行连线后面的节点,否则后续节点将被跳过。 #{StringUtil.equals(StringUtil.split(Job.eventData,',')[1],'21')} 该IF判断条件表示,仅当从DIS通道获取的消息逗号后的部分为“21”时,即每月21日时,才执行后续的作业节点。 如果您需要匹配多条消息记录,可以添加多个Dummy节点并分别添加到Subjob节点的IF条件,然后将数据开发组件配置项中的“多IF策略”设置为“逻辑或”即可。 图4 编辑参数表达式 测试运行作业job_agent,在工作空间A的作业job1未运行的情况下,前往实例监控中查看执行结果是否符合预期。 由于作业job1未运行即未发送消息,则job_agent作业中的Subjob节点被跳过,证明IF条件判断生效。 图5 Subjob节点被跳过 启动调度job_agent。然后测试运行工作空间A作业job1,待job1实例运行成功后,前往工作空间B实例监控中查看作业运行结果是否符合预期。 job_agent被触发运行。 如果当天日期和IF条件中的日期匹配,则job_agent作业中的Subjob节点成功运行、子作业job2也执行完成。否则Subjob节点被跳过。 图6 Subjob节点成功运行
  • 数据清洗说明 在做日志接入创建日志空间时可以配置算子清洗策略完成日志数据清洗,如图2所示,算子清洗功能及使用样例请参见算子清洗功能介绍。 图2 算子清洗 清洗规则:选择“算子清洗”。 日志样例:使用典型日志,用来做清洗验证。 解析脚本:配置解析脚本,将日志样例清洗为字段显示。解析脚本中不支持使用中划线,支持使用下划线。 清洗字段:配置解析脚本后单击“配置解析脚本”,自动生成清洗自动,查看字段是否符合预期。
  • 解决方案 本章节介绍如何通过AppStage运维中心完成对业务实时数据的接入、处理、开发与应用。 图1 数据开发与应用流程 数据接入 AppStage运维中心支持接入虚拟机日志和容器日志,您可以根据日志类型选择日志接入方式。 虚拟机日志接入:通过日志配置下发任务部署filebeat,并根据日志采集配置设置,通过filebeat采集虚拟机上的业务日志。 容器日志接入:安装daemonset插件,通过daemonset实现容器日志接入。 (可选)如果需要将原始日志转化为JSON格式,可以在日志接入时选择算子清洗方式对日志数据做清洗,数据清洗如数据清洗说明所示。 数据导流 接入的日志数据存在于对应的Topic中,需要创建导流任务,将数据存储在对应的数据库中才能进行日志检索、日志数据的管理和后续开发。 (可选)数据汇聚:当日志量较大且不需要关注原始日志时可以对实时日志进行日志汇聚。 数据开发 可以使用存入数据库中的数据进行报表开发、实时监控或者异常告警等应用,可以直接写SQL,但是不同数据源写SQL的方式有差异,且有一定难度,AppStage支持使用运维数仓的方式,会自动根据不同数据源生成对应的SQL。 创建逻辑主体:使用运维数仓时首先需要创建逻辑主体。 创建指标:逻辑主体创建成功后,需要创建数据指标。 (可选)创建视图:为需要计算的指标创建查询视图,也可以在查询视图的基础上创建持久化视图或长期存储视图。 数据应用 使用报表对业务进行实时监控:使用运维数仓中的指标或视图创建业务报表,实时监控业务数据。 通过日志检索进行问题定位:日志接入并创建导流任务后,可以对已接入的日志进行检索,定位业务异常问题。 数据异常告警:支持通过异常检测上报告警和配置虚拟机异常告警,根据业务需要进行配置。
  • 背景信息 随着业务数量增多,业务的数据开发需求也逐渐增多, 数据开发人员不能快速支撑业务的开发需求,了解业务的人员设计和开发业务的数据资产可以使数据发挥最大价值,因此需要业务人员来主导业务的 数据治理 开发工作。 数据治理的核心就是管理好业务的数据资产,随着业务特性和业务复杂度快速增长,面临的不再是无数据的时代,面临的问题是如何在数据世界中获取到准确且有价值的信息,例如同一个指标在不同的应用场景,哪个才是准确的?这么多数据我的业务监控是否都覆盖了?以及是否有无价值和未合理使用的数据等,因此如何有效管理数据资产成了当前重点关注的问题。
  • 基本原理 在 GaussDB (DWS)中,CU是列存表存储数据的最小单元。列存表每列默认存储60000行数据为一个CU,CU生成后数据固定不可更改。无论是向列存表中插入1条还是60000条数据,都只会生成一个CU,在多次插入少量数据时,由于不能有效利用列存压缩能力,从而导致数据膨胀影响查询性能和磁盘使用率。 由于CU文件数据不能更改只能追加写,对CU中的数据做更新或删除都不会真正更改这个CU。删除是将老数据在字典中标记为作废,更新是标记老数据删除后,再写入一条新记录到新CU。在对列存表进行多次更新/删除操作,会导致列存表空间膨胀,大量空间无法有效利用。 列存Delta表解决了小批量入库产生的小CU问题,但无法解决同一个CU上的并发更新产生的锁冲突问题。而实时入库的场景下,需要将insert+upsert+update操作实时并发入库,数据来源于上游的其他数据库或者应用,同时要求入库后的数据要能及时查询,且对于查询的效率要求很高。 HStore表则采用附加delta表的形式,批量插入的数据会直接写入CU,具有与列存一致的压缩优势,而被更新的列、小批量插入的数据会序列化后压缩,同时定期merge到主表CU。
  • 使用场景 GaussDB(DWS)中的HStore表, 在使用列存储格式尽量降低磁盘占用的同时,支持高并发的更新操作入库以及高性能的查询效率。因此对于实时入库和实时查询有较强诉求,以及要求具备处理传统TP事务能力的场景建议使用HStore表。 GaussDB(DWS)在8.3.0.100版本对HStore表做了优化,为保持前向兼容,保留了老的HStore表,优化后的HStore表为HStore_opt表。除了微批copy无更新入库性能要求高的场景外,HStore表的场景都可以使用HStore_opt表代替,性能更优。
  • HStore表的使用要求与建议 参数设置 依赖后台常驻线程对HStore表进行MERGE清理操作,才能保证查询性能与压缩效率,使用HStore表务必设置相关GUC参数,推荐的参数值如下: autovacuum_max_workers_hstore=3 autovacuum_max_workers=6 autovacuum=true enable_col_index_vacuum=on 入库建议(推荐使用HStore_opt表) HStore_opt表入库建议: update入库性能差,建议修改为upsert; delete入库,确定计划走索引扫描即可,用JDBC batch方式入库最佳; upsert入库,无并发冲突下开启enable_hstore_nonconflict_upsert_optimization,其他场景都关闭;enable_hstore_nonconflict_upsert_optimization即可,会自动选择最优路径; merge into入库只有在单次入库数据量超过100W/dn,且无并发数据保证无重复的情况下,建议使用。 点查建议(推荐使用HStore_opt表) HStore_opt表点查建议: 在等值过滤条件使用最多且distinct值分布相对均匀的一个列上创建二级分区(distinct值的分布过于倾斜或者个数太少的列不要创建二级分区); 除了二级分区之外的等值过滤列,如果过滤条件涉及的列在查询中基本固定,使用cbtree索引,创建索引的列数不要超过5列; 除了二级分区之外的等值过滤列,如果过滤条件涉及的列在不同查询中变化,使用gin索引,创建索引的列数不要超过5列; 所有涉及等值过滤的字符串列,都可以建表时指定bitmap索引,不限列数,后续不可修改; 时间范围过滤的列,指定为分区列; 点查返回数据量超过10W/dn的场景,索引扫描很可能不如非索引扫描,建议使用guc参数enable_seqscan对比测试下性能,灵活选择。 索引相关 索引会占用额外的空间,同时带来的点查性能提升有限,所以HStore表只建议在需要做Upsert或者有点查(这里指唯一性与接近唯一的点查) 的诉求下创建一个主键或者btree索引。 MERGE相关 由于HStore表依赖后台autovacuum来将操作MERGE到主表,所以入库速度不能超过MERGE速度,否则会导致delta表的膨胀,可以通过控制入库的并发来控制入库速度。同时由于Delta表本身的空间复用受oldestXmin的影响,如果有老事务存在可能会导致Delta空间复用不及时而产生膨胀。
  • 查看冷热表数据分布 查看单表数据分布情况。 1 2 3 4 5 6 7 SELECT * FROM pg_catalog.pg_lifecycle_table_data_distribute('lifecycle_table'); schemaname | tablename | nodename | hotpartition | coldpartition | switchablepartition | hotdatasize | colddatasize | switchabledatasize ------------+-----------------+--------------+--------------+---------------+---------------------+-------------+--------------+-------------------- public | lifecycle_table | dn_6001_6002 | p1,p2,p3,p8 | | | 96 KB | 0 bytes | 0 bytes public | lifecycle_table | dn_6003_6004 | p1,p2,p3,p8 | | | 96 KB | 0 bytes | 0 bytes public | lifecycle_table | dn_6005_6006 | p1,p2,p3,p8 | | | 96 KB | 0 bytes | 0 bytes (3 rows) 查看所有冷热表数据分布情况。 1 2 3 4 5 6 7 SELECT * FROM pg_catalog.pg_lifecycle_node_data_distribute(); schemaname | tablename | nodename | hotpartition | coldpartition | switchablepartition | hotdatasize | colddatasize | switchabledatasize ------------+-----------------+--------------+--------------+---------------+---------------------+-------------+--------------+-------------------- public | lifecycle_table | dn_6001_6002 | p1,p2,p3,p8 | | | 98304 | 0 | 0 public | lifecycle_table | dn_6003_6004 | p1,p2,p3,p8 | | | 98304 | 0 | 0 public | lifecycle_table | dn_6005_6006 | p1,p2,p3,p8 | | | 98304 | 0 | 0 (3 rows)
  • 冷热数据切换 将热分区数据切换成冷分区数据。 自动切换:每日0点调度框架自动触发,无需关注切换情况。 可使用函数pg_obs_cold_refresh_time(table_name, time)自定义自动切换时间。例如,根据业务情况调整自动触发时间为每天早晨6点30分。 1 2 3 4 5 SELECT * FROM pg_obs_cold_refresh_time('lifecycle_table', '06:30:00'); pg_obs_cold_refresh_time -------------------------- SUC CES S (1 row) 手动切换。 使用ALTER TABLE语句手动切换单表: 1 2 ALTER TABLE lifecycle_table refresh storage; ALTER TABLE 使用函数pg_refresh_storage()批量切换所有冷热表: 1 2 3 4 5 SELECT pg_catalog.pg_refresh_storage(); pg_refresh_storage -------------------- (1,0) (1 row)
  • 约束限制 支持对冷热表的insert、copy、delete、update、select等表相关的DML操作。 支持对冷热表的权限管理等DCL操作。 支持对冷热表进行analyze、vacuum、merge into等操作和一些分区的操作。 支持从普通列存分区表升级为冷热数据表。 支持带有冷热数据管理表的升级、扩容、缩容和重分布。 8.3.0及以上版本支持冷热分区互相转换,8.3.0版本之前仅支持从热数据切换为冷数据。 对于同时存在冷热分区的表,查询时会变慢,因为冷数据存储在OBS上,读写速度和时延都比在本地查询要慢。 目前冷热表只支持列存2.0版本的分区表,外表不支持冷热分区。 只支持修改冷热表的冷热切换策略,不支持修改冷热表的冷数据的表空间。 冷热表的分区操作约束: 不支持对冷分区的数据进行exchange操作。 Merge partition分区只支持热分区和热分区合并、冷分区和冷分区合并,不支持冷热分区合并。 ADD/Merge/Split Partition等分区操作不支持指定表空间为OBS表空间。 不支持创建时指定和修改冷热表分区的表空间。 冷热切换不是只要满足条件就立刻进行冷热数据切换,依赖用户手动调用切换命令,或者通过调度器调用切换命令后才真正进行数据切换。目前自动调度时间为每日0点,可进行修改。 冷热数据表不支持物理细粒度备份和恢复,由于物理备份时只备份热数据,在备份恢复前后OBS上冷数据为同一份,不支持truncate和drop table等涉及删除文件操作语句的备份恢复操作。
  • 创建冷热表 创建列存冷热数据管理表lifecycle_table,指定热数据有效期LMT为100天。 1 2 3 4 5 6 7 8 9 CREATE TABLE lifecycle_table(i int, val text) WITH (ORIENTATION = COLUMN, storage_policy = 'LMT:100') PARTITION BY RANGE (i) ( PARTITION P1 VALUES LESS THAN(5), PARTITION P2 VALUES LESS THAN(10), PARTITION P3 VALUES LESS THAN(15), PARTITION P8 VALUES LESS THAN(MAXVALUE) ) ENABLE ROW MOVEMENT;
  • 场景介绍 海量大数据场景下,随着业务和数据量的不断增长,数据存储与消耗的资源也日益增长。根据业务系统中用户对不同时期数据的不同使用需求,对膨胀的数据进行“冷热”分级管理,不仅可以提高数据分析性能还能降低业务成本。针对数据使用的一些场景,可以将数据按照时间分为:热数据、冷数据。 冷热数据主要从数据访问频率、更新频率进行划分。 Hot(热数据):访问、更新频率较高,对访问的响应时间要求很高的数据。 Cold(冷数据):不允许更新或更新访问频率较低,对访问的响应时间要求不高的数据。 用户可以定义冷热管理表,将符合规则的冷数据切换至OBS上进行存储,可以按照分区自动进行冷热数据的判断和迁移。 图1 冷热数据管理 GaussDB(DWS)列存数据写入时,数据首先进入热分区进行存储,分区数据较多后,可通过手动或自动的方式,将符合冷数据规则的数据切换至OBS上进行存储。在数据切换至OBS上后,其元数据、Desc表信息以及索引信息仍在本地进行存储,保证了读取的性能。 冷热切换的策略名称支持LMT(last modify time)和HPN(hot partition number),LMT指按分区的最后更新时间切换,HPN指保留热分区的个数切换。 LMT:表示切换[day]时间前修改的热分区数据为冷分区,将该数据迁至OBS表空间中。其中[day]为整型,范围[0, 36500],单位为天。 如下图中,设置day为2,即在冷热切换时,根据分区数据的最晚修改时间,保留2日内所修改的分区为热分区,其余数据为冷分区数据。假设当前时间为4月30日,4月30日对[4-26]分区进行了delete操作,4月29日对[4-27]分区进行了insert操作,故在冷热切换时,保留[4-26][4-27][4-29][4-30]四个分区为热分区。 HPN:表示保留HPN个有数据的分区为热分区。分区顺序按照分区的Sequence ID来确定,分区的Sequence ID是根据分区边界值的大小,内置生成的序号,此序号不对外呈现。对于RANGE分区,分区的边界值越大,分区对应的Sequence ID越大;对于LIST分区,分区边界枚举值中的最大值越大,分区对应的Sequence ID越大。在冷热切换时,需要将数据迁移至OBS表空间中。其中HPN为整型,范围为[0,1600]。其中HPN为0时,表示不保留热分区,在进行冷热切换时,将所有有数据的分区都转为冷分区并存储在OBS上。 如下图中,设置HPN为3,即在冷热切换时,保留最新的3个有数据的分区为热分区数据,其余分区均切为冷分区。