GaussDB(DWS) 通过external schema 对接HiveMetaStore，映射到对应的外表元数据，再通过外表访问 Hadoop。SQL查询：select查询形式为 select * from ex.tbl，其中tbl为外源表名，ex为已创建的external schema。语法解析：语法解析层主要针对进行解析，主要负责以下内容：当读取到ex.tbl表以后，连接HMS进行元数据查询。元数据查询：从HMS中查询元数据信息。从HMS中读取数据，主要包括列信息，分区信息、分区键信息、分隔符信息等。数据查询（针对select）：从DFS存储中获取统计信息文件个数和文件大小，为plan生成提供依据。查询重写、查询优化、查询执行查询下发：将元数据随plan下发给DN，DN收到plan以后，会将元数据进行解码后插入到SysCache中。查询执行：DN访问obs对应文件，执行查询。获取Hive的metastore服务内网IP和端口以及要访问的Hive端数据库名称。登录MRS管理控制台。选择“集群列表 > 现有集群”，单击要查看的集群名称，进入集群基本信息页面。单击运维管理处的“前往manager”，并输入用户名和密码登录FI管理页面。依次单击“集群”、“Hive”、“配置”、“全部配置”、“MetaStore”、“端口”，记录参数hive.metastore.port对应的值。依次单击“集群”、“Hive”、“实例”，记录MetaStore对应主机名称包含master1的管理IP。。

external schema主要用于与HiveMeatStore建立连接，获取表对象元数据，在创建external schema时需要指定连接的所需要的各个属性值。普通schema在创建后会将schema的信息记录在pg_namespace中，external schema创建后和普通schema一样也会记录在pg_namespace，可以通过pg_namespace中的nsptype字段区分是external schema还是普通schmea。用户在使用本特性前，将需要创建Server，创建Server过程与已有Server创建过程相同对于创建OBS server有两种方式，一种是通过永久AK、SK的方式创建。（此种方式前提是可以获取永久AK、SK，但是此种方式不安全，AK/SK直接暴露在配置文件中，并且创建服务的时候需要明文输入AK、SK，不建议采用此种方式创建服务）另一种云上DWS绑定ECS委托方式访问OBS，通过管控面创建OBS server。委托通过管控面创建server可参考创建外表时如何创建OBS server。其中SOURCE字段指定了外部元数据存储引擎的类型，DATABASE为Hive中对应的数据库名，SERVER为创建的server，METAADDRESS为Hive提供的地址端口信息，CONFIGURATION为Hive、Kerberos相关配置文件路径。external schema的目标是对接外部元数据（Foreign Meta），使得DWS能主动感知外部元数据的变化。

在大数据融合分析时代，面对海量的数据以及各种复杂的查询，性能是我们使用一款数据处理引擎最重要的考量。而GaussDB(DWS)服务有着强大的计算引擎，其计算性能优于MRS服务中的hive或者spark这类计算引擎，且可以以更低的成本满足业务高弹性和敏捷性需求。通过与MRS联动，无需搬迁数据，利用DWS的高性能计算引擎处理和分析数据湖中的海量数据以及各种复杂的查询业务、分析业务越来越成为主流的解决方案。我们可以通过创建external schema的方式来对接HiveMetaStore元数据服务，从而实现GaussDB(DWS)直接查询hive/spark表或者插入数据到hive/spark表。无需创建读外表或者写外表，也无需担心hive/spark表的定义发生变化时GaussDB(DWS)没有及时更新表定义。HiveMeatStore是Apache Hive的一个关键组件，它是一个元数据存储库，用于管理hive/spark表的元数据信息。HiveMeatStore存储了Hive表的结构信息，包括表名、列名、数据类型、分区信息等。它还存储了表的位置信息，即表数据存储何处。HiveMeatStore的主要作用是提供元数据服务，使得Hive/Spark可以对数据进行查询和分析。它还提供了一些API，可以让开发人员通过编程方式访问表的元数据。总之，HiveMeatStore是Hive的一个重要组件，它提供了元数据管理和查询服务。external schema即外部模式，GaussDB(DWS)通过创建extrenal schema来对接HiveMeatStore服务，每次查询主动获取hive/spark表对象的元数据。无需GaussDB(DWS)内核通过create foreign table获取hive/spark表的元数据。

