我在一家拥有两个遗留数据仓库的公司工作，这些数据仓库一直在演变为不可维护的单体。因此，他们迫切需要重组。
我正在研究将当前的数据架构改革为更符合数据网格原则的架构，就像 Zhamak Dehghani 在这篇有影响力的文章中所提倡的那样（可能是数据专业人士众所周知的材料）。
第一个数据仓库，比如 DWH-A，主要由直接来自核心公司应用程序的操作数据库的数据组成。它每周通过来自运营数据库的 FTP 转储进行更新，每次更新都包含大约 2GB 的数据。在 5 年的时间里，DWH 已经增长到 +-300GB 的可观大小。
第二个数据仓库，比如 DWH-B，由来自各种 API 和其他数据源的各种数据组成。它通过 API 调用不断更新，大小为 +- 100GB。
这两个数据仓库都主要使用 T-SQL 构建并托管在 MS SQL Server 上。目前，所有数据要么从操作数据库（通过 SSIS）插入，要么从 API（通过 SSIS icw ZappySys）插入。
由于我的任务是升级当前的做事方式，并且由于我认为 SSIS 是一种相当多余且繁琐的插入数据的方式，因此我正在寻找其他方式将数据摄取到某些数据存储中符合数据网格的原则（因此没有单体数据仓库）。
为此，我遇到了 Apache nifi、Flume、Storm、Kafka 和 Logstash 等工具。所有这些工具就其本身而言似乎非常强大，并且适合处理大量数据。然而，考虑到我正在处理的数据量，我想知道这些工具是否真的与我的公司相关。我不想通过发射火箭筒来杀死蚊子，并使事情变得不必要地复杂化。我还可以简单地构建一些在我们的 K8S 集群中运行的 Python 脚本，并定期检索/写入数据到我们的数据存储中。
将背景总结为一个问题：
Apache nifi、flume、storm 等数据摄取工具或 logstash 等工具从哪些数据量中变得相关？
任何建议将不胜感激。
首先，在您开始看到问题之前，您提到的数字中似乎遗漏了几个零（IMO）
其次，我只将 Kafka 视为从多个 IoT 设备获取数据的数据加载解决方案的一部分。
在这些情况下，Kafka 被用来解决物联网问题。
符合 ACID 的数据库在从多个客户端摄取一堆单行插入时存在问题。这是因为 COMMIT 在数据安全写入磁盘之前不会返回。
解决方案是缓存请求以保存数据，然后将其批量加载到数据库中。
这就是卡夫卡发挥作用的地方。（我们说的是每秒可扩展至 100 万个物联网读数）
如果您在每天加载 2GB 数据时遇到问题，则需要调查原因。
性能的关键是批量加载数据，而不是使用slow-by-slow（逐行）方法。
我发现数据库代码（PL/SQL；T-SQL）比 ETL 工具（例如 Informatica）运行得更快，但 ETL 工具更容易长期维护。
数据量是选择摄取管道实施的最后标准之一。您可以选择当前工具无法完成的功能，然后对其进行测试以查看是否可以处理该卷（剧透警告：可以；在 99.9% 的情况下，数据库将成为瓶颈）。