當高層管理人員評估新技術時,他們從不同于中層管理層、架構師或數據工程師的角度看待新技術。高層管理人員不只是查看基準和功能列表;而是查看基準和功能列表。他們正在尋找長期生存能力,以及如何給他們的公司一個明確的競爭優勢。此外,他們還在優化上市時間和成本。

作為大數據研究所的總經理,技術評估是我角色的關鍵部分。我們幫助公司確定并采用最佳技術以滿足其業務需求。我們的客戶特別欣賞我們的供應商中立方法。

在這篇文章中,我比較阿帕奇·普爾薩爾和阿帕奇·卡夫卡從CTO的角度。我們不會在真空中進行這種比較,因為我們不應該在不使用用例的情況下做出技術選擇。相反,我們將通過一些實際和常見的用例來查看每種技術,包括簡單的消息傳遞用例、復雜的消息傳遞用例和高級消息傳遞用例。這將使我們能夠更好地了解脈沖星和卡夫卡的權衡。

簡單消息公司

讓我們想象一下,我們公司需要一個簡單的消息系統。它接收從點 A 到 B 的消息,我們不會執行任何復制。新的消息傳遞技術是我們公司首次進軍郵件系統。

數據架構師告訴我們,對于這個用例,Pulsar 和 Kafka 之間沒有任何明顯的優勢。他們做了功課,對商業案例有深刻的了解。團隊不相信在不久的將來,用例會有增長。

對于這樣的簡單消息傳遞用例,我同意每個系統的優缺點是平衡的。從純技術的角度來看,這兩種技術之間的決策是一種紐帶,因此比較就變成了成本。操作費用是多少?培訓我的員工要花多少錢?我會考慮使用卡夫卡或 Pulsar 的 “作為服務” 提供商之一開始比較成本。在此階段,為所選消息平臺利用”作為服務”提供商將降低運營成本和群集操作培訓員工的成本。對于 Kafka,我使用KafkaAPI (Azure) 查看匯流Event Hubs、MSK (AWS)或事件中心。對于脈沖星,我正在尋找流云。

決定

我們對沖我們的賭注,讓團隊使用卡夫卡API。有幾個不同的技術,支持使用卡夫卡的API或線路協議與不是卡夫卡的代理 例如,Pulsar 可以通過重新編譯與 Pulsar 的符合 Kafka 的 API 或與讀取 Kafka 的線路協議 (KoP) 的 Pulsar 用作卡夫卡的后端。

我們創建單位成本比較,并符合最具成本效益的比較。使用 Kafka API 對沖我們的投注,允許我們通過 QA 重新認證在后端之間移動。它使我們免受社區/技術的影響,因為技術不再受歡迎或不再受支持。

復雜消息公司

讓我們想象一下,我們公司需要復雜的消息傳遞。我們需要異地復制,因為我們在世界各地都有數據。我們一直在使用消息傳遞系統,并且通常熟悉實時系統的復雜性。我們看到我們當前消息傳遞系統的局限性,我們想要一些可以處理高級消息傳遞和其他復雜消息傳遞功能的東西。

數據架構師告訴我們每種技術都有自己的優勢。他們已與所有利益相關者和業務方溝通,了解當前和未來的需求,并相信未來的用例和數據量會隨著時間的推移而增長。

在這種情況下,我們在普爾薩爾和卡夫卡之間沒有明確的贏家。我們必須更深入地挖掘用例的各個方面,以做出正確的決策。

異地復制

當我們與 Kafka 供應商談論我們的異地復制需求時,我們發現它們是專有的(昂貴的)或開源的(已安裝)。專有復制解決方案成本高昂,并且是內置的。開源解決方案 (MirrorMaker) 實際上是一個數據復制解決方案,并且由于它不是內置的,因此會產生操作開銷。

當我們與 Pulsar 供應商討論異地復制時,我們發現它是內置的開源,并支持復雜的復制策略。我們知道,隨著復制策略變得越來越復雜,Pulsar 已經支持高級復制策略。

我們決定Pulsar是異地復制的贏家。

復雜消息傳遞

作為我們轉向新消息傳遞平臺的一部分,我們希望處理新的用例。數據架構師一直努力尋找和理解它們。在當前系統中,任何處理錯誤都可以通過重新生成消息來手動重試。我們還需要一種方法來延遲消息的發送。最后,當前系統缺乏強大的架構實施,我們體驗到具有不同架構實現的不同團隊的痛苦。

