随着信息技术的发展，人类进入大数据时代，数据量呈现爆炸式的增长，金融领域数据承载核心业务，即便遭遇各种软硬件错误或灾难，也需要具备找回和快速恢复业务能力，因此备份恢复能力成为数仓的最关键能力之一。华为的GaussDB(DWS)支持了物理细粒度备份恢复能力。用户可自定义备份整集群或部分数据库元素，并进行灵活的单、多表恢复，有效缩减备份数据所需的时间窗口和存储空间，同时聚焦于用户业务场景的关键表的备份恢复。物理细粒度备份恢复目前主要支持的2大场景：一、从细粒度化的集群级全量备份集中恢复单/多表；二、备份指定的schema全量数据，并可从该备份集中恢复单/多表；可以看到物理细粒度备份恢复是对于已有全量数据备份恢复的一个有效的增强，客户可以以更灵活地方式规划自己的冷热数据，选择更小的逻辑粒度进行备份或恢复，节省宝贵的备份存储空间和cpu资源的同时，也更少地对在线业务带来冲击。在恢复层面，不同于旧有的集群级全量恢复需要停集群和清理数据，细粒度在线恢复不影响任何在线业务，也不会因恢复前清理集群带来可能的数据损失风险，因此该技术拥有较为广阔的前景和深远的意义。

通常情况下，电商数据主要分两块：第1类是面向交易的订单、商品、活动、发货等数据；第2类是平台运行的实时日志及用户在平台上活动产生的行为数据。如果企业无法应对大规模在线交易及“实时分析”的业务要求，在“618”这样的大促中就无法掌握主动权。举个例子，某运动服饰类电商企业原有系统采用传统解决方案，交易和BI相互独立。交易平台采用分布式中间件+单机版数据库搭建。由于该方案不具备数据的强一致性能力，在同一时刻系统中数据可能是不完整、不准确的，为销售对单带来极大困难。为保证数据的最终一致性，交易系统数据需要通过ETL工具时隔数小时后同步到BI系统，无法做到实时分析，销售及运营主管无法实时掌握经营情况。为了解决这个问题，他们后来采用了华为云混合负载数据仓库DWS。DWS采用“一库两用”的设计理念，一套数据仓库集群既可以支持超高并发、低时延的业务交易请求，同时可支撑复杂的海量数据分析和BI应用，减少开发和运维成本。相比于原系统，BI系统时效性大大提高，且数据分析性能提升3倍。做到数据实时一致的同时，DWS也确保了对单数据的准确，以及运营报表的“零”时延。DWS小规模可支持万级TPS的写入能力，横向扩展后可达百万至千万级TPS，支撑该电商企业平稳度过 “双十一”、“双十二”。而且由于它原生具备分布式事务ACID特性，具有数据的强一致性保证，在任何时刻均可保证交易系统数据的准确性、完整性，确保对单数据无误。再加上DWS的高可用架构设计，提供自动化数据备份功能，保障业务数据不丢失。

当我们把不同系统模块数据整合到数仓中，让它进一步清洗、整合、规则处理，实现实时、完整以及准确的数据后，还需要通过数据可视化平台推送到产品及运营人员进行可视分析。华为商城之前就将电商大数据应用由TIDB+Spark集群搬迁到基于华为云以DWS数据库为核心的数仓平台中。在数据的实时集成方面提供了基于Flink、Spark两种流计算引擎的CS流计算服务。随着Flink社区的活跃及FlinkSQL对应用开发者极大的门槛降低，通过SQL的形式即可实现流计算。华为云将通用的消息中间件封装成对应数据输入的source算子，逻辑层用SQL作为表示，各种数据存储平台作为sink算子封装。如果用原生Flink API的方式，开发及发布一个简短的输入输出任务，起码2小时才可以完工，但现在一站式的流计算平台10分钟即可完成。 而且进行语法校验后，绝大多数问题都可以在这个环节规避，发布之后，就能通过数据可视界面，查看其输入输出的数据信息进行校验监控。BI数据可视模块选择的是华为云DLV服务，以大屏场景为主。华为商城某次大促活动需要临时加一个指挥大屏看数据，2个开发人员加了2小时班，一个做前台，一个处理数据逻辑，很快完成了0.1版本并发布，之后再持续迭代优化效果。

