數據攝取

就像我們吃食物來獲取能量一樣，計算機系統“吃”或“攝取”數據來獲取信息。

數據攝取系統是一個框架或一組流程，有助于將數據從不同來源傳輸到可以訪問、使用和分析的存儲介質。

數據采集

不同的數據來自不同的地方，比如數據庫、網站，甚至智能設備。 我們將使用稱為協議處理程序的東西來確保我們的系統可以與這些源“對話”而不會出現任何混淆。

對于預定的數據，例如抓取每日天氣預報，我們會設置一個調度程序來完成這項工作。 對于實時內容，例如實時推文或即時更新，流處理器等工具就可以發揮作用。

現在，想象一下每個人都試圖同時進入一個房間； 那就太混亂了。 數據也會發生同樣的情況。 因此，當太多數據試圖同時進入時，我們會使用反壓（backpressure ）策略來進行管理。

我們還要確保所有數據的傳輸和存儲都安全。 這意味著它經過加密或編碼以保持私密性和安全性，尤其是在移動時。

最后，我們會密切關注事情的進展。 使用監控工具，我們可以查看是否一切正常或是否存在任何問題。

協議處理程序

在計算中，協議定義了如何通過網絡傳輸和接收數據的規則。 協議處理程序為特定類型的通信協議（例如用于 Web 流量的 HTTP 或用于文件傳輸的 FTP）解釋和實現這些規則。 它們確保數據在不同系統或軟件之間正確格式化、傳輸和理解。

調度程序

• 基于時間的調度：任務在特定時間或間隔運行。
• 事件驅動的調度：響應特定事件或觸發器而啟動的任務。
• 基于優先級的調度：任務按優先級排列，調度程序選擇可用的最高優先級任務。
• 依賴性調度：根據一項或多項先前任務的完成情況或狀態來調度任務。

流處理器

流處理器在數據到達時持續實時（或接近實時）處理和分析數據。

典型操作：轉換、聚合、過濾、豐富(enrichment)。

鑒于流的連續性，數據通常被分為“窗口”進行分析。 這可以基于時間（例如每 10 秒）或事件計數（例如每 1,000 個事件）。

背壓(Backpressure)

在數據處理和流媒體領域，背壓(Backpressure)是一種機制，接收組件可以向其生產者發出有關其當前可用性的信號，確保數據發送的速度不會快于接收器可以處理的速度。 這對于維持系統穩定性和防止資源耗盡至關重要。

數據處理與轉換

我們首先決定如何處理數據。 有時我們會一次性查看大塊數據，我們稱之為批處理。 其他時候，我們會在它進來時立即檢查它，這稱為流處理。

為了管理這些傳入數據，特別是當數據量很大時，我們使用臨時存儲或“等待線”，數據可以在其中短暫暫停(we use a temporary storage or "waiting line" where data can briefly pause. )。 這種機制很有幫助，特別是當太多數據涌入太快時，讓系統請求暫停或放慢速度。

有些任務需要我們記住以前的數據，這稱為維護狀態(which is called maintaining state)。 根據情況，我們的系統可能會使用過去的數據（有狀態）或將每條數據視為全新的數據（無狀態）。 對于有狀態處理，定義狀態至關重要

