dws怎么获取分布式表结构呢

我们来看下字段随意定义导致的严重资源消耗问题。   一、存储空间差异实际存储：varchar仅存储实际字符长度+1/2字节长度标识，存储相同内容时两者占用空间相同。如存储10字符数据时，两者均占用11-12字节。潜在扩展影响‌：当数据接近定义长度上限时，varchar(2000)可能比varchar(50)多消耗约40倍存储空间（按最大长度计算）。 二、性能影响索引效率‌： 过长的varchar定义（如2000）会导致索引键值变大，降低B-tree索引的节点密度，增加IO操作次数。内存消耗‌：  排序操作（如ORDER BY）时会按定义长度分配内存，而非实际数据长度，varchar(2000)比varchar(50)实际多消耗40倍内存。查询优化器‌：优化器可能因字段长度定义过大而错误估算内存需求，影响执行计划选择。 我们有时候不清楚资源消耗在哪里，为什么这么小的表，消耗内存会这么大，分析系统中  ORDER BY ,  GROUP BY 是家常便饭，定义region_name 为100 和 定义它为 2000,  内存消耗就相差 20 倍， 也许是为了后续不用更改长度，一劳永逸，也许就是全字段皆 2000 ，懒得设计，敏捷的不能再敏捷   。 但上线后， 运行态并发一来，各种排队或资源不足  。 不止ORDER BY , GROUP BY存在这种问题，其他算子有些也存在类似问题。    三、设计规范问题数据完整性‌： 随意使用varchar(5000)会丧失字段长度的约束作用，可能导致存储非预期数据  。资源浪费‌：  定义远大于实际需求的长度会浪费内存池资源，尤其在MPP架构下会影响并行计算效率。      四、不建议随意定义varchar长度的原因行存储限制‌：DWS中单行数据总长度受页大小限制（默认8KB），多个varchar(5000)字段易触发行溢出。维护困难‌：    过大的长度定义会掩盖真实业务需求，增加后续schema优化的复杂度。 建议根据实际业务需求精确设定长度，通常预留20%-50%的扩展余量即可。对于不确定长度的字段，可先采用适中的长度（如varchar(255)），后续通过ALTER TABLE调整。记得Oracle时代，各种评审单位都会对生产上线的表定义，长度，合理性进行评审。   现在是敏捷了， 但是问题却从设计，开发逐步转移到了后端运维  。成本不会消失，只是转移 。  目前只能靠更多的机器堆砌扩容和持续的整改优化来弥补设计上的缺失  。稳定性左移貌似落地太慢 。转载--原作者王琦

一个字符串长度为30，给这个字段设置varchar(50) 和varchar(5000) 有区别吗？插入的时候，占用的空间一样吗？查询的时候，效率一样吗？

TopSQL注意事项cid:link_3记录函数入口语句cid:link_4JDBC执行的带占位符语句cid:link_5operator_realtime级别TopSQL运行监控cid:link_6query_plan原理cid:link_0算子级TopSQL监控cid:link_7TopSQL与其他视图交互cid:link_8TopSQL原理介绍cid:link_9sql_hsah信息cid:link_1数据库弹性扩缩容降本增效cid:link_10弹性资源池cid:link_11手动弹性cid:link_12手动弹性VW的使用方式cid:link_2DDL设置cid:link_13路由策略https://bbs.huaweicloud.com/forum/thread-0208194605946543211-1-1.html

我们支持的路由策略有三种：路由策略none：主VW作业不会卸载到弹性VW上；路由策略dedicated：主VW作业可以卸载专用弹性VW；路由策略elastic：主VW作业可以卸载到专用和公用弹性VW。我们仍然以数据中台团队为例，介绍比例路由方式的案例。数据中台业务用户user1绑定主VW matedata_group1，user2绑定主VW matedata_group2。两个用户提交的作业既包含ETL负载，也包括一些DML业务处理负载。在每日的凌晨12点到6点，ETL负载变高。团队通过在“集群详情”页面中执行“添加增删计划”，设置周期性增删计划。周期类型选择每星期，时间调度计划添加7项，每项对应一周的一天，并设置创建完成时间为凌晨12点，删除时间为凌晨6点。绑定主逻辑集群选项卡设置为matedata_group1，集群名称设置为compute_group1。matedata_group1的60%作业卸载到专用弹性VW compute_group1执行。后续团队发现，由于user1提交的作业负载太高，一个弹性VW仍然不能满足需求，而且，user2提交的作业负载也需要卸载一部分到弹性VW执行。但是出于经济成本考量，在额外新建2个弹性VW成本很高。最好的方式是新建一个弹性VW，新建的弹性VW能够处理user1和user2的作业。此时，团队可以选择elastic路由策略。

