2.2 是什么讓它們有所不同

你也許可以猜到，分析型數據和事務型數據在幾個關鍵方面有所不同，這些方面決定了我們要如何管理其可靠性，如圖2-1所示。

在數據管道中，事務型數據幾乎總是出現在分析型數據的上游。這是因為分析型數據能夠（并且）經常包含事務型數據存儲的聚合或擴充。某一用戶早上5點時在瀏覽器中的點擊率是一個事務型數據，而12月份營銷活動的點擊率則是相應的分析型數據。

事務型數據與分析型數據的區別很重要，一個關鍵原因是吞吐量與延遲的權衡。吞吐量-延遲的約束會影響任何具有固定計算能力的系統。傳統的吞吐量指的是在某一單位時間內處理的數據量，而延遲指的是數據被處理之前所等待的時間。

想象一家外面正在排隊的網紅咖啡廳。排隊的人要多久才能拿到咖啡呢？這個過程包括排隊、下單、付款，然后等待咖啡師制作飲品。這段時間的總和就是該咖啡廳的延遲。相反，單位時間內能夠在室內享用咖啡的顧客數量就是該咖啡廳的吞吐量。

圖2-1：數據平臺示例，僅說明區分事務型數據和分析型數據的一種方法

不過，這兩個度量數據處理效果的指標注定要相互競爭?？Х葟d不能既有高吞吐量又有低延遲。為什么呢？吞吐量和延遲并不是完全相反的呀。這其實與現實中數據處理系統的構建方式有關，具體來說，這與有限數量的請求處理程序有關。

讓我們再來想象一下這家咖啡廳。這里有固定數量的員工，而我們訂購的機器人serveo-trons由于芯片短缺而出現積壓，無法發貨。作為經理，我們必須決定應該為濃縮咖啡機和收銀臺配備多少員工，而又有多少員工應該負責收拾桌子。注意到此處的權衡了嗎？假設我們不惜一切代價優化咖啡廳的延遲，那幾乎就會把所有員工都配備到收銀臺和濃縮咖啡機旁，以便顧客能夠盡快下單并收到他們的飲品。但如果我們這樣做，吞吐量就會大幅降低，因為沒人收拾桌子為新來的顧客騰位置。而與此相反，如果我們讓大多數員工在餐桌周圍服務，在顧客離開的那一刻開始收拾餐桌，那么延遲就會增加，因為沒有人操作收銀機！

在某些情況下，權衡是顯而易見的。事務型數據庫需要在頁面加載時盡快獲取包括訂單詳細信息在內的某些信息。因此，通過各種設計決策，它們的架構將針對低延遲進行優化。相比之下，分析型數據庫則迎合了用戶對海量數據集進行大規模聚合的需要，因此它們必須針對高吞吐量進行優化。這種關于使用哪些服務來做什么的啟發式建議并不完美，但它至少解釋了為什么你通常不會從客戶的用戶界面（UI）中查詢Snowflake或Redshift，或者在MySQL或Postgres實例中運行萬億行的聚合。