主要目标是案例优化的数据表示。这个想法是从多个数据库收集数据，将数据保存在数据仓库中，并重组/连接数据集市中的数据（类似于跨多个数据库的视图）。基本上，目的是让访问分布在数据库中的数据变得更容易。
正如您在图片中看到的那样，计划是拥有依赖数据集市（显示在图片的上半部分）以避免像独立数据集市（显示在图片的底部）那样具有多个清理和加载进程。数据仓库的 BI 方面也将被使用，但与我的问题无关。只会更改数据库中的数据。DW 中表示的数据仅供阅读之用。所以基本概念是没有伤害的。但我仍然觉得 DW 在这里被滥用了。
要回答我的问题，请包括以下几点：
- DW 是否被滥用？
- 是否有任何 DW 具有适合（接近）实时功能的数据连接器？
- 哪些替代方案可以满足这些要求，以连接来自多个数据库的数据，并以干净和结构化的方式实时表示它们，而无需大量的清理和加载过程？
第一个（顶部）示例本质上是为 BI 数据仓库和数据集市设计 ETL 过程的最常用方法。您不需要下面的示例，因为您需要构建、部署/版本化和对同一代码的多个实例进行故障排除。
至于“滥用”与否，这完全取决于您如何设计数据集市。通常，星型模式是为分析而设计的，但毫无疑问它不适用于 OLTP 类型的工作。我会考虑在加载时重塑数据所需的工作量 - 是否值得额外的复杂性，或者您最好直接从您的应用程序查询源数据库？也许源数据库中的数据库视图可以做同样的事情，但复杂性要低得多？
真正小心“实时”BI 实施：您构建的解决方案越“实时”，它不可避免地会变得越复杂。
一方面，每晚执行截断和加载的进程构建和运行起来相对简单。
以及每小时运行一次的增量加载，您需要开始识别源数据中新的、更改的甚至可能删除的 (!) 行。这可能很难甚至不可能，具体取决于源数据的结构或发送给您的方式。
一个完整的“实时”解决方案（在引号内，因为除非您只查看源数据库，否则它不是真正的实时）可能需要对每个从属表进行某种更改捕获、触发器或类似的复杂逻辑。所有这些都可能对源数据库的性能和稳定性产生不利影响。
当这些表交互时，它会变得更加复杂和昂贵，例如，如果您需要将雪花模式连接到星型模式中。
要回答您的第三个问题，几乎所有 ETL 工具（SSIS、Pentaho 等）都将支持基本数据仓库 ETL。一旦你添加了近实时逻辑，平台 ETL 工具的选择就变得不那么重要了（无论如何你可能需要自己编写大部分脚本），并且解决方案变得非常依赖于源数据的数据库平台以及基础设施和数据仓库的平台。