IBM Cognos 8 关于 Teradata 的技巧和技术-数据仓库-火龙果软件工程

捐助

IBM Cognos 8 关于 Teradata 的技巧和技术

作者：Cognos Proven Practices Team 来源：IBM 发布于： 2015-04-08

3300 次浏览

文档性质：技巧或技术；产品；IBM Cognos 8，第三方；关注领域：基础架构

在使用 Teradata 作为数据源来部署 IBM Cognos 8 时的一些技巧和技术。

简介

概述

本文提供了一些在使用 Teradata 作为数据源来部署 IBM Cognos 8 时的技巧和技术。

文中提供的技巧和技术可作为 “帮助” 工具；因此，这些内容可作为意见或建议。每个客户站点都不相同；因此，其中有些提示或技术可能不适用。

以下所描述的技巧和技术是从不同客户站点所获得经验的积累。

本文还可作为 “在建项目”。随时会有新的技巧和技术增加，以下所列的技巧和技术可能随时都会修改，恕不另行通知。

文档先决条件

本文假定读者具有 Teradata、SQL、数据库的相关实践经验，并对 IBM Cognos 8 有深入了解。本文还假定读者精通 IBM Cognos 8 实施的相关知识，以及丰富的建模经验。

强烈建议用户熟悉参考资料部分中所列出的相关项目。

文档范围

本文适合以下软件版本：

1.IBM Cognos 8.2 BI、IBM Cognos 8.3 BI

2.Teradata EDW V2R6.2

IBM Cognos 可在多个层次与 Teradata 集成。本文分为不同层次的集成，以及相应的技巧和技术。

本文基于 Teradata Star/Snowflake 物理表模式。

Teradata 部署

配置文件数据并识别主索引（Primary Index，PI）候选者

在设计 Teradata 主索引时典型的错误是仅仅合并列来在 Teradata AMPs 中均匀地分布数据。虽然数据的分布是许多设计标准之一，但关注的业务问题重点是由业务构成的。主索引是 Teradata 数据库的惟一特性 – 在避免索引相关额外开销的情况下提供索引的优势。

有两种主索引 – 惟一主索引（UPI）与非惟一主索引（NUPI）。如果表中存在构成公共访问路径的列（例如，利用最常用列查询来从表中检索数据），那么，它可以作为主索引候选者。如果它是惟一的，那么它将成为 UPI 的候选者；否则它将成为 NUPI 的候选者。

任何利用主索引列的查询将会遭遇更快速响应时间问题。

为定义高质量的主索引，需要数据剖析（有时称为数据分析）。以下查询可用来根据数据访问为某个表选择一个 PI，并跨不同 AMP 提供相应数据分布：

select hashamp(hashbucket(hashrow(<column that you evaluating for use as PI>))), 
count(*)
from <Table Name for which the PI is being evaluated>
group by 1

利用 Teradata 数据库统计数据

不管哪种模式（3NF 或 Star），Teradata 查询优化器依赖于统计信息帮助确定最佳数据访问路径。统计信息还可帮助优化器确定表中有多少行正被查询，以及预测有多少行符合给定的条件。

在尝试提高特定报告性能时，有一个简单的方法可以确定需要收集哪些统计数据。

首先，使用 Teradata SQL Assistant 连接到数据源。

执行语句来为会话其余部分打开诊断 helpstats （“诊断 helpstats 用于会话”）。

接下来，从 IBM Cognos Report Studio 中复制报告的原始 Teradata SQL。

将 SQL 粘贴到 Teradata SQL Assistant's Query 框架中。

按下 F6 键来执行 Explain。

“High Confidence” 结果指明，对于收集统计信息列是较好的候选者。

在过滤器与提示信息中利用分区和主索引。

编写报告时，要尽可能确保利用具有索引的列。如果数据库设计者已在表上创建了主分区索引，那么查询应当与分区列结合。当连接执行时，合并选中的索引，此时维度表中的任何列都可使用。优化器将根据行中列的函数依赖性来推断关键值选择。

当在 Report Studio 中定义提示信息时，可以采用两种不同的性能优势：“Use Value” 与 “Display Value”。例如，将 Sales Org Code 指定为 “Use Value” 并将 Sales Org Description 指定为 “Display Value”。

