45、数据仓库搜索与测试全解析

数据仓库搜索与测试全解析

1. 数据仓库中的搜索功能

当数据仓库规模增长到数TB,并且存储了数百个报告、多维数据集和众多商业智能(BI)数据模型时,搜索功能就显得尤为重要。搜索工具可以对数据仓库报告、分析或数据模型(包括元数据和内容)进行索引,使用户能够通过在搜索文本框中输入搜索条件来查找信息,还能根据相关性对搜索结果进行排序。

一些供应商,如SAS,会搜索元数据服务器中的业务视图和数据结构,以关联搜索结果中的相关信息;像Information Builder这样的供应商会搜索企业数据库中的结构化数据;而Clarabridge等供应商还会搜索非结构化数据以及结构化报告。

一个典型的搜索应用程序由索引器、检索器和评分程序组成:
- 索引器 :浏览所有文件类型的文件夹,打开并爬取每个文件,将这些单词的位置存储在存储库中,同时收集有关报告、多维数据集和数据模型的信息,并存储先前的搜索和查询。
- 检索器 :从搜索文本框接受一个值,搜索其存储库和元数据,并将结果显示给最终用户。
- 评分程序 :在将结果显示给最终用户之前,根据预设的逻辑/算法对结果进行排序,还可以将结果划分为多个部分,以便在屏幕上分别显示。

在搜索文本框中,用户可以输入“sales”,搜索工具会列出相关的销售报告、BI模型和Analysis Services多维数据集。搜索会遍历报告元数据、多维元数据、数据仓库元数据和BI数据模型元数据,以查找相关的报告、多维数据集和模型,还可以搜索存储报告的内容和先前的搜索记录。

目前,几乎每个BI供应商都在与Google合作推出搜索产品。由于BI或数据仓库搜索是一个相当专业的领域,开发一个按相关性对搜索结果进行排序的排名算法并非易事,而且很难保证自己开发的算法比Google搜索算法更好。因此,将报告内容、列标题、数据值等的搜索工作交给与BI供应商合作的搜索专业公司是更好的选择。

数据仓库中有三个领域可以从搜索功能中受益:
| 受益领域 | 说明 |
| ---- | ---- |
| 简化用户界面 | 搜索用于查询维度数据存储中的结构化数据,用户可以在一个简单的文本框中输入任何内容,应用程序会搜索数据仓库中的相关内容。例如,用户可以输入“October 2007 sales in Midwest region”,而不必输入复杂的SQL查询。 |
| 报告搜索 | 帮助用户快速找到所需的报告。 |
| 非结构化数据搜索 | 可以对文档、网页、文本文件、图像、视频和音频文件等非结构化数据进行浏览和索引,方便查找信息。 |

下面是一个典型的数据仓库查询示例,用于了解每个商店的销售金额:

select s.store, sum(f.sale_amount)
from fact_purchase f
join dim_date d on f.date_key = d.dim_key
join dim_store s on s.store_key = d.store_key
where d.month = 10
and d.year = 2007
and s.region = 'Midwest'
group by s.store

而使用搜索功能时,用户只需输入“October 2007 sales in Midwest region”或“Sales”,搜索应用程序就会显示相关的销售报告。

2. 数据仓库的测试

与其他IT系统一样,构建数据仓库及其ETL和应用程序后,需要进行全面测试,主要包括以下六种类型的测试:
| 测试类型 | 目的 |
| ---- | ---- |
| ETL测试 | 确保源系统中的数据更新被正确捕获并传播到数据仓库,数据正确加载到数据仓库,增量ETL按设计工作,批量加载脚本正确加载数据。 |
| 功能测试 | 确保满足所有业务需求。 |
| 性能测试 | 验证数据仓库能够处理所需的负载和容量。 |
| 安全测试 | 确保只有有权限的用户能够访问资源。 |
| 用户验收测试 | 让最终用户使用数据仓库系统,验证其可用性。 |
| 端到端测试 | 让系统运行几天,模拟生产环境。 |

下面详细介绍ETL测试和功能测试:

2.1 ETL测试

ETL测试至关重要,因为ETL负责将数据从源系统引入数据仓库。如果ETL出现错误,数据仓库中的数据也会出错,从而影响数据仓库的使用。数据仓库系统主要由ETL、数据存储和应用程序三个主要组件组成,其中ETL开发通常占据数据仓库开发工作的大部分。

