据预测未来4年数据量将激增5-8倍，达180ZB，到35年呈50倍增长。同时，数据作为继土地、资本、技术、劳动力的第5种生产要素，已是数字经济发展的重要要素。但相关调查结果显示，企业运营中仅56%的数据被存储，仅32%的数据被利用。因此，在政企数字化转型的关键阶段，如何利用数据湖、数据仓库、数据库等技术，加速数据资产化，发挥数据新价值，成为当前数据领域的重要话题。4月8日，华为云TechWave全球技术峰会在深圳成功举办，峰会以“创新·普惠”为主题，汇聚业界精英、技术大咖、先锋企业、合作伙伴等，共话前沿技术，分享行业优秀应用实践，探讨企业智能升级的成长之道。其中，数据使能分论坛围绕“数据使能，驱动业务增长”为主题，首先解读华为云数据使能服务DAYU，同时招商银行、深圳地铁将分享数字化转型创新实践，合作伙伴永洪BI畅谈联合解决方案，最后由华为云FusionInsight MRS云原生数据湖、GaussDB数据库、GaussDB(DWS)数据仓库等技术专家共同探讨政企用数之道。（数据使能分论坛现场照片）华为云数据使能DAYU重磅开场：加速数据资产化，开发数据新价值（华为云数据使能服务总经理马麟瑜演讲）华为云数据使能服务总经理马麟瑜表示，“数据管理的领导者正在通过挖掘数据价值来驱动数字化转型，创造发展机会，改善客户体验和重塑行业格局。华为云数据使能DAYU致力于打通企业数据从资源到资产的通路，助力政企客户跨越孤立系统、感知业务的数据资源智能管理解决方案，实现全域数据入湖，帮助政企客户从多角度、多层次、多粒度挖掘数据价值，实现数据驱动的数字化转型。”华为云数据使能服务DAYU包含三层能力：数据技术平台-智能数据湖 FusionInsight：为政企客户提供覆盖海量数据全生命周期的管理方案。包含MRS云原生数据湖、GaussDB数据库、GaussDB(DWS)数据仓库、数据湖治理中心DGC等服务。使能套件 DAYU Ekit：包含使能在线化工作台，资产化效率提升10X； 行业使能知识库，协同伙伴沉淀行业资产模型，同时将AI驱动方法论与行业知识结合，实现数据资产化智能流水线工作。资产中心 DAYU Hub：通过为客户提供丰富的数据模型、数据资产管理方法，帮助企业实现资产可信管理，资产模型智能分析 ，多方安全可信计算，保障全局数据的安全流通。招商银行、深圳地铁分享大数据创新实践数据使能分论坛中，招商银行、深圳地铁分别分享了基于华为云数据域的行业创新实践。（招商银行数据仓库架构师曾民演讲）招商银行数据仓库架构师曾民表示：招商银行通过使用华为云强化了数据平台的建设，“人人用数”战略让招行没有难用的数据，打造金融数仓，秉承“源于业务，高于业务，先于业务”的理念，以解决实际业务问题为出发点，沉淀可复用易扩展的数据使能能力，成为数据“能用，好用，爱用”的践行者与布道者。早在2019年下半年，招商银行就开始了新一代MPP数据仓库平台的选型，旨在通过对数据平台的数据处理能力、性能、高可用性、扩展性、易用性、通用性等特性进行多方位的考察。通过多维度的测试，最终选定华为云GaussDB(DWS)作为新一代云上数据仓库平台，进一步提升了金融数仓的算力、备份、存储等性能，加速落实招行“人人用数，人人都是数据分析师”的数据发展战略！同时招商银行已和华为云FusionInsight MRS展开了一系列金融数据湖联合创新，旨在使用HetuEngine提高用数效率，简化用数方式。（深圳地铁运营集团线网管控中心副总经理张洪庆演讲）深圳地铁运营集团线网管控中心副总经理张洪庆在“云数赋能，实现智慧深铁“议题中表示：“在智慧城轨快速发展的大背景下，深圳地铁以科技赋能运营为目标，积极探索智慧运维新模式。在智慧城轨探索上，试点先行，顶层规划和企业标准同步推进，采用了华为城轨云解决方案，利用云计算、大数据、5G、人工智能等技术核心，建立了统一、开放、智能的城轨数字平台。在城轨云平台基础上，利用华为云 FusionInsight MRS云原生数据湖能力构建深圳地铁大数据分析平台，在智慧车站、智慧运维方面，对新技术与地铁场景进行创新融合，推进了车站业务全日自动运行、线上线下一体化客服、设备主动检测、健康管理等应用，探索数字化、高效化的新业务模式，科技赋能运营更高质量运行，企业更低成本运作，为城市提供更优质的公共交通服务。”（永洪BI技术专家黄华晃演讲）合作伙伴永洪BI分享基于华为云实现敏捷BI的联合解决方案永洪BI技术专家黄华晃分享了“永洪BI自助用数，敏捷提效20倍“议题，并表示基于华为云FusionInsight MRS云原生数据湖，永洪BI实现快速搭建应用，打造了更敏捷、更快速、更强大的“永洪BI”，具备自服务、高性能、极致易用等特点，已广泛用于金融、政务、能源等行业，让人人都成为数据分析师！至今，华为云FusionInsight联合800+ISV，已为千行百业的客户提供“一企一湖、一城一湖“的数字化转型方案。数字化转型之路离不开客户对于华为云FusionInsight智能数据湖的信赖，也离不开伙伴的精诚合作。同时，华为云也坚持技术创新，在MRS云原生数据湖、GaussDB数据库、GaussDB(DWS)数据仓库等产品上不断潜心钻研，勇攀技术高峰！华为云FusionInsight、GaussDB技术专家共谈数字化转型创新技术华为云FusionInsight解决方案首席架构师徐礼锋在会议中分享了“华为云FusionInsight MRS云原生数据湖一架构三湖，持续演进“的议题，深度解读了一个架构实现三种湖的能力和新技术。（华为云FusionInsight解决方案首席架构师徐礼锋演讲）逻辑数据湖：HetuEngine提供跨湖、跨仓、跨云统一访问，减少数据搬迁，数据高效流动，全域数据秒级协同分析秒级响应，业务上线效率提升10倍，由周级缩短至天级。实时数据湖：流处理 + Hudi实现数据更新入湖，从T+1到T+0； ClickHouse提供毫秒级实时OLAP分析能力；Flink提供FlinkSQL能力，批流SQL接口统一，实现流批一体。离线数据湖：HetuEngine提供秒级交互式查询能力，数据不出湖，分析链路短，性能比Impala快30%+，分析提效10倍+；DLC提供统一的元数据，数据全局可视； HetuEngine提供湖内统一SQL接口：HDFS、Hive、HBase、ES等，简化用数。华为云FusionInsight MRS践行产学研合作，全面推进大数据开源技术发展，联合清华大学发布了IoTDB时序引擎版本。目前华为云FusionInsight MRS已应用于60多个国家3000+客户，助力政企客户实现一企一湖、一城一湖，业务洞见更准，价值兑现更快！华为云GaussDB技术专家胡彦军分享了“华为云云原生分布式数据库GaussDB，多模架构，多元生态“的议题，为我们解读了华为倾力打造的云原生数据库GaussDB系列产品的技术创新与行业普惠。（华为云GaussDB技术专家胡彦军演讲）华为云GaussDB(for openGauss)基于云化的部署模式，分布式形态，生态开放，更好满足了企业的数据库诉求。经过13年的积累，从内部锤炼，再到外部行业实践，华为云GaussDB(for openGauss)淬炼出6大核心能力：（1）超高可用：支持跨机房、同城、异地、多活高可用，支持分布式强一致，数据0丢失。（2）开放生态：openGauss开放生态，确保客户避免被类似传统商业数据库的封闭生态锁定。（3）极致扩展：通过分布式全局事务一致性优化，实现计算与存储的垂直扩展能力，同时支持新增分片的数据在线重分布能力。（4）卓越性能：分布式优化器+Numa-aware技术加持，提供极致性能。在TPC-C、TPC-H等企业级负载下性能表现卓越。以及具备丰富的企业级特性（如支持HTAP混合负载，拥有AI自治能力）和超高的安全性（具备独立的代码级的问题修复能力及架构优化能力），构建了极具竞争力的能力。华为云GaussDB(DWS)技术专家李海丰分享了“华为云GaussDB(DWS)实时数仓，提速全场景数据分析“的议题，其中实时数仓的时序引擎和CEP引擎成为亮点。（华为云GaussDB(DWS)技术专家李海丰演讲）华为云GaussDB(DWS) 是一款具备分析及混合负载能力的分布式数据仓库，支持行存储与列存储，提供PB级数据分析能力、多模分析能力和实时处理能力，用于数据仓库、数据集市、实时分析、实时决策和混合负载等场景，广泛应用于汽车、制造、零售、互联网、金融、政府、电信等行业核心分析决策系统。作为新一代全场景云原生数据仓库，它不仅仅是把数仓搬上云这么简单，而是真正面向未来的云原生架构的数仓服务。传统数仓一般是基于分布式shared nothing的MPP架构实现的，而GaussDB(DWS)在MPP架构的基础上，与高性能的云存储相结合，打造了多温存储的存算分离架构，支持资源的弹性伸缩。同时，逻辑集群和多租户技术，将存储和计算资源进行了更细粒度的隔离，用户可以对不同的业务划分不同的逻辑集群或租户，实现更加灵活的弹性。受益于云服务的多样性，GaussDB(DWS)支持多源、多模的融合分析，既可以在库内支持时序、流、全文检索、GIS等内置多引擎的数据分析，又可以基于OBS实现跨引擎的协同计算，例如与FusionInsight MRS云原生数据湖、GES图引擎、ModelArts AI平台等实现数据免搬迁。至此，华为云TechWave全球技术峰会数据使能分论坛圆满结束。围绕“数据使能，驱动业务增长”主题，为现场观众讲述了金融、交通等行业的数字化转型创新实践，联合合作伙伴畅谈数据湖BI联合解决方案，云集华为云DAYU数据使能、FusionInsight MRS云原生数据湖、GaussDB数据库、GaussDB(DWS)数据仓库等技术专家共聚一堂“鹏城论数”，探讨政企用数之道，分享了政企客户数字化前沿技术。下一场，上海，与您不见不散！调查问卷更多内容，华为云FusionInsight系列文章：https://bbs.huaweicloud.com/forum/thread-66105-1-1.html 