在凌晨12点到6点，这两个用户将会提交大量的数据导入负载，如果完全在主VW执行，将会花费大量时间，影响其他业务执行。数据中台团队可以在“集群详情”页面中执行“添加增删计划”，设置周期性增删计划。周期类型选择每星期，时间调度计划添加7项，每项对应一周的一天，并设置创建完成时间为凌晨12点，删除时间为凌晨6点。绑定用户选项卡设置user1，集群名称设置为compute_group1，设置完成后，在每日的凌晨12点到6点，user1提交的所有作业将会到新建立的弹性逻辑集群 compute_group1执行。而user2提交的作业仍然在原有的metadata_group执行。如果避免ETL业务影响其他业务执行，团队想将user2提交的作业也到弹性VW执行（即增加用户与已经创建出来的弹性VW的绑定关系），可以手动执行DDL，将多个用户绑定到同一个弹性VW上。无需绑定用户，手动弹性VW创建完成后，用户通过DDL设置主VW的作业路由策略和路由比例，内核自动会将作业按照比例分配到主VW和弹性VW上。

客户提交的作业具体到哪个VW执行，依赖于创建时的配置。具体来说：如果在创建时勾选了绑定具体的用户，则作业将会以用户绑定方式路由。如果在创建时勾选了绑定主逻辑集群，我们将这种配置创建出来的弹性VW称之为专用弹性VW。内核以比例路由方式将所绑定的主VW的作业路由到专用弹性VW，即专用弹性VW只会接受来自绑定的主VW的作业。如果在创建时绑定用户和绑定主逻辑集群均没有选择，我们将这种配置创建出来的弹性VW称之为公用弹性VW。内核以比例路由方式将主VW的作业路由到公用弹性VW，即公用弹性VW可以接受来自集群内所有主VW的作业。总结来说，手动弹性VW的作业路由方式主要分为两种：用户绑定方式和比例路由方式。公司的数据中台团队在每天的凌晨12点到6点执行ETL，完成大数据量的离线导入。团队使用不同的用户账户执行ETL，由于凌晨12点到6点的ETL负载变高，我们可以创建新的弹性VW消费突发的负载，并以用户绑定方式实现不同用户间的ETL负载隔离。具体来说，用户user1和user2，他们分别负载导入不同业务模块的数据。

手动弹性，顾名思义，客户需要手动设置弹性资源的扩容和缩容。具体来说，公司的数据中台团队在每天的凌晨12点到6点执行ETL，完成大数据量的离线导入，ETL负载存在两个阶跃式的增长。在手动弹性的帮助下，DWS在12点时会定时准备好弹性VW 1以消费第一阶段的负载增长，而在凌晨4点又由于负载再次增加，仍会定时准备弹性VW 2来满足第二阶段的负载突发。数据导入大约持续到6点，DWS会定时回收2个手动弹性VW。在此过程中，客户只需要额外为零点到6点这段时间额外付费，无需要对主VW进行资源超配，降低成本。手动弹性不仅可以应对周期性负载突发情况，而且也可以扩展计算资源以实现计算加速。例如，在周期性跑批作业的场景下，固定资源池也可以胜任，但是作业整体完成时间会变长。手动弹性提供额外的计算资源，近线性地加速作业完成时间。在集群列表中，单击集群名称，进入“集群详情”页面，点击“添加增删计划”并设置合理的弹性计划。如图6所示，我们需要设置计划类型和集群名称。我们提供一次性增删计划和周期性增删计划两种方式，其中一次性增删计划，创建完成时间和开始删除时间不是必选项（如果未设置，则立刻创建，删除需要手动删除）。在周期性增删计划中，创建完成时间和删除时间必须设置，支持设置每周或者每月的弹性计划，也支持多个时间段的弹性计划。设置完成后，DWS管理面会按照预期设置的时间进行弹性VW的创建和删除。 