对于postgres生态来说，视图的依赖关系没有现成的查询方法，需要对系统表pg_depend及pg_rewrite编写复杂的组合查询才能得知，而对于Oracle和MySql，该需求都较易实现，分别查询USER_DEPENDENCIES和INFORMATION_SCHEMA.VIEWS即可轻易查出，因此在pg生态来说有必要编写一个直观的视图来查看各个视图与基表或与其他视图的层级依赖关系。可见这种查询并不直观，只能通过肉眼分析得出递归的依赖关系，对用户并不友好。例如起名为PUBLIC.gs_view_dependency。接下来我们来学习一下with recursive语法的使用方法，从pg官网可以get到的知识是，WITH语句通常被称为通用表表达式（Common Table Expressions）或者CTEs。WITH语句作为一个辅助语句依附于主语句，WITH语句和主语句都可以是SELECT，INSERT，UPDATE，DELETE中的任何一种语句。WITH语句还可以通过增加RECURSIVE修饰符来引入它自己，从而实现递归。WITH RECURSIVE语句包含了两个部分（非递归部分）non-recursive term，即上图中的union all前面的部分（递归部分）recursive term，即上图中union all后面的部分执行步骤如下：执行non-recursive term。（如果使用的是union而非union all，则需对结果去重）其结果作为recursive term中对result的引用，同时将这部分结果放入临时的working table中重复执行如下步骤，直到working table为空：用working table的内容替换递归的自引用，执行recursive term，（如果使用union而非union all，去除重复数据），并用该结果（如果使用union而非union all，则是去重后的结果）替换working table。

对于无效视图处理方式，在不同版本之间行为不同，具体差异如下：在8.1.0版本中，无效视图不能使用，需要先执行ALTER VIEW view REBUILD或CREATE OR REPALCE将视图刷新为有效状态在进行操作，过程中需要对该视图及下层无效视图加八级锁；在8.1.1版本中，无效视图查询时同时尝试刷新视图，内部调用ALTER VIEW ONLY view REBUILD语法，对本视图及下层视图做重建，重建过程中对该视图及下层无效视图加八级锁后更新系统表；在8.2.1版本中，无效视图做本地展开（相当于将视图作为一个子查询），本地重建时对该视图及下层视图持一级锁且不更新系统表，视图可正常使用。GaussDB(DWS)视图解耦功能的发展历程以及现有所支持的操作，在总结现在已有的功能的过程中，详细阐释了视图有效状态和无效状态切换时的持锁情况及行为逻辑，展示了视图相关的系统视图作用和效果，对比了友商与我们之间的行为差异。视图解耦功能通过view_independent参数控制，默认关闭。开启后，存在视图依赖的基表或其他数据库对象（如视图、同义词、函数、表字段）可以单独删除（临时表及临时视图除外），关联视图保留但不可用。

为保证实现底层对象和视图之间的解耦且视图定义可以存在，在打开视图解耦后，对视图所依赖的底层对象做以下DDL操作,ATLER TABLE DROP COLUMNATLER TABLE ADD COLUMN(只有视图依赖对象的RECORD类型时)ATLER TABLE COLUMN TYPEALTER TABLE/VIEW SET SCHEMARENAME COLUMN/TABLEDROP TABLECREATE OR REPLACE VIEW/FUCNTION需要将视图依赖关系链中的所有视图标识为无效状态，其定义在pg_rewrite系统表中的ev_enabled字段（'O’为正常，'D’为无效），该标识用于以后续对无效视图的处理。当底层对象发生改变时，上层视图均会置为无效的状态。如果在依赖关系中，中间的视图发生变化，只有其上层视图会被置为无效，也就是说，当该视图无效时，其上层视图也必然是无效的。我们在业务中经常存在这种场景，一个视图依赖于两个及以上底层对象，此时在对底层对象分别做DDL操作时，因为都需要将上层视图置为无效状态，所以会导致另外一个对象锁等待周期过长的问题，无法并发执行。