我們從看卡夫卡開始。我們看到 Kafka 缺少內置的死信隊列,任何消息處理失敗必須手動或以編程方式重試。它缺乏任何延遲發送消息的內置機制,這必須用大量解決方法完成。此外,Kafka 缺乏內置的架構執行機制。因此,有來自其他供應商的架構注冊表的許多不同的實現 它有一個內置的死信隊列。如果消息無法以負確認處理,Pulsar 可以自動重試該消息一定次。Pulsar 還有一個內置機制,可以延遲消息發送一定的時間。Pulsar 認為架構是一流的公民,并且具有內置的架構注冊表。架構的 API 支持也是內置的。

我們決定Pulsar是復雜消息的贏家。

高級消息傳遞

隨著我們更深入地了解體系結構,我們發現我們關于同一主題的數據需要循環傳遞,以便使用甚至資源,并訂購以進行訂購保證。

我們看到,Kafka 不支持更改數據交付給消費者。一旦制作人對主題發出消息,就無法更改該主題。額外的主題迫使我們將數據重復為兩個主題,并處理操作問題?;蛘?,我們必須讓所有消費者被訂購,并過度提供消費者的循環,以跟上。

查看 Pulsar,我們看到它支持在有序和循環中提供同一主題的數據,因為代理具有更智能的路由。Pulsar的經紀人允許我們做我們想做的事,沒有解決方法。

我們決定Pulsar是高級信息傳遞的贏家。

部署和社區

為了總結我們的比較,我們必須比較Pulsar和Kafka的部署數量和整個社區。

從競爭格局來看,我們看到卡夫卡的供應商支持更多,越來越多的公司正在銷售和支持卡夫卡產品。當我們看到開源社區,我們看到卡夫卡和普爾薩爾都有一個充滿活力的社區;然而,卡夫卡有一個更大的社區。

當我們看到大規模使用卡夫卡和Pulsar的公司時,我們看到這兩種技術都在與大型生產公司大規模使用??ǚ蚩〒碛懈嗟墓臼褂盟谏a。

從培訓的角度來看,有更多的人具有卡夫卡的經驗;然而,數據工程團隊認為,一個卡夫卡技能的人可以毫不費力地學習脈沖星。

我們決定卡夫卡在支持和社區方面是明顯的贏家, 普爾薩爾正在升溫。

決定

此用例的決策并不容易,因為每種技術都有明顯的優缺點。

Pulsar 有辦法趕上社區和部署,卡夫卡有辦法趕上功能。

要開始討論,我們需要了解公司最看重的技術。我們是在技術采用上非常保守, 還是不那么保守?我們過去可能運氣很好, 采用新的開源技術, 這將激勵我們使用 Pulsar 即使為異地復制許可證支付了大量資金,用例也可能無法實現。團隊最終可能會花費大量時間,甚至數月時間,編寫、完善和測試他們的解決方法。

如果我們選擇Pulsar,我們可以回到商業贊助商,并說我們可以處理一切。團隊將花更少的時間來實現,因為所有功能都已經在那里進行了測試。

在這種情況下,我們不能用Pulsar后端對沖卡夫卡API的賭注,因為Kafka API沒有我們需要的額外功能。我們必須使用Pulsar API的一切或為卡夫卡制定許多解決方法。

我們的決定:選擇 Pulsar,優先處理業務請求,將團隊重點放在編寫代碼上,而不是解決方法上。我們選擇 Pulsar 并關注社區和供應商的景觀。

我們保守的決定:我們選擇卡夫卡,并接受我們可能無法實現一些用例。對于我們可以近似的用例,我們采用解決方法。我們回顧我們的項目時間表,為預期的解決方法添加更多時間。我們咨詢我們的運營團隊,以確保能夠處理這些變通辦法將帶來的額外操作開銷。

高級消息公司

讓我們想象一下,我們公司已經在使用各種消息傳遞和排隊系統。從操作、體系結構和開銷的角度來看,我們有必要移動到單個系統。此外,我們希望降低運營成本。

數據架構師告訴我們,卡夫卡和Pulsar對于這個用例都有自己的優勢。建筑師已經和所有利益相關者和業務方面交談,以了解當前和未來的愿望。

排隊和消息傳遞

我們痛苦的核心部分存在于我們的兔子MQ系統中。我們通過系統推送了太多的消息,RabbitMQ 無法滿足需求。我們已經使用 RabbitMQ 代碼做了幾種解決方法來緩沖內存中的消息,并且我們不斷支持新的群集來處理負載。我們需要一個系統,可以處理我們需要通過它發送的消息的規模,而不是做解決方法。

當數據架構師處理用例時,他們看到了消息傳遞和排隊需求。對 RabbitMQ 風格的工作需求不會消失,我們需要更好的消息傳遞技術。

