Apache Kafka 集群類型的部署策略

組織開始他們的數據串流採用時，會使用一個 Apache Kafka 集群來部署第一個用例。對於全組織範圍的數據治理和安全需求，但不同的服務水平協議、延遲和基礎設施要求則引入了新的 Kafka 集群。多個 Kafka 集群是常態，而非例外。用例包括混合整合、聚合、遷移和災難恢復。這篇博客文章探討了不同行業中 Kafka 部署的實際成功案例和集群策略。

Apache Kafka：事件驅動架構和數據串流的事實標準

Apache Kafka 是一個開源的分佈式事件串流平台，旨在實現高吞吐量、低延遲的數據處理。它允許您實時發布、訂閱、存儲和處理記錄流。

Kafka 是一個 流行的選擇 用於構建實時數據管道和流處理應用。Kafka 協議已成為 事件流處理的事實標準，適用於各種框架、解決方案和雲服務。它支持操作和分析工作負載，具備持久存儲、可擴展性和容錯性等功能。Kafka 包括像 Kafka Connect 用於集成和 Kafka Streams 用於流處理的組件，使其成為各種數據驅動用例的多功能工具。

雖然 Kafka 以實時用例而聞名，但許多項目利用這個數據流平台來實現整個企業架構中的數據一致性，包括數據庫、數據湖、舊系統、開放 API 以及雲原生應用程序。

不同的 Apache Kafka 叢集類型

Kafka 是一個分佈式系統。生產環境通常至少需要四個代理。因此，大多數人自動認為您只需要一個分佈式叢集，當您增加吞吐量和用例時進行擴展。這在一開始並沒有錯。但是…

一個 Kafka 叢集 並不是 每個用例的正確答案。各種特性影響著 Kafka 叢集的架構：

• 可用性：零停機時間？99.99% 的正常運行時間 SLA？非關鍵的分析？
• 延遲：端到端處理時間是否在<100毫秒內（包括處理）？10分鐘的端到端數據倉庫管道？歷史事件的重處理是否可以進行時間旅行？
• 成本：價值與成本的關係？總擁有成本（TCO）是否重要？例如，在公共雲中，網絡費用可能佔總Kafka成本的80%！
• 安全性與數據隱私：數據隱私（PCI數據、GDPR等）？數據治理與合規性？屬性層級的端到端加密？自帶密鑰？公共訪問與數據共享？隔離的邊緣環境？
• 吞吐量與數據大小：關鍵交易（通常是低量）？大數據源（點擊流、物聯網傳感器、安全日誌等）？

相關主題，如本地部署與公共雲、區域與全球，以及許多其他需求也會影響Kafka架構。

Apache Kafka集群策略與架構

單一的Kafka集群通常是您數據流媒體旅程的正確起點。它可以從不同的業務領域引入多個用例，並以每秒處理數GB的速度運行（如果以正確的方式操作和擴展）。

但是，根據您的項目需求，您需要一個具有多個Kafka集群的企業架構。以下是一些常見示例：

• 混合架構: 在多個數據中心之間進行數據集成和單向或雙向數據同步。通常是在自建數據中心和公共雲服務提供商之間建立連接。將遺留系統轉移到雲端分析是其中最常見的情況之一。但也可能進行命令和控制通信，即將決策/建議/交易發送到區域環境中（例如，在主機中存儲來自移動應用的付款或訂單）。
• 多區域/多雲端: 出於合規、成本或數據隱私原因進行數據複製。數據共享通常僅包括部分事件，而非所有Kafka主題。醫療保健是許多行業中採取這一方向的其中之一。
• 災害恢復: 在不同數據中心或雲區域之間以主動-主動或主動-被動模式複製關鍵數據。包括故障切換和回退機制的策略和工具，以確保業務連續性和合規性。
• 聚合: 用於本地處理（例如預處理、流式ETL、流處理業務應用）的區域集群，並將經過整理的數據複製到大數據中心或雲中心。零售店是一個很好的例子。
• 遷移: 通過從自建數據中心轉移到雲端或從自管理的開源遷移到完全管理的SaaS來進行IT現代化。在業務在切換期間持續運作的情況下，這些遷移可以在零停機或數據丟失的情況下完成。
• 邊緣（斷開連接/空氣隔離）：安全性、成本或延遲要求邊緣部署，例如在工廠或零售店。一些行業在安全關鍵環境中部署，使用單向硬體閘道和數據二極管。
• 單一代理：不具彈性，但足以應對如將Kafka代理嵌入機器或工業電腦（IPC）並將聚合數據複製到大型雲端分析Kafka集群等場景。一個很好的例子是在戰場上士兵的電腦上安裝數據流（包括集成和處理）。