GaussDB(DWS)数仓产品内部使用对象标识符(oid)来保存对象之间的引用关系，这使得视图在定义时就绑定了其依赖的基表的oid。如果要删除字段或整个表，就需要连同其关联的视图一起使用cascade关键字删除，表修改完成后再重建各级视图，这就给用户的使用增加了很大的工作量。为了解决这一问题，GaussDB(DWS) 在8.1.0版本实现了视图的解耦，8.1.1版本在此基础上又实现了自动刷新，8.2.1版本实现了本地自动刷新，避免了自动刷新时持锁周期过长、持锁粒度过大的问题。GaussDB(DWS)数仓产品内部使用对象标识符（oid）来保存对象之间的引用关系，这使得视图在定义的时候就绑定了其依赖的数据库对象的oid，而不管其名称怎么改变，都不会改变这层依赖关系。如果要对基表进行一些字段修改，会因为与视图字段存在强绑定而报错，如果要删除某个表字段或整个表，就需要连同其关联的视图一起使用cascade关键字删除，表字段删除完成或表重建后再顺序重建各级视图，这就给用户的使用增加了很大的工作量，相对于某些市场主流数仓产品存在明显的易用性差异。为了解决这一问题，GaussDB(DWS) 实现了视图的解耦，使得存在视图依赖的基表或其他数据库对象（视图、同义词、函数、表字段）可以单独删除，而其上关联的依赖视图依然存在，而在基表重建后，可以通过ALTER VIEW [ONLY] view_name REBUILD命令重建依赖关系。不同版本之间对于视图解耦功能的优化。

GaussDB(DWS)还提供了许多视图用于展示数据库的内部状态，以下几个视图，在定位故障时会经常使用。pg_stat_activity：用于查询当前实例上各个Session的状态。pg_thread_wait_status：用于查询该实例上各个线程的等待事件。pg_locks：用于查询当前实例上的锁状态。pgxc_lock_conflicts：提供集群中有冲突的锁的信息，当某一个锁正在等待另一个锁，或正在被另一个锁等待，即该锁是有冲突的。pgxc_deadlock：获取导致分布式死锁产生的锁等待信息。存在一系列与 Workload 控制组内 SQL 语句执行次数和响应时间统计相关的视图，如显示当前节点上 Workload 控制组内的 SQL 语句执行次数统计信息的视图，以及显示集群中所有 CN 节点上 Workload 控制组内 SQL 语句执行的响应时间统计信息的视图等，能够帮助用户了解不同类型 SQL 语句的执行情况，便于性能调优和监控。这些系统视图可以帮助用户和管理员更好地管理和监控 GaussDB (DWS) 数据库，了解数据库的运行状态、用户信息、对象结构等方面的信息。具体使用时，可以根据实际需求进行查询和分析。

由于视图时根据数据库的基础表创建的，每当更改与视图关联的那些表的结构时，也必须更改视图。GaussDB(DWS)在8.1.0版本实现了视图的解耦，使得存在视图依赖的基表或其他数据库对象（视图、同义词、函数、表字段）可以单独删除，而其上关联的依赖视图依然存在，而在基表重建后，可以通过ALTER VIEW view_name REBUILD命令重建依赖关系。而8.1.1版本在此基础上又实现了自动重建，可以无感知自动重建依赖关系。在GaussDB(DWS)上，当开启视图可更新参数（enable_view_update）后，系统允许对简单视图使用INSERT，UPDATE、DELETE和MERGE INTO语句进行更新，满足以下所有条件的视图可进行更新。视图定义的FROM语句中只能有一个普通表，不能是系统表、外表、dfs表、delta表、toast表、错误表。视图中包含可更新的列，这些列是对基础表可更新列的简单引用。视图定义不能包含WITH、DISTINCT、GROUP BY、ORDER BY、FOR UPDATE、FOR SHARE、HAVING、TABLESAMPLE、LIMIT、OFFSET子句。视图定义不能包含UNION、INTERSECT、EXCEPT集合操作。视图定义的选择列表不能包含聚集函数、窗口函数、返回集合的函数。视图上不能有触发时机为INSTEAD OF的触发器。视图定义不能包含子链接。视图定义不能包含属性为VOLATILE的函数（函数值可以在一次表扫描内改变的函数）视图定义不能对表的分布键所在列起别名，或将普通列起别名为分布键列名。视图更新操作中包含RETURNING子句时，视图定义中的列只能来自于基础表。