弹性负载均衡（Elastic Load Balance，简称ELB）是将访问流量根据转发策略分发到后端多台服务器的流量分发控制服务，华为云的ELB就可以通过流量分发扩展应用系统对外的服务能力，并通过消除单点故障提升应用系统的可用性。面对不同的电商业务需求，ELB可以灵活处理。举个例子，对于业务量访问较大的业务，可以通过ELB设置相应的转发规则，将访问量均匀的分到多个后端云服务器处理；对于存在潮汐效应的业务，可以随时在ELB上添加和移除后端云服务器，比如在大促第一波高潮前增加服务器，到了中期再移除，最后收尾的时候重新加上。这样既能保证大促期间，商品页面不会因为过多访问而阻塞，也能控制成本的开支。但运营人员如何知道什么时候添加/减少服务器，什么时候为ELB设置转发规则，就得对整个促销的节奏以及自家产品数据有基本的预判。所以，大促期间，除了访问流量压力，更让人头疼的则是数据的实时分析管理能力。

PostGIS依赖Geos、 Proj、 JSON-C、 Libxml2、 Gdal第三方开源工具。安全前首先需要下载Geos、 Proj、 JSON-C、 Libxml2、 Gdal、 PostGIS源码至$GAUSSHOME目录。安装时需切换至omm用户，并检查GaussDB(DWS)环境变量已正确加载，且可正常登录和使用GaussDB(DWS)环境。具体安装命令可参考产品文档，且确保安装路径与文档中给定路径完全一致，自定义路径会导致最终库文件分发失败。在整个安装过程中，可使用make -sj和make install -sj命令并行加速编译，-sj命令极低概率性出现安装错误，如果安装失败则请使用make和make install进行串行安装。此外对于ARM物理机，在每个安装包configure时需要增加如下编译参数： --build=aarch64-unknown-linuxgnu，否则会出现安装失败。同时，在三方开源库proj的安装过程中，可能会报错$GAUSSHOME/install/proj/bin目录不存在，可手动创建该目录再执行proj的安装。安装完成后则需要使用PostGIS_install.sh工具完成PostGIS相关动态链接库在集群节点中的分发。执行方式为：sh $GAUSSHOME/share/postgis/PostGIS_install.sh如若失败，可打开PostGIS_install.sh文件分别执行分发命令，确定是哪个文件不存在而导致分发失败，并进一步分析该库文件编译失败原因。

1.字段处理函数a．AddGeometryColumn为已有的数据表增加一个地理几何数据字段；b．DropGeometryColumn删除一个地理数据字段的；c．ST_SetSRID设置SRID值2.几何关系函数这类函数描述几何对象的距离、包含、范围、相等等几何关系，常见函数如下：ST_Distance、ST_Equals、ST_Disjoint、ST_Intersects、ST_Touches、ST_Within、 ST_Overlaps、ST_Contains。3.读写函数这类函数主要用于各种数据类型之间的转换，尤其是Geometry数据类型与其他字符型等数据类型之间的转换，如ST_AsText、ST_GeomFromText、ST_AsGeoJSON ST_AsHEXEWKB、ST_AsKML、 ST_AsLatLonText。4.几何对象创建函数这类函数用于点、线、多变形等几何对象创建，如ST_GeomFromEWKT、ST_GeomFromEWKB、ST_MakePoint、ST_MakeBox2D、ST_LineFromText、ST_Polygon。5.几何对象编辑函数这类函数提供对几何图像的平移、翻转、旋转、放大等功能，如ST_AddPoint、ST_Reverse、ST_Rotate、ST_Scale、ST_Snap、ST_Transform、ST_Translate、ST_TransScale。6.空间关系及测量函数这类函数实现几何对象最远、最近、长度、面积等计算，ST_3DClosestPoint、ST_3DDistance、ST_3DDWithin、ST_3DDFullyWithin、ST_3DIntersects、ST_3DLongestLine、ST_3DMaxDistance、ST_3DShortestLine、ST_Area。

