主页 / dba / 问题 / 115370
Accepted
Craig
Asked: 2015-09-18 07:31:27 +0800 CST

何时为维度运行 ETL

  • 772

我们有一套餐厅网络应用程序，将数据存储在数据库服务器上的 SQL Server 2012 中。我们现在已经开始将用于报告的数据移动到单独的数据仓库服务器上。数据需要在更新/创建后很快进入数据仓库。

知道何时将事务移动到数据仓库（和事实表）很容易——我们定期或在某些事件发生时（比如经理完成某事）这样做。

但是我怎么知道何时将定义移动到数据仓库（和维表）？我们将定义存储为 SCD 类型 1。

我们正在考虑...

  1. 按照计划，使用维度检查数据库服务器上的所有定义并更新任何更改。将交易分配给“未知”是尚未到达的维度。
  2. 在所有定义表上放置触发器并在发生更改时更新数据仓库
  3. 更新存储过程以在每次进行更改时更新数据仓库
  4. 使用 Microsoft Sync Framework 之类的东西，并在其中合并转换。

数据库和数据仓库服务器位于不同的服务器上——我们计划将其迁移到 SQL Azure。

那么，我如何知道何时运行维度的 ETL？而且，任何关于技术的建议都会有所帮助（我们目前正在使用 SQL Server 链接服务器）。

sql-server data-warehouse

1 个回答

  1. Best Answer

    您有多种选择——所有这些都需要您做出一些日程安排决定。如评论中所述，对您的源系统影响最小的是从您的 OLTP 系统中寻找审计日期/时间戳。每当有插入或更新时，许多系统都会在行上放置日期时间戳，因此可以可靠地用于捕获更改。如果您使用 >= 模式，这是最安全的，这样您就不会错过阅读时提交的任何内容。从最后的毫秒记录复制的可能的小记录集不应该对标准更新插入逻辑造成太大问题。

    您可以保留一个表来跟踪每个源的最新审计日期时间并使用它，但如果您从多个表中提取单个维度，它可能会变得笨拙。如果您了解您的系统，您还可以使用诸如 PK 增量或类似的可靠数据更改模式之类的东西来限制您的源查询。

    CREATE TABLE [UTIL].[IncrementalLoadHelper]
(
     [Id] INT NOT NULL IDENTITY PRIMARY KEY
    ,[TargetTableSchema] VARCHAR(20) NOT NULL
    ,[TargetTableName] VARCHAR(100) NOT NULL
    ,[IncrementalValueInt] INT NULL
    ,[IncrementalValueDateTime] Datetime NULL
    ,[IncrementalValueVarchar] Varchar(500) NULL
    ,[IncrementalValueDecimal] Decimal NULL
    ,[SuccessfulLoadFlag] bit NOT NULL
    ,[InsertRowCount] INT NULL
    ,[UpdateRowCount] INT NULL
    ,[SSISPackageName] Varchar(500) NOT NULL
    ,[AuditInsertDate] DATETIME NOT NULL DEFAULT GETDATE()
    ,[AuditUpdateDate] DATETIME NULL
    ,[AuditUser] VARCHAR(200) NOT NULL DEFAULT SUSER_NAME()
)

    .

    SELECT [Columns]
FROM OLTP.SourceSystem
WHERE AuditDateTime >=
(
 SELECT MAX(AuditDateTime)
 FROM TrackingTable
 WHERE TableName = 'TblName'
)

    您还可以启用使用内置 SQL Server 功能并且不需要有用的 OLTP 数据库设计的更改跟踪。它将比Change Data Capture使用更少的资源，这是一个类似的解决方案。其中任何一个都可以创建易于查询的表，以识别自某个时间以来发生的更改，并允许您大大减少每个 ETL 阶段移动的数据总量。

    我建议删除链接服务器并使用 SSIS 来移动您的数据。它可能更容易维护和设计。它具有可与 CDC 配合使用的预构建任务。要么将 SSIS 放在您的 DW 机器上，要么创建一个专用的 ETL 处理机器，并将尽可能多的 ETL 资源需求移出 DW 和 OLTP。

    由于您提到首先获取事实，因此请确保您拥有正确的推断成员逻辑，以便在所有数据可用时稍后进行解决。

    此外，考虑或让业务考虑更快加载与资源和开发/维护成本的价值。“实时数据”听起来很棒，直到您看到它的别名：$$$$。

    • 3

相关问题