實時流處理新選擇:LinkedIn重磅發佈Samza 1.0

AI前線導讀:近日,LinkedIn正式發佈了開源流式計算框架Samza的1.0版本。實時攝取和處理大量數據的能力對於越來越多的企業來說是一件非常有趣的事情。這是一個快速增長的領域,因爲這些應用場景可以直接轉化爲商業利益。我們已經關注這個領域很長時間了,Apache Samza 1.0的發佈是一個重新審視它的機會,我們拭目以待它將給這個領域帶來哪些改變。

生於LinkedIn

Apache Samza於2013年在LinkedIn誕生,並於2014年成爲Apache的頂級項目。現在,LinkedIn有3000多個應用程序在使用它,用它來進行異常檢測、欺詐檢測、監控性能、通知、實時分析,等等。

如果你對這個領域有一定了解的話,那麼你該知道,Apache Kafka是另一個主要的實時數據處理框架,它最初也是由LinkedIn開發的。Kafka成爲LinkedIn跟蹤數據的標準傳輸機制,並且每天都會向Kafka生成大量數據,應用程序從Kafka中獲取洞見。

這些應用程序在消費Kafka的消息時需要處理一些常見的問題,例如檢查點、本地狀態管理、處理故障、伸縮處理,等等。Apache Samza就是爲解決流式處理中的這些問題而構建的。但問題是,這在過去可能是有意義的,但在今天還是這樣的嗎?

這聽起來是一個奇怪的問題。畢竟,數據仍然在源源不斷地流入,而且還在不斷增加。不同之處在於,還有很多其他框架被構建用於滿足完全相同的需求:Apex、Flink、Spark和Storm(這些還只是Apache的開源項目,當然還有其他一些專有的解決方案)。

image

LinkedIn Samza團隊負責人Samarth Shetty表示,當他們開始接觸流式處理時,已有的流式處理框架很少能夠幫助他們應對LinkedIn的規模或技術問題。因此,他們認爲最好的辦法是開發自己的框架:

“我們必須在Samza中加入增量快照和主機粘性(Host Affinity)等功能。當時的Apache Flink等框架還沒有提供這些功能。Kafka Streams非常適合用於處理Kafka中的事件,但在LinkedIn,我們需要處理來自不同系統的事件,例如Azure EventHubs、AWS Kinesis等。

Samza提供了輕鬆連接到不同系統的能力。流式處理是LinkedIn的一個非常重要的應用場景,因此,我們致力於構建一個最好的框架。隨着時間的推移,我們相信我們已經開發出了最先進的流式處理框架之一,最適合用來滿足LinkedIn規模的處理需求。”

在某種程度上,這有點類似於機器學習領域的框架格局:有很多可用的框架,該如何選擇?當然,有選擇並不是件壞事,但“很多”和“太多”之間存在着一個界限。Facebook PyTorch團隊負責人Soumith Chintala也表達了類似的觀點:我們想要一些對我們來說有用的東西,所以我們決定自己去構建。

兼容Beam

然而,與Kafka和Confluent不同的時,Samza並沒有發展成爲擁有獨立供應商的產品。Shetty說,LinkedIn有一羣工程師致力於從事流式處理開發工作,而Samza是這些工作不可或缺的一部分。他又補充說,他們並沒有將Samza看成是一個產品:

“我們將其視爲一個開源項目。LinkedIn一直以來都是以這種方式參與開源的——當我們認爲我們構建的工具也能爲其他公司帶來價值時,那麼在可能的情況下,我們希望將它們交給社區。

雖然目前沒有與Samza掛鉤的供應商,但包括Slack、TripAdvisor、Redfin和Optimizely在內的多家公司正在生產環境中使用它。我們認爲,能夠吸引其他組織使用Samza的一個事實是,它已經經過大規模的實戰考驗,因爲LinkedIn就在使用它。”

