1. 优点
1.1. 使用关系数据仓库(RDW)可以更轻松地构建任何类型的BI解决方案，因为BI解决方案可以直接从RDW中提取数据，而无须创建复杂的逻辑从多个源系统中提取数据
1.2. 无须清洗或合并数据，因为RDW已经完成了这些工作
1.3. 使用RDW构建的BI解决方案可以是一个数据集市
1.4. 可以对数据进行分类汇总以加快查询和生成报表的速度，甚至可以在Microsoft Excel中使用
1.5. 有了RDW，就等于拥有了一个坚实的基础来构建解决方案
1.6. 减轻系统上的压力
1.7. 优化读取访问
1.7.1. 应用程序数据库通常会被优化以平等地支持所有CRUD（增、删、改、查）操作，因此数据的读取速度会降低
1.7.2. 数据仓库是一种“一次写入，多次读取”的系统，这意味着它主要用于读取数据
1.7.3. 可以针对读取访问进行优化，特别是针对耗时的顺序磁盘扫描频繁发生的时候，比如在运行报表或查询时
1.7.4. 许多数据库技术可以用来加速数据仓库中的读取访问，其中一些会损害写入访问速度，但是这不重要
1.8. 整合多个数据源
1.8.1. 整合多个数据源，以便生成更有价值的报表是构建数据仓库的更重要原因之一
1.8.2. 将所有数据放在一个位置，而不是分散在不同的数据库中，这不仅使生成报表更容易，而且大大提高了性能
1.9. 生成准确的历史报表
-
1.9.1. 如果没有数据仓库，应用程序的用户通常会在每个月的特定一天运行生成所有报表
- 1.9.1.1. 然后他们将报告保存到磁盘，以便将来可以查阅这些报表
1.9.2. 数据仓库可以通过跟踪客户位置变化（通过起止时间的客户位置记录）以及其他需要跟踪的字段（例如，雇主或收入）来解决这个问题
1.10. 重构和重命名表
- 1.10.1. 许多应用程序数据库的表名和字段名非常难以理解，尤其是老旧的ERP和CRM产品
1.11. 防止应用程序升级带来的影响
1.11.1. 如果没有数据仓库，则用户需要根据应用程序数据库创建报表
1.11.2. 使用数据仓库可以避免这种情况。在应用程序升级之后，只需要对将数据从应用程序数据库复制到数据仓库的ETL做一个快速更新，而不必更改报表
1.11.3. ETL更新之后，用户才能看到新的数据，但他们的报表中没有错
1.12. 减少安全隐患
1.12.1. 如果没有数据仓库，开发人员将需要为每个终端用户授予对应用程序数据库的安全访问权限，用户要使用这些数据库生成报表
1.12.2. 有了数据仓库，每个终端用户只需要访问适当的表，提供这种访问权限快得多，也容易得多
1.13. 保存历史数据
1.13.1. 许多系统会限制保存的历史数据的数量
1.13.2. 为了节省空间和提高性能，在某些情况下，也是为了遵守法规
1.13.3. 旧数据通常每年或每月清除，而数据仓库可以保存所有的历史数据，因此永远不必担心生成过去的报表时找不到任何数据
1.14. 主数据管理(MDM)
1.14.1. 在从多个源系统收集数据时，开发人员通常需要使用MDM来删除重复的记录
1.14.2. 数据仓库是实现MDM的最佳场所
1.14.3. 许多MDM工具可以创建层次结构（例如，公司→部门→员工），这更有助于理解数据为其增加更多价值
1.15. 解决源系统中的漏洞来提高数据质量
1.15.1. 事实证明，无论应用程序的所有者说什么（比如“我们的数据是干净的”，但事实证明是错误的），从各种源系统获得的大量数据都需要清理
1.15.2. 数据仓库不仅可以清理数据，还可以通知维护应用程序的人员系统中的漏洞，以便他们修复
1.15.3. 通过这种方式，可以防止将来输入脏数据
1.16. 在报表生成中消除IT痕迹
1.16.1. 建立一个合适的数据仓库就不再需要IT部门参与生成报表了，这项任务将留给用户自己完成
1.16.2. 没有了IT资源的限制，可以更快地生成报表和仪表盘(dashboard)
2. 缺点
2.1. 复杂性
2.1.1. 数据仓库的设计、构建和维护既复杂又耗时
2.1.2. 所需的专业技能和资源可能会增加成本
2.2. 高成本
2.2.1. 实现数据仓库可能是昂贵的，需要在硬件、软件和人员上进行大量投资
2.2.2. 持续的维护和升级也会增加成本
2.3. 数据集成的挑战
2.3.1. 各种来源的数据进行集成是具有挑战性的，因为这可能涉及处理不同数据格式、结构和质量的问题
2.3.2. 需要在数据清洗和预处理上花费时间和精力
2.3.3. 某些数据难以直接摄取到RDW中
2.4. 数据转换耗时
2.4.1. 对于要加载到数据仓库中的数据，可能需要对其进行转换，以符合仓库的数据模型
2.4.2. 可能会很耗时，数据转换中的错误可能会导致数据分析不准确
2.5. 数据延迟
2.5.1. 由于数据仓库是为处理大量数据而设计的，因此它们的处理速度可能比其他类型的数据库慢
2.5.2. 可能导致数据延迟，即仓库中的数据可能不包含源数据库的最新更改
2.6. 维护期
2.6.1. 使用RDW，通常需要一个维护期
2.6.2. 因为加载和清洗数据是非常消耗资源的，如果用户试图在这个时间生成报表，速度会非常慢
2.6.3. 在进行维护时必须将用户拒绝于数据仓库之外，拒绝全天候访问
2.7. 灵活性差
2.7.1. 数据仓库是为支持特定类型的分析而设计的，这可能会限制它们对其他类型数据的处理或分析
2.7.2. 需要额外的工具或系统与仓库集成以满足特定的需求
2.8. 安全和隐私问题
- 2.8.1. 将大量敏感数据存储在一个集中的位置会增加数据泄露和侵犯隐私的风险，因此需要采取强有力的安全措施
3. 构建数据仓库
3.1. 输入数据仓库的源数据表会随着时间的推移而变化，所以数据仓库需要反映出这些变化
3.2. 提取数据的频率
3.2.1. 更新数据仓库的频率在很大程度上取决于源系统更新的频率以及满足用户生成报表的需求
3.2.2. 用户不需要看到当天的数据，而更希望得到前一天结束时的所有数据
-
3.2.3. 要考虑的问题是每次提取的数据量
3.2.3.1. 如果它非常大，更新数据仓库可能会花费很长时间，因此要将更新分成更小的块，并进行更频繁的提取和更新，例如每小时更新而不是每天
3.2.3.2. 如果需要将大量数据从源系统传输到数据仓库，尤其是如果源数据位于本地并且没有从源系统到互联网的高效传输线路，可能需要很长时间
3.2.3.3. 相比大数据量的夜间传输，在白天可能需要切换到数据量更小的以小时为单位的传输
3.3. 提取方法
-
3.3.1. 全量提取
3.3.1.1. 全量提取是从源系统一个或多个表中提取所有的数据。这对于较小的表来说效果最好
3.3.1.2. 提取反映了源系统上目前可用的所有数据，不需要跟踪变化，使得这种方法非常容易构建
3.3.1.3. 源数据是按原样提供的，你不需要任何额外的信息
-
3.3.2. 增量提取
3.3.2.1. 增量提取，是指提取指定时间（例如最后一次提取或财政周期结束）以后更改的数据，而不是整个表
3.3.2.2. 无论是全量提取还是增量提取，提取数据的方式都有两种：在线提取和离线提取
3.3.2.3. 在线提取，提取过程可以直接连接到源系统去访问源表，也可以连接到一个中间系统，该系统通过以预配置的方式对数据的更改进行存储，例如采用事务日志或更改表的方式
3.3.2.4. 并非总是可以直接访问源系统
3.3.2.4.1. 数据会在源系统之外进行处理，并由来自源系统的提取程序创建
3.4. 确定自上次提取之后的数据变化情况
3.4.1. 对于许多源系统来说，识别最近修改的数据并进行增量提取是很困难的
-
3.4.2. 时间戳
- 3.4.2.1. 时间戳是一个很好的选择，也是最容易实现的
-
3.4.3. 变更数据捕获
3.4.3.1. 大多数关系数据库支持变更数据捕获(CDC)，它会记录对数据库表执行的插入、更新和删除操作，并根据关系数据库的事务日志生成一个表记录，说明发生了哪些更改以及发生的时间和位置
3.4.3.2. 如果是实时的数据仓库，可以在几秒内看到源系统中的更改在数据仓库中的反映，CDC可能是实现这一目标的关键技术
-
3.4.4. 分区
- 3.4.4.1. 有些源系统使用范围分区，即根据关键日期将源表分区，这样很容易识别新数据
-
3.4.5. 数据库触发器
- 3.4.5.1. 可以在单个表上添加插入(INSERT)、更新(UPDATE)和删除(DELETE)触发器，并让这些触发器将有关记录更改的信息写入“更改表”
-
3.4.6. MERGE语句
3.4.6.1. 最不可取的选择*是从源系统全量提取到数据仓库中的一个暂存区域，然后使用MERGE语句将此表与之前从源系统完全提取的表进行比较，以识别被更改的数据
3.4.6.2. 会给数据仓库带来相当大的负担，特别是在数据量很大的情况下
3.4.6.3. 在没有其他可能的选择的情况下，这种选择通常是最后的手段
4. 关系数据仓库之死
4.1. 当数据湖第一次出现时，它们是建立在Apache Hadoop技术上的，而且主要是Hadoop供应商宣布RDW已死
4.2. 数据湖为数据科学家和自助式数据使用者（“高级用户”）提供了丰富的数据来源，并且很好地满足了数据分析和大数据的需求
4.3. 关系数据仓库永远不会被完全废除
4.3.1. 在数据湖上生成报表仍然比在数据仓库上更难
4.3.2. 关系数据仓库(RDW)仍然能够满足用户的信息需求并提供价值
4.3.3. 很多人使用、依赖数据仓库，并且信任数据仓库，并不想用数据湖取代数据仓库