可通过传递一个文本值或者连接来实现分区消除。

利用 Teradata Soft Referential Integrity (Soft RI)

表之间的关系提供了 Teradata 数据库优化器的输入值。这些关系通过创建表之间的约束关系来确定。数据仓库中的数据量使得传统引用完整性约束的成本太高。因此，Teradata 通过向约束增加 “WITH NO CHECK OPTION” 短语，创建了 Referential Constraints，通常被称为 “Soft RI” 。该特性定义了哪一边是主实体（驱动器），哪个实体是子实体，并增强了数据访问计划。Soft RI 结合统计数据使得优化器能够生成更有效的访问路径。

以下是在实施 Soft RI 时需要考虑的问题：

确保主键（有些情况下可能称为主索引）上的列在 driving 表/维度中的定义是惟一的。非惟一列不能为不同表提供外键引用。

确保 driving 表中的主键与 target 表中的外键具有相同的数据类型。两个表中的关键列不能被压缩。

创建 Soft RI 的语句如下：

ALTER TABLE <Target Table> 
FOREIGN KEY (<The column which references a Primary Key Column in a Driving Table>) 
REFERENCES WITH NO CHECK OPTION <Driving Table> (<Primary Key Column>);

启用 Soft RI 后，确保得到了约束中所有列的适当统计数据。

见 Teradata Database Administration 手册中 “Using Referential Integrity” 部分。

Teradata 建模

在物理数据模型中避免外部连接

外部连接可能会对查询性能产生负面影响。这一建议还适用于连接超大表的 3NF 与 Star 架构，并不是 Teradata 专用。

可通过用针对外键的默认值来填充 fact 表，来将外部连接转换为内部连接。该性能增强变更不需要重组物理数据模型就可以实现。

ODBC 配置

Teradata 将其 ODBC 驱动器作为首选联系方法。后续内容中提供了该 ODBC 驱动器的几个选项。

存储用户凭据

如果用户想要仅利用一个 TD 用户账户作为代理用户，那么用户凭据将存储于 ODBC 驱动器级别，而不是 IBM Cognos 8 Connection 级别。

在 Windows 中，填写 “Username” 与 “Password” 字段：

在 UNIX 中，填写在 “.odbc.ini” 文件中的 “Username=” 与 “Password=” 字段。比如：

[ODBC]
InstallDir=/usr/odbc
Trace=0
TraceDll=/usr/odbc/lib/odbctrac.so
TraceFile=/usr/odbcusr/joe/trace.log
TraceAutoStop=1
[ODBC Data Sources]
financial=tdata.so 
[financial]
Driver=/usr/odbc/drivers/tdata.so
Description=NCR 3600 running Teradata V2R5.1
DBCName=123.45.67.10
DBCName2=123.45.67.11
DBCName3=123.45.67.12
Username=odbcadm
Password=password
Database=
DefaultDatabase=sales

在利用该技术时，建议在 IBM Cognos Administration 中创建数据源时不要选择 “User ID” 选项。

use X Views

TD ODBC 驱动器提供几个选项。

强烈建议取消选定 “Use X Views” 选项。该选项将会延长 IBM Cognos 应用程序不采用的，在对象上的 Metadata 调用的时间。

在 Windows 中，在 Teradata ODBC 驱动选项中取消选定该选项。

在 UNIX 中，确保在 “.odbc.ini” 文件中不存在 “UseXViews=” 选项。如果文件中有该选项，那么要确保设置为 “No”。例如：

[ODBC]
InstallDir=/usr/odbc
Trace=0
TraceDll=/usr/odbc/lib/odbctrac.so
TraceFile=/usr/odbcusr/joe/trace.log
TraceAutoStop=1
[ODBC Data Sources]
financial=tdata.so 
[financial]
Driver=/usr/odbc/drivers/tdata.so
Description=NCR 3600 running Teradata V2R5.1
DBCName=123.45.67.10
DBCName2=123.45.67.11
DBCName3=123.45.67.12
Username=odbcadm
Password=password
Database=
DefaultDatabase=sales
UseXViews=No

No HELP DATABASE

可启用 “No HELP DATABASE” 选项。当将多个逻辑数据库查询发送给 Teradata 时，这很有用。与 IBM Cognos 8 强制执行中间层中的连接不同，Teradata 不会完成所有的处理流程。

