【问题标题】:Transforming OLTP Relational Database to Data Warehousing Model将 OLTP 关系数据库转换为数据仓库模型
【发布时间】:2010-10-26 11:27:48
【问题描述】:

将数据从典型的实体关系 OLTP 数据库模型加载到 Kimball 星型模式数据仓库/集市模型中时采用了哪些常见设计方法?

  • 您是否使用暂存区执行转换然后加载到仓库?
  • 如何在仓库和 OLTP 数据库之间链接数据?
  • 您在哪里/如何管理转换过程 - 在数据库中作为 sproc、dts/ssis 包或来自应用程序代码的 SQL?

【问题讨论】:

    标签: sql-server data-warehouse oltp


    【解决方案1】:

    我同意高度评价的答案,但我想我会添加以下内容:

    * Do you use a staging area to perform the transformation and then
    

    装入仓库?

    是否需要分段取决于转换的类型。分段提供了将 ETL 分解为更易于管理的块的好处,而且还提供了一个工作区域,允许在不影响仓库的情况下对数据进行操作。它可以帮助(至少)在暂存区域中进行一些维度查找,该区域存储来自 OLTP 系统的键和最新暗记录的键,以在加载事实记录时用作查找。 转换发生在 ETL 过程本身中,但它可能需要也可能不需要一些分段来帮助它。

    * How do you link data between the warehouse and the OLTP database?
    

    将业务键(或实际主键,如果可用)加载到数据仓库中作为对 OLTP 系统的引用是很有用的。另外,在DW过程中的审计应该通过记录已经加载过的加载过程来记录每一位数据的血缘关系。

    * Where/How do you manage the transformation process - in the
    

    数据库作为 sprocs、dts/ssis 包, 还是应用程序代码中的 SQL?

    这通常在 SSIS 包中,但通常在源查询中进行转换会更高效。不幸的是,这使得源查询非常难以理解和维护,因此如果性能不是问题,那么在 SSIS 代码中进行转换是最好的。当您这样做时,这是拥有暂存区域的另一个原因,因为这样您就可以在不同表之间的源查询中进行更多连接。

    【讨论】:

      【解决方案2】:

      您可能想看看Data Vault Modeling。它声称解决了一些孤立的问题,例如更改属性。

      【讨论】:

        【解决方案3】:

        我目前正在开发一个中小型数据仓库。我们采用了 Kimball 提出的一些概念,即带有事实和维度表的星型方案。我们对其进行结构化,以便事实仅连接到维度(不是事实到事实或维度到维度 - 但这是我们的选择,并不是说它应该这样做),所以我们将所有维度连接展平到事实表。

        我们使用 SSIS 将数据从生产 DB -> 源 DB -> 暂存 DB -> 报告 DB 移动(我们本可以使用更少的 DB,但这就是它下降的方式)。

        SSIS 非常棒,因为它可以让您以非常合乎逻辑的方式构建数据流。我们使用 SSIS 组件和存储过程的组合,其中 SSIS 的一个很好的特性是能够提供 SQL 命令作为源/目标数据流之间的转换。这意味着如果我们愿意,我们可以在每一行上调用存储的过程,这可能很有用(虽然有点慢)。

        我们还使用了一个名为更改数据捕获 (CDC) 的新 SQL Server 2008 功能,它允许您审核表上的所有更改(您可以指定要查看这些表中的哪些列),因此我们使用在生产数据库上显示发生了什么变化,这样我们就可以将这些记录移动到源数据库进行处理。

        【讨论】:

          【解决方案4】:

          John Saunders 的流程解释很好。

          如果您希望在 SQL Server 中实施 Datawarehouse 项目,您将在出色的文本“The Microsoft Data Warehouse Toolkit”中找到交付整个项目所需的所有信息。

          有趣的是,其中一位作者是 Ralph Kimball :-)

          【讨论】:

          • 抱歉,我指的是 Kimball,而不是 Kimble :) 我从同事那里借了这本书,但想了解用于执行数据转换的常用策略和工具
          • SSIS 是要走的路。您需要执行的大多数任务已经由现有的包组件提供,并且并行处理能力确实可以让事情在吞吐量方面快速发展。
          【解决方案5】:

          就个人而言,我倾向于如下工作:

          1. 首先设计数据仓库。特别是,设计作为 DW 一部分所需的表,忽略任何临时表。
          2. 使用 SSIS 设计 ETL,但有时使用 SSIS 调用相关数据库中的存储过程。
          3. 如果需要任何临时表作为 ETL 的一部分,那很好,但同时要确保清理它们。仅用作一系列 ETL 步骤的一部分的临时表应在这些步骤完成后截断,无论成功与否。
          4. 我让 SSIS 包至少引用 OLTP 数据库以将数据提取到临时表中。根据情况,他们可以将 OLTP 表直接处理到数据仓库中。所有此类查询均使用 WITH(NOLOCK) 执行。
          5. 文档,文档,文档。明确每个包使用的输入以及输出的去向。确保记录选择输入的标准(过去 24 小时?自上次成功以来?新的身份值?所有行?)

          这对我来说效果很好,虽然我承认我没有做过很多这样的项目,也没有做过任何真正的大项目。

          【讨论】:

          • @John - 您是否为您的数据仓库模型使用了 Kimble“事实和维度星型模式”设计?
          • 我想是的。我从来没有读过这个“Kimble”家伙,尽管人们在数据仓库中调用他的名字几乎和人们在算法中调用“Knuth”一样多。但话又说回来,我从来没有没有读完 Knuth 的第一本书,最后卖掉了整套书。我现在正在处理的数据集市更像是一片雪花,因为我们有几个维度有维度。我们的情况类似于客户和销售人员都是维度,他们都有地理。
          • 抱歉,我指的是 Kimball,不是 Kimble :)
          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2013-12-25
          • 1970-01-01
          • 2015-11-15
          • 1970-01-01
          相关资源
          最近更新 更多