RESOURCE_TRACK_COST(0)设置对当前会话的语句进行资源监控的最小执行代价。RESOURCE_TRACK_LEVEL(QUERY)设置当前会话的资源监控的等级，默认为query级别。RESOURCE_TRACK_APPLICATION设置TopSQL记录指定客户端下发的语句，目前支持设置的客户端为：gs_rewind、cm_agent、pgxc_clean、gs_clean、gs_running_xacts、OM、wlm。设置多个客户端时，相邻的值需用英文逗号隔开TOPSQL_RETENTION_TIME(30)历史TopSQL中GS_WLM_SESSION_INFO和GS_WLM_OPERATOR_INFO表中数据的保存时间，单位为天(历史TopSQL视图的数据实际是存储在postgres数据库中的dbms_om.gs_wlm_session_info系统表上，该表通过start_time进行分区，每天一个分区，通过参数topsql_retention_time配置默认保留30个分区即30天的记录，定期对pgxc_wlm_session_info的分区进行清理、创建，hash分布且分布键为queryid。如判断该表占用空间较多，可调低该参数，最多30min后表空间可下降)。SESSION_HISTORY_MEMORY(100MB)设置历史查询视图的内存大小，如果语句运行过程中出现"TopSQL lfq is full, failed to save queryid"报错信息，可通过如下SQL查询TopSQL无锁队列总共的内存和已使用的内存。

在实际的生产环境中，难免会出现一些突发情况，如计划跳变、异常中断、作业长时间执行不结束等，如果已经没有现场，而且也没有工具将当时的作业运行情况记录下来的话，那么事后就要投入更多的人力以及时间成本对错误进行定位和解决，有时还往往定位不到错误出现的地方。为了解决这种情况，GaussDB(DWS)开发了TopSQL功能，对运行中的语句记录（实时TopSQL），对运行完成的语句进行记录（历史TopSQL）。 目前TopSQL功能被用户广泛使用，是性能定位、劣化分析、审计回溯等重要的基石，为用户提供覆盖内存、耗时、IO、网络、空间等多方面的监控能力。 TopSQL可以帮助用户实现下列功能：①确定影响数据库性能的资源最密集的SQL查询；②监控和跟踪SQL查询随时间推移的性能变化；③分析查询执行计划以确定潜在的优化。TopSQL功能默认打开（use_workload_manager，enable_resource_track，enable_resource_record参数均默认为on），GUC参数详细介绍如下：use_workload_manager(on)资源管理总开关，TopSQL功能开启该参数需要为on。enable_resource_track(on)是否开启监控功能，实时TopSQL的总开关，关闭之后实时TopSQL将不再进行记录，更不会在历史TopSQL中出现。enable_resource_record(on)设置是否开启资源监控记录归档功能。开启时，对于执行结束的记录，会分别被归档到相应的INFO视图，CN和DN都需要设置上。enable_track_record_subsql(on)控制是否记录存储过程、匿名块内部语句（默认为on）(建议820及以上版本开启，TopSQL记录该子语句的前提是：子语句下推到DN执行；子语句执行时间超过resource_track_subsql_duration，目前TopSQL只能记录第一层循环的子语句，多层嵌套循环的子语句不会记录)。resource_track_duration(60s)设置实时TopSQL中记录的语句执行结束后进行历史信息转存的最小执行时间，该时间记录值的判断是包含了排队时间和运行时间（如果在解析优化阶段发生了锁等待，产生的时间不会记录到该参数中），当排队时间+运行时间 > RESOURCE_TRACK_DURATION时，TopSQL历史视图会记录作业信息。CPU和存储资源充足的场景建议设置为0，可记录更全的业务；在QPS高于100场景，可酌情调大，如1-10s。

