Apache nifi、flume、storm 等數據攝取工具或 logstash 等工具從哪些數據量中變得相關？
我在一家擁有兩個遺留數據倉庫的公司工作，這些數據倉庫一直在演變為不可維護的單體。因此，他們迫切需要重組。
我正在研究將目前的數據架構改革為更符合數據網格原則的架構，就像 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 在數據安全寫入磁碟之前不會返回。
Insert into live_data value ( ..... ); commit;解決方案是記憶體請求以保存數據，然後將其批量載入到數據庫中。
這就是卡夫卡發揮作用的地方。（我們說的是每秒可擴展至 100 萬個物聯網讀數）
如果您在每天載入 2GB 數據時遇到問題，則需要調查原因。
性能的關鍵是批量載入數據，而不是使用slow-by-slow（逐行）方法。
我發現數據庫程式碼（PL/SQL；T-SQL）比 ETL 工具（例如 Informatica）執行得更快，但 ETL 工具更容易長期維護。