當我們處理數據時，我們經常需要調整或改變它以使其更有用，這個過程稱為轉換。 有時，這意味著向我們的數據添加更多詳細信息，例如，如果我們知道某人的城市，我們可能會添加其人口 - 這稱為豐富(enrichment)。 確保所有數據看起來和感覺一致也很重要，因此我們對其進行標準化或規范化(It's also essential to ensure all our data looks and feels consistent, so we standardize or normalize it.)。

當我們工作時，定期保存進度是一個好習慣。 這樣，如果事情失控，我們就不必重做所有事情。 這種保存稱為檢查點(checkpointing)。

而且，為了確保順利操作，我們設計的系統即使我們不小心重復某個操作，也不會導致問題。 這就是所謂的冪等性。

最后，當我們的系統采取行動時，我們確保它完全完成，或者如果出現問題，完全逆轉，確保數據的完整性。 這就是所謂的原子性。

有狀態處理

有狀態處理涉及系統保留上下文歷史數據的能力。 首先確定要記住哪些信息以及將其存儲在何處，可以是快速訪問的內存存儲（例如 RAM），還是更持久的解決方案（例如數據庫）。 正確的狀態管理需要初始化、更新并偶爾丟棄過時的信息。 可能存在的并發訪問，通過鎖等策略可確保數據一致性(With potential concurrent access, strategies like locks ensure data consistency.)。 隨著系統規模的擴大，狀態可能會分布在多臺機器上，從而使分布式數據庫或緩存變得有用。 為了實現彈性，系統可以保存定期“檢查點”或維護數據副本。 可以通過緩存等技術來提高性能，同時安全性仍然至關重要。 定期監控確保系統的可靠性。

冪等性我們通過仔細設計 API 端點并利用唯一標識符來實現冪等性，確保重復的操作具有一致且可預測的結果。

原子性

• 事務：大多數數據庫都支持事務，其中一系列操作被分組并作為一個單元執行。 如果事務中的任何操作失敗，則整個事務將回滾到其初始狀態。
• 兩階段提交：對于涉及多個數據庫或服務的分布式系統，兩階段提交可確保它們之間的原子性。 首先，所有參與者“投票”是否可以提交。 如果所有人都投贊成票，則提交發生； 否則，它會被回滾（Two-Phase Commit: For distributed systems, where multiple databases or services are involved, a two-phase commit ensures atomicity across them all. First, all participants "vote" on whether they can commit. If all vote yes, a commit happens; otherwise, it's rolled back.）。
• 補償事務：在長時間運行的流程中，立即回滾可能不可行。 相反，如果出現問題，則會執行補償事務來抵消早期操作并使系統恢復到一致狀態。
• 鎖和并發控制：為了防止多個操作相互干擾，特別是在多用戶系統中，請使用鎖或其他并發控制機制。

數據存儲

在存儲數據時，我們首先需要了解其性質和訪問模式。 對于結構化數據，例如具有定義字段的表（tables with defined fields），我們使用關系數據庫，例如 MySQL 或 PostgreSQL。 如果我們的數據更靈活或更分層，像 MongoDB 或 Cassandra 這樣的 NoSQL 數據庫可能更合適（If our data is more flexible or hierarchical, NoSQL databases like MongoDB or Cassandra might be more suitable）。

我們的數據量也指導我們的選擇。 如果我們正在研究需要分布式存儲和快速處理的海量數據集，那么 Hadoop 的 HDFS 或 Google 的 Bigtable 等大數據解決方案就會發揮作用。 對于需要快速檢索的臨時或緩存數據，Redis 或 Memcached 等內存數據庫是理想的選擇。

當我們談論數據的壽命時，備份就變得至關重要。 定期備份數據可確保在發生故障或損壞時，我們不會丟失關鍵信息。 這些備份可以是增量備份（僅保存更改），也可以是完整備份（復制整個數據集）。

數據安全至關重要。 因此，我們確保靜態和傳輸過程中的加密。 加密會擾亂我們的數據，如果沒有正確的解密密鑰，數據將無法讀取，從而防止未經授權的訪問。

隨著我們的數據增長或用戶群在地理上變得更加多樣化，我們可能會使用分片或復制。 分片將我們的數據庫劃分為更小、更易于管理的部分，而復制則創建數據的副本以提高訪問速度和可靠性（As our data grows or our user base becomes more geographically diverse, we might use sharding or replication. Sharding divides our database into smaller, more manageable pieces, while replication creates copies of our data to improve access speed and reliability.）。

備份

備份是我們防止數據丟失的安全網（Backups are our safety net against data loss）。 通過定期在現場、異地或云平臺上復制和存儲我們的數據，我們確保始終能夠恢復重要信息。 根據我們的需要，這些備份可以是完整的，其中復制所有數據，也可以是增量的，僅捕獲自上次備份以來的更改。 這些備份的頻率、方法和存儲是根據數據的重要性和我們的恢復目標定制的。

分片和復制

為了處理大量數據或確保快速訪問（無論地理位置如何），我們使用分片和復制等策略。 分片將我們的數據分成塊，將它們分布在多個服務器上，確保我們的系統保持響應能力和可擴展性。 另一方面，復制涉及創建數據的副本。 這些副本可以服務讀取請求、平衡負載，并且還可以在主數據源遇到問題時充當故障安全裝置（and also act as a fail-safe in case the primary data source encounters issues）。

案例研究：具有運營管理的數據攝取管道 - Netflix

數據生成

Netflix 的媒體算法團隊對媒體文件（例如電影或節目）運行算法。 這些算法分析內容并生成數據，例如識別視頻中的對象。

數據存儲

生成的數據（稱為注釋）被存入 Marken 系統。 Marken 使用數據庫系統 Cassandra 以結構化方式存儲這些注釋（This generated data, referred to as annotations, is ingested into the Marken system. Marken stores these annotations in a structured manner using Cassandra, a database system.）。

數據更新

隨著算法的改進或變化，它們可能會為相同的媒體文件生成新的或不同的數據。 這意味著系統需要攝取更新的數據并以不與以前的數據沖突的方式對其進行管理。 它不是直接更新注釋（Instead of updating annotations directly），而是單獨管理不同的注釋集（或版本）（it manages different sets (or versions) of annotations separately）。 不直接更新先前運行的注釋的方法可確保效率、維護歷史數據并適應算法輸出的不可預測性。

數據檢索

ElasticSearch 是與 Cassandra 一起使用的另一個系統，有助于快速搜索和檢索提取的數據。 這對于向 Netflix 用戶提供實時推薦至關重要。

Marken架構

Marken 的架構旨在確保生成注釋的團隊或系統獨立于使用這些注釋的團隊或系統進行操作（Marken's architecture is designed to ensure that the teams or systems producing annotations operate independently of the teams or systems using those annotations.）。

Marken如何區分它們（How Marken separates them）：

• 不同的數據路徑（Different Data Paths）：生產者將數據放入Marken系統，消費者將數據取出。 他們使用單獨的工具（API）來完成這些任務，因此不會互相干擾。這里應該就是用不同的api
• 版本處理：生產者可以添加新的數據版本，而不會弄亂舊的版本。 消費者始終會看到最新版本，而不必擔心持續更新。
• 通過使用 ElasticSearch 進行搜索，消費者無需直接查詢主存儲 (Cassandra)。 這種分離可確保消費者的頻繁搜索不會影響主數據庫的性能或工作負載。