使用触发器填补您的数据拼图中的缺失部分
概述
您是否曾经遇到过这样的情况：尝试使用API从事务性系统（例如电子商务系统）中提取关键数据点，却发现必要的信息无法通过提供的端点访问？如果是这样，请继续阅读，了解如何使用触发器有效地解决这个挑战。
在没有端点的情况下，我们可能会认为直接从事务表中查询数据是一种选择。但是直接查询事务表肯定不是一个好主意，因为这可能会对事务系统的性能和稳定性产生重大影响，特别是当涉及到电子商务系统时。当您尝试从正在运行的电子商务系统中查询数据时，这很可能会对用户体验产生不利影响（想象一下在亚马逊购物时等待5-10分钟才能检索购物车！）。
除此之外，在事务性系统的表上运行作业可能会破坏正在进行的事务。如果您每天考虑在数据仓库表中执行“截断-加载”操作，则此问题变得尤为重要。此外，上述选项缺乏对平稳历史数据加载的支持，假设事务性系统中定期进行数据清理。
因此，自动从事务性系统中提取数据并将其无缝集成到数据仓库中，同时又不会对系统产生不利影响，变得至关重要。在这种情况下，数据库触发器提供了一种有效的解决方案。但在我们深入解决方案之前， 这里是有关触发器的介绍。
触发器简介
数据库触发器
通常被忽视的概念，自关系数据库问世以来，数据库触发器一直存在。数据库触发器是每次在源表中创建或更新（甚至删除）记录时触发的函数（在本例中是事务表）。
数据库触发器有两种类型：DDL触发器和DML触发器。
当您希望收到有关数据库结构更改的通知时，设置DDL触发器非常有用。例如，当您希望在定义新模式或创建或删除新表时收到通知时，DDL触发器非常有用。因此，名称为DDL（数据定义语言）触发器。
当插入、删除或更新新记录时，触发DML触发器。 换句话说，每当系统中发生数据操纵更改时，您都会收到通知。这里一个重要的问题是，数据库触发器不仅可以编程为提醒您有关更改的信息，而且可以执行操作，例如将数据移动到临时表中。
专业触发器
现代云平台（例如Azure和AWS）作为其服务的一部分提供专业触发器。值得注意的是，专业触发器与数据库触发器不同。虽然数据库触发器特定于数据库管理系统（DBMS）并在数据库内部运行，但专业触发器具有更广泛的范围。它们可用于各种自动化任务，用于事件驱动的工作流程，并可创建云服务及其组件之间的平稳集成。
以下是AWS作为其云服务之一提供的一些专业触发器：
- AWS Lambda触发器：这些触发器可在特定事件发生时启动Lambda函数。换句话说，您可以指定应触发Lambda函数的事件。事件可以是AWS内部的或外部的。内部事件可以与AWS服务相关，例如Amazon S3，Amazon DynamoDB流或Amazon Kinesis。外部事件可以来自AWS之外的事务性系统的数据库触发器或IoT事件。
- Amazon S3事件通知：这些触发器使您能够在创建、修改或删除S3存储桶时收到通知。它们使用AWS的简单通知服务（SNS）广播消息。
- AWS Cloudwatch事件：如果您使用过独立的关系型数据库，例如Microsoft SQL Server和SQL Server Management Studio（SSMS），则可能已经使用了SQL Server Agent来通知用户作业失败。Cloudwatch专用于AWS，不仅用于通知用户作业失败，还用于触发Lambda函数并响应事件。 CloudWatch事件和Lambda触发器之间的重要区别在于，Lambda触发器指的是AWS Lambda响应事件的能力，而CloudWatch事件是一项更广泛的事件管理服务，可以处理来自Lambda以外的来源的事件。顺便说一下，虽然SQL Server Agent需要配置电子邮件服务器，但Cloudwatch没有这种要求。
以下是 Azure 作为其云服务的一部分提供的一些专用触发器：
- Blob 触发器 — Azure Blob 与 AWS 提供的 S3 存储桶类似。与 Amazon S3 通知可用于获取有关 S3 存储桶中更改的警报类似；Blob 触发器可用于在 Azure Blob 容器中更改时获取通知。
- Azure Function 触发器 — 这些是 Azure 等效的 AWS Lambda Function 触发器。这些触发器可用于在 Azure 中发生事件或外部事件（例如外部事务性数据库触发器、HTTP 请求或 IoT 事件中心流）时启动 Azure 功能。也可以使用定时器触发器基于预定义的计划启动 Azure 功能。
现在，我们已经查看了 AWS 和 Azure 提供的不同类型的数据库触发器和专用触发器，让我们重新访问用例以刷新您的记忆。请允许我提醒您我们之前提到的用例。
用例 — 您在事务性系统的表格中看到一些数据点，您需要这些数据点用于报告指标，但这些数据点未在事务性系统的 API 端点中提供。因此，您无法使用 Python 或 Java 编写脚本来使用 API 获取这些数据点。您不能直接查询事务性系统，因为这可能会对其性能产生负面影响。
为了解决这个问题，我们使用一种组合数据库触发器和云服务提供的专用触发器的方法。以下是一个高级方法：
先决条件：识别事务性系统数据库中具有不可通过 API 端点访问的数据点的表。一旦您识别了该表，按照以下步骤操作 –
步骤 1：创建一个具有与事务性表相同的列的暂存表格。确保您不会从源事务表格复制任何其他约束条件。这是为确保对事务性系统的影响尽可能小而采取的措施。除此之外，还要有一个列来指示执行的操作，例如插入、更新、删除。假设您的事务表格具有 SQL Server 后端，以下是需要创建的事务表格和暂存表格的示例。
-- 示例事务表格CREATE TABLE Pricing_info ( ProductID INT PRIMARY KEY, ProductName VARCHAR(50), Quantity INT, UnitPrice DECIMAL(10, 2), OperationDate DATE);然后暂存表格为：
-- 创建一个没有约束条件的暂存表格CREATE TABLE StagingTable_pricing ( ProductID INT, ProductName VARCHAR(50), Quantity INT, UnitPrice DECIMAL(10, 2), OperationDate DATE, OperationType VARCHAR(10));步骤 2：直接在‘Pricing_info’表格（主事务表格）上设置 DML 触发器。
当新记录进入或现有记录被更新或删除时，触发器需要被编程为将数据插入到暂存表格中。使用暂存表格的想法是它将避免对主事务表格产生任何不必要的负担。
以下是相同的示例。如下所示，DML 触发器的两个最重要的方面（实际上，对于任何数据库触发器）是触发事件和触发时间。触发事件是指应激活触发器的操作。在这种情况下，我们对所有 DML 事件感兴趣，即在交易表“Pricing_info”中的插入、删除和更新。触发时间是指您是否需要在事件发生前或事件发生后触发器执行活动。对于我们的用例，显然是一个“后”事件触发器。我们创建三个触发器，一个用于每个 DML 事件。
以下是插入触发器：
-- 创建触发器CREATE TRIGGER TransactionTrigger_pricing_InsertON Pricing_info--触发事件INSERT 后AS BEGIN -- 将新记录插入暂存表格 INSERT INTO StagingTable_pricing (ID, Column1, Column2, OperationType) SELECT ID, Column1, Column2, 'INSERT' FROM insertedEND;接下来是更新触发器：
-- 创建触发器CREATE TRIGGER TransactionTrigger_pricing_updateON Pricing_info-- 触发事件AFTER UPDATEASBEGIN -- 在分段表中插入记录，包括已更新的数据 INSERT INTO StagingTable_pricing (ID, Column1, Column2, OperationType) SELECT ID, Column1, Column2, 'UPDATE' FROM insertedEND;最后，我们创建删除触发器：
-- 创建触发器CREATE TRIGGER TransactionTrigger_pricing_DeleteON Pricing_info-- 触发事件AFTER DELETEASBEGIN -- 在分段表中插入记录，包括已删除的数据 INSERT INTO StagingTable_pricing (ID, Column1, Column2, OperationType) SELECT ID, Column1, Column2, 'DELETE' FROM deletedEND;步骤3：现在让我们进入专门触发器设置部分。
步骤3a。如果您的数据仓库位于AWS中，下面是一个可以实施的高级解决方案。
在上述解决方案中，源是事务系统。我们在事务系统的数据库中设置一个数据库DML触发器。每当新记录进入事务性数据库表时，触发器都会将新数据插入到事务性数据库中的分段表中。基于时间表（使用AWS Cloudwatch事件），Lambda触发器将触发一个lambda函数，将数据从分段表中获取到数据仓库（Redshift）中的表中。让我们看看其中的步骤。
先决条件：在数据仓库中创建一个将容纳事务信息的表。
步骤3a。 （i）创建AWS Lambda函数：编写Lambda函数的代码，该函数将从分段表中获取记录并将其插入到数据仓库表中，同时进行任何必要的基础计算。
步骤3b。 （ii）创建AWS Lambda触发器 – 使用AWS Cloudwatch服务计划Lambda触发器以在夜间计划中运行Lambda函数（建议在业务小时或交易系统低活动期间运行Lambda函数）。
步骤3c。 （iii）使用EventBridge设置事件映射 – 配置Lambda触发器以使触发器根据指定的事件条件启动事件。典型情况是每天触发Lambda一次。
AWS提供了关于设置Lambda函数的文档，因此，这超出了本文的范围。
步骤3b。如果您的数据仓库位于Azure中，我们可以使用Azure函数和定时器触发器或Azure提供的函数触发器。
在这种情况下，最好使用定时器触发器。当定时器触发器激活时，它将运行Azure函数，然后从分段表中选择新的/更新的/删除的记录。（注意：分段表将具有一个附加的标志变量，指示记录是已插入、已更新还是已删除）。
请按以下步骤操作：
步骤3b。 （i）：创建Azure函数：这类似于设置AWS Lambda函数。设置代码以从分段表中收集记录并将其插入到数据仓库表中，同时进行任何必要的基础计算。
步骤3b。 （ii）：设置Azure函数触发器：使用Azure函数应用程序，设置定时器触发器，并指定时间表和时间戳参数名称。
步骤3b。 （iii）：使用Azure Eventgrid设置事件映射：配置触发器以将事件数据映射到Azure函数中的适当参数。这使触发器能够根据指定的事件条件启动。
处理历史数据负载
到目前为止，我们讨论的解决方案只适用于感兴趣的数据点的新数据。那么如何导入历史数据呢？
为此，一种选择是在创建暂存表时执行“CREATE TABLE AS SELECT”（在 SQL Server 中执行“SELECT * INTO”），这将创建一个预先填充了事务表中当前可用所有数据的暂存表。其余步骤将保持不变（通过专用的 Azure 定时器触发器/AWS Lambda 触发器，具体情况而定）。
另一种选择是在事务表中对所有记录执行“空更新”。以下是基于当前示例/用例的空更新示例：
UPDATE TABLE Pricing_info SET OperationDate=OperationDate如您所见，没有任何值被更新。但是，从数据库的角度来看，所有记录都已更新，因此触发器会为所有更新触发。因此，所有数据都将到达暂存表中。请注意，这不是推荐的方法，因为它可能会由于更新和撤消语句的数量而使事务系统变慢。此外，在整个更新操作期间，事务表也将被锁定，并且不可用于其他进程，从而影响事务系统。如果您的事务表非常小，则可以使用此方法。
结束语
在本文中，我们探讨了触发器在捕获事务系统标准 API 端点不易获取的关键数据点方面的多功能性。
它们有助于确保数据完整性并消除手动干预的需要。从而，它们还确保了关键报告指标的有效包含。此处提供的解决方案是异步的，以确保事务系统不会受到任何负担。如果您的事务系统没有很多流量（或）不直接由终端用户应用程序使用，则可以将其设置为同步进程。在这种情况下，Lambda 或 Azure 函数需要将触发器事件设置为事务数据库的暂存表。还需要提供相应的数据库连接信息。
希望本文对您有所帮助。如果您有任何问题，请在评论中告诉我。祝学习愉快！