DWS存算分离版本（DWS 3.0）存在两个核心逻辑概念：固定资源池和弹性资源池。固定资源池：根据业务需要，部署多个固定VW（Virtual Warehouse），又称主VW。不同业务绑定不同的VW，并提供业务间的负载隔离。主VW的大小在MPP架构下决定了单SQL的上限以及所能处理的QPS的极限。主VW适合承接负载稳定以及低时延的作业。DWS提供分VW的水平扩展能力，通过扩展更多节点资源来满足业务扩张的需要。管理员需要根据长期的负载推演变化趋势来提前规划主VW的规格大小。弹性资源池：适用于细粒度时间范围的负载波动场景，存在一个或多个弹性VW。弹性VW在存储上实现了以OBS为基础储存的shared storage架构，而在计算上则是shared nothing架构。这就决定了计算和存储充分解耦，计算和存储可以实现分层扩展。计算节点扩容无需数据重分布，存储资源按需扩容，实现无限容量存储。弹性VW与主VW之间实时数据共享以解决元数据实时同步问题，避免元数据的滞后刷新，使得弹性VW能够实时利用最新的元数据进行作业执行。本篇文章主要介绍DWS手动弹性VW方案。

随着公司业务的蓬勃发展，为了满足公司业务的扩张，数据库扩容是业界通用的解决方案。业务负载在长时间维度上推演，定量扩容是一个很好的解决方案，能够支撑更多的业务并发。但是在细粒度的时间维度上，例如具体到每周甚至每日，传统的扩容模式仍然以资源超配的方式对抗业务负载波动。考虑图2中的场景，公司的数据中台团队，在每天的凌晨12点到凌晨6点执行ETL，完成大数据量的数据离线导入；业务团队每天作业负载呈现出无规律的负载波动。传统扩容的资源超配将会浪费大量资源，使用成本高。理想情况下，如果数据库能够根据负载波动主动地实现扩容和缩容，按需实现资源的调整能够极大地降低成本，减少资源浪费。为了更灵活、更低成本地实现数据库的扩缩容，数据库系统提供较小资源规格，以满足基础作业负载，又能在业务负载高峰期间快速扩容，保障业务的稳定性。DWS的存算分离版本中，实现了上诉的按需弹性，解决细粒度时间维度上的负载波动，主动地按需扩容弹性资源，以保障负载短期爆发的业务稳定性。

根据作业的sql_hsah信息确定作业的历史执行情况，借助历史TopSQL的资源信息和query_plan字段分析作业性能劣化原因。找到对应的快慢语句后，对比其执行计划query_plan，发现执行计划跳变严重。对相应的表做analyze后，恢复合理计划，语句性能恢复。统计信息不准，导致计划跳变，是十分常见语句变慢原因，analyze不影响读写，遇见语句变慢可预先做analyze。作业长时间运行不结束在作业无排队无死锁正常运行期间，发现作业长时间不结束，此时可查看算子级别的实时TopSQL监控，能够看出哪个算子执行时间长，通过算子执行时间和已处理行数等信息，确定是否需要查杀SQL。开启实时算子监控：set resource_track_level = 'operator_realtime';当发现作业内存整体使用较高，query级别的TopSQL无法记录算子的实际资源信息，此时可以设置TopSQL的监控级别为perf，query级别与perf级别的TopSQL差异主要在query_plan，perf级记录更详细执行信息，较query级性能损耗5%以内，perf级别的TopSQL的query_plan字段可显示算子的时间actual_time，memory，rows和buffer等信息。

作业下发执行后，内核通过打桩记录作业的各项资源信息，如内存、CPU、下盘、IO和网络信息等，作业执行完成后该资源信息后先存在无锁队列中，资源管理后台辅助线程将该数据信息定期转储到dbms_om.gs_wlm_session_info系统表中，后续通过topsql_retention_time定期老化数据。通常情况下，TopSQL记录的信息较多， 查询时可使用start_time做条件，避免全表查询，且使用limit对结果集大小限制，防止结果集过大导致客户端OOM。通过TopSQL历史视图查询到有10+业务SQL存在stream数超过100，判断为CPU高的原因。因为topsql记录了一些语句的执行情况和资源消耗情况，在定位性能问题的时候非常有帮助，比如周期执行的sql，突然有一天变慢了，我们可以通过分析语句的执行时间和阻塞时间判断是语句被阻塞了（排队等）还是执行的慢了，通过记录的执行计划分析语句为什么慢了，是不是当时的统计信息统计不准，还是没有对表做analyze，也可以看下盘量大小分析是不是下盘量大造成的性能变慢。通过pgxc_wlm_session_info视图确认历史的SQL信息（注：历史topsql视图按天分区，查询时尽量带start_time条件）。

