Apache Kafka、Apache Storm、Apache Spark、Apache Samza、Apache Beam
生產、使用、處理和分析數據的速度正在以令人難以置信的步伐迅速增加。社交媒體、物聯網、廣告技術和游戲等垂直領域都在竭力處理大得出奇的數據集。這些行業需要近實時處理和分析數據。像Apache Hadoop這些大數據類型的傳統框架不是很適合這些使用場合。
因而，過去幾年已經啟動了多個開源項目，以處理數據流。它們都旨在處理來自不止一個數據源的源源不斷的記錄。從Kafka到Beam，有十多個Apache項目，它們處于不同的發展階段。
當前的Apache數據流項目高度重疊，針對類似的使用場景。用戶常常一頭霧水，不知該選擇哪種合適的開源架構，以實施實時數據流處理解決方案。本文試圖幫助客戶理清讓人眼花繚亂的Apache數據流項目，為此列出了每個項目的主要差異化優勢。我們將討論以下開源項目針對的使用場合和主要場景：Apache Kafka、Apache Storm、Apache Spark、Apache Samza、Apache Beam及相關項目。
Apache Flume
Apache Flume是歷史最悠久的Apache項目之一，它旨在收集和聚合龐大數據集（比如Web服務器日志），并將它們轉移到中心位置。它屬于數據收集和單事件處理系列的數據流處理解決方案。Flume基于代理驅動型架構，客戶端生成的事件直接流式傳輸到Apache Hive、HBase或其他數據存儲區。
Flume的配置包括：來源、通道和接收器（sink）。來源可以是任何東西：從系統日志（Syslog）、Twitter數據流到Avro端點，不一而足。通道定義了數據流如何傳輸到目的地。有效的選項包括：內存、Java數據庫連接（JDBC）、Kafka、文件及其他。接收器則定義了數據流傳輸到哪個目的地。Flume支持許多接收器，比如Hadoop分布式文件系統（HDFS）、Hive、HBase、ElasticSearch、Kafka及其他。
Flume
Apache Flume很適合客戶端基礎設施支持安裝代理的場景。最流行的使用場合就是，將來自多個來源的日志流式傳輸到中央持久性數據存儲區，供進一步處理分析。
典型的使用場合：流式傳輸來自能夠運行Java虛擬機（JVM）的多個來源的日志。
Apache Spark
Apache Spark是大數據生態系統中最炙手可熱的技術。由于快速的內存處理功能以及一套表達式開發API，它引起了廣大數據科學家和開發人員的注意。Spark最初是在加州大學伯克利分校的AMPLab開發而成，后來被捐贈給了Apache軟件基金會。
Apache Spark為開發人員提供的一套API圍繞一種名為彈性分布式數據集（RDD）的數據結構，這是只讀格式的多重集數據項，這些數據項分布在具有容錯機制的機器集群上。Spark旨在克服MapReduce的局限性，RDD充當分布式程序的工作集，充分利用分布式共享內存。Spark聲稱在內存中處理起來比Hadoop MapReduce快100倍，在磁盤上運行時快10倍。
Spark用Scala編寫，但支持多種編程語言。它隨帶適配件，可以處理存儲在不同來源的數據，包括HDFS文件、Cassandra、HBase和亞馬遜S3。
Spark Streaming是一個必不可少的組件，用于構建容錯的數據流應用程序。它讓開發人員能夠借助Spark的高級API，構建數據流應用程序。由于Spark Streaming在Spark上運行，讓開發人員得以重復使用同一代碼用于批處理，針對歷史數據合并數據流，或者對數據流狀態運行即席查詢。它可用于構建傳統分析之外的強大的交互式應用程序。Spark Streaming在微批處理（micro-batching）模式下運行，批任務大小比常規批處理小得多。
Spark（來源：Toptal）
雖然不是一個嚴格的要求，但Spark可以在現有的Hadoop和Mesos集群上運行。它提供了一個外殼，可用于交互式探究數據。
Apache Spark與Apache Kafka結合起來后，就能提供一種強大的數據流處理環境。
典型的使用場合：實時處理社交媒體內容，以執行情感分析。
Apache Storm
Apache Storm最初由BackType公司（已被Twitter收購）的內森·馬茲（Nathan Marz）開發。收購后，Twitter開放了Storm的源代碼，后來捐贈給Apache軟件基金會。Storm備受Flipboard、雅虎和Twitter等公司的信賴，已逐漸成為開發分布式實時數據處理平臺的標準。
Storm常常被稱為是用于實時處理的Hadoop。據官方說明文檔顯示，“有了Storm，就很容易可靠地處理無邊界數據流，它之于實時處理，如同Hadoop之于批處理。”
Apache Storm主要是為確保可擴展性和容錯性設計的。它保證每個元組（tuple）會至少處理一次。雖然它是用Clojure編寫的，但應用程序可以用讀寫標準輸入輸出數據流的任何編程語言來編寫。Storm旨在支持連接輸入數據流，名為“spout”和“bolt”，它們是處理模塊和輸出模塊。spout和bolt組合構成了有向非循環圖（DAG），這被稱為拓撲結構?；陬A先定義的配置，拓撲結構可以在集群上運行，調度程序將工作量分配到屬于集群一部分的節點上。
Storm拓撲結構常常與Hadoop MapReduce作業相比較。但不同于Hadoop作業，拓撲結構持續運行，直到被終止。在拓撲結構里面，spout獲取數據，之后數據將通過一系列bolt。每個bolt負責轉換或處理數據。一些bolt可能將數據寫入到持久性數據庫或文件，而另一些bolt可能調用第三方API來轉換數據。
來源：Hortonworks
由于開源生態系統，有一系列豐富的spout可用于流行的數據源，它們由社區創建。借助適配件概念，Storm可與HDFS文件系統實現互操作，參與Hadoop作業。
Storm經常與Apache Kafka和Apache Spark等其他數據獲取和處理組件結合起來使用。它提供了一種可靠、可擴展、容錯的分布式計算框架。
典型的使用場合：實時轉換和處理社交媒體/物聯網傳感器數據流。
Apache NiFi
相比其他數據流解決方案，Apache NiFi是個比較新的項目，2015年7月份升級成為Apache的頂級項目。它基于企業集成模式（EIP），數據在到達目的地之前經歷多個階段和多次轉換。
Apache NiFi隨帶一個高度直觀的圖形界面，因而很容易設計數據流和轉換。業務分析師和決策者可以使用該工具來定義數據流。它支持眾多輸入源，包括靜態數據集和流式數據集。從文件系統、社交媒體數據流、Kafka、FTP、HTTP和JMS等數據源獲取的數據可以流到諸多目的地，包括ElasticSearch、亞馬遜S3、AWS Lambda、Splunk、Solr、SQL和NoSQL數據庫。轉換內容可以被引入到數據流的路徑。
NiFi
新興的工業物聯網領域需要一種強大、可靠和安全的數據流引擎。Apache NiFi有望成為最受青睞的編排引擎，用于處理實施的物聯網系統中的傳感器數據。
它結合了Node-Red的簡潔和大數據的力量。內置了支持Kafka、JMS及其他通道的功能，因而成為企業物聯網解決方案的一種理想選擇。
Apache NiFi面向的經典場景之一是，構建熱路徑和冷路徑分析。物聯網設備和傳感器生成的數據集含有需要實時分析的某些數據點，而一小部分的數據存儲起來用于批處理。這類數據集通常通過高速引擎來流式傳輸，比如Apache Kafka、亞馬遜Kinesis和Azure Event Hubs。Apache NiFi可以用來為同一數據集定義兩條不同的路徑：負責近實時處理的熱路徑和負責批處理的冷路徑。
典型的使用場合：定義物聯網傳感器數據流動的交互式規則引擎。
Apache Apex
總部位于硅谷的DataTorrent公司將其中一款實時數據流商業產品捐贈給了Apache軟件基金會，該產品現在名為Apache Apex。它是Apache歷史最短的項目之一，已從孵化器項目升級成為頂級項目。Apache Apex定位于作為Apache Storm和Apache Spark的替代方案，用于實時數據流處理。它聲稱，速度至少比Spark快10倍到100倍。
相比Apache Spark，Apex自帶企業功能，比如事件處理、保證事件傳遞有順序，以及核心平臺層面的容錯機制。不像Spark需要Scala方面有過硬的技能，現有的Java開發人員就可以使用Apex。它可以在現有的Hadoop生態系統里面順暢運行，使用YARN用于向上擴展或向下擴展，同時使用HDFS用于容錯。
Apex
Apache Apex定位于業界唯一的開源企業級引擎，既能夠處理批數據，又能滿足數據流的要求。它是一種動態數據平臺，允許統一處理實時無邊界數據流（流式作業）或常規文件中的邊界數據（批作業）。企業組織可以構建應用程序以適合其業務邏輯，并且跨流式作業和批處理來擴展應用程序。Apache Apex架構可以處理從消息總線、文件系統、數據庫或其他任何數據源讀取數據，或將數據寫入到這些對象。只要這些數據源擁有可以在JVM里面運行的客戶代碼，就可以實現無縫集成。
Apex隨帶一個名為Malhar的操作符庫，這些預先構建的操作符面向數據源和目的地，比如消息總線、文件系統和數據庫。這些操作符讓開發人員能夠快速構建處理眾多數據源的業務邏輯。Apex的總體目標是降低企業中大數據項目的復雜性。
典型的使用場合：在容錯基礎設施上運行的應用，需要實時處理異構數據集以及需要在批模式下處理數據集。
Apache Kafka Streams
Kafka Streams就是建立在流行的數據獲取平臺Apache Kafka上的一個庫。源代碼作為Kafka項目的一部分來提供。它由Confluent捐贈，創辦這家初創公司的正是LinkedIn當初開發Kafka項目的一群人。
不久前，Apache Kafka成為了最流行的實時大規模消息傳遞系統。它迅速成為了當代數據平臺的核心基礎設施構建模塊。它用于眾多行業的成千上萬家公司，包括Netflix、思科、貝寶和Twitter。Kafka還成了提供托管型大數據和分析平臺的公共云提供商提供的一項托管服務。
Kafka Streams是一個庫，用于構建數據流應用程序，具體來說是指負責將輸入Kafka主題轉換為輸出Kafka主題的那些應用程序。它不是為大型分析設計的，而是為提供高效、緊湊的數據流處理的微服務設計的。這意味著，Kafka Streams庫旨在集成到應用程序的核心業務邏輯中，而不是作為批分析作業的一部分。
Kafka
Kafka Streams幫助用戶擺脫了這項任務：安裝、配置和管理專門為數據流處理而部署的復雜Spark集群。它簡化了數據流處理，因而讓它可以作為一種面向異步服務的獨立式應用編程模型。開發人員無需數據流處理集群，就可以嵌入Kafka Streams功能。該架構會有Apache Kafka和應用程序，沒有外部的依賴項。
Kafka Streams提供了與Kafka提供的核心抽象完全集成的處理模式，以便減少數據流架構中活動部分的總數。它不是通常為了處理批處理而編寫的MapReduce代碼的一部分。
討論Kafka Streams時，還有必要談提到Kafka Connect，這種框架可靠地將Kafka與外部系統連接起來，比如數據庫、鍵值存儲系統、搜索索引和文件系統。
Kafka Streams的最大優點是，它可以包裝成一個容器，可以放在Docker上。開發運維團隊還可以使用Ansible、Puppet、Chef、Salt，甚至外殼腳本，以部署和管理應用程序。一旦被包裝成容器，它可以與眾多編排引擎集成起來，比如Docker Swarm、Kubernetes、DC/OS、Yarn及其他編排引擎。
典型的使用場合：需要嵌入式數據流處理功能，又不依賴復雜集群的微服務和獨立式應用程序。
相關網址：http://docs.confluent.io/3.0.0/streams/index.html
Apache Samza
Apache Samza是在LinkedIn開發出來的，避免Hadoop的批處理需要的那種漫長的周轉時間。它建立在Apache Kafka這低延遲分布式消息傳遞系統的基礎上。開發Samza的初衷是，為數據持續處理提供一種輕量級框架。
Kafka和Samza這對組合好比HDFS和MapReduce。如果HDFS充當MapReduce作業的輸入，那么Kafka獲取由Samza處理的數據。數據流入時，Samza可以持續計算結果，提供亞秒級響應時間。
從數據流獲得輸入后，Samza執行作業，作業其實是使用和處理一組輸入數據流的代碼。作業可能用Java、Scala或支持JVM的其他語言編寫。為了確?？蓴U展性，作業進一步細分為名叫任務（task）的更小執行單位，任務是一種并行處理單位，就好比數據流的分區。每個任務使用由其中一個分區傳輸的數據。
任務按順序處理來自每一個輸入分區的消息，按照消息偏移的次序。沒有跨分區的定義順序，讓每個任務可以獨立運行。
Samza
Samza將在一個或多個容器里面執行的多個任務分成一組，容器是隔離的操作系統進程，運行JVM，負責為某一個作業執行一組任務。容器是單線程，負責管理任務的生命周期。
Samza及其他數據流技術之間的主要區別在于有狀態的數據流處理功能。Samza任務有專門的鍵/值存儲區，位于同樣任務的機器上。這種架構提供的讀寫性能勝過其他任何數據流處理軟件。
由于Samza從LinkedIn廣泛使用的Kafka發展而來，它有著出色的兼容性。它變成了Kafka用于獲取數據的架構當中的一種自然選擇。
Apache Samza和Kafka Streams旨在處理同一個問題，后者是一種可嵌入庫，而不是功能完備的軟件。
典型的使用場合：經過優化的數據流處理，面向利用Kafka來獲取數據的應用。
Apache Flink
Apache Flink最初于2010年在德國開發，當時還叫“Stratosphere：云端信息管理系統”，它是德國柏林工業大學、柏林洪堡大學和波茨坦哈索－普拉特納學院合作的產物。提交給Apache軟件基金會后，它在2014年12月成為了一個頂級項目。起初，Apache Flink的概念和使用場合類似Apache Spark。它旨在成為運行批處理、數據流處理、交互處理、圖形處理和機器學習等應用的單一平臺。
但是Spark和Flink在實施方面存在著區別。
Spark Streaming旨在處理小批作業，提供近實時功能。由于細粒度事件級處理架構，Apache Flink提供實時處理。
Flink為數據流處理帶來了幾項獨特的功能。它為狀態更新提供了數據僅處理一次并且僅輸出一次（exactly-once）的保證，讓開發人員不必面臨處理重復的負擔。它有一種高吞吐量引擎，可以在通過分布式網絡發送事件之前緩存事件。Flink提供了一種強大的數據流編程模型，擁有靈活的窗口方案。
Flink
Flink旨在既是用于數據流分析的DataStream API，又是在底層數據流處理引擎上用于批分析的DataSet API。
Apache Flink支持用Java或Scala編寫的程序，這類程序會自動編譯并優化，變成數據流程序。Flink并沒有數據存儲系統。輸入數據可能來自像HDFS或HBase這樣的分布式存儲系統。至于數據流處理，Flink可以使用來自Kafka等消息隊列的數據。
典型的使用場合：實時檢測和預防欺詐性信用卡交易。
Apache Beam
Apache Beam是Apache軟件基金會越來越多的數據流項目中最新增添的成員。這個項目的名稱表明了設計：結合了批處理（Batch）模式和數據流（Stream）處理模式。它基于一種統一模式，用于定義和執行數據并行處理管道（pipeline），這些管理隨帶一套針對特定語言的SDK用于構建管道，以及針對特定運行時環境的Runner用于執行管道。
谷歌以及Data Artisans、Cloudera和貝寶將其大數據服務的SDK：Cloud Dataflow捐贈給Apache軟件基金會，后來它成為了Apache Beam的基礎。它由谷歌的眾多內部項目演變而來，比如MapReduce、FlumeJava和Millwheel。Beam中的Pipeline Runners概念可將數據處理管道轉變成與多個分布式處理后端兼容的API。管道是一連串在數據集上運行的進程。每個Beam程序都會有面向后端的runner，這取決于管道在哪里執行。該平臺目前支持的runner包括：谷歌Cloud Dataflow、Apache Flink和Apache Spark。正在開發支持Storm和MapReduce等其他runner的功能。
Beam
Beam可以解決什么問題？當MapReduce作業從Hadoop遷移到Spark或Flink，就需要大量的重構。Dataflow試圖成為代碼和執行運行時環境之間的一個抽象層。代碼用Dataflow SDK實施后，會在多個后端上運行，比如Flink和Spark。Beam支持Java和Python，與其他語言綁定的機制在開發中。它旨在將多種語言、框架和SDK整合到一個統一的編程模型。
典型的使用場合：依賴多種框架（包括Flink和Spark）的應用程序。
相關網址：http://beam.incubator.apache.org
Apache Ignite
Apache Ignite是建立在分布式內存計算平臺上的一個內存層。它經過了優化，以便實時處理龐大數據集。內存架構讓它的運行速度比基于磁盤或基于閃存的傳統技術要快得多。
該項目最初是由GridGain Systems開發的，后來它在2014年捐贈給了Apache軟件基金會。2015年9月份，Ignite從孵化器項目升級為頂級項目。
雖然Spark和Ignite都依賴分布式內存處理架構，但兩者之間還是存在細微的差別。Spark主要是為交互式分析和機器學習等應用設計的，而Ignite旨在提供編程實時分析、機器對機器通信和高性能事務處理。
Ignite有可能成為事務處理系統的優選解決方案，比如股票交易、欺詐檢測、實時建模和分析。無論是在商用硬件上運行的橫向擴展架構，還是在高端工作站和服務器上的縱向擴展，Ignite同樣可以輕松應對。
Ignite
Ignite數據流功能讓用戶能夠以可擴展、容錯的方式，處理持續不斷的數據流。數據注入Ignite的速度可以非?？?，在一個中等規模的集群上每秒輕松超過100萬個事件。
典型的使用場合：高度依賴編程實時分析、機器對機器通信和高性能事務處理的應用。
相關網址：https://ignite.apache.org
云頭條編譯｜未經授權謝絕轉載
歡迎加入交流，群主微信：aclood