地理数据库属于空间数据库，为地理数据提供了标准的格式和存贮方法，能够方便迅速地进行检索、更新和数据分析，最终达到为多种应用服务的目的。地理数据则包括观测数据、分析测定数据、遥感数据和统计调查数据。地理数据库已广泛的应用于单车、导航，旅游、水利，农业、安平城市等应用场景，渗透到人民生活点点滴滴中。地理数据通常存储为点、线或者多边形的集合。在PostgreSQL中，已经提供了点、线、多边形等空间数据类型，但其提供的数据处理方法和性能很难达到GIS的要求，主要表现在：缺乏复杂的空间类型；没有提供空间分析；没有提供投影变换功能。为了使得PostgreSQL更好的提供空间信息服务，PostGIS也就应运而生。PostGIS支持数据类型PostGIS完全遵循OpenGIS规范，支持OpenGIS中所有空间数据类型：a．POINT, LINESTRING, POLYGON, MULTI-POINT,b．MULTI-LINESTRING, MULTI-POLYGON,c．GEOMETRY COLLECTION除了OpenGIS定义的地理数据类型之外，PostGIS还对数据类型进行了扩展，在WKT和WKB数据类型基础上扩展出EWKT和EWKB数据类型：a．EWKT, EWKB（包含了SRID信息的WKT/WKB）b．SRID(Spatial Referencing System Identifier)：每个空间实例都有一个空间引用标识符 (SRID)。SRID 对应于基于特定椭圆体的空间引用系统，可用于平面球体映射或圆球映射。此外，PostGIS还支持栅格数据raster分析，可以基于已有的影像或者卫星数据，实现影像或者卫星数据不同类别的统计分析。

一般而言，Aggregate Path生成是在表关联的Path生成之后，且有三个主要步骤（Unique Path的Aggregate在Join Path生成的时候就已经完成了，但也会有这三个步骤）：先估算出聚集结果的行数，然后选择Path的方式，最后创建出最优Aggregate Path。前者依赖于统计信息和Cost估算模型，后者取决于前者的估算结果、集群规模和系统资源。Aggregate行数估算主要根据聚集列的distinct值来组合，我们重点关注Aggregate行数估算和最优Aggregate Path选择。有了聚集行数，则可以根据资源情况，灵活选择聚集方式。Aggregate方式主要有以下三种：Aggregate + Gather (+ Aggregate)Redistribute + Aggregate (+Gather)Aggregate + Redistribute + Aggregate (+Gather)括号中的表示可能没有这一步，视具体情况而定。这些聚集方式可以理解成，两表关联时选两边Redistribute还是选一边Broadcast。优化器拿到聚集的最终行数后，会尝试每种聚集方式，并计算相应的代价，选择最优的方式，最终生成路径。这里有两层Aggregate时，最后一层就是最终聚集行数，而第一层聚集行数是根据Poisson模型推算的。Aggregate方式选择默认由优化器根据代价选择，用户也可以通过参数best_agg_plan指定。三类聚集方式大致适用范围如下：第一种，直接聚集后行数不太大，一般是DN聚集，CN收集，有时CN需进行二次聚集第二种，需要重分布且直接聚集后行数未明显减少第三种，需要重分布且直接聚集后行数减少明显，重分布之后，行数又可以减少，一般是DN聚集、重分布、再聚集，俗称双层Aggregate。