系统管理员创建表时如果没有指定TO GROUP，创建的表默认在集群中第一个创建的逻辑集群（pgxc_group中oid最小的逻辑集群）中；通过GUC 参数default_storage_nodegroup可以改变默认的逻辑集群名称；逻辑集群下，所有表（外表）都只分布在所属逻辑集群的DN节点上。逻辑集群下，创建的函数中不能使用%type 引用表字段类型；逻辑集群下，如果函数的参数和返回值有表类型，这些表必须属于同一个逻辑集群；逻辑集群下，对外表来说，CREATE TABLE … LIKE 语句中源表和目的表需要在同一个逻辑集群；逻辑集群下，创建表时如果需要和其他表共享Sequence，该Sequence需要是所有DN节点共享的；逻辑集群下，如果函数中涉及多个逻辑集群表操作，该函数不应该声明为IMMUTABLE类型和SHIPPABLE类型，如果这样声明，会导致函数可能被下推到DN执行，这样执行过程中DN会找不到不属于其逻辑集群的表；如果函数中包含更新操作，不能声明成IMMUTABLE类型和STABLE类型；逻辑集群下需要考虑逻辑集群权限，如果SQL语句或函数体中如果涉及属于不同逻辑集群的表，SQL语句和函数的执行用户需要授予这些逻辑集群的USAGE权限。 

多子业务拆分：将一个大业务拆分为多个子业务，每个子业务创建一个独立逻辑集群；子业务之间资源隔离，同时也可以方便地进行跨子业务查询。例如：将需要大批量查询的数据（比如跑批数据）部署在一个逻辑集群中；将需要实时查询的数据部署在一个逻辑集群；将需要频繁更新的数据部署在一个逻辑集群；其他特定资源要求的逻辑集群。逻辑集群有三种创建方式：在新安装的全新的集群上划分逻辑集群，要求：新安装的物理集群没有任何用户表、多租户或资源池；全新的集群包含DN1~DN6 6个节点, 我们将DN1~DN3用来创建逻辑集群NodeGroup1, 剩下未使用的DN4~DN6暂时将放入弹性池中, 后续可以用来创建新的逻辑集群。将需要拆分到不同逻辑集群的表通过Insert into …select迁移到其他逻辑集群，并删除原表；原逻辑集群可以通过缩容释放部分节点（但被释放的节点必须独立成环）；逻辑集群用户执行CREATE TABLE创建的表，分布在所属逻辑集群包含的DN节点上；系统管理员在指定逻辑集群上创建表，需要通过TO GROUP指定逻辑集群名称。

非逻辑集群用户：在逻辑集群模式下，没有绑定任何逻辑集群的普通用户，这些用户无法创建任何表；逻辑集群转换：将整个集群从非逻辑集群模式转换成逻辑集群模式，物理集群中所有DN节点都被划分到一个统一的逻辑集群中，所有创建了表和资源池的用户都被绑定到该逻辑集群，所有表都属于该逻辑集群，同时创建一个空的弹性集群；逻辑集群回退：将整个集群从逻辑集群模式转换成非逻辑集群模式，只有在集群中只有一个逻辑集群（该逻辑集群包含所有DN节点），且弹性集群为空的时候才允许，转换后所有逻辑集群都会删除，弹性集群也会删除；集群公共组件：指被多个逻辑集群共享的组件，包括CN, GTM, cmserver,cmagent, ETCD；数据库公共对象：指除了表、外表之外的数据库对象；这些对象是所有逻辑集群共享的（但仍然有特殊函数，sequence是特定逻辑集群私有的）；初始逻辑集群：指第一个创建的逻辑集群，在没有明确指定逻辑集群名称时，系统管理员创建的表会在初始逻辑集群中。

资源池（Resource Pool）：用来进行资源配置的数据库对象；可以用来配置CPU，内存资源；在逻辑集群模式下，创建资源池必须指定逻辑集群名称；控制组（Control Group）：通过cgroup来配置CPU资源，资源池通过指定的控制组来限制用户的CPU资源；GaussDB通过gs_cgroup工具来配置控制组；多租户：基于资源池的租户资源管理，包含组资源池和业务资源池两级。数据库用户通过和业务资源池绑定来控制用户执行作业时的资源；系统管理员：在没开启权限分离前基本等同于超级用户，拥有对数据库管理的所有权限；逻辑集群管理员：仅仅属于某个逻辑集群的管理员，但本质上还是一个普通用户，但是可以将所属逻辑集群的访问权限授予其他用户，可以在所属逻辑集群内创建资源池；逻辑集群用户：在逻辑集群模式下，绑定到某个逻辑集群的普通用户，只有绑定到逻辑集群后，才能在该逻辑集群下创建用户表； 

