來自 Confluent的Confluent Platform 3.0消息系統(tǒng)支持使用Kafka Streams實現(xiàn)實時的數(shù)據(jù)處理，這家公司也是在背后支撐Apache Kafka消息框架的公司，它近日宣布最新的開源平臺已經(jīng)達到了通用發(fā)布（general availability）版本。Confluent Platform可以圍繞Apache Kafka創(chuàng)建可擴展的數(shù)據(jù)平臺，Apache Kafka是一個實時的、分布式的、具有容錯功能的消息隊列，它能夠擴展至非常大量的消息。

Kafka Streams是進行數(shù)據(jù)實時處理的輕量級方案，可以用在欺詐和安全監(jiān)控、物聯(lián)網(wǎng)的（Internet of Things，IoT）操作和設備監(jiān)控。它為Kafka提供了一個新的、原生的流開發(fā)環(huán)境。開發(fā)人員能夠使用這個庫基于Kafka構(gòu)建分布式的流處理應用。Kafka涵蓋的功能是消息和數(shù)據(jù)傳輸，而Kafka Streams涵蓋的功能則是數(shù)據(jù)的處理。

Kafka Streams支持有狀態(tài)和無狀態(tài)的處理，同時還支持數(shù)據(jù)的分布式容錯處理。要使用Kafka Streams，并不需要單獨的集群、消息轉(zhuǎn)換層或外部依賴。它每次會處理一個事件，而不是小批量（micro-batch）的消息。它還允許數(shù)據(jù)的延遲抵達并支持windowing處理亂序的數(shù)據(jù)。

在最近的新聞中，Confluent還宣布了Confluent Control Center的發(fā)布，這是一個用于管理Kafka集群的商業(yè)產(chǎn)品。Confluent Control Center可以作為Confluent Enterprise 3.0的一部分來獲取，它的設計目的是幫助數(shù)據(jù)工程團隊操作組織中的Kafka。這個管理工具為運維人員和數(shù)據(jù)團隊提供了監(jiān)控Kafka系統(tǒng)不同組件的功能，這些組件包括主題、生產(chǎn)者和消費者，并且能夠理解數(shù)據(jù)管道中發(fā)生了什么狀況。

借助Control Center，運維人員能夠在消息級別檢查數(shù)據(jù)環(huán)境，從而能夠理解消息投遞情況、可能出現(xiàn)的瓶頸并且可以在原生的Kafka環(huán)境中觀察端到端的消息投遞。為了滿足特定的需求，Control Center UI允許運維人員連接新的數(shù)據(jù)源到集群上并配置新的數(shù)據(jù)源連接器。

如果你有興趣學習Control Center的更多知識，可以關(guān)注接下來的webinar。

InfoQ采訪到了來自Confluent的Joseph Adler（產(chǎn)品管理和數(shù)據(jù)科學主管）和Michael Noll（產(chǎn)品經(jīng)理）來進一步了解這些產(chǎn)品發(fā)布信息以及這些產(chǎn)品如何幫助開發(fā)人員和運維團隊。

InfoQ：Kafka Streams與其他的流數(shù)據(jù)處理框架如Storm、Spark Streaming和Apache Flink相比，其差異性是什么呢？

Joseph Adler & Michael Noll：在流處理框架方面，負責流處理的開發(fā)人員有很多不同的可選方案。事實上，其中很多方案已經(jīng)將Kafka用于在它們的流處理管道中了。Kafka Streams構(gòu)建在Apache Kafka堅實的技術(shù)基礎之上，從這里它繼承了Apache Kafka的可擴展性、彈性、容錯性以及很多其他的特性。我們相信Kafka Streams降低了進入流處理領域的門檻，因此能夠讓很多的公司從實時洞悉業(yè)務現(xiàn)狀中收益。Kafka Streams也繼承了Kafka的安全模型，也就是加密傳輸中的數(shù)據(jù)，這對像金融這樣的行業(yè)來說，是很好的選擇。

像Spark和Flink這樣的框架通常會用在中心數(shù)據(jù)工程團隊中，用于發(fā)揮大數(shù)據(jù)和數(shù)據(jù)倉庫設施的威力。它們的設計是“大型重量級（heavy lifting）”的——運行復雜的查詢，所消耗的時間能夠持續(xù)數(shù)小時甚至更長。

Kafka Streams適用于“快速的應用”或“流應用”——在這些應用中，產(chǎn)生響應的速度是非常重要的。輸出可能是購買決策、基于特定場景的報價或者安全告警。這些開發(fā)人員一般會位于某個業(yè)務處理的流水線之中。

借助Kafka Streams，對于實時處理這樣的需求，我們不必像已有的流處理框架那樣安裝和運維單獨的集群。很多人其實已經(jīng)使用Kafka從事一些實時的數(shù)據(jù)處理（如欺詐探測、用戶活動跟蹤或流量監(jiān)控）并將Kafka作為數(shù)據(jù)平臺中消息系統(tǒng)的基石，所以使用Kafka Streams來處理Kafka原生環(huán)境中所有的數(shù)據(jù)是很自然的選擇，這樣的話，就沒有必要新增另外的基礎設施和技術(shù)了，如果要新增技術(shù)的話，開發(fā)人員可能還需要對其理解、優(yōu)化并保證它的持續(xù)運行。

InfoQ：Flink在流數(shù)據(jù)的處理中，并沒有使用micro batch的方式，這與Kafka Streams的工作機制是類似的。Kafka Streams與Flink還有什么相似之處或差異嗎？