ETL测试的主要目标包括:
- 确保获取所需的所有数据,不遗漏源系统中的数据更新。
- 确保数据正确加载到数据仓库,包括正确的表、列、格式和时间。
- 确保增量ETL按设计工作,无论采用批量架构、推送架构还是面向服务的架构。
- 确保批量加载脚本(如果有)正确加载数据到数据仓库。

进行ETL测试的步骤如下:
1. 从ETL架构图和ETL流程开始,测试整体ETL流程和各个ETL任务是否将数据正确交付到数据存储。例如,有一个包含30个任务的每日批处理、一个包含3个任务的每周批处理和一个包含2个任务的每小时批处理,分别运行这些批处理,确保任务按正确顺序执行。
2. 检查目标数据,与源系统进行比较。
3. 如果有“推送方法”或基于SOA的ETL,开启它们并在源系统中进行一些事务,确保更改被正确捕获并传播到数据仓库,同时测试是否存在“数据泄漏”。
4. 测试可恢复性,列出可能的事件类型(如停电、磁盘故障)和ETL系统中可能发生故障的流程类型(如提取过程、DDS填充过程、立方体构建过程),模拟这些事件和流程类型的组合,重新运行ETL流程,检查是否可以正常继续且无数据丢失。
5. 对于采用涓流馈送的SOA架构,模拟消息队列(MQ)故障或网络故障,确保消息能正确重发。
6. 如果ETL中构建了通知或警报功能,测试在特定事件发生时是否能通知到正确的人员。
7. 测试增量ETL是否能够进行初始批量数据加载,如果预计执行时间超出可容忍范围,则需要开发单独的批量加载架构,并验证批量加载脚本是否能将初始数据完整正确地加载到目标表中,同时确保在截止日期前后不遗漏任何数据。

mermaid流程图如下:

graph LR
    A[开始ETL测试] --> B[运行每日批处理]
    B --> C[检查任务顺序]
    C --> D[检查目标数据与源系统比较]
    D --> E{是否有推送或SOA - ETL}
    E -- 是 --> F[开启并测试数据传播]
    E -- 否 --> G{是否测试可恢复性}
    F --> G
    G -- 是 --> H[模拟故障并测试恢复]
    G -- 否 --> I{是否为SOA涓流馈送}
    H --> I
    I -- 是 --> J[模拟MQ或网络故障]
    I -- 否 --> K{是否有通知功能}
    J --> K
    K -- 是 --> L[测试通知功能]
    K -- 否 --> M{是否测试批量加载}
    L --> M
    M -- 是 --> N[测试批量加载脚本]
    M -- 否 --> O[结束测试]
    N --> O
2.2 功能测试

功能测试的目的是确保数据仓库满足所有业务需求。业务需求在数据仓库项目开始时确定,驱动设计和开发。以Amadeus Entertainment Group案例研究为例,业务需求包括分析订阅销售情况、在商店层面查看每日数据等。

在功能测试中,需要测试所有在项目开始时定义的业务需求,例如分析每个月按商店和销售区域划分的订阅销售成本,将数据仓库中的数字与源系统进行比较,确保两者匹配。由于无法检查每个数字,一种测试技术是先验证总数,然后向下钻取一级(验证所有成员),最后通过选择n个成员向下钻取到最底层。

在选择成员时,应基于边界值,如最小和最大值、最新和最旧的产品代码等。同时,还需要验证所有级别上维度成员的数量,确保数据仓库与源系统一致。

功能测试不仅要计算总数和比较计数,还需要测试以下方面:
- 缓慢变化维度(类型1、2或3)。
- 代理键是否正确链接事实表和维度。
- ODS中的引用完整性。
- 日期维度的所有属性是否正确。
- 维度层次结构是否正确。
- 所有客户属性是否正确集成。
- 所有事实表中的退化维度。
- 所有控制列是否正常工作。
- 所有数据质量过滤器是否正常工作。
- 所有七种类型的元数据是否正确填充。

进行功能测试时,首先确定要测试的业务事件,在源系统的测试环境中准备测试数据以模拟该事件,运行ETL流程将模拟数据引入数据仓库,然后将数据仓库中的数据与源系统进行比较。常见的业务事件包括分支机构关闭、价格上涨、月末或年末处理、新财政日历开始等。

