Data-Warehouse
現代數據倉庫如何處理頻繁的小寫入？尤其是當流數據是來源之一？
所以很多天，我一直在想一個問題。
**現代數據倉庫如何處理頻繁的小額寫入？**尤其是 當流數據是來源之一？
例如 Kafka/Kinesis => DW（Snowflake、Teradata、Oracle ADW 等）
我的印像是，由於數據倉庫表通常是高度非規範化和列式的（為了報告查詢的快速性能以避免連接），因此它們對於頻繁的小寫入操作很慢，但對於報告樣式
SELECT語句具有良好的性能。因此產生了從 OLTP 數據源到 OLAP 數據倉庫的批量夜間上傳的概念。
- 現代 DW 內部架構發生了哪些變化？
- DW 本身是否有一個暫存區域，數據在那裡著陸，然後被聚合，統計數據被收集，然後在最終進入為報告提供動力的實際 DW 表之前進行非規範化？
我很想知道它在內部是如何在高層次上工作的。
我知道這是一個基本問題，但這是我在學生時代的理解，因此我很確定它已經過時了。
正如 mustaccio 已經指出的那樣，頻繁的小更新和大容量查詢從根本上是不兼容的。
主要原因是“頻繁的小更新”是操作數據庫的一個特徵，這通常需要 DBMS 盡其所能（例如鎖定）來保護數據完整性，這通常會妨礙大容量查詢是典型的 DW 類型的使用。（您可以在“忽略完整性”模式下進行查詢（例如讀取未送出的隔離），然後問題會有所不同，因為這只是足夠的記憶體和處理器的問題，但當然是以犧牲結果的可靠性為代價的.)
像 MVCC 這樣的鎖定方案理論上可以解決這個問題，但它們可能會佔用自己的資源，因此它們並沒有真正解決問題，只是將其轉移到其他地方。
像 IDAA（集成數據分析加速器）這樣的架構將整個 DW 及其解除安裝置於 DBMS 的專有控制之下。它們有效，但這確實意味著當您使用 DW 部分時，您永遠不會非常準確地知道您正在查看的數據。
因此，您不僅不太可能找到具有您今天描述的功能的 DBMS，而且您也不太可能在短期到中期的未來看到出現。