Adler & Noll： Kafka Streams學習了行業(yè)之前的經(jīng)驗，包括學術(shù)上的，也包括開源項目社區(qū)的，如Apache Samza。這說明在重要領域具有一定的相似性，比如恰當?shù)臅r間模型來區(qū)分事件時間與處理時間的語義，以及正確處理延遲到達、數(shù)據(jù)亂序的能力。這些特性對于任何實用的流處理用例都是必需的。

另外一個關(guān)鍵的差異在于Kafka Streams支持彈性，也就是說，可以動態(tài)地增加和收縮處理能力。例如，在Kafka Streams中，開始的時候，我們可以只有一臺機器運行流處理應用，用它來處理傳入的業(yè)務數(shù)據(jù)。當數(shù)據(jù)量增大，一臺機器的處理能力不足以應對的時候，那么就可以（在運行時操作，無需停機）在另外一臺機器上啟動相同的應用，它們會自動分擔工作內(nèi)容。

InfoQ：Kafka Streams支持Windowing功能。你們能更詳細地描述一下這個特性嗎，在實時數(shù)據(jù)處理中，它的作用是什么？

Adler & Noll： windowing允許我們將持續(xù)的數(shù)據(jù)流劃分為更小的塊（chunk）。這種windowing最為常見的是基于時間，比如基于五分鐘的間隔來執(zhí)行分析。對于很多的使用場景來說，windowing是非常重要的，比如欺詐檢測（“這個人在過去從來沒有在一個小時內(nèi)多次使用信用卡，但現(xiàn)在，我們在過去的五分鐘內(nèi)看到了五十筆交易——那么信用卡可能被盜了”）或者熱門話題（“在過去的24小時內(nèi)，Twitter的大多數(shù)用戶關(guān)注美國的總統(tǒng)大選、新的Apple MacBook以及Justin Bieber的最新視頻”）。

InfoQ：你們能闡述一下基于時間（Time）和基于會話（Session）的windowing方案的差別嗎，以及分別應該在何時使用它們？

Adler & Noll：比如說，基于時間的windowing會將流數(shù)據(jù)劃分為每隔五分鐘的數(shù)據(jù)塊?？梢詫⑵湎胂鬄橐粋€計數(shù)器：每隔五分鐘，你就會宣布“新窗口的數(shù)據(jù)！”有很多的使用場景都需要windowing功能，可能絕大多數(shù)都是基于時間的。

與之不同，如果是基于會話的windowing，那么它的范圍就不是嚴格的計時器規(guī)則了，這是為了將相關(guān)的事件分組到一個所謂的會話（session）中?？梢詫⑦@些會話視為一個階段內(nèi)的活動。使用基于會話windowing的一個常見使用場景就是分析用戶交互事件，例如理解用戶如何閱讀《金融時報》的Web站點以及如何與Facebook進行交互。

InfoQ：你們能介紹一下Kafka在安全方面所提供的功能嗎，這可能會涵蓋到對消息和主題的限制訪問以及跨Kafka服務器的加密數(shù)據(jù)傳輸？

Adler & Noll：在認證方面，Kafka支持SASL/Kerberos、SASL/PLAIN和SSL/TLS。而在授權(quán)方面，Kafka提供了ACL來控制對特定主題的讀取/寫入/管理訪問，該功能可以配置為針對認證用戶和特定的IP來進行。

傳輸中的數(shù)據(jù)可以使用SSL/TLS進行加密，它的加密發(fā)生在數(shù)據(jù)生產(chǎn)者到Kafka broker之間（服務器），從Kafka broker到數(shù)據(jù)消費者之間以及Kafka集群內(nèi)部broker之間的通信。

InfoQ：Kafka集群能否部署到Docker容器之中？是否有什么最佳實踐或在線資源，幫助開發(fā)人員進行這種集成？

Adler & Noll：是的，可以部署Kafka集群到Docker容器中。Confluent提供了實驗性的Docker鏡像來運行Confluent Platform，其中就包含了Apache Kafka。也就是說，運行基于Docker的Kafka環(huán)境依然還是一種例外的情況，而不是通用的規(guī)則。一方面這是因為相對來講，Docker還是較新的技術(shù)，尚沒有完全成熟。另一方面，在數(shù)據(jù)架構(gòu)中，Kafka的角色是存儲數(shù)據(jù)和提供數(shù)據(jù)服務，也就是說。它是“有狀態(tài)”的服務。Docker的哲學和最佳實踐是不要在容器內(nèi)運行有狀態(tài)的服務——它更適合沒有狀態(tài)的服務——因此，彌合這兩個稍微正交的方式需要一些特殊的考量。

InfoQ：在新特性和功能增強方面，Kafka有什么規(guī)劃？

Adler & Noll：在接下來的發(fā)布版本中，Apache Kafka社區(qū)規(guī)劃關(guān)注于運維的簡便性和更強的投遞可靠性。這部分工作包括Apache Kafka中改進的數(shù)據(jù)平衡、更多的安全增強并支持精確的單次投遞。Confluent Platform將會具有更多的客戶端、連接器，在Confluent Control Center中則會擴展監(jiān)控和管理功能。同時，Kafka Streams的第一個版本已經(jīng)隨Kafka 0.10一起發(fā)布了，Kafka社區(qū)和Confluent將會繼續(xù)致力于擴展Kafka Streams的功能。我們正在進行的一個特性就是在實現(xiàn)流處理應用的時候，可以使用的一個SQL接口。這是我們想要包含進來的一個特性，它有助于擴展Kafka Streams的用戶基礎，也能在總體上提升流處理能力。