不同视图从不同维度统计业务在数据库中的运行状态，因为或多或少都包含部分同类字段，可用于后续关联分析，此处给出历史TopSQL视图常交互的其他视图：使用示例：如果某个语句在历史TopSQL 历史pgxc_wlm_session_info视图中显示以往该作业很快就能正常运行完成，但是此时查杀pgxc_stat_activity发现该语句运行很长时间没有结束，则此时可能有异常，可利用以下步骤进行定位。查询pgxc_stat_activity活跃视图，找出长时间运行不结束的异常作业。根据步骤1得到的query信息，查询历史TopSQL视图，比较以往和现在的运行情况，如果以前运行时间很快，但当前语句运行时间很长未结束，则可考虑该语句已发生异常（历史topsql视图按天分区，查询时尽量带start_time条件）。根据步骤1得到的query_id查询等待视图pgxc_thread_wait_status，得到作业线程号lwtid，并打出作业堆栈进行分析。  

在SQL执行过程中，有些用户更希望能对算子执行进度进行监控，对于长时间运行的SQL，能够看出哪个算子执行时间长，通过算子执行时间和已处理行数等信息，确定是否需要查杀SQL，此时需要将RESOURCE_TRACK_LEVEL参数设置为OPERATOR。算子监控可以将SQL执行过程的算子监控数据以可视化的方式呈现出来，以便用户更加直观地了解算子的运行情况和性能表现。算子监控主要有以下价值：提升用户体验：通过可视化的方式呈现算子执行信息，用户可以更加直观地了解算子的运行情况和性能。性能优化：通过对算子监控数据的可视化分析，可以发现算子运行中的瓶颈和问题，从而及时进行优化和调整，提高算子的运行效率。故障排查：通过对算子监控数据的可视化分析，可以及时发现算子运行中的问题和异常，从而及时进行修复和维护，提高SQL的可维护性。提高算子的可扩展性：通过对算子监控数据的可视化分析，可以发现算子运行中的瓶颈和问题，从而及时进行优化和调整，提高算子的可扩展性，为后续的业务发展提供支持。OPERATOR算子监控和QUERY/PERF语句监控功能类似，均包含实时和历史二种形态，包含静态和动态二类信息：语句静态信息是语句在真正执行前就已经由优化器生成的信息，如执行计划plan_node_name，queryid，预估行数estimated rows等信息。可用来分析生成的执行计划是否合适。语句动态信息是语句在执行器中执行过程中所占用的资源信息，如算子执行进度progress、内存peak_memory、算子下盘spill_size、网络net_size、磁盘IO(read_bytes、write_bytes)，CPU（cpu_time）等不同DN的实时的信息记录。可用来分析语句执行过程中的进度和资源消耗情况，通过该字段可以分析出语句在运行是消耗较久的在什么地方，便于后续优化。

operator_realtime级别TopSQL运行时监控对于CN轻量化和存储过程的情况，暂时不支持。另由于算子执行速度较快的原因，对于算子信息的显示会有一定滞后性。query级别的作业监控和operator的算子监控中的spill_size字段，由于统计维度不同，会有一定差异，query级别监控监控的语句实际下盘文件大小，算子监控的是具体算子在逻辑层IO读写的数据量。当GUC参数enable_stream_operator设置为off状态时，算子执行信息存在显示不准的情况。在813版本中，除初始用户外，enable_gtm_free开启且关联队列不管控情况下，用户作业不进入资源管控。此时实时与历史TopSQL均不记录该用户下发的作业。现网中有概率出现某一个SQL原先执行比较快，后来发现该语句执行时间变长，此时就需要利用TopSQL中的query_plan以及其他资源信息进行分析定位，毋庸置疑，query_plan中的信息越详细，越接近于explain performance，定位过程就更容易。query级别与perf级别的TopSQL差异主要在query_plan，perf级记录更详细执行信息，较query级性能损耗5%以内，perf级别的TopSQL的query_plan字段可显示算子的时间actual_time，memory，rows和buffer等信息。