物理集群：有时候也叫大集群，是实际安装的GaussDB分布式数据库集群。包含所有物理节点，所有CN，DN，GTM，CM，ETCD等组件在内。NodeGroup：也叫节点组，是将部分DN节点组成一个逻辑组，可以在一个NodeGroup上创建表；普通的NodeGroup非常灵活，对包含的DN节点没有任何限制，允许一个DN同时属于多个NodeGroup。逻辑集群：是一种特殊的NodeGroup，要求所包含的DN节点以及DN节点所在物理节点都只能属于一个逻辑集群。弹性集群：是一种特殊的NodeGroup，只在逻辑集群模式下存在，第一次创建逻辑集群时自动创建，可能包含DN节点，也可能不包含任何DN节点；Installation nodegroup：GaussDB安装时自动创建的NodeGroup，包含物理集群内所有DN节点；名称通常是group_version1, group_version2;逻辑集群模式：全新安装的数据库集群总是非逻辑集群模式，当数据库集群中成功创建了一个逻辑集群后，就自动转换为逻辑集群模式，判断是否在逻辑集群模式可以通过检查弹性集群是否存在来判断；当删除弹性集群后，数据库集群就转换回非逻辑集群模式（只有所有逻辑集群都删除后，才能删除弹性集群）。  

使用逻辑集群比单纯用多租户的资源隔离性好，比采用多套物理集群的业务数据互访能力强，但缺点是不同业务不能独立运维。下面将具体来看下逻辑集群对数据隔离，资源隔离，权限隔离的处理。逻辑集群的数据隔离是指用户表数据的隔离。逻辑集群的系统表信息是共享的（每个逻辑集群都可以看到物理集群中所有的数据库对象，包括表名、视图、函数、存储过程、用户信息、资源池信息）。逻辑集群的资源隔离是指不同逻辑集群访问本逻辑集群内数据时CPU，内存，IO资源不存在资源征用。每个逻辑集群内部可以按租户配置资源；逻辑集群访问其他逻辑集群时资源受限；逻辑集群的资源池可以配置并发作业数，CPU（配额和限额），内存，IO资源。每个逻辑集群用户默认只能访问本逻辑集群的表；如果访问其他逻辑集群的表，需要有该逻辑集群的USAGE权限；每个逻辑集群用户只能在本逻辑集群内创建表，不允许在其他逻辑集群创建表；用户创建的所有数据库对象都受到用户所在逻辑集群的权限限制。

逻辑集群实现了一个大集群按节点拆分为不同的节点组(NodeGroup)，每个节点组构建一个逻辑集群。例如下图中, 将数据节点1与数据节点2构成一个逻辑集群NodeGroup1, 我们可以让部分独立业务的表均分布在NodeGroup1中, 其他业务存放于NodeGroup2中. 逻辑集群可以很好的解决上面所述的问题。企业可以根据不同业务的数据规模为其创建不同节点数的逻辑集群，由于不同节点属于不同的逻辑集群，这样可以做到不同业务之间物理资源彻底隔离。在一个逻辑集群内部，所有节点是对等的，数据保持均衡，确保逻辑集群内部作业高效运行。同时，由于所有业务仍然在一个统一的大集群内，有统一的元数据管理和节点管理，跨逻辑集群数据互访非常容易和高效，这样就可以做到高内聚，低耦合。逻辑集群支持的功能数据按节点隔离逻辑集群间资源（CPU/MEMORY/IO)隔离跨逻辑集群访问资源限制逻辑集群并发控制和内存自适应跨逻辑集群访问权限控制非逻辑集群模式和逻辑集群模式转换（仅限单nodegroup ）逻辑集群创建、删除、扩容、缩容、节点替换；逻辑集群GUC参数配置；逻辑集群重启和状态查询；逻辑集群支持弹性计算；