在 Windows 中，选定 “No HELP DATABASE” 选项。

在 UNIX 中，确保 “.odbc.ini” 文件中的 “DontUseHelpDatabase=” 设置为 “Yes”。例如：

[ODBC]
InstallDir=/usr/odbc
Trace=0
TraceDll=/usr/odbc/lib/odbctrac.so
TraceFile=/usr/odbcusr/joe/trace.log
TraceAutoStop=1
[ODBC Data Sources]
financial=tdata.so 
[financial]
Driver=/usr/odbc/drivers/tdata.so
Description=NCR 3600 running Teradata V2R5.1
DBCName=123.45.67.10
DBCName2=123.45.67.11
DBCName3=123.45.67.12
Username=odbcadm
Password=password
Database=
DefaultDatabase=sales
DontUseHelpDatabase=Yes

ODBC 高级选项

TD ODBC 还提供高级选项。

在高级选项中，可对 “Maximum Response Buffer Size” 进行调整。默认值是 8192。允许的最大值是 1048575。不推荐特定的值。每个客户站点需要不同的值。如果该值太大，那将会影响元数据调用。采用较小的值时不会产生副作用。

在生产环境中采用该选项之前应当对其进行全面测试。

在 Windows 中，将该值填入 “Maximum Response Buffer Size:” 选项中。

在 UNIX 中，在 “MaxRespSize=” 选项中采用所需的值。例如：

[ODBC]
InstallDir=/usr/odbc
Trace=0
TraceDll=/usr/odbc/lib/odbctrac.so
TraceFile=/usr/odbcusr/joe/trace.log
TraceAutoStop=1
[ODBC Data Sources]
financial=tdata.so 
[financial]
Driver=/usr/odbc/drivers/tdata.so
Description=NCR 3600 running Teradata V2R5.1
DBCName=123.45.67.10
DBCName2=123.45.67.11
DBCName3=123.45.67.12
Username=odbcadm
Password=password
Database=
DefaultDatabase=sales
MaxRespSize=65477

如果改变了该选项后，当向模型中导入对象时，FM 发出错误消息，那么需要降低 “Maximum Response Buffer Size” 值。还需要对报告的运行进行多次测试。在开始下一个报告之前，要对当前报告进行多次测试。

Custom Catalog Mode

需要注意，当启用 “Enable Custom Catalog Mode for 2.x Applications” 后，性能有了一些提高。

在应用到生产环境之前，要对其进行全面测试。

在 Windows 中，启用 “Enable Custom Catalog Mode for 2.x application” 选项。

在 UNIX 中，启用 “USE2XAPPCUSTOMCATALOGMODE=” 选项。例如：

[ODBC]
InstallDir=/usr/odbc
Trace=0
TraceDll=/usr/odbc/lib/odbctrac.so
TraceFile=/usr/odbcusr/joe/trace.log
TraceAutoStop=1
[ODBC Data Sources]
financial=tdata.so 
[financial]
Driver=/usr/odbc/drivers/tdata.so
Description=NCR 3600 running Teradata V2R5.1
DBCName=123.45.67.10
DBCName2=123.45.67.11
DBCName3=123.45.67.12
Username=odbcadm
Password=password
Database=
DefaultDatabase=sales
USE2XAPPCUSTOMCATALOGMODE=Yes

IBM Cognos 连接

当创建 IBM Cognos 8 数据源连接时，使用 “Teradata (ODBC)” 而不是 “ODBC” 选项。

IBM Cognos 建模

针对 Teradata 的 IBM Cognos 8 元数据建模是 IBM Cognos 8 实施当中最重要的任务。

需要接受一些在 Framework Manager 中建模相关技术的培训，才能成功地实施，并需要充分利用 IBM developerWorks 站点中 IBM Cognos Modeling Proven Practices 文档。

Teradata 最佳实践建议直接连接到 Teradata Business Views Layer（也称为 Semantic Views Layer），而不是 Teradata Physical Tables。IBM Cognos 8 将能够连接到任何一层，但，建议遵循 Teradata 最佳实践。

Teradata Business Views 应当避免表上的 READ Locks：

