Tricentis 如何使用 Amazon Redshift 在软件开发生命周期中快速解锁见解

> *这是一篇与来自 Tricentis 的 Parag Doshi、Guru Havanur 和 Simon Guindon 共同撰写的特约文章。* Tricentis 是 DevOps、云和企业应用程序的持续测试领域的全球领导者。自 State of DevOps 2019 DORA Metrics（2019 年 DevOps 状态 DORA 指标）发布以来，已经广为确认的是，利用 DevOps，公司的软件部署频率提高了 208 倍，速度提高了 106 倍，从事件中恢复的速度提高了 2604 倍，而缺陷则减少为 1/7。速度改变了一切，而在整个 CI/CD 生命周期内的持续测试是关键所在。但是，只有当您有信心按需发布软件时，速度才有现实意义。Tricentis 通过提供实现大规模敏捷持续测试（ACT，Agile Continuous Testing）的软件工具来注入这种信心。无论面向的是探索性还是自动化、功能性还是性能、API 还是 UI 开发，无论针对的是大型机、自定义应用程序、打包应用程序还是云原生应用程序，Tricentis 都提供了一整套专业的持续测试工具，帮助其客户满怀信心地按需发布。 Tricentis 旅程的下一个阶段是跨所有测试工具发掘洞察。由于通过许多不同工具进行的测试彼此隔离，因此，团队可能难于获得整合的软件质量视图。需要整合软件质量视图的用户来无法接受这一情况。在这篇文章中，我们分享了 Amazon Data Lab 如何利用在 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 的支持下获得的洞察，帮助 Tricentis 改进其软件即服务（SaaS）Tricentis Analytics 平台。 ### **挑战** Tricentis 为成千上万的全球客户提供 SaaS 和本地解决方案。在对软件进行了任何需要进行测试的更改后，您可在测试管理工具（例如 Tricentis qTest）、测试自动化工具（例如 Tosca 或 Testim）或性能测试工具（例如 Neoload）中跟踪这些更改。虽然 Tricentis 已积累了十多年的此类数据，但尚未利用这些数据来获取有价值的洞察。所有这些工具自身都具有报告功能，这使得数据难以整合，无法用于获得切实可行的综合性业务洞察。 此外，规模也很重要，因为多租户数据来源会提供持续的测试活动流，并且由于合规性和法规要求，我们的用户需要快速数据刷新以及获取长达十年的历史背景。 最后，数据完整性至关重要。数据来源中的每个事件都有可能相关，而不论是数据丢失、数据质量差还是来源与 Tricentis Analytics 之间存在差异，都是客户所不能容忍的情况。在聚合、汇总以及根据常用信息模型进行调整时，任何转换都不得影响其来源数据的完整性。 ### **解决方案** Tricentis Analytics 的目标是跨其整个 Tricentis 产品组合，解决近乎实时地提供大量具有视觉吸引力的报告和分析所带来的挑战。 最初的客户目标是： * 提供可从 Amazon Cloud 安全访问的数据导出 * 提供一组预构建的初始控制面板，用于提供即时业务洞察 * 在 6 周内与早期采用者客户一起对解决方案进行 Beta 测试 考虑到多租户数据来源，Tricentis 和 Amazon Data Lab 团队针对以下约束条件进行了设计： * 提供端到端管道，仅将符合条件的客户加载到分析存储库中 * 在严格隔离的环境中，将多租户数据转换为针对每位客户进行隔离的单租户数据 由于已经明确了需要跨部署在任意环境中的多个来源整合数据，因此该架构需要企业级分析平台。数据管道包含多个层： * 以应用程序事件或更改数据捕获（CDC，Change Data Capture）流的形式从来源中摄取数据 * 对数据进行排队，这样我们就可以及时回放和重放数据，而不必返回到来源 * 轻量级转换，例如，将多租户数据拆分成单租户数据，从而实现客户数据的隔离 * 在可扩展且可靠的智能湖仓（数据湖和数据仓库）存储库中保存和呈现数据 一些客户通过采用适当防护机制（用于确保稳定性）的 API 直接访问存储库，以将其测试数据与企业中的其他数据来源结合起来，而另一些客户则使用控制面板来获取对测试的洞察。最初，Tricentis 定义了这些控制面板和图表，以深入洞察测试运行、根据要求进行的测试可追溯性以及许多其他可能对客户有用的预定义使用场景。以后，我们会为最终用户提供更多功能，让他们能够自行进行分析和获得洞察。 ### **Tricentis 和 Amazon Data Lab 如何能够在 6 周内获得业务洞察** 考虑到 Tricentis Analytics 需要在 6 周内解决真实的客户挑战，Tricentis 与 Amazon Data Lab 进行了合作。从详细的设计到 Beta 版，在这个过程中，Tricentis 的客户希望仅使用其专用数据湖中的数据，及其十多年来生成的全部数据。客户还需要使用自己的存储库（一个 Apache Parquet 数据湖），该存储库将与客户环境中的其他数据结合使用，以便收集更深入的洞察。 亚马逊云科技客户团队提议举行 Amazon Data Lab Build Lab 会议，帮助 Tricentis 加快原型的设计和构建过程。Build Lab 是一个为期两到五天的活动，由一名 Amazon Data Lab 解决方案架构师指导客户的构建人员团队开展大量的构建工作。在 Build Lab 期间，亚马逊云科技服务专家将向客户提供有关实际架构模式和反模式的指导，以及构建高效解决方案的策略，帮助客户使用其数据在环境中构造原型。包括实验前准备工作时间在内的总参与持续时间通常为 3-6 周，Tricentis 的案例一共用时 3 周：2 周为实验前准备工作，1 周为实验时间。在实验之后，接下来几周的活动包括特定客户的产品上市活动、文档记录、强化、安全审查、性能测试、数据完整性测试和自动化活动。 在实验之前，用 2 周时间完成以下工作： * 了解使用场景并逆向思维来设计架构 * 提供实验期间所用服务的全部相关培训，帮助 Tricentis 团队做好实验准备 对于本解决方案，Tricentis 和亚马逊云科技共同构建了一个数据管道，该管道使用实验前便已存在的流式传输中的数据，此流式传输通过 CDC 捕获数据库事务。在流式传输中，每个表中的数据按主题分离开来，来自所有客户的数据都在同一个主题中（不隔离）。因此，我们创建了一条管道来分离客户，以便在最终目标 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 上创建由架构隔离的表。下图展示了该解决方案的架构。  此架构的主要理念是采用事件驱动型架构，并最终实现一致性。每当创建或修改新的测试用例或测试结果时，都会触发事件，以便立即进行处理，并且可以通过 API 获得新的快照文件，或者按照报告或商业智能（BI，Business Intelligence）工具的刷新频率提取数据。每当来自 Apache Kafka 的 [Amazon Simple Storage Service](https://aws.amazon.com/cn/s3/?trk=cndc-detail)（[Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail)）接收器连接器在 [Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail) 上传输文件时，[Amazon EventBridge](https://aws.amazon.com/cn/eventbridge/?trk=cndc-detail) 会触发 Amazon Lambda函数，将多租户文件转换为单独的文件（每个客户的每个表对应一个文件），并将其放置在 [Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail) 上的特定文件夹上。创建文件时，将触发另一个进程，以将每个客户的数据加载到其在 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 上的架构或表中。在 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 上，使用实体化视图来准备好对控制面板的查询，将其更轻松地返回到 Apache Superset。此外，实体化视图已配置为自动刷新（使用自动刷新选项），因此 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 会在基表发生更改后，尽快自动更新实体化视图中的数据。 在以下部分中，我们将详细介绍在此过程中出现的具体实施挑战和客户所需的其他功能。 ### **数据导出** 如前所述，一些客户希望导出其测试数据并创建数据湖。对于这些客户，Tricentis 以 Apache Parquet 文件格式提供增量数据，能够根据特定项目和特定日期范围进行筛选。为了确保数据完整性，Tricentis 使用了其名为 Tosca DI 的技术（未包括在 Amazon Data Lab 会议中）。 ### **数据安全** 该解决方案使用以下数据安全防护机制： * **数据隔离防护机制** – Tricentis 源数据库系统供所有客户使用，因此，来自不同客户的数据位于同一个数据库中。为了隔离特定于客户的数据，Tricentis 使用唯一标识符来判别特定于客户的数据。所有查询都根据判别器筛选数据，以便获得特定于客户的数据。EventBridge 触发一个 Lambda 函数，将多租户文件转换为单租户（客户）文件，存储在特定于客户的 S3 文件夹中。此时还将触发另一个 Lambda 函数，以将数据从特定于客户的文件夹加载到客户在 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 上的特定架构中。后一个 Lambda 函数支持数据隔离，可触发提醒并停止对不属于特定客户的任何数据的进一步处理。 * **数据访问防护机制** – 为了确保访问控制，Tricentis 对特定工作相关资源的用户和服务账户应用基于角色的访问控制原则。对 [Amazon Managed Streaming for Apache Kafka](https://aws.amazon.com/cn/msk/?trk=cndc-detail)（Amazon MSK）、[Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail)、Amazon Relational Database Service（[Amazon RDS](https://aws.amazon.com/cn/rds/?trk=cndc-detail)）和 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 的访问，则通过在角色级别授予权限并为这些角色分配适当的资源来控制。 \ **按使用量付费和线性成本可扩展性** \ Tricentis 的目标是仅为使用的计算和存储资源付费，并通过线性成本的可扩展性来扩展分析基础设施。为了在数据层面中更好地管理存储成本，Tricentis 以压缩格式将所有原始数据和中间数据存储在 [Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail) 存储中。Amazon MSK 和 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 根据 Tricentis Analytics 负载来确定合适的规模，并且可以根据未来业务需求进行纵向扩展或缩减，而不会产生停机时间。根据客户数据留存和存档要求，所有存储中的数据（包括 Amazon MSK、[Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 和 [Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail) 在内）都受分层存储和留存政策的约束，以便进一步降低成本并提供线性成本可扩展性。 在控制层面中，Debezium 和 Kafka Connect 资源根据需要开启关闭，因此您只需为所用资源付费。Lambda 触发器将基于事件或计划触发，并在完成任务后关闭。 ### **性能和数据丢失防护** 在管道的三个阶段中进行了性能优化，以实现最大吞吐量： * **数据摄取** – 使用 CDC 事件大大提高了摄取过程中的数据完整性，这样我们便能够依赖 PostgreSQL 和 Kafka 中备受推崇的复制机制，不仅简化了系统，而且消除了许多过去需要进行的数据更正。[Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail) 接收器连接器通过将数据划分为固定大小的文件，进一步确保了实时的数据流式传输到 [Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail)。固定大小的数据文件可避免因超出界限的文件大小导致的进一步延迟。因此，数据质量会更高，并且会以更快的速度实时流式传输。 * **数据转换** – 批处理具有较高的成本效益和计算效率，在正确实施时，可以减轻各种潜在的性能问题。Tricentis 使用批量转换将数据从多租户 [Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail) 移至单租户 [Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail)，并通过微型批量加载在单租户 [Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail) 与 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 之间移动数据。批处理按照 Lamba 调用限制和最大 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 连接限制分阶段进行，以保持最低成本。不过，转换管道可配置为处理 EventBridge 事件上的每个传入 S3 文件，从而实时运行。 * **数据查询** – 对于重复和可预测的控制面板工作负载，具有适当的排序键的实体化视图可大大提高性能。Tricentis 管道使用视图中的动态数据加载和实体化视图中的预计算结果，无缝提高控制面板的性能，同时设置适当的简单和复合排序键来提高性能。排序键中的范围限制谓词进一步提高了 Tricentis 查询性能。 ### **实施方面的挑战** Tricentis 跟踪任意给定时间的可用函数，并且只触发那些时隙可用的函数，保持在默认的 1000 个并发 Lambda 函数运行的限制内。对于每个函数 10 GB 的内存限制，Tricentis 调整了 [Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail) 接收器连接器生成的文件和单租户 S3 文件的大小，使其不超过 4 GB。如果以后有必要，可以通过请求更高的并发运行限制来解除 Lambda 函数限制。 Tricentis 还遇到了一些 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 连接限制。[Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 的配额和可调整的配额限制了对服务器资源的使用。为了有效管理 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 的最大连接数限制，Tricentis 使用了连接池来确保实现最佳的使用量和稳定性。 ### **结果和后续步骤** Tricentis 与 Amazon Data Lab 之间的协作方法不仅大大加快了大数据解决方案的构建速度，而且能够满足大数据解决方案构建时间表的要求，这将使 Tricentis 的客户受益多年。自撰写本文以来，已将客户信息载入、可观察性和警报以及安全扫描作为 DevSecops 管道的一部分实现自动化改造。 该团队得以在 6 周内为 Tricentis 的一位客户测试数据导出服务。 未来，Tricentis 预计将添加多个数据来源，统一为一种通用的普适语言统一，以便测试数据和提供更丰富的洞察，让我们的客户能够在单一视图中获得正确的数据，并增强他们大规模地快速交付软件的信心。 ### **总结** 在这篇文章中，我们向您介绍了 Tricentis 团队在参加 Build Lab 会议期间与 Amazon Data Lab 合作的旅程。会议期间，Tricentis 团队与 Amazon Data Lab 合作，确定了最适合其使用场景的架构，并实施了为客户提供新洞察的原型。 要了解有关 Amazon Data Lab 如何帮助您将想法转化为解决方案的更多信息，请访问 Amazon Data Lab。 **Original URL: ** https://aws.amazon.com/blogs/big-data/how-tricentis-unlocks-insights-across-the-software-development-lifecycle-at-speed-and-scale-using-amazon-redshift/?trk=cndc-detail