传统的基于MPP的分布式数据仓库采用的是全对等架构，每个表数据平均分布到所有节点中，这样能保证足够的并发度以及节点间协同，保证性能SLA。只要保证数据在所有节点上是均衡的，数据查询会将计算平均分配到所有节点上，结构简单，扩展性好 。随着业务越来越大，这种简单的数据分布方式可能会带来一些问题。具体表现为：用户不断把各种业务数据集成到一个数仓中，不同业务逻辑访问同一个数仓，这减少了维护多个数仓的成本，运维方便。但也会导致数仓的数据规模越来越大，表越来越多。不同业务访问数仓过程中会带来资源的竞争，比如CPU、内存、磁盘IO、网络的竞争。虽然通过配置资源池可以一定程度解决资源竞争，但所有业务执行逻辑仍然同时在每个节点上执行，无法做到资源完全隔离。事实上，同一业务的不同作业总是倾向访问本业务相关的表，对其他业务的表访问较少，如果能做到业务内数据“高内聚”，业务间“低耦合”无疑是更好的选择。数据库表无论大小都被切分到所有节点，对小表来说，数据过于分散。当节点规模达到一定程度后，通过增加更多节点，提高查询并行度的方式可能就无法带来理想的扩展性了。如果为了避免集群变大，将不同业务数据拆分成独立集群，集群间数据互访就需要从应用层解决，或者需要跨集群导数。

我们评估在两个属性列上分布使用IN运算符与OR运算符进行过滤的差异。首先，我们评估当两个属性都是/不是索引列的情况，然后我们评估两个属性中只有一个属性是/不是索引列的情况。OR运算符与IN运算符的执行计划一模一样，可以知道他们的执行性能将一致，这里就进行性能数据比较了。从上述计划可以看到，DWS优化器先将IN语句转换为OR语句，然后针对语句中的每个谓词条件，执行一次索引扫描获取对应的Ctid，并生成位图，然后进行位图OR运行合并，最后进行原表扫描获取所有的查询列。在对单个属性进行过滤时，DWS对带有 IN 查询始终表现出对 OR 查询相当或更好的性能。对于具有大量谓词的查询尤其如此。关于下推到存储层的优化，截止到本文发布时间，只有在IN运算符是除与WHERE语句中才会生效，并且IN查询单一属性的类型有要求，目前支持INT, NUMERIC,DATE,VARCHAR等，对于其他类型则不支持下推。而在执行层使用临时哈希表加速的功能适用于所有类型，并且为了平衡哈希本身带来的消耗与使用哈希获取的性能收益，只有当IN运算符中条件个数较多时才生效，如大于10个。当根据多个属性进行过滤时，IN 和 OR 查询具有相同的性能，DWS优化器为两种查询生成的计划是一致的。因此，尽量使用 IN 子句，以最大化的提升查询的性能。

