数据仓库:一个服务器上的暂存区、DWH数据库和ETL工具？

Question

我正在考虑DWH服务器布局，我想问您是否能够发现这种布局的任何缺点。其基本思想是拥有临时区域&数据仓库DBs和ETL工具，用于在一台机器上运行从stg到dwh的转换，因为它降低了硬件成本，减少了管理工作：

• sda: 512 GB SDD -> OS (Centos 7)、应用程序、交换空间、MySQL数据库应用程序(但没有数据)、来自数据源的MySQL文件、ETL (五旬节)
• sdb: 960 GB SDD -> MySQL表空间用于暂存区域表
• sdc: 960 GB -> MySQL表空间用于数据仓库表
• sdd: 4 TB ->备份存档磁盘
• 内存: 160 GB
• 原作者:2 x Intel Xeon E5-2620 v3- 12内核

任务：

• 在stg加载期间:从csv到stg加载数据信息
• 在转换过程中:戊and将从stg中选择，并并行插入到dwh中，用于多个表。我认为在单独的磁盘上使用stg和dwh可以避免读写瓶颈。
• 工作时间:报告工具或分析人员确实选择dwh

从您的观点或经验来看，我为什么不应该使用这个布局，而应该像以前一样在两个不同的服务器上拆分stg和dwh？(例如，MySQL性能可能会受到并行选择和插入等因素的影响)

感谢您的反馈！

Answer 1

你的“所有鸡蛋都放在一个篮子里”的场景似乎已经成熟，可能会产生意想不到的后果。我试图将进程解耦，这样就不会对整个DW体系结构的其他部分产生负面影响。使用单独的磁盘肯定是很好的实践，甚至是拆分，请记住，内存和CPU约束同样是重要的争用点。

这是我在你的设计中看到的一个场景

sql计划会发生变化(由于数据数量或质量的变化)，您将在第二天早上返回，并意识到ETL仍然在运行，而额外的CPU和内存绘制正在影响查询性能。这使您处于一种令人不快的情况，您想知道是否已经足够远来完成加载，或者您应该终止它并在稍后进行追赶加载(它可能有更多的数据)，以便用户获取他们的数据。

将某些体系结构解耦使您可以重新查看阶段性数据，查看问题，运行验证检查，最重要的是，您可以灵活地在工作日进行故障排除，而不必担心共享资源。

在任何情况下，如果您确实决定通过单盒路由(我强烈建议反对)运行，请考虑：

• 确保正确的表对适当的需求使用正确的发动机
• CPU限制某些进程，这样它们就不会饿死服务器
• 确保正确设置警报和通知，以便跟踪错误、完成和长时间运行的进程。
• 测试，测试，还有..。测试一下。使用不同的数据大小进行测试。用各种数据进行测试。并通过模拟记忆压力等问题进行测试。

不言而喻，我所说的是一些最佳实践建议和我个人经验的结合。您应该考虑您的业务需求和它的风险能力。例如:在某些行业，拥有一个数据仓库装载前一天的数据是一个非常关键的要求。在其他情况下，仅仅访问数据仓库是最关键的需求。