【华为云年度盛典就要来临】大家有什么想法？

计划生成原理https://bbs.huaweicloud.com/forum/thread-02119167712644340005-1-1.html多列过滤条件估算思想https://bbs.huaweicloud.com/forum/thread-0241167712738755003-1-1.htmlJoinRel行数估算https://bbs.huaweicloud.com/forum/thread-02112167712807239003-1-1.htmlJoinFilter的估算思想https://bbs.huaweicloud.com/forum/thread-0296167712866816005-1-1.htmlJoin Path优化https://bbs.huaweicloud.com/forum/thread-02119167712918144006-1-1.htmlAggregate Path的生成https://bbs.huaweicloud.com/forum/thread-0263167713687615003-1-1.htmlPostGIS支持数据类型https://bbs.huaweicloud.com/forum/thread-02119167713840094007-1-1.htmlPostGIS支持函数类型https://bbs.huaweicloud.com/forum/thread-0296167713903485006-1-1.htmlPostGIS依赖库安装https://bbs.huaweicloud.com/forum/thread-0296167713950760007-1-1.html弹性负载均衡：哪里压力大往哪里搬https://bbs.huaweicloud.com/forum/thread-02112167714032609004-1-1.html数据可视化https://bbs.huaweicloud.com/forum/thread-02112167714078666005-1-1.html数据仓库的好处https://bbs.huaweicloud.com/forum/thread-0296167714140885008-1-1.html物理细粒度备份恢复技术https://bbs.huaweicloud.com/forum/thread-02112167714275573006-1-1.htmlNBU备份恢复方案https://bbs.huaweicloud.com/forum/thread-0217167714322980001-1-1.html细粒度元信息生成方案https://bbs.huaweicloud.com/forum/thread-02109167714454883004-1-1.html

为了能够从备份集中细粒度地恢复单表或多表，首先需要获取所有数据库下schema、表的元信息DDL，将其持久化并备份到介质。需要说明的是，由于元信息DDL导出时间较长，设计中采用DDL导出备份与数据备份并行的方式，以提升性能：Roach获取DDL的设计思路如下所示：备份过程中，为支持细粒度恢复，通过表名映射到元信息，进而找到所有关联表的物理文件、事务信息，需要获取并备份一个映射map，map按数据库元素层次逐层获取，主要包括：Agent --> Instance –> Database –> Schema ->Table –> Related Relations。实际的执行中，将为每个物理节点、实例，并行进行映射元信息查询和存储，设计逻辑如下：GaussDB(DWS)的细粒度化全量备份实现于Roach备份工具。Roach集群级全量备份，通过与GaussDB(DWS)Kernel交互，在pg_start_backup()执行后依次备份行存数据文件、WAL文件，执行pg_stop_backup()后备份列存数据文件。这一系列备份流程在完整的事务保证下，确保数据落磁盘，并被有序地备份到NBU管理的介质路径下。细粒度数据备份的过程，首先依靠2.2中从系统表查询得到的MAP整理待备份物理文件列表，具体到每个库、schema、table，逐层递进，最终得到一张表所依赖的所有关联文件最小集合，创建的备份块最小逻辑粒度为schema，同一个schema下的表，会连续地向同一个逻辑块写，物理上按segment配置（通常为4G）进行切割。具体的备份数据写入介质，依靠如下生产-消费者模型，实例下的数据文件被数据写线程（生产者）按块读取，压缩后写入buffer中，发送数据线程（消费者）则从buffer中获取数据块，调用XBSA标准的API接口，流式地将数据写入到介质层，由NBU Master分配Media Server，最终落盘；数据追加写的过程中，若超过段文件segement size上限，则会切割备份文件，从而形成file_0.rch，file_1.rch等备份压缩文件。

Roach为GaussDB(DWS)数据库备份工具，支持多种备份恢复类型及方案。对于Roach通用架构，每个集群节点都有Roach agent进程负责本节点的数据备份。第一个节点额外有一个Roach master进程负责分布式集群备份。Roach提供非侵入式的备份到NBU方案，物理细粒度备份恢复同样基于此框架，因此首先对此进行介绍说明。Roach client插件部署至NBU Media Server机器中，用于接收Roach agent发送的备份数据，并转发至NBU 服务器中。NBU备份数据流向为：Roach agent将压缩数据向Roach client分片传输；Roach agent调用NBU客户端XBSA接口，请求NBU备份；NBU client将此请求转发至NBU Master Server；NBU master服务器负责分配存储到哪个NBU media服务器；Roach client将调用xbsa接口将备份数据传输至NBU Media Server；Media Server将备份数据存储至挂载的磁带机或磁盘上

随着信息技术的发展，人类进入大数据时代，数据量呈现爆炸式的增长，金融领域数据承载核心业务，即便遭遇各种软硬件错误或灾难，也需要具备找回和快速恢复业务能力，因此备份恢复能力成为数仓的最关键能力之一。华为的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；