橋接混合Kafka集群

這些選項可以組合。例如，邊緣的單一代理通常會將一些精選數據複製到遠端數據中心。混合集群根據如何橋接而具有不同的架構：通過公共互聯網、私人連接、VPC對等、傳輸閘道等。

看過Confluent Cloud這幾年的發展後，我低估了在安全性和連接性上需要花費多少工程時間。然而，缺失的安全橋接是採用Kafka雲服務的主要障礙。因此，除了公共互聯網之外，提供各種Kafka集群之間的安全橋接是不可避免的。

有些使用案例中，組織需要將數據從數據中心複製到雲端，但雲端服務 不允許主動發起連接。Confluent 為此類安全需求構建了一個特定功能，「源主動鏈接」，在這種情況下，源（即本地 Kafka 集群）始終主動發起連接——即使雲端 Kafka 集群正在消耗數據：

來源：Confluent

如您所見，這樣的情況迅速變得複雜。從一開始就找對專家來幫助您，而不是在您已經部署了第一個集群和應用程序之後。

很久以前，我已經在詳細的演示中描述了 分散式、混合式、邊緣和全球 Apache Kafka 部署的架構模式。查看那個幻燈片和視頻錄製以獲取有關部署選項和權衡的更多詳細信息。

RPO 與 RTO = 數據損失與停機時間

RPO 和 RTO 是您在決定 Kafka 集群策略之前需要討論的兩個關鍵 KPI：

• RPO（恢復點目標）是以時間為度量的最大可接受數據損失量，指示應該多頻繁進行備份以最小化數據損失。
• RTO (Recovery Time Objective)是業務中斷後恢復業務運作所需的最長時間。它們一起幫助組織規劃其數據備份和災難恢復策略，以平衡成本和運營影響。

雖然人們通常以RPO = 0和RTO = 0為目標開始，但很快就會意識到實現這一目標是多麼困難（但並非不可能）。您需要決定在災難中可以損失多少數據。如果發生災難，您需要一個災難恢復計劃。法律和合規團隊將告訴您在災難情況下能否損失一些數據集。在評估Kafka集群策略時，需要討論這些以及許多其他挑戰。

使用MIrrorMaker或Cluster Linking等工具在Kafka集群之間進行複製是異步進行的，因此RPO > 0。只有拉伸的Kafka集群提供RPO = 0。

拉伸的Kafka集群：通過數據中心之間的同步複製實現零數據損失

大多數部署多個Kafka集群的情況下，使用MIrrorMaker或Confluent Cluster Linking等工具在數據中心或雲端之間進行異步複製。這對於大多數用例來說已經足夠了。但是在災難發生時，您將損失一些消息。RPO > 0。

拉伸的Kafka集群在三個數據中心部署一個Kafka代理（而不是單個集群），複製是同步的（因為這是Kafka在單個集群內複製數據的方式），並保證零數據損失（RPO = 0） – 即使在災難發生時也是如此！

為什麼不應該總是使用拉伸集群？

• 低延遲（<~50ms）和穩定的連接在數據中心之間是必需的。
• 需要三個 (!) 數據中心；兩個是不夠的，因為大多數（法定人數）必須確認寫入和讀取，以確保系統的可靠性。
• 它們的設置、操作和監控都很困難，比在一個數據中心運行的集群要困難得多。
• 在許多使用案例中，成本與價值不成比例； 在真正的災難中，大多數組織和使用案例面臨的問題比丟失幾條消息（即使是像支付或訂單這樣的關鍵數據）要大得多。

為了澄清，在公共雲中，一個區域通常有三個數據中心（= 可用性區域）。因此，在雲中，是否將一個雲區域視為擴展集群取決於你的服務水平協議（SLA）。大多數SaaS Kafka提供在這裡部署於擴展集群中。

然而，許多合規性場景確實不認為在一個雲區域內的Kafka集群足以保證SLA和業務連續性，如果發生災難。

Confluent構建了一個專門的產品來解決（部分）這些挑戰：多區域集群（MRC）。它提供在擴展Kafka集群內進行同步和異步複製的能力。

例如，在金融服務場景中，MRC 同步複製低量關鍵交易，但異步複製高量日誌：

• 「支付」交易從美國東部和西部進入，實現完全同步複製
• 「日誌」和「位置」信息在同一集群中使用異步 – 優化延遲
• 自動災難恢復（零停機，零數據丟失）