Join路径的选择时，会分两个阶段计算代价，initial和final代价，initial代价快速估算了建hash表、计算hash值以及下盘的代价，当initial代价已经比path_list中某个path大时，就提前剪枝掉该路径；cheapest_total_path有多个原因：主要是考虑到多个维度下，代价很相近的路径都有可能是下一层动态规划的最佳选择，只留一个可能得不到整体最优计划；cheapest_startup_path记录了启动代价最小的一个，这也是预留了另一个维度，当查询语句需要的结果很少时，有一个启动代价很小的Path，但总代价可能比较大，这个Path有可能会成为首选；由于剪枝的原因，有些情况下，可能会提前剪枝掉某个Path，或者这个Path没有被选为cheapest_total_path或cheapest_startup_path，而这个Path是理论上最优计划的一部分，这样会导致最终的计划不是最优的，这种场景一般概率不大，如果遇到这种情况，可尝试使用Plan Hint进行调优；路径生成与集群规模大小、系统资源、统计信息、Cost估算都有紧密关系，如集群DN数影响着重分布的倾斜性和单DN的数据量，系统内存影响下盘代价，统计信息是行数和distinct值估算的第一手数据，而Cost估算模型在整个计划生成中，是选择和淘汰的关键因素，每个JoinRel的行数估算不准，都有可能影响着最终计划。因此，相同的SQL语句，在不同集群或者同样的集群不同统计信息，计划都有可能不一样，如果路径发生一些变化可通过分析Performance信息和日志来定位问题，Performance详解可以参考博文：GaussDB(DWS)的explain performance详解。如果设置了Random Plan模式，则动态规划的每一层cheapest_startup_path和cheapest_total_path都是从path_list中随机选取的，这样保证随机性。

两表关联时，如果基表上有一些无法下推的过滤条件，则一般会变成JoinFilter，即这些条件是在Join过程中进行过滤的，因此JoinFilter会影响到JoinRel的行数，但不会影响基表扫描上来的行数。严格来说，如果把JoinRel看成一个中间表的话，那么这些JoinFilter是这个中间表的过滤条件，但JoinRel还没有产生，也没有行数和统计信息，因此无法准确估算。然而一种简单近似的方法是，仍然利用基表，粗略估算出这个JoinFilter的选择率，然后放到JoinRel最终行数估算中去。已知表关联的方式有多种（比如 NestLoop、HashJoin）、且GaussDB(DWS)的表是分布式的存储在集群中，那么两个表的关联方式可能就有多种了，而我们的目标就是，从这些给定的基表出发，按要求经过一些操作（过滤条件、关联方式和条件、聚集等等），相互组合，层层递进，最后得到我们想要的结果。这就好比从基表出发，寻求一条最佳路径，使得我们能最快得到结果，这就是我们的目的。

基表行数估算完，就可以进入表关联阶段的处理了。那么要关联两个表，就需要一些信息，如基表行数、关联之后的行数、关联的方式选择，然后在这些方式中选择代价最小的，也称之为最佳路径。对于关联条件的估算，也有单个条件和多个条件之分，优化器需要算出所有Join条件和JoinFilter的综合选择率，然后给出估算行数，先看单个关联条件的选择率如何估算。表关联含有多个Join条件时，与基表过滤条件估算类似，也有两种思路，优先尝试多列统计信息进行选择率估算。当无法使用多列统计信息时，则使用单列统计信息按照上述方法分别计算出每个Join条件的选择率。那么组合选择率的方式也由参数cost_param控制，如果Join列是表达式，没有统计信息的话，则优化器会尝试估算出distinct值，然后按没有MCV的方式来进行估算；Left Join/Right Join需特殊考虑以下一边补空另一边全输出的特点，以上模型进行适当的修改即可；如果关联条件是范围类的比较，比如"t1.c2 < t2.c2"，则目前给默认选择率：1 / 3；

