为什么有人会同时保留这两个系统？
DW 最大的问题是昂贵的启动成本。它需要对您的数据和业务领域有很好的理解，然后才能将它们分解为事实和维度。在此过程中的任何时候，如果您的假设是错误的，您就会被束缚，要么保持现状，要么经历另一个艰难的维护周期。由于这种高昂的间接成本，我已经看到 DW 流程永远不会去任何地方。更不用说，如果你的 DW 人离开了，要培养一个替代者是非常困难的，因为领域知识会随他而去。是的，这就像经典的瀑布流程，僵化而脆弱，通常无法应对不断变化的需求/业务环境。
另一方面，NoSql 是敏捷的。您可以根据需要以临时方式动态创建索引。在存储数据之前几乎不需要了解数据。随着您理解的提高，NoSql 解决方案往往可以很好地扩展。
鉴于 NoSql 可以轻松地承担 DW 的角色，但反过来不行，为什么还要为 DW 烦恼呢？当您已经拥有 NoSql 解决方案时，您如何证明 DW 系统的昂贵存在是合理的？2 有没有地方可以共存？
NoSQL 只是一组数据库技术和产品的名称，当然是数据仓库/决策支持类型应用程序的一个可能平台。所以是的，NoSQL 和 DW 可以而且肯定确实可以共存。
但是，您似乎将数据仓库解决方案等同于维度建模，这只是一种可用于创建数据集市或 OLAP 表示层的技术。DW 和维度模型不是一回事。
我认为 NoSQL 没有太多（如果有的话）使 NoSQL 系统比其他技术更适合敏捷项目。我确信有更多的人和团队使用 SQL DBMS 的敏捷方法而不是 NoSQL！
另一方面，如果您在开发团队中没有或无法保留业务领域知识，那么您就会遇到任何技术或项目交付方法都无法为您解决的管理问题。
如果您为业务构建决策支持系统，则需要了解业务流程，无论您构建它的平台是什么。
这是一项与其他任何事情一样的投资。如果计划和执行得当，您将获得投资回报。
我不是 NoSQL 专家，但它肯定会回答 DW 的不同问题。例如，您如何从 NoSQL 数据库中生成成本/人数数据？您如何将 ERP 中基于行的无聊成本信息和 HR 系统中基于行的 Headcount 信息加载到 NoSQL 中并让它执行？
简而言之，对于数据仓库，我认为关系/OLAP 世界具有显着优势，主要是因为在许多 BI 场景中，您希望允许用户探索数据，这对于 SQL 工具集很容易，而对于 NoSQL 解决方案则更难. 但是当您变得太大（并且在 OLAP 场景中太大）时，您可能需要考虑限制用户的选项并使用适合他们需要的 NoSQL 解决方案。
来自：http ://ayende.com/blog/4552/nosql-and-data-warehousing
我想最终用户的 BI 集成将是主要驱动力。从易于集成/服务/可扩展性 PoV 来看，没有 sql 可以轻松夺冠。