有關延展型 Kafka 集群與兩個 Kafka 集群之間的主動-主動/主動-被動複製的更多細節，請參見我的 全球 Kafka 演示文稿。

Kafka 雲端產品的定價（與自我管理相比）

上述部分解釋了為什麼需要根據項目需求考慮不同的 Kafka 架構。自我管理的 Kafka 集群可以根據需要進行配置。在公共雲中，完全管理的產品看起來有所不同（與任何其他完全管理的 SaaS 一樣）。定價不同，因為 SaaS 供應商需要配置合理的限制。供應商必須提供特定的服務級別協議（SLA）。

數據流媒體格局包括各種 Kafka 雲端產品。以下是 Confluent 當前雲端產品的示例，包括多租戶和專用環境，具有不同的 SLA、安全功能和成本模型。

來源：Confluent

確保評估和了解來自不同供應商在公共雲中提供的各種集群類型，包括總擁有成本（TCO）、提供的正常運行時間服務水平協議（SLA）、跨區域或雲供應商的複製成本等。這些差距和限制通常會在細節中故意隱藏。

例如，如果您使用亞馬遜托管的 Apache Kafka 流媒體（MSK），您應該知道條款和條件中規定「服務承諾不適用於任何因基礎的 Apache Kafka 或 Apache Zookeeper 引擎軟件造成的不可用、暫停或終止…導致請求失敗的情況。」

然而，定價和支持 SLA 只是比較的一個關鍵部分。在評估數據流媒體平台時，您必須做出許多「建立與購買」的決策。

Kafka 存儲：分層存儲和冰山表格格式以僅存儲一次數據

Apache Kafka 增加了 分層儲存以分離計算和儲存。這一功能使企業架構更具可擴展性、可靠性和成本效益。Kafka 的分層儲存使一種新的 Kafka 集群類型成為可能：以成本效益的方式在 Kafka 提交日誌中儲存數PB的數據（就像在數據湖中那樣），帶有時間戳和保證排序，以便回溯重新處理歷史數據。KOR Financial 是使用 Apache Kafka 作為長期持久性數據庫的良好範例。

Kafka 使得左移架構成為可能，僅需一次儲存操作和分析數據集：

考慮到這一點，請再次思考我之前描述的多個 Kafka 集群的用例。您是否仍然應該在數據庫、數據湖或湖屋中將數據從一個數據中心或雲區域批量複製到另一個數據中心或雲區域？ 不。您應該實時同步數據，僅儲存一次數據（通常在像 Amazon S3 這樣的物件存儲中），然後將所有分析引擎（如 Snowflake、Databricks、Amazon Athena、Google Cloud BigQuery 等）連接到這一標準表格格式。

多個 Kafka 集群的現實成功案例

大多數組織都有多個 Kafka 集群。本節將探索來自不同產業的四個成功案例：

• Paypal（金融服務）–美國：即時支付，欺詐預防。
• JioCinema（電信/媒體） – APAC：數據整合，點擊流分析，廣告，個性化。
• Audi（汽車/製造業） – EMEA：連接車輛，具有關鍵和分析需求。
• New Relic（軟件/雲端） – 美國：全球的可觀察性和應用程序性能管理（APM）。

Paypal：按安全區域分隔

PayPal是一個數字支付平台，允許用戶在全球範圍內安全便捷地以實時方式發送和接收資金。這需要一個可擴展、安全和合規的Kafka基礎架構。

在2022年黑色星期五期間，Kafka流量峰值達到每天約1.3萬億條消息。目前，PayPal擁有85個以上的Kafka集群，每個假期季他們都會擴展他們的Kafka基礎架構以應對流量激增。Kafka平台繼續無縫擴展以支持這種流量增長，而不對他們的業務造成任何影響。

如今，PayPal的Kafka集群擁有超過1,500個代理人，主機超過20,000個主題。事件在集群之間進行複製，提供99.99%的可用性。

Kafka集群部署在數據中心內的不同安全區域中：

來源：Paypal

Kafka 集群根據數據分類和業務需求，部署在這些安全區域內。使用實時複製工具，如 MirrorMaker（在此範例中，運行於 Kafka Connect 基礎設施上）或 Confluent Cluster Linking（使用更簡單且不易出錯的方法，直接利用 Kafka 協議進行複製）來鏡像數據於數據中心之間，這有助於災難恢復並實現跨安全區域的通信。

JioCinema：按使用案例和服務水平協議分隔