安全性是任何关系数据库管理系统的重要组成部分，数据库视图为数据库管理系统提供了额外的安全性。数据库视图允许创建只读视图以向特定用户公开只读数据，用户只能在只读视图中检索数据，但不能对其进行更新。数据库表中不应该有计算列，但是数据库视图支持有计算列。假设在订单表中有订购产品的数量和每个产品的价格列，但是订单表定义一列来存储每个订单的总销售额。如果有，这样的数据库模式也不是一个好的设计。在这种情况下，可以创建一个名为总销售额的列， 它是计算结果是产品的价格乘以订购产品的数量。当从数据库视图查询数据时，计算列的数据会动态进行计算。假设有一个核心数据库，许多应用程序都在使用它，为了适应新的业务需求，有可能会重新设计数据库，删除了一些表并创建了几个新表，修改表的列名，此时并不希望这些更改影响之前的应用程序。在这种情况下，可以使用与已删除的旧表相同的表结构创建数据库视图。应用程序可以访问视图来完成此前功能，这样就无需对应用程序做任何的修改。从传统数据库视图查询数据可能会很慢，特别是如果视图是基于其他视图创建的。GaussDB(DWS)通过对视图解析和查询优化，生成的查询计划基于基础表，依然可以提供高效的查询性能。

当用户对数据库中的一张或者多张表的某些字段的组合感兴趣，而又不想每次键入这些查询时，用户就可以定义一个视图，以便解决这个问题。视图中列可以来自于表里的不同列，这些列都是用户所感兴趣的数据列。视图与表不同，它在物理上不是真实存在的，而是一个虚表。在数据库里仅存放视图的定义，而不存放视图对应的数据。视图中的这些数据存放在其对应的表中，如果表中的数据发生了变化，从视图中查询出的数据也会随之发生改变。从这个意义来看，视图就像一个窗口，透过它可以看到数据库中用户感兴趣的数据及变化。每一次查看视图或引用视图的的时候，都会运行一次视图上的查询。用户可以使用SELECT语句从视图里查询数据，对于符合一定约束条件的视图，还可以使用INSERT、UPDATE、DELETE、MERGE INTO等语句修改视图对应的基础表里的数据。视图在提供操作方便的同时，还可以保障数据库数据的安全。数据库视图由许多基础表相关联的 SQL 语句定义，可以使用数据库视图向最终用户和外部应用程序隐藏底层表的复杂性。通过数据库视图，只需要使用简单的 SQL 语句，不需要编写具有许多连接的复杂语句。如果不希望所有用户都可以查询敏感数据，就可以使用数据库视图仅向特定用户组公开非敏感数据。