以下是一个功能测试的步骤列表:
1. 确定业务需求。
2. 制定测试计划,包括测试用例和测试数据。
3. 执行测试,按照验证总数、向下钻取一级、向下钻取到最底层的步骤进行。
4. 比较数据仓库和源系统的数据。
5. 检查维度成员数量。
6. 测试其他相关方面(如缓慢变化维度、代理键等)。
7. 记录测试结果,如有问题及时反馈给开发团队。

mermaid流程图如下:

graph LR
    A[开始功能测试] --> B[确定业务需求]
    B --> C[制定测试计划]
    C --> D[准备测试数据]
    D --> E[运行ETL流程]
    E --> F[验证总数]
    F --> G[向下钻取一级]
    G --> H[向下钻取到最底层]
    H --> I[比较数据仓库和源系统]
    I --> J[检查维度成员数量]
    J --> K[测试其他相关方面]
    K --> L[记录测试结果]
    L --> M{是否有问题}
    M -- 是 --> N[反馈给开发团队]
    M -- 否 --> O[结束测试]
    N --> C
3. 性能测试

性能测试的核心目的是验证数据仓库是否能够承受所需的负载和数据量。在实际的业务场景中,数据仓库可能会面临大量用户同时访问、复杂查询频繁执行等情况,如果性能不佳,将会严重影响用户的使用体验和业务决策的效率。

进行性能测试可以按照以下步骤进行:
1. 确定测试场景 :根据实际业务需求,模拟不同的使用场景,例如高峰时段大量用户同时查询数据、执行复杂的数据分析任务等。
2. 设置测试环境 :确保测试环境与生产环境尽可能相似,包括硬件配置、软件版本、数据量等。
3. 执行测试用例 :使用专业的性能测试工具,如LoadRunner、JMeter等,按照预设的测试场景执行测试用例。在测试过程中,记录系统的响应时间、吞吐量、资源利用率等关键指标。
4. 分析测试结果 :根据记录的指标,分析数据仓库在不同场景下的性能表现。如果发现性能瓶颈,如响应时间过长、吞吐量过低等,需要进一步分析原因,可能是硬件资源不足、查询语句优化不够、数据存储结构不合理等。
5. 优化和调整 :根据分析结果,对数据仓库进行相应的优化和调整。例如,增加硬件资源、优化查询语句、调整数据存储结构等。然后再次进行测试,直到满足性能要求为止。

测试指标 说明
响应时间 用户发起请求到系统返回结果的时间,是衡量用户体验的重要指标。
吞吐量 系统在单位时间内处理的请求数量,反映了系统的处理能力。
资源利用率 包括CPU、内存、磁盘I/O等资源的使用情况,过高的资源利用率可能导致系统性能下降。
4. 安全测试

安全测试的主要任务是保证只有经过授权的用户才能够访问数据仓库中的资源。数据仓库通常包含大量的敏感业务数据,如客户信息、财务数据等,如果安全措施不到位,可能会导致数据泄露、数据篡改等严重后果。

安全测试可以从以下几个方面进行:
1. 用户认证 :验证用户登录数据仓库系统时的身份认证机制是否有效,例如用户名和密码的验证、多因素认证等。
2. 访问控制 :检查系统是否根据用户的角色和权限,对不同的数据资源进行了合理的访问控制。例如,某些用户只能查看特定部门的数据,而不能进行修改操作。
3. 数据加密 :确保数据在传输和存储过程中进行了加密处理,防止数据在传输过程中被窃取或篡改。
4. 漏洞扫描 :使用专业的漏洞扫描工具,对数据仓库系统进行全面的漏洞扫描,及时发现并修复可能存在的安全漏洞,如SQL注入、跨站脚本攻击等。
5. 审计和日志记录 :检查系统是否具备完善的审计和日志记录功能,能够记录用户的所有操作行为,以便在发生安全事件时进行追溯和调查。

以下是一个安全测试的流程列表:
1. 制定安全测试计划,明确测试范围和目标。
2. 进行用户认证测试,验证身份认证机制的有效性。
3. 检查访问控制策略,确保用户只能访问其有权限的数据资源。
4. 测试数据加密功能,确保数据的安全性。
5. 使用漏洞扫描工具进行全面扫描,发现并修复安全漏洞。
6. 检查审计和日志记录功能,确保操作行为可追溯。
7. 总结测试结果,提出安全改进建议。

mermaid流程图如下:

graph LR
    A[开始安全测试] --> B[制定测试计划]
    B --> C[用户认证测试]
    C --> D[访问控制检查]
    D --> E[数据加密测试]
    E --> F[漏洞扫描]
    F --> G{是否发现漏洞}
    G -- 是 --> H[修复漏洞]
    G -- 否 --> I[审计和日志检查]
    H --> I
    I --> J[总结测试结果]
    J --> K{是否需要改进}
    K -- 是 --> L[提出改进建议]
    K -- 否 --> M[结束测试]
    L --> B
5. 用户验收测试

用户验收测试是让最终用户亲自使用数据仓库系统,以验证系统的可用性和是否满足他们的实际业务需求。最终用户是数据仓库的直接使用者,他们的反馈对于系统的成功部署和使用至关重要。

进行用户验收测试可以按照以下步骤进行:
1. 培训用户 :在测试前,对最终用户进行系统培训,使他们熟悉数据仓库的功能和操作方法。
2. 制定测试场景 :根据用户的实际业务需求,制定一系列的测试场景,涵盖系统的主要功能和常见的业务操作。
3. 用户执行测试 :让用户在实际的测试环境中按照测试场景进行操作,记录他们在使用过程中遇到的问题和反馈。
4. 收集反馈 :及时收集用户的反馈意见,包括系统的易用性、功能完整性、性能表现等方面的评价。
5. 问题处理 :对于用户提出的问题,及时进行分析和处理。如果是系统的缺陷,需要及时修复;如果是用户的使用问题,需要进行进一步的培训和指导。
6. 验收确认 :当用户对系统的可用性和满足业务需求的程度表示满意时,进行验收确认,标志着数据仓库系统可以正式投入使用。

测试关注点 说明
易用性 系统的操作是否方便快捷,用户界面是否友好。
功能完整性 系统是否具备用户所需的所有功能。
性能表现 系统在实际使用中的响应时间、吞吐量等性能指标是否满足要求。
6. 端到端测试

端到端测试的目的是模拟生产环境,让数据仓库系统连续运行几天,以检查系统在实际运行过程中是否存在问题。通过端到端测试,可以发现一些在单独测试各个组件时难以发现的问题,如系统之间的集成问题、数据流转问题等。

进行端到端测试可以按照以下步骤进行:
1. 准备测试环境 :搭建一个与生产环境高度相似的测试环境,包括硬件、软件、数据等方面的配置。
2. 设置测试数据 :使用实际的业务数据或模拟数据,填充测试环境中的数据仓库。
3. 启动系统 :按照正常的业务流程启动数据仓库系统,让其连续运行一段时间,例如一周或一个月。
4. 监控系统运行 :在系统运行过程中,实时监控系统的各项指标,如性能指标、日志记录等,及时发现系统运行过程中出现的异常情况。
5. 分析问题并处理 :如果发现系统运行过程中出现问题,及时进行分析和处理。对于一些小问题,可以在测试过程中进行修复;对于一些严重的问题,可能需要重新调整系统配置或进行代码修改。
6. 总结测试结果 :在测试结束后,对测试结果进行总结,评估系统在端到端运行过程中的稳定性和可靠性。如果系统表现良好,可以考虑将其正式部署到生产环境中;如果存在较多问题,需要进一步进行优化和改进。

mermaid流程图如下:

graph LR
    A[开始端到端测试] --> B[准备测试环境]
    B --> C[设置测试数据]
    C --> D[启动系统]
    D --> E[监控系统运行]
    E --> F{是否出现问题}
    F -- 是 --> G[分析问题并处理]
    F -- 否 --> H[继续监控]
    G --> H
    H --> I{测试是否结束}
    I -- 否 --> E
    I -- 是 --> J[总结测试结果]
    J --> K{是否满足要求}
    K -- 是 --> L[正式部署]
    K -- 否 --> M[优化改进]
    M --> B

总结

数据仓库的搜索功能和测试工作对于其成功应用和稳定运行至关重要。搜索功能可以帮助用户更高效地查找所需的数据和信息,提高工作效率;而全面的测试工作则可以确保数据仓库的正确性、性能、安全性和可用性,为企业的业务决策提供可靠的支持。在实际应用中,需要根据企业的具体需求和业务场景,合理选择和配置搜索工具,严格按照测试流程进行各项测试工作,不断优化和改进数据仓库系统,以满足企业不断发展的业务需求。

评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符  | 博主筛选后可见
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值