IN运算符首先进行Index Ctid Scan扫描主键索引以获取满足条件的行ctid，索引过滤的条件为IN条件。获取到所有满足的Ctid后，进行Index Heap Scan查询原表，获取并返回所有用户所需列。OR运算符也是首先进行Index Ctid Scan扫描主键索引表，但索引的过滤条件为单个谓词，每个OR条件都需要执行一次查找。查找完成后进行Index OR汇总，最后也是进行Index Heap Scan查询原表。OR运算符性能较差的原因在于需要为每个谓词做一次索引扫描并建立一个位图，即id = 1 为一个位图，id = 2 为一个位图等等。随后进行按位或组合这些位图。在谓词个数为1000时，需要进行1000次索引扫描并生成1000个位图，与只进行一此索引扫描的IN运算符相比，效率大大降低。并且随着谓词个数的增加，性能差别会逐步拉大。IN运算符与OR运算符的执行算子一致，唯一不同的是Predicate Information。IN运算符生成的是CU Predicate Filter， OR运算符生成的是Filter。CU Predicate Filter意味着此过滤条件下推到了存储层过滤，这样的做法可以减少了性能消耗。原因在于其直接在读CU（DWS列存表单列数据的基本存储单位）的时候就将不必要的数据过滤掉，而无需将其先填入Batch（DWS执行引擎中单列数据的基本存储单位）中，然后在执行器中进行过滤。除此以外，可以看到IN运算符的过滤条件为ANY，而OR运算符的过滤条件为OR。当起ANY条件下推到存储层时，存储层会生成一个临时的哈希表，并将条件中的谓词都存入哈希表中。相比多个OR条件，在进行过滤时，只需进行一次哈希比较，而无需逐个谓词比较，算法复杂度由O(N）变成了O(1)，大大的提升了执行性能。

声明式查询语言（如 SQL）的最初想法是，用户直接要求数据库管理系统 (DBMS) 给出其想要的答案，而无需考虑其计算方式与计算过程。DBMS的查询优化器负责确定查询的最高效执行计划。理想情况下，如果您使用不同的 SQL 命令提出相同的问题，DBMS应该选择相同的最佳计划。遗憾的是，实际情况并非总是如此，查询性能通常取决于用户编写查询的方式。有时对SQL 进行简单的改写即能得到显著的性能提升。在WHERE语句中使用IN和OR运算符对查询的结果做过滤是上述问题的代表场景之一，如下面的查询语句范例，它们产生的查询结果是一致的，使用Hstore OPT列存表，开启Turbo执行引擎。由于Hstore Opt表在单行数据插入时，会先插入delta表，并异步写成CU中。本文为了去除查询delta表对实验数据的影响，手动执行一次merge，保证所有delta表中数据都已写入CU。当单一属性上声明了索引，我们检验在WHERE 子句中使用单个 IN 运算符和使用多个 OR 子句运行相同的查找的性能差异。上诉语句声明中，id列声明为唯一列，DWS会自动为此列创建索引，我们使用此列进行下列的实验。我们首先运行IN语句，然后运行OR语句，并不断的增加条件中需要查找的ID个数。

随着智能数据时代的到来，数据量呈爆炸式增长，数据应用也迎来了前所未有的发展机遇。数据已成为驱动决策、优化运营和技术创新的关键资源。在这一背景下，数据仓库作为企业数据管理的重要基础设施，其重要性不言而喻。数据仓库不仅支持高效决策，还能驱动业务创新与增长，保障数据安全与隐私，促进跨部门协作与数据共享。因此，构建一个高效、安全、可靠的数据仓库系统，已成为企业数字化转型的必由之路。严苛考核体系：HCCDE是华为云认证体系中的最高级别，而HCCDE-GaussDB(DWS)则是华为云对数据仓库从业人员的技术、知识及操作技能的最高级别认可。获取此认证需历经严格的理论考试与实战操作双重考验，确保每位持证者都具备深厚的数据仓库架构设计、开发与运维管理实力。持续学习机制：认证体系倡导并鼓励持续的职业成长与终身学习，确保持证者的知识体系始终与最新技术同步，保持行业领先地位。核心技术与架构理念：认证课程深入剖析GaussDB(DWS)数据仓库的核心架构与先进技术，包括系统级数据仓库解决方案的设计原理，让开发者洞悉数据仓库的底层逻辑。业务场景融合：结合多样化的业务场景需求，详细解读数仓安全策略、高可用性设计、容灾备份方案及业务监控系统的构建思路，让开发者能够灵活应对各种复杂挑战。高效数据平台构建指南：通过实战案例分析，传授数据仓库设计与优化的高级技巧，助推开发者打造高效、稳定的数据存储与处理平台。云上实战环境：提供即开即用的云上实验环境，模拟真实、复杂的业务场景，支持在实战中锤炼数据仓库的运维技能。问题解决能力：通过实际操作，让开发者学会如何快速定位并解决数据仓库运行中的各种问题，提升应急响应与故障处理能力。业务洞察与决策支持：在运维实践中，开发者还将学会如何利用数据仓库提供的数据洞察能力，为业务决策提供有力支持，实现数据驱动的业务增长。

大数据未来发展趋势大家怎么看