运行过程中出错，ODBC是不会打屏的。错误信息需要业务里获取错误信息（API为：SQLGetDiagField/SQLGetDiagRec）。 如果用户的业务里有打印具体的错误信息，或者业务的错误信息不足以定位，请根据3.7中的描述，将ODBC的日志打印出来，在其中找SQL_ERROR相关信息。这里最好能和业务开发人员一起定位，因为API的调用序列是乱序的，由业务决定。 如果ODBC的日志仍然不足以定位支撑，请登录到连接的目标CN所在的机器，通过以下方法进入CN日志文件目录：source ${BIGDATA_HOME}/mppdb/.mppdbgs_profilecd $GAUSSLOG/pg_log/cn_50xx #这里的cn_50xx表示CN编号，根据实际情况修改找到对应时间点的日志，观察其中是否有错误信息。 我们ODBC驱动默认使用utf-8编码。如果要调整，需要自行在会话开始时设置client_encoding。 但是请注意，请不要在宽字节模式下使用GBK，因为宽字节编码本身就是UNICODE的一部分（一般为UCS2），此时使用GBK可能导致数据无法显示，SQL查询结果不正确等问题。

典型报错： unsupported frontend protocol 3.51: server supports 1.0 to 3.0 可能原因： 使用了新版本的数据库驱动连接老版本的数据库(V1R6C10)；或者使用了我们的驱动，连接到了开源的数据库上。 解决办法： 请使用老版本的数据库驱动连接该数据库。我们的数据库中，默认低版本客户端可以连接高版本数据库；使用高版本驱动连接低版本客户端，不在规格约束范围内。这个规格也比较好理解：因为用户一般是对数据库集中管理，升级也是有计划的。但是客户端驱动可能嵌入到业务中的每一个角落，有时甚至是已经发布的装备中，升级相对比较困难。 如果是开源服务器：我们的数据库驱动不支持开源数据库，无法连接；请使用开源客户端连接。增加了安全性，使用了SHA256算法做认证加密；同时调整密钥哈希加密次数 提升了批量性能（V1R7C10 2019-4-30及以后版本）还是基础知识里那张图，用户引用的API是由驱动管理器提供的，我们提供的API只可供驱动管理器使用；新增API无法穿过中间层为用户提供服务。Copy是PG的特有语法及通信协议;而ODBC是微软提出的通用调用接口，所以无此特殊接口。驱动管理器在Linux上并不是操作系统的一部分，它也是由其他开源组织开发的。所以并不是只有UnixODBC一种。但是目前使用最广泛的，其实只有UnixODBC，多数据操作系统安装时基本都已经自带了UnixODBC的某个特定版本；除此之外，还有iODBC等，现在已经慢慢退出市场了。

大家对HDC2025大会有哪些想法

本月1号时对LVS服务器进行重启操作，验证后连接没问题，到了15日大部分客户端突然出现 connection refused，并且还有少数IP是可以连接的，问题就比较奇怪。然后我们在同网络telnet  vip  25308，发现是不通的，直接telnet 各CN节点物理IP的25308都是通的，所以判断问题可能出在LVS上面，一直也没有定位问题的原因。LVS的配置文件中使用的是 fwmark 方式转发数据库包的，当时LVS有问题的时候，我们多次重启keepalived问题依然存在，后来我们改成了 vip 加 25308的方式，这样数据库集群就都能访问了，从这里也确认是LVS有问题了。后来我们检查了iptables的配置文件，发现没有下面命令的记录，这条命令在/etc/rc.local里被注释掉了，所以怀疑是数据包进来时没有打标签，然后LVS不进行转发。但是有个问题没有办法解释，就是1日重启后就没这条记录了，一直也运行正常，为什么直到了15日才出现无法访问的问题？iptables  -t mangle -I PREROUTING -p tcp -m tcp -d $VIP --dport $VPORT -m mac ! --mac-source $MAC_Director_B -j 但是在iptables的mangle表中有一条主机名的记录，也不知道这条记录是怎么来的target     prot opt source               destination         DR-I       all  --  anywhere             anywhere            MARK       tcp  --  anywhere             主机名          tcp dpt:25308 MAC ! xx:xx:xxxx:xx:xx MARK set 0x1然后怀疑是不是lvs  的fwmark功能是不是有什么bug，重启keepalived也不行。这也只是怀疑，没有依据，重启主机前运行好多年了，也没有什么问题请各位专家帮助分析分析出问题时  keepalived的配置文件，截取了主要的部分。