JioCinema 是印度一個快速增長的視頻串流平台。該電信 OTT 服務以其豐富的內容提供而聞名，包括印度超級聯賽（IPL）等現場體育賽事、新推出的動漫中心，以及涵蓋巴黎 2024 奧運會等重大事件的全面計劃。

數據架構利用 Apache Kafka、Flink 和 Spark 進行數據處理，如在 2024 年班加羅爾 Kafka 峰會上所展示：

來源：JioCinema

數據流在各種用例中扮演著至關重要的角色，以轉化用戶體驗和內容傳遞。每秒超過一千萬條消息可增強分析、用戶洞察和內容傳遞機制。

JioCinema的用例包括：

• 服務間通信
• 點擊流/分析
• 廣告追踪器
• 機器學習和個性化

JioCinema的數據平台、分析和消費主管Kushal Khandelwal解釋道，並非所有數據都相同，不同用例的優先順序和服務等級協議有所不同：

來源：JioCinema

數據流是一場旅程。與全球許多其他組織一樣，JioCinema從一個大型Kafka集群開始，使用1000多個Kafka主題和10萬多個Kafka分區來應對各種用例。隨著時間的推移，關於用例和服務等級協議的關注點分離演變為多個Kafka集群：

來源：JioCinema

JioCinema的成功故事展示了數據流媒體組織的共同演變。現在讓我們探索另一個例子，其中從一開始就為一個用例部署了兩個非常不同的Kafka集群。

Audi：面向連接汽車的運營與分析

汽車製造商Audi提供功能齊全的連接汽車，具有集成互聯網連接和智能系統的先進技術。Audi的汽車支持實時導航、遠程診斷和增強車內娛樂。這些車輛配備了Audi Connect服務。功能包括緊急呼叫、在線交通信息和與智能家居設備的集成，以增強駕駛員的便利和安全。

來源：Audi

Audi在2018年Kafka峰會的主題演講中展示了其連接汽車架構。Audi企業架構依賴於兩個具有非常不同SLA和用例的Kafka集群。

來源：Audi

數據攝取Kafka叢集非常重要。它需要24/7運行以應對大規模需求。它為數百萬輛汽車提供最後一公里的連接，使用Kafka和MQTT。IT方面與車輛之間的反向通道有助於服務通信和空中更新（OTA）。

ACDC雲是奧迪連接汽車架構的分析Kafka叢集。該叢集是許多分析工作負載的基礎，能夠以Apache Spark等批處理框架處理大量的物聯網和日誌數據。

這一架構早在2018年就已經提出。奧迪的標語“通過技術實現進步”顯示了該公司在大多數汽車製造商部署類似場景之前，如何應用新技術進行創新。來自連接汽車的所有傳感器數據均以實時方式處理並存儲以供歷史分析和報告。

New Relic：全球多雲可觀察性

New Relic是一個基於雲的可觀察性平台，為全球客戶提供應用程序和基礎設施的實時性能監控和分析。

New Relic的軟件工程副總裁Andrew Hartnett解釋了數據流對New Relic整個商業模型的重要性：

“Kafka 是我們的中央神經系統。它是我們所做的一切的一部分。在我們公司，來自 110 個不同工程團隊的數百個服務以某種方式與 Kafka 互動，因此它確實是關鍵任務。我們所尋求的是增長的能力，而 Confluent Cloud 提供了這一點。

New Relic 每分鐘吸收高達 70 億個數據點，並有望在 2023 年吸收 2.5 艾字節的數據。隨著 New Relic 擴展其多雲策略，團隊將使用 Confluent Cloud 以便在所有環境中獲得單一的全景視圖。

“New Relic 是多雲的。我們希望在客戶所在的地方。我們希望在那些相同的環境中，在那些相同的地區，我們希望在那裡有我們的 Kafka。”Artnett 在 Confluent 的案例研究中表示。

多個 Kafka 叢集是常態，而非例外

事件驅動架構和 流處理 已存在數十年。隨著 Apache Kafka 和 Flink 等開源框架與完全管理的雲服務的結合，採用率不斷增長。越來越多的組織在其 Kafka 擴展方面面臨挑戰。企業級數據治理、卓越中心、部署和運營自動化，以及企業架構最佳實踐，有助於成功提供多個 Kafka 叢集的數據流，以滿足獨立或協作的業務領域的需求。”

多個 Kafka 集群是常態，而非例外。混合整合、災難恢復、遷移或聚合等用例讓即時數據流在各處實現所需的 SLA。