Create/Replace view {view name} as Locking Row for Access Select * From {table name}

本地缓存

IBM Cognos Framework Manager 能提供对信息本地缓存的再利用，而不需要每次都访问 Teradata。建议启用该选项，除非是针对 Teradata Active Data Warehouse。为此，在 Project 菜单下，选择 Edit Governors，然后选择 Allow usage of local cache。

SQL 连接语法

SQL 连接语法可能会对性能产生影响。要注意，可使用 Explicit Joins vs. Implicit Joins 获得更优性能。

要确保采用了所需的 SQL 连接语法，可启用 project Governors 对话框中的选项。

WITH 子句

当关闭 “Use WITH clause when generating SQL” 选项后，性能会有一些提高。

Like Data Types 上的连接

通过在将 fact 表中的外键与 dimension 表中的主键进行连接时采用 like 数据类型（例如 INT32 to INT32），可提高查询性能。通过在 DDL 中确保数据类型一致，在查询运行当中与数据转换相关的开销会比较小。

创建 Durable Models

想要最小化基础数据源变更的影响，IBM Cognos 建议利用分层方法来在 IBM Cognos Framework Manager 中进行模型设计。关于如何对其进行实施的信息，请参见名为 “IBM Cognos 8 Framework Manager - Durable Models” 的 IBM Cognos Proven Practice 文档。

避免附加元数据调用

强烈建议最小化对 Teradata 的元数据调用。要达到这一目的，需要尽量保持数据库/物理层的简洁。对该层的变更将会导致附加元数据调用，包括在元数据查询对象定义 SQL 选项卡中修改示例 select 语句，以及增加计算器或过滤器。这些类型的活动会出现在更高层的建模中，比如在模型查询对象所组成的元数据 Business View 中，而不是数据源查询对象。

要确定数据库/物理查询对象是否正发起元数据调用，可查看 Query Test 的 “Response”。

示例查询测试正在进行元数据调用：

未发起元数据调用的 Query Test 示例：

想要避免对底层数据源的元数据回调，推荐的方法是创建一组专用查询对象，来避免缓存元数据。为此，需要创建 Framework Manager 名称空间，其中导入的所有表和视图都保持不变。这些保持不变的数据源查询对象可被模型中的其他查询对象、计算器、以及过滤器所引用。

Report Studio 的使用

当采用 Report Studio 来创建高度格式化的报告时，可考虑采用几个高级选项。

Processing

Processing 应当尽量设置为 “Database only”。尽量避免 “Limited Local”。如果需要设置 “Limited Local”，那么需要重新访问 Framework Manager 模型，来查看是否存在将 processing 传递给 Teradata 的方法。

Query Joins、Unions、Intersections 与 Excepts

IBM Cognos 8 为报告开发人员提供了将其分析合并到多个查询中的功能。这非常有用；然而，当大多数（如果不是全部）报告需要大量在报告级别连接的查询时，建议重新访问 Teradata 中的数据库架构，来更好地利用 Teradata 数据库的处理能力。

执行方法

IBM Cognos 8 能够并发地或顺序地运行多个报告。默认情况下，IBM Cognos 8 将会运行顺序查询。报告开发人员能够变更执行方法来进行并发查询。

注意：将选项转换为 Concurrent 并不意味着报告将会运行得更快。有理由相信，当顺序运行时，报告将会提供更好的性能。在将其部署到生产环境中之前，必须对其进行全面测试。

测试与疑难解答

建议在测试和/或疑难解答中，采用非 IBM Cognos 数据。例如，如果 Query Subject 出现错误，那么可在这些工具中对 SQL 语句进行复制与粘贴，来验证 SQL 语句。

可用的工具包括：

在 Windows 中，Teradata SQL Assistant

在 UNIX 中，Adhoc.c 示例应用程序

两个工具都会通过 ODBC 连接到 Teradata，这会针对 ODBC 驱动器来再次验证 SQL 语句。

结束语

IBM Cognos 与 Teradata 为客户提供了非常有效的 BI/EDW 解决方案。以上所列出的技巧和技术是对不同客户站点综合考察的结果。强烈建议对以上所列的每个技巧和技术进行全面的测试，确保实现您特定站点的最优性能。

3300 次浏览