我們知道,Apex背後的供應商DataTorrent最近破產了。或許在這個時候,這個領域沒有足夠的空間容納更多的開放核心的流式處理平臺供應商。所以,如果你想要使用Samza,必須想清楚,並自己想辦法在生產環境中運行它,即使是最新的1.0版本也是這樣。不過,在其他方面倒是發生了一些變化,可能會帶來更廣泛的影響。

Samza提供了一組新的API,與Apache Beam兼容。Apache Beam是一個開源項目,提供了一組統一的API,用於跨執行引擎移植處理管道,包括Samza、Spark和Flink。Beam還支持使用其他編程語言進行數據處理,包括數據科學領域的寵兒——Python。

image

在某種程度上,Samza團隊已經意識到,雖然穩定性和性能是Samza的核心優勢,但它的編程API卻相當低級。Samza提供了一組簡單的基於回調的API,可用於指定消息級別的操作。

開發人員必須基於這組API自行實現複雜的操作,如窗口操作和連接操作。此外,需要使用Kafka主題將多個Samza作業連接在一起,這使得構建應用程序非常耗時且容易出錯。

Samza 1.0提供了一組高級API,開發人員可以通過組合多個運算符來構建複雜的數據管道。但Samza團隊不滿足於此,他們又向前邁進了一步,讓他們的API與Apache Beam兼容。

也就是說,現在可以使用Java、Scala或Python在Beam上開發流式應用程序,並且可以將它們移植到支持它們的框架中,甚至可以在Google Cloud Dataflow上運行它們——至少在理論上是這樣的。

Flink和Spark都提供了Beam API之外的專有擴展,而Spark創建者對支持Beam並不是很感興趣。Spark對Beam的支持主要是由社區提供的。

SQL和DevOps

但這些並非Samza 1.0的全部,因爲它還帶來了一些更重要的新功能:SQL和DevOps改進。Samza團隊意識到,即使他們的API得到了升級,但並非所有人都喜歡使用API。非工程師更願意通過SQL訪問數據,而Samza正在提供這樣的功能。

我們說“正在”,是因爲從技術層面看是可以實現SQL功能,但仍然需要通過API調用來使用這個功能。這種使用方式違背了降低使用門檻的目標,但Shetty指出,他們也正在爲SQL創建交互式的shell。SQL已經成爲流式處理的香饃饃——Kafka、Flink和Spark都支持SQL。

image

Samza 1.0的另一個改進方面是集羣管理器的獨立性。在Samza 1.0之前,Samza需要藉助YARN進行資源管理和應用程序的分佈式執行。雖然使用YARN沒有什麼問題,但用戶希望能夠靈活地在任意環境中運行流式處理。Samza 1.0通過提供獨立運行模式來解決這個問題。

這種模式允許將Samza作爲庫嵌入到應用程序中,並在任意資源管理器中運行。但還存在幾個問題:獨立模式還不支持像窗口和連接這樣的有狀態流式處理,並且對Kubernetes的支持還不夠。Samza團隊正在努力解決這些問題。Samza 1.0還支持表和流的連接,並改進了Samza應用程序的可測試性。

Samza 1.0帶來了巨大的改進。它背後的團隊似乎意識到它的短板,並努力解決這些問題。他們也意識到了它的優勢,例如Samza在一臺機器上每秒可以處理120萬條消息。

但問題是你應不應該使用它?如果你確信自己可以搭建、開發、部署和維護它,那麼絕對值得一試。

但無論你是否會使用它,Samza 1.0都是一個重要的里程碑。因爲在Apache Beam似乎陷入僵局的時候,Samza拉了它一把。並非每家公司都會像LinkedIn那樣,並非每家公司都有建立和維護自己的框架的必要。但在目前看來,基於Beam進行開發似乎是可移植性方面的最佳選擇。

Samza 1.0發佈詳細公告:

https://engineering.linkedin.com/blog/2018/11/samza-1-0--stream-processing-at-massive-scale

英文原文:

https://www.zdnet.com/article/real-time-data-processing-just-got-more-options-linkedin-releases-apache-samza-1-0-streaming/

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章