【摘要】 本文介绍GaussDB(DWS)和Teradata数据库分区表的实现原理和使用方法。第一章：GaussDB(DWS)分区介绍一、      分区与分区表：1.    分区表及分区概念：分区表是把逻辑上的一张表根据某种方案分成几张物理块进行存储。这张逻辑上的表称之为分区表，物理块称之为分区。分区表是一张逻辑表，不存储数据，数据实际是存储在分区上的，即是由普通表存储的，主要用于提升查询性能。常见的分区方案有范围分区（Range Partitioning）、哈希分区（Hash Partitioning）、列表分区（List Partitioning）、数值分区（Value Partition）等。目前行存表、列存表仅支持范围分区。范围分区是根据表的一列或者多列，将要插入表的记录分为若干个范围，这些范围在不同的分区里没有重叠。为每个范围创建一个分区，用来存储相应的数据。范围分区的分区策略是指记录插入分区的方式。目前范围分区仅支持范围分区策略。范围分区策略：根据分区键值将记录映射到已创建的某个分区上，如果可以映射到已 创建的某一分区上，则把记录插入到对应的分区上，否则给出报错和提示信息。这是常用的分区策略。范围分区表：将数据基于范围映射到每一个分区，这个范围是由创建分区表时指定的分区键决定的。这种分区方式是为常用的，并且分区键经常采用日期，例如将销售数据按照月份进行分区。 2.    GaussDB(DWS)分区表：GaussDB(DWS)数据库支持的分区表为范围分区表。通过分区表的剪枝机制可以大幅减少数据的扫描量。有限地支持唯一约束和主键约束，即唯一约束和主键约束的约束键必须包含所有分区键。分区表上不支持并行创建索引、不支持创建部分索引、不支持NULL FIRST特性。在分区表上创建唯一索引时，索引项中必须包含分布列和所有分区键。在数据写入分区表时，GaussDB(DWS)还提供了Exchange（交换分区）的技术来提升写入性能。 3.    分区及使用分区表的好处：分区可以提供若干好处：l  某些类型的查询性能可以得到极大提升。特别是表中访问率较高的行位于一个单 独分区或少数几个分区上的情况下。分区可以减少数据的搜索空间，提高数据访问效率。l  当查询或更新一个分区的大部分记录时，连续扫描那个分区而不是访问整个表可 以获得巨大的性能提升。l  如果需要大量加载或者删除的记录位于单独的分区上，则可以通过直接读取或删 除那个分区以获得巨大的性能提升，同时还可以避免由于大量DELETE导致的 VACUUM超载（仅范围分区）。 分区表和普通表相比具有以下优点：l  改善查询性能：对分区对象的查询可以仅搜索自己关心的分区，提高检索效率。l  增强可用性：如果分区表的某个分区出现故障，表在其他分区的数据仍然可用。l  方便维护：如果分区表的某个分区出现故障，需要修复数据，只修复该分区即可。l  均衡I/O：可以把不同的分区映射到不同的磁盘以平衡I/O，改善整个系统性能。 二、         GaussDB(DWS)分区：1.    GaussDB(DWS)分区表的技术指标：l  创建列存分区表和HDFS分区表的数量建议不超过1000个。l  分区表的分区个数最大值为32768l  分区表的单个分区大小最大值为1PBl  分区表的单个分区记录数最大值为255 2.    分区建议当表中的数据量很大时，应当对表进行分区，一般需要遵循以下原则：l  【建议】使用具有明显区间性的字段进行分区，比如日期、区域等字段上建立分区。l  【建议】分区名称应当体现分区的数据特征。例如，关键字+区间特征。l  【建议】将分区上边界的分区值定义为MAXVALUE，以防止可能出现的数据溢 出。普通表若要转成分区表，需要新建分区表，然后把普通表中的数据导入到新建的分区表中。因此在初始设计表时，请根据业务提前规划是否使用分区表。 3.    分区使用说明3.1 创建表空间CREATE TABLESPACEØ  只有系统管理员可以创建表空间。Ø  不允许在一个事务块内部执行CREATE TABLESPACE。Ø  执行CREATE TABLESPACE失败，如果内部创建目录（文件）操作成功了就会产生残留的目录（文件），重新创建时需要用户手动清理表空间指定的目录下残留的 内容。如果在创建过程中涉及到数据目录下的表空间软连接残留，需要先将软连 接的残留文件删除，再重新执行OM相关操作。Ø  CREATE TABLESPACE不支持两阶段事务，如果部分节点执行失败，不支持回滚。语法：CREATE TABLESPACE tablespace_name                                                                                        [ OWNER user_name ] RELATIVE LOCATION 'directory' [ MAXSIZE 'space_size' ]    [with_option_clause];其中普通表空间的with_option_clause为： WITH ( {filesystem= { 'general'| "general" | general} |                              random_page_cost = { 'value' | value } |                                                                   seq_page_cost = { 'value' | value }}[,...])其中HDFS表空间的with_option_clause为： WITH ( filesystem= { 'systemtype '| "systemtype" | systemtype }                                [ { , address = 'ip:port [ {, ip:port }]' ],                                                                            cfgpath = 'path' , storepath = 'rootpath'                                                                              [{, random_page_cost = { 'value'| value }}]                                          [{,seq_page_cost = { 'value'| value }}]) 3.2  创建分区表                            CREATE TABLE PARTITION                            语法：CREATE TABLE [ IF NOT EXISTS ] partition_table_name                                            ( [                                                                                                                                  { column_name data_type [ COLLATE collation ] [ column_constraint [ ... ] ]                  | table_constraint                                                                                                                | LIKE source_table [ like_option [...] ] }[, ... ]                                                            ] )                                                                                                                                                [ WITH ( {storage_parameter = value} [, ... ] ) ]                                                                [ COMPRESS | NOCOMPRESS ]                                                                                             [ TABLESPACE tablespace_name ]                                                                               [ DISTRIBUTE BY { REPLICATION | { [ HASH ] ( column_name ) } } ]                             [ TO { GROUP groupname | NODE ( nodename [, ... ] ) } ]                            PARTITION BY {                                                                                                                            {VALUES (partition_key)} |                                                                                            {RANGE (partition_key) ( partition_less_than_item [, ... ] )} |                                     {RANGE (partition_key) ( partition_start_end_item [, ... ] )}                                       } [ { ENABLE | DISABLE } ROW MOVEMENT ];列约束column_constraint：[ CONSTRAINT constraint_name ]                                                                                                  { NOT NULL | NULL |                                                                                                   CHECK ( expression ) |                                                                                                 DEFAULT default_expr |                                                                                               UNIQUE index_parameters |                                                                         PRIMARY KEY index_parameters }                                                                                        [ DEFERRABLE | NOT DEFERRABLE | INITIALLY DEFERRED | INITIALLY IMMEDIATE ]表约束table_constraint：[ CONSTRAINT constraint_name ]                                                                                                  { CHECK ( expression ) |                                                                                               UNIQUE ( column_name [, ... ] ) index_parameters |                                   PRIMARY KEY ( column_name [, ... ] ) index_parameters}                                        [ DEFERRABLE | NOT DEFERRABLE | INITIALLY DEFERRED | INITIALLY IMMEDIATE ]like选项like_option：{ INCLUDING | EXCLUDING } { DEFAULTS | CONSTRAINTS | INDEXES | STORAGE | COMMENTS | RELOPTIONS | DISTRIBUTION | ALL }索引存储参数index_parameters：[ WITH ( {storage_parameter = value} [, ... ] ) ]                                                         [USING INDEX TABLESPACE tablespace_name ]partition_less_than_item：PARTITION partition_name VALUES LESS THAN                                                                           ( { partition_value | MAXVALUE } )                                                                                      [TABLESPACE tablespace_name]partition_start_end_item：PARTITION partition_name {                                                                                           {START(partition_value) END (partition_value) EVERY (interval_value)} |                {START(partition_value) END ({partition_value | MAXVALUE})} |                                      {START(partition_value)} |                                                        {END({partition_value | MAXVALUE})}                                                                                   } [TABLESPACE tablespace_name]在创建分区表若第一个分区定义含START值，则范围（MINVALUE，START） 将自动作为实际的第一个分区。在创建分区表时START END与LESS THAN语法不可混合使用。即使创建分区表时使用START END语法，备份（gs_dump）出的SQL语句也是 VALUES LESS THAN语法格式。3.3  修改表分区                            ALTER TABLE PARTITION修改表分区，包括增删分区、切割分区、合成分区，以及修改分区属性等。注意事项Ø  添加分区的表空间不能是PG_GLOBAL。Ø  添加分区的名字不能与该分区表已有分区的名字相同。Ø  添加分区的分区键值要和分区表的分区键的类型一致，且要大于分区表中后一个范围分区的上边界。Ø  如果目标分区表中已有分区数达到了大值（32767），则不能继续添加分区。Ø  当分区表只有一个分区时，不能删除该分区。Ø  选择分区使用PARTITION FOR()，括号里指定值个数应该与定义分区时使用的列 个数相同，并且一一对应。Ø  Value分区表不支持相应的Alter Partition操作。Ø  列存分区表不支持切割分区。Ø  不能修改分区表的tablespace，但可以修改分区的tablespace。                            ● 修改表分区主语法：ALTER TABLE [ IF EXISTS ]                                                                                                                 { table_name | ONLY table_name | ONLY ( table_name  )}                      action [, ... ];其中action统指如下分区维护子语法。当存在多个分区维护子句时，保证了分区 的连续性，无论这些子句的排序如何，GaussDB A总会先执行DROP PARTITION再执行ADD PARTITION操作，后顺序执行其它分区维护操作。move_clause  |                                                                                          exchange_clause  |                                                                                                        row_clause  |                                                                                                     merge_clause  |                                                                                                 modify_clause  |                                                                                                       split_clause  |                                                                                                                add_clause  |                                                                                                              drop_clause– move_clause子语法用于移动分区到新的表空间。MOVE PARTITION { partion_name | FOR ( partition_value [, ...] ) }                       TABLESPACE tablespacename– exchange_clause子语法用于把普通表的数据迁移到指定的分区。EXCHANGE PARTITION { ( partition_name ) | FOR ( partition_value [, ...] ) }      WITH TABLE {[ ONLY ] ordinary_table_name | ordinary_table_name * |                        ONLY ( ordinary_table_name )}                                                                                        [ { WITH | WITHOUT } VALIDATION ] [ VERBOSE ]进行交换的普通表和分区必须满足如下条件： ▪ 普通表和分区的列数目相同，对应列的信息严格一致，包括：列名、列的数据类型、列约束、列的Collation信息、列的存储参数、列的压缩信息等。 ▪ 普通表和分区的表压缩信息严格一致。 ▪ 普通表和分区的分布列信息严格一致。 ▪ 普通表和分区的索引个数相同，且对应索引的信息严格一致。 ▪ 普通表和分区的表约束个数相同，且对应表约束的信息严格一致。 ▪ 普通表不可以是临时表。 完成交换后，普通表和分区的数据被置换，同时普通表和分区的表空间信息被置换。此时，普通表和分区的统计信息变得不可靠，需要对普通表和分区重新执行analyze。– row_clause子语法用于设置分区表的行迁移开关。{ ENABLE | DISABLE } ROW MOVEMENT– merge_clause子语法用于把多个分区合并成一个分区。MERGE PARTITIONS { partition_name } [, ...] INTO PARTITION partition_name                    [ TABLESPACE tablespacename ]– modify_clause子语法用于设置分区索引是否可用。MODIFY PARTITION partition_name                                                                                      { UNUSABLE LOCAL INDEXES | REBUILD UNUSABLE LOCAL INDEXES }– split_clause子语法用于把一个分区切割成多个分区。SPLIT PARTITION { partition_name | FOR ( partition_value [, ...] ) }                                         { split_point_clause | no_split_point_clause }▪ 指定切割点split_point_clause的语法为:                     AT ( partition_value ) INTO ( PARTITION partition_name                                                 [ TABLESPACE tablespacename ] ,                                                                                            PARTITION partition_name [ TABLESPACE tablespacename ] )u  列存分区表不支持切割分区。                                        u  切割点的大小要位于正在被切割的分区的分区键范围内，指定切割点的方式只能把一个分区切割成两个新分区。▪ 不指定切割点no_split_point_clause的语法为。 INTO { ( partition_less_than_item [, ...] ) | ( partition_start_end_item [, ...] ) }u  不指定切割点的方式，partition_less_than_item指定的第一个新分区的分区键要大于正在被切割的分区的前一个分区（如果存在的话）的 分区键，partition_less_than_item指定的后一个分区的分区键要等于正在被切割的分区的分区键大小。u  不指定切割点的方式，partition_start_end_item指定的第一个新分区的起始点（如果存在的话）必须等于正在被切割的分区的前一个分区（如果存在的话）的分区键，partition_start_end_item指定的后一个分区的终止点（如果存在的话）必须等于正在被切割的分区的分区 键。u  partition_less_than_item支持的分区键个数多为4，而partition_start_end_item仅支持1个分区键。u  在同一语句中partition_less_than_item和partition_start_end_item两者不可同时使用；不同split语句之间没有限制。▪ 分区项partition_less_than_item的语法为: PARTITION partition_name VALUES LESS THAN ( { partition_value | MAXVALUE }              [, ...] )                                                                                                                                     [ TABLESPACE tablespacename ]▪ 分区项partition_start_end_item的语法为: PARTITION partition_name {                                                            {START(partition_value) END (partition_value) EVERY (interval_value)} |                   {START(partition_value) END ({partition_value | MAXVALUE})} |                               {START(partition_value)} |                                                                                                  {END({partition_value | MAXVALUE})} }                                                                 [TABLESPACE tablespace_name]– add_clause子语法用于为指定的分区表添加一个或多个分区。 ADD {partition_less_than_item | partition_start_end_item}– drop_clause子语法用于删除分区表中的指定分区。 DROP PARTITION { partition_name | FOR ( partition_value [, ...] ) } ● 修改表分区名字的语法:ALTER TABLE [ IF EXISTS ] { table_name| ONLY table_name | ONLY ( table_name  )} RENAME PARTITION { partion_name | FOR ( partition_value [, ...] ) } TO partition_new_name; 3.4  查询分区语法: SELECT * FROM [scheme]. table_name                                                           PARTITION { ( partition_name ) |                                                                         FOR ( partition_value [, ...] ) };3.5  删除分区表DROP TABLE删除指定的分区表。DROP TABLE会强制删除指定的表，删除表后，依赖该表的索引会被删除，而使用到该表的函数和存储过程将无法执行。删除分区表，会同时删除分区表中的所有分区。删除分区表与删除普通表的语法一致，都是通过DROP TABLE语法进行删除。语法:DROP TABLE [ IF EXISTS ]                                                                                                                { [schema.]table_name } [, ...] [ CASCADE | RESTRICT ];3.6  删除表空间DROP TABLESPACEØ  只有表空间所有者有权限执行DROP TABLESPACE命令，系统管理员默认拥有此权限。Ø  在删除一个表空间之前，表空间里面不能有任何数据库对象，否则会报错。Ø  DROP TABLESPACE不支持回滚，因此，不能出现在事务块内部。Ø  执行DROP TABLESPACE操作时，如果有另外的会话执行\db查询操作，可能会由于tablespace事务的原因导致查询失败，请重新执行\db查询操作。Ø  如果执行DROP TABLESPACE失败，需要再次执行一次DROP TABLESPACE IF EXISTS。 语法:DROP TABLESPACE [ IF EXISTS ] tablespace_name;第二章：Teradata分区介绍一、      Teradata分区表的设计原理：1.1  创建分区表的时候会在每行记录上加一个分区值Partition #。Ø  Row ID = Partition # + Row Hash + Uniqueness ValueØ  在新版本里面会自适应表分区的个数，小于65,535时使用2-byte做分区值，如果大于会用8-byte分区值，最大支持：9.223 E18个分区 1.2  数据存放的三级机制：Ø  通过Row的PI字段的hash值确定放那个AMP上（类比我们的逻辑DN）Ø  在AMP级别，Row会按其分区值排序存放。Ø  在分区内，数据行通过Row-ID序列逻辑存储。  图例：1.3  分区表数据访问机制：二、      Teradata分区表的优缺说明：2.1. 优点：Ø  提升按partition字段查询的效率，避免做全表扫描，节约IO资源。 2.2. 缺点：Ø  每行多申请2-byte空间（8-byte），会需要额外perm空间。Ø  PI的访问可能会慢，因为要扫每个partition。Ø  PI的join可能会比较慢，以前等值直接join，现在要每个分区都需要做sub-join。Ø  不能定义UPI，因为这样会导致insert-select会非常慢，需要判断每个partition里面的合法性。 三、      Teradata分区表的使用说明3.1. 创建分区表语法：CREATE TABLE …[UNIQUE] PRIMARY INDEX (col1, col2, …)PARTITION BY <partitioning-expression> Ø  <partitioning-expression>选项包括:²  范围分区²  条件分区, 模数分区, 和表达式分区.²  分区列不一定是PI中的字段，如果不是的话，那么PI不能加唯一约束。²  分区表达式中包括的列称为“分区列”。²  TD提供了RANGE_N和CASE_N两个函数来方便创建常见分区表。 3.2. RANGE_N的使用说明Ø  test_expression一个表达式或者字段，数据类型为BYTEINT, SMALLINT, INTEGER, DATE, CHAR, VARCHAR, GRAPHIC or VARGRAPHIC。Ø  start_expression*定义范围起始边界的字符串或字符串表达式。start_expression的数据类型必须与test_expression的数据类型相同，或者必须隐式转换为与test_expression相同的数据类型。如果未指定结束边界，则范围由其开始边界定义（并且该开始边界包括在该范围内），直到但不包括下一个范围的开始边界。使用星号（*）作为列表中第一个范围的开始边界，以指示可能的最小值（所有值和NULL均大于指定为星号的起始边界）。 星号与任何数据类型兼容。Ø  end_expression*定义范围结束边界的字符串或字符串表达式。end_expression的数据类型必须与test_expression的数据类型相同，或者必须隐式转换为与test_expression相同的数据类型。列表中的最后一个范围必须指定结束边界。 对于所有其他范围，如果没有指定结束边界，则范围由其开始边界定义（并且该开始边界包括在该范围内），直到但不包括下一个范围的开始边界。星号（*）表示列表中最后一个范围的结束边界，以表示可能的最大值（所有值和NULL均小于指定为星号的结束边界）。Ø  EACH range_size值大于零的字符或字符表达式。指定一个EACH短语的范围等效于一系列范围，其中系列中的第一个范围从start_expression开始，随后的范围从start_expression +（range_size * n）开始，当start_expression +（range_size * n）小于或等于end_expression，或者小于范围列表中的下一个start_expression时，n从1开始递增1。对于DATE类型，在后续范围内的有效日期的计算使用ADD_MONTHS而不是加号（+）算术运算符。range_size的数据类型必须兼容才能添加到test_expression中。Ø  Note:如果test_expression的数据类型是字符类型（CHAR，VARCHAR，GRAPHIC或VARGRAPHIC），则无法指定EACH短语。Ø  NO RANGE用于处理未映射到任何指定范围的test_expression的范围。Ø  OR UNKNOWN与NO RANGE一起使用。NO RANGE或UNKNOWN处理不会映射到任何指定范围的test_expression，或者当RANGE_N未指定BETWEEN * AND *范围时，test_expression评估为NULL。Ø  UNKNOWN当RANGE_N未指定范围BETWEEN * AND *时，处理一个求值为NULL的test_expression。 Ø  例如：例1:CREATE TABLE orders(storeid INTEGER NOT NULL,productid INTEGER NOT NULL,orderdate DATE FORMAT 'yyyy-mm-dd' NOT NULL,totalorders INTEGER)PRIMARY INDEX (storeid, productid)PARTITION BY RANGE_N(totalorders BETWEEN *, 100, 1000 AND *,UNKNOWN); 分区号范围1totalorders >1002100<=totalorders<1000 3totalorders >=10004totalorders =NULL,UNKNOWN. 例2: CREATE TABLE orders(storeid INTEGER NOT NULL,productid INTEGER NOT NULL,orderdate DATE FORMAT 'yyyy-mm-dd' NOT NULL,totalorders INTEGER NOT NULL)PRIMARY INDEX (storeid, productid)PARTITION BY (RANGE_N(totalorders BETWEEN *, 100, 1000 AND *),RANGE_N(orderdate BETWEEN *, '2005-12-31' AND *) ); Level 1 Partition NumberLevel 2 Partition Number范围11totalorders >100 and   orderdate<'2005-12-31'2totalorders >100 and   orderdate>='2005-12-31'21(100<=totalorders<1000) and   orderdate<'2005-12-31'2(100<=totalorders<1000) and   orderdate>='2005-12-31'31totalorders >=1000 and   orderdate<'2005-12-31'2totalorders >=1000 and   orderdate>='2005-12-31' 例3.CREATE TABLE Orders(o_orderkey INTEGER NOT NULL,o_custkey INTEGER,o_orderstatus CHAR(1) CASESPECIFIC,o_totalprice DECIMAL(13,2) NOT NULL,o_orderdate DATE FORMAT 'yyyy-mm-dd' NOT NULL,o_orderpriority CHAR(21),o_comment VARCHAR(79))PRIMARY INDEX (o_orderkey)PARTITION BY RANGE_N(o_orderdate BETWEEN DATE '2002-01-01' AND DATE '2008-12-31'EACH INTERVAL '1' MONTH) 分区为：2002-01-01到2008-12-31日期范围内的数据，每个月的数据作为一个分区。 目前在银行数据仓库中，第三种分区方式比较常见。 3.3. CASE_N的使用说明Ø  conditional_expression条件表达式,计算结果必须为TRUE，FALSE或UNKNOWN。Ø  NO CASE如果所有的conditional_expression计算结果为FALSE,则取值为TRUE。Ø  OR UNKNOWN和 NO CASE一起使用.如果列表中的conditional_expression结果为FALSE、或者UNKNOWN，则NO CASE 或者 UNKNOWN结果为TRUE。Ø  UNKNOWN如果conditional_expression评估为UNKNOWN且列表中的所有先前条件均评估为TRUE评估为FALSE。 Ø  例如：例1. CREATE TABLE orders(storeid INTEGER NOT NULL,productid INTEGER NOT NULL,orderdate DATE FORMAT 'yyyy-mm-dd' NOT NULL,totalorders INTEGER)PRIMARY INDEX (storeid, productid)PARTITION BY CASE_N(totalorders < 100, totalorders < 1000,NO CASE, UNKNOWN); 分区号范围1totalorders >1002100<=totalorders<1000 3totalorders >=10004totalorders =NULL,UNKNOWN. 例2.CREATE TABLE orders(storeid INTEGER NOT NULL,productid INTEGER NOT NULL,orderdate DATE FORMAT 'yyyy-mm-dd' NOT NULL,totalorders INTEGER NOT NULL)PRIMARY INDEX (storeid, productid)PARTITION BY (CASE_N(totalorders < 100, totalorders < 1000,NO CASE),CASE_N(orderdate <= '2005-12-31', NO CASE) ); Level 1 Partition NumberLevel 2 Partition Number范围11totalorders >100 and   orderdate<'2005-12-31'2totalorders >100 and   orderdate>='2005-12-31'21(100<=totalorders<1000) and   orderdate<'2005-12-31'2(100<=totalorders<1000) and   orderdate>='2005-12-31'31totalorders >=1000 and   orderdate<'2005-12-31'2totalorders >=1000 and   orderdate>='2005-12-31'

【摘要】 使用Python连接GaussDB(DWS)的配置步骤及程序编写样例。配置方法：1、安装psycopg2；rpm -ivh python-psycopg2-2.5.1-3.el7.x86_64.rpm2、编写python脚本样例，并赋予执行权限；import psycopg2conn = psycopg2.connect(database="pocdb", user="u1",password="******", host="*.*.*.*", port="25308")cursor = conn.cursor()cursor.execute("DROP TABLE if exists test_conn")cursor.execute("CREATE TABLE test_conn(id int, name text)")cursor.execute("INSERT INTO test_conn values(1,'haha')")cursor.execute("INSERT INTO test_conn values(2,'lala')")cursor.execute("update test_conn set name = 'xixi'")cursor.execute("delete from test_conn where id = 1")conn.commit()cursor.execute("select * from test_conn")rows = cursor.fetchall()for row in rows:    print 'id = ',row[0], 'name = ', row[1], '\n'cursor.close()conn.close()3、执行脚本刷新环境变量：source /opt/huawei/Bigdata/mppdb/.mppdbgs_profilepython test.py4、登录数据库，查验数据；步骤1 连接服务器：*.*.*.*  root/*****，或者直接用omm用户连接，omm/******;步骤2 切换omm用户 ,刷新环境变量；         source /opt/huawei/Bigdata/mppdb/.mppdbgs_profile步骤3 连接数据库；         gsql -d pocdb -p 25308  -U u1 -W ****** -r         执行sql命令，\d+ tablename查看表定义；         \d+ test_conn         查询表数据；         Select * from test_conn;

摘要】 本文介绍使用perl通过ODBC连接GaussDB(DWS)的安装和配置方法使用perl语言连接Gaussdb1 准备本例使用软件如下unixODBC-2.3.0DBI-1.642DBD-ODBC-1.562   安装unixODBC2.1 上传安装包使用root用户上传安装包unixODBC-2.3.0.tar.gz到/tmp下2.2 安装使用root用户安装，执行如下命令cd /tmptar zxvf unixODBC-2.3.0.tar.gzcd unixODBC-2.3.0./configure --enable-gui=no（x86编译命令）./configure --enable-gui=no --build=arm-linux（arm编译命令）makemake install2.3 测试安装结果命令行敲击isql，出现如下结果，表示安装成功2.4  替换驱动程序包解压GaussDB-Kernel-V300R002C00-SUSE11-64bit-Odbc.tar.gz包把odbc/lib下的psqlodbcw.la，psqlodbcw.so 这2个文件拷贝到/usr/local/lib路径下。2.5 添加环境变量使用omm用户，编辑~/.bashrc文件,追加红色内容vi ~/.bashrcexport LD_LIBRARY_PATH=/usr/local/lib/:$LD_LIBRARY_PATHexport ODBCSYSINI=/usr/local/etcexport ODBCINI=/usr/local/etc/odbc.ini 生效环境变量source ~/.bashrc2.6   配置数据源使用root用户，做如下操作。在“/usr/local/etc/odbcinst.ini”文件中追加以下内容。vi /usr/local/etc/odbcinst.ini[GaussMPP]Driver64=/usr/local/lib/psqlodbcw.sosetup=/usr/local/lib/psqlodbcw.so 在“/usr/local/etc/odbc.ini ”文件中追加以下内容。vi /usr/local/etc/odbc.ini[GaussODBC]Driver=GaussMPPServername=10.185.180.123（数据库Server IP）Database=postgres （数据库名）Username=odbc （数据库用户名）Password=Bigdata123@ （数据库用户密码）Port=25308 （数据库监听端口）Sslmode=allow2.7  配置pg_hba.conf文件gs_guc set -Z coordinator -N all -I all -h "host all all 10.185.180.123/32 sha256"2.8  重启集群source /opt/huawei/Bigdata/mppdb/.mppdbgs_profilecm_ctl stopcm_ctl start2.9  创建odbc配置的用户如果用户已经存在，可以忽略此步。登录CNsource /opt/huawei/Bigdata/mppdb/.mppdbgs_profilegsql -d postgres -p 25308 -arcreate user odbc password 'Bigdata123@';2.10 测试isql -v GaussODBC出现如下结果表示配置成功3  安装DBI3.1  上传安装包使用root用户上传安装包DBI-1.642.tar到/tmp下3.2 安装使用root用户安装，执行如下命令cd /tmptar xvf DBI-1.642.tarcd DBI-1.642perl Makefile.PLmakemake install4 安装DBD-ODBC4.1 上传安装包使用root用户上传安装包DBD-ODBC-1.56.tar.gz到/tmp下4.2  安装使用root用户安装，执行如下命令cd /tmptar zxvf DBD-ODBC-1.56.tar.gzcd DBD-ODBC-1.56perl Makefile.PLmakemake install5  Perl脚本连接数据库脚本：use DBI;my $dbh;$dbh = DBI->connect("dbi:ODBC:GaussODBC","odbc","Bigdata123@",{AutoCommit => 1, PrintError => 1, RaiseError => 0, LongReadLen => 1048576});my $sth = $dbh->prepare("select current_time");$sth ->execute();@tabrow=$sth->fetchrow();$result=@tabrow[0];$sth->finish();$dbh->disconnect();print $result."\n";

背景：当前sql多表关联sql性能较差，经分析关联条件已经是分布键，数据分布均匀，统计信息均已收集，想进一步优化可以通过创建PCK进行性能提升。PCK的选取遵循以下原则：•【关注】一张表上只能建立一个PCK，一个PCK可以包含多列，但是一般不建议超过2列。•【建议】在查询中的简单表达式过滤条件上创建PCK。这种过滤条件一般形如col op const，其中col为列名，op为操作符 =、>、>=、<=、<，const为常量值。•【建议】在满足上面条件的前提下，选择distinct值比较少的列上建PCK。1、在已有表结构创建pckALTER TABLE tablename ADD PARTIAL CLUSTER KEY(column name);主表从表均需要增加局部聚簇键，然后对张表执行VACUUM FULL，使局部聚簇生效。2、当pck设置不合理可以用如下语句删除再调整ALTER TABLE tablename DROP CONSTRAINT pckname;3、pckname获取方式可以执行\d+ tablename ,红色部分即pcknamePartial Cluster :    "student1_cluster" PARTIAL CLUSTER KEY (stuno)4、pck紧随where 也可提升性能

我们在学习GaussDB(DWS)的基础知识时都学习了安全环的概念，即GaussDB在数据安全方面采用的是三副本（主，备，从）的安全环方式，那么，大家是否有思考过，一个多节点的集群中最多可以坏几个节点呢？    虽然设计的是三副本，日常使用中至少得保证有两副本可用才不会导致集群不可用。下面分别以3节点2DN和8节点2DN的集群来分析一下这个“最多”我们应该怎么计算。   如果我们采用3节点2DN的方式部署集群的话，三副本的主备从分布图如下：             根据上图，我们以节点1上的主DN为基准，什么损坏情况下这两个DN的数据损坏会导致集群不可用呢？我们假设节点3宕机了，那么，此时DN1的从备和DN2的备份不可用，而在节点2上分别有DN1的备份和DN2的从备，此时仍然保障着两幅本可用，即不会导致集群不可用，只是会导致集群的性能下降。仍然回到DN1和DN2的分布上来，如果再多宕机一台节点，明显可以看到，同理，当我们以DN3和DN4的主为基准时，分析的方法是相同的，即此时节点1和节点3可以任意宕机一个。      综上，我先假设一个计算方法，一个集群中最多可down机的节点个数=节点总数/(dn个数+1)，对应到上面的例子：3/(2+1)=1,即最多可以有一个节点down机。          如果是8节点2DN的集群呢？ 上述公式是否同样适用？ 首先，我们来看8节点2DN的主备从分布图，如下：          上图中我们仍然以DN1和DN2为基准，可以看到节点1到节点4组成了一个安全环，假设节点1down了，那么节点2,3,4就不能再down了；我们接着看，假设节点5down了，那么，节点6,7,8就不能再down了。此时，我们看到节点1和节点5down掉以后，其他节点都不具备down机的条件了，否则就会导致集群不可用。我们看看此时上述公式是否使用？ 节点总数 8/ (dn个数+1) = 8/3约等于2.6， 因为机器没有半台，而我们又不能多down机一台，只能取整数部分。这样来看，上述公式基本适用，但是，需要完善，即取一下整数部分。      综上，个人认为一个集群中最多可down的节点数 =节点总数/(dn个数+1)，然后，取整数。      以上纯属个人观点，如有错误，欢迎指正。

我们知道GaussDB(DWS)为了保证业务的连续性和高可靠性，各个组件都进行了高可用设计。下图是应用访问GaussDB(DWS)的业务流程架构图，对于业务应用或者用户来说，他们发生请求给CN，CN解析并生成执行计划，交给DN去执行，执行后再由CN汇总将数据返回给业务用户或者业务应用。这个过程是容易理解的，本次我们重点关注的是站在CN前面的LVS+KeepAlived。现在的问题是：CN的返回结果是否会经过LVS，然后再返回给前端应用？如果经过LVS，那么，LVS会不会成为单点瓶颈？带着这两个问题我们探究一下LVS和KeepAlived的原理。一、LVS是什么？ LVS是Linux Virtual Server的简称，也就是Linux虚拟服务器, 是一个由章文嵩博士发起的自由软件项目，它的官方站点是www.linuxvirtualserver.org。现在LVS已经是 Linux标准内核的一部分，在Linux2.4内核以前，使用LVS时必须要重新编译内核以支持LVS功能模块，但是从Linux2.4内核以后，已经完全内置了LVS的各个功能模块，无需给内核打任何补丁，可以直接使用LVS提供的各种功能。二、LVS的目的是什么？LVS主要用于服务器集群的负载均衡，拥有VIP，客户端将所有请求发送至此VIP，LVS负责将请求分发到不同的RS，客户不感知RS。其目的是提高服务器的性能，将请求均衡的转移到不同的服务器上执行，从而将一组服务器构成高性能、高可靠的虚拟服务器。 三、LVS的体系结构使用LVS架设的服务器集群系统有三个部分组成：　　（1）最前端的负载均衡层，用Load Balancer表示；　　（2）中间的服务器集群层，用Server Array表示；　　（3）最底端的数据共享存储层，用Shared Storage表示；在用户看来，所有的内部应用都是透明的，用户只是在使用一个虚拟服务器提供的高性能服务。如图：Load Balancer层：位于整个集群系统的最前端，有一台或者多台负载调度器（Director Server）组成，LVS模块就安装在Director Server上，而Director的主要作用类似于一个路由器，它含有完成LVS功能所设定的路由表，通过这些路由表把用户的请求分发给Server Array层的应用服务器（Real Server）上。同时，在Director Server上还要安装对Real Server服务的监控模块Ldirectord，此模块用于监测各个Real Server服务的健康状况。在Real Server不可用时把它从LVS路由表中剔除，恢复时重新加入。Server Array层：由一组实际运行应用服务的机器组成，Real Server可以是WEB服务器、MAIL服务器、FTP服务器、DNS服务器、视频服务器中的一个或者多个，每个Real Server之间通过高速的LAN或分布在各地的WAN相连接。在实际的应用中，Director Server也可以同时兼任Real Server的角色。Shared Storage层：是为所有Real Server提供共享存储空间和内容一致性的存储区域，在物理上，一般有磁盘阵列设备组成，为了提供内容的一致性，一般可以通过NFS网络文件系统共享数据，但是NFS在繁忙的业务系统中，性能并不是很好，此时可以采用集群文件系统，例如Red hat的GFS文件系统，oracle提供的OCFS2文件系统等。    从整个LVS结构可以看出，Director Server是整个LVS的核心，目前，用于Director Server的操作系统只能是Linux和FreeBSD，linux2.6内核不用任何设置就可以支持LVS功能，而FreeBSD作为Director Server的应用还不是很多，性能也不是很好。对于Real Server，几乎可以是所有的系统平台，Linux、windows、Solaris、AIX、BSD系列都能很好的支持。四、LVS的程序组成部分LVS 由2部分程序组成，包括 ipvs 和 ipvsadm。ipvs(ip virtual server)：一段代码工作在内核空间，叫ipvs，是真正生效实现调度的代码。ipvsadm：另外一段是工作在用户空间，叫ipvsadm，负责为ipvs内核框架编写规则，定义谁是集群服务，而谁是后端真实的服务器(Real Server)五、LVS的负载均衡机制1、 LVS是四层负载均衡，也就是说建立在OSI模型的第四层——传输层之上，传输层上有我们熟悉的TCP/UDP，LVS支持TCP/UDP的负载均衡。因为LVS是四层负载均衡，因此它相对于其它高层负载均衡的解决办法，比如DNS域名轮流解析、应用层负载的调度、客户端的调度等，它的效率是非常高的。2、 LVS的转发主要通过修改IP地址（NAT模式，分为源地址修改SNAT和目标地址修改DNAT）、修改目标MAC（DR模式）来实现。 GaussDB(DWS)目前主要采用的是DR(Direct Routing)模式，所以，我们主要聊一聊DR模式。下图是DR模式的一个示意图：DR模式下需要LVS和RS集群绑定同一个VIP（RS通过将VIP绑定在loopback实现），请求由LVS接受，由真实提供服务的服务器（RealServer, RS）直接返回给用户，返回的时候不经过LVS。详细来看，一个请求过来时，LVS只需要将网络帧的MAC地址修改为某一台RS的MAC，该包就会被转发到相应的RS处理，注意此时的源IP和目标IP都没变，LVS只是做了一下移花接木。RS收到LVS转发来的包时，链路层发现MAC是自己的，到上面的网络层，发现IP也是自己的，于是这个包被合法地接受，RS感知不到前面有LVS的存在。而当RS返回响应时，只要直接向源IP（即用户的IP）返回即可，不再经过LVS。至此，回答了我们第一个问题：CN的返回结果是否会经过LVS，然后再返回给前端应用？答：GaussDB(DWS)采用的是LVS的DR模式，返回时不再经过LVS。 接下来，我们看看keepAlived。一、什么是keepAlived？Keepalived顾名思义，保持存活，在网络里面就是保持在线了，也就是所谓的高可用或热备，用来防止单点故障(单点故障是指一旦某一点出现故障就会导致整个系统架构的不可用)的发生。二、keepAlived的原理Keepalived的实现基于VRRP（Virtual Router Redundancy Protocol，虚拟路由器冗余协议），而VRRP是为了解决静态路由的高可用。虚拟路由器由多个VRRP路由器组成，每个VRRP路由器都有各自的IP和共同的VRID(0-255)，其中一个VRRP路由器通过竞选成为MASTER，占有VIP，对外提供路由服务，其他成为BACKUP，MASTER以IP组播（组播地址：224.0.0.18）形式发送VRRP协议包，与BACKUP保持心跳连接，若MASTER不可用（或BACKUP接收不到VRRP协议包），则BACKUP通过竞选产生新的MASTER并继续对外提供路由服务，从而实现高可用。三、KeepAlived与LVS的关系1、keepalived 是 lvs 的扩展项目，是对LVS项目的扩展增强，因此它们之间具备良好的兼容性。2、对LVS应用服务层的应用服务器集群进行状态监控：若应用服务器不可用，则keepalived将其从集群中摘除，若应用服务器恢复，则keepalived将其重新加入集群中。3、检查LVS主备节点的健康状态，通过IP漂移，实现主备冗余的服务高可用，服务器集群共享一个虚拟IP，同一时间只有一个服务器占有虚拟IP并对外提供服务，若该服务器不可用，则虚拟IP漂移至另一台服务器并对外提供服务，解决LVS本身单点故障问题。 至此，我们可以回答第二个问题：如果经过LVS，那么，LVS会不会成为单点瓶颈或者出现单独故障？答：返回结果不会经过LVS，不会因为返回的数据量太大造成单独瓶颈的问题。对应请求， LVS只需要将用户请求转发给CN即可，负载很低，也不会出现单独瓶颈的问题。另外，LVS通过keepAlived实现了主备冗余，避免了单独故障。

本文主要是探讨OLAP关系型数据库框架的数据仓库平台如何设计双集群系统，即增强系统高可用的保障水准。当前社会、企业运行当中，大数据分析、数据仓库平台已逐渐成为生产、生活的重要地位，不再是一个附属的可有可无的分析系统，外部监控要求、企业内部服务，涌现大批要求7*24小时在线的应用，逐步出现不同等级要求的双集群系统。数据仓库主流数据库平台均已存在多重高可靠保障措施设计，如硬盘冗余的raid设计、数据表冗余、节点备用冗余、机柜备用数据交叉等，以及加上服务进程高可用冗余设计，其最大化程度满足数据仓库服务持续在线。但现实场景，如数据库软件缺陷、定期加固补丁、产品迭代、硬件升级这些产品现实因素，以及来自机房、数据中心、地域、网络的外部灾难故障因素，均在降低数据仓库可用性服务水平。鉴于数据仓库存在大量数据吞吐，针对不同数据库、不同可用性要求，若需要设计双集群冗余设计，可选技术手段分别有数据同步模式、双ETL模式、双活模式，具体探讨如下：1.       数据同步模式a)         架构由于数据库IO能力有限、且两个数据库间带宽有限，除了首次全量同步之后，后续通常考虑增量同步技术，即如何准确、高效获取“变化数据”，一般存在日志同步技术、备份增量同步技术、逻辑数据同步；b)        日志同步技术日志同步技术，有业内最著名Oracle Golden Gate，大部分厂家也有自己的实现方式，像Teradata近年来推出Unity CDM（变化数据广播）技术，而我司GaussDB for DWS可采用xlog及page进行变化数据同步。优势：直接同步变化数据增量，数据量少，要求带宽低，但目前市面技术大都只适合数据每日变化量较少的数据仓库环境；劣势：现实的技术门槛高，应对各类异常场景适应能力差，对主数据库侵入性能要求高，一旦主库繁忙，同步时效低；面对全删全插等变化数据量大场景，同步吃力；c)         备份增量同步技术主要利用各数据库平台备份恢复能力，进行数据增、全量备份、恢复；通常源库备份数据压缩之后，经网络传输后，解压恢复到目标库；对应GaussDB for DWS可采用roach备份恢复工具实现；优势：利用同一技术实现增、全量数据同步，逻辑清晰，各场景容错能力强；劣势：要求数据库支持增备能力，且往往锁等待严重；d)        逻辑数据同步该项主要涉及较高的业务侵入性，即充分获取ETL调度数据流元数据，对应数据库当日数据稳定之后，发起数据表导出-导入操作，针对数据表加工特性，选择增全量同步规则，进行数据准实时同步。优势：较上述同步技术，可以实现多样选择性同步，同步过程由实施项目本身控制，做到表级数据同步，不需要全系统同步，即可实现部分业务双集群；劣势：客户化同步逻辑，操作前置依赖多，实施投入人力多，较难推广；2.       双ETL模式a)         架构即采用两套独立调度平台进行数据加工，抽取同一个数据源（往往是落地稳定的数据交换平台），采用同一套ETL代码依赖逻辑调度，各自生成目标数据，往往批量过程中，采取主库对外持续服务，待主备库数据准实时或批后校验一致后，再开放备库对外服务。若双集群数据发生不一致场景，主要以主库数据为准，覆盖备库。该同步过程，需要使用到“数据同步模式”相关同步技术。b)         参照落地架构c)         加载源数据考虑为保证两套ETL调度加载数据源一致及数据复用，往往要求搭建一个数据交换平台。因为至少存在一个文件被两套调度读取，要求数据交换平台两倍过往吞吐能力；且禁止加载的数据文件被二次覆盖，导致两套系统加载不一致；d)         调度依赖顺序考虑由于ETL作业调度关系没有配置完备，即存在A作业使用B作业的数据，但不配置依赖关系（绝大部分的情况是A作业可容忍B数据的时效，是否最新数据均可以使用，故为时效，业务上不配置依赖关系；当然也存在物理时间上，通常B远远早于A执行），导致两套系统A作业生成数据不一致。该场景下，在一套调度平台无法发现此问题，但存在两套系统的校验比对，即发现数据不一致；该问题建议用户补全依赖关系，确认执行顺序一致性；当然若希望灵活使用依赖关系，则需二次开发，控制两套调度当日时序一致性；e)         ETL代码服务器考虑为了避免两套ETL调度代码维护不一致，需考虑统一维护渠道，包含不限于同一个代码存储源、版本服务器，以及代码变更时机f)          存在不确定值的SQL函数返回ETL代码中往往存在sample、random、row_number排序这种同一份数据产生不同结果集的函数，造成两套系统数据不一致；该问题建议用户使用替代函数、明确取值、唯一排序，确保最终数据一致性；同时，该设计逻辑正确情况下，哪份数据均可被业务采信，若该数据对下游影响少，可每日批后从主库同步备库，拉平数据；g)         报错修数逻辑考虑其中一套系统的数据发生报错、修数行为，会涉及到另一套系统的维护行为；可选作法是保留操作逻辑，待另一套系统发生报错时重复执行一次；其它交给数据质量校验（DQC）、数据校验去复查；h)         干预重跑修数逻辑考虑若批后重跑，两套系统重跑逻辑一致，涉及重复劳动（或支撑平台优化），相对简单；但涉及批量过程中发现部分数据需要重跑，由于两套调度进度不一致，会导致i)           数据校验 i.              校验时机批后校验，逻辑清晰，对调度依赖少，即根据整体调度进度，做到分层、分库或整体数据校验；准实时校验，即侵入调度环节，在每个作业完成时，均发起日志解析，提取每个SQL影响记录数，若相应作业SQL存在影响记录数不一致场景，即中止较晚完成的调度平台调度后续作业；ii.              校验手段增全量校验，即针对不同加工逻辑的数据表，区分增、全量数据值，以最小代价覆盖所有业务表iii.              校验方法通常作法有记录数、汇总值、checksum校验；汇总值校验，通过是数值型字段直接sum、字符型计算字符长度的sum、时间类型则转换成数值相加的比对；Checksum校验，针对全表或部分字段，进行md5或hash运算，完成两套系统一致性比对；对于关系型数据库，校验开销代价逐步递增（记录数 < 汇总值 < checksum校验）；往往是结合增量校验、结合重要指标，区分维度校验，日常增量逻辑校验，定期全量校验，在校验数据一致性和系统性能之间取得平衡点。j)           优化考量i.              校验改进即嵌入调度平台，提取ETL代码运行日志，通过执行SQL影响的记录值，实时进行两套系统完成作业日志比对，发现记录值影响，立即停止备库调度，采用人工或自动方式修复数据，继续后续批量。该作法最大好处是，即时发现数据异常，避免问题放大，保障备库更高可用性；ii.              引入统一维护平台即减少人为双系统维护操作，代码变更平台化，修数逻辑平台化，由平台分别下发两套调度平台、两套数据库。3.       双活模式以下基于Teradata Unity产品理念的延伸构想a)         架构b)         双活功能点i.              访问路由能力客户端直接将中间件作为数据库登陆，保持原来登陆逻辑不变；中间件根据登陆用户及附加参数实现拒绝登陆、双系统登陆、或单系统登陆，实现写登陆、读登陆，实现受控方式登陆、或非受控方式登陆；即实现受控和非受控方式的系统读写；同时兼顾考虑异常路由选择或同步路由选择，满足最大化异常执行及少部分同步需求场景；ii.              SQL分发能力经中间件发送的SQL指令，正常发送到相应数据库，并接受数据库响应信息；iii.              批量导入、导出能力针对数据大批量的导入，需要考虑采用更加高效的加载协议进行数据加载，并考虑经中间件复制数据块，异步分发两个数据库；数据导出，需要考虑高效数据导出协议，从其中一套数据库正确导出数据；iv.              更新类SQL校验能力Delete、Update、Insert、Merge等更新类DML SQL进行SQL影响记录数校验；DDL/DCL执行返回码验证一致性能力；v.              对象注册功能通过路由及创建对象的DDL语句，实现对象动态注册；通过命令行指令实现对象注册；适当增加对象索引、约束索引的注册信息，用于扩展细粒度对象锁能力，提高数据仓库ETL SQL并发能力；*数据仓库环境下，只需要考虑到表级双活的能力，不建议实施字段级、记录级双活； vi.              对象锁能力根据SQL指令给相应对象动态加锁、释放锁；同时根据数据库自带的锁特征，至少区分读、写锁控制，以及部分数据库的脏读功能锁；vii.              对象状态控制能力进行管理的多套数据库在线状态控制；进行对象状态控制功能，包含不限于在线、离线、只读、只写、主动中断缓存中、被动中断缓存中、不可用等状态；viii.              缓存能力进行SQL指令流缓存能力，以及缓存恢复执行的能力；进行SQL与加载数据结合缓存、以及缓存恢复执行的能力；ix.              SQL异常控制能力考虑用户体验，始终由返回响应正确的SQL指令返回客户端；两个数据库返回均成功，但返回的影响记录数不一致，则响应慢的数据库对应SQL及涉及对象被设置成不可用状态；若两套数据库其中一套执行成功，另一套执行失败，则执行失败的数据库SQL和涉及对象被设置为被动中断缓存中，同时缓存SQL，定时重试SQL；若两套数据库返回均报错，才通知客户端报错；若SQL涉及对象已处理非在线状态，则新提交的SQL被缓存，新提交SQL相应对象被设置为被动中断缓存中。针对中间件和数据库之间，存在数据库已执行完、但中间件未收到信号场景，需考虑闪环该场景（如增加事务锁等）；c)         Teradata Unity参照落地架构ü  主要通过Unity实现多集群SQL、数据分发与管理；ü  Data Mover实现集群间数据同步；ü  Eocsystem Manager实现数据批后自动校验及不一致重同步事件触发；ü  Viewpoint实现系统平台透视图展现与维护，并对接用户告警平台；d)         中间件高可用考虑由于引入了中间件（前置）服务，即该服务的稳定、可靠对双活模式至关重要。数据库单套系统本身已经具备极高的可用性，引入中间件后，由于所有数据库访问行为均通过该中间件，中间件任何异常均同时影响两套数据库访问能力。除了中间件本身所有相关服务需要满足高可用之外，还需考虑极端场景下bypass能力，此项能力在于极端异常条件下，可以保障系统持续服务的能力。高可用场景中，存在控制节点脑裂与自动升主场景，需借鉴仲裁机制减少脑残裂发生；e)         数据重同步考虑即利用“数据同步模式”相关同步技术，实现两套数据库数据重同步能力；f)          不确定值的SQL函数考虑最佳方案，是采用“数据同步模式”的数据日志重同步技术，直接将第一套数据库SQL执行结果的日志信息同步到第二套数据库中，消除返回结果不一致；部分简单的系统时间函数，直接通过中间件改写，保障SQL执行结果一致性；另外，则通过SQL改写，保证row_number函数进行主键或全字段排序，保证SQL执行结果一致性；g)         异常会话重放能力针对异常会话过程的SQL，可能需要从会话建立后，可视化选择，倒回前几个SQL重新执行，并指定过程SQL是否参与结果集校验，以及SQL回放结束的确认动作，让异常场景处理手段更加丰富。4.       适用场景a)         “数据同步模式” – 日志同步技术适用数据变化量小、数据传输压力小的数据场景，通常只适用于小型数据仓库平台；对于规模小的平台，RPO、RTO可以接近0；b)         “数据同步模式” – 备份增量同步技术适合大数据量同步场景，实现方式容易被用户理解；往往需要数据库备份工具具备增量备份恢复能力；同时考验备份工具消除相关硬件限制条件，让该技术方案更加灵活；双集群的初始化同步往往采用全备全恢的逻辑实现，可以最大化、最快拉平存量数据；对于规模大的平台，RPO往往需要小时级别，RTO最好水准也在分钟、10分钟以上；同时主集群需要保障一定资源量供数据同步使用，对主集群开销大；c)         “数据同步模式” – 逻辑数据同步技术适用灵活同步场景，往往数据同步量不会太大，或同步时间可容忍场景；此场景往往适合于用户对其数据仓库ETL过程元数据信息清晰、完整，依赖客户开发能力，相关同步数据存在清晰ETL算法，结合调度作业运行进度，动态发起相关数据表增、全量同步；对于中等规模的平台，RPO可以做到分钟、半小时，RTO可以维持在分钟级；d)         “双ETL模式”需要两套ETL调度环境，整体成本翻倍，但调度逻辑清晰、易于理解和维护；较容易匹配不同规模的数据仓库平台采纳；较难实现数据实时比对，以及数据发生不一致之后的控制逻辑（若需要实现，对于调度逻辑侵入性大）；ETL调度批量中途，较难实现两套调度链路协调重跑；同时数据不一致，依赖于”数据同步模式”技术辅助实施；由于主备调度进行不一致，无法做到主备统一视图展现；若双集群硬件相当，RPO、RTO均可以维持在分钟级别；e)         ”双活模式“需要独立中间件、且严重依赖数据库自身厂商，中间件实现难度大；中间件的高可用（稳定性）成为它落地的最大障碍；“双ETL模式”的升级版，能适应各类数据仓库双集群场景；绝大部分场景下，RPO、RTO均可以接近0，特别是双活同时在线能力，不存在双集群的主备切换，RTO可以做到0；同时存在统一视图，不会因为其中一个集群故障，造成前后同一个查询返回结果不一致场景；5.       总结比对

Informatica10.2与GaussDB A8.0对接方法1. Informatica 通过插件与GaussDB对接1.1 了解 PowerExchange for GaussDB A        PowerExchange for GaussDB A是由GaussDB A 提供的可在ETL工具PowerCenter上使用的插件，可实现数据的快速导入。        本插件可以将PowerCenter处理好的数据快速导入GaussDB A 8.0数据库。主要原理是把 PowerCenter处理数据写入本地管道，通过调用gaussload工具启动GDS服务，然后将管 道数据传输至GaussDB A数据库DN端，实现了数据快速导入。        本文档主要介绍Informatica PowerCenter安装和使用。此文档适用于具备数据装载权限 的数据库管理和开发人员，且假设您已掌握以下基本知识：数据库基本理论、 GaussDB A 8.0和PowerCenter使用方法。1.2 安装 PowerExchange for GaussDB A 8.01.2.1 安装准备插件名称：        GaussDB-8.0.0-REDHAT-x86_64bit-Informatica-plugin.tar.gz        GaussDB-8.0.0-REDHAT-x86_64bit-gauss-loader.tar.gz插件位置：        FusionInsight_MPPDB_8.0.0_RHEL.tar.gz安装包中，FusionInsight_MPPDB/software/components/package/package路径下。软件环境要求：        Linux操作系统：支持SUSE Linux Enterprise Server 11 SP1/SP2, x86_64，Redhat，centos。        PowerCenter版本：10.2。 工具：必须为系统自带Python2.6版本。前提条件本地已成功安装PowerCenter server组件。PowerCenter client端已配置GaussDB A 8.0 ODBC驱动（配置方法见后面章节）。用户对<PowerCenter Installation Directory>/server/bin目录具有读写执行权限。需要提前安装gaussload工具，安装步骤如下：                步骤1：进入gaussload解压目录，执行bash install_gaussload.sh。                步骤2：配置环境变量GAUSS_LOADERS，将$GAUSS_LOADERS/bin加到PATH环境变量中，export PATH=$GAUSS_LOADERS/bin:$PATH。1.2.2安装步骤步骤1 在Informatica Server主机上，解压GaussDB-8.0.0-REDHAT-x86_64bit-Informatica-plugin.tar.gz文件，执行bash install.sh命令，提示安装成功。步骤2 打开Informatica的B/S管理端"Informatica Administrator"，使用域口令登录。        说明 该管理端的入口在Informatica Server的安装过程中会有提示。一般的URL为： http://10.119.31.38:6008，其中IP地址为Informatica Server所在IP，端口默认为6008。如果在安装 过程中使用的是自定义端口，这里请做相应修改。步骤3 找到需要配置的PowerCenter存储库服务，在属性页面找到“存储库属性”，点击修 改，如下图。          步骤4 将PowerCenter的存储库操作模式调整为“独占”模式，这将会重启存储库，请注意。步骤5 待存储库重启完成后，转到插件页面，点击添加插件图标，如下图：         步骤6 在弹出的“PowerCenter存储库服务注册插件”页面，选择步骤1中GaussDB-8.0.0-REDHAT-x86_64bit-Informatica-plugin.tar.gz解压出的插件文件 GaussDB_Kernel_Connector.xml        说明：如果之前注册过该插件，请勾选“更新现有插件注册”，并请同步更新Informatica Server的插件安装包，执行install.sh脚本，见步骤1。 步骤7 按照之前的步骤，重新将存储库服务的操作模式，调整为“普通”，重启存储库服务，完成。----结束 1.2.3 使用 PowerExchange for GaussDB A        当需要通过PowerCenter向GaussDB A 8.0导入数据时，可以利用PowerExchange for GaussDB A组件实现数据快速导入。 操作步骤步骤1 导入GaussDB A 8.0目标表。        用户可以在设计阶段从GaussDB A 8.0数据库导入目标表，PowerCenter会做数据类型转换，将原始数据类型转换为ODBC数据类型。        1、点击源或目标，选择从数据库导入，添加GaussDB A 8.0与数据库的DSN连接。                2、选择"PostgreSQL Unicode"选项，点击完成进入"PostgreSQL ANSI ODBC Driver(psqlODBC) Setup"窗口，填写用户名、密码，连接GaussDB A 8.0                 3、配置好数据源后，选择相应ODBC数据源，输入用户名、密码等信息，点击连接，空白窗口显示表信息，选择要导入的源表或目标表         步骤2  配置PowerExchange for GaussDB A 8.0连接        1、单击连接，选择关系，显示关系连接浏览器窗口                2、单击“新建”，选择PWX GaussMPP，选中确定进入连接对象定义窗口，将跳转至链接配置信息页面                3、输入连接配置信息，详细内容请参见表1-1                表 1-1 PowerExchange for GaussDB A 8.0 连接属性         步骤3  配置PowerExchange for GaussDB A 8.0会话(Session)属性。 用户可以在映射(Mapping)窗口设置Session属性，配置信息如表1-2所示                 表 1-2 PowerExchange for GaussDB A 8.0 会话(Session)属性                                ----结束 参数配置成功后，可以执行导入操作，具体使用方法参考参照《PowerCenter用户指 南》文档。 2. Informatica通过ODBC方式连接GaussMPP2.1 Informatica版本        Informatica Server版本：        2.2  配置ODBC驱动        Informatica利用ODBC方式连接GaussMPP，需要分别配置server端及client端。2.2.1 server端配置GaussMPP odbc驱动步骤1  从unixODBC官方网站下载unixODBC-2.3.0.tar.gz，解压、编译、安装；        tar zxvf unixODBC-2.3.0.tar.gz        ./configure        make && make install步骤2  从FusionInsight_MPPDB_8.0.0_RHEL.tar.gz安装包的解压文件的路径FusionInsight_MPPDB/software/components/package/package下。得到GaussDB-8.0.0-REDHAT-x86_64bit-Odbc.tar.gz驱动包，解压得到psqlodbcw.la, psqlodbcw.so两个文件；步骤3  以上package路径下解压GaussDB-8.0.0-REDHAT-x86_64bit-Libpq.tar.gz得到libpq的lib文件；步骤4  将$Informatica_intall/ODBC7.1/lib/备份为$Informatica_intall/ODBC7.1/lib.bak，重新建立$Informatica_intall/9.6.1/ODBC7.1/lib/目录，将unixODBC安装得到的/usr/local/lib/libodbc.so.1.0.0、so.1.0.0及libpq.so拷贝到$Informatica_install/ODBC7.1/lib/目录中，将步骤2解压得到的psqlodbcw.la、psqlodbcw.so拷贝到$Informatica_install/ODBC7.1/lib/目录中。(其实无需备份，直接拷贝到ODBC7.1/lib目录即可)。        将/usr/local/lib目录下的libodbc.so.2.0.0和libodbcinst.so.2.0.0拷贝到$Informatica_intall/9.6.1/ODBC7.1/lib/目录中。（/usr/local/lib目录下若没有可搜索系统中其他位置是否有）。步骤5  修改$Informatica_intall /ODBC7.1/ini文件，添加如下（按照实际填写）：        2.2.2  客户端配置GaussMPP odbc驱动步骤1  从FusionInsight_MPPDB_8.0.0_RHEL.tar.gz安装包的解压文件的路径FusionInsight_MPPDB/software/components/package/package下。得到GaussDB-8.0.0-Windows-Odbc.tar.gz驱动包，解压后安装psqlodbc.msi文件和psqlodbc_x64.msi文件，安装psqlODBC成功步骤2  配置驱动，win64位系统需配置C:\Windows\SysWOW64\odbcad32.exe文件，系统32位系统需配置C:\Windows\System32\odbcad32.exe文件，添加mppdb驱动。        点击Test测试连接是否成功。步骤3  PowerCenter 客户端工具在通过ODBC方式连接到GaussMPP数据库时，可以连接，但是出现以下两处警告，如下图所示：               消除以下两处警告；修改D:\Informatica\9.6.1\clients\PowerCenterClient\client\bin\powrmart.ini，在[ODBCDLL]中添加条目：PostgreSQL=extodbc.dll2.3  从oracle向gaussmpp中导入数据步骤1 repository manager中创建ORACLE_TO_MPP文件夹；        步骤2  在designer中创建源、目标和Mapping                  源使用oracle数据库中的bi_source的emp表        目标指定到mpp中的tmp表        需要提前在mpp中创建空白表        步骤3  workflow中指定目标emp的关系连接编辑器，连接字符串连接为gaussdb，与ini文件中名称一致；        步骤4  执行会话，结果显示成功, workflow monitor显示如图：        步骤5  确认oracle中dept表的数据        步骤6  查看MPP中tmp表的数据        步骤7  使用Informatica的测试工具，一直是等待状态，没有其他提示         补充：客户端如果与服务端不在同一机器上时，客户端(windows)需要安装msi文件，win64位系统需配置C:\Windows\SysWOW64\odbcad32.exe文件，系统32位系统需配置C:\Windows\System32\odbcad32.exe文件，添加mppdb驱动。        服务端需配置mpp odbc驱动，所需文件，其中libpq必须，不能缺少；        指定源和目标时，目标无需从数据库导入，只要从源数据创建就可以。源使用oracle数据库中的scott的dept表，目标指定到mpp中的dept表，需要提前在mpp中创建空白表。3. 遇到过的问题：1、1.2.3中步骤2中无法看到PWX GaussMPP的插件。解决方法：1.2.2中，卸载其他插件，只安装Gauss的插件后，可以在1.2.3的步骤2中看到该插件。

ETL是将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程，是构建数据仓库的重要一环，用户从数据源抽取出所需的数据，经过数据清洗，最终按照预先定义好的数据仓库模型，将数据加载到数据仓库中。目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析依据。1      ETL算法概览>  算法应用场景概览以上共计累积了8种ETL算法，其中主要分成4大类，增量累加、拉链算法是更符合数据仓库历史数据追踪的算法，但现实中基于业务及性能考虑，往往存在全删全插、增量累全算法的数据表应用。2      全删全插模型即Delete/Insert实现逻辑；>  应用场景主要应用在维表、参数表、主档表加载上，即适合源表是全量数据表，该数据表业务逻辑只需保存当前最新全量数据，不需跟踪过往历史信息。>   算法实现逻辑1.清空目标表；2.源表全量插入；>   ETL代码原型--   1. 清理目标表TRUNCATE TABLE <目标表>; --   2. 全量插入INSERT INTO <目标表>   (字段***)SELECT 字段***FROM <源表>***JOIN <关联数据>WHERE   ***;3      增量累全模型即Upsert实现逻辑；>  应用场景主要应用在参数表、主档表加载上，即源表可以是增量或全量数据表，目标表始终最新最全记录。>  算法实现逻辑1.利用PK主键比对；2.目标表和源表PK一致的变化记录，更新目标表；3.源表存在但目标表不存在，直接插入；>  ETL代码原型-- 1. 生成加工源表Create temp Table <临时表> ***;INSERT INTO <临时表> (字段***)SELECT 字段***  FROM <源表>***JOIN <关联数据>WHERE ***; -- 2. 可利用Merge Into实现累全能力，当前也可以采用分步Delete/Insert或Update/Insert操作Merge INTO <目标表> As T1 (字段***)Using <临时表> as S1on (***PK***)when Matched thenupdate set Colx = S1.Colx ***when Not Matched thenINSERT (字段***)   values (字段*** );4      增量累加模型即Append实现逻辑；>   应用场景主要应用在流水表加载上，即每日产生的流水、事件数据，追加到目标表中保留全历史数据。流水表、快照表、统计分析表等均是通过该逻辑实现。>  算法实现逻辑1.源表直接插入目标表；>  ETL代码原型--   1.插入目标表INSERT INTO <目标表>   (字段***)SELECT 字段***FROM <源表>***JOIN <关联数据>WHERE   ***;5      全历史拉链模型>  拉链表背景知识l  概念拉链表是一张至少存在PK字段、跟踪变化的字段、开链日期、闭链日期组成的数据仓库ETL数据表；l  益处根据开链、闭链日期可以快速提取对应日期有效数据；对于跟踪源系统非事件流水类表数据，拉链算法发挥越大作用，源业务系统通常每日变化数据有限，通过拉链加工可以大大降低每日打快照带来的空间开销，且不损失数据变化历史；l  示例，提取指定日期有效数据提取2020年2月5日当日有效数据Select *From  <目标表>Where 开始日期<=date'2020-02-05'And   结束日期 >date'2020-02-05';最终提取到数据：>   应用场景全历史拉链，跟踪源表全量变化历史，若源表记录不存在，则说明数据闭链；根据PK新拉一条有效记录。>  算法实现逻辑1.提取当前有效记录；2.提取当日源系统最新数据；3.根据PK字段比对当前有效记录与最新源表，更新目标表当前有效记录，进行闭链操作；4.根据全字段比对最新源表与当前有效记录，插入目标表；>  ETL代码原型-- 1. 提取当前有效记录Insert into <临时表-开链-pre> (不含开闭链字段***)Select 不含开闭链字段***From <目标表>Where 结束日期 =date'<最大日期>';;-- 2. 提取当日源系统最新数据<源表临时表-cur>-- 3 今天全部开链的数据，即包含今天全新插入、数据发生变化的记录Insert Into <临时表-增量-ins>Select 不含开闭链字段***From <源表临时表-cur>where (不含开闭链字段***) not in   (Select 不含开闭链字段***    From <临时表-开链-pre>   );-- 4 今天需要闭链的数据，即今天发生变化的记录Insert into <临时表-增量-upd>Select 不含开闭链字段***,开始时间From <临时表-开链-pre>where (不含开闭链字段***) not in   (Select 不含开闭链字段***    From <临时表-开链-cur>   );-- 5 更新闭链数据，即历史记录闭链（删除-插入替代更新）DELETE FROM <目标表>WHERE (PK***) IN(Select PK*** From <临时表-增量-upd>)AND 结束日期=date'<最大日期>';INSERT INTO <目标表>      (不含开闭链字段***,开始时间,结束日期)Select 不含开闭链字段***,开始时间,date'<数据日期>'From  <临时表-增量-upd>;-- 6 插入开链数据，即当日新增记录INSERT INTO <目标表> .      (不含开闭链字段***,开始时间,结束日期)Select 不含开闭链字段***,date'<数据日期>',date'<最大日期>'From    <临时表-增量-ins>;6      增量拉链模型>  应用场景增量拉链，目的是追踪数据增量变化历史，根据PK比对新拉一条开链数据；>  算法实现逻辑1.提取上日开链数据；2.PK相同变化记录，关闭旧记录链，开启新记录链；3.PK不同，源表存在，新增开链记录>  ETL代码原型--   1. 提取当前有效记录Insert into <临时表-开链-pre> (不含开闭链字段***)Select 不含开闭链字段***From <目标表>Where 结束日期 =date'<最大日期>';--   2. 提取当日源系统增量记录<源表临时表-cur>--   3. 提取当日源系统新增记录Insert into <临时表-增量-ins>Select 不含开闭链字段***From <临时表-开链-cur>where (***PK***) not in  (select ***PK*** from <临时表-开链-pre>);--   4. 提取当日源系统历史变化记录Insert into <临时表-增量-upd>Select 不含开闭链字段***From <临时表-开链-cur>inner join <临时表-开链-pre>on (***PK 等值***)where (***变化字段 非等值***);--   5. 更新历史变化记录，关闭历史旧链，开启新链update <目标表> AS T1SET <***变化字段 S1赋值***>,结束日期 = date'<数据日期>'FROM <临时表-增量-upd> AS S1WHERE ( <***PK 等值***> )AND   T1.结束日期 =date'<最大日期>';INSERT INTO <目标表>      (不含开闭链字段***,开始时间,结束日期)SELECT 不含开闭链字段***,date'<数据日期>',date'<最大日期>'FROM <临时表-增量-upd>;--   6. 插入全新开链数据INSERT INTO <目标表>      (不含开闭链字段***,开始时间,结束日期)SELECT 不含开闭链字段***,date'<数据日期>',date'<最大日期>'FROM <临时表-增量-ins>;7      增删拉链模型>  应用场景主要是利用业务字段跟踪增量数据中包含删除的变化历史。>  算法实现逻辑1.提取上日开链数据；2.提取源表非删除记录；3.PK相同变化记录，关闭旧记录链，开启新记录链；4.PK比对，源表存在，新增开链记录；5.提取源表删除记录；6.PK比对，旧开链记录存在，关闭旧记录链；>  ETL代码原型--   1. 清理目标表《待续...》TRUNCATE TABLE <目标表>; --   2. 全量插入INSERT INTO <目标表>   (字段***)SELECT 字段***FROM <源表>***JOIN <关联数据>WHERE   ***;8      全量增删拉链模型>  应用场景主要是利用业务字段跟踪全量数据中包含删除的变化历史。>  算法实现逻辑1.提取上日开链数据；2.提取源表非删除记录；3.PK相同变化记录，关闭旧记录链，开启新记录链；4.PK比对，源表存在，新增开链记录；5.提取源表删除记录；6.PK比对，旧开链记录存在，关闭旧记录链；7.PK比对，提取旧开链存在但源表不存在记录，关闭旧记录链；>  ETL代码原型--   1. 清理目标表，《待续...》TRUNCATE TABLE <目标表>; --   2. 全量插入INSERT INTO <目标表>   (字段***)SELECT 字段***FROM <源表>***JOIN <关联数据>WHERE   ***;9      自拉链模型>  应用场景主要将流水表数据转化成拉链表数据。>  算法实现逻辑借助源表业务日期字段，和目标表开链、闭链日期比对，首尾相接，拉出全历史拉链；>  ETL代码原型--   1. 清理目标表，《待续...》TRUNCATE TABLE <目标表>; --   2. 全量插入INSERT INTO <目标表>   (字段***)SELECT 字段***FROM <源表>***JOIN <关联数据>WHERE   ***;10  其它说明1.根据数据仓库最佳实践，所有数据表通常还会包含一些控制字段，即插入日期、更新日期、更新源头字段，这样对于数据变化敏感的数据仓库，可以进一步追踪数据变化历史；2.ETL算法本身是为了更好服务于数据加工过程，实际业务实现过程中，并不局限于传统算法，即涉及到更多适应业务的自定义的ETL算法。

GaussDB(DWS)基于postgreSQL进行的开发，在公共模式方面两者基本一致；常见的公共模式有以下三种：PUBLIC模式，Catalog模式，information_Schema模式。1、Public模式缺省时，创建的表(以及其它对象)都自动放到一个叫做"public"的模式中去了。每个新数据库都包含一个这样的模式。搜索路径中第一个存在的模式是创建新对象的缺省位置。这就是为什么缺省的对象都会创建在 public 模式里的原因。如果在其它环境中引用对象且没有模式修饰，那么系统会遍历搜索路径，直到找到一个匹配的对象。因此，在缺省的配置里，任何未修饰的访问只能引用 public 模式。public 模式没有任何特殊之处，只不过它缺省时就存在。我们也可以删除它。请注意，缺省时每个人都在public模式上有CREATE和USAGE权限。这样就允许所有可以连接到指定数据库上的用户在这里创建对象。2、Catalog模式除了public和用户创建的模式之外，每个数据库都包含一个pg_catalog模式，它包含系统表和所有内置数据类型、函数、操作符。pg_catalog总是搜索路径中的一部分。如果它没有明确出现在路径中，那么它隐含地在所有路径之前搜索。这样就保证了内置名字总是可以被搜索。自从系统表名以pg_开头开始，最好避免使用这样的名字，以保证自己将来不会和新版本冲突：那些版本也许会定义一些和你的表同名的表(在缺省搜索路径中，一个对你的表的无修饰引用将解析为系统表)。系统表将继续遵循以pg_开头的传统，因此，只要你的表不是以pg_开头，就不会和无修饰的用户表名字冲突。3、information_schema模式 Information_schema自动的存在于每个database中，里面包含了数据库中所有对象的定义信息。 Information_schema默认不存在于任何用户的search_path中，所以对所有用户都是隐藏的。\dn看不到，通过pgAdmin等客户端工具也不会自动显示。因此访问这个schema的任何视图都需要加上schema名。当然也可以通过修改search_path参数来访问。但不推荐这样做，因为里面的视图名称可能会跟用户应用程序中的对象名冲突。information_schema模式下几个重要的视图：表信息: information_schema.tables ，相当于Oracle中的all_tables字段信息： information_schema.columns，相当于Oracle中的all_tab_cloumns 权限信息：   table_privileges中记录了表权限；column_privileges中记录了列上的权限；routine_privileges上记录了function/procedure的权限role_usage_grants记录了sequence/domain等类型的对象的usage权限，跟usage_privileges类似视图信息：  Views中记录视图基础信息；view_table_usage记录视图所依赖的表；view_routine_usage记录所依赖的function；view_column_usage记录所涉及的字段 PostgreSQL有两个系统架构调用information_schema和pg_catalog，这可能会让大家感到困惑。下面是一些区别，标了一些关键字，请大家自行理解。Catalog：The system catalogs are the place where a relational database management system stores schema metadata, such as information about tables and columns, and internal bookkeeping information. PostgreSQL's system catalogs are regular tables. You can drop and recreate the tables, add columns, insert and update values, and severely mess up your system that way. Normally, one should not change the system catalogs by hand, there are always SQL commands to do that. (For example, CREATE DATABASE inserts a row into the pg_database catalog — and actually creates the database on disk.) There are some exceptions for particularly esoteric operations, such as adding index access methods.Information_schema: The information schema consists of a set of views that contain information about the objects defined in the current database. The information schema is defined in the SQL standard and can therefore be expected to be portable and remain stable — unlike the system catalogs, which are specific to PostgreSQL and are modeled after implementation concerns. The information schema views do not, however, contain information about PostgreSQL-specific features; to inquire about those you need to query the system catalogs or other PostgreSQL-specific views. 

AIX服务器通过客户端工具访问GaussDB A，可以使用下面方法：1、Aix安装gmake，下载make-4.1-2.aix6.1.ppc.rpm        ftp://ftp.software.ibm.com/aix/freeSoftware/aixtoolbox/RPMS/ppc/make/2、root执行rpm -ivh make-4.1-2.aix6.1.ppc.rpm3、下载postgresql-9.2.4源码包。        https://www.postgresql.org/ftp/source/v9.2.4/        或https://ftp.postgresql.org/pub/source/v9.2.4/4、上传postgresql-9.2.4.tar.gz到aix服务器，并解压。5、进入到解压后的目录，使用root用户执行。      ./configure      gmake      gmake install6、使用psql命令连接GaussDB数据库。

在线上，我们DWS（数据仓库服务）与ADB for MySQL有非常多的差异，将目前发现的差异总结如下，如有遗漏，欢迎大家补充。一、总体结构的差异在ADB for MySQL中，由上至下的结构是：实例-->数据库-->表   JDBC需要连接到实例上，使用库名.表名来进行表数据的增删改查等操作。由此可见，ADB for MySQL中实例对应DWS中的数据库，其数据库对应DWS中的模式（schema），同样，在ADB中可以使用库名.表名的方式进行跨库访问（类似于跨schema访问）。二、数据类型的差异ADB(MySQL)中大部分数据类型与DWS是一致的，如VARCHAR、int、bigint、decimal等，但有如下几个数据类型需要大家注意：    1.datetime与timestamp在ADB(MySQL)中datetime是没有时区的时间戳，而timestamp是带时区的时间戳，因此，在转换成DWS中的数据类型时，datetime需要转为timestamp without time zone，timestamp转为timestamp with time zone;    2.tinyintDWS与ADB中均存在tinyint这种数据类型，但是，在ADB中其范围是 -128~127，而DWS中为0~255，因此，ADB中的tinyint需要转为DWS中smallint，或int；三、常用函数的差异ADB中的日期处理函数与DWS中完全不一致，在语法改造过程中需要格外的注意。日期的加减，在ADB中有两个不同函数，分别为date_add及date_sub，DWS中可直接改为加减号，但是有一点大家要注意，ADB中INTERVAL后是可以不加单引号的，而且其数值可以是一个字段名。      如下，select DATE_ADD(NOW(),INTERVAL col1 DAY) from table1;而且，在ADB中INTERVAL 后面的小数会自动截取整数位，这点也是与DWS有很大差距的，这种语法一样但是结果不同的差异，大家一定要注意。此外，字符与日期之间的相互转化，ADB中为date_format(now(),'%Y%m%d')及str_to_date('20201127193000','%Y%m%d%H%i%s')，这里有一点需要注意，to_date这个函数在MySQL兼容模式下，其输出为日期，而不是时间戳。例如：to_date('20201127193000','yyyymmddhh24miss')，其结果为 2020-11-27，因此在做函数转化的时候，需要将str_to_date改为to_timestamp而不是to_date。    其他一些ADB特有的函数，如ifnull、if、max_pt等，都需要做相应的转换四、其他    ADB（MySQL）与DWS的差异当然不仅仅这些，这里只是简单列举了一些常见的、容易出问题的地方供大家参考，此外还有以下几点需要注意：1、ADB中联合主键中的某一个字段可以为空值。若需要从ADB中同步数据时，如果报错信息是违反非空约束，那除了字段与ADB没有对齐之外，还有一种可能就是因为联合主键中出现了空值。此时，可以将主键改为唯一索引来规避此问题。2、ADB中如果没有指定主键，会自动建一个`__adb_auto_id__` bigint AUTO_INCREMENT的自增序列作为主键，DWS中需要改成__adb_auto_id__ bigserial。在使用CDM从ADB同步数据时，该字段是无法默认出现的，需要在CDM中手工添加该字段的映射关系，或去掉该字段映射，使用DWS的默认自增序列。3、ADB中的replace into需要改为merge into，如果是调度周期比较短或者更新表数据量很大，需要重点关注，可以将merge into 改为select * from a union all select b.* from b left  join a on b.id =a.id where a.id is null（a是源表，b是目标表）4、分区ADB中可以支持overwrite一个分区的数据，而DWS不支持，因此，在进行语法改造的时候要提高警惕，不要把所有的overwrite都复制过来，需要先删除当前分区的数据，再插入新的数据。

一、安装前检查1、检测服务器主机名称主机名与业务平面IP地址保持一一映射关系，即每个主机名对应唯一一个业务平面IP地址，每个业务平面IP地址对应唯一一个主机名。执行命令:hostname2、检查硬盘分区是否符合规范OS盘需要对以下目录单独分区/  20G/tmp 10G/var 10G/var/log 130G/srv/Bigdata 60G/opt 200G其他24块硬盘以每组6个做成4组raid54组raid不挂载目录，在后续安装过程中会自行挂载ps：由于/srv/BigData/dbdata_om及/srv/BigData/LocalBackup没有单独分区，因此需要在主备管理节点，手工挂载磁盘，创建分区，具体操作步骤见下文二、配置软件包1、将安装包《GaussDB_A_8.0.0_RHEL.zip》上传到主管理节点198.203.70.206的/opt目录下在opt目录下解压安装包cd /opt$tar -zxvf GaussDB_A_8.0.0_RHEL.zip得到以下软件包：•FusionInsight_Manager_6.5.1_RHEL.tar.gz•FusionInsight_Manager_6.5.1.6_redhat.tar.gz•FusionInsight_BASE_6.5.1_RHEL.tar.gz•FusionInsight_BASE_6.5.1.6_redhat.tar.gz•GaussDB_A_8.0.0_RHEL.tar.gz•FusionInsight_SetupTool_6.5.1.6.tar.gz2、解压软件包tar -zxvf FusionInsight_Manager_6.5.1_RHEL.tar.gztar -zxvf GaussDB_A_8.0.0_RHEL.tar.gztar -zxvf FusionInsight_SetupTool_6.5.1.6.tar.gz3、copy文件到指定目录cp FusionInsight_BASE_6.5.1_RHEL.tar.gz FusionInsight_MPPDB_8.0.0_RHEL.tar.gz FusionInsight_Manager/software/packs/cp FusionInsight_Manager_6.5.1.6_redhat.tar.gz FusionInsight_BASE_6.5.1.6_redhat.tar.gz FusionInsight_Manager/software/patch/4、挂载操作系统镜像mount /home/backuofile/iso/rhel7664.iso /mnt/ -o loop5、检查OS的编码格式是否符合要求locale 检查OS的编码格式是否为“en_US.UTF-8“三、生成配置文件1、打开《配置规划工具》，启用宏2、基础配置修改集群名称：CMBC_GAUSS芯片类型：uname -p  x86_64OS类型：redhat-7.6OS镜像挂载目录：/mnt/配置套餐：MN&CN&DN集群节点数量：5输出配置文件路径：D:\gaussdb\ini3、选择服务使用默认配置即可，无需修改4、IP规划与进程部署选择206与207为主备管理节点，因此在前两行类型为MN&CN&DN中填写206及207相关信息，其他3行填写208~210的信息管理IP 199.203.76.206业务IP 198.203.70.206前两行MN&CN&DN中OMSServer、LdapServer、KrbServer均填Y，其余行不填，MPPDBServer所有行均填Y5、节点信息CPU虚拟核数：40 （ cat /proc/cpuinfo |grep "processor"|sort -u|wc -l ）内存 ：256 （free -g  ）主机逻辑磁盘数量 ：5 （parted -l 2>/dev/null | grep "Disk /dev/" | grep -iv "Disk /dev/mapper" | wc -l）最小数据盘容量 ：4500 （执行命令 parted -l 2>/dev/null | grep "Disk /dev/" | grep -iv "Disk /dev/mapper" 得出 5001G，再乘以0.9得 4500）主机名：206-gscmdn001 207-gsmcdn002 208-gsdn003 209-gsdn004 210-gsdn005（hostname）6、浮动IP浮动IP：198.203.70.65接口：bond0:web bond0:oms（ifconfig 查找与浮动IP在同一网段的网卡名称 bond0）子网掩码：255.255.255.0（ifconfig Use Iface为bond0的数据中对应的Genmask）网关：198.203.70.1（ifconfig Use Iface为bond0的数据中对应的Gateway）7、磁盘配置参照前文《一、安装前检查》中“2、检查硬盘分区是否符合规范”，查看OS盘分区，并填写至相应目录/     20/tmp  10/var  10/var/log 130/srv/Bigdata 60/opt  200元数据盘数：206与207填写1（如无多余硬盘分区，则选择0），其他3台机器选择0数据盘数：4（每台服务器配置4个dn，每个dn单独占据一块磁盘）8、集群参数配置选择默认配置即可，无需修改9、实例参数配置206、207选择1，其他服务器选择010、点击生成配置文件四、配置并检查安装环境1、进入“2.基础配置”中 输出配置文件路径：D:\gaussdb\ini，将software文件夹打包，然后通过跳板机上传到206这台服务器的/opt/ini_file目录下2、登录206服务器，进入配置文件压缩包所在目录后，解压压缩包cd /opt/ini_fileunzip software.zip3、将配置文件copy到指定目录cd /opt/ini_file/software/cp -r ./preinstall/* /opt/FusionInsight_Manager/software/preinstall//cp -r ./preinstall/* /opt/FusionInsight_SetupTool/preinstall//cp -r ./precheck /opt/FusionInsight_Manager/software/precheck//cp -r ./precheck /opt/FusionInsight_SetupTool/precheck//cp -r ./install_oms  /opt/FusionInsight_SetupTool4、执行preinstallcd /opt/FusionInsight_SetupTool./setuptool.sh preinstall注：若执行错误，可在“/tmp/fi-preinstall.log”路径下查看“preinstall”的日志文件，并进行相应处理。5、“preinstall”过程结束后，默认会自动继续进行“precheck”若precheck执行失败，可查看precheck日志/opt/FusionInsight_SetupTool/precheck/log/precheck_failed.log，并进行相应处理五、安装manager1、确认上一步preinstall及precheck执行无误，检查**.ini文件已传到主节点服务器/opt/FusionInsight_Manager/software/install_oms下2、检查ini文件是否配置正确cd /opt/FusionInsight_Manager/softwarecat install_oms/192.168.10.10.ini3、执行manager安装命令，等待安装执行完毕cd /opt/FusionInsight_Manager/software./install.sh -f /opt/FusionInsight_Manager/software/install_oms/192.168.10.10.ini注1：安装命令执行过程中，不支持通过“Ctrl+Z”将任务挂起。挂起后再恢复执行时可能会导致安装失败。注2：安装失败后，查看日志/var/log/Bigdata/controller/scriptlog/install.log and /var/log/Bigdata/controller/controller.log，定位错误原因。修改之后，在执行安装之前，需执行/opt/huawei/Bigdata/om-server/om/inst/uninstall.sh进行卸载后，再重新安装六、安装集群1、在步骤五安装完成后，会在控制台输出FIM页面地址：HTTP://****:8080/web复制该网址到谷歌浏览器2、输入初始用户名\密码 admin\Admin@123，首次登录后修改密码，然后重新登录3、登录成功后，点击创建集群按钮4、点击按钮模板安装，选择通过lld工具生成的xml文件，d:\gaussdb\ini\software\install_cluster\installTemplet.xml,点击提交5、选择root用户并输入“密码”，单击“查找”发现节点。查找后会自动跳转至“确定”页面，此时若发现配置规划数据有误，可单击“上一步”回到各配置项检查或更改参数值。6、确认配置信息，单击“提交”，在弹出的对话框中确认是否勾选“安装后启动集群”。7、单击“确定”开始安装集群。则待集群安装完成后，在弹出的对话框中确认是否启动集群。七、安装后检查1、检查集群状态登录FusionInsight Manager系统● 检查服务的状态。选择“集群 > 待操作的集群名称 > 服务”，各服务的“运行状态”为“良好”。● 检查节点状态。在FusionInsight Manager页面单击“主机”，各节点的“运行状态”为“良好”。注：● 主机名称前有标志表示该节点为主管理节点。● 主机名称前有标志表示该节点为备管理节点。2、执行健康检查● 执行集群的健康检查a. 选择“集群 > 待操作的集群名称” 。b. 选择“更多 > 健康检查”。● 执行主机健康检查a. 单击“主机”。b. 勾选待检查主机前的复选框。c. 选择“更多 > 健康检查”启动指定主机健康检查。附：安装过程中出现的部分问题及解决方案问题【一】：执行preinstall报错问题现象：执行preinstall时，有3台服务器磁盘分区成功，有2台服务器磁盘分区失败原因分析：成功的3台服务器为纯DN服务器，206及207这两台服务器是失败的，通过分析日志中的错误信息，发现是由于/srv/BigData/LocalBackup及/srv/BigData/dbdata_om没有单独分区，因此在执行preinstall过程中，需要4（DN数量）+1（OS系统盘）+1（/srv/BigData/LocalBackup及/srv/BigData/dbdata_om）共6块磁盘，而实际可用硬盘数量为5，从而导致执行失败。解决方案：在206及207两台机器中，分别手工执行挂载目录，具体操作步骤如下：1、创建磁盘挂载目录（按照规划sda~d分别对应/srv/BigData/data1~4，以daeta1为例）mkdir -p /srv/BigData/data12、将指定的磁盘分区，划分分区并执行格式化parted -s /dev/sda mklabel gptparted -s /dev/sda mkpart logic 100M 100%mkfs.xfs -f /dev/sda13、刷新操作系统分区表partprobe4、获取新分区的UUID。运行如下命令：blkid /dev/sda15、修改“/etc/fstab”，将如下语句作为新行添加到“/etc/fstab”中UUID=XXXXXXXXXXXXXXXXXXXXXXX /srv/BigData/data1 xfs defaults,noatime,nodiratime 1 06、挂载磁盘，并修改属主mount -achown 2000:wheel /srv/BigData/data17、重复执行步骤1~6，直至206及207两台服务器上data1~4均挂载成功使用df -h查看目录是否挂载成功8、主节点修改preinstall.ini配置文件，将参数“g_parted”值设为09、重新执行preinstall脚本，执行成功问题【二】：执行precheck报错问题现象：执行precheck报错，查看日志，报错信息为the real disk number 6 does not match the config file 7原因分析：与问题【一】原因一致，是由于/srv/BigData/LocalBackup及/srv/BigData/dbdata_om没有单独分区导致解决方案：修改precheck下checkNodes.Config，将/srv/BigData/LocalBackup及/srv/BigData/dbdata_om的硬盘分区信息删除，重新执行precheck脚本，执行成功问题【三】：在FIM使用模板安装集群时报错问题现象：使用模板安装集群，执行第一步校验请求参数报错，页面显示报错信息为 the hostname already exists原因分析：查看日志信息，报错信息为 Failed to verify node：gsmcdn001， the hostname already exists，怀疑可能是因为手工在/etc/hosts下添加所有机器的ip对应主机名信息导致。解决方案：1、删除所有5台服务器中/etc/hosts下所有手工添加的信息，在FIM使用模板创建集群，点击提交按钮后，显示“无效的业务IP”错误信息，修复失败2、将每台服务器下/etc/hosts中只保留本机的配置，如206服务器保留 198.203.70.206 gsmcdn001，在FIM使用模板创建集群，点击提交按钮后，执行第一步校验请求参数报错，页面显示报错信息为 the hostname already exists，修复失败3、删除所有5台服务器中/etc/hosts下所有手工添加的信息，然后执行/opt/huawei/Bigdata/om-server/om/inst/uninstall.sh卸载 Manager，重新安装安装Manager，再次使用模板创建集群，点击提交按钮后，显示“无效的业务IP”错误信息，修复失败4、删除所有5台服务器中/etc/hosts下所有手工添加的信息，然后执行/opt/huawei/Bigdata/om-server/om/inst/uninstall.sh卸载 Manager，重新执行preinstall后再重新安装安装Manager，再次使用模板创建集群，点击提交按钮后，执行第一步校验请求参数报错，页面显示报错信息为 the hostname already exists，修复失败5、将所有安装文件删除，重新解压安装包，从头重来一次（因目录已挂载成功，所有将preinstall.ini中 g_parted值设为0）,在FIM中使用模板安装集群，成功。问题【四】：安装集群后有两个告警信息问题现象：集群安装完成后，在FIM中有两个告警信息-“主要配置文件出错”，分别是在gsmcdn001及gsmcdn002中原因分析：查看日志中的报错信息为/etc/fstab中的UUID “XXXXXXXXXX”与mount的UUID XXXXXXXX不一致，猜测是由于这两台服务的目录挂载是手工执行的，可能与脚本自动挂载的不一致。查看其它3台正常服务器中的/etc/fstab文件与有告警信息的2台服务器做对比，发现有告警信息的服务器中是 UUID="XXXXXXXX"，而正常服务器中为UUID=XXXXXXXX解决方案：删除多余的双引号，再执行mount -a，然后再次执行日志中记录报出告警的shell脚本，shell脚本执行通过，无异常。再等待一段时间后，告警自动消除。

Cognos11.0.12 对接GaussDB A 8.01.       Cognos 介绍        Cognos是IBM公司研发的一款BI工具，实现了企业级的交互式数据库查询和报表生成。它不仅能够让企业的每一位员工都能够轻松自如地访问企业重要数据，有效地管理其业务，还能对企业数据进行多维分析和统计汇总，为企业管理者决策提供依据。cognos11与cognos10相比，变动较大。2.       环境准备GaussDB A已经安装完成。Cognos已经安装完成。Framework Manager已经安装完成。本文验证所用Cognos及GaussDB A的版本和操作系统信息如下：软件版本操作系统IBM cognos11.0.12Redhat6.5GaussDB A8.0.0Redhat 7.43.       使用JDBC对接cognos113.1 在Cognos 服务器端配置 GaussDB A JDBC 驱动        在Cognos服务器端配置GaussDB A的JDBC驱动后，Web端才可以通过JDBC连接GaussDB A，并将GaussDB A设置为数据源以完成对接。解压GaussDB A安装包获得JDBC驱动包 jar。                将JDBC驱动 jar 复制到Cognos的安装目录下的：<cognos install>/drivers。（与cognos10版本的配置路径有差异）。将jar 重命名为 postgresql-9.4.1202.jdbc42.jar。（cognos10版本的需改成postgresql-9.4-1201.jdbc4.jar）。重启Cognos服务使配置生效。    ----结束3.2 在Cognos Web 端将GaussDB A 配置为数据源         在Cognos Web端将GaussDB A配置为数据源后，Framework Manger可以将GaussDB A数据制作成数据包，并发布到Cognos服务端，最终由Cognos Web端的Report Studio根据已发布的数据包自定义生成报表。打开浏览器通过 http://serverIP:9300/bi访问Cognos server。例如：访问 http://189.122.105.25:9300/bi        点击左下角“管理”进入管理界面后选择“管理控制台”，跳转到新的界面，点击“配置”标签，单击右上角的（新建数据源）。        配置数据源，通过JDBC连接GaussDB A。输入名称，单击“下一步”。        类型中选择标准JDBC，单击“下一步”。        将 JDBC URL: jdbc:postgresql://<host>:<port>/<database-name> 替换为实际值。登录中的用户信息和密码使用可连接到数据库的用户帐号及密码。        说明：基于安全考虑，GaussDB A已禁止使用omm用户进行远程连接。故需要使用自行创建的用户，例如 “test_user”。配置结束后单击“测试连接”。        单击“测试”，查看能否成功连接数据源。        如下表示数据源连接成功。        保存数据源配置生成数据源。            ----结束3.3 测试报表是否可直连数据库随便找一张报表，点击编辑报表。        点击左侧工具栏“查询”-“查询”，然后再点击左侧工具栏“工具箱”（锤子图标）。                拖动查询下面的“sql”图标到右侧，然后点击右上角“显示属性”。        点击“数据源”，选择前面配置的数据源JDBC_TO_GaussDB，点击确定。        点击右侧“sql”后面的…按钮，打开sql窗口。输入查询语句，点击验证。        验证通过。        如果第6步报以下错误，可以从pg官网下载postgresql-9.4.1202.jdbc42.jar驱动，按照上面的方法重新配置。                        4.       使用ODBC对接cognos11        以下操作在cognos服务器上操作。4.1 准备并安装驱动网上下载以下软件源码包：名称网址附件postgresql-9.2.4.tarhttps://www.postgresql.org/ftp/source/v9.2.4/       https://ftp.postgresql.org/pub/source/v9.2.4/20M左右，可从官网下载。该包的作用是，odbc可能会用到pg的一些lib库文件。unixODBC-2.3.0.tar.gzftp://ftp.unixodbc.org/pub/unixODBCpsqlodbc-12.00.0000.tar.gzhttps://www.postgresql.org/ftp/odbc/versions/src/ 依次解压并编译安装（需要编译为32位的）        注意：如果原来系统里面已经安装过上面三个软件需要先卸载后再安装。         #postgresql        ./configure  CFLAGS="-m32"  --without-readline --without-zlib --prefix=/usr/local/pgsql/        make        make install        #unixODBC         ./configure  CFLAGS="-m32"  --prefix=/usr/local/unixodbc/        make        make install        #pgsqlodbc        ./configure  CFLAGS="-m32"  --prefix=/usr/local/psqlodbc/ --with-unixodbc=/usr/local/unixodbc/ --with-libpq=/usr/local/pgsql/         使用odbcinst –j 进行测试 ，确定使用的是新安装的unixodbc ，如果不是，需要设置PATH         配置DSN        修改 vi $ODBCINI ,添加 如下内容       [TRCBDB]       Driver=/usr/local/psqlodbc/lib/psqlodbcw.so       Servername=10.16.87.113       Port=25308       Database=trcbdb       Username=etl_usr       Password=etl_usr@123       Sslmode=allow 测试连接       [root@cognos02 analytics]# isql -v TRCBDB       +---------------------------------------+       | Connected!                            |       |                                       |       | sql-statement                         |       | help [tablename]                      |       | quit                                  |       |                                       |       +---------------------------------------+       SQL>         重启cognos        [root@cognos02 bin64]# pwd        /cognos/analytics/bin64        [root@cognos02 bin64]# ./shutdown.sh        JAVA_HOME is /cognos/jdk1.8.0_171        JRE_HOME is        JAVA_CMD is /cognos/jdk1.8.0_171/bin/java        正在停止服务器 cognosserver。        服务器 cognosserver 已停止。        [root@cognos02 bin64]# ./startup.sh        JAVA_HOME is /cognos/jdk1.8.0_171        JRE_HOME is        JAVA_CMD is /cognos/jdk1.8.0_171/bin/java        COGNOS_INSTALL_DIR is /cognos/analytics        LD_LIBRARY_PATH is set to /cognos/analytics/bin64:.::/usr/local/nz/lib:/lib64/:/usr/local/lib/:/usr/local/pgsql/lib/:/usr/local/psqlodbc/lib:/usr/local/nz/lib:/lib64/:/usr/local/lib/:/usr/local/pgsql/lib/:/usr/local/psqlodbc/lib        正在启动服务器 cognosserver。        服务器 cognosserver 已启动，进程标识为 128015。 4.2 在cognos 服务端配置odbc 连接登录cognos服务端，如：http://10.16.86.35:9300/bi/ 输入用户密码        进入管理控制台，新建数据源GaussDBODBC。                        填写ini中配置的数据源TRCBDB        点击测试链接，成功。         4.3 测试报表是否可直连数据库随便找一张报表，点击编辑报表。        点击左侧工具栏“查询”-“查询”，然后再点击左侧工具栏“工具箱”（锤子图标）。                拖动查询下面的“sql”图标到右侧，然后点击右上角“显示属性”。        点击“数据源”，选择前面配置的数据源GaussDBODBC，点击确定。        点击右侧“sql”后面的…按钮，打开sql窗口。输入查询语句，点击验证。        验证成功。        5.       GaussDB A 8.0.0对接cognos11遇到的问题5.1 问题描述1、对接cognos10版本时，客户的cognos10安装在windows server服务器上，使用GaussDB A 8.0.0安装包中的odbc和jdbc驱动，按照GaussDB A 8.0.0产品文档的操作配置odbc和jdbc后可以正常对接cognos10。2、对接cognos11版本时，客户的cognos11安装在linux系统上（5），使用GaussDB A 8.0.0安装包中的jdbc驱动，按照congnos10版本的配置方法配置后，数据源可以正常配置。但在cognos工具直连数据库取数据时报错。报错信息如下：                3、对接cognos11版本时，客户的cognos11安装在linux系统上（5），使用GaussDB A 8.0.0安装包中的odbc驱动，按照GaussDB A 8.0.0产品文档的操作配置odbc后，在linux系统后台执行isql -v TRCBDB可正常连接到集群，但在cognos11配置odbc数据源后会报下图中的错。        5.2  解决方案        针对5.1中2和3的问题，最终发现是驱动使用的问题。官网原文如下：Before making the datasource connection in IBM Cognos Administration you will need to make sure that you have installed the 32bit PostgreSQL ODBC driver。Once this is complete you will need to download the necessary JDBC driver file(postgresql-9.4.1202.jdbc42.jar) from the PostgreSQL Site then copy that to the <cognos install>/drivers directory.详细内容见后面网址或图片。ODBC解决方法        cognos11要求odbc是32位的驱动，并且要使用32位的unixodbc，GaussDB A 8.0.0暂无linux下的32位驱动，都是64位的。下载psqlodbc、unixODBC、postgresql源码包，编译安装。详细过程见第4章使用ODBC对接cognos11。JDBC解决方法        cognos11中对pg的jdbc要求的版本与cognos10要求的不一样，cognos11要求postgresql-9.4.1202.jdbc42.jar，cognos10要求postgresql-9.4-1201.jdbc4.jar。可以下载官方要求的jdbc驱动版本或者按照第3章使用jdbc对接cognos11中的方法把GaussDBA的jdbc驱动名称改名为要求的名字。附：官方驱动安装说明，链接中网页最下面有对应驱动的下载地址。https://www.ibm.com/support/pages/node/302939    （cognos11）https://www.ibm.com/support/pages/node/530621    （cognos10）