Kafka 適用于消息傳遞,可以處理規模,但它不解決排隊端問題。團隊可以進行一些解決方法,但它們使我們無法實現我們所期望的單一系統目標。要處理排隊用例,我們需要一個 Kafka 群集和 RabbitMQ 群集。Kafka 群集將充當更多的緩沖區,以防止 RabbitMQ 群集超載,但 Kafka 缺乏對 RabbitMQ 的內置支持,我們必須與供應商合作或編寫自己的代碼在 Kafka 和 RabbitMQ 之間移動數據 Pulsar 將允許將所有消息傳遞和排隊用例合并到一個群集中。我們還可以選擇繼續使用 RabbitMQ 代碼。在Pulsar和 StreamNative 中還有一個 RabbitMQ 連接器,該處理程序可以直接插入代理,并且是 Apache 許可的。

如果我們不想重用 RabbitMQ 代碼,我們可以使用 Pulsar API,并具有相同的隊列樣式功能。根據代碼的考慮情況,這可能是一個簡單的更改,我們必須運行廣泛的QA。

我們決定Pulsar是排隊和消息傳遞的贏家。

高級保留

數據架構師分析了數據使用情況,發現 99.99% 的消息在第一次使用后未讀取。然而,他們決定保持保守,并保留七天的信息。即使我們存儲了七天的數據,我們也不希望我們的運營成本爆炸。分層存儲使我們能夠通過本地保存一些數據以及將其他數據卸載到 S3 以節省長期保留成本來更好地管理成本。

Kafka 正在開發分層存儲,但 Apache Kafka 項目尚未發布此新功能。有些供應商以封閉源提供此服務,但我們不確定其是否已做好生產準備。

在 Pulsar 中,支持分層存儲,并且已有一段時間了。該功能已做好生產準備,并且正在由公司用于生產。

我們決定Pulsar是分層存儲的贏家,卡夫卡趕上了。

路由主題

由于我們使用許多主題來分解數據,因此我們需要下一個系統來處理要創建的大量主題。我們的數據架構師認為,我們最初需要 100,000 個主題,并且隨著時間的推移,我們將增長到 500,000 個主題。

Kafka 群集受可創建的分區數限制,每個主題至少需要一個分區。正在努力支持更多關于卡夫卡的話題, 但這些努力尚未公布。此外,Kafka 缺少命名空間和多租戶,因此所有 100,000 個主題將在同一命名空間中放在一起,因為無法根據主題分段資源。

雖然一些公司利用多個 Kafka 群集來容納更多主題并劃分資源,但這種方法增加了成本并消除了僅使用單個群集的選項。

與脈沖星有數以百萬計的主題的支持。該功能已發布,并在生產中使用。為了降低操作開銷,Pulsar 支持命名空間和多租戶。這允許我們設置每個主題的資源配額。

我們決定Pulsar是主題上的明顯贏家。

路由

由于我們公司使用 RabbitMQ 的背景,我們的許多設計都圍繞著讓經紀人為我們路由到主題上 例如,我們有一個用于整個世界的主題,RabbitMQ 經紀商將該主題分解為每個國家/地區的主題。

數據架構師已經研究了他們如何使用一個主題為整個世界在每個系統中。他們發現,下游消費者的設計并不是要處理接收數據、去功能化數據、查看數據并扔掉數據增加的負載,因此需要付出太多的努力來改變每個下游系統。

我們開始研究卡夫卡,并看到一般的建議是把一切放在一個話題里。我們已經意識到,由于消費者在篩選和群集上的負載增加,這不起作用,我們開始研究解決方法。解決方法是通過水平縮放來讀取和處理全局主題,以增加使用者的數量。消費者的選擇是:編寫我們自己的自定義使用者/生產者,編寫 Kafka Streams 程序,或使用專有的 KSQL。

我們查看 Pulsar,看到它支持使用 Pulsar 函數或自定義使用者/生產者進行路由。我們將閱讀全局主題,將數據保存到單獨的國家/地區特定主題。通過單獨討論主題,消費者可以只訂閱他們需要的主題,并且只能接收相關信息。

我們決定Pulsar是路線上的明顯贏家。

決定

這個決定歸根結底是時間問題。我們有時間讓卡夫卡趕上普爾薩爾嗎?我們有時間讓數據工程師為 Kafka 實施解決方法嗎?等待將使公司因錯過機會和延遲新的用例而降低成本。這些等待可能會對業務產生直接影響。

我們的決定:我們和普爾薩爾一起去。

我們的決定與額外的時間:我們推遲我們的新架構。我們檢查卡夫卡在六個月內是否趕上了普爾薩爾。如果有,我們檢查是否有人在生產中運行這些新功能,以及他們對穩定性的表示。如果我們沒有看到卡夫卡的是正確的結果, 我們和普爾薩爾一起去。

結論性思考

嗯, 你已經走這么遠, 或者只是在這里瀏覽一下。上述每個示例都是我處理過的真實用例。希望遵循上述框架將幫助您根據用例進行更明智的技術評估。

Comments are closed.