按单列统计信息计算每个过滤条件的选择率，然后选择一种方式来组合这些选择率，选择的方式可通过设置cost_param来指定。为何需要选择组合方式呢？因为实际模型中，列与列之间是有一定相关性的，有的场景中相关性比较强，有的场景则比较弱，相关性的强弱决定了最后的行数。如果过滤的组合列的组合统计信息已经收集，则优化器会优先使用组合统计信息来估算行数，估算的基本思想与单列一致，即将多列组合形式上看成“单列”，然后再拿多列的统计信息来估算。比如，多列统计信息有：((c1, c2, c4))，((c1, c2))，双括号表示一组多列统计信息：若条件是：c1 = 7 and c2 = 3 and c4 = 5，则使用((c1, c2, c4))若条件是：c1 = 7 and c2 = 3，则使用((c1, c2))若条件是：c1 = 7 and c2 = 3 and c5 = 6，则使用((c1, c2))多列条件匹配多列统计信息的总体原则是：多列统计信息的列组合需要被过滤条件的列组合包含；所有满足“条件1”的多列统计信息中，选取“与过滤条件的列组合的交集最大“的那个多列统计信息。对于无法匹配多列统计信息列的过滤条件，则使用单列统计信息进行估算。值得注意的地方目前使用多列统计信息时，不支持范围类条件；如果有多组多列条件，则每组多列条件的选择率相乘作为整体的选择率。上面说的单列条件估算和多列条件估算，适用范围是每个过滤条件中仅有表的一列，如果一个过滤条件是多列的组合，比如 “t1.c1 < t1.c2”，那么一般而言单列统计信息是无法估算的，因为单列统计信息是相互独立的，无法确定两个独立的统计数据是否来自一行。目前多列统计信息机制也不支持基表上的过滤条件涉及多列的场景。无法下推到基表的过滤条件，则不纳入基表行数估算的考虑范畴，如上述：t1.c3 is not null or t2.c3 is not null，该条件一般称为JoinFilter，会在创建JoinRel时进行估算。如果没有统计信息可用，那就给默认选择率了。

GaussDB(DWS)优化器的计划生成方法有两种，一是动态规划，二是遗传算法，前者是使用最多的方法，也是本系列文章重点介绍对象。一般来说，一条SQL语句经语法树（ParseTree）生成特定结构的查询树（QueryTree）后，从QueryTree开始，才进入计划生成的核心部分，其中有一些关键步骤：有统计信息：等值条件1）对比MCV，如果满足过滤条件，则选择率（即most_common_freqs）累加；2）对Histogram数据，按distinct值个数粗略估算选择率；范围条件1）对比MCV数据，如果满足过滤条件，则选择率累加；2）对Histogram数据，按边界位置估算选择率；不等值条件：可转化为等值条件估算。无统计信息：等值条件：比如过滤条件是：“substr(c3, 1, 5) = 'gauss'”，c3列有统计信息，但substr(c3, 1, 5)没有统计信息。那如何估算这个条件选择率呢？一个简单的思路是，如果substr(c3, 1, 5) 的distinct值已知的话，则可粗略假设每个distinct值的重复度一致，于是选择率也可以估算出来；在GaussDB(DWS)中，可通过设置cost_model_version=1开启表达式distinct值估算功能；范围条件：此时仅仅知道substr(c3, 1, 5)的distinct值是无法预估选择率的，对于无法估算的表达式，可通过qual_num_distinct进行设置指定相应distinct值；不等值条件：可转化为等值条件估算。

【问题现象】     打开监控面板，有部分监控指标缺失，并且会提示弹窗DWS.13000未知异常，特别注意不是所有未知异常都是数据库连接数配置过小导致。 【常见版本】全版本    【定位思路】    1、确认此问题需要排查两个服务日志。 2、第一个，CCN节点的dms-agent服务日志dms/collection/metric相关接口，频繁打印504错误码 3、第二个，dms-collection服务日志有非常明显的JDBC报错，频繁打印Connection is not available, request timed out after 30001ms  4、解决方法，登录CDK，需要修改dms-collection服务的参数，修改如下： hikari.maximum-pool-size(默认值50)修改为350 hikari.minimum-idle（默认值5）修改为50 LIVENESS_PROBE.PERRIOD_SECONDS修改规则在原有数值上加1 

Q：通常采用Pygresql驱动程序来连接PostgreSQL以及Greenplum。DWS支持的python驱动程序有哪些？A：Python连接DWS的驱动有两种：1、 上文中提到的Pygresql使用方式请参考：使用Python第三方库PyGreSQL连接集群_数据仓库服务 GaussDB(DWS)_华为云 (huaweicloud.com)2、 使用psycopg2使用方式请参考：使用Python第三方库psycopg2连接集群_数据仓库服务 GaussDB(DWS)_华为云 (huaweicloud.com)